All of lore.kernel.org
 help / color / mirror / Atom feed
From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xensource.com
Subject: how to handle paged hypercall args?
Date: Wed, 10 Nov 2010 09:58:17 +0100	[thread overview]
Message-ID: <20101110085817.GB4427@aepfle.de> (raw)


Hello,

I'm running into the BUG_ON() after an incomplete XENMEM_decrease_reservation
HYPERVISOR_memory_op call in balloon.c:decrease_reservation().

The reason for that is the huge number of nr_extents, were many of them
are paged out pages. Because the are paged out, they can just be dropped
from the xenpaging point of view, no need to page them in before calling
p2m_remove_page() for the paged-out gfn. Whatever strategy is chosen,
the hypercall will be preempted.

Because the hypercall is preempted, the arg is copied several times from
the guest to the stack with copy_from_guest(). Now there is appearently
nothing that stops the xenpaging binary in dom0 from making progress and
eventually nominating the gfn which holds the guests kernel stack page.
This lets __hvm_copy() return HVMCOPY_gfn_paged_out, which means
copy_from_user_hvm() "fails", and this lets the whole hypercall fail.

Now in my particular case, its the first copy_from_user_hvm() and I can
probably come up with a simple patch which let copy_from_user_hvm()
return some sort of -EAGAIN. This could be used in do_memory_op() to
just restart the hypercall once more until the gfn which holds args is
available again. Then my decrease_reservation() bug would have a
workaround and I could move on.

However, I think there is nothing that would prevent the xenpaging
binary from nominating the guest gfn while the actual work is done
during the hypercall and then copy_to_user_hvm would fail.
How should other hypercalls deal with the situation that the guest gfn
gets into the paged-out state? Can they just sleep and do some sort of
polling until the page is accessible again? Was this case considered
while implementing xenpaging?

I'm currently reading through the callers of __hvm_copy(). Some of them
detect HVMCOPY_gfn_paged_out and so some sort of retry. Others just
ignore the return codes, or turn them into generic errors. In the case
of copy_from/to_guest each caller needs an audit if a retry is possible.


Olaf

             reply	other threads:[~2010-11-10  8:58 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-10  8:58 Olaf Hering [this message]
2010-11-11 14:33 ` how to handle paged hypercall args? Olaf Hering
2010-11-11 20:08   ` Keir Fraser
2010-11-11 20:34     ` Olaf Hering
2010-11-11 21:00       ` Keir Fraser
2010-11-12  9:45     ` Jan Beulich
2010-11-12 10:22       ` Keir Fraser
2010-11-12 10:47         ` Jan Beulich
2010-11-12 14:32           ` Keir Fraser
2010-11-15 13:12             ` Olaf Hering
2010-11-17 16:52               ` Keir Fraser
2010-11-18 12:33                 ` Keir Fraser
2010-11-18 13:51                   ` Olaf Hering
2010-12-02 10:11                   ` Olaf Hering
2010-12-02 10:22                     ` Keir Fraser
2010-12-02 10:30                       ` Keir Fraser
2010-12-03  9:14                         ` Olaf Hering
2010-12-03 14:37                           ` Keir Fraser
2010-12-02 10:25                     ` Jan Beulich
2010-12-03  9:06                       ` Olaf Hering
2010-12-03 14:18                         ` Keir Fraser
2010-12-02 10:18                   ` Olaf Hering
2010-12-02 10:25                     ` Keir Fraser
2010-12-07  9:25                       ` Olaf Hering
2010-12-07 16:45                         ` Keir Fraser
2010-12-07 17:16                           ` Olaf Hering
2010-12-07 18:08                             ` Keir Fraser
2010-12-07 18:50                               ` Olaf Hering
2010-11-15  9:37       ` Tim Deegan
2010-11-15  9:53         ` Jan Beulich
2010-11-15 10:09           ` Keir Fraser
2010-11-15 10:20             ` Tim Deegan
2010-11-15 10:33               ` Keir Fraser
2010-11-15 10:49                 ` Tim Deegan
2010-11-15 11:55                   ` Keir Fraser
2010-11-15 12:04                     ` Tim Deegan
2010-11-15 12:17                       ` Keir Fraser
2010-12-03  9:03                         ` Olaf Hering
2010-12-03 14:13                           ` Keir Fraser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101110085817.GB4427@aepfle.de \
    --to=olaf@aepfle.de \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.