Re: [Qemu-devel] Which functions of southbridges should be no-user?

[Markus Armbruster]

Anthony Liguori <address@hidden> writes:

> On Wed, Oct 16, 2013 at 3:00 AM, Markus Armbruster <address@hidden> wrote:
>> Anthony Liguori <address@hidden> writes:
>>
>>> On Tue, Oct 15, 2013 at 7:41 AM, Kevin Wolf <address@hidden> 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.
>
> No, I don't object.  As Andreas points out, we may have problems today
> if you try to add two IDE controllers but those are bugs that should
> be fixed.

The mission of cannot_instantiate_with_device_add_yet is protecting
users from device-adds that cannot possibly work.  So, *if* these
devices actually have bugs that are so severe that device-add becomes
effectively useless, then we should keep
cannot_instantiate_with_device_add_yet for now.  But that's detail.

In my very limited testing, I wasn't able to get a system with two
piix3-ide to boot, but it didn't look flat out impossible.  See my reply
to Andreas.

> It used to be possible to buy secondary PCI IDE controllers to add
> more than 4 disks.  You could only access them with proper drivers (so
> you couldn't boot from the 5th disk) but otherwise it worked.

Yes, but these IDE boards didn't identify as intel 82371SB.  For what
it's worth, we have an IDE controller device that isn't a southbridge
function: cmd646-ide.