suing
the tools/firmware/include/ headers.
This in turn requires making firmware's stdint.h compatible with 64bit builds.
We now have compiler types for every standard type we use.
Suggested-by: Jan Beulich
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
tools/firmw
On 28/03/2025 2:05 pm, Anthony PERARD wrote:
> On Thu, Mar 27, 2025 at 05:43:02PM +0000, Andrew Cooper wrote:
>> The $(eval $(check-y)) is badly positioned:
>>
>> xen.git/xen$ make
>> *** FATAL BUILD ERROR: Xen requires at least GCC 0x150100
>> *** FATAL B
On 28/03/2025 1:44 pm, Andrew Cooper wrote:
> From: Lin Liu
>
> These wrappers simply hide a deference, which adds to the cognitive complexity
> of reading the code. As such, they're not going to be included in the new
> byteswap infrastructure.
>
> No functional chan
With the common code moved fully onto xen/byteorder.h, clean up the dregs.
The use of byteorder.h in io.h appears to have been copy&paste from ARM. It's
not needed, but macros and types are.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
With the common code moved fully onto xen/byteorder.h, clean up the dregs.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Shawn Anastasio
CC
move tmem from hypervisor")
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Shawn Anastasio
CC: Oleksii Kurochko
CC: Daniel P. Smith
CC: Lin Li
e.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Shawn Anastasio
CC: Oleksii Kurochko
CC: Daniel P. Smith
CC: Lin Liu
v5:
* New
---
xe
From: Lin Liu
These wrappers simply hide a deference, which adds to the cognitive complexity
of reading the code. As such, they're not going to be included in the new
byteswap infrastructure.
No functional change.
Signed-off-by: Lin Liu
Signed-off-by: Andrew Cooper
---
CC: Anthony P
From: Lin Liu
This file has its own implementation of swap bytes. Clean up
the code with xen/byteswap.h.
No functional change.
Signed-off-by: Lin Liu
Acked-by: Jan Beulich
Reviewed-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau
Sort the includes. Drop useless includes of xen/types.h
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Shawn Anastasio
CC: Oleksii Kurochko
There is a singular user. It's unlikely we'll gain a big-endian build of Xen,
but it's far more unlikely that bitfields will differ from main endianness.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Mon
With the common code moved fully onto xen/byteorder.h, clean up the dregs.
Sort includes in some files while swapping over to xen/byteorder.h.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC
Sort the includes while at it.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Shawn Anastasio
CC: Oleksii Kurochko
CC
: Lin Liu
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Shawn Anastasio
CC: Oleksii Kurochko
CC: Daniel P. Smith
CC: Lin Liu
v5:
* Rebase
defined. Therefore, centralise their definitions in xen/config.h
Signed-off-by: Lin Liu
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Shawn
From: Lin Liu
It is no longer used.
Signed-off-by: Lin Liu
Reviewed-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Shawn Anastasio
CC: Oleksii
From: Lin Liu
In divmod.c, additionally swap xen/lib.h for xen/macros.h as only ABS() is
needed.
In find-next-bit.c, ext2 has nothing to do with this logic. Despite the
comments, it was a local modification when the logic was imported from Linux,
because Xen didn't have a suitable helper.
The
From: Lin Liu
unaligned.h already inlcudes byteorder.h, so most can simply be dropped.
No functional change.
Signed-off-by: Lin Liu
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Volodymyr Babchuk
CC: Bertrand Marq
The diffstat speaks for itself.
This is a follow-up to Lin's years-old series, rebased to account for RISC-V
and PPC, and simplified owing to our new compiler baseline.
Andrew Cooper (8):
xen/lzo: Remove more remanants of TMEM
xen: Remove __{BIG,LITTLE}_ENDIAN_BITFIELD
xsm/flask: S
From: Lin Liu
These wrappers simply hide a deference, which adds to the cognitive complexity
of reading the code. As such, they're not going to be included in the new
byteswap infrastructure.
No functional change.
Signed-off-by: Lin Liu
Signed-off-by: Andrew Cooper
---
CC: Anthony P
_LONG_LONG__)
> +
> +/* It is assumed that sizeof(void *) == __alignof(void *) */
> +#define POINTER_ALIGN __SIZEOF_POINTER__
> +
> #endif /* __XEN_CONFIG_H__ */
As it turns out, this is a prerequisite for the byteswap cleanup.
~Andrew
to
> update to the new baseline, ..."
This is now committed.
~Andrew
gt; across
>> architectures.
>>
>> Additionally, *_BYTEORDER macros are removed, as BITS_PER_* values now come
>> directly from the compiler environment.
>>
>> The arch_fls() implementation for Arm and PPC is updated to use BITS_PER_INT
>> instead of a hardcoded value of 32.
On 27/03/2025 4:05 pm, Oleksii Kurochko wrote:
>
>
> On 3/27/25 4:37 PM, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Anthony PERARD
>> CC: Michal Orzel
>> CC: Jan Beulich
>> CC: Julien Grall
>> CC: Roger Pau Monné
her conditionals here using only a
>> major version, with subversion being 0, I think the same should go for 14.
>> Unless of course there is a good reason to be inconsistent.
> As I said, 9nth counter was added in GCC 14.1, GCC 14.0 had less counters.
In GCC's numbering scheme, .0 is the dev window and .1 is the release.
The 9th counter will have appeared somewhere in the dev window, but
that's all GCC 14 as far as we're concerned.
~Andrew
.
Include a GCC 12.2 check for RISCV, and include a Clang 11 baseline check.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Oleksii Kurochko
v3:
* Reinstate the xen/compiler.h block
On 27/03/2025 4:55 pm, Oleksii Kurochko wrote:
>
>
> On 3/27/25 4:45 PM, Andrew Cooper wrote:
>> On 21/03/2025 4:24 pm, Oleksii Kurochko wrote:
>>> On 3/20/25 4:59 PM, Andrew Cooper wrote:
>>>> Signed-off-by: Andrew Cooper
>>>> ---
>>>
On 27/03/2025 4:39 pm, Jan Beulich wrote:
> On 27.03.2025 17:31, Andrew Cooper wrote:
>> We have checks in both xen/compiler.h, and Config.mk. Both are incomplete.
>> Remove the one from compiler.h, as it's pointless to perform in addition to
>> the xen.git-wide
On 27/03/2025 4:37 pm, Oleksii Kurochko wrote:
>
>
> On 3/27/25 5:31 PM, Andrew Cooper wrote:
>> We have checks in both xen/compiler.h, and Config.mk. Both are incomplete.
>> Remove the one from compiler.h, as it's pointless to perform in addition to
>> the xen.gi
On 21/03/2025 4:24 pm, Oleksii Kurochko wrote:
>
>
> On 3/20/25 4:59 PM, Andrew Cooper wrote:
>> Signed-off-by: Andrew Cooper
>> ---
>> CC: Anthony PERARD
>> CC: Michal Orzel
>> CC: Jan Beulich
>> CC: Julien Grall
>> CC: Roger Pau Monné
On 27/03/2025 4:31 pm, Andrew Cooper wrote:
> diff --git a/Config.mk b/Config.mk
> index 8a73f3da62b4..a9d62fc10cfa 100644
> --- a/Config.mk
> +++ b/Config.mk
> @@ -125,8 +125,18 @@ define cc-ver-check-closure
> endif
> endef
>
> -# Require GCC v4.1+
> -chec
, and inherits the GCC 5.1 global baseline.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Oleksii Kurochko
v2:
* Change to altering Config.mk
https://gitlab.com/xen-project/people/andyhh
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Oleksii Kurochko
v2:
* State x86 and ARM, rather than implying all architectures.
---
CHANGELOG.md | 3 +++
1 file changed, 3 insertions
>> Hm, no idea really. We do the device restore ahead of the MTRR
>>>> restore, so I wonder whether we could have issues by using unexpected
>>>> effective cache attributes for device memory accesses as a result of
>>>> MTRRs not being initialized?
>>&g
27;t. It was lost in 4304ff420e51 ("x86/S3: Drop
> {save,restore}_rest_processor_state() completely"), with there being no
> indication in the description that this was actually intentional. Looks like
> another S3 regression we need to fix. Unless you, Andrew, have an explanation
> for this.
Hmm, I don't think I intended to make a change without discussing it.
However, I think I'd concluded that it was redundant with the
mtrr_aps_sync_end() call.
~Andrew
c: Fix out-of-bounds accesses in vgic_mmio_write_sgir()
Looking at the patchqueue, the only one I can see is
c11772277fe5 - tools/ocaml: Fix oxenstored build warning.
~Andrew
These are all loops over a scalar value, and don't need to call general bitop
helpers behind the scenes.
Clamp data to the width of the access in dispatch_mmio_write(), rather than
doing so in every handler.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Stefano Stabellin
On 27/03/2025 8:21 am, Jan Beulich wrote:
> On 27.03.2025 01:44, Andrew Cooper wrote:
>> On 26/03/2025 5:47 pm, Oleksii Kurochko wrote:
>>> diff --git a/xen/include/xen/config.h b/xen/include/xen/config.h
>>> index d888b2314d..dbbf2fce62 100644
>>> --- a/xe
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Oleksii Kurochko
---
CHANGELOG.md | 3 +++
1 file changed, 3 insertions(+)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 9a5919585d43
place the "<< 3" as you're hard-coding 8 here
and ignoring __CHAR_BIT__.
I'd suggest keeping the BITS_PER_BYTE on the LHS, e.g:
#define BITS_PER_INT (BITS_PER_BYTE * __SIZEOF_INT__)
which tabulates better.
I suggest keeping BITS_PER_XEN_ULONG to be arch-local. ARM is the
odd-one-out having a non-64bit arch use a 64bit XEN_ULONG.
~Andrew
ily ack this based on diffstat alone.
Juergen has expressed an interest in finally purging qemu-trad in this
release cycle, which I agree with.
If we're going to do this, then I suggest we delete qemu-trad first.
Otherwise we are technically breaking something that someone might be using.
~Andrew
>
> The device model version for a domain.
>
As a spec of what might liably be found in xenstore, this probably
shouldn't remove "qemu_xen_traditional" entirely. Perhaps an extra
sentence saying "qemu_xen_traditional" is a since-removed dm-version?
~Andrew
d qemu-xen were
not inter-operable and we needed Windows not to go a shade of blue.
Therefore I'd prefer if this could stay in it's off-by-default form,
rather than carrying a revert.
~Andrew
C: Add SGIR register handler")
Signed-off-by: Andrew Cooper
---
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bertrand Marquis
CC: Michal Orzel
This vgic driver is explicity not security supported, hence no XSA.
---
xen/arch/arm/vgic/vgic-mmio-v2.c | 3 ++-
1 file ch
V CR8 generates #UD rather than becoming a
CR0 access.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
Also, designers never put an ADD into silicon if they can possibly avoid it,
because it's slow and large compared to the single OR gate needed in this
case.
---
xen/
On 26/03/2025 2:29 pm, Anthony PERARD wrote:
> CONFIG_GCOV_FORMAT_AUTODETECT has been removed in 767e6c5fd55b.
>
> Fixes: 767e6c5fd55b ("kconfig/gcov: remove gcc version choice from kconfig")
> Signed-off-by: Anthony PERARD
Reviewed-by: Andrew Cooper
On 26/03/2025 10:15 am, Jan Beulich wrote:
> On 25.03.2025 18:04, Oleksii Kurochko wrote:
>> On 3/25/25 5:46 PM, Jan Beulich wrote:
>>> On 25.03.2025 17:35, Oleksii Kurochko wrote:
>>>> On 3/7/25 1:12 PM, Andrew Cooper wrote:
>>>>> On 07/03/2025 12:01 p
I to initialize
> vpl011")
> Signed-off-by: Jan Beulich
Reviewed-by: Andrew Cooper
On 26/03/2025 11:38 am, Jan Beulich wrote:
> copy_to_guest() returns the number of bytes not copied; that's not what
> the function should return to its caller though. Convert to returning
> -EFAULT instead.
>
> Fixes: 7542c4ff00f2 ("Add user PM control interface"
On 26/03/2025 11:19 am, Jan Beulich wrote:
> On 25.03.2025 18:41, Andrew Cooper wrote:
>> Petr reports:
>>
>> (XEN) MMIO emulation failed (1): d12v1 64bit @ 0010:f8057ba7dfbf -> 45
>> 0f 20 c2 ...
>>
>> during introspection.
>>
>> This i
On 26/03/2025 9:00 am, Jan Beulich wrote:
> On 25.03.2025 19:00, Andrew Cooper wrote:
>> I was mistaken about when ASM_CALL_CONSTRAINT is applicable. It is not
>> applicable for plain pushes/pops, so remove it from the flags logic.
>>
>> Clarify the description o
On 26/03/2025 9:20 am, Jan Beulich wrote:
> On 25.03.2025 19:52, Andrew Cooper wrote:
>> It turns out that LZCNT/TZCNT have the same input dependent bug, prior to
>> Skylake.
> These two do, but BSF/BSR don't? Pretty odd.
BSF/BSR have true input dependencies. They bo
r x86 maintainers wouldn't prefer this
> to not go in in the first place (so I'll also give it another day or two).
I'm ok with this change. Unlike v1, it's meaningful in context.
~Andrew
In hvmemul_read_cr(), make the TRACE()/X86EMUL_OKAY path common in preparation
for adding a %cr8 case. Use a local 'val' variable instead of always
operating on a deferenced pointer.
In both, calculate curr once.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan B
Manually break the false dependency for the benefit of cases such as
bitmap_weight() which is a reasonable hotpath.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
Not sure if this warrants a fixes or not, but:
Fixes: 6978602334d9 ("x86/bitops: Use the POPCNT instru
ation in elf_core_save_regs()")
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/arch/x86/include/asm/asm_defns.h | 5 +++--
xen/arch/x86/include/asm/x86_64/elf.h | 2 +-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/include/asm/asm_
This very quickly turned into a rats nest. I don't have time to fix %cr8
handling, so stay with a stopgap mitigation for introspection puporses, and
leave some notes for later.
Andrew Cooper (2):
x86/hvm: Rearrange the logic in hvmemul_{read,write}_cr()
x86/emul: Emulate %cr8 accesses
quot;)
> Signed-off-by: Jan Beulich
The code change looks ok, so Acked-by: Andrew Cooper
but I'd prefer a clarified commit message.
On 25/03/2025 2:00 pm, Jan Beulich wrote:
> On 25.03.2025 14:52, Andrew Cooper wrote:
>> On 25/03/2025 12:53 pm, Jan Beulich wrote:
>>> --- a/xen/drivers/acpi/pmstat.c
>>> +++ b/xen/drivers/acpi/pmstat.c
>>> @@ -219,25 +218,22 @@ static int get_cpufreq_para(stru
also drop j (we can use i twice) and adjust the type of
> the remaining two variables on that line.
>
> Signed-off-by: Jan Beulich
Wow this function is a mess.
It is an improvement, so Acked-by: Andrew Cooper
, but the allocations could be removed
entirely by restructuring the logic some
-8dc9-e9683d4ca...@suse.com/
> Link:
> https://lkml.kernel.org/r/20241219092615.644642-2-ariel.otilibili-ani...@eurecom.fr
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Ariel Otilibili
> Suggested-by: Jan Beulich
> Signed-off-by: Andrew Morton
> Orig
* simplify it.
> */
> -extra_space = sizeof(start_info);
> -
> if ( initrd )
> -extra_space += sizeof(mod) + ROUNDUP(initrd_len, PAGE_SIZE);
> +{
> +extra_space = elf_round_up(&elf, initrd_len);
I'm going to insist on not doing this. For the sake of anyone (else)
trying to follow this logic.
You're trading increased cognitive complexity of the logic to avoid
using one local variable.
~Andrew
s manual fixup to prevent your commits going in as
authored by dm...@proton.me, and one already slipped through.
https://xenbits.xen.org/gitweb/?p=xen.git&a=search&h=refs%2Fheads%2Fstaging&st=author&s=dmkhn%40proton.me
Thanks,
~Andrew
***
> (XEN) [9.630471] Panic on CPU 14:
> (XEN) [9.634182] UBSAN failure detected
> (XEN) [9.638469]
>
> throughout tests on actual hardware in CI. And really I don't think it's just
> UB, but
> rather a real NULL deref:
This is a consequence of us turning on UBSAN generally in GitlabCI, and
will be the norm moving forward.
Nevertheless, "member access within null pointer of type $X" is very
clear cut.
~Andrew
uivalent comments for the other trees.
I'm not sure if it's useful to delete the check-in policy. I think the
note at the top listing the backport maintainers is good enough.
~Andrew
On 21/03/2025 6:52 am, Jan Beulich wrote:
> On 20.03.2025 18:56, Andrew Cooper wrote:
>> On 18/03/2025 3:26 pm, Jan Beulich wrote:
>>> The sole dependency is percpu_init_areas(),
>>> which runs - as even visible from patch context here - ahead of
>>> earl
ater into traps_init(). Note that it already
contains enable_each_ist(), so the call is simply dropped.
This removes some complexity prior to having exception support, and lays the
groundwork to not even allocate a TSS when using FRED.
No practical change.
Signed-off-by: Andrew Cooper
---
CC: Jan Be
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Oleksii Kurochko
---
CHANGELOG.md | 3 +++
1 file changed, 3 insertions(+)
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 9a5919585d43
Prep work to allow us to start making changes based on the toolchain
requirements.
https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1726628670
https://cirrus-ci.com/build/5232741505040384
Andrew Cooper (3):
CI: Update build tests based on new minimum toolchain requirements
Xen
We didn't really have a Clang check before, so add one while adjusting the GCC
check.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Oleksii Kurochko
---
xen/include/xen/compiler.h
Prep work to allow us to start making changes based on the toolchain
requirements.
https://gitlab.com/xen-project/people/andyhhp/xen/-/pipelines/1726628670
https://cirrus-ci.com/build/5232741505040384
Andrew Cooper (3):
CI: Update build tests based on new minimum toolchain requirements
Xen
We didn't really have a Clang check before, so add one while adjusting the GCC
check.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Oleksii Kurochko
---
xen/include/xen/compiler.h
On 13/03/2025 9:27 am, Choi, Anderson wrote:
> May I know when you think it would be mainlined? And will it be applied to
> all branches, like 4.19 and 4.20?
FYI, backports of this and the xfree() bug have just happened, back to 4.18.
~Andrew
On 19/03/2025 9:05 am, Roger Pau Monné wrote:
> On Tue, Mar 18, 2025 at 08:10:33PM +0000, Andrew Cooper wrote:
>> The LRET is detached from the PUSHes which set it up, and this is about to
>> get
>> worse with the changes to trampoline relocation. For the sake of one
>
eading to SetUefiImageMemoryAttributes() leaves open where
> gCpu->SetMemoryAttributes() is implemented. I can spot some Arm and RISC-V
> code
> with respective names (albeit in distinct places), and MTRR functionality with
> names along these lines. None of these can be it.
https://www.kraxel.org/blog/2023/12/uefi-nx-linux-boot/
~Andrew
sh the VM if it executes an STGI instruction,
rather than injecting #UD.
~Andrew
On 20/03/2025 9:28 am, Jan Beulich wrote:
> Signed-off-by: Jan Beulich
> ---
> I was wondering whether in elf_round_up() itself we might better use
> ROUNDUP().
I did wonder that too. It's probably easier to arrange now we've got
xen-tools/common-macros.h.
Reviewed-by: Andrew Cooper
On 19/03/2025 9:41 pm, Jason Andryuk wrote:
> On 2025-03-19 13:13, Andrew Cooper wrote:
>> The expression for one parameter of find_memory() is already
>> complicated and
>> about to become moreso. Break it out into a new variable, and
>> express it in
>>
On 19/03/2025 12:39 pm, Jan Beulich wrote:
> On 19.03.2025 13:12, Andrew Cooper wrote:
>> On 19/03/2025 11:18 am, Jan Beulich wrote:
>>> As per observation in practice, initrd->cmdline_pa is not normally zero.
>>> Hence so far we always appended at least one byte. Tha
The expression for one parameter of find_memory() is already complicated and
about to become moreso. Break it out into a new variable, and express it in
an easier-to-follow way.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
---
xen/arch/x86/hvm
to PAGE_SIZE? And hence the length should take
> into account a possible page offset of s?
All modules are page aligned, because we require this of the bootloader.
Prior to cd7cc5320bb2, Xen strictly depended on it, because we shifted
mod_start by 12 to operate on it.
cd7cc5320bb2 retained the alignment check, panic("Bootloader didn't
honor module alignment request\n");, but operates in terms of paddr, not
frames.
~Andrew
elf_64bit(&elf) ? 8 : 4);
+
+ last_addr = find_memory(d, &elf, metadata_len);
if ( last_addr == INVALID_PADDR )
{
printk("Unable to find a memory region to load initrd and
metadata\n");
which I think I ought to submit as a prerequisite to this, after which
your logic squashed on the RHS now becomes an expansion of the `if (
initrd )`.
Thoughts?
~Andrew
quot;, Struct(None, [("gic_version", libxl_gic_version),
>> ("vuart", libxl_vuart_type),
>> ("sve_vl", libxl_sve_type),
>> - ("nr_spis", uint32),
>> + ("nr_spis", uint32, {'init_val':
>> 'UINT32_MAX'}),
>>])),
>> ("arch_x86", Struct(None, [("msr_relaxed", libxl_defbool),
>>])),
> Doesn't this regenerate the golang bindings?
You need a build environment with golang for that to happen. It's easy
to miss.
In this case, best to ask the committer to regen.
~Andrew
On 19/03/2025 8:46 am, Roger Pau Monné wrote:
> On Tue, Mar 18, 2025 at 05:45:09PM +0000, Andrew Cooper wrote:
>> On 18/03/2025 5:35 pm, Roger Pau Monne wrote:
>>> Clarify that trampoline_setup is only used for EFI when booted using the
>>> multiboot2 entry point.
>&
the program header offset of the LOAD segment when checking
> whether the NOTE segments is contained within.
>
> Fixes: a353cab905af ('build_id: Provide ld-embedded build-ids')
> Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
I'm not sure if it want's to go in ahead, merged with, or
after this patch.
Also, encoding bits in RELA_TARGET() isn't terribly nice. What's wrong
with keeping the casts as-are, and having RELA_TARGET() only taking ptr?
~Andrew
functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
Roger: I'd like this to be a prerequisite to your "[PATCH 4/7] x86/boot: apply
trampoline relocations at destination position" to avoid the movement of
reloc_trampoline32() making things worse
ic which depend on the trampoline being
placed, and ideally wouldn't, but they're quite easy to find now with
bootsym().
There's also definitely bits of logic which have temporaries in the
trampoline which shouldn't be there, and now that some of the
Hyperlaunch prep work is in place, can be moved out relatively easily.
~Andrew
; CONTENTS, ALLOC, LOAD, DATA
> [...]
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
On 17/03/2025 5:15 pm, Andrew Cooper wrote:
> On 17/03/2025 8:43 am, Jan Beulich wrote:
>> On 14.03.2025 18:59, Andrew Cooper wrote:
>>> This is an unnecessary indirection.
>>>
>>> Signed-off-by: Andrew Cooper
>> Reviewed-by: Jan Beulich
> So,
va + i - disp - rva);
> reloc_size += 2;
I'm on the fence about this.
Obviously we don't want a warning firing for good cases, but the
trampoline is special where the relocation is to a R/O section but we
don't apply the relocation in that position.
Is it possible to limit this to only trampoline_{start,end} and keep the
warning in general?
~Andrew
U LD warning.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
formly on all architectures, assuming that the
> addition was simply done as a copy and paste of the original x86 linking
> rune.
>
> Signed-off-by: Roger Pau Monné
-N has been stripped out of other parts of x86 too (hvmloader, notably),
and clearly isn't intended to be used in combination with a linker script.
Reviewed-by: Andrew Cooper
- * Called on legacy BIOS and EFI platforms.
> + * Called on legacy BIOS and EFI platforms when using multiboot
> (either
> + * 1 or 2).
> */
/* Called for Mutiboot entry, including MB2+EFI. */
is a little more concise?
~Andrew
e
> function.
>
> Signed-off-by: Roger Pau Monné
Whatever is wonky in the backtrace isn't related to this patch, so
Acked-by: Andrew Cooper , but the backtrace
does want fixing.
s: 84c4461b7d3a ("Force out-of-line instances of inline functions into
.init.text in init-only code")
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
CC: Michal Orzel
CC: Jan Beulich
CC: Julien Grall
CC: Roger Pau Monné
CC: Stefano Stabellini
---
xen/include/xen/compiler.h | 10 +
a special case for the bottom 1M where it
does nothing and exits.
What's the consequence of ioremap_wc() failing? Presumably nothing out
on the screen when using legacy text mode?
>From that point of view, this is an improvement I suppose.
~Andrew
he option won't be present in
> the first place if the compiler doesn't support -fsanitize=undefined.
>
> Signed-off-by: Roger Pau Monné
Reviewed-by: Andrew Cooper
I can't remember quite what it was, but it was very early days and I
recall the toolchain cared ab
+0x1252/0x2450
>[] F lib/xxhash64.c#svm_stgi_label+0x5/0x15
>
> Adjust the calculations in COMPAT_ARG_XLAT_VIRT_BASE to subtract from the
> per-domain area to obtain the mirrored linear address in the 4th slot,
> instead of overflowing the per-domain linear address.
>
> Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
he issue by latching esp to a local variable, this prevents
> clang duplicating the inline asm blocks.
>
> Suggested-by: Jan Beulich
> Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
1 - 100 of 7045 matches
Mail list logo
