From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43700) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VW4j0-0001vf-Bc for qemu-devel@nongnu.org; Tue, 15 Oct 2013 09:31:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VW4is-0005o8-TP for qemu-devel@nongnu.org; Tue, 15 Oct 2013 09:31:50 -0400 Received: from cantor2.suse.de ([195.135.220.15]:47222 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VW4is-0005o2-Kr for qemu-devel@nongnu.org; Tue, 15 Oct 2013 09:31:42 -0400 Message-ID: <525D43BB.2010503@suse.de> Date: Tue, 15 Oct 2013 15:31:39 +0200 From: =?ISO-8859-15?Q?Andreas_F=E4rber?= MIME-Version: 1.0 References: <1381416174-5110-1-git-send-email-armbru@redhat.com> <87fvs2hdpu.fsf@blackfin.pond.sub.org> In-Reply-To: <87fvs2hdpu.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Which functions of southbridges should be no-user? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Markus Armbruster , qemu-devel@nongnu.org Cc: Kevin Wolf , Peter Maydell , Anthony Liguori Am 15.10.2013 15:21, schrieb Markus Armbruster: > Andreas, >=20 > To go beyond RFC with this series, I need to explain why the IDE > controller functions of southbridges piix3-ide, piix3-ide-xen, piix4-id= e > and via-ide cannot_instantiate_with_device_add_yet, or drop that. I'd > appreciate your help. >=20 > Our modelling of PCI devices is weird, to put it politely. One of many > weird things is that we don't distinguish between a function and a > complete device: our "function models" are actually PCI device models, > and can be used as such, even though they only exist as functions of a > multifunction device in the real world. We permit collecting aribitrar= y > PCI devices into multifunction devices. >=20 > One instance of multifunction PCI devices are southbridges. For > example, the ICH9 southbridge's PCI device 00:1F consists of ISA bridge > ("ICH9 LPC"), IDE controller ("ich9-ahci"), SMB controller ("ICH9 SMB")= , > and Thermal Subsystem (which we don't implement). The PIIX3 southbridg= e > consists of ISA bridge ("PIIX3", IDE controller ("piix3-ide"), USB > controller ("piix3-usb-uhci", can be suppressed), and SMB controller > ("PIIX4_PM", can be suppressed). >=20 > Some functions of southbridges still need to be wired up in code ("ICH9 > LPC", "ICH9 SMB", "PIIX4_PM", "PIIX4", "PIIX3", "PIIX3-xen", see PATCH > 5-6/9), thus cannot_instantiate_with_device_add_yet. >=20 > The IDE controller functions have always been > cannot_instantiate_with_device_add_yet, but it's not obvious to me why. >=20 > The other functions are available with device-add. Users device-add'in= g > them would of course be odd, but if it works... I don't actually know > whether it works for all of them. >=20 > Should all southbridge functions be made unavailable with device-add fo= r > consistency, at least for now? >=20 > Or should all functions be made available, except for the ones that > cannot possibly work with device-add? >=20 > If the latter, can you think of any specific reason why the IDE > controllers couldn't work? I would've thought you and Kevin know more about IDE than me. ;) No idea why it is how it is. Two aspects: 1) PCI devices/functions can technically be hotplugged. 2) Drivers might not expect such devices to be hot-added/removed. I would tend for the latter proposal. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=FCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=F6rffer; HRB 16746 AG N=FCrnbe= rg