From: andre.przywara@arm•com (Andre Przywara)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH v4 17/19] arm64: KVM: add SGI generation register emulation
Date: Fri, 28 Nov 2014 15:40:12 +0000 [thread overview]
Message-ID: <5478975C.5070107@arm.com> (raw)
In-Reply-To: <20141125110339.GD31297@cbox>
Hej Christoffer,
On 25/11/14 11:03, Christoffer Dall wrote:
> Hi Andre,
>
> On Mon, Nov 24, 2014 at 04:37:58PM +0000, Andre Przywara wrote:
>> Hi,
>>
>> On 23/11/14 15:08, Christoffer Dall wrote:
>>> On Fri, Nov 14, 2014 at 10:08:01AM +0000, Andre Przywara wrote:
>>>> While the generation of a (virtual) inter-processor interrupt (SGI)
>>>> on a GICv2 works by writing to a MMIO register, GICv3 uses the system
>>>> register ICC_SGI1R_EL1 to trigger them.
>>>> Trap that register on ARM64 hosts and handle it in a new handler
>>>> function in the GICv3 emulation code.
>>>
>>> Did you reorder something or does my previous comment still apply that
>>> you're not enabling trapping yet, you're just adding the handler - those
>>> are two different things.
>>
>> Yes, I can fix the wording.
>>
>>> You sort of left my question about access_gic_sgi() not checking if the
>>> gicv3 is presetn hanging from the last thread, but I think I'm
>>> understanding properly now, that as long as you're not setting the
>>> ICC_SRE_EL2.Enable = 1, then we'll never get here, right?
>>
>> Right, that is the idea. Just to make sure that I got this right from
>> the discussion the other day: We will not trap to EL2 as long as
>> ICC_SRE_EL2.Enable is 0 - which it should still be at this point, right?
>
> No, when ICC_SRE_EL2.Enable is 0, then Non-secure EL1 access to
> ICC_SRE_EL1 trap to EL2 (See Section 5.7.39 in the spec), which means
> that accesses to the ICC_SGIx registers will cause an undefined
> exception in the guest because we set ICC_SRE_EL1.SRE to 0 for the
> guest and the guest cannot change this.
>
> Now, when we set ICC_SRE_EL2.Enable to 1, then the guest can set
> ICC_SRE_EL1.SRE to 1 (and we also happen to reset it to 1), and we will
> indeed trap on guest access to the ICC_SGIx registers, because all
> virtual accesses to these registers trap.
>
> (Going back and checking where 'virtual accesses' is defined in the spec
> left me somewhere without any results, but I am guessing that because we
> set the ICH_HCR_EL2.En to 1, all accesses will be deemed virtual
> accesses, maybe the spec should be clarfied on this matter?).
>
> Anyhow, to get back to my original question, getting here requires
> a situation where the guest copy of the ICC_SRE_EL1.SRE is 1, which we
> only allow when we have properly initialized the GICv3 data structures.
So to summarize (and check) this: There is no real issue at this point?
And the code is totally fine after 19/19?
Would this kind of problem actually matter _inside_ a patch series? To
trigger an issue, we would need a bogus guest and bogus userland
(because at this point neither of them would see/inject a GICv3 FDT
node). I'd assume that running a kernel at this point is just for
debugging/bisecting? Where you wouldn't care about every corner case of
execution?
Please tell me if I should give my email reading a seventh pass ;-)
Regards,
Andre.
>> (I am asking because I struggle to find this in the spec).
>>
>> So actually your ICC_SRE_EL1 trap patch solved that problem ;-)
>>
>
> So I think this is a different thing, not related that closely to my
> question above.
>
> That patch was about when ICC_SRE_EL2.Enable is 0, then we would trap
> guest accesses to ICC_SRE_EL1 which did not have any sysreg handler
> installed, and ended up with an undefined exception in the guest instead
> of handling the trap as RAZ/WI.
>
next prev parent reply other threads:[~2014-11-28 15:40 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-14 10:07 [PATCH v4 00/19] KVM GICv3 emulation Andre Przywara
2014-11-14 10:07 ` [PATCH v4 01/19] arm/arm64: KVM: rework MPIDR assignment and add accessors Andre Przywara
2014-11-18 10:35 ` Eric Auger
2014-11-23 9:34 ` Christoffer Dall
2014-11-14 10:07 ` [PATCH v4 02/19] arm/arm64: KVM: pass down user space provided GIC type into vGIC code Andre Przywara
2014-11-18 10:36 ` Eric Auger
2014-11-14 10:07 ` [PATCH v4 03/19] arm/arm64: KVM: refactor vgic_handle_mmio() function Andre Przywara
2014-11-18 10:35 ` Eric Auger
2014-11-14 10:07 ` [PATCH v4 04/19] arm/arm64: KVM: wrap 64 bit MMIO accesses with two 32 bit ones Andre Przywara
2014-11-18 10:36 ` Eric Auger
2014-11-23 9:42 ` Christoffer Dall
2014-11-24 13:50 ` Andre Przywara
2014-11-24 14:40 ` Christoffer Dall
2014-11-14 10:07 ` [PATCH v4 05/19] arm/arm64: KVM: introduce per-VM ops Andre Przywara
2014-11-23 9:58 ` Christoffer Dall
2014-11-14 10:07 ` [PATCH v4 06/19] arm/arm64: KVM: move kvm_register_device_ops() into vGIC probing Andre Przywara
2014-11-18 10:43 ` Eric Auger
2014-11-18 10:58 ` Eric Auger
2014-11-18 11:03 ` Andre Przywara
2014-11-14 10:07 ` [PATCH v4 07/19] arm/arm64: KVM: dont rely on a valid GICH base address Andre Przywara
2014-11-14 10:07 ` [PATCH v4 08/19] arm/arm64: KVM: make the maximum number of vCPUs a per-VM value Andre Przywara
2014-11-23 13:21 ` Christoffer Dall
2014-12-08 14:10 ` Andre Przywara
2014-11-14 10:07 ` [PATCH v4 09/19] arm/arm64: KVM: make the value of ICC_SRE_EL1 a per-VM variable Andre Przywara
2014-11-14 10:07 ` [PATCH v4 10/19] arm/arm64: KVM: refactor MMIO accessors Andre Przywara
2014-11-14 10:07 ` [PATCH v4 11/19] arm/arm64: KVM: refactor/wrap vgic_set/get_attr() Andre Przywara
2014-11-23 13:27 ` Christoffer Dall
2014-11-14 10:07 ` [PATCH v4 12/19] arm/arm64: KVM: add vgic.h header file Andre Przywara
2014-11-18 14:07 ` Eric Auger
2014-11-18 15:24 ` Andre Przywara
2014-11-23 13:29 ` Christoffer Dall
2014-11-14 10:07 ` [PATCH v4 13/19] arm/arm64: KVM: split GICv2 specific emulation code from vgic.c Andre Przywara
2014-11-23 13:32 ` Christoffer Dall
2014-11-14 10:07 ` [PATCH v4 14/19] arm/arm64: KVM: add opaque private pointer to MMIO data Andre Przywara
2014-11-23 13:33 ` Christoffer Dall
2014-11-14 10:07 ` [PATCH v4 15/19] arm/arm64: KVM: add virtual GICv3 distributor emulation Andre Przywara
2014-11-14 11:07 ` Christoffer Dall
2014-11-17 13:58 ` Andre Przywara
2014-11-17 23:46 ` Christoffer Dall
2014-11-18 15:57 ` Eric Auger
2014-11-23 14:38 ` Christoffer Dall
2014-11-24 16:00 ` Andre Przywara
2014-11-25 10:41 ` Christoffer Dall
2014-11-28 15:24 ` Andre Przywara
2014-11-30 8:30 ` Christoffer Dall
2014-12-02 16:24 ` Andre Przywara
2014-12-02 17:06 ` Marc Zyngier
2014-12-02 17:32 ` Andre Przywara
2014-12-03 10:30 ` Christoffer Dall
2014-12-03 10:47 ` Andre Przywara
2014-12-03 11:06 ` Christoffer Dall
2014-12-03 10:29 ` Christoffer Dall
2014-12-03 10:44 ` Marc Zyngier
2014-12-03 11:07 ` Christoffer Dall
2014-12-03 10:28 ` Christoffer Dall
2014-12-03 11:10 ` Andre Przywara
2014-12-03 11:28 ` Arnd Bergmann
2014-12-03 11:39 ` Peter Maydell
2014-12-03 12:03 ` Andre Przywara
2014-12-03 13:14 ` Arnd Bergmann
2014-12-04 9:34 ` Christoffer Dall
2014-12-04 10:02 ` Eric Auger
2014-11-14 10:08 ` [PATCH v4 16/19] arm64: GICv3: introduce symbolic names for GICv3 ICC_SGI1R_EL1 fields Andre Przywara
2014-11-23 14:43 ` Christoffer Dall
2014-11-14 10:08 ` [PATCH v4 17/19] arm64: KVM: add SGI generation register emulation Andre Przywara
2014-11-23 15:08 ` Christoffer Dall
2014-11-24 16:37 ` Andre Przywara
2014-11-25 11:03 ` Christoffer Dall
2014-11-28 15:40 ` Andre Przywara [this message]
2014-11-30 8:45 ` Christoffer Dall
2014-12-03 17:50 ` Andre Przywara
2014-12-03 20:22 ` Christoffer Dall
2014-11-14 10:08 ` [PATCH v4 18/19] arm/arm64: KVM: enable kernel side of GICv3 emulation Andre Przywara
2014-11-24 9:09 ` Christoffer Dall
2014-11-24 17:41 ` Andre Przywara
2014-11-25 11:08 ` Christoffer Dall
2014-11-14 10:08 ` [PATCH v4 19/19] arm/arm64: KVM: allow userland to request a virtual GICv3 Andre Przywara
2014-11-24 9:39 ` Christoffer Dall
2014-11-24 9:33 ` [PATCH v4 00/19] KVM GICv3 emulation Eric Auger
2014-11-24 17:46 ` Andre Przywara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5478975C.5070107@arm.com \
--to=andre.przywara@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox