Re: [Xen-devel] Debian stable kernel got timer issue when running as PV guest

[Sheng Yang <sheng@xxxxxxxxxx>]

On Fri, Apr 13, 2012 at 12:56 AM, Jan Beulich <JBeulich@xxxxxxxx> wrote:

>>> On 12.04.12 at 21:22, Sheng Yang <sheng@xxxxxxxxxx> wrote:
> I've compiled a kernel, force sched_clock_stable=0, then it solved the
> timestamp jump issue as expected. Luckily, seems it also solved the call
> trace and guest hang issue as well.

And this is also how it should be fixed.

> Attachment is a (untested) patch to mask the CPUID leaf 0x80000007. I think
> the issue can be easily reproduced using a Westmere or SandyBridge
> machine(my old colleagues at Intel said the feature likely existed after
> Nehalem) running newer version of PV guest, check the guest cpuinfo you
> would see nonstop_tsc, and you would notice the abnormal timestamp of
> printk.

Masking the entire leaf is certainly out of question. And even masking
the individual bit is questionable - a PV kernel simply shouldn't look at
it imo (for other than possibly reporting to user mode purposes).

Jan

The CPUID detection part in the kernel is handled by CPU vendor, not Xen. And the way how Xen control it is through CPUID it present to the guest.

1. We can only mask one bit of it. But currently this leaf got only this feature. I don't think it would be a big problem of mask the whole leaf. I think it's already a problem that Xen handle PV guest a blacklist of cpu feature rather than a white list, so when some new feature slipped in(like this time), nobody would know what would happen. I am really thinking of some thing like:

switch ( input[0] )

case...

case...

+default: 

        regs[0] = regs[1] = regs[2] = regs[3] = 0;

Maybe there are some reason that we didn't set a default value for pv cpuid policy, but I can't see why.

2. If we want to present the cpu feature to the guest and disable that feature in the guest, then what's the point? I don't think it is a good idea. What if there are something else interactive with this cpuid feature but we failed to disable(e.g. something other than sched_clock_stable)? Just don't show it would be a better/cleaner way to do it, as long as we agreed this feature is useless even troublesome for PV guest.

 

--

regards

Yang, Sheng

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