[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b63950513f519d9a04f9719f5aa6a2db@kernel.org>
Date: Fri, 20 Mar 2020 09:09:35 +0000
From: Marc Zyngier <maz@...nel.org>
To: Zenghui Yu <yuzenghui@...wei.com>
Cc: Auger Eric <eric.auger@...hat.com>,
linux-arm-kernel@...ts.infradead.org, kvmarm@...ts.cs.columbia.edu,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Jason Cooper <jason@...edaemon.net>,
Robert Richter <rrichter@...vell.com>,
Thomas Gleixner <tglx@...utronix.de>,
James Morse <james.morse@....com>,
Julien Thierry <julien.thierry.kdev@...il.com>,
Suzuki K Poulose <suzuki.poulose@....com>
Subject: Re: [PATCH v5 23/23] KVM: arm64: GICv4.1: Expose HW-based SGIs in
debugfs
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).
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.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
Powered by blists - more mailing lists