On Mon, Dec 14, 2009 at 03:49:39PM -0600, Anthony Liguori wrote: > Michael S. Tsirkin wrote: >> On Mon, Dec 14, 2009 at 02:54:49PM -0600, Anthony Liguori wrote: >> >>> Michael S. Tsirkin wrote: >>> >>>> On Mon, Dec 14, 2009 at 02:18:33PM -0600, Anthony Liguori wrote: >>>> >>>>> Michael S. Tsirkin wrote: >>>>> >>>>>> This might help 32 bit guests, but not guests with 64 bit >>>>>> kernel and 32 bit userspace (my case) because all 64 bit >>>>>> CPUs advertise syscall bit in cpuid. Thus 64 bit guests >>>>>> do not seem to even bother checking this bit: >>>>>> AMD + 64 bit -> syscall. >>>>>> >>>>> Okay, I don't see a great option other than migrating the vendor_id >>>>> string. >>>>> >>>> This won't help with kernels <2.6.32 though. I guess we can switch >>>> default vendor to Intel, this likely has some other side effects. >>>> >>> That's a kernel bug. If we think it effects a lot of users, we >>> should introduce a CAP such that we can detect this in userspace and >>> fail gracefully. >>> >> >> Not emulating feature host CPU does not have is a kernel bug? >> Okay ... >> Yes, almost no one runs 2.6.32 yet. >> > > The kernel has the ability to filter feature bits from cpuid.
I don't think it does: cpuid is an unpriveledged operation, is it not? > We assume > it's going to filter out things it doesn't support. It's tricky: this bit has multiple meanings. This is a cpu architecture bug, not a kernel bug. > Regards, > > Anthony Liguori
