[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.