From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58494) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VWOsR-0005Lk-G0 for qemu-devel@nongnu.org; Wed, 16 Oct 2013 07:03:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VWOsL-0003Jn-Qn for qemu-devel@nongnu.org; Wed, 16 Oct 2013 07:02:55 -0400 Received: from cantor2.suse.de ([195.135.220.15]:57918 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VWOsL-0003Ja-HU for qemu-devel@nongnu.org; Wed, 16 Oct 2013 07:02:49 -0400 Message-ID: <525E7254.2070705@suse.de> Date: Wed, 16 Oct 2013 13:02:44 +0200 From: =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= MIME-Version: 1.0 References: <1381416174-5110-1-git-send-email-armbru@redhat.com> <87fvs2hdpu.fsf@blackfin.pond.sub.org> <525D43BB.2010503@suse.de> <20131015144103.GF3039@dhcp-200-207.str.redhat.com> <87eh7lsfh7.fsf@blackfin.pond.sub.org> In-Reply-To: <87eh7lsfh7.fsf@blackfin.pond.sub.org> Content-Type: text/plain; charset=UTF-8 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 , Anthony Liguori Cc: Kevin Wolf , Peter Maydell , qemu-devel , Anthony Liguori Am 16.10.2013 12:00, schrieb Markus Armbruster: > Anthony Liguori writes: >=20 >> On Tue, Oct 15, 2013 at 7:41 AM, Kevin Wolf wrote: >>> Am 15.10.2013 um 15:31 hat Andreas F=C3=A4rber geschrieben: >>>> Am 15.10.2013 15:21, schrieb Markus Armbruster: >>>>> Andreas, >>>>> >>>>> To go beyond RFC with this series, I need to explain why the IDE >>>>> controller functions of southbridges piix3-ide, piix3-ide-xen, piix= 4-ide >>>>> and via-ide cannot_instantiate_with_device_add_yet, or drop that. = I'd >>>>> appreciate your help. >>>>> >>>>> 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 mode= ls, >>>>> and can be used as such, even though they only exist as functions o= f a >>>>> multifunction device in the real world. We permit collecting aribi= trary >>>>> PCI devices into multifunction devices. >>>>> >>>>> One instance of multifunction PCI devices are southbridges. For >>>>> example, the ICH9 southbridge's PCI device 00:1F consists of ISA br= idge >>>>> ("ICH9 LPC"), IDE controller ("ich9-ahci"), SMB controller ("ICH9 S= MB"), >>>>> and Thermal Subsystem (which we don't implement). The PIIX3 southb= ridge >>>>> consists of ISA bridge ("PIIX3", IDE controller ("piix3-ide"), USB >>>>> controller ("piix3-usb-uhci", can be suppressed), and SMB controlle= r >>>>> ("PIIX4_PM", can be suppressed). >>>>> >>>>> Some functions of southbridges still need to be wired up in code ("= ICH9 >>>>> LPC", "ICH9 SMB", "PIIX4_PM", "PIIX4", "PIIX3", "PIIX3-xen", see PA= TCH >>>>> 5-6/9), thus cannot_instantiate_with_device_add_yet. >>>>> >>>>> The IDE controller functions have always been >>>>> cannot_instantiate_with_device_add_yet, but it's not obvious to me = why. >>>>> >>>>> The other functions are available with device-add. Users device-ad= d'ing >>>>> them would of course be odd, but if it works... I don't actually k= now >>>>> whether it works for all of them. >>>>> >>>>> Should all southbridge functions be made unavailable with device-ad= d for >>>>> consistency, at least for now? >>>>> >>>>> Or should all functions be made available, except for the ones that >>>>> cannot possibly work with device-add? >>>>> >>>>> 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. >>> >>> I'm not sure how IDE hardware really works, but I don't think you can >>> handle it as a pure PCI device. On PCs, the IDE controller still prov= ides >>> the good old IDE registers on the I/O ports that were already used in >>> ISA times, and they are not described in any BARs, for example. >> >> Legacy IDE and VGA accesses are positively decoded in the i440fx and >> dispatched to the first PCI device with the appropriate class code. >> >>> From a >>> software point of view, the PCI device is just for configuring Busmas= ter >>> DMA. Perhaps in reality it should be two devices, one for DMA on the = PCI >>> bus and another one for the core on sysbus or ISA? >> >> It's definitely all a PCI device. It could realistically be a >> discrete device too that's plugged into a PCI bus that lacks a super >> I/O chipset. >> >>> >>> Anyway, having two IDE controllers using the same I/O ports won't wor= k, >>> obviously. So if you would allow -device or device-add for them, you'= d >>> need options to configure the ports at least. >> >> It's allowed but the PCI bus will only route the legacy requests to on= e of them. >=20 > Any objections to dropping cannot_instantiate_with_device_add_yet from > all IDE controller southbridge functions? These are: piix3-ide, > piix3-ide-xen, piix4-ide and via-ide. I understood Anthony as describing expected hardware behavior. At least with the old ioport API registering a port twice used to abort. Andreas --=20 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N=C3=BCrnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imend=C3=B6rffer; HRB 16746 AG N=C3=BC= rnberg