Re: [PATCH v2] x86/hvm: re-work viridian APIC assist code

[Paul Durrant <Paul.Durrant@citrix.com>]

> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@infradead.org]
> Sent: 05 September 2018 10:40
> To: Paul Durrant <Paul.Durrant@citrix.com>; xen-devel@lists.xenproject.org
> Cc: Andrew Cooper <Andrew.Cooper3@citrix.com>; Jan Beulich
> <jbeulich@suse.com>; Eslam Elnikety <elnikety@amazon.de>; Shan Haitao
> <haitao.shan@intel.com>
> Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: re-work viridian APIC assist
> code
> 
> On Wed, 2018-09-05 at 09:36 +0000, Paul Durrant wrote:
> >
> > I see. Given that Windows has used APIC assist to circumvent its EOI
> > then I wonder whether we can get away with essentially doing the
> > same. I.e. for a completed APIC assist found in
> > vlapic_has_pending_irq() we simply clear the APIC assist and highest
> > vector in the ISR, rather than calling through to vlapic_EOI_set()
> > and suffering the overhead. I'll spin up a patch and give it a whirl.
> 
> I think that's fine if you don't actually pass unmaskable MSIs through
> to the guest in question, but if you *do* then you still need the EOI
> to happen properly to "unmask" it.
> 
> Hence my approach which is basically doing what you said and bypassing
> the expensive part of hvm_dpci_msi_eoi(), but *only* if there's no
> unmaskable MSI to worry about.

Yeah, I'm kind of trusting Windows to only use APIC assist in the case where it is sure there is no need to EOI. Perhaps your approach is safer.

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