From: Borislav Petkov <bp@alien8.de>
To: Neeraj Upadhyay <Neeraj.Upadhyay@amd.com>
Cc: Dave Hansen <dave.hansen@intel.com>,
linux-kernel@vger.kernel.org, tglx@linutronix.de,
mingo@redhat.com, dave.hansen@linux.intel.com,
Thomas.Lendacky@amd.com, nikunj@amd.com, Santosh.Shukla@amd.com,
Vasant.Hegde@amd.com, Suravee.Suthikulpanit@amd.com,
David.Kaplan@amd.com, x86@kernel.org, hpa@zytor.com,
peterz@infradead.org, seanjc@google.com, pbonzini@redhat.com,
kvm@vger.kernel.org
Subject: Re: [RFC 02/14] x86/apic: Initialize Secure AVIC APIC backing page
Date: Thu, 24 Oct 2024 14:59:47 +0200 [thread overview]
Message-ID: <20241024125947.GDZxpEw9BLJ46B5VKC@fat_crate.local> (raw)
In-Reply-To: <358df653-e572-4e76-954a-15b230d09263@amd.com>
On Thu, Oct 24, 2024 at 06:01:16PM +0530, Neeraj Upadhyay wrote:
> With Secure AVIC enabled, source vCPU directly writes to the Interrupt
> Request Register (IRR) offset in the target CPU's backing page. So, the IPI
> is directly requested in target vCPU's backing page by source vCPU context
> and not by HV.
So the source vCPU will fault in the target vCPU's backing page if it is not
there anymore. And if it is part of a 2M translation, the likelihood that it
is there is higher.
> As I clarified above, it's the source vCPU which need to load each backing
> page.
So if we have 4K backing pages, the source vCPU will fault-in the target's
respective backing page into its TLB and send the IPI. And if it is an IPI to
multiple vCPUs, then it will have to fault in each vCPU's backing page in
succession.
However, when the target vCPU gets to VMRUN, the backing page will have to be
faulted in into the target vCPU's TLB too.
And this is the same with a 2M backing page - the target vCPUs will have to
fault that 2M page translation too.
But then if the target vCPU wants to send IPIs itself, the 2M backing pages
will be there already. Hmmm.
> I don't have the data at this point. That is the reason I will send this
> contiguous allocation as a separate patch (if required) when I can get data
> on some workloads which are impacted by this.
Yes, that would clarify whether something more involved than simply using 4K
pages is needed.
> For smp_call_function_many(), where a source CPU sends IPI to multiple CPUs,
> source CPU writes to backing pages of different target CPUs within this function.
> So, accesses have temporal locality. For other use cases, I need to enable
> perf with Secure AVIC to collect the TLB misses on a IPI benchmark and get
> back with the numbers.
Right, I can see some TLB walks getting avoided if you have a single 2M page
but without actually measuring it, I don't know. If I had to venture a guess,
it probably won't show any difference but who knows...
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2024-10-24 13:00 UTC|newest]
Thread overview: 81+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-13 11:36 [RFC 00/14] AMD: Add Secure AVIC Guest Support Neeraj Upadhyay
2024-09-13 11:36 ` [RFC 01/14] x86/apic: Add new driver for Secure AVIC Neeraj Upadhyay
2024-10-08 19:15 ` Borislav Petkov
2024-10-09 1:56 ` Neeraj Upadhyay
2024-10-09 5:23 ` Borislav Petkov
2024-10-09 6:01 ` Neeraj Upadhyay
2024-10-09 10:38 ` Borislav Petkov
2024-10-09 11:00 ` Neeraj Upadhyay
2024-10-09 11:02 ` Borislav Petkov
2024-10-09 12:38 ` Neeraj Upadhyay
2024-10-09 13:15 ` Tom Lendacky
2024-10-09 13:50 ` Neeraj Upadhyay
2024-10-09 10:10 ` Kirill A. Shutemov
2024-10-09 10:42 ` Borislav Petkov
2024-10-09 11:03 ` Kirill A. Shutemov
2024-10-09 11:22 ` Borislav Petkov
2024-10-09 12:12 ` Kirill A. Shutemov
2024-10-09 13:53 ` Borislav Petkov
2024-10-11 7:29 ` Kirill A. Shutemov
2024-11-18 21:45 ` Melody (Huibo) Wang
2024-11-21 5:05 ` Neeraj Upadhyay
2024-11-21 5:41 ` Borislav Petkov
2024-11-21 8:03 ` Neeraj Upadhyay
2024-11-21 10:53 ` Borislav Petkov
2024-11-25 7:21 ` Neeraj Upadhyay
2024-11-25 10:08 ` Borislav Petkov
2024-11-25 11:16 ` Neeraj Upadhyay
2024-09-13 11:36 ` [RFC 02/14] x86/apic: Initialize Secure AVIC APIC backing page Neeraj Upadhyay
2024-10-09 15:27 ` Dave Hansen
2024-10-09 16:31 ` Neeraj Upadhyay
2024-10-09 17:03 ` Dave Hansen
2024-10-09 17:52 ` Neeraj Upadhyay
2024-10-23 16:30 ` Borislav Petkov
2024-10-24 4:01 ` Neeraj Upadhyay
2024-10-24 11:49 ` Borislav Petkov
2024-10-24 12:31 ` Neeraj Upadhyay
2024-10-24 12:59 ` Borislav Petkov [this message]
2024-10-23 16:36 ` Borislav Petkov
2024-10-24 3:24 ` Neeraj Upadhyay
2024-09-13 11:36 ` [RFC 03/14] x86/apic: Populate .read()/.write() callbacks of Secure AVIC driver Neeraj Upadhyay
2024-11-06 18:16 ` Borislav Petkov
2024-11-07 3:32 ` Neeraj Upadhyay
2024-11-07 14:28 ` Borislav Petkov
2024-11-08 8:59 ` Neeraj Upadhyay
2024-11-08 10:48 ` Borislav Petkov
2024-11-08 16:14 ` Neeraj Upadhyay
2024-11-06 19:20 ` Melody (Huibo) Wang
2024-11-07 3:33 ` Neeraj Upadhyay
2024-09-13 11:36 ` [RFC 04/14] x86/apic: Initialize APIC backing page for Secure AVIC Neeraj Upadhyay
2024-11-07 15:28 ` Borislav Petkov
2024-11-08 18:08 ` Neeraj Upadhyay
2024-11-09 16:27 ` Borislav Petkov
2024-11-09 16:51 ` Neeraj Upadhyay
2024-11-11 22:43 ` [sos-linux-ext-patches] " Melody (Huibo) Wang
2024-11-12 3:01 ` Neeraj Upadhyay
2024-09-13 11:36 ` [RFC 05/14] x86/apic: Initialize APIC ID " Neeraj Upadhyay
2024-11-09 20:13 ` [sos-linux-ext-patches] " Melody (Huibo) Wang
2024-11-10 3:55 ` Neeraj Upadhyay
2024-11-10 12:12 ` Borislav Petkov
2024-11-10 15:22 ` Neeraj Upadhyay
2024-11-10 16:34 ` Borislav Petkov
2024-11-11 3:45 ` Neeraj Upadhyay
2024-09-13 11:36 ` [RFC 06/14] x86/apic: Add update_vector callback " Neeraj Upadhyay
2024-09-13 11:36 ` [RFC 07/14] x86/apic: Add support to send IPI " Neeraj Upadhyay
2024-09-13 11:36 ` [RFC 08/14] x86/apic: Support LAPIC timer " Neeraj Upadhyay
2024-09-13 11:37 ` [RFC 09/14] x86/sev: Initialize VGIF for secondary VCPUs " Neeraj Upadhyay
2024-09-13 11:37 ` [RFC 10/14] x86/apic: Add support to send NMI IPI " Neeraj Upadhyay
2024-09-13 11:37 ` [RFC 11/14] x86/apic: Allow NMI to be injected from hypervisor " Neeraj Upadhyay
2024-09-13 11:37 ` [RFC 12/14] x86/sev: Enable NMI support " Neeraj Upadhyay
2024-09-13 11:37 ` [RFC 13/14] x86/apic: Enable Secure AVIC in Control MSR Neeraj Upadhyay
2024-09-13 11:37 ` [RFC 14/14] x86/sev: Indicate SEV-SNP guest supports Secure AVIC Neeraj Upadhyay
2024-10-17 8:23 ` [RFC 00/14] AMD: Add Secure AVIC Guest Support Kirill A. Shutemov
2024-10-18 2:33 ` Neeraj Upadhyay
2024-10-18 7:54 ` Kirill A. Shutemov
2024-10-29 9:47 ` Borislav Petkov
2024-10-29 10:24 ` Neeraj Upadhyay
2024-10-29 10:54 ` Borislav Petkov
2024-10-29 11:51 ` Kirill A. Shutemov
2024-10-29 12:15 ` Neeraj Upadhyay
2024-10-29 14:36 ` Kirill A. Shutemov
2024-10-29 15:28 ` Neeraj Upadhyay
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=20241024125947.GDZxpEw9BLJ46B5VKC@fat_crate.local \
--to=bp@alien8.de \
--cc=David.Kaplan@amd.com \
--cc=Neeraj.Upadhyay@amd.com \
--cc=Santosh.Shukla@amd.com \
--cc=Suravee.Suthikulpanit@amd.com \
--cc=Thomas.Lendacky@amd.com \
--cc=Vasant.Hegde@amd.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=nikunj@amd.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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
all inboxes | Powered by JetHome®