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

[Anthony Liguori <aliguori@us.ibm.com>]

"Michael S. Tsirkin" <mst@redhat.com> writes:

> On Tue, Dec 11, 2012 at 04:27:49PM +0100, Stefan Hajnoczi wrote:
>> On Tue, Dec 11, 2012 at 3:13 PM, Michael S. Tsirkin <mst@redhat.com> 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().
>
> You don't normally want to dirty the whole region,
> you want to do this to individual pages.
>
>> 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
>
> So why not reuse existing code? If you drop it later it won't
> matter what you used ...

Let's not lose sight of the forest for the trees here...

This whole series is not reusing existing code.  That's really the whole
point.

The point is to take the code (duplication and all) and then do all of
the refactoring to use common code in the tree itself.

If we want to put this in a hw/staging/ directory, that's fine by me
too.

Regards,

Anthony Liguori

>
> -- 
> MST