On Thu, Dec 08, 2016 at 09:21:23AM -0700, Jan Beulich wrote: > >>> On 30.11.16 at 17:49, <roger....@citrix.com> 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. > > I continue to not really agree with this. For a while you can't assume > posted interrupts to be universally available. And iirc we still don't > enable their use by default in Xen. Hence I could see this to be the > preferred mechanism, but the event channel based mechanism may > want to remain an alternative, the more that ...
Maybe they are not universally available now, but AFAICT the trend in the hardware industry is to follow that route. Keep in mind that when PVHv2 Dom0 becomes production ready most of this technologies are going to be widely available. > > +### 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. > > ... you still need them anyway. Well, I think that event channels from virt devices and event channels from physical ones are quite different. IIRC Linux even uses a different IRQ chip in order to handle them. > Similarly I continue to be in disagreement with the blanket disabling > of all physdev ops. I'm not opposed to enabling some of them. I think we already agreed that at least PHYSDEVOP_pci_mmcfg_reserved is required on some hardware. I'm just opposed to wholesale enabling them all, like we did for PVHv1. Also, if we enable them now, we will be tied to this ABI, and then the only solution if we ever want to get rid of them is to bump the ABI. Roger. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
