Re: [Qemu-devel] [RFC v2 3/6] memory: support unmapping of MemoryRegion mapped into HVA parent

[Igor Mammedov]

On Mon, 08 Jun 2015 19:06:39 +0200
Paolo Bonzini <address@hidden> wrote:

> 
> 
> On 08/06/2015 18:25, Michael S. Tsirkin wrote:
> > > issue is that we have to re-reserve HVA region first so no other 
> > > allocation
> > > would claim gap and the only way I found was just to call mmap() on it
> > > which as side effect invalidates MemoryRegion's backing RAM.
> > 
> > Well the only point we need to mmap is where we'd unmap
> > normally, if that's not safe then unmapping wouldn't
> > be safe either?
> 
> I think it is it possible to map slot 2 at address 0x12340000 right
> after unmapping slot 1 at the same address but before an RCU grace
> period has expired.
Let me sum up my understanding of issue:

1. we can "unmap" GPA of HVA remapped region using memory_region_del_subregion()
   from guest current flatview but mapping will stay in old flatview
   until RCU's grace period passes.

2. hanging reference from old flatview doesn't allow us to mmap(RESEVED)
   to be freed range in container's HVA range.

3. until #2 is done we can't allow to map another memory region in
   current flatview at the same range, hence need to keep list of
   still active HVA ranges so we could check at memory_region_add_subregion()
   time that new mapping is allowed. => adding "Error **errp"
   to memory_region_add_subregion() for reporting fail.


> 
> If this is possible, then you can have two DIMMs trying to mmap
> themselves at the same address.
> 
> Probably you need to stop using object_child_foreach in
> hw/mem/pc-dimm.c, and instead build your own list.  An object can keep a
> "weak" reference to itself in the list, and remove itself from the list
> at instance_finalize time.
I don't get what you suggest,
how would it solve issue with still alive MemoryRegion reference in old 
flatview?


> 
> Paolo