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

[Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>]

On Wed, 15 May 2013 13:12:56 +0100
"Jan Beulich" <JBeulich@xxxxxxxx> wrote:

> >>> 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)?

Yes, so we can pass the flag to domain_create() which sets the guest type:

    domcr_flags = (opt_dom0pvh ? DOMCRF_pvh | DOMCRF_hap : 0);
    domcr_flags |= DOMCRF_s3_integrity;
    dom0 = domain_create(0, domcr_flags, 0);

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

Shoot, forgot about ARM. thanks.

> > +    {
> > +        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.

Hmm... thats the best way I could come up with. If you want to prototype
something and replace what I've got, it's perfectly ok by me.


thanks
Mukesh

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