Re: [PATCH v2] xen/arm: implement GICD_I[S/C]ACTIVER reads

[Julien Grall <julien@xxxxxxx>]

On 03/04/2020 11:43, George Dunlap wrote:
> > On Apr 3, 2020, at 9:47 AM, Marc Zyngier <maz@xxxxxxxxxx> wrote:
> >
> > On 2020-04-02 19:52, Julien Grall wrote:
> > > (+Marc)
> > Thanks for looping me in. Definitely an interesting read, but also a very
> > puzzling one.
> [snip]
>
> > No. Low latency is a very desirable thing, but it doesn't matter at all when
> > you don't even have functional correctness. To use my favourite car analogy,
> > having a bigger engine doesn't help when you're about to hit the wall and
> > have no breaks... You just hit the wall faster.
> [snip]
>
> > s/imprecise/massively incorrect/
> [snip]
>
> > There is just no way I'll ever accept a change to the GIC interrupt state
> > machine for Linux. Feel free to try and convince other OS maintainers.
> [snip]
>
> > If I was someone developing a product using Xen/ARM, I'd be very worried
> > about what you have written above. Because it really reads "we don't care
> > about reliability as long as we can show amazing numbers". I really hope
> > it isn't what you mean.
> What's puzzling to me, is that what everyone else in this thread is that what 
> Stefano is trying to do is to get Xen to be have like KVM.
This reads to me as "bugs don't exist".

As I actually said in a previous e-mail, our vGIC is significantly 
different compare to KVM. It *might* be possible they are not affected 
because the may trap when a guest is deactivating an interrupt *or* by 
other means.
I didn't look in the details their implementation, but this suggests you 
or Stefano may have. Why do you think Stefano's implementation is 
following what KVM does? If the behavior is the same, was the problem 
reported to KVM ML? What was the answer from the maintainers?
I suspect this was never discussed on KVM ML. So that should really be 
the first step.
Cheers,

--
Julien Grall