Re: Xen 4.1 + Linux compiled with PVH == BOOM

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Mon, Dec 23, 2013 at 11:49:49AM +0000, Jan Beulich wrote:
> >>> "Jan Beulich" <jbeulich@suse.com> 12/23/13 10:39 AM >>>
> >>>> Ian Campbell <Ian.Campbell@citrix.com> 12/21/13 12:10 PM >>>
> >>On Fri, 2013-12-20 at 12:57 -0500, Konrad Rzeszutek Wilk wrote:
> >>> But perhaps that is not the way to do it and we should just cherry-pick
> >>> 30832c06a8d1f9caff0987654ef9e24d59469d9a in Xen 4.1?
> >>
> >>I think we should do both, i.e. backport 30832c06a8d1 now to solve the
> >>immediate problem and then look at fixing unstable to be more accepting
> >>of new features which it doesn't yet know about.
> >
> >Hmm, not sure - without a split between necessary to be understood
> >and acceptable to be unknown ones, I'm not sure either model will be
> >the right thing.
> 
> And actually, in the case at hand the "BOOM" is correct: If the kernel tells
> the hypervisor that it needs a feature the hypervisor doesn't even recognize,
> it's surely wrong to ignore this. The mistake here is for the kernel to require

But it does not ignore it. It checks later on in construct_dom0 whether
the 'required' parameters are present, like:

if ( test_bit(XENFEAT_supervisor_mode_kernel, parms.f_required) )



> that feature statically in the first place - that should be done only if the kernel
> could _only_ boot in PVH mode.

The feature is not marked as "required" but rather - it can utilize said
extension (so supported). I am advocating that the calleer checks that
all of the required pieces are correct - and it can ignore the ones it
has no idea off (which it does for some of the Xen ELF notes - ignores
them if it has no idea of what they are).


> 
> Jan
>