[Top][All Lists]
[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
- [Qemu-devel] KVM call agenda for Jan 26, Chris Wright, 2010/01/26
- [Qemu-devel] Re: KVM call agenda for Jan 26, Alexander Graf, 2010/01/26
- [Qemu-devel] Re: KVM call agenda for Jan 26, Anthony Liguori, 2010/01/26
- [Qemu-devel] Re: KVM call agenda for Jan 26, Avi Kivity, 2010/01/26
- [Qemu-devel] Re: KVM call agenda for Jan 26,
Alexander Graf <=
- [Qemu-devel] Re: KVM call agenda for Jan 26, Avi Kivity, 2010/01/26
- [Qemu-devel] Re: KVM call agenda for Jan 26, Daniel P. Berrange, 2010/01/26
- [Qemu-devel] Re: KVM call agenda for Jan 26, Alexander Graf, 2010/01/26
- [Qemu-devel] Re: KVM call agenda for Jan 26, Avi Kivity, 2010/01/26
- [Qemu-devel] Re: KVM call agenda for Jan 26, Anthony Liguori, 2010/01/26
- [Qemu-devel] Re: KVM call agenda for Jan 26, Avi Kivity, 2010/01/26
- [Qemu-devel] Re: KVM call agenda for Jan 26, Anthony Liguori, 2010/01/26
- [Qemu-devel] Re: KVM call agenda for Jan 26, Avi Kivity, 2010/01/26
- [Qemu-devel] Re: KVM call agenda for Jan 26, Anthony Liguori, 2010/01/26
- [Qemu-devel] Re: KVM call agenda for Jan 26, Avi Kivity, 2010/01/26