From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@qumranet.com>
Subject: Re: [patch 0/3] QEMU balloon support
Date: Mon, 17 Mar 2008 16:56:26 +0200
Message-ID: <47DE869A.2020804@qumranet.com>
References: <20080312191720.490529767@localhost.localdomain>
	<47DD27E6.9090202@qumranet.com> <20080316185951.GA931@dmt>
	<47DE51CF.1030905@qumranet.com> <20080317130818.GA4443@dmt>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Cc: kvm-devel@lists.sourceforge.net
To: Marcelo Tosatti <marcelo@kvack.org>
Return-path: <kvm-devel-bounces@lists.sourceforge.net>
In-Reply-To: <20080317130818.GA4443@dmt>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/kvm-devel>,
	<mailto:kvm-devel-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=kvm-devel>
List-Post: <mailto:kvm-devel@lists.sourceforge.net>
List-Help: <mailto:kvm-devel-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/kvm-devel>,
	<mailto:kvm-devel-request@lists.sourceforge.net?subject=subscribe>
Sender: kvm-devel-bounces@lists.sourceforge.net
Errors-To: kvm-devel-bounces@lists.sourceforge.net
List-Id: kvm.vger.kernel.org

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/