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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 18.05.13 at 04:01, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> On Thu, 16 May 2013 09:03:16 +0100
> "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>> >>> On 16.05.13 at 03:58, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
>> >>> wrote:
>> > On Wed, 15 May 2013 13:12:56 +0100
>> > "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>> > 
>> >> > +    {
>> >> > +        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.
> 
> Not sure if you are referring to just changes in elf_load_image():
> 
> +    if ( opt_dom0pvh )
> +    {
> +        unsigned long addr = (unsigned long)dst;
> +        early_pvh_copy_or_zero(addr, src, filesz);
> +        early_pvh_copy_or_zero(addr + filesz, NULL, memsz - filesz);
> +
> +        return 0;
> +    }
> +
>      rc = raw_copy_to_guest(dst, src, filesz);
> 
> or all changes including construct_dom0() also?

The part above is particularly ugly, but indeed I think you can only
get all or nothing here.

> As the comment says, for elf_load_image() we need early_pvh_copy_or_zero
> because it's too early in boot and construct_dom0() is running on idle
> vcpu where curr points to.
> 
> If that doesn't address your concern, please elaborate.

The fact that we're running on the idle vCPU here isn't any different
for PV Dom0. As much as PV Dom0 setup temporarily switches to
Dom0's page tables, I would imagine PVH Dom0 setup could do so
too, provided you don't lift the address space restrictions (which in
theory you could do, but in practice I don't see any need for). That
should allow having the PVH changes to Dom0 setup be a single code
fragment (adjusting Dom0 page tables from using machine addresses
to physical ones _after_ all other setup was done).

Jan


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