From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1NKYQj-000240-PX
	for qemu-devel@nongnu.org; Tue, 15 Dec 2009 09:31:14 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1NKYQd-00022B-UN
	for qemu-devel@nongnu.org; Tue, 15 Dec 2009 09:31:12 -0500
Received: from [199.232.76.173] (port=44061 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1NKYQc-00021v-Nc
	for qemu-devel@nongnu.org; Tue, 15 Dec 2009 09:31:06 -0500
Received: from mx1.redhat.com ([209.132.183.28]:12374)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <mst@redhat.com>) id 1NKYQc-0001M7-GW
	for qemu-devel@nongnu.org; Tue, 15 Dec 2009 09:31:06 -0500
Date: Tue, 15 Dec 2009 16:28:21 +0200
From: "Michael S. Tsirkin" <mst@redhat.com>
Subject: Re: [Qemu-devel] cpuid problem in upstream qemu with kvm
Message-ID: <20091215142820.GA23472@redhat.com>
References: <20091214194432.GC6150@redhat.com> <4B2698A9.9090107@codemonkey.ws>
	<20091214200002.GA27769@redhat.com>
	<4B2699BB.1090302@codemonkey.ws> <20091214201049.GD6150@redhat.com>
	<4B269D99.8080404@codemonkey.ws> <20091214203125.GH6150@redhat.com>
	<4B26A619.7070503@codemonkey.ws> <20091214211024.GD6100@redhat.com>
	<4B26B2F3.9080102@codemonkey.ws>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4B26B2F3.9080102@codemonkey.ws>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: qemu-devel@nongnu.org, Gleb Natapov <gleb@redhat.com>, avi@redhat.com

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