RE: [PATCH] vtdt: add a missing change (RE: [Xen-devel] Re: xen guest hang with TSC_DEADLINE)

["Wei, Gang" <gang.wei@xxxxxxxxx>]

Christoph Egger wrote on 2011-01-05:
>>>>>>> c/s 22529 and 22530 cause a xen guest hang.
>>>>>>> 
>>>>>>> While "normal" guests like Linux and NetBSD boot fine I boot
>>>>>>> Xen itself as a xen guest for my nested virtualization.
>>>>>>> 
>>>>>>> When I do that then the guest dom0 hangs at boot when it tries
>>>>>>> to initialize the first vcpu.
>>>>>>> The bug is introduced somewhere in c/s 22529 and triggers with
>>>>>>> c/s 22530.
>>>>>> 
>>>>>> Can you enable apic_timer debug info var hvm_debug and give
>>>>>> more serial port log around the guest dom0 hangs? I used to
>>>>>> test xen guest, it works well expect that it boot a little bit slowly.
>>>>> 
>>>>> This is the log output I get with TSC_DEADLINE feature enabled:
>>>> 
>>>> Just found one change was missed while the whole patch was checked in.
>>>> Apply below patch, it should be ok now.
>>>> ...
>>> The hang is still reproducable with this change. Sorry.
>> 
>> Can you still see below line in the serial log? Is there anything
>> different?
>> 
>> (XEN) [HVM:1.0] <vlapic_tdt_msr_set> ignore tsc deadline msr write
> 
> This one disappeared.
> 
> My serial log is flooded with
>...
> 
> But I never see a line starting with [HVM:1.0] or [HVM:1.4]. My guest
> has four virtual vcpus.
> 
> nested dom0 output did not change.

I tried 4-vcpu guest on my 2-pcpu machine also. It can finally boot up although 
it hangs for quite a long period (tens of minutes) while guest dom0 do starting 
udev. It is similar as nested xen tdt=off case.

So it may caused by vendor specific code in dom0. I would like to propose a 
easy workaround: expose tdt feature to guest on Intel platform only. Do you 
agree? Or do you prefer to find the root cause of current issue?

Jimmy

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel