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.
