On 02/20/2017 05:28 AM, Andrew Cooper wrote:
> The current hvm_msr_{read,write}_intercept() infrastructure calls
> hvm_inject_hw_exception() directly to latch a fault, and returns
> X86EMUL_EXCEPTION to its caller.
>
> This behaviour is problematic for the hvmemul_{read,write}_msr() paths, as the
> fault is raised behind the back of the x86 emulator.
>
> Alter the behaviour so hvm_msr_{read,write}_intercept() simply returns
> X86EMUL_EXCEPTION, leaving the callers to actually inject the #GP fault.
>
> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
> Acked-by: Kevin Tian <kevin.t...@intel.com>
> Reviewed-by: Jan Beulich <jbeul...@suse.com>> > diff --git a/xen/arch/x86/hvm/svm/svm.c b/xen/arch/x86/hvm/svm/svm.c > index 894c457..b864535 100644 > --- a/xen/arch/x86/hvm/svm/svm.c > +++ b/xen/arch/x86/hvm/svm/svm.c > @@ -1744,7 +1744,6 @@ static int svm_msr_read_intercept(unsigned int msr, > uint64_t *msr_content) > return X86EMUL_OKAY; > > gpf: > - hvm_inject_hw_exception(TRAP_gp_fault, 0); > return X86EMUL_EXCEPTION; > } > > @@ -1897,7 +1896,6 @@ static int svm_msr_write_intercept(unsigned int msr, > uint64_t msr_content) > return result; > > gpf: > - hvm_inject_hw_exception(TRAP_gp_fault, 0); > return X86EMUL_EXCEPTION; > } The label can be dropped with a direct return instead of a 'goto'. Either way Reviewed-by: Boris Ostrovsky <boris.ostrov...@oracle.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
