mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	Oliver Upton <oupton@google.com>
Subject: Re: [GIT PULL] KVM changes for Linux 5.6-rc4
Date: Tue, 3 Mar 2020 14:07:00 +0100	[thread overview]
Message-ID: <9bb75cdc-961e-0d83-0546-342298517496@redhat.com> (raw)
In-Reply-To: <87tv35fv5t.fsf@vitty.brq.redhat.com>

On 03/03/20 14:02, Vitaly Kuznetsov wrote:
> Right you are,
> 
> a big hammer like
> 
> diff --git a/arch/x86/include/asm/kvm_emulate.h b/arch/x86/include/asm/kvm_emulate.h
> index 2a8f2bd..52c9bce 100644
> --- a/arch/x86/include/asm/kvm_emulate.h
> +++ b/arch/x86/include/asm/kvm_emulate.h
> @@ -324,14 +324,6 @@ struct x86_emulate_ctxt {
>          */
>  
>         /* current opcode length in bytes */
> -       u8 opcode_len;
> -       u8 b;
> -       u8 intercept;
> -       u8 op_bytes;
> -       u8 ad_bytes;
> -       struct operand src;
> -       struct operand src2;
> -       struct operand dst;
>         union {
>                 int (*execute)(struct x86_emulate_ctxt *ctxt);
>                 fastop_t fop;
> @@ -343,6 +335,14 @@ struct x86_emulate_ctxt {
>          * or elsewhere
>          */
>         bool rip_relative;
> +       u8 opcode_len;
> +       u8 b;
> +       u8 intercept;
> +       u8 op_bytes;
> +       u8 ad_bytes;
> +       struct operand src;
> +       struct operand src2;
> +       struct operand dst;
>         u8 rex_prefix;
>         u8 lock_prefix;
>         u8 rep_prefix;
> 
> seems to make the issue go away. (For those wondering why fielf
> shuffling makes a difference: init_decode_cache() clears
> [rip_relative, modrm) range) How did this even work before...
> (I'm still looking at the code, stay tuned...)

On AMD, probably because all these instructions were normally trapped by L1.

Of these, however, most need not be zeroed again. op_bytes, ad_bytes,
opcode_len and b are initialized by x86_decode_insn, and dst/src/src2
also by decode_operand.  So only intercept is affected, adding
"ctxt->intercept = x86_intercept_none" should be enough.

Paolo


  reply	other threads:[~2020-03-03 13:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-24 18:57 Paolo Bonzini
2020-02-24 20:25 ` pr-tracker-bot
2020-03-02 18:40 ` Vitaly Kuznetsov
2020-03-03 10:58   ` Paolo Bonzini
2020-03-03 13:02     ` Vitaly Kuznetsov
2020-03-03 13:07       ` Paolo Bonzini [this message]
2020-03-03 13:38         ` Vitaly Kuznetsov

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=9bb75cdc-961e-0d83-0546-342298517496@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oupton@google.com \
    --cc=vkuznets@redhat.com \
    /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

all inboxes | Powered by JetHome®