[Qemu-devel] KVM call agenda for Jan 26

[Qemu-devel] KVM call agenda for Jan 26

[Chris Wright]

Please send in any agenda items you are interested in covering.

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

[Alexander Graf]

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

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%

--

That way users can easily determine what to expect when they run KVM on a machine without need to know about CPUID flags that don't even get exposed in /proc/cpuinfo or grepping dmesg.

My main question on this one is how to best implement it.

Should this be part of qemu? We'll need some architecture specific backend code, so leveraging the structure might be helpful.
Should this be a separate script? That'd mean installing one more application that distros might name differently :(.
Does it even have chances to get accepted upstream?


Alex

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

[Anthony Liguori]

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.

> 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.

Regards,

Anthony Liguori

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

[Avi Kivity]

On 01/26/2010 03:11 PM, 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.

I knew I should have put a disclaimer in there.  Maybe I should make the 
output vary randomly over time?

Anyway we really need a "virtualization stack inquiry tool", since 
capabilities depend on the hardware, kernel, and qemu.

-- 
error compiling committee.c: too many arguments to function

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

[Alexander Graf]

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

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

[Avi Kivity]

On 01/26/2010 03:18 PM, Alexander Graf wrote:
>
> 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.
>
>    

Me too, especially as the whole stack is involved, and qemu is the 
topmost part from our perspective (no doubt libvirt will want to 
integrate that functionality as well).

-- 
error compiling committee.c: too many arguments to function

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

[Daniel P. Berrange]

On Tue, Jan 26, 2010 at 03:24:50PM +0200, Avi Kivity wrote:
> On 01/26/2010 03:18 PM, Alexander Graf wrote:
> >
> >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.
> >
> >   
> 
> Me too, especially as the whole stack is involved, and qemu is the 
> topmost part from our perspective (no doubt libvirt will want to 
> integrate that functionality as well).

FYI, libvirt already exposes this kind of functionality. The API call
virConnectGetCapabilities() / command line "virsh capabilities" command
tells you about what the virtualization host is able to support. It can
tell you what architectures are supported, by which binaries. What
machine types are available. Whether KVM or KQEMU acceleration are
present. What CPU model / flags are on the host. What NUMA topology is
available. etc etc 

The data format it outputs though is not exactly targetted for direct
end user consumption though, rather its a XML doc aimed at applications
The virt-manager app tries to use this to inform the user of problems
such as ability todo hardware virt, but it not being enabled.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

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

[Alexander Graf]

On 26.01.2010, at 14:33, Daniel P. Berrange wrote:

> On Tue, Jan 26, 2010 at 03:24:50PM +0200, Avi Kivity wrote:
>> On 01/26/2010 03:18 PM, Alexander Graf wrote:
>>> 
>>> 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.
>>> 
>>> 
>> 
>> Me too, especially as the whole stack is involved, and qemu is the 
>> topmost part from our perspective (no doubt libvirt will want to 
>> integrate that functionality as well).
> 
> FYI, libvirt already exposes this kind of functionality. The API call
> virConnectGetCapabilities() / command line "virsh capabilities" command
> tells you about what the virtualization host is able to support. It can
> tell you what architectures are supported, by which binaries. What
> machine types are available. Whether KVM or KQEMU acceleration are
> present. What CPU model / flags are on the host. What NUMA topology is
> available. etc etc 
> 
> The data format it outputs though is not exactly targetted for direct
> end user consumption though, rather its a XML doc aimed at applications
> The virt-manager app tries to use this to inform the user of problems
> such as ability todo hardware virt, but it not being enabled.

Hrm, while I sympathize with the goals of libvirt and all the efforts in it, I'd like to see the stock qemu exectable stay as user friendly as possible. One of qemu's strong points always used to be its really simple CLI.
So IMHO it rather belongs there with libvirt querying qemu than the other way around.

Nevertheless, I suppose the code would be a pretty good starting point!

Alex

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

[Avi Kivity]

