Re: [RFC PATCH 0/3] xen/privcmd: support for paged-out frames

[David Vrabel <david.vrabel@citrix.com>]

On 24/08/12 02:32, Andres Lagar-Cavilla wrote:
> On Aug 23, 2012, at 1:13 PM, David Vrabel wrote:
> 
>> This series is a straight forward-port of some functionality from
>> classic kernels to support Xen hosts that do paging of guests.
>>
>> This isn't functionality the XenServer makes use of so I've not tested
>> these with paging in use (GridCentric requested that our older kernels
>> supported this and I'm just doing the forward port).
> 
> Thanks for this series. Very timely. I may add that we are not the
> only consumers of paging. This functionality was first added into
> classic kernels by Olaf Hering from Suse (added to cc).

Sure.

>> I'm not entirely happy about the approach used here because:
>>
>> 1. It relies on the meaning of the return code of the update_mmu
>> hypercall and it assumes the value Xen used for -ENOENT is the same
>> the kernel uses. This does not appear to be a formal part of the
>> hypercall ABI.
>>
>> Keir, can you comment on this?
> 
> I see your point. I may add that it's likely to be more pervasive
> than just relying on ENOENT being 12. Which is a fairly safe bet.
> 
>>
>> 2. It seems more sensible to have the kernel do the retries instead of
>> libxc doing them.  The kernel has to have a mechanism for this any way
>> (for mapping back/front rings).
>>
>> 3. The current way of handling paged-out frames by repeatedly retrying
>> is a bit lame.  Shouldn't there be some event that the guest waiting
>> for the frame can wait on instead?  By moving the retry mechanism into
>> the kernel we can change this without impacting the ABI to userspace.
> 
> Lame is an interesting choice of language :)

My embedded background makes me frown at anything that polls -- it's
generally bad for power consumption.

> I am not a huge fan of libxc retry, but we've been pounding it quite
> hard for a while and it works -- and, importantly, it yields the
> scheduler :)
> 
> While kernel retry may benefit from hypothetical code reuse,
> "Shouldn't there be some event that the guest waiting for the frame can
> wait on instead?" will need to become concrete to start a real discussion.

In kernel retries don't require the event.  Using the event is something
to consider in the longer term.

> For better or worse, since xen-4.1 (!) libxc will do the right thing
> if fed the appropriate errno.

At a minimum I think we need to fix the existing interface to have the
behavior libxc expects.

Is PRIVCMD_MMAPBATCH_V2 actually required?  It doesn't seem to do much
more than the V1 interface.  Perhaps the fix in patches #1 and #2
sufficient to make libxc work?

David