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

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

On Mon, Dec 23, 2013 at 11:49:49AM +0000, Jan Beulich wrote:
> >>> "Jan Beulich" <jbeulich@xxxxxxxx> 12/23/13 10:39 AM >>>
> >>>> Ian Campbell <Ian.Campbell@xxxxxxxxxx> 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
> 

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