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

[Markus Armbruster]

Andreas Färber <address@hidden> writes:

> Am 16.10.2013 12:00, schrieb Markus Armbruster:
>> 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.
>
> I understood Anthony as describing expected hardware behavior.
>
> At least with the old ioport API registering a port twice used to abort.

If I add a second piix3-ide controller in the "wrong" order, the BIOS
attempts to boot from the wrong one, and fails.

If I add it in the other order, Linux starts booting, but fails to pivot
the root device, and drops me in an emergency shell.  I can see both
controllers in /sys/devices/ there.

Unfortunately, I don't have time today to figure out how to make the
second controller work.

Good enough to drop cannot_instantiate_with_device_add_yet?