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

[Christoffer Dall <christoffer.dall@xxxxxxxxxx>]

On Wed, Nov 1, 2017 at 10:54 PM, Stefano Stabellini
<sstabellini@xxxxxxxxxx> 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@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel