[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.