From: Sheng Yang <sheng@linux.intel.com>
To: kvm@vger.kernel.org
Cc: Marcelo Tosatti <mtosatti@redhat.com>, Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH] KVM: VMX: Judge MMIO based on PFN rather than HVA in EPT violation
Date: Wed, 11 Feb 2009 11:29:31 +0800 [thread overview]
Message-ID: <200902111129.32148.sheng@linux.intel.com> (raw)
In-Reply-To: <200902111043.45193.sheng@linux.intel.com>
On Wednesday 11 February 2009 10:43:43 Sheng Yang wrote:
> On Tuesday 10 February 2009 20:14:32 Marcelo Tosatti wrote:
> > Hi Sheng,
> >
> > On Tue, Feb 10, 2009 at 05:43:41PM +0800, Sheng Yang wrote:
> > > One page can be unmapped from userspace, then HVA seems legal, but in
> > > fact, PFN is illegal.
> > >
> > > Signed-off-by: Sheng Yang <sheng@linux.intel.com>
> > > ---
> > > arch/x86/kvm/vmx.c | 6 +++---
> > > 1 files changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > > index 9913a1d..a4fa1b5 100644
> > > --- a/arch/x86/kvm/vmx.c
> > > +++ b/arch/x86/kvm/vmx.c
> > > @@ -3061,7 +3061,7 @@ static int handle_ept_violation(struct kvm_vcpu
> > > *vcpu, struct kvm_run *kvm_run) u64 exit_qualification;
> > > enum emulation_result er;
> > > gpa_t gpa;
> > > - unsigned long hva;
> > > + pfn_t pfn;
> > > int gla_validity;
> > > int r;
> > >
> > > @@ -3086,8 +3086,8 @@ static int handle_ept_violation(struct kvm_vcpu
> > > *vcpu, struct kvm_run *kvm_run) }
> > >
> > > gpa = vmcs_read64(GUEST_PHYSICAL_ADDRESS);
> > > - hva = gfn_to_hva(vcpu->kvm, gpa >> PAGE_SHIFT);
> > > - if (!kvm_is_error_hva(hva)) {
> > > + pfn = gfn_to_pfn(vcpu->kvm, gpa >> PAGE_SHIFT);
> > > + if (!is_error_pfn(pfn)) {
> > > r = kvm_mmu_page_fault(vcpu, gpa & PAGE_MASK, 0);
> > > if (r < 0) {
> > > printk(KERN_ERR "EPT: Not enough memory!\n");
> >
> > Forgot to drop the additional reference acquired by gfn_to_pfn ?
>
> Sadly, yeah... :(
>
> > Hum, gfn_to_hva assumes the slot information is accurate, which is not
> > the case if you simply munmap a page in the middle of a slot... we
> > should provide a helper in userspace, and make sure nothing bad can
> > happen otherwise.
>
> Yes. But maintain a list in kernel seems a little complex for it. I checked
> the callings of gfn_to_hva, seems most of them are safe with a inaccurate
> result(not sure about host_largepage_backed, seems this would be affected
> if one 4k page was unmapped inside a large page).
>
> > Anyway, why don't you just let kvm_mmu_page_fault handle instruction
> > emulation instead of opencoding it in handle_ept_violation ?
>
> It didn't work as expect. Checking it.
Oh, seems it didn't work due to my fault... Update the patch, thanks for
reminder. :)
--
regards
Yang, Sheng
prev parent reply other threads:[~2009-02-11 3:29 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-10 9:43 [PATCH] KVM: VMX: Judge MMIO based on PFN rather than HVA in EPT violation Sheng Yang
2009-02-10 12:14 ` Marcelo Tosatti
2009-02-11 2:43 ` Sheng Yang
2009-02-11 3:29 ` Sheng Yang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200902111129.32148.sheng@linux.intel.com \
--to=sheng@linux.intel.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.