From: Gleb Natapov <gleb@redhat.com>
To: Orit Wasserman <oritw@il.ibm.com>
Cc: Abel Gordon <ABELG@il.ibm.com>,
aliguori@us.ibm.com, Ben-Ami Yassour1 <BENAMI@il.ibm.com>,
kvm@vger.kernel.org, mdday@us.ibm.com,
Muli Ben-Yehuda <MULI@il.ibm.com>
Subject: Re: [PATCH 5/5] Nested VMX patch 5 implements vmlaunch and vmresume
Date: Thu, 22 Oct 2009 11:04:58 +0200 [thread overview]
Message-ID: <20091022090457.GU29477@redhat.com> (raw)
In-Reply-To: <OF8FB5B240.2FFD1FA4-ONC2257656.004A6956-C2257656.0050E8C3@il.ibm.com>
On Wed, Oct 21, 2009 at 04:43:44PM +0200, Orit Wasserman wrote:
> > > @@ -4641,10 +4955,13 @@ static void vmx_complete_interrupts(struct
> > vcpu_vmx *vmx)
> > > int type;
> > > bool idtv_info_valid;
> > >
> > > - exit_intr_info = vmcs_read32(VM_EXIT_INTR_INFO);
> > > -
> > > vmx->exit_reason = vmcs_read32(VM_EXIT_REASON);
> > >
> > > + if (vmx->nested.nested_mode)
> > > + return;
> > > +
> > Why return here? What the function does that should not be done in
> > nested mode?
> In nested mode L0 injects an interrupt to L2 only in one scenario,
> if there is an IDT_VALID event and L0 decides to run L2 again and not to
> switch back to L1.
> In all other cases the injection is handled by L1.
This is exactly the kind of scenario that is handled by
vmx_complete_interrupts(). (vmx|svm)_complete_interrups() store
pending event in arch agnostic way and re-injection is handled by
x86.c You bypass this logic by inserting return here and introducing
nested_handle_valid_idt() function below.
> >
> > > + exit_intr_info = vmcs_read32(VM_EXIT_INTR_INFO);
> > > +
> > > /* Handle machine checks before interrupts are enabled */
> > > if ((vmx->exit_reason == EXIT_REASON_MCE_DURING_VMENTRY)
> > > || (vmx->exit_reason == EXIT_REASON_EXCEPTION_NMI
> > > @@ -4747,6 +5064,60 @@ static void fixup_rmode_irq(struct vcpu_vmx
> *vmx)
> > > | vmx->rmode.irq.vector;
> > > }
> > >
> > > +static int nested_handle_valid_idt(struct kvm_vcpu *vcpu)
> > > +{
> > It seems by this function you are trying to bypass general event
> > reinjection logic. Why?
> See above.
The logic implemented by this function is handled in x86.c in arch
agnostic way. Is there something wrong with this?
> > > + vmx->launched = vmx->nested.l2_state->launched;
> > > +
> > Can you explain why ->launched logic is needed?
> It is possible L1 called vmlaunch but we didn't actually run L2 (for
> example there was an interrupt and
> enable_irq_window switched back to L1 before running L2). L1 thinks the
> vmlaunch was successful and call vmresume in the next time
> but KVM needs to call vmlaunch for L2.
handle_vmlauch() and handle_vmresume() are exactly the same. Why KVM needs
to run one and not the other?
> > > +static int nested_vmx_vmexit(struct kvm_vcpu *vcpu,
> > > + bool is_interrupt)
> > > +{
> > > + struct vcpu_vmx *vmx = to_vmx(vcpu);
> > > + int initial_pfu_active = vcpu->fpu_active;
> > > +
> > > + if (!vmx->nested.nested_mode) {
> > > + printk(KERN_INFO "WARNING: %s called but not in nested mode\n",
> > > + __func__);
> > > + return 0;
> > > + }
> > > +
> > > + save_msrs(vmx->guest_msrs, vmx->save_nmsrs);
> > > +
> > > + sync_cached_regs_to_vmcs(vcpu);
> > > +
> > > + if (!nested_map_shadow_vmcs(vcpu)) {
> > > + printk(KERN_INFO "Error mapping shadow vmcs\n");
> > > + set_rflags_to_vmx_fail_valid(vcpu);
> > Error during vmexit should set abort flag, not change flags.
> I think this is more a vmlaunch/vmresume error (in the code that switch
> back to L1).
How is this vmlaunch/vmresume error? This function is called to exit
from L2 guest while on L2 vcms. It is called asynchronously in respect
to L2 guest and you modify L2 guest rflags register at unpredictable
place here.
--
Gleb.
next prev parent reply other threads:[~2009-10-22 9:04 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-15 14:41 Nested VMX support v3 oritw
2009-10-15 14:41 ` [PATCH 1/5] Nested VMX patch 1 implements vmon and vmoff oritw
2009-10-15 14:41 ` [PATCH 2/5] Nested VMX patch 2 implements vmclear oritw
2009-10-15 14:41 ` [PATCH 3/5] Nested VMX patch 3 implements vmptrld and vmptrst oritw
2009-10-15 14:41 ` [PATCH 4/5] Nested VMX patch 4 implements vmread and vmwrite oritw
2009-10-15 14:41 ` [PATCH 5/5] Nested VMX patch 5 implements vmlaunch and vmresume oritw
2009-10-19 17:29 ` Gleb Natapov
2009-10-21 14:43 ` Orit Wasserman
2009-10-22 9:04 ` Gleb Natapov [this message]
2009-10-22 15:46 ` Orit Wasserman
2009-10-25 9:44 ` Gleb Natapov
2009-10-28 16:23 ` Orit Wasserman
2009-10-29 17:31 ` Gleb Natapov
2009-11-09 9:33 ` Abel Gordon
2009-10-22 10:55 ` Avi Kivity
2009-10-20 4:56 ` Avi Kivity
2009-10-22 12:56 ` Orit Wasserman
2009-10-19 13:17 ` [PATCH 4/5] Nested VMX patch 4 implements vmread and vmwrite Gleb Natapov
2009-10-21 13:32 ` Orit Wasserman
2009-10-20 4:44 ` Avi Kivity
2009-10-22 12:50 ` Orit Wasserman
2009-10-19 11:17 ` [PATCH 3/5] Nested VMX patch 3 implements vmptrld and vmptrst Gleb Natapov
2009-10-21 13:27 ` Orit Wasserman
2009-10-19 12:59 ` Gleb Natapov
2009-10-21 13:28 ` Orit Wasserman
2009-10-20 4:24 ` Avi Kivity
2009-10-22 12:48 ` Orit Wasserman
2009-10-20 4:06 ` [PATCH 2/5] Nested VMX patch 2 implements vmclear Avi Kivity
2009-10-21 14:56 ` Orit Wasserman
2009-10-20 4:00 ` [PATCH 1/5] Nested VMX patch 1 implements vmon and vmoff Avi Kivity
2009-10-22 12:41 ` Orit Wasserman
2009-10-19 10:47 ` Nested VMX support v3 Gleb Natapov
2009-10-20 3:30 ` Avi Kivity
2009-10-21 14:50 ` Orit Wasserman
-- strict thread matches above, loose matches on Subject: below --
2009-09-30 13:32 Nested VMX support v2 oritw
2009-09-30 13:32 ` [PATCH 1/5] Nested VMX patch 1 implements vmon and vmoff oritw
2009-09-30 13:32 ` [PATCH 2/5] Nested VMX patch 2 implements vmclear oritw
2009-09-30 13:32 ` [PATCH 3/5] Nested VMX patch 3 implements vmptrld and vmptrst oritw
2009-09-30 13:32 ` [PATCH 4/5] Nested VMX patch 4 implements vmread and vmwrite oritw
2009-09-30 13:32 ` [PATCH 5/5] Nested VMX patch 5 implements vmlaunch and vmresume oritw
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=20091022090457.GU29477@redhat.com \
--to=gleb@redhat.com \
--cc=ABELG@il.ibm.com \
--cc=BENAMI@il.ibm.com \
--cc=MULI@il.ibm.com \
--cc=aliguori@us.ibm.com \
--cc=kvm@vger.kernel.org \
--cc=mdday@us.ibm.com \
--cc=oritw@il.ibm.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).