From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57150) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiDL7-0007tH-3Q for qemu-devel@nongnu.org; Tue, 03 Jan 2012 18:00:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RiDL5-0005X9-Uj for qemu-devel@nongnu.org; Tue, 03 Jan 2012 18:00:17 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55036) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RiDL5-0005X4-Ix for qemu-devel@nongnu.org; Tue, 03 Jan 2012 18:00:15 -0500 Message-ID: <4F038866.1060705@redhat.com> Date: Wed, 04 Jan 2012 00:59:50 +0200 From: Dor Laor MIME-Version: 1.0 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> In-Reply-To: <4F0384FF.8070207@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Better qemu/kvm defaults (was Re: [RFC PATCH 0/4] Gang scheduling in CFS) Reply-To: dlaor@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel , Paolo Bonzini , Avi Kivity , Nikunj A Dadhania , kvm-devel 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