Re: virtio & hypercall interface?

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Rusty Russell wrote:
> On Sat, 2007-09-15 at 11:05 +0300, Avi Kivity wrote:
>   
>> Rusty Russell wrote:
>>     
>>> On Sat, 2007-09-15 at 01:31 +0300, Dor Laor wrote:
>>>   
>>>       
>>>> Second, regardless of the channel signal notification, there are still 
>>>> real necessities for userspace hypercall handling:
>>>> 1. For virtio drivers there is also registration hypercall for passing 
>>>> the shared memory pfns.
>>>>     Sure there are other possibilities, but why limit ourselves?
>>>>     
>>>>         
>>> I really prefer doing this the more "hardware-like" way and having the
>>> device description say where the pages are.  Surely this is simpler from
>>> the qemu side, too?
>>>   
>>>       
>> This is mmio style (device provides memory).  DMA style (guest provides
>> memory, device dmas it) is easier for kvm: we don't need to allocate a
>> new memory slot, and migration is easier.
>>
>> Most current hardware place the descriptor ring in guest memory, not the
>> device, since mmio is slower for the cpu than RAM.
>>     
>
> But for virtual devices it seems unnecessarily convoluted: we'd have
> some mmio space (or PCI config space?) to tell the device where the ring
> buffer is.  That's a little nasty for lguest early printk, too.
>   

I don't see why there is a difference.  With mmio, the host tells the
guest where the ring is.  With dma, the guest tells the host where the
ring is.  In both cases, you need some form of communication (read-only
for mmio, write-only for dma).

For mmio, the mechanism is standardized within pci; for dma it is not,
but it is still just as simple, write to some word in pci config space
and you're done.


If early printk can't handle pci, we can provide a pio port that does
byte-at-a-time output.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/