Re: [Xen-devel] Xen 4.1 + Linux compiled with PVH == BOOM

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Tue, Dec 24, 2013 at 01:05:10PM +0000, David Vrabel wrote:
> On 24/12/2013 12:55, Andrew Cooper wrote:
> > On 24/12/2013 12:31, David Vrabel wrote:
> >> On 20/12/2013 17:57, Konrad Rzeszutek Wilk wrote:
> >>> Hey,
> >>>
> >>> This is with Linux and
> >>>
> >>> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git 
> >>> stable/pvh.v11
> >>>
> >>> I get Xen 4.1 (only) hypervisor to blow up with a Linux kernel that has 
> >>> been
> >>> compiled with PVH.
> >>>
> >>> I think the same problem would show up if I tried to launch a PV guest 
> >>> compiled as PVH under Xen 4.1 as well - as the ELF parsing code is shared
> >>> with the toolstack.
> >> If a kernel with both PVH and PV support enabled cannot boot in PV mode
> >> with a non-PVH aware hypervisor/toolstack then the kernel is broken.
> >>
> >> Hypervisor/tool-side fixes aren't the correct fix here.  Xen 4.1 and
> >> even older are still widely deployed.
> >>
> >> David
> > 
> > I believe that the problem is because the elf parsing code is not
> > sufficiently forward-compatible aware, and rejects the PVH kernel
> > because it has an unrecognised Xen elf note field.  This is not a kernel
> > bug.

It (Xen 4.1) has the logic to ignore unrecognized Xen elf note fields. But
it (all Xen versions) do not have the logic to ignore in the 
"SUPPORTED_FEATURES"
an unrecognized string.

> > 
> > The elf parsing should accept unrecognised fields for forward
> > compatibility, which would then allow a PV & PVH compiled kernel to run
> > in PV mode.
> 
> It should but it doesn't, so a different way needs to be found for the
> kernel to report (optional) PVH support.  A method that is compatible
> with older toolstacks.

Also known as changes to the PVH ABI.

Mukesh, Roger, George (emailing Ian instead since he is now the Release 
Manager-pro-temp), Jan,

a).  That means dropping the 'hvm_callback_vector' check from xc_dom_core.c and
just depending on: 
"writable_descriptor_tables|auto_translated_physmap|supervisor_mode_kernel"
for PVH guests.

b) Or dropping that altogether and introducing a new Xen elf note field, say:

XEN_ELFNOTE_PVH_VERSION


Which way should we do this?

P.S.
It looks like that the git tree is not accessible so I cannot update to the
latest git tree to produce an RFC patchset :-(

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