On Tue, Dec 11, 2012 at 10:32:28AM -0600, Anthony Liguori wrote: > "Michael S. Tsirkin" <m...@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 <m...@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
Yes I agree. I think lack of handling for cross regin descriptors bothers me a bit more. > > > > -- > > MST
