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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@xxxxxxxxxxxxx]
> Sent: 05 September 2018 11:45
> To: Paul Durrant <Paul.Durrant@xxxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: Eslam Elnikety <elnikety@xxxxxxxxx>; Andrew Cooper
> <Andrew.Cooper3@xxxxxxxxxx>; Shan Haitao <haitao.shan@xxxxxxxxx>; Jan
> Beulich <jbeulich@xxxxxxxx>
> Subject: Re: [Xen-devel] [PATCH v2] x86/hvm: re-work viridian APIC assist
> code
> 
> On Wed, 2018-09-05 at 10:40 +0000, Paul Durrant wrote:
> >
> > Actually the neatest approach would be to get information into the
> > vlapic code as to whether APIC assist is suitable for the given
> > vector so that the code there can selectively enable it, and then Xen
> > would know it was safe to avoid fully emulating an EOI for anything
> > that did have assist enabled.
> 
> I'm not sure I understand why an assisted EOI should be any different
> from "normal" EOI.
> 
> The global lock and indirect function calls and all that stuff that
> hvm_dpci_msi_eoi() does are *expensive*, for a rare case.
> 
> Why not bypass all that when it's not needed, for "normal" EOI and
> APIC-assisted EOI alike? Why have a distinction between the two?

True. I guess that's more globally applicable... i.e. it would help guests not 
aware of the enlightenment, or those with it disabled.

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