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

[Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>]

On Tue, 14 May 2013 07:56:47 +0100
"Jan Beulich" <JBeulich@xxxxxxxx> wrote:

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

Ah, got it. I can just check for opt_dom0pvh in elf_load_image().

Mukesh

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