From: Gleb Natapov <gleb@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>, kvm <kvm@vger.kernel.org>
Subject: Re: vmx real mode emulated mmio?
Date: Sat, 15 Dec 2012 18:23:37 +0200 [thread overview]
Message-ID: <20121215162337.GC4384@redhat.com> (raw)
In-Reply-To: <1355586862.3224.398.camel@bling.home>
On Sat, Dec 15, 2012 at 08:54:22AM -0700, Alex Williamson wrote:
> On Sat, 2012-12-15 at 10:07 +0200, Gleb Natapov wrote:
> > On Fri, Dec 14, 2012 at 04:42:36PM -0700, Alex Williamson wrote:
> > >
> > > I don't really know what I'm doing messing around with realmode
> > > exception handling, but are we missing something like this:
> > >
> > > --- a/arch/x86/kvm/vmx.c
> > > +++ b/arch/x86/kvm/vmx.c
> > > @@ -4332,7 +4332,8 @@ static int handle_exception(struct kvm_vcpu *vcpu)
> > > if (vcpu->arch.halt_request) {
> > > vcpu->arch.halt_request = 0;
> > > return kvm_emulate_halt(vcpu);
> > > - }
> > > + } else if (vcpu->mmio_needed)
> > > + return 0;
> > > return 1;
> > > }
> > >
> > >
> > > The background is that I was playing around with when the MMIO regions
> > > of PCI assigned devices get direct mapped through KVM and start using
> > > memory slots and I found that the boot ROM on an e1000e card that I
> > > often use for testing causes the VM to hang when not directly mapped
> > > through a memory slot. This happens with both pci-assign and vfio-pci.
> > > Debugging further, I see the kernel instruction emulator decodes this
> > > and sets all the necessary flags and fragments for userspace to complete
> > > the access, but since it happened in real mode, vcpu_enter_guest always
> > > returns 1 and therefore KVM_RUN never exits to userspace and KVM gets
> > > stuck in an infinite loop re-handling this instruction.
> > >
> > > The above is pretty trivial and allows the ROM to work again. Is it
> > > correct? What other exceptions are we missing here that should allow an
> > > exit? This particular access generated a GP_VECTOR exception if we want
> > > to key on that somewhere. Thanks,
> > >
> > As far as I see the patch is nop. If handle_rmode_exception() returns 1
> > mmio_needed should be 0. Also if handle_rmode_exception() makes IO
> > according to the code qemu should exit with "KVM: exception 13 exit
> > (error code 0x0)" or something. Can you provide a ftrace for the hang?
>
> The real mode vector is GP_VECTOR, so handle_rmode_exception returns 1
> even though emulate_instruction returns EMULATE_DO_MMIO. Maybe the
Then #GP should be injected into a guest, which is incorrect of course.
> point at which handle_rmode_exception gets EMULATE_DO_MMIO from
> emulate_instruction is the point at which we should return 0.
Yes, this is likely what should be done here.
> I'll run
> an ftrace if it's still not clear how we're getting here. Thanks,
>
Yes please, I wonder what instruction is this. The code in
handle_exception() looks incorrect, but it is not clear to me me how to
fix it yet.
--
Gleb.
prev parent reply other threads:[~2012-12-15 16:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-14 23:42 vmx real mode emulated mmio? Alex Williamson
2012-12-15 8:07 ` Gleb Natapov
2012-12-15 15:54 ` Alex Williamson
2012-12-15 16:23 ` Gleb Natapov [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=20121215162337.GC4384@redhat.com \
--to=gleb@redhat.com \
--cc=alex.williamson@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.