Re: [Qemu-devel] Which functions of southbridges should be no-user?
Anthony Liguori writes:
> On Wed, Oct 16, 2013 at 3:00 AM, Markus Armbruster wrote:
>> Anthony Liguori writes:
>>
>>> On Tue, Oct 15, 2013 at 7:41 AM, Kevin Wolf 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 ID
Re: [Qemu-devel] Which functions of southbridges should be no-user?
Andreas Färber writes:
> Am 16.10.2013 12:00, schrieb Markus Armbruster:
>> Anthony Liguori writes:
>>
>>> On Tue, Oct 15, 2013 at 7:41 AM, Kevin Wolf 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?
Re: [Qemu-devel] Which functions of southbridges should be no-user?
On Wed, Oct 16, 2013 at 3:00 AM, Markus Armbruster wrote:
> Anthony Liguori writes:
>
>> On Tue, Oct 15, 2013 at 7:41 AM, Kevin Wolf 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.
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.
Regards,
Anthony Liguori
Re: [Qemu-devel] Which functions of southbridges should be no-user?
Am 16.10.2013 12:00, schrieb Markus Armbruster:
> Anthony Liguori writes:
>
>> On Tue, Oct 15, 2013 at 7:41 AM, Kevin Wolf 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
Re: [Qemu-devel] Which functions of southbridges should be no-user?
Anthony Liguori writes:
> On Tue, Oct 15, 2013 at 7:41 AM, Kevin Wolf 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.
Re: [Qemu-devel] Which functions of southbridges should be no-user?
Andreas Färber writes: > Am 15.10.2013 16:41, schrieb Kevin Wolf: >> 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. > > Or a new can_only_be_instantiated_once flag. :) > Or proper error handling to have it fail gracefully at least. can_only_be_instantiated_once helps users only in special cases of the general resource conflict problem. Proper handling of resource conflicts helps them always.
Re: [Qemu-devel] Which functions of southbridges should be no-user?
On Tue, Oct 15, 2013 at 7:41 AM, Kevin Wolf 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.
Regards,
Anthony Liguori
> Kevin
>
Re: [Qemu-devel] Which functions of southbridges should be no-user?
Am 15.10.2013 16:41, schrieb Kevin Wolf: > 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. Or a new can_only_be_instantiated_once flag. :) Or proper error handling to have it fail gracefully at least. Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] Which functions of southbridges should be no-user?
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. 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?
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.
Kevin
Re: [Qemu-devel] Which functions of southbridges should be no-user?
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.
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] Which functions of southbridges should be no-user? (was: [PATCH RFC 0/9] Clean up and fix no_user)
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?
