From: Takahiro Itazuri <itazur@amazon.com>
To: Sean Christopherson <seanjc@google.com>,
Eric Northup <digitaleric@google.com>,
Eric Northup <digitaleric@gmail.com>,
Jon Cargille <jcargill@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Jim Mattson <jmattson@google.com>
Cc: <kvm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<x86@kernel.org>, Takahiro Itazuri <zulinx86@gmail.com>,
Takahiro Itazuri <itazur@amazon.com>
Subject: Re: [PATCH 1/1] KVM: pass through CPUID(0x80000006)
Date: Fri, 7 Jul 2023 12:41:07 +0100 [thread overview]
Message-ID: <20230707114107.73019-1-itazur@amazon.com> (raw)
In-Reply-To: <20200415023726.GD12547@linux.intel.com>
Please forgive me if this is an absurd question.
Date: Tue, 14 Apr 2020 19:37:26 -0700
From: Sean Christopherson <sean.j.christopherson@intel.com>
> Return the host's L2 cache and TLB information for CPUID.0x80000006
> instead of zeroing out the entry as part of KVM_GET_SUPPORTED_CPUID.
> This allows a userspace VMM to feed KVM_GET_SUPPORTED_CPUID's output
> directly into KVM_SET_CPUID2 (without breaking the guest).
I noticed that CPUID 0x80000005 also returns cache information (L1 Cache
and TLB Information) when looking at AMD APM, while it is marked
reserved on Intel SDM. What do you think about passing through CPUID
0x80000005 to guests?
To be honest, I'm not sure if it is harmless from security and
performance perspectives in the first place.
Regard security aspect, I'm a bit concerned that it could help malicious
guests to know something to allow cache side channel attacks. However,
CPUID 0x80000006 has already passed through L2 Cache and TLB and L3
Cache Information. If passing through CPUID 0x80000006 is really fine,
I'm guessing it is the case with CPUID 0x80000005 as well.
In terms of performance, as far as I know, some softwares utilizes cache
information to achieve better performance. To simply put, by letting
guests know cache information, they may gain some benefits. Having said
that, if I understand correctly, guests can be scheduled on CPUs that do
not belong to the same group of CPUs that they run last time, unless
guests are pinned to a specific set of host physical CPUs. In such
cases, guests may not benefit from using cache information.
If I'm missing something or say something wrong, I'd appreciate it if
you could correct me. If it sounds no problem, I'd like to send a patch
for it.
Best regards,
Takahiro Itazuri
next prev parent reply other threads:[~2023-07-07 11:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-15 1:23 [PATCH 1/1] KVM: pass through CPUID(0x80000006) Jon Cargille
2020-04-15 2:37 ` Sean Christopherson
2020-04-15 2:51 ` Sean Christopherson
2020-04-15 5:27 ` Eric Northup
2020-04-15 14:52 ` Paolo Bonzini
2020-04-15 17:27 ` Jon Cargille
[not found] ` <CANxmayh4P5hhbJPxAnA2nvbzZC9EwFPeVCxDrkHzu8h6Y7JPPQ@mail.gmail.com>
2020-04-15 17:32 ` Sean Christopherson
2023-07-07 11:41 ` Takahiro Itazuri [this message]
2023-07-12 15:58 ` Sean Christopherson
2023-07-12 17:02 ` Takahiro Itazuri
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=20230707114107.73019-1-itazur@amazon.com \
--to=itazur@amazon.com \
--cc=digitaleric@gmail.com \
--cc=digitaleric@google.com \
--cc=jcargill@google.com \
--cc=jmattson@google.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=seanjc@google.com \
--cc=x86@kernel.org \
--cc=zulinx86@gmail.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