Re: [PATCH v8 05/32] libxc: introduce a domain loader for HVM guest firmware

[Ian Campbell <ian.campbell@citrix.com>]

On Thu, 2015-10-08 at 12:43 +0200, Roger Pau Monné wrote:
> > However I'm unsure that the presence or absence of ELF notes is sufficient,
> > since there is at least the legacy SHT_NOTE section and then __xen_guest
> > section (see the tail of elf_xen_parse) as well.
> 
> AFAICT NetBSD still uses the __xen_guest section, and it works fine with
> this change:
> 
> http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/sys/arch/amd64/amd64/locore.S?rev=1.78&content-type=text/plain&only_with_tag=MAIN
> 
> elfloader recognizes the kernel and it's able to load it without issues.
> 
> xc_dom_parse_elf_kernel already calls elf_xen_parse later on, while
> trying to load the kernel, so the functionality it's exactly the same,
> it's just that we now simply refuse to try to load a kernel without
> elfnotes with elfloader.
> 
> Without this change the elfloader would try to load a kernel without
> elfnotes just to fail later while parsing it.

Great, thanks for confirming.

> > It's a bit of a shame to now have to parse the ELF twice. How abusive would
> > to be to declare that when a xc_dom ->probe hook returns success it is
> > entitled to rely on the contents of dom->loader_private being preserved
> > until ->parse is called. In turn this would imply that the first successful
> > probe would be used rather than e.g. probing everything and then picking a
> > winner from the successful applicants.
> 
> We already do this, we stop testing once a probe returns 0 (see
> xc_dom_find_loader), and use that as the loader, so there's no
> functional change in this aspect. IMHO, this approach is not very
> intrusive, would you like me implement it in a followup patch or rather
> do it in the series?

I think this series is big enough that we need to start draining the
pipeline. So lets address this later.

On the basis that v7 was Reviewed by Andy and Acked by Wei and that I've
looked at the delta (only) from that:

Acked-by: Ian Campbell <ian.campbell@citrix.com>



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