qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] KVM call minutes for Feb 8


From: Peter Maydell
Subject: Re: [Qemu-devel] KVM call minutes for Feb 8
Date: Thu, 10 Feb 2011 13:06:36 +0000

On 10 February 2011 12:23, Anthony Liguori <address@hidden> wrote:
> But something interacts with each processor and dispatches the I/O
> operations in the address space, no?  I can't believe there are 2^32 address
> lines coming off of every arm chip that each device connects.

Well, the AXI bus is kind of complicated and definitely not my
area of expertise, but as I understand it you have an interconnect
like a PL300 that effectively implements the "memory map" and
defines where the slaves (devices) appear. But unless you actually
want to be modelling bus transactions at a pretty low level this
isn't really a visible difference from "these devices appear at
this address in the memory map on this bus". (And there might
be a bridge down from AXI to AHB or APB between the core
and any particular device, but that's not programmer visible either.)

> This relationship of how I/O fans out through various devices is important
> because occasionally platforms do weird things during I/O fan out like
> implement an IOMMU.  If we don't model this I/O dispatch model within QEMU,
> then it's extremely difficult to implement things like IOMMUs.

Yes, but what does this have to do with chipsets and getting rid
of machines? Getting I/O fanout through devices is a matter of
modelling some sort of conceptual bus, and having the right APIs
so you can do it fast in the common case and still allow IOMMUs
and other interesting devices to intercept and change transactions.
Any particular board might have to wire up the bus so it goes through
an IOMMU, or it might not.

Whether you want to bundle up a collection of devices and bus wiring
and call it a "chipset" or not should be a matter of whether that makes
sense and is a usefully reusable conceptual unit for whatever board
you're modelling, I think. (For instance "an OMAP3" is an obvious
reusable unit which any OMAP3-based board model is going to want
to use.)

Some of the I/O fanout and bus wiring might be internal to
a qemu core model, for that matter -- for instance M profile
ARM cores have several output buses which deal with
different bits of the memory space (which are predefined
as being for devices, or memory, or whatever), and the
A9MP's internal timers and interrupt controller and so on ought
to all be inside the core (at the moment we rely on all A9MP
boards instantiating them as a separate device, which is ugly).

-- PMM



reply via email to

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