All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: Markus Armbruster <armbru@redhat.com>
Cc: "Alexander Graf" <agraf@suse.de>,
	qemu-ppc@nongnu.org, qemu-devel@nongnu.org,
	"Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [PATCH] spapr-pci: enable adding PHB via -device
Date: Tue, 21 Jan 2014 21:00:25 +1100	[thread overview]
Message-ID: <52DE4539.9080502@ozlabs.ru> (raw)
In-Reply-To: <87k3dtzs2v.fsf@blackfin.pond.sub.org>

On 01/21/2014 06:56 PM, Markus Armbruster wrote:
> Alexey Kardashevskiy <aik@ozlabs.ru> writes:
> 
>> On 01/21/2014 02:27 AM, Markus Armbruster wrote:
>>> Alexey Kardashevskiy <aik@ozlabs.ru> writes:
>>>
>>>> Recent changes introduced cannot_instantiate_with_device_add_yet
>>>> and removed capability of adding yet another PCI host bridge via
>>>> command line for SPAPR platform (POWERPC64 server).
>>>
>>> Specifically:
>>>
>>> commit 837d37167dc446af8a91189108b363c04609e296
>>> Author: Markus Armbruster <armbru@redhat.com>
>>> Date:   Thu Nov 28 17:26:55 2013 +0100
>>>
>>>     sysbus: Set cannot_instantiate_with_device_add_yet
>>>     
>>>     device_add plugs devices into suitable bus.  For "real" buses, that
>>>     actually connects the device.  For sysbus, the connections need to be
>>>     made separately, and device_add can't do that.  The device would be
>>>     left unconnected, and could not possibly work.
>>>     
>>>     Quite a few, but not all sysbus devices already set
>>>     cannot_instantiate_with_device_add_yet in their class init function.
>>>     
>>>     Set it in their abstract base's class init function
>>>     sysbus_device_class_init(), and remove the now redundant assignments
>>>     from device class init functions.
>>>     
>>>     Signed-off-by: Markus Armbruster <armbru@redhat.com>
>>>     Reviewed-by: Marcel Apfelbaum <marcel.a@redhat.com>
>>>     Signed-off-by: Andreas Färber <afaerber@suse.de>
>>>
>>> Always good to point to specific commits in commit messages instead of
>>> hand-waving "recent changes".
>>
>>
>> My bad, I'll do this next time. Just lost myself in that patch series.
>>
>>
>>>> This brings the capability back and puts SPAPR PHB into "bridge"
>>>> category.
>>>
>>> Look, a sysbus device that grabs the resources it needs from its init()
>>> callback instead of getting connected to them by the code that creates
>>> it!  I'm not sure that's proper, but if it works...  Maybe Andreas
>>> (cc'ed) can advise.
>>
>> Sorry, I am not following you. SPAPR PHB allocates resources (memory
>> regions...) as (for example) E1000 ethernet device does.
> 
> "Resources" was a poor choice of word.
> 
> I'm talking about connections to other devices.  An ordinary device on a
> proper bus like PCI or USB gets all its connections via its bus.  The
> "sysbus" doesn't provide any connection opportunities for its devices.
> Instead, the connections are made by the code creating the device.
> 
> You tell me "-device spapr-pci-host-bridge" works (with your patch).
> That either means it doesn't need any such connections, or it sets them
> up itself somehow, or I'm missing something.  The first two would be
> unusual, the latter not so much :)


It maps itself (MMIO/IO windows) into the guest physical RAM at some
predefined addresses which are calculated from its @index property, and
that is pretty much it. I am not sure what else connections it might ever
need :) The rest is done via platform hyper- or rtas-calls, and this is
that connection I guess.



-- 
Alexey

  reply	other threads:[~2014-01-21 10:00 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-13  9:29 [Qemu-devel] [PATCH] spapr-pci: enable adding PHB via -device Alexey Kardashevskiy
2014-01-20 14:55 ` Alexander Graf
2014-01-20 15:27 ` Markus Armbruster
2014-01-21  1:37   ` Alexey Kardashevskiy
2014-01-21  7:56     ` Markus Armbruster
2014-01-21 10:00       ` Alexey Kardashevskiy [this message]
2014-01-21 10:19     ` Andreas Färber
2014-01-21 13:00       ` Alexey Kardashevskiy

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=52DE4539.9080502@ozlabs.ru \
    --to=aik@ozlabs.ru \
    --cc=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=armbru@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-ppc@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.