[Qemu-devel] Better qemu/kvm defaults (was Re: [RFC PATCH 0/4] Gang scheduling in CFS)

[Qemu-devel] Better qemu/kvm defaults (was Re: [RFC PATCH 0/4] Gang scheduling in CFS)

[Dor Laor]

On 12/26/2011 11:05 AM, Avi Kivity wrote:
> On 12/26/2011 05:14 AM, Nikunj A Dadhania wrote:
>>>
>>> btw you can get an additional speedup by enabling x2apic, for
>>> default_send_IPI_mask_logical().
>>>
>> In the host?
>>
>
> In the host, for the guest:
>
>   qemu -cpu ...,+x2apic
>

It seems to me that we should improve our default flags.
So many times users fail to submit the proper huge command-line options 
that we require. Honestly, we can't blame them, there are so many flags 
and so many use cases its just too hard to get it right for humans.

I propose a basic idea and folks are welcome to discuss it:

1. Improve qemu/kvm defaults
    Break the current backward compatibility (but add a --default-
    backward-compat-mode) and set better values for:
     - rtc slew time
     - cache=none
     - x2apic, maybe enhance qemu64 or move to -cpu host?
     - aio=native|threads (auto-sense?)
     - use virtio devices by default
     - more?

    Different defaults may be picked automatically when TCG|KVM used.

2. External hardening configuration file kept in qemu.git
    For non qemu/kvm specific definitions like the io scheduler we
    should maintain a script in our tree that sets/sense the optimal
    settings of the host kernel (maybe similar one for the guest).

HTH,
Dor

Re: [Qemu-devel] Better qemu/kvm defaults (was Re: [RFC PATCH 0/4] Gang scheduling in CFS)

[Avi Kivity]

On 12/29/2011 06:07 PM, Dor Laor wrote:
> On 12/26/2011 11:05 AM, Avi Kivity wrote:
>> On 12/26/2011 05:14 AM, Nikunj A Dadhania wrote:
>>>>
>>>> btw you can get an additional speedup by enabling x2apic, for
>>>> default_send_IPI_mask_logical().
>>>>
>>> In the host?
>>>
>>
>> In the host, for the guest:
>>
>>   qemu -cpu ...,+x2apic
>>
>
> It seems to me that we should improve our default flags.
> So many times users fail to submit the proper huge command-line
> options that we require. Honestly, we can't blame them, there are so
> many flags and so many use cases its just too hard to get it right for
> humans.
>
> I propose a basic idea and folks are welcome to discuss it:
>
> 1. Improve qemu/kvm defaults
>    Break the current backward compatibility (but add a --default-
>    backward-compat-mode)

This exists, -M pc-1.0.

> and set better values for:
>     - rtc slew time
>     - cache=none
>     - x2apic, maybe enhance qemu64 or move to -cpu host?

We tried this for 1.0, but it caused regressions.  Need to try again for
1.1.

>     - aio=native|threads (auto-sense?)
>     - use virtio devices by default

Can't install non-Linux guests.

>     - more?
>
>    Different defaults may be picked automatically when TCG|KVM used.


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

Re: [Qemu-devel] Better qemu/kvm defaults (was Re: [RFC PATCH 0/4] Gang scheduling in CFS)

[Anthony Liguori]

On 12/29/2011 10:07 AM, Dor Laor wrote:
> On 12/26/2011 11:05 AM, Avi Kivity wrote:
>> On 12/26/2011 05:14 AM, Nikunj A Dadhania wrote:
>>>>
>>>> btw you can get an additional speedup by enabling x2apic, for
>>>> default_send_IPI_mask_logical().
>>>>
>>> In the host?
>>>
>>
>> In the host, for the guest:
>>
>> qemu -cpu ...,+x2apic
>>
>
> It seems to me that we should improve our default flags.
> So many times users fail to submit the proper huge command-line options that we
> require. Honestly, we can't blame them, there are so many flags and so many use
> cases its just too hard to get it right for humans.
>
> I propose a basic idea and folks are welcome to discuss it:
>
> 1. Improve qemu/kvm defaults
> Break the current backward compatibility (but add a --default-
> backward-compat-mode) and set better values for:
> - rtc slew time

What do you specifically mean?

> - cache=none

