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 13:56 +0000, Paul Durrant wrote:
> > -----Original Message-----
> > From: Ian Campbell
> > Sent: 17 March 2014 12:54
> > To: Paul Durrant
> > Cc: xen-devel@xxxxxxxxxxxxx
> > Subject: Re: [Xen-devel] [PATCH v3 5/6] ioreq-server: add support for
> > multiple servers
> > 
> > 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.
> > 
> 
> I see. I guess the only other option is to put the pfns somewhere that
> we can always grow (within reason). The guest itself never maps these
> pfns, only the emulator, but they should be part of the guest's
> allocation. Is there somewhere else in the p2m that they could live
> such that we can grow the space even for migrated-in guests? Somewhere
> just above the top of RAM perhaps?

It's always struck me as odd to have a Xen<->DM communication channel
sitting there in guest pfn space (regardless of who the nominal owner
is).

I don't suppose there is any way to pull these pages out of the guest
pfn space while still accounting them to the guest. Or if there is it
would probably be a whole other kettle of fish than this series.

Ian.


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