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

["Jan Beulich" <JBeulich@suse.com>]

>>> On 16.05.13 at 03:58, Mukesh Rathor <mukesh.rathor@oracle.com> wrote:
> On Wed, 15 May 2013 13:12:56 +0100
> "Jan Beulich" <JBeulich@suse.com> wrote:
> 
>> >>> On 15.05.13 at 02:52, Mukesh Rathor <mukesh.rathor@oracle.com>
>> >>> 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);

The symbol is global, so use sites don't matter. And I continue to
think that logically it belongs into domain_build.c.

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

There's nothing to prototype - just use the code that's there for
PV Dom0.

Jan