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] [PATCH 1/1] Xen PV support for hugepages

To: "Jan Beulich" <jbeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 1/1] Xen PV support for hugepages
From: Dave McCracken <dcm@xxxxxxxx>
Date: Thu, 6 Nov 2008 07:44:56 -0600
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Delivery-date: Thu, 06 Nov 2008 05:45:19 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4911C63E.76E4.0078.0@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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20081104154149.21144.75675.sendpatchset@xxxxxxxxxxxxxxxxxxx> <C5372D1F.28B44%keir.fraser@xxxxxxxxxxxxx> <4911C63E.76E4.0078.0@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.9.9
On Wednesday 05 November 2008, Jan Beulich wrote:
> The return value handling seems correct, but the call to map_pages_to_xen()
> at the end of get_page_from_l2e() doesn't: Simply or-ing the guest-provided
> flags into PAGE_HYPERVISOR definitely isn't correct. The cache attributes
> must be extracted, converted to L1 notion, and then be or-ed in.

Oops.  I thought I'd fixed that.  Apparently I looked at it and got 
sidetracked.  I'll fix.

> Also, the special code to deal with LDT pages in put_page_from_l1e() should
> now also be required in put_page_from_l2e(). Perhaps that logic could be
> moved into put_data_page()?

It looks to me like this is only done for PGT_seg_desc_page.  I don't think 
any hugepage can be of this type.  I can add it to put_data_page() if you 
think we need to be sure.

> Further, with L2_DISALLOW_MASK now permitting _PAGE_PSE, the use
> site in mod_l2_entry() must certainly also be modified, i.e. the subsequent
> l2e_has_changed() would need to include _PAGE_PSE, and the case of
> _PAGE_RW toggling when _PAGE_PSE was and will be set needs to be
> taken care of.
>
> Next, adjust_guest_l2e() would apparently also need to be modified.

I'll look more closely into those.

> Finally, no longer hiding X86_FEATURE_PSE from the guest seems rather
> risky: I'm pretty sure the pv-ops kernel relies on this flag being clear -
> when set, it would blindly (i.e. without ensuring the underlying memory is
> contiguous and suitably aligned) try to use 2Mb mappings for e.g. the 1:1
> mapping. I would think this capability ought to be propagated by another
> means. Likewise I'm uncertain about letting X86_CR4_PSE shine through.
>
> And a general question: How is a trivial DomU going to be able to make
> use of this, without being permitted to allocate non-order-zero chunks of
> memory?

This is the point of having hugepages a command line option.  It should only 
be turned on if you intend to run guests who enforce the alignment rules.  
I'm working on ways to get guests to run in aligned memory.

Dave McCracken
Oracle Corp.

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