Re: [Xen-devel] xen-unstable + 4.1.0-rc1: Dom0 kernel stalls in early boot

[Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>]

On 04/27/2015 04:15 PM, Boris Ostrovsky wrote:
> On 04/27/2015 11:40 AM, Sander Eikelenboom wrote:
> > Monday, April 27, 2015, 4:55:06 PM, you wrote:
> >
> > > Hi David / Konrad,
> > > Today i tried upgrading my dom0 kernel to 4.1-rc1, but it stalls in 
> > > early boot.
> > > Xen console was still reponsive so i dumped some info with the debug 
> > > keys.
> > > Serial log is attached.
> > > The kernel boots fine on baremetal and my previous test kernel that 
> > > was pulled
> > > and compiled on 20150423 in the mergewindow boots fine 
> > > (unfortunately my scripts
> > > don't add an git commit version to the kernel name yet.
> > > (but the 20150423 version has it's own issue when used as a PV guest 
> > > kernel
> > > with pci passthrough, pci-front can't connect somehow, which i was 
> > > trying
> > > to get at .. when i stumbled upon this one :-) ).
> > > --
> > > Sander
> > Hrmm shoot, that even didn't need a full bisection
> > (but i looked over it before sending the mails), tested by reverting
> > this one commit, after that it boots fine:
> >
> > 61f01dd941ba9e06d2bf05994450ecc3d61b6b8b
> > "x86_64, asm: Work around AMD SYSRET SS descriptor attribute issue"
> >
> > Question is .. why does it boot on baremetal, but not under Xen ?
> > (any ideas before getting this to LKML and x86 maintainers  / Linus ?)
> We shouldn't be loading __KERNEL_DS to stack segment in PV, which is 
> what this patch does.
> The bug that this commit is trying to fix is not applicable to PV 
> guests in the first place (and even if it is it would have to be fixed 
> in the hypervisor) so we essentially need to avoid setting 
> X86_BUG_SYSRET_SS_ATTRS flag in CPU initialization code. I need to 
> find a good place to clear it early enough.
The most logical thing to do seems to be adding set_cpu_features op to 
x86_hyper_xen_hvm (and renaming it). The trouble is that its name string 
is "Xen HVM" and so "HVM" part would have to go. This may be bad if a 
tool greps for this string in the log.
Alternatively we could re-assign name string when we figure out which 
guest we are but that would require un-constifying struct hypervisor_x86 
everywhere.
Any preference?

-boris

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