From: Vern Hao <haoxing990@gmail.com>
To: Tom Lendacky <thomas.lendacky@amd.com>, Rik van Riel <riel@surriel.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, bp@alien8.de,
peterz@infradead.org, dave.hansen@linux.intel.com,
zhengqi.arch@bytedance.com, nadav.amit@gmail.com,
kernel-team@meta.com, linux-mm@kvack.org,
akpm@linux-foundation.org, jannh@google.com,
mhklinux@outlook.com, andrew.cooper3@citrix.com,
Manali Shukla <Manali.Shukla@amd.com>
Subject: Re: [PATCH v9 04/12] x86/mm: get INVLPGB count max from CPUID
Date: Thu, 13 Feb 2025 16:16:47 +0800 [thread overview]
Message-ID: <366195ff-3dd4-4d27-9091-6586d681ae13@gmail.com> (raw)
In-Reply-To: <93281f16-4237-b6d6-624e-cc805adb1c37@amd.com>
[-- Attachment #1: Type: text/plain, Size: 3154 bytes --]
On 2025/2/12 23:56, Tom Lendacky wrote:
> On 2/11/25 19:57, Vern Hao wrote:
>> On 2025/2/11 00:48, Rik van Riel wrote:
>>> On Mon, 2025-02-10 at 15:30 +0800, Vern Hao wrote:
>>>> I do some test on my Machine with AMD EPYC 7K83, these patches work
>>>> on my host, but failed on my guest with qemu.
>>>>
>>>> in host, use lscpu cmd, you can see invlpgb in flags, but in guest
>>>> no.
>>>>
>>>> So are you plan to support it in guest?
>>> How exactly did it fail in the guest?
>>>
>>> Did the guest simply not use INVLPGB because that
>>> CPUID flag was not presented in the CPUID that
>>> qemu shows to the guest, or did things crash somehow?
>> i support these patches in host and guest, and add this patch to support
>> cpuid flags in kvm.
>>
>> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
>> index db3838667466..fd21d9438137 100644
>> --- a/arch/x86/kvm/cpuid.c
>> +++ b/arch/x86/kvm/cpuid.c
>> @@ -488,7 +488,7 @@ static inline int __do_cpuid_func(struct
>> kvm_cpuid_entry2 *entry, u32 function,
>>
>> /* cpuid 0x80000008.ebx */
>> const u32 kvm_cpuid_8000_0008_ebx_x86_features =
>> - F(CLZERO) | F(XSAVEERPTR) |
>> + F(CLZERO) | F(XSAVEERPTR) | F(INVLPGB) |
>> F(WBNOINVD) | F(AMD_IBPB) | F(AMD_IBRS) | F(AMD_SSBD) |
>> F(VIRT_SSBD) |
>> F(AMD_SSB_NO) | F(AMD_STIBP) | F(AMD_STIBP_ALWAYS_ON);
>>
>> But in guest, use lscpu cmd, i still can not see invlpgb, so i just
>> wonder where is wrong ?
> Well, for one, the INVLPGB instruction has to be enabled in the VMCB in
> order for it to be used (unless it is an SEV-ES or SEV-SNP guest). Also,
> lscpu won't show "invlpgb" since the patches don't define the feature in
> the way that it would be visible via lscpu. You need to issue CPUID to
> see the bit is set or not. Also, you might need VMM support in order for
> that CPUID bit to be set in the guest.
>
> But, it will take hypervisor support to use INVLPGB in a non-SEV guest,
> since non-SEV guests do not use global ASIDs. In this case, the
> instruction will need to be intercepted and the hypervisor will need to
> determine how to process it.
>
> If you have an SEV guest, which use global ASIDs and use the same ASID
> for all vCPUs within a guest, you can use INVLPGB in the guest without
> issue and without needing to intercept the instruction.
>
> See "Guest Usage of INVLPGB" in AMD APM Vol 3 under the INVLPGB
> instruction documentation.
OK, Thanks a lot*.
*
*Obviously, my 5.10 version of the kernel KVM does not support this
CPUID well, i test it on upstream kernel, it works well.*
>
> Thanks,
> Tom
>
>>> My understanding is that while INVLPGB can work
>>> in guests, actually implementing that is a whole
>>> other can of worms, and definitely not something
>>> we should try to tackle at the same time as bare
>>> metal support.
>>>
>>> A TLB flush hypercall, with IRQ-less flushing on
>>> the hypervisor side will probably get us 90% of
>>> the way there, potentially with less overall
>>> complexity than actually supporting INVLPGB in
>>> the guest.
>>>
[-- Attachment #2: Type: text/html, Size: 4707 bytes --]
next prev parent reply other threads:[~2025-02-13 8:16 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-06 4:43 [PATCH v9 00/12] AMD broadcast TLB invalidation Rik van Riel
2025-02-06 4:43 ` [PATCH v9 01/12] x86/mm: make MMU_GATHER_RCU_TABLE_FREE unconditional Rik van Riel
2025-02-07 14:28 ` Brendan Jackman
2025-02-11 11:07 ` Peter Zijlstra
2025-02-11 12:10 ` Brendan Jackman
2025-02-11 20:23 ` Rik van Riel
2025-02-06 4:43 ` [PATCH v9 02/12] x86/mm: remove pv_ops.mmu.tlb_remove_table call Rik van Riel
2025-02-06 4:43 ` [PATCH v9 03/12] x86/mm: consolidate full flush threshold decision Rik van Riel
2025-02-07 14:50 ` Brendan Jackman
2025-02-07 20:22 ` Rik van Riel
2025-02-10 11:15 ` Brendan Jackman
2025-02-10 19:12 ` Rik van Riel
2025-02-06 4:43 ` [PATCH v9 04/12] x86/mm: get INVLPGB count max from CPUID Rik van Riel
2025-02-07 15:10 ` Brendan Jackman
2025-02-07 17:34 ` Brendan Jackman
2025-02-10 7:30 ` Vern Hao
2025-02-10 16:48 ` Rik van Riel
2025-02-12 1:18 ` Vern Hao
2025-02-12 1:57 ` Vern Hao
2025-02-12 15:56 ` Tom Lendacky
2025-02-13 8:16 ` Vern Hao [this message]
2025-02-06 4:43 ` [PATCH v9 05/12] x86/mm: add INVLPGB support code Rik van Riel
2025-02-06 4:43 ` [PATCH v9 06/12] x86/mm: use INVLPGB for kernel TLB flushes Rik van Riel
2025-02-07 16:03 ` Brendan Jackman
2025-02-07 20:50 ` Rik van Riel
2025-02-10 11:22 ` Brendan Jackman
2025-02-11 2:01 ` Rik van Riel
2025-02-06 4:43 ` [PATCH v9 07/12] x86/mm: use INVLPGB in flush_tlb_all Rik van Riel
2025-02-06 4:43 ` [PATCH v9 08/12] x86/mm: use broadcast TLB flushing for page reclaim TLB flushing Rik van Riel
2025-02-06 4:43 ` [PATCH v9 09/12] x86/mm: enable broadcast TLB invalidation for multi-threaded processes Rik van Riel
2025-02-10 14:15 ` Brendan Jackman
2025-02-11 3:07 ` Rik van Riel
2025-02-06 4:43 ` [PATCH v9 10/12] x86/mm: do targeted broadcast flushing from tlbbatch code Rik van Riel
2025-02-10 15:27 ` Brendan Jackman
2025-02-11 3:45 ` Rik van Riel
2025-02-11 10:02 ` Brendan Jackman
2025-02-11 20:21 ` Rik van Riel
2025-02-12 10:38 ` Brendan Jackman
2025-02-06 4:43 ` [PATCH v9 11/12] x86/mm: enable AMD translation cache extensions Rik van Riel
2025-02-06 4:43 ` [PATCH v9 12/12] x86/mm: only invalidate final translations with INVLPGB Rik van Riel
2025-02-06 10:16 ` [PATCH v9 00/12] AMD broadcast TLB invalidation Oleksandr Natalenko
2025-02-06 14:16 ` Rik van Riel
2025-02-06 14:23 ` Peter Zijlstra
2025-02-06 14:48 ` Rik van Riel
2025-02-07 8:16 ` Peter Zijlstra
2025-02-07 17:46 ` Rik van Riel
2025-02-07 18:23 ` Brendan Jackman
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=366195ff-3dd4-4d27-9091-6586d681ae13@gmail.com \
--to=haoxing990@gmail.com \
--cc=Manali.Shukla@amd.com \
--cc=akpm@linux-foundation.org \
--cc=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=jannh@google.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhklinux@outlook.com \
--cc=nadav.amit@gmail.com \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
--cc=thomas.lendacky@amd.com \
--cc=x86@kernel.org \
--cc=zhengqi.arch@bytedance.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