On Thu, Jan 14, 2021 at 07:30:24PM +0100, Borislav Petkov wrote:
> On Thu, Dec 17, 2020 at 09:12:57PM +0800, kernel test robot wrote:
> >ld: arch/x86/kernel/alternative.o: in function `paravirt_set_cap':
> > >> arch/x86/kernel/alternative.c:6
You forgot to Cc Mike, lemme add him.
And drop stable@ too.
On Tue, Sep 14, 2021 at 01:06:22PM +0200, Juergen Gross wrote:
> On 14.09.21 12:03, Jan Beulich wrote:
> > On 14.09.2021 11:41, Juergen Gross wrote:
> > > Commit a799c2bd29d19c565 ("x86/setup: Consolidate early memory
> > > reservations"
On Thu, Sep 16, 2021 at 12:09:27PM +0300, Mike Rapoport wrote:
> I think the first sentence about reserving memory before memblock
> allocations are possible is important and I think we should keep it.
I expanded that comment this way:
/*
* Do some memory reservations *before* me
On Thu, Sep 07, 2023 at 08:08:00PM -0700, Elliott Mitchell wrote:
> This reverts commit 767f4b620edadac579c9b8b6660761d4285fa6f9.
>
> There are at least 3 valid reasons why a VM may see MCE events/registers.
Hmm, so they all read like a bunch of handwaving to me, with those
probable hypothetical
On Thu, Sep 14, 2023 at 10:02:05AM -0700, Elliott Mitchell wrote:
> Indeed. At what point is the lack of information and response long
> enough to simply commit a revert due to those lacks?
At no point.
> Even with the commit message having been rewritten and the link to:
> https://lkml.kernel.o
On Mon, Mar 08, 2021 at 01:28:43PM +0100, Juergen Gross wrote:
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index 36cd71fa097f..04b3067f31b5 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -137,7 +137,8 @@ static inli
On Tue, Mar 09, 2021 at 02:48:03PM +0100, Juergen Gross wrote:
> @@ -167,6 +168,17 @@ static u64 native_steal_clock(int cpu)
> return 0;
> }
>
> +DEFINE_STATIC_CALL(pv_steal_clock, native_steal_clock);
> +DEFINE_STATIC_CALL(pv_sched_clock, native_sched_clock);
> +
> +bool paravirt_using_na
On Tue, Mar 09, 2021 at 02:48:05PM +0100, Juergen Gross wrote:
> Add support for alternative patching for the case a feature is not
> present on the current cpu.
>
> For users of ALTERNATIVE() and friends an inverted feature is specified
> by applying the ALT_NOT() macro to it, e.g.:
>
> ALTERNAT
On Wed, Mar 10, 2021 at 08:51:22AM +0100, Jürgen Groß wrote:
> It is combining the two needed actions: update the static call and
> set the paravirt_using_native_sched_clock boolean.
I actually meant what the point of using_native_sched_clock() is but put
this comment at the wrong place, sorry.
>
On Wed, Mar 10, 2021 at 08:52:40AM +0100, Jürgen Groß wrote:
> Did you look at patch 13? :-)
Well, I usually review in increasing patch order. :-P
But make that change here pls because otherwise unnecessary churn.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-ne
On Tue, Mar 09, 2021 at 02:48:06PM +0100, Juergen Gross wrote:
> diff --git a/arch/x86/include/asm/alternative.h
> b/arch/x86/include/asm/alternative.h
> index 89889618ae01..4fb844e29d26 100644
> --- a/arch/x86/include/asm/alternative.h
> +++ b/arch/x86/include/asm/alternative.h
> @@ -178,6 +178,9
On Tue, Mar 09, 2021 at 02:48:01PM +0100, Juergen Gross wrote:
> This is a major cleanup of the paravirt infrastructure aiming at
> eliminating all custom code patching via paravirt patching.
>
> This is achieved by using ALTERNATIVE instead, leading to the ability
> to give objtool access to the
On Thu, Mar 11, 2021 at 01:50:26PM +0100, Borislav Petkov wrote:
> and move the cleanups patches 13 and 14 to the beginning of the set?
Yeah, 14 needs ALTERNATIVE_TERNARY so I guess after patch 5, that is.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Wed, May 03, 2023 at 11:14:25AM -0700, Sohil Mehta wrote:
> A Nit -> Documentation/process/maintainer-tip.rst suggests:
> "The condensed patch description in the subject line should start with a
> uppercase letter and ..."
Yeah, good point.
But my patch massaging script does that automatically
On Tue, May 02, 2023 at 02:09:15PM +0200, Juergen Gross wrote:
> This series tries to fix the rather special case of PAT being available
> without having MTRRs (either due to CONFIG_MTRR being not set, or
> because the feature has been disabled e.g. by a hypervisor).
More weird stuff. With the ser
On Tue, May 09, 2023 at 10:14:37PM +0200, Borislav Petkov wrote:
> On Tue, May 02, 2023 at 02:09:15PM +0200, Juergen Gross wrote:
> > This series tries to fix the rather special case of PAT being available
> > without having MTRRs (either due to CONFIG_MTRR being not set, or
On Wed, May 10, 2023 at 01:36:41AM +0200, Borislav Petkov wrote:
> More staring at this tomorrow, on a clear head.
Yeah, I'm going to leave it as is. Tried doing a union with bitfields
but doesn't get any prettier.
Next crapola:
The Intel box says now:
[8.138683] sgx
On Wed, May 10, 2023 at 03:30:24PM +0200, Borislav Petkov wrote:
> So this map lookup thing is wrong in this case.
Btw, current tree is:
https://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git/log/?h=rc1-mtrr
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Wed, May 10, 2023 at 05:53:15PM +0200, Juergen Gross wrote:
> Urgh, yes, there is something missing:
>
> diff --git a/arch/x86/kernel/cpu/mtrr/generic.c
> b/arch/x86/kernel/cpu/mtrr/generic.c
> index 031f7ea8e72b..9544e7d13bb3 100644
> --- a/arch/x86/kernel/cpu/mtrr/generic.c
> +++ b/arch/x86/
On Mon, May 22, 2023 at 04:17:50PM +0200, Juergen Gross wrote:
> The attached diff is for patch 13.
Merged and pushed out into same branch.
Next issue. Diffing /proc/mtrr shows:
--- proc-mtrr.6.3 2023-05-30 17:00:13.215999483 +0200
+++ proc-mtrr.after 2023-05-30 16:01:38.281997816 +020
On Wed, May 31, 2023 at 09:28:57AM +0200, Juergen Gross wrote:
> Can you please boot the system with the MTRR patches and specify "mtrr=debug"
> on the command line? I'd be interested in the raw register values being read
> and the resulting memory type map.
This is exactly why I wanted this optio
On Thu, Sep 08, 2022 at 10:49:11AM +0200, Juergen Gross wrote:
> diff --git a/arch/x86/kernel/cpu/mtrr/mtrr.c b/arch/x86/kernel/cpu/mtrr/mtrr.c
> index 9609a0d235f8..956838bb4481 100644
> --- a/arch/x86/kernel/cpu/mtrr/mtrr.c
> +++ b/arch/x86/kernel/cpu/mtrr/mtrr.c
> @@ -761,13 +761,10 @@ void __in
On Thu, Sep 08, 2022 at 10:49:12AM +0200, Juergen Gross wrote:
> -void set_mtrr_aps_delayed_init(void)
> -{
> - if (!cache_generic)
> - return;
> -
> - mtrr_aps_delayed_init = true;
> -}
> -
Except that you've removed the accessors and made that bool global.
Which is less prett
On Tue, Sep 27, 2022 at 10:57:37AM +0200, Juergen Gross wrote:
> TBH I don't see the point of having an accessor which is just setting a
> variable to "true". But if you like it better, I can keep it.
Accessors are always better, no matter how silly. :)
But, in trying to grok your next patch - yo
On Tue, Sep 27, 2022 at 12:14:42PM +0200, Juergen Gross wrote:
> Yes: cpu hotplug.
You might need to elaborate here.
Because I see mtrr_ap_init() on the AP hotplug path:
native_cpu_up->
do_boot_cpu->
start_secondary->
smp_callin->
smp_store_cpu_info->
identify_secondary_cpu->
mtrr_ap_init
Which
On Tue, Sep 27, 2022 at 01:25:47PM +0200, Juergen Gross wrote:
> You mean by replacing it with "(system_state != SYSTEM_RUNNING)" ?
Right, or maybe even something more elegant. I've been meaning to ask
tglx about it as I needed it for the microcode loader too.
--
Regards/Gruss,
Boris.
https
On Tue, Sep 27, 2022 at 02:21:17PM +0200, Juergen Gross wrote:
> So replacing the bool with "(system_state != SYSTEM_RUNNING)" is fine
> with you right now? We can later switch that to the "more elegant"
> solution when it shows up.
Ok, I think I have something. And it was staring me straight in t
On Wed, Sep 28, 2022 at 08:16:53AM +0200, Juergen Gross wrote:
> > Are sure the hotplug notifier doesn't get called in the boot and in the
It doesn't because it gets registered after smp_init()...
> > resume cases?
... but it gets called during resume because by that time the notifier
has been r
On Wed, Sep 28, 2022 at 01:14:11PM +0200, Juergen Gross wrote:
> No, we don't.
>
> Using basically your patch, but with
>
> + mtrr_online = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN,
> + "x86/mtrr:online",
> +
On Wed, Sep 28, 2022 at 03:43:56PM +0200, Juergen Gross wrote:
> Would you feel better with adding a new enum member CPUHP_AP_CACHECTRL_ONLINE?
>
> This would avoid a possible source of failure during resume in case no slot
> for CPUHP_AP_ONLINE_DYN is found (quite improbable, but in theory possib
On Wed, Sep 28, 2022 at 06:32:20PM +0200, Juergen Gross wrote:
> I can do that.
Thx!
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Thu, Sep 29, 2022 at 10:26:59AM +0200, Juergen Gross wrote:
> So right now I'm inclined to be better on the safe side by not adding any
> cpu hotplug hook, but to use just the same "delayed AP init" flag as today,
> just renaming it. This would leave the delayed MTRR/PAT init in place for
> resu
On Fri, Sep 30, 2022 at 03:11:07PM +0200, Juergen Gross wrote:
> Yes, this can be done. It would practically have to be the first one just
> after CPUHP_BRINGUP_CPU.
Right.
> The question is whether we really want to call the MTRR/PAT initialization
> on hotplugged cpus only after enabling interr
Adding Xen and Jailhouse people and MLs to Cc.
Folks, thread starts here:
https://lore.kernel.org/r/1650035401-22855-1-git-send-email-ross.philip...@oracle.com
On Fri, Apr 15, 2022 at 11:10:00AM -0400, Ross Philipson wrote:
> There are a number of places where early_memremap is called
> but the
On Wed, Oct 12, 2022 at 11:13:20AM -0400, Ross Philipson wrote:
> I am already using the pr_* macros in the patches. Are you asking me to do
> something
Yes. You do
pr_X("prefix_string: msg"
while you should set the prefix string and do
pr_X("msg".
As said, grep the tree for examples where pr_
On Thu, Oct 20, 2022 at 01:36:19PM +0200, Juergen Gross wrote:
> xen_enable_sysenter() and xen_enable_syscall() can be simplified a lot.
>
> Signed-off-by: Juergen Gross
> ---
> arch/x86/xen/setup.c | 23 ++-
> 1 file changed, 6 insertions(+), 17 deletions(-)
>
> diff --git
On Fri, Jan 31, 2025 at 06:17:02PM -0800, Sean Christopherson wrote:
> And if the host provides the core crystal frequency in CPUID.0x15, then KVM
> guests can use that for the APIC timer period instead of manually
> calibrating the frequency.
Hmm, so that part: what's stopping the host from fakin
On Fri, Jan 31, 2025 at 06:17:05PM -0800, Sean Christopherson wrote:
Drop:
jailhouse-...@googlegroups.com
Alexey Makhalov
from Cc as they're bouncing.
> Add a TODO to call out that AMD_MEM_ENCRYPT is a mess and doesn't depend on
> HYPERVISOR_GUEST because it gates both guest and host code.
Wh
On Fri, Jan 31, 2025 at 06:17:03PM -0800, Sean Christopherson wrote:
> Extract retrieval of TSC frequency information from CPUID into standalone
> helpers so that TDX guest support and kvmlock can reuse the logic. Provide
> a version that includes the multiplier math as TDX in particular does NOT
On Mon, Dec 23, 2024 at 03:32:01PM +0800, Weikang Guo wrote:
> First of all, thank you for your reminder and patience. In fact, this
> is the first time I received a patch discussion when submitting a
> patch.
> About Reviewed-by or Acked-by tags, I will not add it myself in the
> future. Regarding
On Thu, Jan 23, 2025 at 02:07:36PM -0500, Brian Gerst wrote:
> Instead of having a private area for the stack canary, use
> fixed_percpu_data for GSBASE like the native kernel.
>
> Signed-off-by: Brian Gerst
> Reviewed-by: Ard Biesheuvel
> ---
> arch/x86/platform/pvh/head.S | 15 +
On January 25, 2025 5:51:29 PM GMT+01:00, Brian Gerst wrote:
>To be fair, this was a copy of an existing comment. Is there a style
>guide where all these grammar rules are documented, so I don't have to
>keep resending these patches for trivial typos?
You don't have to keep resending them for tr
On Tue, Feb 11, 2025 at 09:25:47AM -0800, Sean Christopherson wrote:
> Because obviously optimizing code that's called once during boot is super
> critical?
Because let's stick 'em where they belong and keep headers containing only
small, trivial and inlineable functions. Having unusually big func
On Tue, Feb 11, 2025 at 09:43:23AM -0800, Sean Christopherson wrote:
> It conflates two very different things: host/bare metal support for memory
> encryption, and SEV guest support. For kernels that will never run in a VM,
> pulling in all the SEV guest code just to enable host-side support for S
On Wed, Jul 24, 2024 at 11:55:39AM +0200, Jürgen Groß wrote:
> I'd prefer a general way to handle this problem, like e.g. some kind of
> __refdata tagging for percpu variables.
Any reason for not doing the trivial thing?
diff --git a/arch/x86/xen/multicalls.c b/arch/x86/xen/multicalls.c
index 10c
Right.
> It's fixed by:
>
> https://lore.kernel.org/xen-devel/87v7rxzct0.ffs@tglx/
>
> Waiting for Thomas to formally sent that.
Yap, he just pointed me to that one.
Tested-by: Borislav Petkov (AMD)
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
+ Linus so that he can whack it before it spreads any further.
On Wed, Feb 19, 2025 at 10:20:57AM +0100, Roger Pau Monne wrote:
> Setting pci_msi_ignore_mask inhibits the toggling of the mask bit for both
> MSI and MSI-X entries globally, regardless of the IRQ chip they are using.
> Only Xen sets
On Thu, Mar 27, 2025 at 03:21:45PM +0100, Jürgen Groß wrote:
> Well, that is wasting nearly 3kB of the data section.
>
> Maybe not a big deal, but still...
We could do it until the proper fix is in place, no?
3K is meh, especially for the hypervisor kernel, I'd say...
--
Regards/Gruss,
Bor
On Thu, Mar 27, 2025 at 04:15:11PM +0100, Jürgen Groß wrote:
> Another approach could be to have:
>
> -static DEFINE_PER_CPU(struct mc_debug_data *, mc_debug_data) =
> - &mc_debug_data_early;
> +static DEFINE_PER_CPU(struct mc_debug_data *, mc_debug_data);
>
> and to use an inline access func
101 - 149 of 149 matches
Mail list logo
