[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2ad38077300bdcaedd2e3b073cd36743@kernel.org>
Date: Tue, 01 Dec 2020 10:55:20 +0000
From: Marc Zyngier <maz@...nel.org>
To: Shenming Lu <lushenming@...wei.com>
Cc: James Morse <james.morse@....com>,
Julien Thierry <julien.thierry.kdev@...il.com>,
Suzuki K Poulose <suzuki.poulose@....com>,
Eric Auger <eric.auger@...hat.com>,
linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.cs.columbia.edu,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
Christoffer Dall <christoffer.dall@....com>,
Alex Williamson <alex.williamson@...hat.com>,
Kirti Wankhede <kwankhede@...dia.com>,
Cornelia Huck <cohuck@...hat.com>, Neo Jia <cjia@...dia.com>,
wanghaibin.wang@...wei.com, yuzenghui@...wei.com
Subject: Re: [RFC PATCH v1 3/4] KVM: arm64: GICv4.1: Restore VLPI's pending
state to physical side
On 2020-11-30 07:23, Shenming Lu wrote:
Hi Shenming,
> We are pondering over this problem these days, but still don't get a
> good solution...
> Could you give us some advice on this?
>
> Or could we move the restoring of the pending states (include the sync
> from guest RAM and the transfer to HW) to the GIC VM state change
> handler,
> which is completely corresponding to save_pending_tables (more
> symmetric?)
> and don't expose GICv4...
What is "the GIC VM state change handler"? Is that a QEMU thing?
We don't really have that concept in KVM, so I'd appreciate if you could
be a bit more explicit on this.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists