Re: [patch 0/3] QEMU balloon support

Avi Kivity
2008-03-17T14:56:26Z

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