Page MenuHomeFreeBSD

gicv3_its: Flush cache after allocating ITT memory
ClosedPublic

Authored by kd on Apr 29 2021, 10:19 AM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 14 2024, 9:40 PM
Unknown Object (File)
Feb 7 2024, 7:45 PM
Unknown Object (File)
Jan 31 2024, 4:02 PM
Unknown Object (File)
Jan 28 2024, 4:44 AM
Unknown Object (File)
Jan 23 2024, 5:28 PM
Unknown Object (File)
Jan 12 2024, 2:45 AM
Unknown Object (File)
Dec 7 2023, 12:29 PM
Unknown Object (File)
Dec 6 2023, 9:32 PM
Subscribers

Details

Summary

It has to be zeroed before committing it to device.
We do that by allocating it with M_ZERO, but there was no memory barrier or cache flush to ensure its sees it zeroed.
This fixes MSIX on LS1028A SoC.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

kd requested review of this revision.Apr 29 2021, 10:19 AM

Does this need to be done in all cases, or just when the ITS is not cache-coherent?

Does this need to be done in all cases, or just when the ITS is not cache-coherent?

Good question. I checked and Linux does this flush unconditionally.
With that being said our driver worked on cache-coherent devices without it.
Updated the revision to do the flush on non cache-coherent devices only

sys/arm64/arm64/gicv3_its.c
1203

I think we want a dsb(ishst); in the else case to ensure any previous writes to itt are complete. We might get it via the spinlock below, but shouldn't rely on it.

sys/arm64/arm64/gicv3_its.c
1203

I though about it and I don't think it is necessary here.
Before itt is committed to the ITS its_cmd_sync will be called, which does dsb(ishst); for cache-coherent devices.

This revision is now accepted and ready to land.Apr 30 2021, 1:50 PM