Re: [RFC PATCH v1 1/4] irqchip/gic-v4.1: Plumb get_irqchip_state VLPI callback

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2020-12-01 09:38, luojiaxing wrote:
On 2020/11/28 18:18, Marc Zyngier wrote:
On Sat, 28 Nov 2020 07:19:48 +0000,
luojiaxing <luojiaxing@xxxxxxxxxx> wrote:

How can you confirm that the interrupt pending status is the latest?
Is it possible that the interrupt pending status is still cached in
the GICR but not synchronized to the memory.
That's a consequence of the vPE having been unmapped:

"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."


Yes, in addition to that, if a vPE is scheduled out of the PE, the
cache clearing and write-back to VPT are also performed, I think.

There is no such architectural requirement.

However, I feel a litter confusing to read this comment at first , 
because it is not only VMAPP that causes cache clearing.

I can't see anything else that guarantee that the caches are clean,
and that there is no possible write to the PE table.

I don't know why VMAPP was mentioned here until I check the other two
patches ("KVM: arm64: GICv4.1: Try to save hw pending state in
save_pending_tables").

So I think may be it's better to add some background description here.

Well, relying on the standard irqchip state methods to peek at the
pending state isn't very reliable, as you could be temped to call into
this even when the VPE is mapped. Which is why I've suggested
a different implementation.

        M.
--
Jazz is not dead. It just smells funny...



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux