Re: [Qemu-devel] KVM call agenda for 2014-04-15

[Peter Maydell]

Some fuller comments below on the parts of the call which
I had opinions on.

On 15 April 2014 15:55, Alexander Graf <address@hidden> wrote:
>
> 2) -device for non-PCI devices
>
> There are 2 reasons we want to create "platform" devices using -device on
> the command line. One is that Xilinx is trying to create a full machine from
> the command line. The other one is that we want VFIO for platform devices.

I think the "create a full machine" part of this very
definitely needs to be done by taking a wider view of
the design, fixing or reworking parts of our system which
aren't sufficiently QOMified, etc first. Then you can get
to the point where you can create a board model from a
config file or script; and then maybe you can think about
the command line. Starting from "on the command line" is
definitely the wrong end. Most of my comments below are
suggestions about what direction I think we should be going
if we want to tackle this.

The VFIO case, on the other hand, might potentially be solvable
with a more limited set of changes. Unfortunately I can't currently
see anything we can do here which isn't going to be irredeemably
ugly :-(

> a) IRQs
>
> The "Anthony" way of doing IRQ links between random devices is his stateful
> Pin object approach. Since Anthony is gone and it'd be a lot of refactoring,
> we don't deem this approach realistic.

I think my point was not necessarily "unrealistic" but more
that we don't need to feel obliged to stick with this design
if we have a better idea. I don't think that moving to a more
QOM-aware irq/gpio connection scheme necessarily requires
stateful Pin objects.

Is it possible to move to stateful Pin objects without breaking
migration compatibility for everything?

> Andreas suggested that we could make every qemu_irq a QOM object that then
> gets a global name in the QOM hierarchy and can be addressed as connector
> for IRQ output lines of devices in the -device command line syntax.

I think QOMifying qemu_irqs would be nice anyway: we could
as part of this arrange to be able to give them names, so
that you could connect "mmc.card-present" to "sysctl.mmc-card-present"
rather than having to wire up output 0 to input 1, and you
could have the ARM GIC have several different arrays of
inputs rather than the current scheme of encoding them all
as different parts of the single gpio in array.

> b) Memory Regions
>
> The "Anthony" approach was to turn memory regions into QOM objects. That
> allows to expose memory region links as QOM links.

I think this is worth pursuing; it links up with some of Edgar's
recent patches to make CPUs use particular AddressSpaces for
dispatch, and so on. Parts of this have obvious QOM property
syntax: a device can expose its MemoryRegions as suitable
kinds of QOM properties or links, just as is proposed above
for its IRQ lines. (And again, we would be able to give them
sensible names like "regs", "pci-io-window", "pci-mem-window-1",
"pci-mem-window-2", etc.) And where a QOM object wants to
accept a MemoryRegion (because it is a transaction master like
a CPU or DMA controller) that also seems straightforward, in
analogy to how an interrupt controller has inbound GPIO lines.
The unanswered question for command line syntax is how you
would deal with what we currently do in C where a board
model or a SoC device creates a container MemoryRegion and
populates it before feeding it to a transaction master.
I think you could probably handle this by having some kind
of special case syntax for "map memory region X into memory
region Y at offset Z", eg "-global board.memmap[0x3000] = mydevice.regs".

We also talked about the issue that if we allow users to do
this sort of thing on the command line we're effectively
making our QOM hierarchy ABI, in that if we rearrange how
we instantiate devices this will break some command lines.
One suggestion here to ameliorate this was to provide aliases,
so you could say "interrupt-controller" rather than
"board/a15mpcore/gic"; then this would be nicer for users and
also we could say "only the aliases are guaranteed not to break".

> The currently proposed approach is to add a -sysbusdev (or -device) command
> line option that hard codedly puts memory region n of device x into address
> a of the physical address space.

I really don't like this idea at all. It seems to be completely
ducking any attempt to address the wider issues here.

thanks
-- PMM