> > Why is your device so unique? How does it interact with the guest system > > and what features does it require that doen't exist in any device that > > can be emulated? > > Perhaps I misunderstood what you meant by "similar characteristics". I see > no reason to spend a bunch of time implementing full emulation for a > device, that isn't going to be used, just because it seems like a nice > intermediary step.
You say your device has MMIO regions, generates IRQs and initiates DMA transactions. Any device or selection of devices that between them use all those features will do the job. I'd expect most SoC to have several. We don't care what the device actually does, only the ways it communicates with the rest of the machine. I think you're coming at this problem from completely the wrong direction. Instead of "how do I wedge this passthrough into my machine", you should be asking "how do I create a machine without knowing the machine layout at compile time". Once you fix that, hooking up the passthrough device should be fairly trivial. You only have a single passthrough device, and the rest of us have none at all. Anything restricted to the pasthrough case is thus unlikely to be the right answer to the second question, and I'd expect it to be removed/changed/broken when we do get round to implementing dynamic device creation. > > > We're talking about directly mapping the registers into the guest. The > > > whole point is performance. > > > > That's an additional step after you get passthrough working the normal > > way. > > "normal"? Mapping a MMIO region into the guest is an additional complication, and purely a performance optimization. qemu already needs to be in the loop to handle interrupts, probably DMA setup and the non-kvm case. > I'm not sure what the use case is for direct assignment of a device in an > otherwise completely emulated guest, but perhaps there is one. Typically because the host system doesn't know how to talk to it, or there isn't a sensible way to relay the functionality provided by the device from the kernel to qemu. > > We already have mechanisms (or at least patches) for mapping file-like > > objects into guest physical memory. That's largely independent of > > device passthrough. It's a relatively minor tweak to how the passthrough > > device sets up its MMIO regions. > > > > Mapping host device MMIO regions into guest space is entirely > > uninteresting unless we already have some way of creating guest-host > > passthrough devices. > > Isn't that what's being discussed? It's your end goal, but I don't think it's particularly relevant to the problem you've encountered. > > Creating guest-device passthrough devices isn't going to happen until the > > can create arbitrary devices (within the set emulated by qemu) that > > interact with the rest of the emulated machine in a similar way. > > What do you mean by "interact with the rest of the emulated machine in a > similar way"? See first paragraph above. Paul
