Am 16.10.2013 12:00, schrieb Markus Armbruster: > Anthony Liguori <anth...@codemonkey.ws> writes: > >> On Tue, Oct 15, 2013 at 7:41 AM, Kevin Wolf <kw...@redhat.com> wrote: >>> Am 15.10.2013 um 15:31 hat Andreas Färber 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, piix4-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 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 aribitrary >>>>> 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 bridge >>>>> ("ICH9 LPC"), IDE controller ("ich9-ahci"), SMB controller ("ICH9 SMB"), >>>>> and Thermal Subsystem (which we don't implement). The PIIX3 southbridge >>>>> 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). >>>>> >>>>> 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. >>>>> >>>>> 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-add'ing >>>>> them would of course be odd, but if it works... I don't actually know >>>>> whether it works for all of them. >>>>> >>>>> Should all southbridge functions be made unavailable with device-add 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 provides >>> 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 Busmaster >>> 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 work, >>> 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 one of >> them. > > 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 -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg