From: "Andreas Färber" <afaerber@suse.de>
To: Markus Armbruster <armbru@redhat.com>, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
Peter Maydell <peter.maydell@linaro.org>,
Anthony Liguori <aliguori@amazon.com>
Subject: Re: [Qemu-devel] Which functions of southbridges should be no-user?
Date: Tue, 15 Oct 2013 15:31:39 +0200 [thread overview]
Message-ID: <525D43BB.2010503@suse.de> (raw)
In-Reply-To: <87fvs2hdpu.fsf@blackfin.pond.sub.org>
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
next prev parent reply other threads:[~2013-10-15 13:31 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-10 14:42 [Qemu-devel] [PATCH RFC 0/9] Clean up and fix no_user armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 1/9] qdev: Replace no_user by cannot_instantiate_with_device_add_yet armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 2/9] sysbus: Set cannot_instantiate_with_device_add_yet armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 3/9] apic: Document why cannot_instantiate_with_device_add_yet armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 4/9] pci-host: Consistently set cannot_instantiate_with_device_add_yet armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 5/9] ich9: Document why cannot_instantiate_with_device_add_yet armbru
2013-10-10 16:01 ` Paolo Bonzini
2013-10-10 16:03 ` Paolo Bonzini
2013-10-11 6:13 ` Markus Armbruster
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 6/9] piix3 piix4: " armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 7/9] vt82c686: " armbru
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 8/9] isa: Clean up use of cannot_instantiate_with_device_add_yet armbru
2013-10-15 12:43 ` [Qemu-devel] Should the i8259 devices remain no-user? (was: [PATCH RFC 8/9] isa: Clean up use of cannot_instantiate_with_device_add_yet) Markus Armbruster
2013-10-15 12:54 ` [Qemu-devel] Should the i8259 devices remain no-user? Paolo Bonzini
2013-10-16 9:51 ` Markus Armbruster
2013-10-16 11:06 ` Paolo Bonzini
2013-10-16 16:12 ` Markus Armbruster
2013-10-16 16:21 ` BALATON Zoltan
2013-10-16 16:23 ` Paolo Bonzini
2013-10-26 20:00 ` [Qemu-devel] fix clearing i8259 IRQ lines (Was: Should the i8259 devices remain no-user?) Matthew Ogilvie
2013-10-29 16:27 ` BALATON Zoltan
2013-10-10 14:42 ` [Qemu-devel] [PATCH RFC 9/9] qdev: Do not let the user try to device_add when it cannot work armbru
2013-10-15 12:24 ` [Qemu-devel] Why is TYPE_CPU no-user? (was: [PATCH RFC 0/9] Clean up and fix no_user) Markus Armbruster
2013-10-15 12:37 ` Peter Maydell
2013-10-15 14:01 ` [Qemu-devel] Why is TYPE_CPU no-user? Markus Armbruster
2013-10-15 13:08 ` Andreas Färber
2013-10-16 9:55 ` Markus Armbruster
2013-10-15 13:21 ` [Qemu-devel] Which functions of southbridges should be no-user? (was: [PATCH RFC 0/9] Clean up and fix no_user) Markus Armbruster
2013-10-15 13:31 ` Andreas Färber [this message]
2013-10-15 14:41 ` [Qemu-devel] Which functions of southbridges should be no-user? Kevin Wolf
2013-10-15 14:53 ` Andreas Färber
2013-10-16 9:58 ` Markus Armbruster
2013-10-15 15:09 ` Anthony Liguori
2013-10-16 10:00 ` Markus Armbruster
2013-10-16 11:02 ` Andreas Färber
2013-10-17 9:47 ` Markus Armbruster
2013-10-16 17:53 ` Anthony Liguori
2013-10-17 9:49 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=525D43BB.2010503@suse.de \
--to=afaerber@suse.de \
--cc=aliguori@amazon.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.