I'm not sure I see this as a "better default" particularly since O_DIRECT fails 
on certain file systems.  I think we really need to let WCE be toggable from the 
guest and then have a caching mode independent of WCE.  We then need some 
heuristics to only enable cache=off when we know it's safe.

> - x2apic, maybe enhance qemu64 or move to -cpu host?

Alex posted a patch for this.  I'm planning on merging it although so far no one 
has chimed up either way.

> - aio=native|threads (auto-sense?)

aio=native is unsafe to default because linux-aio is just fubar.  It falls back 
to synchronous I/O if the underlying filesystem doesn't support aio.  There's no 
way in userspace to problem if it's actually supported or not either...

> - use virtio devices by default

I don't think this is realistic since appropriately licensed signed virtio 
drivers do not exist for Windows.  (Please note the phrase "appropriately 
licensed signed").

> - more?
>
> Different defaults may be picked automatically when TCG|KVM used.
>
> 2. External hardening configuration file kept in qemu.git
> For non qemu/kvm specific definitions like the io scheduler we
> should maintain a script in our tree that sets/sense the optimal
> settings of the host kernel (maybe similar one for the guest).

What are "appropriate host settings" and why aren't we suggesting that distros 
and/or upstream just set them by default?

Regards,

Anthony Liguori

> HTH,
> Dor
>

Re: [Qemu-devel] Better qemu/kvm defaults (was Re: [RFC PATCH 0/4] Gang scheduling in CFS)

[Dor Laor]

On 12/29/2011 06:16 PM, Anthony Liguori wrote:
> On 12/29/2011 10:07 AM, Dor Laor wrote:
>> On 12/26/2011 11:05 AM, Avi Kivity wrote:
>>> On 12/26/2011 05:14 AM, Nikunj A Dadhania wrote:
>>>>>
>>>>> btw you can get an additional speedup by enabling x2apic, for
>>>>> default_send_IPI_mask_logical().
>>>>>
>>>> In the host?
>>>>
>>>
>>> In the host, for the guest:
>>>
>>> qemu -cpu ...,+x2apic
>>>
>>
>> It seems to me that we should improve our default flags.
>> So many times users fail to submit the proper huge command-line
>> options that we
>> require. Honestly, we can't blame them, there are so many flags and so
>> many use
>> cases its just too hard to get it right for humans.
>>
>> I propose a basic idea and folks are welcome to discuss it:
>>
>> 1. Improve qemu/kvm defaults
>> Break the current backward compatibility (but add a --default-
>> backward-compat-mode) and set better values for:
>> - rtc slew time
>
> What do you specifically mean?

-rtc localtime,driftfix=slew

>
>> - cache=none
>
> I'm not sure I see this as a "better default" particularly since
> O_DIRECT fails on certain file systems. I think we really need to let
> WCE be toggable from the guest and then have a caching mode independent
> of WCE. We then need some heuristics to only enable cache=off when we
> know it's safe.

cache=none is still faster then it has the FS support.
qemu can test-run O_DIRECT and fall back to cache mode or just test the 
filesystem capabilities.

>
>> - x2apic, maybe enhance qemu64 or move to -cpu host?
>
> Alex posted a patch for this. I'm planning on merging it although so far
> no one has chimed up either way.
>
>> - aio=native|threads (auto-sense?)
>
> aio=native is unsafe to default because linux-aio is just fubar. It
> falls back to synchronous I/O if the underlying filesystem doesn't
> support aio. There's no way in userspace to problem if it's actually
> supported or not either...

Can we test-run this too? Maybe as a separate qemu mode or even binary 
that given a qemu cmdline, it will try to suggest better parameters?

>> - use virtio devices by default
>
> I don't think this is realistic since appropriately licensed signed
> virtio drivers do not exist for Windows. (Please note the phrase
> "appropriately licensed signed").

What's the percentage of qemu invocation w/ windows guest and a short 
cmd line? My hunch is that plain short cmdline indicates a developer and 
probably they'll use linux guest.

>
>> - more?
>>
>> Different defaults may be picked automatically when TCG|KVM used.
>>
>> 2. External hardening configuration file kept in qemu.git
>> For non qemu/kvm specific definitions like the io scheduler we
>> should maintain a script in our tree that sets/sense the optimal
>> settings of the host kernel (maybe similar one for the guest).
>
> What are "appropriate host settings" and why aren't we suggesting that
> distros and/or upstream just set them by default?

It's hard to set the right default for a distribution since the same 
distro should optimize for various usages of the same OS. For example, 
Fedora has tuned-adm w/ available profiles:
- desktop-powersave
- server-powersave
- enterprise-storage
- spindown-disk
- laptop-battery-powersave
- default
- throughput-performance
- latency-performance
- laptop-ac-powersave

We need to keep on recommending the best profile for virtualization, for 
Fedora I think it either enterprise-storage and maybe 
throughput-performance.

If we have a such a script, it can call the matching tuned profile 
instead of tweaking every /sys option.

>
> Regards,
>
> Anthony Liguori
>
>> HTH,
>> Dor
>>
>
>

Re: [Qemu-devel] Better qemu/kvm defaults (was Re: [RFC PATCH 0/4] Gang scheduling in CFS)

[Ronen Hod]

On 01/01/2012 12:16 PM, Dor Laor wrote:
> On 12/29/2011 06:16 PM, Anthony Liguori wrote:
>> On 12/29/2011 10:07 AM, Dor Laor wrote:
>>> On 12/26/2011 11:05 AM, Avi Kivity wrote:
>>>> On 12/26/2011 05:14 AM, Nikunj A Dadhania wrote:
>>>>>>
>>>>>> btw you can get an additional speedup by enabling x2apic, for
>>>>>> default_send_IPI_mask_logical().
>>>>>>
>>>>> In the host?
>>>>>
>>>>
>>>> In the host, for the guest:
>>>>
>>>> qemu -cpu ...,+x2apic
>>>>
>>>
>>> It seems to me that we should improve our default flags.
>>> So many times users fail to submit the proper huge command-line
>>> options that we
>>> require. Honestly, we can't blame them, there are so many flags and so
>>> many use
>>> cases its just too hard to get it right for humans.

You might want to take into account migration considerations. I.e., the 
target host's optimal setup.
Also, we need to beware of too much automation, since hardware changes 
might void Windows license activations.
Some of the parameters will depend on dynamic factors such as the total 
guest's nCPUs, mem, sharing (KSM), or whatever.
As a minimum, we can automatically suggest the qemu parameters and the 
host setup.

Ronen.

>>>
>>> I propose a basic idea and folks are welcome to discuss it:
>>>
>>> 1. Improve qemu/kvm defaults
>>> Break the current backward compatibility (but add a --default-
>>> backward-compat-mode) and set better values for:
>>> - rtc slew time
>>
>> What do you specifically mean?
>
> -rtc localtime,driftfix=slew
>
>>
>>> - cache=none
>>
>> I'm not sure I see this as a "better default" particularly since
>> O_DIRECT fails on certain file systems. I think we really need to let
>> WCE be toggable from the guest and then have a caching mode independent
>> of WCE. We then need some heuristics to only enable cache=off when we
>> know it's safe.
>
> cache=none is still faster then it has the FS support.
> qemu can test-run O_DIRECT and fall back to cache mode or just test 
> the filesystem capabilities.
>
>>
>>> - x2apic, maybe enhance qemu64 or move to -cpu host?
>>
>> Alex posted a patch for this. I'm planning on merging it although so far
>> no one has chimed up either way.
>>
>>> - aio=native|threads (auto-sense?)
>>
>> aio=native is unsafe to default because linux-aio is just fubar. It
>> falls back to synchronous I/O if the underlying filesystem doesn't
>> support aio. There's no way in userspace to problem if it's actually
>> supported or not either...
>
> Can we test-run this too? Maybe as a separate qemu mode or even binary 
> that given a qemu cmdline, it will try to suggest better parameters?
>
>>> - use virtio devices by default
>>
>> I don't think this is realistic since appropriately licensed signed
>> virtio drivers do not exist for Windows. (Please note the phrase
>> "appropriately licensed signed").
>
> What's the percentage of qemu invocation w/ windows guest and a short 
> cmd line? My hunch is that plain short cmdline indicates a developer 
> and probably they'll use linux guest.
>
>>
>>> - more?
>>>
>>> Different defaults may be picked automatically when TCG|KVM used.
>>>
>>> 2. External hardening configuration file kept in qemu.git
>>> For non qemu/kvm specific definitions like the io scheduler we
>>> should maintain a script in our tree that sets/sense the optimal
>>> settings of the host kernel (maybe similar one for the guest).
>>
>> What are "appropriate host settings" and why aren't we suggesting that
>> distros and/or upstream just set them by default?
>
> It's hard to set the right default for a distribution since the same 
> distro should optimize for various usages of the same OS. For example, 
> Fedora has tuned-adm w/ available profiles:
> - desktop-powersave
> - server-powersave
> - enterprise-storage
> - spindown-disk
> - laptop-battery-powersave
> - default
> - throughput-performance
> - latency-performance
> - laptop-ac-powersave
>
> We need to keep on recommending the best profile for virtualization, 
> for Fedora I think it either enterprise-storage and maybe 
> throughput-performance.
>
> If we have a such a script, it can call the matching tuned profile 
> instead of tweaking every /sys option.
>
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>> HTH,
>>> Dor
>>>
>>
>>
>
>

Re: [Qemu-devel] Better qemu/kvm defaults (was Re: [RFC PATCH 0/4] Gang scheduling in CFS)

[Dor Laor]

On 01/01/2012 04:01 PM, Ronen Hod wrote:
> On 01/01/2012 12:16 PM, Dor Laor wrote:
>> On 12/29/2011 06:16 PM, Anthony Liguori wrote:
>>> On 12/29/2011 10:07 AM, Dor Laor wrote:
>>>> On 12/26/2011 11:05 AM, Avi Kivity wrote:
>>>>> On 12/26/2011 05:14 AM, Nikunj A Dadhania wrote:
>>>>>>>
>>>>>>> btw you can get an additional speedup by enabling x2apic, for
>>>>>>> default_send_IPI_mask_logical().
>>>>>>>
>>>>>> In the host?
>>>>>>
>>>>>
>>>>> In the host, for the guest:
>>>>>
>>>>> qemu -cpu ...,+x2apic
>>>>>
>>>>
>>>> It seems to me that we should improve our default flags.
>>>> So many times users fail to submit the proper huge command-line
>>>> options that we
>>>> require. Honestly, we can't blame them, there are so many flags and so
>>>> many use
>>>> cases its just too hard to get it right for humans.
>
> You might want to take into account migration considerations. I.e., the
> target host's optimal setup.
> Also, we need to beware of too much automation, since hardware changes

There is no such a thing. :)

