qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: KVM call agenda for Jan 26


From: Alexander Graf
Subject: [Qemu-devel] Re: KVM call agenda for Jan 26
Date: Tue, 26 Jan 2010 14:18:04 +0100

On 26.01.2010, at 14:11, Anthony Liguori wrote:

> On 01/26/2010 03:09 AM, Alexander Graf wrote:
>> On 26.01.2010, at 07:49, Chris Wright wrote:
>> 
>>   
>>> Please send in any agenda items you are interested in covering.
>>>     
>> KVM Hardware Inquiry Tool
>>   
> 
> Avi beat you to it ;-)  See vmxcap in the tree.

Interesting. Though as the name implies it's for VMX. No good for anybody but 
Intel users. I was more thinking of something generic that would also work just 
fine on PPC and S390.

> 
>> One of the things I have on my todo list is a tool you can run on your 
>> machine that tells you which virtualization features it supports. Imaginary 
>> output of such a tool:
>> 
>> --
>> 
>> KVM Supported: yes
>> NPT/EPT: yes
>> Device Assignment: no
>> 
>> Expected Virtual CPU Speed: 95%
>>   
> 
> I would suggest exercising caution in making such a broad performance 
> statement.  It's never going to be that simple.

Well, I think we should tell users something. We are telling them "According to 
performance measurements, when using NPT with a non-IO heavy workload gives you 
> 90% native performance in the VM" today already. At least that's what I 
remembered ;-).

The message should be something really simple so users know what to expect from 
KVM before they actually use it. With all the device assignment questions 
arising that somehow seems to underline my statement.

I'd also like to see some simple help analysis built into this tool. Something 
like "VMX is disabled in the BIOS", "Machine is Device Passthrough capable, but 
it's disabled in the BIOS", "Please pass parameter XXX to the kernel command 
line to activate feature Y".

The main question is where does it belong?

a) built into qemu
b) built as separate tool, but shipped with qemu
c) completely separate

I'm personally leaning towards a. That way we can reuse the detection code and 
give help when an option is used that doesn't work.

Alex



reply via email to

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