qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 02/18] vfio: introduce vfio_get_vaddr()


From: Peter Xu
Subject: Re: [Qemu-devel] [PATCH v5 02/18] vfio: introduce vfio_get_vaddr()
Date: Thu, 26 Jan 2017 14:26:48 +0800
User-agent: Mutt/1.5.24 (2015-08-30)

On Wed, Jan 25, 2017 at 06:16:44PM +0100, Paolo Bonzini wrote:
> 
> 
> On 25/01/2017 17:43, Alex Williamson wrote:
> > On Wed, 25 Jan 2017 12:32:21 +0800
> > Peter Xu <address@hidden> wrote:
> >> I have similar question as well above - IIUC the RCU read lock
> >> protects us from not losing the references of memory objects, however
> >> in our case even after we release the lock, we are still using the
> >> backend ram (vaddr) since we have set it up inside kernel to build up
> >> the IO page table. After that, the kernel/device should be able to
> >> write to addresses of that backend ram any time.
> 
> I don't think that's what happens.  As far as I understand, VFIO pins
> the pages corresponding to vaddr, not vaddr itself.  The memory backend
> is mmap-ed memory; when you hot-unplug it the munmap releases the VMA
> and loses the connection between QEMU's virtual address space and the
> pages.  However, the pages stay pinned and stay mapped into VFIO's own
> IOMMU page tables.
> 
> So if a guest does a memory hot-unplug without IOMMU unmap, it would
> keep on seeing the content of the hot-unplugged memory, and the host
> could not release the pages, but the guest cannot overwrite QEMU data
> structures.

Sounds reasonable. I forgot that these pages are pinned if without an
explicit unmap.

Thanks Paolo. :)

-- peterx



reply via email to

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