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

Re: [Xen-devel] [PATCH 4/6] xen/pvh: bootup and setup related changes.



On Mon, 22 Oct 2012, Konrad Rzeszutek Wilk wrote:
> On Mon, Oct 22, 2012 at 02:34:44PM +0100, Stefano Stabellini wrote:
> > On Sat, 20 Oct 2012, Konrad Rzeszutek Wilk wrote:
> > > From: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
> > > 
> > > In enlighten.c for PVH we can trap cpuid via vmexit, so don't
> > > need to use emulated prefix call. We also check for vector callback
> > > early on, as it is a required feature. PVH also runs at default kernel
> > > IOPL.
> > > 
> > > In setup.c, in xen_add_extra_mem() we can skip updating P2M as it's 
> > > managed
> > > by Xen. PVH maps the entire IO space, but only RAM pages need to be 
> > > repopulated.
> > > 
> > > Finally, pure PV settings are moved to a separate function that is only 
> > > called
> > > for pure PV, ie, pv with pvmmu.
> > > 
> > > Signed-off-by: Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
> > > Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> > >
> > > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> > > index 8971a26..8cce47b 100644
> > > --- a/arch/x86/xen/setup.c
> > > +++ b/arch/x86/xen/setup.c
> > > @@ -27,6 +27,7 @@
> > >  #include <xen/interface/memory.h>
> > >  #include <xen/interface/physdev.h>
> > >  #include <xen/features.h>
> > > +#include "mmu.h"
> > >  #include "xen-ops.h"
> > >  #include "vdso.h"
> > >  
> > > @@ -78,6 +79,9 @@ static void __init xen_add_extra_mem(u64 start, u64 
> > > size)
> > >  
> > >   memblock_reserve(start, size);
> > >  
> > > + if (xen_feature(XENFEAT_auto_translated_physmap))
> > > +         return;
> > > +
> > >   xen_max_p2m_pfn = PFN_DOWN(start + size);
> > >   for (pfn = PFN_DOWN(start); pfn < xen_max_p2m_pfn; pfn++) {
> > >           unsigned long mfn = pfn_to_mfn(pfn);
> > > @@ -100,6 +104,7 @@ static unsigned long __init xen_do_chunk(unsigned 
> > > long start,
> > >           .domid        = DOMID_SELF
> > >   };
> > >   unsigned long len = 0;
> > > + int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
> > >   unsigned long pfn;
> > >   int ret;
> > >  
> > > @@ -113,7 +118,7 @@ static unsigned long __init xen_do_chunk(unsigned 
> > > long start,
> > >                           continue;
> > >                   frame = mfn;
> > >           } else {
> > > -                 if (mfn != INVALID_P2M_ENTRY)
> > > +                 if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
> > >                           continue;
> > >                   frame = pfn;
> > >           }
> > 
> > Shouldn't we add a "!xlated_phys &&" to the other case as well?
> 
> No. That is handled in xen_pvh_identity_map_chunk which
> just does a xen_set_clr_mmio_pvh_pte call for the "released"
> pages. But that is a bit of ... well, extra logic. I think
> if we did this it would work and look much nicer:

Yes, I think that this version looks better

> 
> diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> index 8cce47b..b451a77 100644
> --- a/arch/x86/xen/setup.c
> +++ b/arch/x86/xen/setup.c
> @@ -114,9 +114,15 @@ static unsigned long __init xen_do_chunk(unsigned long 
> start,
>  
>               if (release) {
>                       /* Make sure pfn exists to start with */
> -                     if (mfn == INVALID_P2M_ENTRY || mfn_to_pfn(mfn) != pfn)
> +                     if (mfn == INVALID_P2M_ENTRY || (!xlated_phys && 
> (mfn_to_pfn(mfn) != pfn)))
>                               continue;
>                       frame = mfn;
> +                     /* The hypercall PHYSDEVOP_map_iomem to release memory 
> has already
> +                      * happend, so we just do a nop here. */
> +                     if (xlated_phys) {
> +                             len++;
> +                             continue;
> +                     }
>               } else {
>                       if (!xlated_phys && mfn != INVALID_P2M_ENTRY)
>                               continue;
> @@ -219,15 +225,24 @@ static void __init xen_set_identity_and_release_chunk(
>  {
>       unsigned long pfn;
>  
> +     /* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The 
> mfns
> +      * are released as part of this 1:1 mapping hypercall back to the dom 
> heap.
> +      * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
> +      */
> +     int xlated_phys = xen_feature(XENFEAT_auto_translated_physmap);
> +
>       /*
>        * If the PFNs are currently mapped, the VA mapping also needs
>        * to be updated to be 1:1.
>        */
> -     for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++)
> -             (void)HYPERVISOR_update_va_mapping(
> -                     (unsigned long)__va(pfn << PAGE_SHIFT),
> -                     mfn_pte(pfn, PAGE_KERNEL_IO), 0);
> -
> +     for (pfn = start_pfn; pfn <= max_pfn_mapped && pfn < end_pfn; pfn++) {
> +             if (xlated_phys)
> +                     xen_set_clr_mmio_pvh_pte(pfn, pfn, 1 /* one pfn */, 1 
> /* add mapping */);
> +             else
> +                     (void)HYPERVISOR_update_va_mapping(
> +                             (unsigned long)__va(pfn << PAGE_SHIFT),
> +                             mfn_pte(pfn, PAGE_KERNEL_IO), 0);
> +     }
>       if (start_pfn < nr_pages)
>               *released += xen_release_chunk(
>                       start_pfn, min(end_pfn, nr_pages));
> @@ -235,27 +250,6 @@ static void __init xen_set_identity_and_release_chunk(
>       *identity += set_phys_range_identity(start_pfn, end_pfn);
>  }
>  
> -/* For PVH, the pfns [0..MAX] are mapped to mfn's in the EPT/NPT. The mfns
> - * are released as part of this 1:1 mapping hypercall back to the dom heap.
> - * Also, we map the entire IO space, ie, beyond max_pfn_mapped.
> - */
> -static void __init xen_pvh_identity_map_chunk(unsigned long start_pfn,
> -             unsigned long end_pfn, unsigned long *released,
> -             unsigned long *identity, unsigned long max_pfn)
> -{
> -     unsigned long pfn;
> -     int numpfns = 1, add_mapping = 1;
> -
> -     for (pfn = start_pfn; pfn < end_pfn; pfn++)
> -             xen_set_clr_mmio_pvh_pte(pfn, pfn, numpfns, add_mapping);
> -
> -     if (start_pfn <= max_pfn) {
> -             unsigned long end = min(max_pfn_mapped, end_pfn);
> -             *released += end - start_pfn;
> -     }
> -     *identity += end_pfn - start_pfn;
> -}
> -
>  static unsigned long __init xen_set_identity_and_release(
>       const struct e820entry *list, size_t map_size, unsigned long nr_pages)
>  {
> @@ -286,17 +280,10 @@ static unsigned long __init 
> xen_set_identity_and_release(
>                       if (entry->type == E820_RAM)
>                               end_pfn = PFN_UP(entry->addr);
>  
> -                     if (start_pfn < end_pfn) {
> -                             if (xlated_phys) {
> -                                     xen_pvh_identity_map_chunk(start_pfn,
> -                                             end_pfn, &released, &identity,
> -                                             nr_pages);
> -                             } else {
> -                                     xen_set_identity_and_release_chunk(
> +                     if (start_pfn < end_pfn)
> +                             xen_set_identity_and_release_chunk(
>                                               start_pfn, end_pfn, nr_pages,
>                                               &released, &identity);
> -                             }
> -                     }
>                       start = end;
>               }
>       }
> 

_______________________________________________
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®.