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

Re: [Xen-devel] [PATCH 0 of 3] RFC Paging support for AMD NPT V2



>
>
>> -----Original Message-----
>> From: Andres Lagar-Cavilla [mailto:andres@xxxxxxxxxxxxxxxx]
>> Sent: Friday, March 02, 2012 12:34 AM
>> To: Hongkaixing
>> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; tim@xxxxxxx; andres@xxxxxxxxxxxxxx;
>> olaf@xxxxxxxxx; adin@xxxxxxxxxxxxxx; wei.wang2@xxxxxxx;
>> yanqiangjun@xxxxxxxxxx
>> Subject: RE: [PATCH 0 of 3] RFC Paging support for AMD NPT V2
>>
>> >
>> >
>> >> -----Original Message-----
>> >> From: Andres Lagar-Cavilla [mailto:andres@xxxxxxxxxxxxxxxx]
>> >> Sent: Thursday, March 01, 2012 11:16 AM
>> >> To: xen-devel@xxxxxxxxxxxxxxxxxxx
>> >> Cc: tim@xxxxxxx; andres@xxxxxxxxxxxxxx; olaf@xxxxxxxxx;
>> >> adin@xxxxxxxxxxxxxx; wei.wang2@xxxxxxx; hongkaixing@xxxxxxxxxx
>> >> Subject: [PATCH 0 of 3] RFC Paging support for AMD NPT V2
>> >>
>> >> There has been some progress, but still no joy. Definitely not
>> intended
>> >> for
>> >> inclusion at this point.
>> >>
>> >> Tim, Wei, I added a Xen command line toggle to disable IOMMU and P2M
>> >> table
>> >> sharing.
>> >>
>> >> Tim, I verified that changes to p2m-pt.c don't break shadow mode
>> (64bit
>> >> hypervisor and Win 7 guest).
>> >>
>> >> Hongkaixing, I incorporated your suggestion in patch 2, so I should
>> add
>> >> your
>> >> Signed-off-by eventually. Please review.
>> >
>> >   I have checked the code, it looks like OK. But I don't have AMD
>> machine
>> > to run it.
>> >   We used almost the same code in a AMD server months before, and it
>> > worked fine.
>> >   The only difference is we have not changed the clipped invalid mfn
>> to
>> > INVALID_MFN, just like EPT.
>>
>> That is most interesting. Can you elaborate? do you have functional
>> paging
>> on AMD since "months before"? If you do, can you please post it to
>> xen-devel for inclusion?
>>
>> Thanks a lot,
>> Andres
>
> All what we have done is shown below.
> The code is based on xen 4.0.2, it looks informal, but it works fine when
> xenpaging target is set at arbitrary number..
> Now we do not have AMD platform to validate, so I am not sure it can work
> under unstable code.

Thanks. That's actually great. The code is roughly the same, and it shows
we're on a good lead.

Cheers!
Andres
>
> Index: E:/xen-4.0.2/xen/arch/x86/mm/p2m.c
> ===================================================================
> --- E:/xen-4.0.2/xen/arch/x86/mm/p2m.c        (revision 30771)
> +++ E:/xen-4.0.2/xen/arch/x86/mm/p2m.c        (revision 30772)
> @@ -77,6 +77,13 @@
>  #define SUPERPAGE_PAGES (1UL << 9)
>  #define superpage_aligned(_x)  (((_x)&(SUPERPAGE_PAGES-1))==0)
>
> +#ifdef __x86_64__
> +/* there are only 40bits for pfn in PTE */
> +#define MASK_MFN(x)  ( x & ((1UL << 40) -1 ))
> +#else
> +#define MASK_MFN(x)  ( x )
> +#endif
> +
>  static unsigned long p2m_type_to_flags(p2m_type_t t)
>  {
>      unsigned long flags;
> @@ -1306,6 +1313,8 @@
>
>          if ( mfn_valid(mfn) || (p2mt == p2m_mmio_direct) )
>              entry_content = l1e_from_pfn(mfn_x(mfn),
> p2m_type_to_flags(p2mt));
> +        else if ( p2m_is_paging( p2mt ) )
> +            entry_content = l1e_from_pfn( MASK_MFN(mfn_x(mfn)),
> p2m_type_to_flags(p2mt));
>          else
>              entry_content = l1e_empty();
>
> @@ -1370,6 +1379,7 @@
>      paddr_t addr = ((paddr_t)gfn) << PAGE_SHIFT;
>      l2_pgentry_t *l2e;
>      l1_pgentry_t *l1e;
> +    unsigned long flags;
>
>      ASSERT(paging_mode_translate(d));
>
> @@ -1455,7 +1465,8 @@
>      l1e = map_domain_page(mfn_x(mfn));
>      l1e += l1_table_offset(addr);
>  pod_retry_l1:
> -    if ( (l1e_get_flags(*l1e) & _PAGE_PRESENT) == 0 )
> +    flags = l1e_get_flags(*l1e);
> +    if ((( flags & _PAGE_PRESENT) == 0) &&
> (!p2m_is_paging(p2m_flags_to_type(flags))))
>      {
>          /* PoD: Try to populate */
>          if ( p2m_flags_to_type(l1e_get_flags(*l1e)) ==
> p2m_populate_on_demand )
> Index: E: /xen-4.0.2/xen/arch/x86/mm/mem_event.c
> ===================================================================
> --- E:/xen-4.0.2/xen/arch/x86/mm/mem_event.c  (revision 30771)
> +++ E:/xen-4.0.2/xen/arch/x86/mm/mem_event.c  (revision 30772)
> @@ -231,10 +231,9 @@
>              if ( d->mem_event.ring_page )
>                  break;
>
> -            /* Currently only EPT is supported */
> +            /* Both AMD NPT and intel EPT are supported */
>              rc = -ENODEV;
> -            if ( !(is_hvm_domain(d) && d->arch.hvm_domain.hap_enabled &&
> -                  (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL)) )
> +            if ( !(is_hvm_domain(d) && d->arch.hvm_domain.hap_enabled ))
>                  break;
>
>              /* Get MFN of ring page */
>>
>> >
>> >
>> >>
>> >> Olaf, I do not see errors when mapping pages prior to eviction. Let
>> me
>> >> know how
>> >> it goes for you.
>> >>
>> >> If I unleash xenpaging on a domain for a non-ambitious target (64
>> MiBs
>> >> paged
>> >> out for one minute), we sail by just fine. But if I kick things up a
>> >> notch,
>> >> still dying on an VMEXIT_SHUTDOWN (a.k.a. triple fault). Not sure at
>> all
>> >> what
>> >> to do next.
>> >>
>> >> Signed-off-by: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>
>> >> Signed-off-by: Adin Scannell <adin@xxxxxxxxxxx>
>> >>
>> >>  xen/drivers/passthrough/iommu.c |   2 +
>> >>  xen/arch/x86/mm/p2m-pt.c        |  56
>> >> ++++++++++++++++++++++++++++------------
>> >>  xen/arch/x86/mm/mem_event.c     |   7 +++-
>> >>  xen/arch/x86/mm/mem_sharing.c   |   7 +++++
>> >>  4 files changed, 53 insertions(+), 19 deletions(-)
>> >
>> >
>
>
>



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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