Re: [Xen-devel] [PATCH 19/20] PVH xen: elf and iommu related changes to prep for dom0 PVH

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.05.13 at 02:52, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> --- a/xen/arch/x86/setup.c
> +++ b/xen/arch/x86/setup.c
> @@ -60,6 +60,10 @@ integer_param("maxcpus", max_cpus);
>  static bool_t __initdata disable_smep;
>  invbool_param("smep", disable_smep);
>  
> +/* Boot dom0 in PVH mode */
> +bool_t __initdata opt_dom0pvh;
> +boolean_param("dom0pvh", opt_dom0pvh);

Does this really belong here (instead of domain_build.c)?

> --- a/xen/common/libelf/libelf-loader.c
> +++ b/xen/common/libelf/libelf-loader.c
> @@ -127,6 +131,16 @@ static int elf_load_image(void *dst, const void *src, 
> uint64_t filesz, uint64_t
>      int rc;
>      if ( filesz > ULONG_MAX || memsz > ULONG_MAX )
>          return -1;
> +
> +    if ( opt_dom0pvh )

So you define (above) and declare (below) the variable in x86-
specific files, but use it in common code? That's going to break the
ARM build.

> +    {
> +        unsigned long addr = (unsigned long)dst;
> +        early_pvh_copy_or_zero(addr, src, filesz);
> +        early_pvh_copy_or_zero(addr + filesz, NULL, memsz - filesz);

And anyway - repeating my earlier complaint - I don't see why this
is necessary. In fact I don't see why most of the PV Dom0 building
code can't be used unchanged for PVH: There's no real need for
lifting the few restrictions that apply, and hence there needn't be
any fear of colliding address spaces.

> @@ -146,7 +158,15 @@ void __init iommu_dom0_init(struct domain *d)
>                   ((page->u.inuse.type_info & PGT_type_mask)
>                    == PGT_writable_page) )
>                  mapping |= IOMMUF_writable;
> -            hd->platform_ops->map_page(d, mfn, mfn, mapping);
> +
> +            if ( is_pvh_domain(d) )
> +            {
> +                unsigned long gfn = mfn_to_gfn(d, _mfn(mfn));
> +                hd->platform_ops->map_page(d, gfn, mfn, mapping);
> +            }
> +            else
> +                hd->platform_ops->map_page(d, mfn, mfn, mapping);

With mfn_to_gfn(mfn) == mfn, is there really a need for two code
paths here?

Jan


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