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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 14.05.13 at 03:16, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> On Wed, 24 Apr 2013 10:15:25 +0100
> "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
> 
>> >>> On 23.04.13 at 23:26, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
>> >>> wrote:
>> >  
>> > -static int elf_load_image(void *dst, const void *src, uint64_t
>> > filesz, uint64_t memsz) +extern void __init
>> > early_pvh_copy_or_zero(unsigned long dest, char *src,
>> > +                                          int len, unsigned long
>> > v_start);
>> 
>> This needs to be put in a header included both here and at the
>> producer side.
>> 
>> Also, if you need to pass v_start around just to pass it back to
>> this function, you could as well store it in a static variable in
>> domain_build.c, and leave all of these functions untouched.
> 
> Actually, elf_load_image() <-- elf_load_binary() needs to know if it's 
> PVH domain, so I'd need to change it to pass is_pvh_domain anyways. 

But the single place where it's being looked at for purposes other
than forwarding to the next function is a pretty odd hack anyway.

> I could check for idle_domain in elf_load_binary() and assume PVH dom0
> construct, since for other callers, current should never be idle domain,
> but, that seems pretty hacky... 

Using v_start being (non-)zero as a flag to tell pv from pvh isn't
much less of a hack.

> So, I could either leave it as is with v_start being passed, or make
> v_start static and pass is_pvh_domain flag. Please LMK.

In the end I wonder whether for all this special casing a cleaner
implementation can't be found.

Jan


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