All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Vrabel <david.vrabel@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Konrad
Subject: Re: [PATCH 0/4] xen: map foreign pages for shared rings by updating the PTEs directly
Date: Thu, 29 Sep 2011 17:45:52 +0100	[thread overview]
Message-ID: <4E84A0C0.6000804@citrix.com> (raw)
In-Reply-To: <4E84B3FE02000078000588A9@nat28.tlf.novell.com>

On 29/09/11 17:07, Jan Beulich wrote:
>>>> On 29.09.11 at 17:53, David Vrabel <david.vrabel@citrix.com> wrote:
>> [Resend as requested by Konrad.]
>>
>> This series of patches allows the vmalloc_sync_all() to be removed
>> from alloc_vm_area() by getting the hypervisor to update the PTEs (in
>> init_mm) directly rather than having the hypervisor look in the
>> current page tables to find the PTEs.
>>
>> Once the hypervisor has updated the PTEs, the normal mechanism of
>> syncing the page tables after a fault works as expected.
> 
> Did you actually test that, and namely the case where alloc_vm_area()
> would result in a new top level page directory entry to get populated?
>
> I cannot see how this new entry would propagate into other mm-s, and
> hence I cannot see how you can do away with calling vmalloc_sync_all()
> just by changing how leaf page table entries get populated.

I don't think this new behaviour of alloc_vm_area() is any different
from how a regular vmalloc() works.

vmalloc_fault() copies the page table entries from init_mm into the
current MM (on 32-bit it calls vmalloc_sync_one() which makes it
obviously correct I think).

David

>> This mechanism doesn't currently work on the ia64 port as that does
>> not support the GNTMAP_contains_pte flag.
>>
>> David

  reply	other threads:[~2011-09-29 16:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-29 15:53 [PATCH 0/4] xen: map foreign pages for shared rings by updating the PTEs directly David Vrabel
2011-09-29 15:53 ` [PATCH 1/4] xen: use generic functions instead of xen_{alloc, free}_vm_area() David Vrabel
2011-09-29 15:53 ` [PATCH 2/4] block: xen-blkback: use API provided by xenbus module to map rings David Vrabel
2011-09-29 15:53 ` [PATCH 3/4] net: xen-netback: " David Vrabel
2011-09-29 15:53 ` [PATCH 4/4] xen: map foreign pages for shared rings by updating the PTEs directly David Vrabel
2011-09-29 16:07 ` [PATCH 0/4] " Jan Beulich
2011-09-29 16:45   ` David Vrabel [this message]
2011-09-30  8:08     ` Jan Beulich
2011-09-30 10:14       ` David Vrabel
2011-09-30 10:50         ` Jan Beulich
2011-09-30 11:04           ` Ian Campbell
2011-09-30 10:18       ` Ian Campbell
  -- strict thread matches above, loose matches on Subject: below --
2011-10-20 10:45 David Vrabel
2011-10-20 23:44 ` Konrad Rzeszutek Wilk

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=4E84A0C0.6000804@citrix.com \
    --to=david.vrabel@citrix.com \
    --cc=JBeulich@suse.com \
    --cc=konrad.wilk@oracle.com \
    --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.