qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Peter Maydell <peter.maydell@linaro.org>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: "qemu-ppc@nongnu.org list:PowerPC" <qemu-ppc@nongnu.org>,
	Alexander Graf <agraf@suse.de>,
	qemu-devel Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 0/9] Add platform bus
Date: Mon, 22 Jul 2013 23:34:40 +0100	[thread overview]
Message-ID: <CAFEAcA-5n=cOcjAdc3Q4_cBOEOiDe8SoeCXqbu6vCrk75EX4zA@mail.gmail.com> (raw)
In-Reply-To: <87siz6qmi7.fsf@codemonkey.ws>

On 22 July 2013 23:05, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Peter Maydell <peter.maydell@linaro.org> writes:
>> We don't currently have any PCI host controller which is:
>> (a) for ARM
>
> In QEMU?  You can make one super easily by just extending PCIHostState.
>
> It's just a matter of mapping the index and data registers somewhere.

That's a model of some random nonexistent thing, not a model
of a piece of hardware or silicon that actually exists and
thus that there's some hope the kernel might someday maybe
be able to drive properly.

> I can't believe it's that hard to get this working in Linux either.

Actual ARM hardware with PCI is rare; the overlap of
that with "ARM hardware we model in QEMU" is pretty near
zero. And we demonstrably can't get the kernel folks to write
working driver code for a PCI controller that only exists in
QEMU -- just look at the trainwreck which is the versatile PCI
kernel code.

>> (b) entirely device tree driven
>
> I'm not sure what this means, but presumably it wouldn't be
> hard to do the above.

It means "not tied up with assumptions that the PCI
controller is sitting in whatever SoC it sits in in hardware,
with the clock and power control and etc etc etc that that
PCI controller has in hardware". In other words, such that
you can just drop a model of that controller into a random
nonexistent board and have it work, rather than having to
model an entire complex SoC because the driver code (entirely
reasonably) assumes the hardware is always in that SoC.

>> (c) supported by QEMU
>
> This part is easy enough.

Modelling a PCI controller isn't so hard. Modelling the
SoC it sits in is much harder.

>> (d) with a decent Linux driver
>
> See above.

See my remarks above too :-)

>> So mach-virt doesn't have PCI; it will use virtio-mmio,
>> same as kvmtool for ARM does.
>
> That's all well and fine but there are a lot of advantages to having PCI
> and being able to use all of the features associated with it.

I completely agree. The reason we're here with virtio-mmio
is because of the gaping lack of PCI for ARM yet. This will
improve, I'm sure, but just now there simply isn't a
sensible device we can model that I'm aware of. I'm open
to suggestions if anybody has them.

-- PMM

  reply	other threads:[~2013-07-22 22:35 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-22 17:50 [Qemu-devel] [PATCH 0/9] Add platform bus Alexander Graf
2013-07-22 17:50 ` [Qemu-devel] [PATCH 1/9] PlatBus: Add Platform Bus Alexander Graf
2013-07-22 17:50 ` [Qemu-devel] [PATCH 2/9] PlatBus: Add abstract Platform Device Alexander Graf
2013-07-22 17:50 ` [Qemu-devel] [PATCH 3/9] PlatBus: Add Sysbus/Platform bridge device Alexander Graf
2013-07-22 17:50 ` [Qemu-devel] [PATCH 4/9] PlatBus: Hook up into Makefile system Alexander Graf
2013-07-22 17:50 ` [Qemu-devel] [PATCH 5/9] PPC: Add platform bus to the default compile set Alexander Graf
2013-07-22 17:50 ` [Qemu-devel] [PATCH 6/9] PlatBus: Add serial-platbus device Alexander Graf
2013-07-22 18:26   ` Peter Maydell
2013-07-22 18:56     ` Alexander Graf
2013-07-24 20:16       ` Scott Wood
2013-07-24 20:25         ` Peter Maydell
2013-07-22 17:50 ` [Qemu-devel] [PATCH 7/9] PPC: Add PlatBus Serial to default configs Alexander Graf
2013-07-22 17:50 ` [Qemu-devel] [PATCH 8/9] PPC: E500: Spawn PlatBus bridge for ppce500 machine Alexander Graf
2013-07-22 17:50 ` [Qemu-devel] [PATCH 9/9] PPC: E500: Add PlatBus device tree walker Alexander Graf
2013-07-22 18:21 ` [Qemu-devel] [PATCH 0/9] Add platform bus Peter Maydell
2013-07-22 18:55   ` Alexander Graf
2013-07-23 12:19   ` Paolo Bonzini
2013-07-23 12:22     ` Peter Maydell
2013-07-23 12:34       ` Paolo Bonzini
2013-07-23 12:40         ` Peter Maydell
2013-07-23 13:06           ` Paolo Bonzini
2013-07-23 14:26           ` Anthony Liguori
2013-07-23 14:28             ` Peter Maydell
2013-07-23 12:29     ` François Revol
2013-07-22 19:38 ` Anthony Liguori
2013-07-22 19:44   ` Alexander Graf
2013-07-22 19:52     ` Anthony Liguori
2013-07-22 21:50       ` Peter Maydell
2013-07-22 22:05         ` Anthony Liguori
2013-07-22 22:34           ` Peter Maydell [this message]
2013-07-22 23:03             ` Andreas Färber

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='CAFEAcA-5n=cOcjAdc3Q4_cBOEOiDe8SoeCXqbu6vCrk75EX4zA@mail.gmail.com' \
    --to=peter.maydell@linaro.org \
    --cc=agraf@suse.de \
    --cc=anthony@codemonkey.ws \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).