Re: [RFC] ARM: New (Xen) VGIC design document

From: Christoffer Dall <christoffer.dall@linaro.org>
To: Stefano Stabellini <sstabellini@kernel.org>
Cc: Marc Zyngier <marc.zyngier@arm.com>,
	"xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Julien Grall <julien.grall@arm.com>,
	Andre Przywara <andre.przywara@linaro.org>,
	Eric Auger <eric.auger@redhat.com>
Subject: Re: [RFC] ARM: New (Xen) VGIC design document
Date: Thu, 2 Nov 2017 08:40:33 +0100	[thread overview]
Message-ID: <CAMJs5B9ewmm86uaKhOyNJ0m8J6si7UWMiyFKMQNcqNzuRDje9Q@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.10.1711011351390.1707@sstabellini-ThinkPad-X260>

On Wed, Nov 1, 2017 at 10:54 PM, Stefano Stabellini
<sstabellini@kernel.org> wrote:

[...]

>
>> > The suggestion of using this model in Xen was made in the past already.
>> > I always objected for the reason that we don't actually know how many
>> > LRs the hardware provides, potentially very many, and it is expensive
>> > and needless to read/write them all every time on entry/exit.
>> >
>> > I would prefer to avoid that, but I'll be honest: I can be convinced
>> > that that model of handling LRs is so much simpler that it is worth it.
>> > I am more concerned about the future maintainance of a separate new
>> > driver developed elsewhere.
>>
>> I think this LR topic should have been covered in that other email.
>>
>> Beside being a strong supporter of the KISS principle in general, I
>> believe in case of the GIC emulation we should avoid (premature)
>> optimizations like the plague, as there are quite some corner cases in
>> any VGIC, and handling all of them explicitly with some hacks will not
>> fly (been there, done that).
>> So I can just support Christoffer's point: having an architecture
>> compliant VGIC emulation in an maintainable manner requires a
>> straight-forward and clear design. Everything else should be secondary,
>> and can be evaluated later, if there are good reasons (numbers!).
>
> The reason why I stated the above is that I ran the numbers back in the
> day and reading or writing LRs on an XGene was so slow that it made
> sense to avoid it as much as possible. But maybe things have changed if
> Christoffer also ran the numbers and managed to demonstrate the
> opposite.

Accessing LRs on GICv2 is terrible indeed, and we already optimize it
as much as it makes sense.  It's just that with the current KVM code
base reading/writing the same value almost never happens, so there's
no more room (in practice) for optimization.

Also, note with GICv3 the cost goes down a lot, and potentially also
for other integrations of GICv2.

-Christoffer

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel