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] support 1gb pages in guest page table walker

To: Christoph Egger <Christoph.Egger@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH] support 1gb pages in guest page table walker
From: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Date: Mon, 25 Jul 2011 11:25:46 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>
Delivery-date: Mon, 25 Jul 2011 03:26:16 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4E2D3B81.9000908@xxxxxxx>
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: <4E298E8F.1040306@xxxxxxx> <4E29B6A7020000780004F3B6@xxxxxxxxxxxxxxxxxxxx> <4E2D3538.1060106@xxxxxxx> <4E2D53F9020000780004F67E@xxxxxxxxxxxxxxxxxxxx> <4E2D3B81.9000908@xxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.21 (2010-09-15)
Hi, 

Thanks for this.  Do you have a matching patch that enables 1GB mappings
in the appropriate guests?

At 11:46 +0200 on 25 Jul (1311594401), Christoph Egger wrote:
> +#if GUEST_PAGING_LEVELS >= 4 /* 64-bit only... */
> +    pse1G = (guest_supports_1G_superpages(v) && 
> +           (guest_l3e_get_flags(gw->l3e) & _PAGE_PSE)); 
> +
> +    if ( pse1G )
> +    {
> +        /* Special case: this guest VA is in a PSE superpage, so there's
> +         * no guest l1e.  We make one up so that the propagation code
> +         * can generate a shadow l1 table.  Start with the gfn of the 
> +         * first 4k-page of the superpage. */

Shadow pagetables don't support 1GB mappings, so this comment needs to
be updated to say why you're making the fake l1e (basically as a vehicle
for the GFN of the target frame).

> +        gfn_t start = guest_l2e_get_gfn(gw->l2e);
> +        /* Grant full access in the l1e, since all the guest entry's 
> +         * access controls are enforced in the shadow l2e. */
> +        int flags = (_PAGE_PRESENT|_PAGE_USER|_PAGE_RW|
> +                     _PAGE_ACCESSED|_PAGE_DIRTY);
> +        /* Import cache-control bits. Note that _PAGE_PAT is actually
> +         * _PAGE_PSE, and it is always set. We will clear it in case
> +         * _PAGE_PSE_PAT (bit 12, i.e. first bit of gfn) is clear. */
> +        flags |= (guest_l2e_get_flags(gw->l2e)
> +                  & (_PAGE_PAT|_PAGE_PWT|_PAGE_PCD));

You should be taking these from the l3e, not the l2e.  Also, you should
probably do it before the code that maps the l2 table. :)

> diff -r 4f2c59fb28e6 xen/include/asm-x86/guest_pt.h
> --- a/xen/include/asm-x86/guest_pt.h  Mon Jul 18 11:43:45 2011 +0200
> +++ b/xen/include/asm-x86/guest_pt.h  Mon Jul 25 11:43:36 2011 +0200
> @@ -194,6 +194,17 @@ guest_supports_superpages(struct vcpu *v
>  }
>  
>  static inline int
> +guest_supports_1G_superpages(struct vcpu *v)
> +{
> +    if (!guest_supports_superpages(v))
> +        return 0;
> +
> +    return (GUEST_PAGING_LEVELS >= 4
> +           && cpu_has_page1gb
> +           && hvm_long_mode_enabled(v));

There needs to be some interlock to make sure this returns false for
all guests except HVM HAP ones.  

Also this function should be called from the CPUID trap handler to make
sure we never advertise PSE1GB when we're not going to support it.  
(I think that involves moving it out of this header file -- it should
probably go into hvm.h and be renamed to match the hvm_*_enabled macros
already there.)

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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