> might void Windows license activations.

Since qemu controls the guest's hardware abstraction and both src/dst 
invocation is 100% the same, it shouldn't be an issue

> Some of the parameters will depend on dynamic factors such as the total
> guest's nCPUs, mem, sharing (KSM), or whatever.
> As a minimum, we can automatically suggest the qemu parameters and the
> host setup.

Normally, the host settings are outside the scope of qemu. It's for 
projects like libvirt & VDSM to manage. By suggesting we'll maintain a 
script for optimized host setting I was mainly motivated to close a gap 
w/ developers/users that run qemu directly on a single host.

>
> Ronen.
>
>>>>
>>>> I propose a basic idea and folks are welcome to discuss it:
>>>>
>>>> 1. Improve qemu/kvm defaults
>>>> Break the current backward compatibility (but add a --default-
>>>> backward-compat-mode) and set better values for:
>>>> - rtc slew time
>>>
>>> What do you specifically mean?
>>
>> -rtc localtime,driftfix=slew
>>
>>>
>>>> - cache=none
>>>
>>> I'm not sure I see this as a "better default" particularly since
>>> O_DIRECT fails on certain file systems. I think we really need to let
>>> WCE be toggable from the guest and then have a caching mode independent
>>> of WCE. We then need some heuristics to only enable cache=off when we
>>> know it's safe.
>>
>> cache=none is still faster then it has the FS support.
>> qemu can test-run O_DIRECT and fall back to cache mode or just test
>> the filesystem capabilities.
>>
>>>
>>>> - x2apic, maybe enhance qemu64 or move to -cpu host?
>>>
>>> Alex posted a patch for this. I'm planning on merging it although so far
>>> no one has chimed up either way.
>>>
>>>> - aio=native|threads (auto-sense?)
>>>
>>> aio=native is unsafe to default because linux-aio is just fubar. It
>>> falls back to synchronous I/O if the underlying filesystem doesn't
>>> support aio. There's no way in userspace to problem if it's actually
>>> supported or not either...
>>
>> Can we test-run this too? Maybe as a separate qemu mode or even binary
>> that given a qemu cmdline, it will try to suggest better parameters?
>>
>>>> - use virtio devices by default
>>>
>>> I don't think this is realistic since appropriately licensed signed
>>> virtio drivers do not exist for Windows. (Please note the phrase
>>> "appropriately licensed signed").
>>
>> What's the percentage of qemu invocation w/ windows guest and a short
>> cmd line? My hunch is that plain short cmdline indicates a developer
>> and probably they'll use linux guest.
>>
>>>
>>>> - more?
>>>>
>>>> Different defaults may be picked automatically when TCG|KVM used.
>>>>
>>>> 2. External hardening configuration file kept in qemu.git
>>>> For non qemu/kvm specific definitions like the io scheduler we
>>>> should maintain a script in our tree that sets/sense the optimal
>>>> settings of the host kernel (maybe similar one for the guest).
>>>
>>> What are "appropriate host settings" and why aren't we suggesting that
>>> distros and/or upstream just set them by default?
>>
>> It's hard to set the right default for a distribution since the same
>> distro should optimize for various usages of the same OS. For example,
>> Fedora has tuned-adm w/ available profiles:
>> - desktop-powersave
>> - server-powersave
>> - enterprise-storage
>> - spindown-disk
>> - laptop-battery-powersave
>> - default
>> - throughput-performance
>> - latency-performance
>> - laptop-ac-powersave
>>
>> We need to keep on recommending the best profile for virtualization,
>> for Fedora I think it either enterprise-storage and maybe
>> throughput-performance.
>>
>> If we have a such a script, it can call the matching tuned profile
>> instead of tweaking every /sys option.
>>
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>>
>>>> HTH,
>>>> Dor
>>>>
>>>
>>>
>>
>>
>