On 01/26/2010 03:33 PM, Daniel P. Berrange wrote:
>
>> Me too, especially as the whole stack is involved, and qemu is the
>> topmost part from our perspective (no doubt libvirt will want to
>> integrate that functionality as well).
>>      
> FYI, libvirt already exposes this kind of functionality. The API call
> virConnectGetCapabilities() / command line "virsh capabilities" command
> tells you about what the virtualization host is able to support. It can
> tell you what architectures are supported, by which binaries. What
> machine types are available. Whether KVM or KQEMU acceleration are
> present. What CPU model / flags are on the host. What NUMA topology is
> available. etc etc
>
>    

Great.  Note that for a cpu flag to be usable in a guest, it needs to be 
supported by both kvm.ko and qemu, so reporting /proc/cpuinfo is 
insufficient.  There are also synthetic cpu flags (kvm paravirt 
features, x2apic) that aren't present in /proc/cpuinfo.


-- 
error compiling committee.c: too many arguments to function

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

[Anthony Liguori]

On 01/26/2010 07:24 AM, Avi Kivity wrote:
> On 01/26/2010 03:18 PM, Alexander Graf wrote:
>>
>> 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.
>>
>
> Me too, especially as the whole stack is involved, and qemu is the 
> topmost part from our perspective (no doubt libvirt will want to 
> integrate that functionality as well).

I'm not sure I agree.  It would use no code from qemu and really benefit 
in no way from being part of qemu.  I don't feel that strongly about it 
though.

Regards,

Anthony Liguori

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

[Avi Kivity]

On 01/26/2010 04:13 PM, Anthony Liguori wrote:
>> Me too, especially as the whole stack is involved, and qemu is the 
>> topmost part from our perspective (no doubt libvirt will want to 
>> integrate that functionality as well).
>
>
> I'm not sure I agree.  It would use no code from qemu and really 
> benefit in no way from being part of qemu.  I don't feel that strongly 
> about it though.
>

It would need to know which cpuid bits qemu supports.  Only qemu knows that.

-- 
error compiling committee.c: too many arguments to function

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

[Anthony Liguori]

On 01/26/2010 08:15 AM, Avi Kivity wrote:
> On 01/26/2010 04:13 PM, Anthony Liguori wrote:
>>> Me too, especially as the whole stack is involved, and qemu is the 
>>> topmost part from our perspective (no doubt libvirt will want to 
>>> integrate that functionality as well).
>>
>>
>> I'm not sure I agree.  It would use no code from qemu and really 
>> benefit in no way from being part of qemu.  I don't feel that 
>> strongly about it though.
>>
>
> It would need to know which cpuid bits qemu supports.  Only qemu knows 
> that.

I'm not sure I understand why.  Can you elaborate?

Regards,

Anthony Liguori

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

[Avi Kivity]

On 01/26/2010 04:22 PM, Anthony Liguori wrote:
> On 01/26/2010 08:15 AM, Avi Kivity wrote:
>> On 01/26/2010 04:13 PM, Anthony Liguori wrote:
>>>> Me too, especially as the whole stack is involved, and qemu is the 
>>>> topmost part from our perspective (no doubt libvirt will want to 
>>>> integrate that functionality as well).
>>>
>>>
>>> I'm not sure I agree.  It would use no code from qemu and really 
>>> benefit in no way from being part of qemu.  I don't feel that 
>>> strongly about it though.
>>>
>>
>> It would need to know which cpuid bits qemu supports.  Only qemu 
>> knows that.
>
> I'm not sure I understand why.  Can you elaborate?
>

If qemu doesn't recognize -cpu qemu64,+nx, then no amount of hardware 
and kvm.ko support will allow the user to enable nx in a guest.

-- 
error compiling committee.c: too many arguments to function

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

[Anthony Liguori]

On 01/26/2010 08:26 AM, Avi Kivity wrote:
> On 01/26/2010 04:22 PM, Anthony Liguori wrote:
>> On 01/26/2010 08:15 AM, Avi Kivity wrote:
>>> On 01/26/2010 04:13 PM, Anthony Liguori wrote:
>>>>> Me too, especially as the whole stack is involved, and qemu is the 
>>>>> topmost part from our perspective (no doubt libvirt will want to 
>>>>> integrate that functionality as well).
>>>>
>>>>
>>>> I'm not sure I agree.  It would use no code from qemu and really 
>>>> benefit in no way from being part of qemu.  I don't feel that 
>>>> strongly about it though.
>>>>
>>>
>>> It would need to know which cpuid bits qemu supports.  Only qemu 
>>> knows that.
>>
>> I'm not sure I understand why.  Can you elaborate?
>>
>
> If qemu doesn't recognize -cpu qemu64,+nx, then no amount of hardware 
> and kvm.ko support will allow the user to enable nx in a guest.

