qemu-devel
[Top][All Lists]
Advanced

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

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


From: Ian Molton
Subject: Re: [Qemu-devel] Address translation - virt->phys->ram
Date: Mon, 22 Feb 2010 17:47:17 +0000
User-agent: Mozilla-Thunderbird 2.0.0.22 (X11/20091109)

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. So far, switching from
abusing an instruction to interrupt qemu to using virtio has incurred a
roughly 5x slowdown. 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





reply via email to

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