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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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.

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