[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen with dom0 pvops on ultra-recent "git tip"kernel on x86_64


  • To: Christophe Saout <christophe@xxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
  • From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Date: Sun, 18 Jan 2009 22:39:19 +0000
  • Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Sun, 18 Jan 2009 14:39:46 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Acl5vZmgslNEE/6Ll0qAKghvxJQ/7A==
  • Thread-topic: [Xen-devel] Xen with dom0 pvops on ultra-recent "git tip"kernel on x86_64

On 18/01/2009 21:28, "Christophe Saout" <christophe@xxxxxxxx> wrote:

> However, in direct_remap_pfn_range() the first two lines are:
> 
>        if (xen_feature(XENFEAT_auto_translated_physmap))
>                return remap_pfn_range(vma, address, mfn, size, prot);
> 
> I guess this is not the case on my system / hypervisor?

You can ignore auto_translated_physmap. It's not a supported mode any more.

> There is some logic in the native Xen kernel which prevents a call to
> mm_unpin if there are "foreign mappings", i.e. set by
> direct_remap_pfn_range.  What's up with that?

It's subtle. Whether it is needed depends on whether the pv_ops kernel
detects mappings of non-reference-counted memory by putting a flag in the
relevant PTEs, or by the more subtle means used in our 2.6.18 kernel (see
include/asm-i386/mach-xen/asm/maddr.h:mfn_to_local_pfn() and the comment
above it). In the former case the flag would not be needed, and I think that
is what Jeremy implemented.

The flag would possibly still be needed for grant mappings in user space
though (i.e., mappings made via the gntdev device driver, or by the blktap
device driver).

 -- Keir



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.