Does -cpu host filter out flags that we don't know about?  I'm pretty 
sure it doesn't.  Since we're planning on moving to -cpu host by default 
for KVM, does it really matter?

Oh, I was under the impression that the tool was meant to be software 
agnostic.  IOW, here are all the virt features your hardware supports.

Regards,

Anthony Liguori

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

[Avi Kivity]

On 01/26/2010 04:32 PM, Anthony Liguori wrote:
>>>> It would need to know which cpuid bits qemu supports.  Only qemu 
>>>> knows that.
>>>
>>> I'm not sure I understand why.  Can you elaborate?
>>>
>>
>> If qemu doesn't recognize -cpu qemu64,+nx, then no amount of hardware 
>> and kvm.ko support will allow the user to enable nx in a guest.
>
>
> Does -cpu host filter out flags that we don't know about?  I'm pretty 
> sure it doesn't.  Since we're planning on moving to -cpu host by 
> default for KVM, does it really matter?

People who use discovery tools are probably setting up a migration 
cluster.  They aren't going to use -cpu host.

>
> Oh, I was under the impression that the tool was meant to be software 
> agnostic.  IOW, here are all the virt features your hardware supports.

That's /proc/cpuinfo, we should just extend it, maybe that's what Alex 
meant, but I'd like to see something more capable.

-- 
error compiling committee.c: too many arguments to function

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

[Alexander Graf]

On 26.01.2010, at 15:37, Avi Kivity wrote:

> On 01/26/2010 04:32 PM, Anthony Liguori wrote:
>>>>> It would need to know which cpuid bits qemu supports.  Only qemu knows that.
>>>> 
>>>> I'm not sure I understand why.  Can you elaborate?
>>>> 
>>> 
>>> If qemu doesn't recognize -cpu qemu64,+nx, then no amount of hardware and kvm.ko support will allow the user to enable nx in a guest.
>> 
>> 
>> Does -cpu host filter out flags that we don't know about?  I'm pretty sure it doesn't.  Since we're planning on moving to -cpu host by default for KVM, does it really matter?
> 
> People who use discovery tools are probably setting up a migration cluster.  They aren't going to use -cpu host.
> 
>> 
>> Oh, I was under the impression that the tool was meant to be software agnostic.  IOW, here are all the virt features your hardware supports.
> 
> That's /proc/cpuinfo, we should just extend it, maybe that's what Alex meant, but I'd like to see something more capable.

I think we're all looking at different use-cases.

First and frontmost the one type of user I'm concerned with in this case is a mortal end-user who doesn't know that much about virtualization details and doesn't care what NPT is. He just wants to have a VM running and wants to know how well it'll work.

For such a user an addition to /proc/cpuinfo would be enough, if it'd include IOMMU information. Or maybe /proc/iommu?

I think users should be able to run some simple command to evaluate if what they're trying to do works out. And if not, the command should give assistance on how to make things work (buy a new mainboard, set this kernel option, ...)

Of course one could fit in stuff for management tools too, but that's not my main goal for this feature.

Alex

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

[Anthony Liguori]

On 01/26/2010 08:37 AM, Avi Kivity wrote:
> People who use discovery tools are probably setting up a migration 
> cluster.  They aren't going to use -cpu host.

BTW, it might be neat to introduce a qemu command line that runs a 
monitor command and exits without creating a VM.  We could then 
introduce a info cpucap command that dumped all of the supported CPU 
features.

Someone setting up a migration cluster would then run qemu -monitor 
command="info cpucap", collect the results, compute an intersection, and 
then use that to generate a -cpu flag.  In fact, providing a tool that 
parsed a bunch of those outputs and generated a -cpu flag would be a 
pretty nice addition.

