Some fuller comments below on the parts of the call which I had opinions on. On 15 April 2014 15:55, Alexander Graf <agraf@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