Re: [Qemu-devel] Better qemu/kvm defaults (was Re: [RFC PATCH 0/4] Gang scheduling in CFS)

[Anthony Liguori]

On 01/01/2012 04:16 AM, Dor Laor wrote:
> On 12/29/2011 06:16 PM, Anthony Liguori wrote:
>> On 12/29/2011 10:07 AM, Dor Laor wrote:
>>> On 12/26/2011 11:05 AM, Avi Kivity wrote:
>>>> On 12/26/2011 05:14 AM, Nikunj A Dadhania wrote:
>>>>>>
>>>>>> btw you can get an additional speedup by enabling x2apic, for
>>>>>> default_send_IPI_mask_logical().
>>>>>>
>>>>> In the host?
>>>>>
>>>>
>>>> In the host, for the guest:
>>>>
>>>> qemu -cpu ...,+x2apic
>>>>
>>>
>>> It seems to me that we should improve our default flags.
>>> So many times users fail to submit the proper huge command-line
>>> options that we
>>> require. Honestly, we can't blame them, there are so many flags and so
>>> many use
>>> cases its just too hard to get it right for humans.
>>>
>>> I propose a basic idea and folks are welcome to discuss it:
>>>
>>> 1. Improve qemu/kvm defaults
>>> Break the current backward compatibility (but add a --default-
>>> backward-compat-mode) and set better values for:
>>> - rtc slew time
>>
>> What do you specifically mean?
>
> -rtc localtime,driftfix=slew

