Re: [Xen-devel] [PATCH v6 1/7] xen/x86: remove XENFEAT_hvm_pirqs for PVHv2 guests

[Roger Pau Monne <roger.pau@xxxxxxxxxx>]

On Mon, Feb 13, 2017 at 06:09:27AM -0700, Jan Beulich wrote:
> >>> On 10.02.17 at 13:33, <roger.pau@xxxxxxxxxx> wrote:
> > --- a/docs/misc/hvmlite.markdown
> > +++ b/docs/misc/hvmlite.markdown
> > @@ -75,3 +75,23 @@ info structure that's passed at boot time (field 
> > rsdp_paddr).
> >  
> >  Description of paravirtualized devices will come from XenStore, just as 
> > it's
> >  done for HVM guests.
> > +
> > +## Interrupts ##
> > +
> > +### Interrupts from physical devices ###
> > +
> > +Interrupts from physical devices are delivered using native methods, this 
> > is
> > +done in order to take advantage of new hardware assisted virtualization
> > +functions, like posted interrupts. This implies that PVHv2 guests with 
> > physical
> > +devices will also have the necessary interrupt controllers in order to 
> > manage
> > +the delivery of interrupts from those devices, using the same interfaces 
> > that
> > +are available on native hardware.
> > +
> > +### Interrupts from paravirtualized devices ###
> > +
> > +Interrupts from paravirtualized devices are delivered using event 
> > channels, see
> > +[Event Channel Internals][event_channels] for more detailed information 
> > about
> > +event channels. Delivery of those interrupts can be configured in the same 
> > way
> > +as HVM guests, check xen/include/public/hvm/params.h and
> > +xen/include/public/hvm/hvm_op.h for more information about available 
> > delivery
> > +methods.
> 
> Just FTR - my comments on v4 still stand; I especially don't buy
> your argument [1] of posted interrupts becoming more widely
> available, since - as pointed out before - we continue to not fully
> enable their use by default, due to unresolved problems with
> the implementation. Furthermore emulation_flags_ok() allows
> EMU_LAPIC to be clear (together with all other bits being clear),
> in which case posted interrupts can't be used at all afaict.

It only allows it for DomUs, which don't support passthrough at all. If a
device is passed thought, a LAPIC will be required.

Also note that the current set of physdev ops available to PVHv2 is completely
wrong. Since PVHv2 is considered a HVM guest from Xen PoV, it will take the
is_hvm_domain branch at the top of physdev_map_pirq, which will certainly lead
to all kinds of fun, because that's the weird path used in (PV)HVM guests that
allows them to remap interrupts from emulated or physical devices into event
channels. So at the moment, I think this should even be considered a bug-fix.

As I think I've said before, I don't think we should initially follow this
route for PVHv2, but in any case this can always be added afterwards by
re-enabling the XENFEAT_hvm_pirqs flag and fixing the physdev ops so they can
work properly in this context.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel