WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Re: Next steps with pv_ops for Xen

To: Gerd Hoffmann <kraxel@xxxxxxxxxx>
Subject: Re: [Xen-devel] Re: Next steps with pv_ops for Xen
From: Derek Murray <Derek.Murray@xxxxxxxxxxxx>
Date: Wed, 05 Dec 2007 11:48:36 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Eduardo Habkost <ehabkost@xxxxxxxxxx>, Juan Quintela <quintela@xxxxxxxxxx>, "Stephen C. Tweedie" <sct@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxxxx>, Glauber de Oliveira Costa <gcosta@xxxxxxxxxx>, Chris Wright <chrisw@xxxxxxxxxxxx>, "virtualization@xxxxxxxxxxxxxx" <virtualization@xxxxxxxxxxxxxx>
Delivery-date: Wed, 05 Dec 2007 03:49:17 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <4755B158.3030008@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <1195682725.6726.48.camel@xxxxxxxxxxxxxxxxxxxxx> <4753FC6A.4020601@xxxxxxxxxx> <4754024C.7020905@xxxxxxxxxxxx> <47540FB8.8000106@xxxxxxxxxx> <475417E7.9070006@xxxxxxxxxxxx> <47546931.2090602@xxxxxxxxxx> <475520A1.6080909@xxxxxxxxxxxx> <475541A8.7030100@xxxxxxxxxx> <1196771999.10809.18.camel@xxxxxxxxxxxxxxxxxxxxx> <4755B158.3030008@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 2.0.0.9 (X11/20071115)
Hi Gerd,

Gerd Hoffmann wrote:
Want reproduce?  Here we go:

  * grab xenner 0.8 from http://dl.bytesex.org/releases/xenner/
  * grab a xenified dom0 kernel without blktap driver (either not
    compiled or module not loaded).
  * start xend
  * start blkbackd from xenner package (you probably want the -d switch
    for debug output, twice for more).
  * run "xm block-attach 0 tap:aio:/path/to/some/file xvda r"
  * watch it blow up ;)

Thanks for the repro details. I'll have a go at this later. One thing we haven't tested AFAIK is mapping grants in the same domain: could you check to see if the bug is the same if you attach a block device to a domain other than Dom0? Also, could you send any Xen console output, if it contains errors or warnings?

I can't help wondering if this is a hint that now is the time to find a
better API, which doesn't have the requirement (a) that seems to be
causing such trouble?  Are other PV guests --- *BSD, Solaris --- going
to have the same problems with their VM layers if they try to implement
this API?  Upstream Linux pv_ops certainly will, and it would be good if
we could avoid tying unprivileged guests to ABIs which cannot hope to be
merged into pv_ops.

And I fear the problems I've trapped into up to now is only the tip of
the iceberg.  What happens if an application with active grant table
mappings calls fork() ?

Ultimately, fork calls dup_mm, which calls, dup_mmap, which calls copy_{page,pud,pmd,pte}_range, which calls copy_one_pte, which calls set_pte_at, which hypercalls HYPERVISOR_update_va_mapping.

The hypercall will not succeed and will return an error code indicating the reason for this. Therefore the PTE will not be set. There appears to be no way to propagate this error through the Linux VM code, because there is no concept of a PTE update failing. I could add return codes to all those functions, but I don't fancy their chances upstream....

A possibility for solving that might be to carry out the mappings upon a page fault: I believe this would be compatible with copy_page_range.

(In fact, it's possible that a forked process would attempt to demand-page in the granted page, bypassing the copy_page_range code. Since there is no nopage handler for a gntdev VMA, that would lead to an anonymous page being mapped into memory instead.)

So, as far as I can tell, there would be no kernel BUG() or domain_crash() in the event of a fork(). It looks like implementing nopage in gntdev would enable grants to be remapped after a fork() and the correct behaviour to happen.

Regards,

Derek.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>