On 8 July 2013 14:45, Alexander Graf <agraf@xxxxxxx> wrote: > On 08.07.2013, at 15:23, Peter Maydell wrote: >> Now I'm completely confused. Why would assigned devices >> have anything to do with this? Can you explain in more >> detail, because I don't really see what you're suggesting? > > The only missing link we have to create any device using -device > on the command line is the IRQ line enumeration. If we can allocate > IRQ lines automatically, we can put any command line given -device > onto our main system bus that is non-pci, non-isa. If the user is expected to be able to get the MMIO address right (which they'd have to specify on the command line somehow too) why not require them to specify the IRQ number while they're doing it? I'm a bit suspicious of anything that requires the user to specify to that level of detail though, since it requires a lot of inside knowledge about the board. This is the whole reason for having the separate transport: the board gets to take care of the board specific detail of how to wire up the transport, and the user just asks to create the backends that plug automatically into it. The virtio command line options are complicated and confusing enough as it is. > So if we want to ever support VFIO for platform devices, > the user will want to pass -device vfio-ahci,foo=bar on > the command line to assign an AHCI device. This appears to be seriously short on actually specifying enough information to wire a device up. > The only infrastructure blocker we have for that today > is the IRQ allocation. DMA lines? Specifying the right location in the address space? > Maybe we could even try to be as smart as putting the MMIO > regions into guest address space intelligently automatically. This sounds likely to cause problems with migration unless we can guarantee that we always pick the same place. -- PMM _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
