On 2020-03-20 11:35, Zenghui Yu wrote:
Hi Marc,
On 2020/3/20 17:09, Marc Zyngier wrote:
Hi Zenghui,
On 2020-03-20 04:38, Zenghui Yu wrote:
Hi Marc,
On 2020/3/19 23:21, Marc Zyngier wrote:
With GICv4.1, you can introspect the HW state for SGIs. You can also
look at the vLPI state by peeking at the virtual pending table, but
you'd need to unmap the VPE first,
Out of curiosity, could you please point me to the "unmap the VPE"
requirement in the v4.1 spec? I'd like to have a look.
Sure. See IHI0069F, 5.3.19 (VMAPP GICv4.1), "Caching of virtual LPI
data
structures", and the bit that says:
"A VMAPP with {V,Alloc}=={0,1} cleans and invalidates any caching of
the
Virtual Pending Table and Virtual Configuration Table associated with
the
vPEID held in the GIC"
which is what was crucially missing from the GICv4.0 spec (it doesn't
say
when the GIC is done writing to memory).
OK. Thanks for the pointer!
Side note: it'd be good to know what the rules are for your own GICv4
implementations, so that we can at least make sure the current code is
safe.
As far as I know, there will be some clean and invalidate operations
when v4.0 VPENDBASER.Valid gets programmed.
Interesting. The ideal behaviour would be that the VPT is up-to-date and
the caches clean when Valid is cleared (and once Dirty flips to 0).
But not sure about behaviors
on VMAPP (unmap), it may be a totally v4.1 stuff. I'll have a talk with
our SOC team.
The VMAPP stuff is purely v4.1.
But how can the current code be unsafe? Is anywhere in the current code
will peek/poke the vpt (whilst GIC continues writing things into it)?
No. But on VM termination, the memory will be freed, and will eventually
be
reallocated. If the GIC can still write to that memory after it has been
freed, you end-up with memory corruption... Which is why I'm curious of
what ensures that on your implementation.
I'd also like to know the same thing about the QC implementation, but
there's nobody left to find out...
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
