[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxx [mailto:xen-devel-
> bounces@xxxxxxxxxxxxx] On Behalf Of Paul Durrant
> Sent: 20 March 2014 11:22
> To: Tim (Xen.org)
> Cc: Ian Campbell; xen-devel@xxxxxxxxxxxxx
> Subject: Re: [Xen-devel] [PATCH v3 5/6] ioreq-server: add support for
> multiple servers
> 
> > -----Original Message-----
> > From: Tim Deegan [mailto:tim@xxxxxxx]
> > Sent: 20 March 2014 11:12
> > To: Paul Durrant
> > Cc: Ian Campbell; xen-devel@xxxxxxxxxxxxx
> > Subject: Re: [Xen-devel] [PATCH v3 5/6] ioreq-server: add support for
> > multiple servers
> >
> > At 14:52 +0000 on 17 Mar (1395064322), Paul Durrant wrote:
> > > > -----Original Message-----
> > > > From: Ian Campbell
> > > > 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.
> > > >
> > >
> > > The closest analogy I can think of accounting-wise would be shadow
> > > pages. I'll have a look at how they are handled.
> >
> > It should be much simpler than shadow pages _provided_ that nobody
> > adds a XENMAPSPACE namespace that uses real MFNs.  Shadow pages
> have
> > to be accounted weirdly becaus ethey can't be owned by the guest or PV
> > guests could just map them.
> >
> > As long as we stick to the rule that all HVM-guest operations have to
> > go through the p2m, and we don't let the guest map pages by MFN, then
> > removing it from the p2m is enough to stop the guest accessing it.
> >
> 
> My plan is to use alloc_domheap_pages() for secondary emulators so that
> the pages are accounted to the guest, but never add those pages to the
> p2m. For the default emulator I'll use the existing specials, for 
> compatibility.
> My concern is that this will limit secondary emulators to running in dom0,
> since they'll need to use DOMID_XEN to map the pages.
> 

Having talked this through with Tim, the conclusion is that emulator pages have 
to live in the guest p2m otherwise there's no good way to find them from the 
emulating domain. However, whilst the emulator is active it should be possible 
to remove them from the guest p2m so that the guest has no direct access.
So, I will  use a range special pfns as before, but simply advertise them via 
base and range HVM params so that I can allocate from and free to that space as 
ioreq servers come and go.

  Paul

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.