We can just set this for pc-1.1.  I don't see any real harm in doing that.

>>> - cache=none
>>
>> I'm not sure I see this as a "better default" particularly since
>> O_DIRECT fails on certain file systems. I think we really need to let
>> WCE be toggable from the guest and then have a caching mode independent
>> of WCE. We then need some heuristics to only enable cache=off when we
>> know it's safe.
>
> cache=none is still faster then it has the FS support.
> qemu can test-run O_DIRECT and fall back to cache mode or just test the
> filesystem capabilities.

I think a safer approach is to white list based on the results from fstat but 
regardless, we need WCE to be toggable first since I'm fairly certain you 
wouldn't want directsync to become the default :-)

>>> - x2apic, maybe enhance qemu64 or move to -cpu host?
>>
>> Alex posted a patch for this. I'm planning on merging it although so far
>> no one has chimed up either way.
>>
>>> - aio=native|threads (auto-sense?)
>>
>> aio=native is unsafe to default because linux-aio is just fubar. It
>> falls back to synchronous I/O if the underlying filesystem doesn't
>> support aio. There's no way in userspace to problem if it's actually
>> supported or not either...
>
> Can we test-run this too?

Nope.  We need a kernel interface that reports aio capabilities.

> Maybe as a separate qemu mode or even binary that
> given a qemu cmdline, it will try to suggest better parameters?

