kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: kvm@vger.kernel.org, mtosatti@redhat.com
Subject: Re: [PATCHv2 6/6] KVM: VMX: handle IO when emulation is due to #GP in real mode.
Date: Thu, 20 Dec 2012 18:43:25 +0200	[thread overview]
Message-ID: <20121220164325.GM29007@redhat.com> (raw)
In-Reply-To: <1356017141.10845.33.camel@ul30vt.home>

On Thu, Dec 20, 2012 at 08:25:41AM -0700, Alex Williamson wrote:
> On Thu, 2012-12-20 at 16:57 +0200, Gleb Natapov wrote:
> > With emulate_invalid_guest_state=0 if a vcpu is in real mode VMX can
> > enter the vcpu with smaller segment limit than guest configured.  If the
> > guest tries to access pass this limit it will get #GP at which point
> > instruction will be emulated with correct segment limit applied. If
> > during the emulation IO is detected it is not handled correctly. Vcpu
> > thread should exit to userspace to serve the IO, but it returns to the
> > guest instead.  Since emulation is not completed till userspace completes
> > the IO the faulty instruction is re-executed ad infinitum.
> > 
> > The patch fixes that by exiting to userspace if IO happens during
> > instruction emulation.
> 
> Thanks for finding the right fix Gleb.  This originally came about from
> an experiment in lazily mapping assigned device MMIO BARs.  That's
> something I think might still have value for conserving memory slots,
> but now I have to be aware of this bug.  That makes me wonder if we need
> to expose a capability for the fix.  I could also just avoid the lazy
> path if a device includes a ROM, but it's still difficult to know how
> long such a workaround is required.  Thanks,
> 
I do not like the idea to have capability flags for emulator bugs. We
have to many of those.  And It is hard to know at which point exactly
this capability should be set.  Case in point: apply this patch series
and the one it depends upon, but do not apply the last patch that actually
fixes the bug you've found. Run your test. It will work. Also the test
case will work on older kernels on AMD and modern Intel cpus with
unrestricted guest capability.
 
