[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] Address translation - virt->phys->ram
Date: Tue, 23 Feb 2010 10:21:03 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

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:


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.


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.


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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]