qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3


From: Avi Kivity
Subject: Re: [kvm-devel] [Qemu-devel] expose host CPU features to guests: Take 3
Date: Tue, 25 Sep 2007 11:31:35 +0200
User-agent: Thunderbird 2.0.0.5 (X11/20070719)

J. Mayer wrote:
> On Tue, 2007-09-25 at 11:01 +0200, Avi Kivity wrote:
>   
>> Dan Kenigsberg wrote:
>>     
>>> On Tue, Sep 25, 2007 at 03:28:24AM +0200, andrzej zaborowski wrote:
>>>   
>>>       
>>>> Hi,
>>>>
>>>> On 24/09/2007, Dan Kenigsberg <address@hidden> wrote:
>>>>     
>>>>         
>>>>> As with previous "Takes" of this patch, its purpose is to expose host
>>>>> +{
>>>>> +    asm("cpuid"
>>>>> +        : "=a" (*ax),
>>>>> +          "=b" (*bx),
>>>>> +          "=c" (*cx),
>>>>> +          "=d" (*dx)
>>>>> +        : "a" (function));
>>>>> +}
>>>>>       
>>>>>           
>>>> I haven't really read through the rest of your code but this piece
>>>> appears to be outside any #ifdef/#endif so it will only build on x86.
>>>>     
>>>>         
>>> I might be missing something here, but isn't not being on the
>>> TARGET_PATH of Makefile.target enough? I don't see #ifdef TARGET_I386
>>> elsewhere under target-i386. I don't mind adding extra protection, I
>>> just be happy to better understand the whats and whys.
>>>   
>>>       
>> target-i386 means the guest will run i386 instructions, but the host can
>> be something else (say, powerpc).
>>
>> Nothing else uses host instructions in that directory, so no protection
>> was necessary before.
>>     
>
> I've got a remark about this: why this has to be added to the Qemu
> code ?
> Imho, all is needed is an implementation of the -cpu option for
> x86/x86_64 target. Then, an external tool (even a shell script) can be
> used to determine what is the host CPU if you want to select the exact
> same CPU to be emulated in Qemu. It seems to me that trying to do so is
> out of the scope of Qemu code and just add unneeded complexity.
>   

Indeed for regular qemu this is useless.  But it is useful for kqemu
(for which there is support in mainline qemu), and for kvm (which we
hope to merge one day).


-- 
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]