Re: libxl/xl memory paging/sharing/ballooning/etc proposal.

[Olaf Hering <olaf@aepfle.de>]

On Thu, Mar 15, Ian Campbell wrote:

> On Thu, 2012-03-15 at 15:26 +0000, Olaf Hering wrote:
> > On Thu, Mar 15, Andres Lagar-Cavilla wrote:
> > 
> > 
> > > > libxl_domain_(set|get)_paging_target(ctx, domid, target_memkb, relative)
> > > >
> > > >         Read/write whichever XS path controls the xenpaging daemon's
> > > >         target. (Olaf?). I think this path should not be
> > > >         under /local/domain since it should not be guest visible
> > > >         (probably it already isn't).
> > > It is /local/domain/X/memory/target-tot_pages. I agree it should not be
> > > guest visible, and we're still in time to change it.
> > 
> > Is it guest visible? I think the entry point for a guest is /vm/<uuid>/,
> > I'm almost sure it can not get to /local/domain/X/memory/
> 
> /local/domain/X is generally considered to be part of the "guest
> visible" state and there are various guest visible things there,
> devices/* and memory/target spring to mind.

Is memory/target below /local/domain/X or /vm/<uuid> in use by the guet?
I'm sure the latter can only be used to set a watch for example (dont
have a guest at hand to verify).
Also the guest would have to proactivly parse the "links" to find its
domid, to later browse /local/domain/X.
What would it protect if /local/domain/X/memory (and other parts) are not accesible?

> > > /libxl/X/memory-policy/paging-target? Is there a non-libxl
> > > non-/local/domain path xenpaging could look into, should it be launched
> > > autonomously? Olaf, do you care about xenpaging in non-libxl environments?
> > 
> > xenpaging needs to read its target from somewhere, I dont think this has
> > anything todo with libxl or not.
> 
> Except that libxl needs to know where to write to.

Sure.

Olaf