[<prev] [next>] [day] [month] [year] [list]
Date: Tue, 10 Oct 2017 18:10:39 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: peng.hao2@....com.cn
Cc: rkrcmar@...hat.com, x86@...nel.org, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: X86: clear page flags when freeing kvm mmapping page
On 10/10/2017 17:39, peng.hao2@....com.cn wrote:
>>How did you know that this was a kvm_run page, and why is it the right
>>thing to clear the flags?
>
> first I can't repeat this "bad page report". But I add print message to
> trace. I found that kvm_run page is freed with page flags
> PG_dirty and PG_referenced. I don't think it is right status for
> freed page.
That would be the symptom, not the cause. So it would not be the right
thing to clear the flags.
> second, kvm_run page is mmaped in qemu with fd of "kvm-vcpu". It has
> special mmap function(kvm_vcpu_mmap),but when munmap is called
> the kvm_run page goes into general munmap route.it is not suitable for
> kvm_run page that is set dirty in munmap route.
There are many many cases where .mmap and .fault are defined but .munmap
isn't, and none of them calls ClearPageDirty or ClearPageReferenced; see
for example kernel/relay.c (whose only user is blktrace).
Can the page be dirty in those cases? If not, what makes KVM different?
Since you cannot reproduce the failure, this patch is basically
untested. You need to dig deeper into what's happening, and provide a
better justification for what you are doing. But generally, it's a bad
sign if you're doing something special that no other device in the
kernel is doing.
Paolo
Powered by blists - more mailing lists