Re: [Qemu-devel] device assignment for embedded Power

[Paul Brook <paul@codesourcery.com>]

> > 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