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

["Andreas Färber" <afaerber@suse.de>]

Am 16.10.2013 12:00, schrieb Markus Armbruster:
> Anthony Liguori <anthony@codemonkey.ws> writes:
> 
>> On Tue, Oct 15, 2013 at 7:41 AM, Kevin Wolf <kwolf@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