Re: [Xen-devel] [PATCH v4 8/8] ioreq-server: bring the PCI hotplug controller implementation into Xen

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Ian Campbell
> Sent: 08 April 2014 09:57
> To: Paul Durrant
> Cc: xen-devel@xxxxxxxxxxxxx; Ian Jackson; Stefano Stabellini; Jan Beulich
> Subject: Re: [PATCH v4 8/8] ioreq-server: bring the PCI hotplug controller
> implementation into Xen
> 
> On Tue, 2014-04-08 at 09:49 +0100, Paul Durrant wrote:
> > > -----Original Message-----
> > > From: Ian Campbell
> > > Sent: 08 April 2014 09:45
> > > To: Paul Durrant
> > > Cc: xen-devel@xxxxxxxxxxxxx; Ian Jackson; Stefano Stabellini; Jan Beulich
> > > Subject: Re: [PATCH v4 8/8] ioreq-server: bring the PCI hotplug controller
> > > implementation into Xen
> > >
> > > On Tue, 2014-04-08 at 09:25 +0100, Paul Durrant wrote:
> > >
> > > > > Also, if you are obscuring those regions now how does it continue to
> > > > > work?
> > > > >
> > > >
> > > > We only obscure the old regions if we create the in-xen hotplug
> > > > controller. This doesn't happen for migrated-in guests.
> > >
> > > I presume it does happen for migrated in guests from new Xen with this
> > > support?
> >
> > Sorry, yes. I meant migrated-in guests from old xen; I'll fix the text.
> >
> > >
> > > > > Hrm, so I didn't see anything on the restore side which handles the
> > > > > registration or not of the thing which would lead to EOPNOTSUPP vs
> > > > > success on a guest started on an older Xen. How does all that actually
> > > > > hang together?
> > > > >
> > > >
> > > > If the guest was started on an older xen then
> > > > HVM_PARAM_NR_IOREQ_SERVER_PAGES would not have been set,
> so
> > > when
> > > > xc_domain_restore runs it would find no corresponding save record.
> > > > Thus that param would not be set on restore and hence the controller
> > > > would not be created. I could add another hvm op to make hotplug
> > > > controller creation explicit if you like, but it seemed like rather a
> > > > lot of extra code.
> > >
> > > I think what wasn't obvious was that the use of the ioreq server
> > > interfaces also implicitly causes the hotplug controller to be enabled
> > > within Xen instead of elsewhere. I can see the chain of events which
> > > leads to this now that it has been pointed out, and with that I can see
> > > where the commit message implies it, but I think it could do with being
> > > made explicit.
> > >
> >
> > Ok. I can shortcut some code-churn by using an HVM param (e.g. setting
> > it to non-zero creates the controller) or would you prefer a new
> > HVMOP?
> 
> Sorry, I meant explicit in the docs/comments etc, I don't think an
> explicit HVPOP is necessarily worth it (although the hypervisor side
> people may disagree and I wouldn't object to adding it).
> 
> It's possible that just making the support for migration from older
> Xen's more explicit in the restore code as we were discussing on another
> and having a suitable comment at that point will be sufficient.
> 

Ok. I'll do that then :-)

  Paul

> e.g.
> 
>       /* If we are migrating from blah then register the blah blah,
>        * this will also enable the in-Xen hotplug controller. etc etc
>        * If we are migrating from an older Xen then this chunk won't
>        * be present and the hotplug controller is provided by qemu
>        * (sometimes?) and the ioreq pfns are ...  */
>       if (we got the new chunk)
>       {
>               xc_hvm_whatever(...)
>       }
> 
> (fill in the details ;-))
> 
> Ian.

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