We could potentially whitelist to enable linux-aio where we know it's safe.

>>> - use virtio devices by default
>>
>> I don't think this is realistic since appropriately licensed signed
>> virtio drivers do not exist for Windows. (Please note the phrase
>> "appropriately licensed signed").
>
> What's the percentage of qemu invocation w/ windows guest and a short cmd line?

I'm not really sure.

> My hunch is that plain short cmdline indicates a developer and probably they'll
> use linux guest.

I've thought about how we could fix this and what I've come up with in the past 
is something a little different.

We could enable the guest to choose which type of hardware is presented to it. 
Essentially, qemu -net nic,model=guests-pick

When using 'guests-pick', we initially present the most compatible network model 
(rtl8139, for instance).  We would provide a paravirtual channel (guest-agent?) 
that could be used to enumerate which models were available and let guest decide 
which model to use for the next reboot.  You could also enable immediate switch 
over using hot plug.

>
>>
>>> - more?
>>>
>>> Different defaults may be picked automatically when TCG|KVM used.
>>>
>>> 2. External hardening configuration file kept in qemu.git
>>> For non qemu/kvm specific definitions like the io scheduler we
>>> should maintain a script in our tree that sets/sense the optimal
>>> settings of the host kernel (maybe similar one for the guest).
>>
>> What are "appropriate host settings" and why aren't we suggesting that
>> distros and/or upstream just set them by default?
>
> It's hard to set the right default for a distribution since the same distro
> should optimize for various usages of the same OS. For example, Fedora has
> tuned-adm w/ available profiles:
> - desktop-powersave
> - server-powersave
> - enterprise-storage
> - spindown-disk
> - laptop-battery-powersave
> - default
> - throughput-performance
> - latency-performance
> - laptop-ac-powersave
>
> We need to keep on recommending the best profile for virtualization, for Fedora
> I think it either enterprise-storage and maybe throughput-performance.

I think that's more of a distro.  It might be worth referring to in our 
documentation but I'm not sure it's something we can do much about.

Regards,

Anthony Liguori

>
> If we have a such a script, it can call the matching tuned profile instead of
> tweaking every /sys option.
>
>>
>> Regards,
>>
>> Anthony Liguori
>>
>>> HTH,
>>> Dor
>>>
>>
>>
>
>

Re: [Qemu-devel] Better qemu/kvm defaults (was Re: [RFC PATCH 0/4] Gang scheduling in CFS)

[Dor Laor]

On 01/03/2012 05:48 PM, Anthony Liguori wrote:
> On 01/01/2012 04:16 AM, Dor Laor wrote:
>> On 12/29/2011 06:16 PM, Anthony Liguori wrote:
>>> On 12/29/2011 10:07 AM, Dor Laor wrote:
>>>> On 12/26/2011 11:05 AM, Avi Kivity wrote:
>>>>> On 12/26/2011 05:14 AM, Nikunj A Dadhania wrote:
>>>>>>>
>>>>>>> btw you can get an additional speedup by enabling x2apic, for
>>>>>>> default_send_IPI_mask_logical().
>>>>>>>
>>>>>> In the host?
>>>>>>
>>>>>
>>>>> In the host, for the guest:
>>>>>
>>>>> qemu -cpu ...,+x2apic
>>>>>
>>>>
>>>> It seems to me that we should improve our default flags.
>>>> So many times users fail to submit the proper huge command-line
>>>> options that we
>>>> require. Honestly, we can't blame them, there are so many flags and so
>>>> many use
>>>> cases its just too hard to get it right for humans.
>>>>
>>>> I propose a basic idea and folks are welcome to discuss it:
>>>>
>>>> 1. Improve qemu/kvm defaults
>>>> Break the current backward compatibility (but add a --default-
>>>> backward-compat-mode) and set better values for:
>>>> - rtc slew time
>>>
>>> What do you specifically mean?
>>
>> -rtc localtime,driftfix=slew
>
> We can just set this for pc-1.1. I don't see any real harm in doing that.

