Re: [PATCH] x86/pat: fix W^X violation false-positives when running as Xen PV guest

* 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

Re: [PATCH v2 1/1] x86: Rename __{start,end}_init_task to __{start,end}_init_stack

* 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

Re: linux-next: duplicate patches in the xen-tip tree

* 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")

Re: [PATCH v2 6/7] x86/power: Sprinkle some noinstr

* 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) > { >

Re: [PATCH v2 6/7] x86/power: Sprinkle some noinstr

* 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();

Re: [PATCH v2 1/7] x86/boot: Remove verify_cpu() from secondary_startup_64()

gt; 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

Re: [RFC][PATCH 2/6] x86/power: Inline write_cr[04]()

* 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

Re: [Xen-devel] [PATCH v3] x86/stackframe/32: repair 32-bit Xen PV

* 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

Re: [Xen-devel] [PATCH v2 1/2] x86: respect memory size limiting via mem= parameter

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 want thi

Re: [Xen-devel] [PATCH v2 1/2] x86: respect memory size limiting via mem= parameter

* 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

Re: [Xen-devel] [PATCH v5 0/3] x86: make rsdp address accessible via boot params

* 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 >

Re: [Xen-devel] [PATCH v5 0/3] x86: make rsdp address accessible via boot params

* 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

Re: [Xen-devel] [PATCH v2] xen/pv: Call get_cpu_address_sizes to set x86_virt/phys_bits

* 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

Re: [Xen-devel] [PATCH -resend 01/27] linkage: new macros for assembler symbols

* 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

Re: [Xen-devel] [PATCH] x86/xen: Remove use of VLAs

gt; desc_ptr *dtr) > { > 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)]; >

Re: [Xen-devel] [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

* 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

Re: [Xen-devel] [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

* 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 > >>

Re: [Xen-devel] [PATCH] x86/xen: zero MSR_IA32_SPEC_CTRL before suspend

* 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

Re: [Xen-devel] [v2 1/1] xen, mm: Allow deferred page initialization for xen pv domains

it_32.c | 1 + > arch/x86/mm/init_64.c | 1 + > arch/x86/xen/mmu_pv.c | 38 ++---- > mm/page_alloc.c | 4 > 6 files changed, 31 insertions(+), 16 deletions(-) Acked-by: Ingo Molnar <mi...@kernel.org> Thanks, Ingo __

Re: [Xen-devel] [PATCH] x86/xen: Calculate __max_logical_packages on PV domains

s. > >> > >> Calculate __max_logical_packages for PV domains. > >> > >> Fixes: b4c0a7326f5d ("x86/smpboot: Fix __max_logical_packages estimate") > >> Signed-off-by: Prarit Bhargava <pra...@redhat.com> > >> Tested-and-reported-by:

Re: [Xen-devel] [PATCH v2] x86: xen: remove the use of VLAIS

* 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. > >> > >>

Re: [Xen-devel] [PATCH v2] x86-64/Xen: eliminate W+X mappings

* 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

Re: [Xen-devel] [PATCH 2/2] x86-64/Xen: eliminate W+X mappings

* 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

Re: [Xen-devel] [PATCH 2/2] x86-64/Xen: eliminate W+X mappings

* 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

Re: [Xen-devel] [PATCH 1/2] x86: consider effective protection attributes in W+X check

* 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,

Re: [Xen-devel] [PATCH v3 4/4] x86/xen: supply rsdp address in boot params for pvh guests

* 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

Re: [Xen-devel] [PATCH v2 1/3] x86/boot: add acpi rsdp address to setup_header

* 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

Re: [Xen-devel] [PATCH v2 3/3] x86/xen: supply rsdp address in boot params for pvh guests

* 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

Re: [Xen-devel] [PATCH v2 1/3] x86/boot: add acpi rsdp address to setup_header

* 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

Re: [Xen-devel] [PATCH v2 2/3] x86/acpi: take rsdp address for boot params if available

* 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