gicv3_its: Flush cache after allocating ITT memory
ClosedPublic
Actions

Authored by kd on Apr 29 2021, 10:19 AM.

Details

Reviewers

andrew
mw
wma
manu

Commits

rGe245ee2774b3: gicv3_its: Flush cache after allocating ITT memory

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 created this revision.Apr 29 2021, 10:19 AM

Herald added a reviewer: manu. · View Herald TranscriptApr 29 2021, 10:19 AM

Herald added a subscriber: emaste. · View Herald Transcript

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?

kd updated this revision to Diff 88404.Apr 30 2021, 7:13 AM

In D30033#674082, @andrew wrote:

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

andrew added inline comments.Apr 30 2021, 9:41 AM

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.

kd added inline comments.Apr 30 2021, 9:50 AM

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.