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: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?

  Paul

> Ian.

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