qemu-devel
[Top][All Lists]
Advanced

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

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


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [RFC v2 3/6] memory: support unmapping of MemoryRegion mapped into HVA parent
Date: Mon, 8 Jun 2015 18:25:32 +0200

On Mon, Jun 08, 2015 at 06:13:14PM +0200, Igor Mammedov wrote:
> On Mon, 08 Jun 2015 17:32:27 +0200
> Paolo Bonzini <address@hidden> wrote:
> 
> > 
> > 
> > On 08/06/2015 17:19, Igor Mammedov wrote:
> > > +void qemu_ram_unmap_hva(ram_addr_t addr)
> > > +{
> > > +    RAMBlock *block = find_ram_block(addr);
> > > +
> > > +    assert(block);
> > > +    mmap(block->host, block->used_length, PROT_NONE,
> > > +         MAP_FIXED | MAP_NORESERVE | MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
> > > +}
> > > +
> > 
> > Hmm, this is not good. :(  The area at block->host can be in use, for
> > example via memory_region_ref/memory_region_unref.  This can happen a
> > bit after the memory_region_del_subregion.  So you can SEGV if you
> > simply make a synchronous update.  I'm not sure if there is a solution
> Yep, that's the problem I haven't found solution to so far,
> any ideas hoe to approach this are appreciated.
> 
> 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?

> > (but thanks for splitting the patches in a way that made the problem
> > clear!).
> > 
> > Paolo



reply via email to

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