* 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(
32 matches
Mail list logo
