qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/9] Add platform bus


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH 0/9] Add platform bus
Date: Mon, 22 Jul 2013 23:34:40 +0100

On 22 July 2013 23:05, Anthony Liguori <address@hidden> wrote:
> Peter Maydell <address@hidden> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]