Marcelo Tosatti wrote: > On Mon, Mar 17, 2008 at 01:11:11PM +0200, Avi Kivity wrote: > > >>> + up_read(&kvm->slots_lock); >>> >>> So as to avoid rmap_nuke, since that will be done through the madvise() >>> path. >>> >>> >>> >> Why not do it in userspace? >> > > I don't see any way of knowing whether you have or not mmu notifiers from > userspace except adding an ioctl. > >
KVM_CHECK_CAPABILITY (KVM_CAP_MMU_NOTIFIERS) >> I'll likely merge zap directly into the backwards compatibility support >> (it won't ever appear in mainline since mmu notifiers will be merged >> sooner). >> > > Even with mmu notifiers QEMU needs to ask the host kernel "do you have > mmu notifiers?" before zapping any page, otherwise the guest will crash. > > If we drop the shadow ptes explicitly, it shouldn't crash? > So some method of finding if the host kernel has mmu notifiers needs to > be in place even in mainline. > > Yes, the capability test. > And what about allocation of ioctl numbers? Will you reserve the number > used for ZAP_GFN on mainline? > > We can allocate those from the end and hope they never meet. > KVM: MMU: handle page removal with shadow mapping > > Do not assume that a shadow mapping will always point to the same host > frame number. Fixes crash with madvise(MADV_DONTNEED). > > Applied, thanks. -- error compiling committee.c: too many arguments to function ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
