xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Jan Beulich" <JBeulich@suse.com>
To: Mukesh Rathor <mukesh.rathor@oracle.com>
Cc: xen-devel@lists.xenproject.org, roger.pau@citrix.com
Subject: Re: [RFC V0 PATCH 1/1] Replace handle_mmio calls in svm/vmx
Date: Mon, 25 Aug 2014 09:28:40 +0100	[thread overview]
Message-ID: <53FB0FD8020000780002D0FF@mail.emea.novell.com> (raw)
In-Reply-To: <1408756502-16647-2-git-send-email-mukesh.rathor@oracle.com>

>>> On 23.08.14 at 03:15, <mukesh.rathor@oracle.com> 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

      parent reply	other threads:[~2014-08-25  8:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-23  1:15 [RFC V0 PATCH 0/1] Replace handle_mmio calls in svm/vmx Mukesh Rathor
2014-08-23  1:15 ` [RFC V0 PATCH 1/1] " Mukesh Rathor
2014-08-23 13:26   ` Andrew Cooper
2014-08-25  8:28   ` Jan Beulich [this message]

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=53FB0FD8020000780002D0FF@mail.emea.novell.com \
    --to=jbeulich@suse.com \
    --cc=mukesh.rathor@oracle.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /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).