Re: [Xen-devel] [PATCH v3 5/6] ioreq-server: add support for multiple servers

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2014-03-17 at 12:51 +0000, Paul Durrant wrote:

> > > > > diff --git a/tools/libxc/xc_domain_restore.c
> > > > b/tools/libxc/xc_domain_restore.c
> > > > > index 1f6ce50..3116653 100644
> > > > > --- a/tools/libxc/xc_domain_restore.c
> > > > > +++ b/tools/libxc/xc_domain_restore.c
> > > > > @@ -746,6 +746,7 @@ typedef struct {
> > > > >      uint64_t acpi_ioport_location;
> > > > >      uint64_t viridian;
> > > > >      uint64_t vm_generationid_addr;
> > > > > +    uint64_t nr_ioreq_servers;
> > > >
> > > > This makes me wonder: what happens if the source and target hosts do
> > > > different amounts of disaggregation? Perhaps in Xen N+1 we split some
> > > > additional component out into its own process?
> > > >
> > > > This is going to be complex with the allocation of space for special
> > > > pages, isn't it?
> > > >
> > >
> > > As long as we have enough special pages then is it complex?
> > 
> > The "have enough" is where the complexity comes in though. If Xen
> > version X needed N special pages and Xen X+1 needs N+2 pages then we
> > have a tricky situation because people may well configure the guest with
> > N.
> > 
> 
> I don't quite follow. The specials are just part of the guest image
> and so they get migrated around with that guest, so providing we know
> how many special pages a guest had when it was created (so we know how
> many there are to play with for secondary emulation) there's no
> problem is there?

What if the newer version of Xen requires more secondaries than the
older one? That's the case I'm thinking of.

Ian.


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