From: Sean Christopherson <seanjc@google.com>
To: Jim Mattson <jmattson@google.com>
Cc: Tina Zhang <zhang_wei@open-hieco.net>,
mlevitsk@redhat.com, Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, Shuah Khan <shuah@kernel.org>,
zhouyanjing@hygon.cn, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] KVM: nSVM: Expose DecodeAssists to L1
Date: Tue, 7 Jul 2026 08:37:43 -0700 [thread overview]
Message-ID: <ak0dRzS4Ap-JREvg@google.com> (raw)
In-Reply-To: <CALMp9eTycB8Z94V8j-xyfDeah5KaJypRrPfFNHfQSUzgrr7FkQ@mail.gmail.com>
On Tue, Jul 07, 2026, Jim Mattson wrote:
> On Tue, Jul 7, 2026 at 7:41 AM Sean Christopherson <seanjc@google.com> wrote:
> >
> > insn = ctxt->fetch.data;
> > if (ctxt->eip == kvm_rip_read(vcpu))
> > insn_len = ctxt->fetch.end - ctxt->fetch.ptr;
> >
> > for (len = X86_MAX_INSTRUCTION_LENGTH - insn_len; len >= 0; len--) {
> > if (!kvm_fetch_guest_virt(vcpu, kvm_rip_read(vcpu) + insn_len,
> > &insn[insn_len], len, NULL))
> > break;
> > }
>
> This split doesn't bother you?
What split? Do you mean reading some bytes from the emulator, and some at the
time of #VMEXIT? If so: no. IMO, the most important thing in practice is to
capture the actual bytes used to decode the instruction that led to the #NPF.
Exactly how and when the "CPU" reads the bytes is a micro-architectural detail,
so I don't have any qualms from an architectural-correctness perspective.
next prev parent reply other threads:[~2026-07-07 15:37 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 12:52 [PATCH 0/2] KVM: nSVM: Expose DecodeAssists to L1 Tina Zhang
2026-06-29 12:52 ` [PATCH 1/2] KVM: nSVM: Virtualize DecodeAssists for nested guests Tina Zhang
2026-06-29 13:12 ` sashiko-bot
2026-06-30 15:11 ` Jim Mattson
2026-06-29 12:52 ` [PATCH 2/2] KVM: selftests: Add nested SVM DecodeAssists test Tina Zhang
2026-06-30 15:52 ` [PATCH 0/2] KVM: nSVM: Expose DecodeAssists to L1 Jim Mattson
2026-07-06 22:10 ` mlevitsk
2026-07-07 0:01 ` Tina Zhang
2026-07-07 1:32 ` Jim Mattson
2026-07-07 2:44 ` Tina Zhang
2026-07-07 3:21 ` Sean Christopherson
2026-07-07 3:25 ` Jim Mattson
2026-07-07 3:32 ` Jim Mattson
2026-07-07 14:42 ` Sean Christopherson
2026-07-07 15:19 ` Jim Mattson
2026-07-07 15:47 ` Sean Christopherson
2026-07-07 18:56 ` Jim Mattson
2026-07-07 14:41 ` Sean Christopherson
2026-07-07 15:24 ` Jim Mattson
2026-07-07 15:37 ` Sean Christopherson [this message]
2026-07-07 18:23 ` Jim Mattson
2026-07-07 19:16 ` Sean Christopherson
2026-07-08 23:21 ` Venkatesh Srinivas
2026-07-09 14:08 ` Sean Christopherson
2026-07-07 22:34 ` Yosry Ahmed
2026-07-08 0:53 ` Tina Zhang
2026-07-08 14:04 ` Sean Christopherson
2026-07-08 17:47 ` Yosry Ahmed
2026-07-09 1:00 ` Tina Zhang
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=ak0dRzS4Ap-JREvg@google.com \
--to=seanjc@google.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mlevitsk@redhat.com \
--cc=pbonzini@redhat.com \
--cc=shuah@kernel.org \
--cc=zhang_wei@open-hieco.net \
--cc=zhouyanjing@hygon.cn \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.