From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MxcO3-00009P-Kn for qemu-devel@nongnu.org; Tue, 13 Oct 2009 04:05:39 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MxcNz-0008PM-0X for qemu-devel@nongnu.org; Tue, 13 Oct 2009 04:05:39 -0400 Received: from [199.232.76.173] (port=56737 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MxcNy-0008PB-Tp for qemu-devel@nongnu.org; Tue, 13 Oct 2009 04:05:34 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56112) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MxcNx-0003q4-OM for qemu-devel@nongnu.org; Tue, 13 Oct 2009 04:05:34 -0400 Message-ID: <4AD434BB.1080102@redhat.com> Date: Tue, 13 Oct 2009 10:05:15 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH v2 9/9] Add -kvm option References: <1254953315-5761-2-git-send-email-glommer@redhat.com> <1254953315-5761-3-git-send-email-glommer@redhat.com> <1254953315-5761-4-git-send-email-glommer@redhat.com> <1254953315-5761-5-git-send-email-glommer@redhat.com> <1254953315-5761-6-git-send-email-glommer@redhat.com> <1254953315-5761-7-git-send-email-glommer@redhat.com> <1254953315-5761-8-git-send-email-glommer@redhat.com> <1254953315-5761-9-git-send-email-glommer@redhat.com> <1254953315-5761-10-git-send-email-glommer@redhat.com> <4ACD1D92.8080607@us.ibm.com> <20091007231405.GQ8092@mothafucka.localdomain> <4ACD2414.9000401@codemonkey.ws> <4AD319F6.70506@redhat.com> <4AD33774.1030001@us.ibm.com> <4AD34C75.8090803@redhat.com> <4AD359E6.50108@us.ibm.com> In-Reply-To: <4AD359E6.50108@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Glauber Costa , qemu-devel@nongnu.org On 10/12/09 18:31, Anthony Liguori wrote: > Gerd Hoffmann wrote: >> On 10/12/09 16:04, Anthony Liguori wrote: >>> Gerd Hoffmann wrote: >>>> -M $machine gives you a barebone machine with all core devices which >>>> belong to it. You can't easily remove and/or replace devices. >>>> Especially not something central as the IRQ controller. But also no >>>> other core components, i.e. you wouldn't stick a piix4 ide controller >>>> into a Q35 machine. Just say 'no'. >>> >>> This seems fundamentally flawed to me. If you cannot remove a device >>> from a machine using command line options, then how do we support >>> something like -net none? >> >> '-net none' does not remove a nic. It makes qemu not add the default nic. > > qemu should not have the concept of a default nic. Well, right now it has (likewise for serial, vga, ...). And it causes problems with the qdev way of managing devices, so we have to find a way to deal with it. Right now the default devices are tied to a command line switch, i.e. in case there isn't a -serial switch specified qemu will add a default serial device, even in case one was added via -device isa-serial. > Instead, if you > choose the pc machine type, by default you get an e1000. I think it's > also reasonable to get a USB controller too along with the balloon > driver and anything else we think a user could benefit from. Hmm. It makes sense to have a usable default or example configuration. I don't think the machine type should be that though. IMO the machine type should be more like a chipset, i.e. the current pc type should include all core stuff (pit, pic, apic, rtc, ...) and the piix devices (host bridge, isa bridge, apci controller, ide controller, usb controller) but nothing else. > If you give devices well known ids, then changing a default device is > not really that big of a deal. It involves removing the device and > adding a new device with that same device id. Might be workable for anything added via -device, because you could do the operations in QemuOpts space, before actually creating qdev device instances. And the user could switch the nic type via '-set device.defaultnic.driver=rtl8139' then. I still don't like the concept though. Configuring a second nic would be different from configuring the first nic, because for the first you'll modify the default device, the second is added instead. libvirt folks will hate us for doing this. > For platform devices, like the interrupt controller/pic, the same > principle could be applied to switch out a userspace irqchip/pit with > the kvm kernel implementations. Doesn't fly. You can't simply add interrupt controllers via -device. They are tied way to much with the other core devices. cheers, Gerd