Great, it 'only' took about 3 years from the time it got developed 
originally by Uri...

>
>>>> - cache=none
>>>
>>> I'm not sure I see this as a "better default" particularly since
>>> O_DIRECT fails on certain file systems. I think we really need to let
>>> WCE be toggable from the guest and then have a caching mode independent
>>> of WCE. We then need some heuristics to only enable cache=off when we
>>> know it's safe.
>>
>> cache=none is still faster then it has the FS support.
>> qemu can test-run O_DIRECT and fall back to cache mode or just test the
>> filesystem capabilities.
>
> I think a safer approach is to white list based on the results from
> fstat but regardless, we need WCE to be toggable first since I'm fairly
> certain you wouldn't want directsync to become the default :-)
>
>>>> - x2apic, maybe enhance qemu64 or move to -cpu host?
>>>
>>> Alex posted a patch for this. I'm planning on merging it although so far
>>> no one has chimed up either way.
>>>
>>>> - aio=native|threads (auto-sense?)
>>>
>>> aio=native is unsafe to default because linux-aio is just fubar. It
>>> falls back to synchronous I/O if the underlying filesystem doesn't
>>> support aio. There's no way in userspace to problem if it's actually
>>> supported or not either...
>>
>> Can we test-run this too?
>
> Nope. We need a kernel interface that reports aio capabilities.

That's nasty, maybe Paolo will be able to cover it on one of his block 
crusades

>
>> Maybe as a separate qemu mode or even binary that
>> given a qemu cmdline, it will try to suggest better parameters?
>
> We could potentially whitelist to enable linux-aio where we know it's safe.
>
>>>> - use virtio devices by default
>>>
>>> I don't think this is realistic since appropriately licensed signed
>>> virtio drivers do not exist for Windows. (Please note the phrase
>>> "appropriately licensed signed").
>>
>> What's the percentage of qemu invocation w/ windows guest and a short
>> cmd line?
>
> I'm not really sure.
>
>> My hunch is that plain short cmdline indicates a developer and
>> probably they'll
>> use linux guest.
>
> I've thought about how we could fix this and what I've come up with in
> the past is something a little different.
>
> We could enable the guest to choose which type of hardware is presented
> to it. Essentially, qemu -net nic,model=guests-pick
>
> When using 'guests-pick', we initially present the most compatible
> network model (rtl8139, for instance). We would provide a paravirtual
> channel (guest-agent?) that could be used to enumerate which models were
> available and let guest decide which model to use for the next reboot.
> You could also enable immediate switch over using hot plug.

If guest uses an agent, it probably has virtio-serial driver and it 
indicates it has other virtio ones, otherwise, the agent won't fly

>
>>
>>>
>>>> - more?
>>>>
>>>> Different defaults may be picked automatically when TCG|KVM used.
>>>>
>>>> 2. External hardening configuration file kept in qemu.git
>>>> For non qemu/kvm specific definitions like the io scheduler we
>>>> should maintain a script in our tree that sets/sense the optimal
>>>> settings of the host kernel (maybe similar one for the guest).
>>>
>>> What are "appropriate host settings" and why aren't we suggesting that
>>> distros and/or upstream just set them by default?
>>
>> It's hard to set the right default for a distribution since the same
>> distro
>> should optimize for various usages of the same OS. For example, Fedora
>> has
>> tuned-adm w/ available profiles:
>> - desktop-powersave
>> - server-powersave
>> - enterprise-storage
>> - spindown-disk
>> - laptop-battery-powersave
>> - default
>> - throughput-performance
>> - latency-performance
>> - laptop-ac-powersave
>>
>> We need to keep on recommending the best profile for virtualization,
>> for Fedora
>> I think it either enterprise-storage and maybe throughput-performance.
>
> I think that's more of a distro. It might be worth referring to in our
> documentation but I'm not sure it's something we can do much about.

