qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v6 03/12] dataplane: add host memory mapping cod


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v6 03/12] dataplane: add host memory mapping code
Date: Tue, 11 Dec 2012 16:27:49 +0100

On Tue, Dec 11, 2012 at 3:13 PM, Michael S. Tsirkin <address@hidden> wrote:
> On Mon, Dec 10, 2012 at 02:09:36PM +0100, Stefan Hajnoczi wrote:
>> The data plane thread needs to map guest physical addresses to host
>> pointers.  Normally this is done with cpu_physical_memory_map() but the
>> function assumes the global mutex is held.  The data plane thread does
>> not touch the global mutex and therefore needs a thread-safe memory
>> mapping mechanism.
>>
>> Hostmem registers a MemoryListener similar to how vhost collects and
>> pushes memory region information into the kernel.  There is a
>> fine-grained lock on the regions list which is held during lookup and
>> when installing a new regions list.
>
> Can we export and reuse the vhost code for this?
> I think you will find this advantageous when you add migration
> support down the line.
> And if you find it necessary to use MemoryListener e.g. for performance
> reasons, then vhost will likely benefit too.

It's technically possible and not hard to do but it prevents
integrating deeper with core QEMU as the memory API becomes
thread-safe.

There are two ways to implement dirty logging:
1. The vhost log approach which syncs dirty information periodically.
2. A cheap thread-safe way to mark dirty outside the global mutex,
i.e. a thread-safe memory_region_set_dirty().

If we can get thread-safe guest memory load/store in QEMU then #2 is
included.  We can switch to using hw/virtio.c instead of
hw/dataplane/vring.c, we get dirty logging for free, we can drop
hostmem.c completely, etc.

Stefan



reply via email to

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