On 25.09.2024 22:20, Andrew Cooper wrote:
> On 25/09/2024 7:01 am, Frediano Ziglio wrote:
>> +const char * asmlinkage __init
>> +efi_multiboot2_prelude(uint32_t magic, const multiboot2_fixed_t *mbi)
>> +{
>> +const multiboot2_tag_t *tag;
>> +EFI_HANDLE ImageHandle = NULL;
>> +EFI_SYSTEM
Hi Jens,
> On 23 Sep 2024, at 19:36, Jens Wiklander wrote:
>
> Hi,
>
> On Thu, Sep 19, 2024 at 2:20 PM Bertrand Marquis
> wrote:
>>
>> When an RXTX buffer is mapped by a VM transmit it to the SPMC when it
>> supports RX_ACQUIRE.
>> As a consequence of that, we must acquire the RX buffer of a
Hi Julien,
> On 24 Sep 2024, at 19:31, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 24/09/2024 09:16, Bertrand Marquis wrote:
>>> On 22 Sep 2024, at 11:07, Julien Grall wrote:
>>>
>>> Hi,
>>>
>>> On 19/09/2024 14:19, Bertrand Marquis wrote:
Store the list of ABI we need in a list and go
Hi Julien,
> On 25 Sep 2024, at 18:45, Julien Grall wrote:
>
>
>
> On 24/09/2024 09:23, Bertrand Marquis wrote:
>> Hi Julien,
>
> Hi Bertrand,
>
>
>>> On 22 Sep 2024, at 14:25, Julien Grall wrote:
>>>
>>> Hi Bertrand,
>>>
>>> NIT Typo: s/fix/Fix/ to match the other title
>> Ack
>>>
>>>
Hi Julien,
> On 22 Sep 2024, at 15:03, Julien Grall wrote:
>
> Hi Bertrand,
>
> On 19/09/2024 14:19, Bertrand Marquis wrote:
>> Create a bitmap to store which feature is supported or not by the
>> firmware and use it to filter which calls done to the firmware.
>> With this enabled. allow FF-A s
On 25.09.2024 21:33, Andrew Cooper wrote:
> On 25/09/2024 7:00 am, Frediano Ziglio wrote:
>> @@ -449,62 +458,40 @@ __pvh_start:
>> mov %ecx, %es
>> mov %ecx, %ss
>>
>> -/* Skip bootloader setup and bios setup, go straight to trampoline
>> */
>> -movb
On 25.09.2024 18:51, Andrew Cooper wrote:
> On 25/09/2024 5:45 pm, Ard Biesheuvel wrote:
>> On Wed, 25 Sept 2024 at 18:39, Linus Torvalds
>> wrote:
>>> And we do have special calling conventions that aren't the regular
>>> ones, so %rdi might actually be used elsewhere. For example,
>>> __get_user
Hi Julien,
I will answer after to your previous comments but I wanted to jump in on this
subject first.
> On 25 Sep 2024, at 18:56, Julien Grall wrote:
>
>
>
> On 23/09/2024 13:27, Jens Wiklander wrote:
>> Hi,
>
> Hi,
>
>> On Sun, Sep 22, 2024 at 3:04 PM Julien Grall wrote:
>>>
>>> Hi Be
On 25.09.2024 23:15, Andrew Cooper wrote:
> On 23/04/2024 3:44 pm, Jan Beulich wrote:
>> On 22.04.2024 20:14, Andrew Cooper wrote:
>>> +if ( res.rel_type == REL_TYPE_d8 )
>>> +{
>>> +int8_t *d8 = res.rel;
>>> +void *target = ip
On 25.09.2024 18:08, oleksii.kuroc...@gmail.com wrote:
> On Wed, 2024-09-25 at 10:36 +0200, Jan Beulich wrote:
>> PPC's desire to use DECL_SECTION() can certainly be covered by
>> providing
>> a (trivial) DECL_SECTION() also for Arm and RISC-V. Seeing that even
>> x86
>> overrides the default to th
This series came from part of the work of removing duplications between
boot code and rewriting part of code from assembly to C.
First patch rework BIOS/PVH paths to reuse some code.
Second patch rewrites EFI code in pure C.
Changes since v1, more details in specific commits:
- style updates;
- co
No need to have it coded in assembly.
Signed-off-by: Frediano Ziglio
---
Changes since v1:
- update some comments;
- explain why %ebx is saved before calling efi_parse_mbi2;
- move lea before test instruction;
- removed asmlinkage from efi_multiboot2 and add to efi_parse_mbi2;
- fix line length;
Tag structure should contain at least the tag header.
Entire tag structure must be contained inside MBI2 data.
Signed-off-by: Frediano Ziglio
---
xen/arch/x86/efi/parse-mbi2.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/efi/parse-mbi2.c b/xen/arch/x86/efi
The 2 code paths were sharing quite some common code, reuse it instead
of having duplications.
Signed-off-by: Frediano Ziglio
---
Changes since v1:
- use %dl instead of %ebp to reduce code size;
- fold cli instruction;
- update some comments.
Changes since v3:
- dropped %dl and constant, disting
flight 187848 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187848/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-armhf-xl-raw 12 debian-di-install fail in 187837 pass in 187848
test-amd64-amd64-xl-qemuu-debianh
flight 187846 xen-4.17-testing real [real]
flight 187859 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/187846/
http://logs.test-lab.xenproject.org/osstest/logs/187859/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
t
Hi Kelly,
Wonder whether there will be recording or notes for this and public later?
Thanks,
Peng.
From: Xen-users On Behalf Of Kelly Choi
Sent: Wednesday, September 25, 2024 10:59 PM
To: xen-devel ; xen-us...@lists.xenproject.org
Subject: [POLL] Interest in next Xen Project meetup (Cambridge)
On 2024-09-25 17:50, Ard Biesheuvel wrote:
On Wed, 25 Sept 2024 at 23:11, Jason Andryuk wrote:
Hi Ard,
On 2024-09-25 11:01, Ard Biesheuvel wrote:
From: Ard Biesheuvel
The .head.text section contains code that may execute from a different
address than it was linked at. This is fragile, give
On Wed, 25 Sep 2024, Julien Grall wrote:
> Hi Edgar,
>
> On 25/09/2024 17:49, Edgar E. Iglesias wrote:
> > On Wed, Sep 25, 2024 at 10:44 AM Edgar E. Iglesias
> > wrote:
> >
> > > On Wed, Sep 25, 2024 at 05:38:13PM +0100, Julien Grall wrote:
> > > > Hi Edgar,
> > > >
> > > > On 25/09/2024 17:34,
On Wed, 25 Sept 2024 at 23:11, Jason Andryuk wrote:
>
> Hi Ard,
>
> On 2024-09-25 11:01, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel
> >
> > The .head.text section contains code that may execute from a different
> > address than it was linked at. This is fragile, given that the x86 ABI
> > can
On 23/04/2024 3:59 pm, Jan Beulich wrote:
> On 22.04.2024 20:14, Andrew Cooper wrote:
>> @@ -317,14 +338,23 @@ static void init_or_livepatch
>> _apply_alternatives(struct alt_instr *start,
>> */
>> goto skip_this_alternative;
>>
On 24/04/2024 6:54 am, Jan Beulich wrote:
> On 23.04.2024 16:59, Jan Beulich wrote:
>> On 22.04.2024 20:14, Andrew Cooper wrote:
>>> --- a/xen/arch/x86/alternative.c
>>> +++ b/xen/arch/x86/alternative.c
>>> @@ -244,10 +244,31 @@ static void init_or_livepatch
>>> _apply_alternatives(struct alt_inst
On 23/04/2024 3:44 pm, Jan Beulich wrote:
> On 22.04.2024 20:14, Andrew Cooper wrote:
>> In debug builds, walk all alternative replacements with x86_decode_lite().
>>
>> This checks that we can decode all instructions, and also lets us check that
>> disp8's don't leave the replacement block.
>>
>>
On 2024-09-25 11:01, Ard Biesheuvel wrote:
From: Ard Biesheuvel
Calling C code via a different mapping than it was linked at is
problematic, because the compiler assumes that RIP-relative and absolute
symbol references are interchangeable. GCC in particular may use
RIP-relative per-CPU variable
Hi Ard,
On 2024-09-25 11:01, Ard Biesheuvel wrote:
From: Ard Biesheuvel
The .head.text section contains code that may execute from a different
address than it was linked at. This is fragile, given that the x86 ABI
can refer to global symbols via absolute or relative references, and the
toolcha
On 25/09/2024 17:01, Ard Biesheuvel wrote:
From: Ard Biesheuvel
Build the kernel as a Position Independent Executable (PIE). This
results in more efficient relocation processing for the virtual
displacement of the kernel (for KASLR). More importantly, it instructs
the linker to generate what
On Wed, Sep 25, 2024 at 10:01 PM Ard Biesheuvel wrote:
>
> On Wed, 25 Sept 2024 at 21:39, Uros Bizjak wrote:
> >
> > On Wed, Sep 25, 2024 at 9:14 PM Ard Biesheuvel wrote:
> > >
> > > On Wed, 25 Sept 2024 at 20:54, Uros Bizjak wrote:
> > > >
> > > > On Wed, Sep 25, 2024 at 5:02 PM Ard Biesheuvel
On 25/09/2024 7:01 am, Frediano Ziglio wrote:
> diff --git a/xen/arch/x86/boot/head.S b/xen/arch/x86/boot/head.S
> index 2d2f56ad22..859f7055dc 100644
> --- a/xen/arch/x86/boot/head.S
> +++ b/xen/arch/x86/boot/head.S
> @@ -252,36 +243,30 @@ __efi64_mb2_start:
>
>
> /* We are on EFI plat
flight 187857 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187857/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On Wed, 25 Sept 2024 at 21:39, Uros Bizjak wrote:
>
> On Wed, Sep 25, 2024 at 9:14 PM Ard Biesheuvel wrote:
> >
> > On Wed, 25 Sept 2024 at 20:54, Uros Bizjak wrote:
> > >
> > > On Wed, Sep 25, 2024 at 5:02 PM Ard Biesheuvel
> > > wrote:
> > > >
> > > > From: Ard Biesheuvel
> > > >
> > > > Bu
On Wed, Sep 25, 2024 at 9:14 PM Ard Biesheuvel wrote:
>
> On Wed, 25 Sept 2024 at 20:54, Uros Bizjak wrote:
> >
> > On Wed, Sep 25, 2024 at 5:02 PM Ard Biesheuvel wrote:
> > >
> > > From: Ard Biesheuvel
> > >
> > > Build the kernel as a Position Independent Executable (PIE). This
> > > results
On 25/09/2024 7:00 am, Frediano Ziglio wrote:
> The 2 code paths were sharing quite some common code, reuse it instead
> of having duplications.
> Use %dl register to store boot type before running common code.
> Using a 8 bit register reduces code size.
These final two lines are stale and can be
On Wed, 25 Sept 2024 at 20:54, Uros Bizjak wrote:
>
> On Wed, Sep 25, 2024 at 5:02 PM Ard Biesheuvel wrote:
> >
> > From: Ard Biesheuvel
> >
> > Build the kernel as a Position Independent Executable (PIE). This
> > results in more efficient relocation processing for the virtual
> > displacement
On Wed, Sep 25, 2024 at 5:02 PM Ard Biesheuvel wrote:
>
> From: Ard Biesheuvel
>
> Build the kernel as a Position Independent Executable (PIE). This
> results in more efficient relocation processing for the virtual
> displacement of the kernel (for KASLR). More importantly, it instructs
> the lin
On Wed, Sep 25, 2024 at 06:45:19PM +0100, Julien Grall wrote:
> Hi Edgar,
>
> On 25/09/2024 17:49, Edgar E. Iglesias wrote:
> > On Wed, Sep 25, 2024 at 10:44 AM Edgar E. Iglesias
> > wrote:
> >
> > > On Wed, Sep 25, 2024 at 05:38:13PM +0100, Julien Grall wrote:
> > > > Hi Edgar,
> > > >
> > > >
On Wed, Sep 25, 2024 at 5:02 PM Ard Biesheuvel wrote:
>
> From: Ard Biesheuvel
>
> Specify the guard symbol for the stack cookie explicitly, rather than
> positioning it exactly 40 bytes into the per-CPU area. Doing so removes
> the need for the per-CPU region to be absolute rather than relative
On Wed, 25 Sep 2024, Ard Biesheuvel wrote:
> The x86_64 approach was needed to accommodate per-task stack protector
> cookies, which used to live at a fixed offset of GS+40, requiring GS to
> be treated as a base register. This is no longer the case, though, and
> so GS can be repurposed as a true
On 25/09/2024 11:00 am, Roger Pau Monné wrote:
> On Wed, Sep 25, 2024 at 10:33:39AM +0100, Andrew Cooper wrote:
>> On 25/09/2024 9:42 am, Roger Pau Monne wrote:
>>> The livepatch_elf_sec data field points to the temporary load buffer, it's
>>> the
>>> load_addr field that points to the stable load
flight 187858 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187858/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 39462fcd99349732ef561cda71c4c633b8ce8246
baseline version:
ovmf b8122cc9d8b6c9017905a
On Wed, 25 Sep 2024, Julien Grall wrote:
> On 25/09/2024 00:16, Stefano Stabellini wrote:
> > On Tue, 24 Sep 2024, Julien Grall wrote:
> > > On 24/09/2024 18:11, Edgar E. Iglesias wrote:
> > > > On Tue, Sep 24, 2024 at 05:35:20PM +0100, Julien Grall wrote:
> > > > > Hi Edgar,
> > > > >
> > > > > O
On Wed, Sep 25, 2024 at 10:43 AM Ard Biesheuvel wrote:
>
> On Wed, 25 Sept 2024 at 17:54, Ian Rogers wrote:
> >
> > On Wed, Sep 25, 2024 at 8:02 AM Ard Biesheuvel wrote:
> > >
> > > From: Ard Biesheuvel
> > >
> > > Specify the guard symbol for the stack cookie explicitly, rather than
> > > posi
Hi Edgar,
On 25/09/2024 17:49, Edgar E. Iglesias wrote:
On Wed, Sep 25, 2024 at 10:44 AM Edgar E. Iglesias
wrote:
On Wed, Sep 25, 2024 at 05:38:13PM +0100, Julien Grall wrote:
Hi Edgar,
On 25/09/2024 17:34, Edgar E. Iglesias wrote:
On Wed, Sep 25, 2024 at 08:44:41AM +0100, Julien Grall wro
On Wed, 25 Sept 2024 at 17:54, Ian Rogers wrote:
>
> On Wed, Sep 25, 2024 at 8:02 AM Ard Biesheuvel wrote:
> >
> > From: Ard Biesheuvel
> >
> > Specify the guard symbol for the stack cookie explicitly, rather than
> > positioning it exactly 40 bytes into the per-CPU area. Doing so removes
> > th
On 23/09/2024 13:27, Jens Wiklander wrote:
Hi,
Hi,
On Sun, Sep 22, 2024 at 3:04 PM Julien Grall wrote:
Hi Bertrand,
On 19/09/2024 14:19, Bertrand Marquis wrote:
Create a bitmap to store which feature is supported or not by the
firmware and use it to filter which calls done to the firm
On 25/09/2024 5:45 pm, Ard Biesheuvel wrote:
> On Wed, 25 Sept 2024 at 18:39, Linus Torvalds
> wrote:
>> And we do have special calling conventions that aren't the regular
>> ones, so %rdi might actually be used elsewhere. For example,
>> __get_user_X and __put_user_X all have magical calling conv
On Wed, Sep 25, 2024 at 10:44 AM Edgar E. Iglesias
wrote:
> On Wed, Sep 25, 2024 at 05:38:13PM +0100, Julien Grall wrote:
> > Hi Edgar,
> >
> > On 25/09/2024 17:34, Edgar E. Iglesias wrote:
> > > On Wed, Sep 25, 2024 at 08:44:41AM +0100, Julien Grall wrote:
> > > > Hi,
> > > > On 24/09/2024 17:23
On Wed, 25 Sept 2024 at 18:39, Linus Torvalds
wrote:
>
> On Wed, 25 Sept 2024 at 08:16, Ard Biesheuvel wrote:
> >
> > Instead of pushing an immediate absolute address, which is incompatible
> > with PIE codegen or linking, use a LEA instruction to take the address
> > into a register.
>
> I don't
On 24/09/2024 09:23, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 22 Sep 2024, at 14:25, Julien Grall wrote:
Hi Bertrand,
NIT Typo: s/fix/Fix/ to match the other title
Ack
On 19/09/2024 14:19, Bertrand Marquis wrote:
Fix FFA version negotiation with the firmware to follow t
On Wed, Sep 25, 2024 at 05:38:13PM +0100, Julien Grall wrote:
> Hi Edgar,
>
> On 25/09/2024 17:34, Edgar E. Iglesias wrote:
> > On Wed, Sep 25, 2024 at 08:44:41AM +0100, Julien Grall wrote:
> > > Hi,
> > > On 24/09/2024 17:23, Edgar E. Iglesias wrote:
> > > > From: Stewart Hildebrand
> > > >
> >
On Wed, 25 Sept 2024 at 08:16, Ard Biesheuvel wrote:
>
> Instead of pushing an immediate absolute address, which is incompatible
> with PIE codegen or linking, use a LEA instruction to take the address
> into a register.
I don't think you can do this - it corrupts %rdi.
Yes, the code uses %rdi
Hi Edgar,
On 25/09/2024 17:34, Edgar E. Iglesias wrote:
On Wed, Sep 25, 2024 at 08:44:41AM +0100, Julien Grall wrote:
Hi,
On 24/09/2024 17:23, Edgar E. Iglesias wrote:
From: Stewart Hildebrand
When virtio-pci is specified in the dom0less domU properties, create a
virtio-pci node in the guest
On Wed, Sep 25, 2024 at 08:44:41AM +0100, Julien Grall wrote:
> Hi,
>
Hi Julien,
> On 24/09/2024 17:23, Edgar E. Iglesias wrote:
> > From: Stewart Hildebrand
> >
> > When virtio-pci is specified in the dom0less domU properties, create a
> > virtio-pci node in the guest's device tree. Set up a
On Fri, Aug 16, 2024 at 07:02:54PM +0100, Alejandro Vallejo wrote:
> On Fri Jul 26, 2024 at 4:21 PM BST, Roger Pau Monne wrote:
> > Instead of allocating a monitor table for each vCPU when running in HVM HAP
> > mode, use a per-pCPU monitor table, which gets the per-domain slot updated
> > on
> >
On Wed, 2024-09-25 at 10:36 +0200, Jan Beulich wrote:
> PPC's desire to use DECL_SECTION() can certainly be covered by
> providing
> a (trivial) DECL_SECTION() also for Arm and RISC-V. Seeing that even
> x86
> overrides the default to the trivial form for building xen.efi, I'm
> inclined to suggest
On Wed, Sep 25, 2024 at 8:02 AM Ard Biesheuvel wrote:
>
> From: Ard Biesheuvel
>
> Specify the guard symbol for the stack cookie explicitly, rather than
> positioning it exactly 40 bytes into the per-CPU area. Doing so removes
> the need for the per-CPU region to be absolute rather than relative
On Wed, Sep 25, 2024, at 15:01, Ard Biesheuvel wrote:
> From: Ard Biesheuvel
>
> Bump the minimum GCC version to 8.1 to gain unconditional support for
> referring to the per-task stack cookie using a symbol rather than
> relying on the fixed offset of 40 bytes from %GS, which requires
> elaborate
---
xen/arch/x86/srat.c | 45 ++--
xen/arch/x86/x86_64/mm.c | 22 ++--
xen/common/numa.c| 27 ++--
3 files changed, 88 insertions(+), 6 deletions(-)
diff --git a/xen/arch/x86/srat.c b/xen/arch/x86/srat.c
index 68
On 25.09.2024 17:27, Roger Pau Monné wrote:
> On Wed, Sep 25, 2024 at 04:03:04PM +0200, Jan Beulich wrote:
>> On 25.09.2024 15:31, Roger Pau Monné wrote:
>>> On Wed, Aug 14, 2024 at 12:10:56PM +0200, Jan Beulich wrote:
On 26.07.2024 17:21, Roger Pau Monne wrote:
> --- a/docs/misc/xen-comma
From: Ard Biesheuvel
The relocs tool is no longer used on vmlinux, which is the only 64-bit
ELF executable that it used to operate on in the 64-bit build. (It is
still used for parts of the decompressor)
So drop the 64-bit handling - it is dead code now.
Signed-off-by: Ard Biesheuvel
---
arch
On Wed, Sep 25, 2024 at 04:03:04PM +0200, Jan Beulich wrote:
> On 25.09.2024 15:31, Roger Pau Monné wrote:
> > On Wed, Aug 14, 2024 at 12:10:56PM +0200, Jan Beulich wrote:
> >> On 26.07.2024 17:21, Roger Pau Monne wrote:
> >>> --- a/docs/misc/xen-command-line.pandoc
> >>> +++ b/docs/misc/xen-comman
From: Ard Biesheuvel
Build the kernel as a Position Independent Executable (PIE). This
results in more efficient relocation processing for the virtual
displacement of the kernel (for KASLR). More importantly, it instructs
the linker to generate what is actually needed (a program that can be
moved
From: Ard Biesheuvel
Instead of pushing an immediate absolute address, which is incompatible
with PIE codegen or linking, use a LEA instruction to take the address
into a register.
Signed-off-by: Ard Biesheuvel
---
arch/x86/kernel/rethook.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(
From: Ard Biesheuvel
Calling C code via a different mapping than it was linked at is
problematic, because the compiler assumes that RIP-relative and absolute
symbol references are interchangeable. GCC in particular may use
RIP-relative per-CPU variable references even when not using -fpic.
So ca
From: Ard Biesheuvel
Due to the placement of per-CPU variables in a special, 0x0 based
disjoint memory segment in the ELF binary, the KASLR relocation tool
needed to perform special processing for references to such variables,
as they were not affected by KASLR displacement.
This meant that abso
From: Ard Biesheuvel
Specify the guard symbol for the stack cookie explicitly, rather than
positioning it exactly 40 bytes into the per-CPU area. Doing so removes
the need for the per-CPU region to be absolute rather than relative to
the placement of the per-CPU template region in the kernel imag
From: Ard Biesheuvel
In some cases, LLVM's lld linker may emit the following symbol into the
symbol table
? _GLOBAL_OFFSET_TABLE_
and its presence throws off the relative base logic in kallsyms. Since
0x0 is never a valid relative base, just ignore it.
Signed-off-by: Ard Biesh
From: Ard Biesheuvel
Add support for standard dynamic ELF relocations to perform the virtual
relocation of the core kernel at boot. The RELR format results in a 10x
reduction in memory footprint of the relocation data, and can be
generated by the linker directly. This removes the need for
a) a ho
From: Ard Biesheuvel
Use ordinary RIP-relative references to make the code compatible with
running the linker in PIE mode.
Note that wakeup_long64() runs in the kernel's ordinary virtual mapping
so there is no need to record the address of .Lresume_point in a global
variable. And fix the comment
From: Ard Biesheuvel
Use RIP-relative symbol references to make them compatible with running
the linker in PIE mode.
Signed-off-by: Ard Biesheuvel
---
arch/x86/kernel/head_64.S| 14 +-
arch/x86/kernel/relocate_kernel_64.S | 6 --
2 files changed, 13 insertions(+),
From: Ard Biesheuvel
As an intermediate step towards enabling PIE linking for the 64-bit x86
kernel, enable PIE codegen for all objects that are linked into the
kernel proper.
This substantially reduces the number of relocations that need to be
processed when booting a relocatable KASLR kernel.
From: Ard Biesheuvel
Fix up a couple of occurrences in the x86_64 entry code where we take
the absolute address of a symbol while we could use RIP-relative
addressing just the same. This avoids relocation fixups at boot for
these quantities.
Signed-off-by: Ard Biesheuvel
---
arch/x86/entry/cal
From: Ard Biesheuvel
In some cases, the compiler may rely on indirect calls using GOT slots
as memory operands to emit function calls. This leaves it up to the
linker to relax the call to a direct call if possible, i.e., if the
destination address is known at link time and in range, which may not
From: Ard Biesheuvel
The .head.text section contains code that may execute from a different
address than it was linked at. This is fragile, given that the x86 ABI
can refer to global symbols via absolute or relative references, and the
toolchain assumes that these are interchangeable, which they
From: Ard Biesheuvel
When running the compiler in PIC/PIE mode, it will emit data objects
that are 'const' in the context of the program into the .data.rel.ro
section if they contain absolute addresses of statically allocated
global objects. This helps the dynamic loader distinguish between
objec
From: Ard Biesheuvel
The code in .head.text executes from a 1:1 mapping and cannot generally
refer to global variables using their kernel virtual addresses. However,
there are some occurrences of such references that are valid: the kernel
virtual addresses of _text and _end are needed to populate
From: Ard Biesheuvel
Use RIP-relative accesses and avoid fixups at runtime.
Signed-off-by: Ard Biesheuvel
---
arch/x86/include/asm/sync_core.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/include/asm/sync_core.h b/arch/x86/include/asm/sync_core.h
index ab7382f
From: Ard Biesheuvel
SMP on x86_64 no longer needs absolute per-CPU variables, so this
support can be dropped from kallsyms as well, as no other architectures
rely on this functionality.
Signed-off-by: Ard Biesheuvel
---
init/Kconfig| 4 --
kernel/kallsyms.c | 12 +
scri
From: Ard Biesheuvel
objtool generates ELF sections such as __mcount_loc, which carry
absolute symbol references that need to be fixed up at boot time, based
on the actual virtual placement of the kernel binary.
This involves writing to the section at boot time, and in some cases
(e.g., when usi
From: Ard Biesheuvel
Use RIP-relative accesses and 32-bit offsets for .tracedata, to avoid
the need for relocation fixups at boot time.
Signed-off-by: Ard Biesheuvel
---
arch/x86/include/asm/pm-trace.h | 4 ++--
drivers/base/power/trace.c | 6 +++---
2 files changed, 5 insertions(+), 5 de
From: Ard Biesheuvel
For historic reasons, per-CPU symbols on x86_64 are emitted in an
address space that is disjoint from the ordinary kernel VA space,
starting at address 0x0. This splits a per-CPU symbol reference into a
base plus offset, where the base is programmed into the GS segment
regist
From: Ard Biesheuvel
Replace some absolute symbol references with RIP-relative ones, so we
don't need to fix them up at boot.
Signed-off-by: Ard Biesheuvel
---
arch/x86/power/hibernate_asm_64.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/power/hibernate_asm
From: Ard Biesheuvel
Xen puts virtual and physical addresses into ELF notes that are treated
by the linker as relocatable by default. Doing so is not only pointless,
given that the ELF notes are only intended for consumption by Xen before
the kernel boots. It is also a KASLR leak, given that the
From: Ard Biesheuvel
Implicit absolute symbol references (e.g., taking the address of a
global variable) must be avoided in the C code that runs from the early
1:1 mapping of the kernel, given that this is a practice that violates
assumptions on the part of the toolchain. I.e., RIP-relative and
a
From: Ard Biesheuvel
Some of the early x86_64 startup code is written in C, and executes in
the early 1:1 mapping of the kernel, which is not the address it was
linked at, and this requires special care when accessing global
variables. This is currently being dealt with on an ad-hoc basis,
primar
From: Ard Biesheuvel
Avoid absolute references in code, which require fixing up at boot time,
and replace them with RIP-relative ones. In this particular case, due to
the register pressure, they cannot be avoided entirely, so one absolute
reference is retained but the resulting reference via the
From: Ard Biesheuvel
Bump the minimum GCC version to 8.1 to gain unconditional support for
referring to the per-task stack cookie using a symbol rather than
relying on the fixed offset of 40 bytes from %GS, which requires
elaborate hacks to support.
Signed-off-by: Ard Biesheuvel
---
Documentat
From: Ard Biesheuvel
The x86_64 port has a number of historical quirks that result in a
reliance on toolchain features that are either poorly specified or
basically implementation details of the toolchain:
- the 'kernel' C model implemented by the compiler is intended for
position dependent co
From: Ard Biesheuvel
Instead of relying on fseek() and fread() to traverse the vmlinux file
when processing the ELF relocations, mmap() the whole thing and use
memcpy() or direct references where appropriate:
- the executable and section headers are byte swabbed before use if the
host is big en
On 24.09.2024 18:42, Oleksii Kurochko wrote:
> --- a/xen/include/asm-generic/percpu.h
> +++ b/xen/include/asm-generic/percpu.h
> @@ -10,7 +10,14 @@
> extern char __per_cpu_start[];
> extern const char __per_cpu_data_end[];
Afaics the only users of these two are in the new common/percpu.c. These
flight 187855 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187855/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-arm64-arm64-xl-xsm 1
On 25/09/2024 2:35 pm, Roger Pau Monné wrote:
> On Wed, Sep 25, 2024 at 12:18:59PM +0100, Andrew Cooper wrote:
>> On 12/09/2024 2:23 pm, Roger Pau Monne wrote:
>>> Reported-by: Andrew Cooper
>>> Signed-off-by: Roger Pau Monné
>>> ---
>>> CHANGELOG.md | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
Hi all,
Quick poll to gather interest for next Xen Project/Zephyr meetup in
Cambridge.
*Date: 24th October 2024*
We are also seeking two speakers for demos/lightning talks.
Could you reply with a +1 if interested in attending?
Just looking to gather numbers for now.
Kelly Choi
Community Manager
On 25.09.2024 16:50, oleksii.kuroc...@gmail.com wrote:
> On Wed, 2024-09-25 at 16:22 +0200, Jan Beulich wrote:
>> On 25.09.2024 12:07, oleksii.kuroc...@gmail.com wrote:
>>> On Tue, 2024-09-24 at 15:31 +0200, Jan Beulich wrote:
On 24.09.2024 13:30, oleksii.kuroc...@gmail.com wrote:
> On Tue
On Wed, 2024-09-25 at 16:22 +0200, Jan Beulich wrote:
> On 25.09.2024 12:07, oleksii.kuroc...@gmail.com wrote:
> > On Tue, 2024-09-24 at 15:31 +0200, Jan Beulich wrote:
> > > On 24.09.2024 13:30, oleksii.kuroc...@gmail.com wrote:
> > > > On Tue, 2024-09-24 at 12:49 +0200, Jan Beulich wrote:
> > > >
On 25.09.2024 12:07, oleksii.kuroc...@gmail.com wrote:
> On Tue, 2024-09-24 at 15:31 +0200, Jan Beulich wrote:
>> On 24.09.2024 13:30, oleksii.kuroc...@gmail.com wrote:
>>> On Tue, 2024-09-24 at 12:49 +0200, Jan Beulich wrote:
On 13.09.2024 17:57, Oleksii Kurochko wrote:
> +static int pt_n
flight 187845 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/187845/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 187228
test-amd64-amd64-xl-qemut-win7-a
On 25.09.2024 15:31, Roger Pau Monné wrote:
> On Wed, Aug 14, 2024 at 12:10:56PM +0200, Jan Beulich wrote:
>> On 26.07.2024 17:21, Roger Pau Monne wrote:
>>> --- a/docs/misc/xen-command-line.pandoc
>>> +++ b/docs/misc/xen-command-line.pandoc
>>> @@ -2387,7 +2387,7 @@ By default SSBD will be mitigat
On 9/25/24 02:28, Juergen Gross wrote:
> On 16.09.24 10:44, Juergen Gross wrote:
>> x86 maintainers,
>>
>> are you going to pick this series up, or should I take it via the
>> Xen tree?
>
> I take the silence as a "its okay to go via the Xen tree".
Or, "most of us were traveling last week and in
On 8/23/24 12:36, Jason Andryuk wrote:
> The PVH entry point will need an additional set of prebuild page tables.
> Move the macros and defines to pgtable_64.h, so they can be re-used.
>
> Signed-off-by: Jason Andryuk
> Reviewed-by: Juergen Gross
Acked-by: Dave Hansen
On Wed, Sep 25, 2024 at 11:53:30AM +0100, Andrew Cooper wrote:
> On 25/09/2024 9:42 am, Roger Pau Monne wrote:
> > alternatives is used both at boot time, and when loading livepatch payloads.
> > While for the former it makes sense to panic, it's not useful for the
> > later, as
> > for livepatche
1 - 100 of 160 matches
Mail list logo
