From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Vrabel Subject: Re: [RFC PATCH 0/3] xen/privcmd: support for paged-out frames Date: Fri, 24 Aug 2012 12:58:15 +0100 Message-ID: <50376C57.2050008@citrix.com> References: <1345742026-10569-1-git-send-email-david.vrabel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andres Lagar-Cavilla Cc: Olaf Hering , "xen-devel@lists.xensource.com" , "Keir (Xen.org)" , Konrad Rzeszutek Wilk List-Id: xen-devel@lists.xenproject.org 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