From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dor Laor Subject: Re: [Qemu-devel] Better qemu/kvm defaults (was Re: [RFC PATCH 0/4] Gang scheduling in CFS) Date: Wed, 04 Jan 2012 00:59:50 +0200 Message-ID: <4F038866.1060705@redhat.com> References: <20111219083141.32311.9429.stgit@abhimanyu.in.ibm.com> <20111219112326.GA15090@elte.hu> <87sjke1a53.fsf@abhimanyu.in.ibm.com> <4EF1B85F.7060105@redhat.com> <877h1o9dp7.fsf@linux.vnet.ibm.com> <20111223103620.GD4749@elte.hu> <4EF701C7.9080907@redhat.com> <87vcp4t45p.fsf@linux.vnet.ibm.com> <4EF838BD.60406@redhat.com> <4EFC903C.3030509@redhat.com> <4EFC9277.9040604@codemonkey.ws> <4F003268.90906@redhat.com> <4F032363.5000700@codemonkey.ws> <4F0381CF.30204@redhat.com> <4F0384FF.8070207@codemonkey.ws> Reply-To: dlaor@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Paolo Bonzini , Avi Kivity , Nikunj A Dadhania , kvm-devel , qemu-devel To: Anthony Liguori Return-path: Received: from mx1.redhat.com ([209.132.183.28]:61206 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751581Ab2ACXAQ (ORCPT ); Tue, 3 Jan 2012 18:00:16 -0500 In-Reply-To: <4F0384FF.8070207@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: 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