> Alex
> 
> > Reported-by: Alex Williamson <alex.williamson@redhat.com>
> > Signed-off-by: Gleb Natapov <gleb@redhat.com>
> > ---
> >  arch/x86/kvm/vmx.c |   75 ++++++++++++++++++++++++++++------------------------
> >  1 file changed, 41 insertions(+), 34 deletions(-)
> > 
> > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> > index a101dd4..ab5933f 100644
> > --- a/arch/x86/kvm/vmx.c
> > +++ b/arch/x86/kvm/vmx.c
> > @@ -4230,28 +4230,9 @@ static int vmx_set_tss_addr(struct kvm *kvm, unsigned int addr)
> >  	return 0;
> >  }
> >  
> > -static int handle_rmode_exception(struct kvm_vcpu *vcpu,
> > -				  int vec, u32 err_code)
> > +static bool rmode_exception(struct kvm_vcpu *vcpu, int vec) 
> >  {
> > -	/*
> > -	 * Instruction with address size override prefix opcode 0x67
> > -	 * Cause the #SS fault with 0 error code in VM86 mode.
> > -	 */
> > -	if (((vec == GP_VECTOR) || (vec == SS_VECTOR)) && err_code == 0)
> > -		if (emulate_instruction(vcpu, 0) == EMULATE_DONE)
> > -			return 1;
> > -	/*
> > -	 * Forward all other exceptions that are valid in real mode.
> > -	 * FIXME: Breaks guest debugging in real mode, needs to be fixed with
> > -	 *        the required debugging infrastructure rework.
> > -	 */
> >  	switch (vec) {
> > -	case DB_VECTOR:
> > -		if (vcpu->guest_debug &
> > -		    (KVM_GUESTDBG_SINGLESTEP | KVM_GUESTDBG_USE_HW_BP))
> > -			return 0;
> > -		kvm_queue_exception(vcpu, vec);
> > -		return 1;
> >  	case BP_VECTOR:
> >  		/*
> >  		 * Update instruction length as we may reinject the exception
> > @@ -4260,7 +4241,12 @@ static int handle_rmode_exception(struct kvm_vcpu *vcpu,
> >  		to_vmx(vcpu)->vcpu.arch.event_exit_inst_len =
> >  			vmcs_read32(VM_EXIT_INSTRUCTION_LEN);
> >  		if (vcpu->guest_debug & KVM_GUESTDBG_USE_SW_BP)
> > -			return 0;
> > +			return false;
> > +		/* fall through */
> > +	case DB_VECTOR:
> > +		if (vcpu->guest_debug &
> > +			(KVM_GUESTDBG_SINGLESTEP | KVM_GUESTDBG_USE_HW_BP))
> > +			return false;
> >  		/* fall through */
> >  	case DE_VECTOR:
> >  	case OF_VECTOR:
> > @@ -4270,10 +4256,37 @@ static int handle_rmode_exception(struct kvm_vcpu *vcpu,
> >  	case SS_VECTOR:
> >  	case GP_VECTOR:
> >  	case MF_VECTOR:
> > -		kvm_queue_exception(vcpu, vec);
> > -		return 1;
> > +		return true;
> > +	break;
> >  	}
> > -	return 0;
> > +	return false;
> > +}
> > +
> > +static int handle_rmode_exception(struct kvm_vcpu *vcpu,
> > +				  int vec, u32 err_code)
> > +{
> > +	/*
> > +	 * Instruction with address size override prefix opcode 0x67
> > +	 * Cause the #SS fault with 0 error code in VM86 mode.
> > +	 */
> > +	if (((vec == GP_VECTOR) || (vec == SS_VECTOR)) && err_code == 0) {
> > +		if (emulate_instruction(vcpu, 0) == EMULATE_DONE) {
> > +			if (vcpu->arch.halt_request) {
> > +				vcpu->arch.halt_request = 0;
> > +				return kvm_emulate_halt(vcpu);
> > +			}
> > +			return 1;
> > +		}
> > +		return 0;
> > +	}
> > +
> > +	/*
> > +	 * Forward all other exceptions that are valid in real mode.
> > +	 * FIXME: Breaks guest debugging in real mode, needs to be fixed with
> > +	 *        the required debugging infrastructure rework.
> > +	 */
> > +	kvm_queue_exception(vcpu, vec);
> > +	return 1;
> >  }
> >  
> >  /*
> > @@ -4361,17 +4374,11 @@ static int handle_exception(struct kvm_vcpu *vcpu)
> >  		return kvm_mmu_page_fault(vcpu, cr2, error_code, NULL, 0);
> >  	}
> >  
> > -	if (vmx->rmode.vm86_active &&
> > -	    handle_rmode_exception(vcpu, intr_info & INTR_INFO_VECTOR_MASK,
> > -								error_code)) {
> > -		if (vcpu->arch.halt_request) {
> > -			vcpu->arch.halt_request = 0;
> > -			return kvm_emulate_halt(vcpu);
> > -		}
> > -		return 1;
> > -	}
> > -
> >  	ex_no = intr_info & INTR_INFO_VECTOR_MASK;
> > +
> > +	if (vmx->rmode.vm86_active && rmode_exception(vcpu, ex_no))
> > +		return handle_rmode_exception(vcpu, ex_no, error_code);
> > +
> >  	switch (ex_no) {
> >  	case DB_VECTOR:
> >  		dr6 = vmcs_readl(EXIT_QUALIFICATION);
> 
> 

--
			Gleb.

  reply	other threads:[~2012-12-20 16:43 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-20 14:57 [PATCHv2 0/6] more VMX real mode emulation fixes Gleb Natapov
2012-12-20 14:57 ` [PATCHv2 1/6] KVM: emulator: drop RPL check from linearize() function Gleb Natapov
2013-02-11 16:58   ` Jan Kiszka
2013-02-11 17:25     ` Gleb Natapov
2013-02-11 17:31       ` Jan Kiszka
2013-02-11 17:40         ` Gleb Natapov
2013-02-11 17:50           ` Gleb Natapov
2013-02-11 18:05             ` Jan Kiszka
2013-02-11 18:40               ` Gleb Natapov
2012-12-20 14:57 ` [PATCHv2 2/6] KVM: emulator: implement fninit, fnstsw, fnstcw Gleb Natapov
2012-12-20 14:57 ` [PATCHv2 3/6] KVM: VMX: make rmode_segment_valid() more strict Gleb Natapov
2012-12-20 14:57 ` [PATCHv2 4/6] KVM: VMX: fix emulation of invalid guest state Gleb Natapov
2012-12-20 14:57 ` [PATCHv2 5/6] KVM: VMX: Do not fix segment register during vcpu initialization Gleb Natapov
2012-12-20 14:57 ` [PATCHv2 6/6] KVM: VMX: handle IO when emulation is due to #GP in real mode Gleb Natapov
2012-12-20 15:25   ` Alex Williamson
2012-12-20 16:43     ` Gleb Natapov [this message]
2012-12-20 22:58       ` Alex Williamson
2012-12-21  8:01         ` Gleb Natapov
2012-12-22 11:06     ` Avi Kivity
2012-12-23  9:44       ` Gleb Natapov
2013-01-03 12:53 ` [PATCHv2 0/6] more VMX real mode emulation fixes Marcelo Tosatti

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=20121220164325.GM29007@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).