* Xin Li wrote:
>
> >>> On 5/15/2025 10:54 AM, Xin Li wrote:
> >>> On 5/15/2025 8:27 AM, Ingo Molnar wrote:
> >>>>
> >>>> * Xin Li (Intel) wrote:
> >>>>
> >>>>> Convert a native_wrmsr() use to native_
* Xin Li wrote:
> On 5/15/2025 10:54 AM, Xin Li wrote:
> > On 5/15/2025 8:27 AM, Ingo Molnar wrote:
> > >
> > > * Xin Li (Intel) wrote:
> > >
> > > > Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
> > > &g
* Xin Li wrote:
> On 5/15/2025 8:29 AM, Ingo Molnar wrote:
> >
> > * Xin Li (Intel) wrote:
> >
> > > xen_read_msr_safe() currently passes an uninitialized argument err to
> > > xen_do_read_msr(). But as xen_do_read_msr() may not set the argument,
>
* Xin Li (Intel) wrote:
> xen_read_msr_safe() currently passes an uninitialized argument err to
> xen_do_read_msr(). But as xen_do_read_msr() may not set the argument,
> xen_read_msr_safe() could return err with an unpredictable value.
>
> To ensure correctness, initialize err to 0 (represent
* Xin Li (Intel) wrote:
> Convert a native_wrmsr() use to native_wrmsrq() to zap meaningless type
> conversions when a u64 MSR value is splitted into two u32.
>
> Signed-off-by: Xin Li (Intel)
> ---
> arch/x86/coco/sev/core.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
>
* Xin Li (Intel) wrote:
> For some reason, there are some TSC-related functions in the MSR
> header even though there is a tsc.h header.
>
> Relocate rdtsc{,_ordered}() from to , and
> subsequently remove the inclusion of in .
>
> Signed-off-by: Xin Li (Intel)
> Acked-by: Dave Hansen
> Ac
* Xin Li (Intel) wrote:
> hpa found that pmu_msr_write() is actually a completely pointless
> function [1]: all it does is shuffle some arguments, then calls
> pmu_msr_chk_emulated() and if it returns true AND the emulated flag
> is clear then does *exactly the same thing* that the calling code
* Xin Li (Intel) wrote:
> For some reason, there are some TSC-related functions in the MSR
^^^
> header even though there is a tsc.h header.
The real reason is that the rdtsc{,_ordered}() methods use the
EAX_EDX_*() macros to optimize their EDX/EAX assembly accessors, which
is
* Xin Li (Intel) wrote:
> index 94408a784c8e..13335a130edf 100644
> --- a/arch/x86/include/asm/tsc.h
> +++ b/arch/x86/include/asm/tsc.h
> @@ -7,7 +7,81 @@
>
> #include
> #include
> -#include
> +
> +/*
> + * both i386 and x86_64 returns 64-bit value in edx:eax, but gcc's "A"
> + * constra
* Linus Torvalds wrote:
> On Mon, 28 Apr 2025 at 00:14, Ingo Molnar wrote:
> >
> > And, just out of intellectual curiosity, I also tried to measure the
> > code generation price of the +1 standards-quirk in the fls()/ffs()
> > interface as well:
> >
> &g
* Ingo Molnar wrote:
> And once we remove 486, I think we can do the optimization below to
> just assume the output doesn't get clobbered by BS*L in the
> zero-case, right?
>
> In the text size space it's a substantial optimization on x86-32
> defconfig
* Ingo Molnar wrote:
> > UNTESTED patch applied in case somebody wants to play with this. It
> > removes 10 lines of silly code, and along with them that 'cmov' use.
> >
> > Anybody?
>
> Makes sense - it seems to boot here, but I only did some very lig
de is already using __ffs() and __fls() that use sane interfaces
close to the machine instruction ABI. Check ahead for zero in C.
There's a minor text size increase on x86-32 defconfig:
text databss dechexfilename
165777287598826 1744896
* H. Peter Anvin wrote:
> The undefined zero case applies to family < 6 as far as I know... the
> same platforms which don't have cmov...
So, technically, these are family 5 CPUs with CMOV support, if
Kconfig.cpu can be believed:
MGEODE_LX
MCRUSOE
Right?
Ingo
* Linus Torvalds wrote:
> On Sat, 26 Apr 2025 at 11:59, Arnd Bergmann wrote:
> >
> > Right. With the current set of features, CMOV is almost the
> > same as 686. My reasoning was that support for CMOV has a
> > very clear definition, with the instruction either being
> > available or not.
>
>
* Arnd Bergmann wrote:
> CMOV is missing not just on old Socket 5/7 CPUs (Pentium MMX, AMD K6,
> Cyrix MII) but also newer embedded Via C3, Geode GX and
> Vortex86DX/MX/EX/DX2. The replacement Nehemiah (2003), GeodeLX (2005)
> and Vortex86DX3/EX2 (2015!) have CMOV, but the old ones were sold
* H. Peter Anvin wrote:
> Dropping CMOV would mean dropping P5 support.
Yeah, I think we should make the cutoff at the 686 level. Is there any
strong reason not to do that? Stable kernels will still exist for a
very long time for ancient boards.
Ingo
* Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> With cx8 and tsc being mandatory features, the only important
> architectural features are now cmov and pae.
>
> Change the large list of target CPUs to no longer pick the instruction set
> itself but only the mtune= optimization level and in-
" choices. Reviewing a 34 patches
> > > series
> > > without being able to apply it is a wee bit difficult...
> > >
> >
> > $ git show f30a0c0d2b08b355c01392538de8fc872387cb2b
> > commit f30a0c0d2b08b355c01392538de8fc872387cb2b
> > Merge: 49b5
* Jürgen Groß wrote:
> On 11.04.25 11:27, Ingo Molnar wrote:
> >
> > * Juergen Gross wrote:
> >
> > > On 10.04.25 21:31, Jason Andryuk wrote:
> > > > Hypercall detection is failing with xen_hypercall_intel() chosen even on
> > > > an A
ff-by: Jason Andryuk
>
> Reviewed-by: Juergen Gross
Wanna merge this via the Xen tree, or should it go to x86/urgent?
The bug was *caused* by the x86 tree so we'd be glad to merge,
but your call.
If you'll merge it:
Acked-by: Ingo Molnar
Thanks,
Ingo
* Xin Li wrote:
> On 4/1/2025 12:52 AM, Ingo Molnar wrote:
> > > Should we rename the *msrl() functions to *msrq() as part of this
> > > overhaul?
> > Yeah, that's a good idea, and because talk is cheap I just implemented
> > this in the tip:WIP.x86/msr
* Dave Hansen wrote:
> On 4/9/25 12:53, Ingo Molnar wrote:
> >>> What would folks think about "wrmsr64()"? It's writing a 64-bit
> >>> value to an MSR and there are a lot of functions in the kernel that
> >>> are named with the arg
* H. Peter Anvin wrote:
> On April 2, 2025 8:41:07 AM PDT, Dave Hansen wrote:
> >On 3/31/25 22:53, Xin Li wrote:
> >> Per "struct msr" defined in arch/x86/include/asm/shared/msr.h:
> >>
> >> struct msr {
> >> union {
> >> struct {
> >> u32 l;
>
* H. Peter Anvin wrote:
> On March 31, 2025 3:17:30 AM PDT, Ingo Molnar wrote:
> >
> >* Xin Li (Intel) wrote:
> >
> >> - __wrmsr (MSR_AMD_DBG_EXTN_CFG, val | 3ULL << 3, val >> 32);
> >> + native_wrmsrl(MSR_AMD_DBG_EXTN_C
* Xin Li wrote:
> Hi Ingo,
>
> Is this branch public?
>
> I wanted to rebase on it and then incooperate your review comments, but
> couldn't find the branch.
Yeah, I moved it over to:
git://git.kernel.org/pub/scm/linux/kernel/git/mingo/tip.git WIP.x86/msr
Thanks,
Ingo
* Xin Li (Intel) wrote:
> __rdmsr() is the lowest level primitive MSR read API, and its direct
> use is NOT preferred. Use its wrapper function native_rdmsrl()
> instead.
This description is very misleading. As of today, native_rdmsrl()
doesn't exist in-tree, so it cannot be 'preferred' in
* Xin Li (Intel) wrote:
> - __wrmsr (MSR_AMD_DBG_EXTN_CFG, val | 3ULL << 3, val >> 32);
> + native_wrmsrl(MSR_AMD_DBG_EXTN_CFG, val | 3ULL << 3);
This is an improvement.
> - __wrmsr (MSR_IA32_PQR_ASSOC, rmid_p, plr->closid);
> + native_wrmsrl(MSR_IA32_PQR_ASSOC, (u64
* Juergen Gross wrote:
> When running as Xen PV guest in some cases W^X violation WARN()s have
> been observed. Those WARN()s are produced by verify_rwx(), which looks
> into the PTE to verify that writable kernel pages have the NX bit set
> in order to avoid code modifications of the kernel by
* Xin Li (Intel) wrote:
> The stack of a task has been separated from the memory of a task_struct
> struture for a long time on x86, as a result __{start,end}_init_task no
> longer mark the start and end of the init_task structure, but its stack
> only.
>
> Rename __{start,end}_init_task to __
* Peter Zijlstra wrote:
> On Tue, Feb 14, 2023 at 12:47:00PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > The following commits are also in the tip tree as different commits
> > (but the same patches):
> >
> > 415dab3c1796 ("drivers/xen/hypervisor: Expose Xen SIF flags to userspace")
* Peter Zijlstra wrote:
> Nope, they do as they say on the tin.
>
> noinstr void foo(void)
> {
> }
>
> declares the whole function as non-instrumented.
>
> Within such functions, we demark regions where instrumentation is
> allowed by:
>
> noinstr void foo(void)
> {
> instrumentation_
* Peter Zijlstra wrote:
> + /*
> + * Definitely wrong, but at this point we should have at least enough
> + * to do CALL/RET (consider SKL callthunks) and this avoids having
> + * to deal with the noinstr explosion for now :/
> + */
> + instrumentation_begin();
BTW.
_startup_64()
> renders the whole secondary_startup_64_no_verify() thing moot, so
> remove that too.
>
> Cc: jroe...@suse.de
> Cc: h...@zytor.com
> Fixes: e81dc127ef69 ("x86/callthunks: Add call patching for call depth
> tracking")
> Reported-by: Joan Bruguera
> Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Ingo Molnar
Thanks,
Ingo
* Peter Zijlstra wrote:
> Since we can't do CALL/RET until GS is restored and CR[04] pinning is
> of dubious value in this code path, simply write the stored values.
>
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> arch/x86/power/cpu.c |4 ++--
> 1 file changed, 2 insertions(+), 2 delet
* Jan Beulich wrote:
> Once again RPL checks have been introduced which don't account for a
> 32-bit kernel living in ring 1 when running in a PV Xen domain. The
> case in FIXUP_FRAME has been preventing boot. Adjust BUG_IF_WRONG_CR3
> as well to guard against future uses of the macro on a code
lly present in the E820 map, but the "mem=" will remove it from
> there again. During ACPI scan it is found (again) and will be added via
> hotplug mechanism, so "mem=" has no effect for that memory.
OK. With that background:
Acked-by: Ingo Molnar
I suppose you wan
* Juergen Gross wrote:
> When limiting memory size via kernel parameter "mem=" this should be
> respected even in case of memory made accessible via a PCI card.
>
> Today this kind of memory won't be made usable in initial memory
> setup as the memory won't be visible in E820 map, but it might
* Juergen Gross wrote:
> You can just dive into the discussion we had back in February:
That was half a year and a thousand commits ago! ;-)
> https://lore.kernel.org/lkml/20180213163244.j2zuxyhs4kbfh...@gmail.com/
>
> The scheme I have used in V5 of the series is the one you agreed to use
>
* Juergen Gross wrote:
> In the non-EFI boot path the ACPI RSDP table is currently found via
> either EBDA or by searching through low memory for the RSDP magic.
> This requires the RSDP to be located in the first 1MB of physical
> memory. Xen PVH guests, however, get the RSDP address via the st
* Boris Ostrovsky wrote:
> x86 maintainers, this needs your ack please.
LGTM:
Acked-by: Ingo Molnar
Thanks,
Ingo
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
* Jiri Slaby wrote:
> Documentation/asm-annotations.rst | 218
> arch/x86/include/asm/linkage.h| 10 +-
> include/linux/linkage.h | 257
> --
> 3 files changed, 475 insertions(+), 10 deletions(-)
> create mode
; unsigned long va = dtr->address;
> unsigned int size = dtr->size + 1;
> - unsigned pages = DIV_ROUND_UP(size, PAGE_SIZE);
> - unsigned long frames[pages];
> + unsigned long frames[DIV_ROUND_UP(SZ_64K, PAGE_SIZE)];
> int f;
Reviewed-by: Ingo Molnar
Tha
* Jan Beulich wrote:
> >>> On 12.04.18 at 09:32, wrote:
>
> > * Jan Beulich wrote:
> >
> >> >>> On 11.04.18 at 13:53, wrote:
> >> > * Jan Beulich wrote:
> >> >
> >> >> Additionally, x86 maintainers: is there a particular reason this (or
> >> >> any functionally equivalent patch) isn't ups
* Jan Beulich wrote:
> >>> On 11.04.18 at 13:53, wrote:
> > * Jan Beulich wrote:
> >
> >> Additionally, x86 maintainers: is there a particular reason this (or
> >> any functionally equivalent patch) isn't upstream yet? As indicated
> >> before, I had not been able to find any discussion, and
* Jan Beulich wrote:
> Additionally, x86 maintainers: is there a particular reason this (or
> any functionally equivalent patch) isn't upstream yet? As indicated
> before, I had not been able to find any discussion, and hence I
> see no reason why this is a patch we effectively carry privately i
| 38 ++
> mm/page_alloc.c | 4
> 6 files changed, 31 insertions(+), 16 deletions(-)
Acked-by: Ingo Molnar
Thanks,
Ingo
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
>> Calculate __max_logical_packages for PV domains.
> >>
> >> Fixes: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate")
> >> Signed-off-by: Prarit Bhargava
> >> Tested-and-reported-by: Simon Gaiser
> >> Cc: Thomas Gleix
* Juergen Gross wrote:
> On 08/01/18 17:10, Peter Zijlstra wrote:
> > On Sat, Jan 06, 2018 at 01:39:48PM -0800, Nick Desaulniers wrote:
> >> Variable Length Arrays In Structs (VLAIS) is not supported by Clang, and
> >> frowned upon by others.
> >>
> >> https://lkml.org/lkml/2013/9/23/500
> >>
>
* Jan Beulich wrote:
> A few thousand such pages are usually left around due to the re-use of
> L1 tables having been provided by the hypervisor (Dom0) or tool stack
> (DomU). Set NX in the direct map variant, which needs to be done in L2
> due to the dual use of the re-used L1s.
>
> For x86_co
* Jan Beulich wrote:
> >>> On 12.12.17 at 11:38, wrote:
> > * Jan Beulich wrote:
> >> --- 4.15-rc3/arch/x86/xen/mmu_pv.c
> >> +++ 4.15-rc3-x86_64-Xen-avoid-W+X/arch/x86/xen/mmu_pv.c
> >> @@ -1902,6 +1902,16 @@ void __init xen_setup_kernel_pagetable(p
> >>/* Graft it onto L4[511][510] */
>
* Jan Beulich wrote:
> A few thousand such pages are usually left around due to the re-use of
> L1 tables having been provided by the hypervisor (Dom0) or tool stack
> (DomU). Set NX in the direct map variant, which needs to be done in L2
> due to the dual use of the re-used L1s.
>
> For x86_co
* Jan Beulich wrote:
> Using just the leaf page table entry flags would cause a false warning
> in case _PAGE_RW is clear or _PAGE_NX is set in a higher level entry.
Good find - I assume this bug can cause both false positives and false
negatives
as well, right?
Thanks,
Ingo
__
* Juergen Gross wrote:
> On 11/12/17 11:09, Jan Beulich wrote:
> On 08.12.17 at 16:11, wrote:
> >> Set the boot loader version to 2.14 (0x020e) replacing the wrong 0x0212
> >> which should have been 0x020c.
> >
> > This part of the description has become partly stale now with the
> > new
* Juergen Gross wrote:
> On 08/12/17 08:05, Ingo Molnar wrote:
> >
> > * Juergen Gross wrote:
>
> ...
>
> > acpi_physical_address acpi_arch_get_root_pointer(void)
> > {
> > return boot_params.hdr.acpi_rsdp_addr;
> > }
> >
&
* Juergen Gross wrote:
> >> +Offset/size: 0x268/8
> >> +Protocol: 2.14+
> >> +
> >> + This field can be set by the boot loader to tell the kernel the
> >> + physical address of the ACPI RSDP table.
> >> +
> >> + A value of 0 indicates the kernel should fall back to the standard
> >> + m
* Jan Beulich wrote:
> >>> On 08.12.17 at 08:16, wrote:
> > Also, a more fundamental question: why doesn't Xen use EFI to hand over
> > hardware configuration details?
>
> Iirc the main purpose of the change here is to allow booting PVH
> (guest or Dom0) with Grub2 in the middle. PVH, at leas
* Juergen Gross wrote:
> When booted via the special PVH entry save the RSDP address set in the
> boot information block in struct boot_params. This will enable Xen to
> locate the RSDP at an arbitrary address.
>
> Set the boot loader version to 2.14 (0x020e) replacing the wrong 0x0212
> which
* Juergen Gross wrote:
> Xen PVH guests receive the address of the RSDP table from Xen. In order
> to support booting a Xen PVH guest via grub2 using the standard x86
> boot entry we need a way fro grub2 to pass the RSDP address to the
> kernel.
>
> For this purpose expand the struct setup_head
* Juergen Gross wrote:
> In case the rsdp address in struct boot_params is specified don't try
> to find the table by searching, but take the address directly as set
> by the boot loader.
>
> Signed-off-by: Juergen Gross
> ---
> drivers/acpi/osl.c | 8
> 1 file changed, 8 insertions(
60 matches
Mail list logo
