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

[Michael S. Tsirkin]

On Tue, Dec 11, 2012 at 10:32:28AM -0600, Anthony Liguori wrote:
> "Michael S. Tsirkin" <address@hidden> 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 <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().
> >
> > 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

Yes I agree. I think lack of handling for cross regin descriptors
bothers me a bit more.

> >
> > -- 
> > MST