Someone said on the kvm community call today: "no one reads 
documentation", so it better be a script. As noted about we do have it 
in my favorite distribution, I hoped all distributions gets it.


> Regards,
>
> Anthony Liguori
>
>>
>> If we have a such a script, it can call the matching tuned profile
>> instead of
>> tweaking every /sys option.
>>
>>>
>>> Regards,
>>>
>>> Anthony Liguori
>>>
>>>> HTH,
>>>> Dor
>>>>
>>>
>>>
>>
>>
>

Re: [Qemu-devel] Better qemu/kvm defaults (was Re: [RFC PATCH 0/4] Gang scheduling in CFS)

[Anthony Liguori]

On 01/03/2012 04:31 PM, Dor Laor wrote:
>> We can just set this for pc-1.1. I don't see any real harm in doing that.
>
> Great, it 'only' took about 3 years from the time it got developed originally by
> Uri...

Someone just needs to send a patch.

>> When using 'guests-pick', we initially present the most compatible
>> network model (rtl8139, for instance). We would provide a paravirtual
>> channel (guest-agent?) that could be used to enumerate which models were
>> available and let guest decide which model to use for the next reboot.
>> You could also enable immediate switch over using hot plug.
>
> If guest uses an agent, it probably has virtio-serial driver and it indicates it
> has other virtio ones, otherwise, the agent won't fly

Right, but I still you want the ability for the guest to indicate that it would 
like to use virtio drivers or not.

If you think about it, it makes no sense to choose which type of device gets 
used in the hypervisor.  In an ideal world, the guest would just figure out what 
it wants to see and get that.

The same is probably true about most device model properties.  rtc clock slew 
policy is another good example.  Instead of trying to figure out what the guest 
type is, we should just let the guest request device model settings like that.

>>> We need to keep on recommending the best profile for virtualization,
>>> for Fedora
>>> I think it either enterprise-storage and maybe throughput-performance.
>>
>> I think that's more of a distro. It might be worth referring to in our
>> documentation but I'm not sure it's something we can do much about.
>
> Someone said on the kvm community call today: "no one reads documentation", so
> it better be a script. As noted about we do have it in my favorite distribution,
> I hoped all distributions gets it.

Indeed, "referring to it in our documentation" was a polite way of saying, it's 
a distro problem :-)

The distro should let you choose a profile during installation or something like 
that.

Regards,

Anthony Liguori

>
>
>> Regards,
>>
>> Anthony Liguori
>>
>>>
>>> If we have a such a script, it can call the matching tuned profile
>>> instead of
>>> tweaking every /sys option.
>>>
>>>>
>>>> Regards,
>>>>
>>>> Anthony Liguori
>>>>
>>>>> HTH,
>>>>> Dor
>>>>>
>>>>
>>>>
>>>
>>>
>>
>
>

Re: [Qemu-devel] Better qemu/kvm defaults (was Re: [RFC PATCH 0/4] Gang scheduling in CFS)

[Dor Laor]

On 01/04/2012 12:45 AM, Anthony Liguori wrote:
>
>>> When using 'guests-pick', we initially present the most compatible
>>> network model (rtl8139, for instance). We would provide a paravirtual
>>> channel (guest-agent?) that could be used to enumerate which models were
>>> available and let guest decide which model to use for the next reboot.
>>> You could also enable immediate switch over using hot plug.
>>
>> If guest uses an agent, it probably has virtio-serial driver and it
>> indicates it
>> has other virtio ones, otherwise, the agent won't fly
>
> Right, but I still you want the ability for the guest to indicate that
> it would like to use virtio drivers or not.

It would probably require a PCI 4.0 edition...

> If you think about it, it makes no sense to choose which type of device
> gets used in the hypervisor.  In an ideal world, the guest would just
> figure out what it wants to see and get that.
>
> The same is probably true about most device model properties.  rtc clock
> slew policy is another good example.  Instead of trying to figure out
> what the guest type is, we should just let the guest request device
> model settings like that.

The poor guest only wanted to have a real time clock that works w/ fine 
grain time stamps. It was x86 vendors w/ the help of few programmers who 
kept addition various ideas like tsc, hpet, constant_tsc, non stop tsc, 
really really non stop tsc + timer,...

Cheers,
Dor