From: Avi Kivity <avi@redhat.com>
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: KVM mailing list <kvm@vger.kernel.org>
Subject: Re: buggy emulate_int_real
Date: Tue, 12 Apr 2011 17:14:40 +0300 [thread overview]
Message-ID: <4DA45E50.90909@redhat.com> (raw)
In-Reply-To: <20110412135740.GA6456@hallyn.com>
On 04/12/2011 04:57 PM, Serge E. Hallyn wrote:
> Quoting Avi Kivity (avi@redhat.com):
> > On 04/12/2011 10:53 AM, Serge E. Hallyn wrote:
> > >Quoting Avi Kivity (avi@redhat.com):
> > >> On 04/09/2011 12:09 AM, Serge E. Hallyn wrote:
> > >> >Hi,
> > >> >
> > >> >at https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/747090, it was
> > >> >found that emulate_int_real() sometimes pushes the wrong eip when doing a
> > >> >int. Whereas with non-kvm qemu we push the next instruction after the
> > >> >int, with kvm we push the addr of the instruction itself.
> > >> >
> > >>
> > >>
> > >> The code says:
> > >>
> > >> c->src.val = c->eip;
> > >> emulate_push(ctxt, ops);
> > >> rc = writeback(ctxt, ops);
> > >> if (rc != X86EMUL_CONTINUE)
> > >> return rc;
> > >>
> > >> which appears to be the address of the next instruction from my
> > >> reading of the code (see how insn_fetch() increments c->eip).
> > >
> > >Nevertheless removing commits
> > >
> > > a92601bb707f6f49fd5563ef3d09928e70cc222e
> > > 63995653ade16deacaea5b49ceaf6376314593ac
> > > 6e154e56b4d7a6a28c54f0984e13d3f8defc4755
> > >
> > >changes the eip value being pushed. If you look at
> > >a92601bb707f6f49fd5563ef3d09928e70cc222e, you see:
> > >
> > > if (vmx->rmode.vm86_active) {
> > >- vmx->rmode.irq.pending = true;
> > >- vmx->rmode.irq.vector = nr;
> > >- vmx->rmode.irq.rip = kvm_rip_read(vcpu);
> > >- if (kvm_exception_is_soft(nr))
> > >- vmx->rmode.irq.rip +=
> > >- vmx->vcpu.arch.event_exit_inst_len;
> > >- intr_info |= INTR_TYPE_SOFT_INTR;
> > >- vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, intr_info);
> > >- vmcs_write32(VM_ENTRY_INSTRUCTION_LEN, 1);
> > >- kvm_rip_write(vcpu, vmx->rmode.irq.rip - 1);
> > >+ if (kvm_inject_realmode_interrupt(vcpu, nr) != EMULATE_DONE)
> > >+ kvm_make_request(KVM_REQ_TRIPLE_FAULT, vcpu);
> > > return;
> > > }
> > >
> > >but kvm_inject_realmode_interrupt() does not appear to increment
> > >vmx->rmode.irq.rip anywhere, as the code being replaced does.
> >
> > Ah, I see now. There are two cases, hard interrupt and soft
> > interrupts. I guess hard interrupts are handled fine, and the
> > failing case is
> >
> > guest executes INTn instruction in guest mode
> > vmx intercepts a page fault (say due to access to the IDT or the stack)
> > kvm notes that a soft interrupt was in progress (vmx_complete_interrupts)
> > kvm handles the exception
> > reinject the interrupt while reentering the guest
> >
> > so we do need something like
> >
> > if (soft)
> > vcpu->arch.emulate_ctxt.eip += inst_len;
> >
> > in kvm_inject_realmode_interrupt().
>
> But not always, so perhaps it would be better to still do this at
> the callers?
Possibly.
> For instance vmx_inject_nmi() didn't do it at all,
> and the other two callers only did it for a soft interrupt.
NMIs are always hard.
Perhaps have a new helper for this.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2011-04-12 14:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-08 21:09 buggy emulate_int_real Serge E. Hallyn
2011-04-10 8:30 ` Avi Kivity
2011-04-12 7:53 ` Serge E. Hallyn
2011-04-12 8:02 ` Avi Kivity
2011-04-12 13:57 ` Serge E. Hallyn
2011-04-12 14:14 ` Avi Kivity [this message]
2011-04-12 14:12 ` Serge E. Hallyn
2011-04-12 14:16 ` Avi Kivity
2011-04-12 15:42 ` Jan Kiszka
2011-04-12 18:31 ` Serge E. Hallyn
2011-04-12 20:51 ` Jan Kiszka
2011-04-12 21:25 ` Serge E. Hallyn
2011-04-12 22:39 ` Serge E. Hallyn
2011-04-12 23:31 ` Jan Kiszka
2011-04-13 13:24 ` Serge E. Hallyn
2011-04-13 13:29 ` Avi Kivity
2011-04-13 13:52 ` Serge E. Hallyn
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=4DA45E50.90909@redhat.com \
--to=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=serge@hallyn.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox