| Message ID | 583703A60200007800121BA7@prv-mh.provo.novell.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 24/11/16 14:13, Jan Beulich wrote: > Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> There is an opposite problem on the Intel side, delivering some #UD with an error code (although the guest behaviour does appear to be correct, so perhaps hardware swallows it). I will do a companion fix. As this interacts with my 191 series, shall I put this patch into my series and rebase properly over it. ~Andrew
>>> On 24.11.16 at 15:19, <andrew.cooper3@citrix.com> wrote: > On 24/11/16 14:13, Jan Beulich wrote: >> Signed-off-by: Jan Beulich <jbeulich@suse.com> > > Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> > > There is an opposite problem on the Intel side, delivering some #UD with > an error code (although the guest behaviour does appear to be correct, > so perhaps hardware swallows it). I will do a companion fix. Oh - I did go through and checked the #GP-s, but didn't think of also checking the other way around. > As this interacts with my 191 series, shall I put this patch into my > series and rebase properly over it. Well, I would hope for the one here to still go in for 4.8, whereas your series is targeting 4.9 only aiui. Jan
On Thu, Nov 24, 2016 at 07:33:48AM -0700, Jan Beulich wrote: > >>> On 24.11.16 at 15:19, <andrew.cooper3@citrix.com> wrote: > > On 24/11/16 14:13, Jan Beulich wrote: > >> Signed-off-by: Jan Beulich <jbeulich@suse.com> > > > > Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> > > > > There is an opposite problem on the Intel side, delivering some #UD with > > an error code (although the guest behaviour does appear to be correct, > > so perhaps hardware swallows it). I will do a companion fix. > > Oh - I did go through and checked the #GP-s, but didn't think of > also checking the other way around. > > > As this interacts with my 191 series, shall I put this patch into my > > series and rebase properly over it. > > Well, I would hope for the one here to still go in for 4.8, whereas > your series is targeting 4.9 only aiui. Release-acked-by: Wei Liu <wei.liu2@citrix.com> Please apply this by Friday, otherwise it needs to be backported. > > Jan > >
On 24/11/16 14:33, Jan Beulich wrote: >>>> On 24.11.16 at 15:19, <andrew.cooper3@citrix.com> wrote: >> On 24/11/16 14:13, Jan Beulich wrote: >>> Signed-off-by: Jan Beulich <jbeulich@suse.com> >> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> >> >> There is an opposite problem on the Intel side, delivering some #UD with >> an error code (although the guest behaviour does appear to be correct, >> so perhaps hardware swallows it). I will do a companion fix. > Oh - I did go through and checked the #GP-s, but didn't think of > also checking the other way around. > >> As this interacts with my 191 series, shall I put this patch into my >> series and rebase properly over it. > Well, I would hope for the one here to still go in for 4.8, whereas > your series is targeting 4.9 only aiui. Either way, it is now currently in my series and I have rebased over it. If it goes in earlier, git will DTRT when rebasing onto a newer staging. ~Andrew
On 11/24/2016 09:13 AM, Jan Beulich wrote: > Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com> (even though it's already been applied)
--- a/xen/arch/x86/hvm/svm/svm.c +++ b/xen/arch/x86/hvm/svm/svm.c @@ -2029,7 +2029,7 @@ svm_vmexit_do_vmrun(struct cpu_user_regs if ( !nestedsvm_vmcb_map(v, vmcbaddr) ) { gdprintk(XENLOG_ERR, "VMRUN: mapping vmcb failed, injecting #GP\n"); - hvm_inject_hw_exception(TRAP_gp_fault, HVM_DELIVER_NO_ERROR_CODE); + hvm_inject_hw_exception(TRAP_gp_fault, 0); return; } @@ -2068,7 +2068,6 @@ svm_vmexit_do_vmload(struct vmcb_struct struct cpu_user_regs *regs, struct vcpu *v, uint64_t vmcbaddr) { - int ret; unsigned int inst_len; struct page_info *page; @@ -2078,8 +2077,8 @@ svm_vmexit_do_vmload(struct vmcb_struct if ( !nsvm_efer_svm_enabled(v) ) { gdprintk(XENLOG_ERR, "VMLOAD: nestedhvm disabled, injecting #UD\n"); - ret = TRAP_invalid_op; - goto inject; + hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE); + return; } page = nsvm_get_nvmcb_page(v, vmcbaddr); @@ -2087,8 +2086,8 @@ svm_vmexit_do_vmload(struct vmcb_struct { gdprintk(XENLOG_ERR, "VMLOAD: mapping failed, injecting #GP\n"); - ret = TRAP_gp_fault; - goto inject; + hvm_inject_hw_exception(TRAP_gp_fault, 0); + return; } svm_vmload_pa(page_to_maddr(page)); @@ -2098,11 +2097,6 @@ svm_vmexit_do_vmload(struct vmcb_struct v->arch.hvm_svm.vmcb_in_sync = 0; __update_guest_eip(regs, inst_len); - return; - - inject: - hvm_inject_hw_exception(ret, HVM_DELIVER_NO_ERROR_CODE); - return; } static void @@ -2110,7 +2104,6 @@ svm_vmexit_do_vmsave(struct vmcb_struct struct cpu_user_regs *regs, struct vcpu *v, uint64_t vmcbaddr) { - int ret; unsigned int inst_len; struct page_info *page; @@ -2120,8 +2113,8 @@ svm_vmexit_do_vmsave(struct vmcb_struct if ( !nsvm_efer_svm_enabled(v) ) { gdprintk(XENLOG_ERR, "VMSAVE: nestedhvm disabled, injecting #UD\n"); - ret = TRAP_invalid_op; - goto inject; + hvm_inject_hw_exception(TRAP_invalid_op, HVM_DELIVER_NO_ERROR_CODE); + return; } page = nsvm_get_nvmcb_page(v, vmcbaddr); @@ -2129,18 +2122,13 @@ svm_vmexit_do_vmsave(struct vmcb_struct { gdprintk(XENLOG_ERR, "VMSAVE: mapping vmcb failed, injecting #GP\n"); - ret = TRAP_gp_fault; - goto inject; + hvm_inject_hw_exception(TRAP_gp_fault, 0); + return; } svm_vmsave_pa(page_to_maddr(page)); put_page(page); __update_guest_eip(regs, inst_len); - return; - - inject: - hvm_inject_hw_exception(ret, HVM_DELIVER_NO_ERROR_CODE); - return; } static int svm_is_erratum_383(struct cpu_user_regs *regs)