Re: [Qemu-devel] Address translation - virt->phys->ram

[Anthony Liguori]

On 02/22/2010 11:47 AM, Ian Molton wrote:
> Anthony Liguori wrote:
>    
> > On 02/22/2010 10:46 AM, Ian Molton wrote:
> >      
> > > Anthony Liguori wrote:
> > >
> > >
> > >        
> > > > cpu_physical_memory_map().
> > > >
> > > > But this function has some subtle characteristics.  It may return a
> > > > bounce buffer if you attempt to map MMIO memory.  There is a limited
> > > > pool of bounce buffers available so it may return NULL in the event that
> > > > it cannot allocate a bounce buffer.
> > > >
> > > > It may also return a partial result if you're attempting to map a region
> > > > that straddles multiple memory slots.
> > > >
> > > >          
> > > Thanks. I had found this, but was unsure as to wether it was quite what
> > > I wanted. (also is it possible to tell when it has (eg.) allocated a
> > > bounce buffer?)
> > >
> > > Basically, I need to get buffer(s) from guest userspace into the hosts
> > > address space. The buffers are virtually contiguous but likely
> > > physically discontiguous. They are allocated with malloc() and theres
> > > nothing I can do about that.
> > >
> > > The obvious but slow solution would be to copy all the buffers into nice
> > > virtio-based scatter/gather buffers and feed them to the host that way,
> > > however its not fast enough.
> > >
> > >        
> > Why is this slow?
> >      
> Because the buffers will all have to be copied.

Why?

It sounds like your kernel driver is doing the wrong thing if you can't 
preserve zero-copy from userspace.

>   So far, switching from
> abusing an instruction to interrupt qemu to using virtio has incurred a
> roughly 5x slowdown.

If you post patches, we can help determine what you're doing that's 
causing such a slow down.

Regards,

Anthony Liguori

>   I'd guess much of this is down to the fact we have
> to switch to kernel-mode on the guest and back again for every single GL
> call...
>
> If I can establish some kind of stable guest_virt->phys->host_virt
> mapping, many of the problems will just 'go away'. a way to interrupt
> qemu from user-mode on the guest without involving the guest kernel
> would be quite awesome also (theres really nothing we want the kernel to
> actually /do/ here, it just adds overhead).
>
> -Ian
>
>