Re: xen-unstable + 4.1.0-rc1: Dom0 kernel stalls in early boot

[Boris Ostrovsky <boris.ostrovsky@oracle.com>]

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