>>
>> Oh, I was under the impression that the tool was meant to be software 
>> agnostic.  IOW, here are all the virt features your hardware supports.
>
> That's /proc/cpuinfo, we should just extend it, maybe that's what Alex 
> meant, but I'd like to see something more capable.

I definitely think extending /proc/cpuinfo or introducing a 
/proc/virtinfo would be a good idea regardless of any tool we introduce.

Regards,

Anthony Liguori

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

[Avi Kivity]

On 01/26/2010 04:42 PM, Anthony Liguori wrote:
> On 01/26/2010 08:37 AM, Avi Kivity wrote:
>> People who use discovery tools are probably setting up a migration 
>> cluster.  They aren't going to use -cpu host.
>
> BTW, it might be neat to introduce a qemu command line that runs a 
> monitor command and exits without creating a VM.  We could then 
> introduce a info cpucap command that dumped all of the supported CPU 
> features.
>
> Someone setting up a migration cluster would then run qemu -monitor 
> command="info cpucap", collect the results, compute an intersection, 
> and then use that to generate a -cpu flag.  In fact, providing a tool 
> that parsed a bunch of those outputs and generated a -cpu flag would 
> be a pretty nice addition.

Definitely.  And query about supported machine models virtio NIC 
features, etc.



-- 
error compiling committee.c: too many arguments to function

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

[Avi Kivity]

On 01/26/2010 04:42 PM, Alexander Graf wrote:
>
>> That's /proc/cpuinfo, we should just extend it, maybe that's what Alex meant, but I'd like to see something more capable.
>>      
> I think we're all looking at different use-cases.
>
> First and frontmost the one type of user I'm concerned with in this case is a mortal end-user who doesn't know that much about virtualization details and doesn't care what NPT is. He just wants to have a VM running and wants to know how well it'll work.
>    

It really depends on what he does with it.  3D gaming? might have a 
different experience from the always exciting kernel builds.

-- 
error compiling committee.c: too many arguments to function

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

[Alexander Graf]

On 26.01.2010, at 15:47, Avi Kivity wrote:

> On 01/26/2010 04:42 PM, Alexander Graf wrote:
>> 
>>> That's /proc/cpuinfo, we should just extend it, maybe that's what Alex meant, but I'd like to see something more capable.
>>>     
>> I think we're all looking at different use-cases.
>> 
>> First and frontmost the one type of user I'm concerned with in this case is a mortal end-user who doesn't know that much about virtualization details and doesn't care what NPT is. He just wants to have a VM running and wants to know how well it'll work.
>>   
> 
> It really depends on what he does with it.  3D gaming? might have a different experience from the always exciting kernel builds.

Well, we can give an estimation (based on previous measurements) for certain subsystems. Like I proposed in the original mail, we can actually give users information about virtual CPU speed.

With SPICE hopefully merged one day we also could give some estimates on 3D performance.


Alex

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

[Anthony Liguori]

On 01/26/2010 08:50 AM, Alexander Graf wrote:
> On 26.01.2010, at 15:47, Avi Kivity wrote:
>
>    
>> On 01/26/2010 04:42 PM, Alexander Graf wrote:
>>      
>>>        
>>>> That's /proc/cpuinfo, we should just extend it, maybe that's what Alex meant, but I'd like to see something more capable.
>>>>
>>>>          
>>> I think we're all looking at different use-cases.
>>>
>>> First and frontmost the one type of user I'm concerned with in this case is a mortal end-user who doesn't know that much about virtualization details and doesn't care what NPT is. He just wants to have a VM running and wants to know how well it'll work.
>>>
>>>        
>> It really depends on what he does with it.  3D gaming? might have a different experience from the always exciting kernel builds.
>>      
> Well, we can give an estimation (based on previous measurements) for certain subsystems. Like I proposed in the original mail, we can actually give users information about virtual CPU speed.
>    

The problem with making an unqualified statement about something like 
"virtual CPU speed" is that if a user runs a random benchmark, and gets 
less than XX%, they'll consider it a bug and be unhappy.

I'm very reluctant to take anything in QEMU that makes promises about 
virtualization performance.  It's a bad idea IMHO.

> With SPICE hopefully merged one day we also could give some estimates on 3D performance.
>    

Spice doesn't support 3D today.

Regards,

Anthony Liguori

> Alex