|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [RFC V0 PATCH 1/1] Replace handle_mmio calls in svm/vmx
>>> On 23.08.14 at 03:15, <mukesh.rathor@xxxxxxxxxx> wrote:
> --- a/xen/arch/x86/hvm/emulate.c
> +++ b/xen/arch/x86/hvm/emulate.c
> @@ -1252,6 +1252,32 @@ void hvm_emulate_prepare(
> hvmemul_get_seg_reg(x86_seg_ss, hvmemul_ctxt);
> }
>
> +void hvm_emulate(struct cpu_user_regs *regs)
This surely is too generic a name.
> +{
> + int rc;
> + struct hvm_emulate_ctxt ctxt;
> +
> + hvm_emulate_prepare(&ctxt, regs);
> + rc = hvm_emulate_one(&ctxt);
As said in an earlier mail, I'm not sure this is the right thing to do
(namely continuing to use the full hvm_emulate_ops).
> + case X86EMUL_EXCEPTION:
> + {
> + uint8_t vector = ctxt.exn_pending ? ctxt.exn_vector : TRAP_gp_fault;
> + int32_t errcode = ctxt.exn_pending ? ctxt.exn_error_code : 0;
> + hvm_inject_hw_exception(vector, errcode);
This looks ugly. Either do this with if/else, or put the conditional
operators right as function arguments. (And style-wise if it
remained the way it is it would at least need a blank line between
declarations and statements.)
> --- a/xen/arch/x86/hvm/svm/svm.c
> +++ b/xen/arch/x86/hvm/svm/svm.c
> @@ -2475,16 +2475,16 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
> if ( handle_pio(port, bytes, dir) )
> __update_guest_eip(regs, vmcb->exitinfo2 - vmcb->rip);
> }
> - else if ( !handle_mmio() )
> - hvm_inject_hw_exception(TRAP_gp_fault, 0);
> + else
> + hvm_emulate(regs);
As said in the earlier mail, I think there is a reason for this to call
handle_mmio().
> case VMEXIT_CR0_READ ... VMEXIT_CR15_READ:
> case VMEXIT_CR0_WRITE ... VMEXIT_CR15_WRITE:
> if ( cpu_has_svm_decode && (vmcb->exitinfo1 & (1ULL << 63)) )
> svm_vmexit_do_cr_access(vmcb, regs);
> - else if ( !handle_mmio() )
> - hvm_inject_hw_exception(TRAP_gp_fault, 0);
> + else
> + hvm_emulate(regs);
While this one indeed doesn't need it, nor does it (as said above)
need the full hvm_emulate_ops.
> @@ -2493,8 +2493,8 @@ void svm_vmexit_handler(struct cpu_user_regs *regs)
> svm_invlpg_intercept(vmcb->exitinfo1);
> __update_guest_eip(regs, vmcb->nextrip - vmcb->rip);
> }
> - else if ( !handle_mmio() )
> - hvm_inject_hw_exception(TRAP_gp_fault, 0);
> + else
> + hvm_emulate(regs);
Same here.
> --- a/xen/arch/x86/hvm/vmx/vmx.c
> +++ b/xen/arch/x86/hvm/vmx/vmx.c
> @@ -3008,8 +3008,8 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
> break;
>
> case EXIT_REASON_APIC_ACCESS:
> - if ( !vmx_handle_eoi_write() && !handle_mmio() )
> - hvm_inject_hw_exception(TRAP_gp_fault, 0);
> + if ( !vmx_handle_eoi_write() )
> + hvm_emulate(regs);
How can this not need handle_mmio()? The LAPIC page is an
(emulated) MMIO one after all.
> @@ -3026,11 +3026,7 @@ void vmx_vmexit_handler(struct cpu_user_regs *regs)
> case EXIT_REASON_IO_INSTRUCTION:
> __vmread(EXIT_QUALIFICATION, &exit_qualification);
> if ( exit_qualification & 0x10 )
> - {
> - /* INS, OUTS */
> - if ( !handle_mmio() )
> - hvm_inject_hw_exception(TRAP_gp_fault, 0);
> - }
> + hvm_emulate(regs); /* INS, OUTS */
Same as for AMD's IOIO case.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |