Re: [Xen-devel] [PATCH v10 1/3] ioreq-server: add support for multiple servers

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

Hi, Paul,

This is a nice work, and great all of your patches have been accepted in
the upstream. Based on previous discussion, it should address a similar
requirement in XenGT (Intel GVT-g as recently announced), and we plan
to evaluate and move to it.

One basic question first, though I think the answer is likely no. Is this
ioreq server designed solely for multiple servers in user space? XenGT
has all the necessary bits in a kernel driver in Dom0, except legacy VGA
emulation still carried by Qemu. So want to make sure no obvious 
limitation against our usage.

Thanks
Kevin

> From: Paul Durrant
> Sent: Monday, June 02, 2014 1:35 AM
> 
> > -----Original Message-----
> > From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
> > Sent: 02 June 2014 09:05
> > To: Paul Durrant
> > Cc: Ian Jackson; Stefano Stabellini; xen-devel@xxxxxxxxxxxxx
> > Subject: Re: [PATCH v10 1/3] ioreq-server: add support for multiple servers
> >
> > >>> On 22.05.14 at 12:38, <paul.durrant@xxxxxxxxxx> wrote:
> > > The previous single ioreq server that was created on demand now
> > > becomes the default server and an API is created to allow secondary
> > > servers, which handle specific IO ranges or PCI devices, to be added.
> > >
> > > When the guest issues an IO the list of secondary servers is checked
> > > for a matching IO range or PCI device. If none is found then the IO
> > > is passed to the default server.
> > >
> > > Secondary servers use guest pages to communicate with emulators, in
> > > the same way as the default server. These pages need to be in the
> > > guest physmap otherwise there is no suitable reference that can be
> > > queried by an emulator in order to map them. Therefore a pool of
> > > pages in the current E820 reserved region, just below the special
> > > pages is used. Secondary servers allocate from and free to this pool
> > > as they are created and destroyed.
> > >
> > > The size of the pool is currently hardcoded in the domain build at a
> > > value of 8. This should be sufficient for now and both the location and
> > > size of the pool can be modified in future without any need to change the
> > > API.
> > >
> > > Signed-off-by: Paul Durrant <paul.durrant@xxxxxxxxxx>
> > > Acked-by: Ian Campbell <ian.campbell@xxxxxxxxxx>
> >
> > I committed and pushed this, but I had to fix up two build errors
> > with XSM enabled. Please in the future make sure patches you
> > submit build in all relevant modes.
> >
> 
> Apologies. I didn't realise I had to explicitly enable it in the build. I'll 
> know for
> next time.
> 



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