public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serge@hallyn.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Avi Kivity <avi@redhat.com>, KVM mailing list <kvm@vger.kernel.org>
Subject: Re: buggy emulate_int_real
Date: Tue, 12 Apr 2011 13:31:59 -0500	[thread overview]
Message-ID: <20110412183158.GA29423@hallyn.com> (raw)
In-Reply-To: <4DA472E5.9060807@siemens.com>

Quoting Jan Kiszka (jan.kiszka@siemens.com):
> On 2011-04-12 16:16, Avi Kivity wrote:
> > On 04/12/2011 05:12 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().
> >>
> >> Oops, right.  Disregard last email pls :)
> >>
> >> So is 'kvm_exception_is_soft(irq)' a reliable check?
> >>
> > 
> > No, need to check vcpu->arch.interrupt.soft instead.  Not sure about 
> > kvm_exception_is_soft().  Jan?
> 
> Jumping late on this, I don't understand the question. Reliable /wrt what?

As to whether we are supposed to increment eip or not.

thanks,
-serge

  reply	other threads:[~2011-04-12 18:32 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
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 [this message]
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=20110412183158.GA29423@hallyn.com \
    --to=serge@hallyn.com \
    --cc=avi@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    /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