> > Thanks---however, after re-reading xen-mapcache.c, dma needs to be false
> > for unlocked mappings.
>
> If there is a DMA operation already in progress, it means that we'll
> already have a locked mapping for it.
Yes, I only wanted to say that qemu_ram_ptr_length should pass dma=false
when c
On Tue, 25 Jul 2017, Paolo Bonzini wrote:
> - Original Message -
> > From: "Stefano Stabellini"
> > To: "Paolo Bonzini"
> > Cc: "Anthony PERARD" , "Stefano Stabellini"
> > ,
> > xen-devel@lists.xen.org, qemu-de...@nongnu.org
> > Sent: Tuesday, July 25, 2017 8:08:21 PM
> > Subject: Re: QE
- Original Message -
> From: "Stefano Stabellini"
> To: "Paolo Bonzini"
> Cc: "Anthony PERARD" , "Stefano Stabellini"
> ,
> xen-devel@lists.xen.org, qemu-de...@nongnu.org
> Sent: Tuesday, July 25, 2017 8:08:21 PM
> Subject: Re: QEMU commit 04bf2526ce breaks use of xen-mapcache
>
> On
On Tue, 25 Jul 2017, Paolo Bonzini wrote:
> > Hi,
> >
> > Commits 04bf2526ce (exec: use qemu_ram_ptr_length to access guest ram)
> > start using qemu_ram_ptr_length() instead of qemu_map_ram_ptr().
> > That result in calling xen_map_cache() with lock=true, but this mapping
> > is never invalidated
> Hi,
>
> Commits 04bf2526ce (exec: use qemu_ram_ptr_length to access guest ram)
> start using qemu_ram_ptr_length() instead of qemu_map_ram_ptr().
> That result in calling xen_map_cache() with lock=true, but this mapping
> is never invalidated.
> So QEMU use more and more RAM until it stop workin
Hi,
Commits 04bf2526ce (exec: use qemu_ram_ptr_length to access guest ram)
start using qemu_ram_ptr_length() instead of qemu_map_ram_ptr().
That result in calling xen_map_cache() with lock=true, but this mapping
is never invalidated.
So QEMU use more and more RAM until it stop working for a reason
