[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [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. 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |