From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:56205) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMhZO-0000pK-4s for qemu-devel@nongnu.org; Fri, 12 Oct 2012 11:54:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TMhZM-00018B-Vw for qemu-devel@nongnu.org; Fri, 12 Oct 2012 11:54:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37336) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TMhZM-000183-NR for qemu-devel@nongnu.org; Fri, 12 Oct 2012 11:54:36 -0400 Date: Fri, 12 Oct 2012 11:00:08 -0400 From: Jason Baron Message-ID: <20121012150008.GL3592@redhat.com> References: <20121011105705.GE5552@redhat.com> <20121011142122.GH3592@redhat.com> <20121011144656.GF8983@redhat.com> <20121011153408.GI3592@redhat.com> <5077C646.3070007@redhat.com> <20121012093937.GB32014@redhat.com> <5077EBB4.80304@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5077EBB4.80304@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 21/21] q35: add acpi-based pci hotplug. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: aliguori@us.ibm.com, juzhang@redhat.com, "Michael S. Tsirkin" , jan.kiszka@siemens.com, qemu-devel@nongnu.org, agraf@suse.de, blauwirbel@gmail.com, yamahata@valinux.co.jp, alex.williamson@redhat.com, kevin@koconnor.net, avi@redhat.com, mkletzan@redhat.com, pbonzini@redhat.com, lcapitulino@redhat.com, afaerber@suse.de, armbru@redhat.com On Fri, Oct 12, 2012 at 12:06:44PM +0200, Gerd Hoffmann wrote: > Hi, > > >>> I just tried out getting rid of the bridges by default. > >> > >> That clearly raises the question which devices should be created > >> automatically by -M q35. I think the devices which are part of the ich9 > >> chipset should be there by default. /me looks at my laptop which > >> happens to have a ich9 chipset. > > > > The reason this is a bad idea is very simple: we only have a way to add > > devices not to remove them. So if you miss a device which your guest > > needs, it is easy to add, but there is no way to remove. > > Why would you want remove devices? They don't harm when present. And > you can't remove them on real hardware either. Try ordering a ich9 > without sound or usb ;) > > >> Real ich9 has the e1000 @ 00:19.0, so it would make sense to place one > >> there. Adding a default nic will probably create some headache though, > >> so maybe better don't. > > > > And that's just one example. > > It is problematic because the nic needs configuration and configuring a > builtin device is tricky. Also our e1000 model isn't the ich9 one. > > Most other chipset devices are not problematic at all as they are just > controllers where you can attach stuff to (and by default there isn't > anything attached). This includes: > > * pcie ports (waiting for pcie devices plugged in). > * ahci controller (waiting for disks/cdroms being attached). > * intel-hda (waiting for audio coded (hda-*) being attached). > * ehci+uhci (waiting for usb devices being plugged in). > > The stuff being attached/plugged there needs configuration, but not the > controllers themself. > > > Fact is, we don't emulate real hardware exactly. > > But we try to. > > > So let's have a minimal machine and if you want to add e1000 audio etc, > > you can do this. We can even teach management to do it with friendly > > UI as opposed to cryptic machine types. > > /me disagrees. > What if we have a 'basic' configuration as Michael suggests, but have an easy way to specify that we want these additional built-in controllers/bridges at their default slot. For example, for q35 I can currently pass '-usb' and it will create a uhci at slot 1d func 0. (I have small patch to add ehci as well). Not sure if we have appropriate options we can piggy-back on for default sound and bridges, but we can add these later, if this makese sense. Thanks, -Jason