Re: [Xen-devel] [PATCH] x86/hvm: more sure APIC assist is aborted if guest EOIs APIC

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Xen-devel [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf
> Of Paul Durrant
> Sent: 18 January 2018 10:37
> To: 'Jan Beulich' <JBeulich@xxxxxxxx>
> Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; xen-
> devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH] x86/hvm: more sure APIC assist is aborted
> if guest EOIs APIC
> 
> > -----Original Message-----
> > From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> > Sent: 18 January 2018 10:17
> > To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>
> > Cc: Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>; xen-
> > devel@xxxxxxxxxxxxxxxxxxxx
> > Subject: RE: [PATCH] x86/hvm: more sure APIC assist is aborted if guest
> EOIs
> > APIC
> >
> > >>> On 18.01.18 at 10:55, <Paul.Durrant@xxxxxxxxxx> wrote:
> > > Ok. I'll re-work it so that abort is passed a vector and warns on 
> > > mismatch.
> >
> > You mean on the new path only, I suppose? The old path should
> > not trigger warnings (aiui it would always do so).
> 
> I think, in the existing abort case, the latched vector should always be the
> lowest pending bit in the ISR.
> 

Actually reading through the code and the spec. again, I'm not convinced by the 
logic even with the EOI fix. It looks to me like vlapic_has_pending_irq() could 
leave an existing assist in place and return a higher priority irr value. This 
guest would then service the higher priority interrupt, skip the EOI because 
the assist bit is set, but then the next call to vlapic_has_pending_irq() would 
erroneously clear the lower priority vector from the ISR because we originally 
latched the lower priority vector.
As the spec. points out... only the first EOI can avoided, thus I'm not sure 
trying to track the vector in the viridian code is worth it. It looks like the 
correct thing to do as test whether an EOI was avoided and then clear the 
highest priority vector in the ISR (since, if we hadn't squashed it, that would 
have been the first EOI). We can test when an EOI is avoided because the bit in 
the shared page would have transitioned from 1 to 0.

  Paul

>   Paul
> 
> >
> > Jan
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/mailman/listinfo/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel