On 3/31/2025 2:45 PM, Andrew Cooper wrote:
On 31/03/2025 9:22 am, Xin Li (Intel) wrote:
__wrmsr() is the lowest level primitive MSR write API, and its direct
use is NOT preferred. Use its wrapper function native_wrmsrl() instead.
No functional change intended.
Signed-off-by: Xin Li (Intel)
[Public]
> -Original Message-
> From: Jan Beulich
> Sent: Tuesday, March 25, 2025 5:58 PM
> To: Penny, Zheng
> Cc: Huang, Ray ; Andrew Cooper
> ; Roger Pau Monné ; xen-
> de...@lists.xenproject.org; Jason Andryuk
> Subject: Re: [PATCH v3 09/15] xen/x86: introduce a new amd cppc driver f
On 03/04/2025 10:58, Jan Beulich wrote:
>
>
> On 03.04.2025 10:44, Orzel, Michal wrote:
>> On 03/04/2025 10:43, Jan Beulich wrote:
>>> On 03.04.2025 10:19, Michal Orzel wrote:
Just like for RISCV and PPC, the earlier we enable the CI build the
better.
>>>
>>> What about Arm32?
>> The
On 03.04.2025 09:40, Penny, Zheng wrote:
>> -Original Message-
>> From: Jan Beulich
>> Sent: Tuesday, March 25, 2025 5:58 PM
>>
>>> +#define amd_get_freq(name)
>>> \
>>
>> The macro parameter is used just ...
>>
>>> +static int amd_get_
On 01.04.2025 03:17, Volodymyr Babchuk wrote:
> --- a/xen/Kconfig
> +++ b/xen/Kconfig
> @@ -41,6 +41,11 @@ config CC_SPLIT_SECTIONS
> config CC_HAS_UBSAN
> def_bool $(cc-option,-fsanitize=undefined)
>
> +# Compiler supports -fcondition-coverage aka MC/DC
> +config CC_HAS_MCDC
> + def_b
Just like for RISCV and PPC, the earlier we enable the CI build the
better.
Signed-off-by: Michal Orzel
---
automation/gitlab-ci/build.yaml | 10 ++
1 file changed, 10 insertions(+)
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index 2513908b059b..8cb770
Some of the uses of dom_cow aren't easily DCE-able (without extra
#ifdef-ary), and hence it being constantly NULL when MEM_SHARING=n
misguides Coverity into thinking that there may be a NULL deref in
if ( p2m_is_shared(t) )
d = dom_cow;
if ( get_page(page, d) )
On 03.04.2025 10:19, Michal Orzel wrote:
> Just like for RISCV and PPC, the earlier we enable the CI build the
> better.
What about Arm32?
Jan
On 03/04/2025 10:43, Jan Beulich wrote:
>
>
> On 03.04.2025 10:19, Michal Orzel wrote:
>> Just like for RISCV and PPC, the earlier we enable the CI build the
>> better.
>
> What about Arm32?
The series to enable compilation of Arm32 with MPU is still under review on the
ML.
~Michal
On 03/04/2025 11:28, Jan Beulich wrote:
>
>
> On 03.04.2025 11:17, Orzel, Michal wrote:
>> On 03/04/2025 10:58, Jan Beulich wrote:
>>> On 03.04.2025 10:44, Orzel, Michal wrote:
On 03/04/2025 10:43, Jan Beulich wrote:
> On 03.04.2025 10:19, Michal Orzel wrote:
>> Just like for RISC
On 03.04.2025 18:20, Oleksii Kurochko wrote:
>
> On 4/1/25 6:04 PM, Jan Beulich wrote:
>> On 01.04.2025 17:58, Oleksii Kurochko wrote:
>>> On 3/31/25 6:14 PM, Jan Beulich wrote:
On 31.03.2025 17:20, Oleksii Kurochko wrote:
> +_AC(XEN_VIRT_START, UL) >> vpn1_shift;
> +const
Added a new file prepare_xen_region.inc to hold the common earlyboot MPU regions
configurations across arm64 and arm32.
prepare_xen_region, fail_insufficient_regions() will be used by both arm32 and
arm64. Thus, they have been moved to prepare_xen_region.inc.
enable_secondary_cpu_mm() is a stub w
On 4/1/25 6:04 PM, Jan Beulich wrote:
On 01.04.2025 17:58, Oleksii Kurochko wrote:
On 3/31/25 6:14 PM, Jan Beulich wrote:
On 31.03.2025 17:20, Oleksii Kurochko wrote:
+_AC(XEN_VIRT_START, UL) >> vpn1_shift;
+const unsigned long xen_virt_end_vpn =
+xen_virt_starn_vpn + ((XE
On 03/04/2025 7:23 pm, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Improve error handling in VMX wrappers by switching to `asm goto()` where
> possible.
>
> vmread_safe() kept as is because the minimally required baseline GCC does
> not support output operands in `asm goto`.
>
> Resolves: http
Patches 1-5 remove various workarounds under HAVE_AS_XXX for older compilers,
as the minimally required GCC 5.1 / Binutils 2.25, and Clang 11 natively
support instructions worked around in the hypervisor code.
Patch 6 cleans up error handling in VMX asm wrappers using `asm goto`.
[1] Link to v1:
On 03/04/2025 7:23 pm, dm...@proton.me wrote:
> From: Denis Mukhin
>
> The new toolchain baseline knows the {rd,wr}{f,g}sbase instructions,
> no need to carry the workaround in the code.
>
> Resolves: https://gitlab.com/xen-project/xen/-/work_items/207
> Signed-off-by: Denis Mukhin
Reviewed-by:
On 03/04/2025 7:23 pm, dm...@proton.me wrote:
> From: Denis Mukhin
>
> The new toolchain baseline knows the invpcid instruction,
> no need to carry the workaround in the code.
>
> Resolves: https://gitlab.com/xen-project/xen/-/work_items/209
> Signed-off-by: Denis Mukhin
Reviewed-by: Andrew Coop
On 30/03/2025 22:11, Julien Grall wrote:
Hi Ayan,
Hi Julien,
On 30/03/2025 19:03, Ayan Kumar Halder wrote:
Signed-off-by: Ayan Kumar Halder
---
Changes from :-
v1, v2 -
1. New patch introduced in v3.
2. Should be applied on top of
https://patchwork.kernel.org/project/xen-devel/cover/20250
On 03/04/2025 7:23 pm, dm...@proton.me wrote:
> From: Denis Mukhin
>
> The new toolchain baseline knows the VMX instructions,
> no need to carry the workaround in the code.
>
> Move asm for vmxoff directly on the only callsite in vmcs.c
Ideally VMXOFF in capitals as it's an instruction name. But
From: Denis Mukhin
The new toolchain baseline knows the rdrand/rdseed instructions,
no need to carry the workaround in the code.
Resolves: https://gitlab.com/xen-project/xen/-/work_items/208
Signed-off-by: Denis Mukhin
---
xen/arch/x86/arch.mk| 2 --
xen/arch/x86/x86_emulate/0fc7.
From: Denis Mukhin
The new toolchain baseline knows the invpcid instruction,
no need to carry the workaround in the code.
Resolves: https://gitlab.com/xen-project/xen/-/work_items/209
Signed-off-by: Denis Mukhin
---
xen/arch/x86/arch.mk | 1 -
xen/arch/x86/include/asm/invpcid.h
From: Denis Mukhin
The new toolchain baseline knows the {rd,wr}{f,g}sbase instructions,
no need to carry the workaround in the code.
Resolves: https://gitlab.com/xen-project/xen/-/work_items/207
Signed-off-by: Denis Mukhin
---
xen/arch/x86/arch.mk | 1 -
xen/arch/x86/include/asm/msr
Add stubs to enable compilation
Signed-off-by: Ayan Kumar Halder
---
Changes from :-
v1, v2 -
1. New patch introduced in v3.
2. Should be applied on top of
https://patchwork.kernel.org/project/xen-devel/cover/20250316192445.2376484-1-luca.fance...@arm.com/
v3 -
1. Add stubs for map_domain_page
MISRA C:2012 Ammendment 3 (which is under consideration, but not used by Xen
yet) is more particular about the order of keywords.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr Babchuk
CC: Bert
MISRA C:2012 Amendment 3 (which is under consideration, but not used by Xen
yet) is more particular about having the storage class specifier first.
No functional change.
Signed-off-by: Andrew Cooper
---
CC: Jan Beulich
CC: Roger Pau Monné
CC: Stefano Stabellini
CC: Julien Grall
CC: Volodymyr
xenstored maps other domains' xenstore pages. Currently this relies on
init-dom0less or xl to seed the grants from Dom0. With split
hardware/control/xenstore domains, this is problematic since we don't
want the hardware domain to be able to map other domains' resources
without their permission.
When creating a hardware domain, have the dom0less code call
construct_hwdom() which is shared with the dom0 code. The hardware
domain requires building that best matches the dom0 build path. Re-use
it to keep them in sync.
The device tree node of the dom0less config is now passed into
construct
This series implements separation of dom0 into separate hardware and
control domains. It uses the capabilities idea from Hyperlaunch -
hardware, control, and xenstore. It's been tested with dom1 as
control, dom2 as a domU, and dom3 as hardware and xenstore.
To keep things more managable, this v
Store the result of finding a "multiboot,device-tree" node. This will
simplity adding hardware domain checks.
Signed-off-by: Jason Andryuk
---
v3:
New
Could be squashed into the next patch, but this helps make the next one
cleaner.
---
xen/arch/arm/dom0less-build.c | 8 +---
1 file changed
Add a capabilities property to dom0less to allow building a
disaggregated system. Only a single hardware domain and single xenstore
domain can be specified. Multiple control domains are possible.
Introduce bootfdt.h to contain these constants.
When using the hardware or xenstore capabilities, a
The following sequence of events may lead a debug build of Xen to crash
when using the null scheduler:
1. domain creation (e.g. d1) failed due to bad configuration
2. complete_domain_destroy() was deferred
3. domain creation (e.g. d2) succeeds
At this point, d2 is running, while the zombie d1 is
On 03/04/2025 7:36 pm, Teddy Astie wrote:
> Yes, while proving it on the hypervisor side may be doable, I am quite
> unsure about PV guests.
> Some calls to HYPERVISOR_mmuext_op incidentally call invlpg and alike
> which could be affected with this change, as the guest can "assume" some
> behavi
We have created the same boot-time MPU protection regions as Armv8-R AArch64.
Also, we have defined *_PRBAR macros for arm32. The only difference from
arm64 is that XN is 1-bit for arm32.
The macros have been defined in mpu/cpregs.h.
Also defined WRITE_SYSREG_ASM() to write to system registers in
Le 03/04/2025 à 16:08, Andrew Cooper a écrit :
> On 03/04/2025 1:58 pm, Jan Beulich wrote:
>> On 03.04.2025 14:44, Teddy Astie wrote:
>>> Signed-off-by: Teddy Astie
>>> ---
>>> RFC:
>>> - is this change actually safe ?
>> Well, before getting here with reading I was already about to ask this v
This allows rebuilding containers using podman too.
Signed-off-by: Marek Marczykowski-Górecki
---
automation/build/Makefile | 4 ++--
automation/tests-artifacts/Makefile | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/automation/build/Makefile b/automation/buil
From: "Daniel P. Smith"
Add and use a new internal create domain flag to specify the hardware
domain. This removes the hardcoding of domid 0 as the hardware domain.
This allows more flexibility with domain creation.
Signed-off-by: Daniel P. Smith
Signed-off-by: Jason Andryuk
Reviewed-by: Jan
On 03/04/2025 10:04 pm, Nicola Vetrini wrote:
> On 2025-04-03 22:43, Andrew Cooper wrote:
>> MISRA C:2012 Ammendment 3 (which is under consideration, but not used
>> by Xen
> ^ typo
>> yet) is more particular about the order of keywords.
>>
>> No functional change.
>>
>> Signed-off-b
The hardware domain is unable to seed a control domain, but we want the
control domain to use xenstore. Rely on the hypervisor to seed dom0less
grant table entries for Xenstore, so this seeding is unnecessary.
However, that only works for the new xenstore late init. The legacy
protocol which use
On 04/04/2025 12:28 am, Andrew Cooper wrote:
> On 04/04/2025 12:22 am, Alexander M. Merritt wrote:
>> The new toolchain baseline knows both the XSAVEOPT and CLWB instructions.
> I know that's what I wrote on the ticket, but what I'd forgotten was
> that we only use XSAVEOPT for it's operand.
>
> Re
On Thu, 3 Apr 2025, Marek Marczykowski-Górecki wrote:
> On Thu, Apr 03, 2025 at 01:32:38PM +0200, Jan Beulich wrote:
> > On 03.04.2025 13:04, Marek Marczykowski-Górecki wrote:
> > > It appears as sometimes it takes more time for Xen even start booting,
> > > mostly due to firmware and fetching larg
On Thu, 3 Apr 2025, Marek Marczykowski-Górecki wrote:
> This build is used for hardware tests, and some runners use XHCI console
>
> Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Stefano Stabellini
> ---
> automation/gitlab-ci/build.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff
On Thu, 3 Apr 2025, Marek Marczykowski-Górecki wrote:
> Signed-off-by: Marek Marczykowski-Górecki
Acked-by: Stefano Stabellini
> ---
> automation/scripts/qubes-x86-64.sh | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/automation/scripts/qubes-x86-64.sh
> b/automation/scripts/qubes
On 04/04/2025 12:22 am, Alexander M. Merritt wrote:
> The new toolchain baseline knows both the XSAVEOPT and CLWB instructions.
I know that's what I wrote on the ticket, but what I'd forgotten was
that we only use XSAVEOPT for it's operand.
Really what we're doing here is knowing CLWB, and also g
On Thu, 3 Apr 2025, Marek Marczykowski-Górecki wrote:
> And start collecting qemu log earlier, so it isn't lost in case of a
> timeout during domain startup.
>
> Signed-off-by: Marek Marczykowski-Górecki
As we are doing this across the board please also do the same for
xilinx-smoke-dom0-x86_64.s
On Thu, 3 Apr 2025, Marek Marczykowski-Górecki wrote:
> The network driver initializes asynchronously, and it may not be ready
> yet by the time the startup script is called. This is especially the
> case for USB network adapter (where the PCI device is the USB
> controller) in the upcoming runner.
On Thu, Apr 03, 2025 at 05:21:56PM -0700, Stefano Stabellini wrote:
> Hi Marek, would you be up for moving your script to use "expect"?
> Something like ./automation/scripts/console.exp?
>
> That way, we would immediately complete the job no matter the timeout
> value. It is also nicer :-)
Oh, th
On Thu, 3 Apr 2025, Marek Marczykowski-Górecki wrote:
> This allows rebuilding containers using podman too.
>
> Signed-off-by: Marek Marczykowski-Górecki
Reviewed-by: Stefano Stabellini
> ---
> automation/build/Makefile | 4 ++--
> automation/tests-artifacts/Makefile | 4 ++--
> 2
On Thu, 2 Apr 2025, Marek Marczykowski-Górecki wrote:
> It fails on larger initramfs (~250MB one) and sometimes even smaller
> depending on memory size/memory map, let Linux do it.
>
> Signed-off-by: Marek Marczykowski-Górecki
I believe this is the default with U-Boot anyway, if I remember right
On one Sapphire AMD x86 board, I see this:
(XEN) [003943ca6ff2] [f000, f7ff] (reserved)
(XEN) [0039460886d9] [fd00, ] (reserved)
[...]
(XEN) [4.612235] :02:00.0: not mapping BAR [fea00, fea03] invalid
position
Linux boots fi
On Thu, 3 Apr 2025, Jason Andryuk wrote:
> Store the result of finding a "multiboot,device-tree" node. This will
> simplity adding hardware domain checks.
>
> Signed-off-by: Jason Andryuk
Reviewed-by: Stefano Stabellini
> ---
> v3:
> New
>
> Could be squashed into the next patch, but this he
On Thu, 3 Apr 2025, Jason Andryuk wrote:
> Add a capabilities property to dom0less to allow building a
> disaggregated system. Only a single hardware domain and single xenstore
> domain can be specified. Multiple control domains are possible.
>
> Introduce bootfdt.h to contain these constants.
>
On Thu, 3 Apr 2025, Jason Andryuk wrote:
> xenstored maps other domains' xenstore pages. Currently this relies on
> init-dom0less or xl to seed the grants from Dom0. With split
> hardware/control/xenstore domains, this is problematic since we don't
> want the hardware domain to be able to map oth
On Thu, 3 Apr 2025, Jason Andryuk wrote:
> To allocate the xenstore event channel and initialize the grant table
> entry, the xenstore domid is neeed. A dom0 is created before the domUs,
> so it is normally available through hardware_domain. With capabilities
> and dom0less, the xenstore domain m
On Thu, 3 Apr 2025, Jason Andryuk wrote:
> The hardware domain is unable to seed a control domain, but we want the
> control domain to use xenstore. Rely on the hypervisor to seed dom0less
> grant table entries for Xenstore, so this seeding is unnecessary.
>
> However, that only works for the new
From: Denis Mukhin
Improve error handling in VMX wrappers by switching to `asm goto()` where
possible.
vmread_safe() kept as is because the minimally required baseline GCC does
not support output operands in `asm goto`.
Resolves: https://gitlab.com/xen-project/xen/-/work_items/210
Signed-off-by
The new toolchain baseline knows both the XSAVEOPT and CLWB instructions.
Resolves: https://gitlab.com/xen-project/xen/-/work_items/205
Signed-off-by: Alexander M. Merritt
---
xen/arch/x86/arch.mk | 2 --
xen/arch/x86/flushtlb.c | 28 +---
xen/arch
On Thu, 3 Apr 2025, Marek Marczykowski-Górecki wrote:
> This is AMD Ryzen 5 7640U in Framework Laptop AMD.
> It has several things different than the other runners.
> First of all, the console is using XHCI debug capability.
> And then, this system doesn't have normal wired ethernet. But is has one
On Thu, 3 Apr 2025, Jason Andryuk wrote:
> From: "Daniel P. Smith"
>
> Add and use a new internal create domain flag to specify the hardware
> domain. This removes the hardcoding of domid 0 as the hardware domain.
>
> This allows more flexibility with domain creation.
>
> Signed-off-by: Daniel
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 branch with a couple of other cleanups in
this area (see the shortlog & diffstat
On 03/04/2025 7:23 pm, dm...@proton.me wrote:
> From: Denis Mukhin
>
> The new toolchain baseline knows the crc32 instructions,
> no need to carry the workaround in the code.
>
> Resolves: https://gitlab.com/xen-project/xen/-/work_items/206
> Signed-off-by: Denis Mukhin
Reviewed-by: Andrew Coope
On 03.04.2025 11:35, Orzel, Michal wrote:
>
>
> On 03/04/2025 11:28, Jan Beulich wrote:
>>
>>
>> On 03.04.2025 11:17, Orzel, Michal wrote:
>>> On 03/04/2025 10:58, Jan Beulich wrote:
On 03.04.2025 10:44, Orzel, Michal wrote:
> On 03/04/2025 10:43, Jan Beulich wrote:
>> On 03.04.2025
On 03.04.2025 13:39, Andrew Cooper wrote:
> On 03/04/2025 12:29 pm, Jan Beulich wrote:
>> On 03.04.2025 13:04, Marek Marczykowski-Górecki wrote:
>>> It fails on larger initramfs (~250MB one) and sometimes even smaller
>>> depending on memory size/memory map, let Linux do it.
>> Iirc grub only unpac
On 03.04.2025 14:02, Andrew Cooper wrote:
> On 01/04/2025 6:56 am, Jan Beulich wrote:
>> Putting a few bytes ahead of page tables isn't very efficient; there's
>> a gap almost worth a full page. To avoid re-ordering of items in the
>> source file, simply put the few small items in sub-section 1, fo
The fixup section is only used by x86, and we're working to remove it there
too. Logic in the fixup section is unconnected to it's origin site, and
interferes with backtraces/etc.
Remove the section from the architectures which don't use it.
Signed-off-by: Andrew Cooper
---
CC: Anthony PERARD
Signed-off-by: Marek Marczykowski-Górecki
---
automation/scripts/qubes-x86-64.sh | 2 ++
1 file changed, 2 insertions(+)
diff --git a/automation/scripts/qubes-x86-64.sh
b/automation/scripts/qubes-x86-64.sh
index 771c77d6618b..d316c17e0c9f 100755
--- a/automation/scripts/qubes-x86-64.sh
+++ b/au
It fails on larger initramfs (~250MB one) and sometimes even smaller
depending on memory size/memory map, let Linux do it.
Signed-off-by: Marek Marczykowski-Górecki
---
automation/scripts/qubes-x86-64.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/automation/scripts/qubes
Some of those patches are collected from my stubdomain test series, others are
made while getting the new runner working. All of the cleanups can be applied
independently, but most if not all are needed for the final patch adding new
runner.
As usual, besides the patches, somebody need to click on
The network driver initializes asynchronously, and it may not be ready
yet by the time the startup script is called. This is especially the
case for USB network adapter (where the PCI device is the USB
controller) in the upcoming runner.
Don't bother about separate timeout - test timeout will cove
AMD Translation Cache Extension is a flag that can be enabled in the EFER MSR
to optimize
some TLB flushes. Enable this flag if supported by hardware.
AMD Architecture Developer Manual describe this feature as follow
> Setting this bit to 1 changes how the INVLPG, INVLPGB, and INVPCID
> instruct
On 03/04/2025 12:25 pm, Jan Beulich wrote:
> It gives the wrong impression of there being a type change, when
> get_s_time() really returns s_time_t itself (kind of naturally given its
> name).
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
On 03.04.2025 13:04, Marek Marczykowski-Górecki wrote:
> It fails on larger initramfs (~250MB one) and sometimes even smaller
> depending on memory size/memory map, let Linux do it.
Iirc grub only unpacks gzip-ed modules, so wouldn't a yet better approach
be to use a better compressing algorithm,
On 03.04.2025 13:04, Marek Marczykowski-Górecki wrote:
> It appears as sometimes it takes more time for Xen even start booting,
> mostly due to firmware and fetching large boot files by grub. In some
> jobs the current timeout is pretty close to the actual time needed, and
> sometimes (rarely for n
On 03/04/2025 12:29 pm, Jan Beulich wrote:
> On 03.04.2025 13:04, Marek Marczykowski-Górecki wrote:
>> It fails on larger initramfs (~250MB one) and sometimes even smaller
>> depending on memory size/memory map, let Linux do it.
> Iirc grub only unpacks gzip-ed modules, so wouldn't a yet better app
On 25.03.25 10:17, Juergen Gross wrote:
On 14.03.25 13:18, Juergen Gross wrote:
In order to close a race window for Xenstore live update when using
the new unique_id of domains, the migration stream needs to contain
this unique_id for each domain known by Xenstore.
Signed-off-by: Juergen Gross
On 03.04.2025 14:44, Teddy Astie wrote:
> AMD Translation Cache Extension is a flag that can be enabled in the EFER MSR
> to optimize
> some TLB flushes. Enable this flag if supported by hardware.
>
> AMD Architecture Developer Manual describe this feature as follow
>> Setting this bit to 1 chang
On Thu, Apr 03, 2025 at 09:30:21AM +0200, Jan Beulich wrote:
> On 01.04.2025 03:17, Volodymyr Babchuk wrote:
> > --- a/xen/Rules.mk
> > +++ b/xen/Rules.mk
> > @@ -138,6 +138,9 @@ ifeq ($(CONFIG_CC_IS_CLANG),y)
> > COV_FLAGS := -fprofile-instr-generate -fcoverage-mapping
> > else
> > COV_
On Thu, Apr 03, 2025 at 01:29:16PM +0200, Jan Beulich wrote:
> On 03.04.2025 13:04, Marek Marczykowski-Górecki wrote:
> > It fails on larger initramfs (~250MB one) and sometimes even smaller
> > depending on memory size/memory map, let Linux do it.
>
> Iirc grub only unpacks gzip-ed modules, so wo
Switch to my container repo for rebuilt kernel
---
automation/gitlab-ci/build.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/automation/gitlab-ci/build.yaml b/automation/gitlab-ci/build.yaml
index d41f27fc94bf..ac7aca141010 100644
--- a/automation/gitlab-ci/build.yaml
+++
This is AMD Ryzen 5 7640U in Framework Laptop AMD.
It has several things different than the other runners.
First of all, the console is using XHCI debug capability.
And then, this system doesn't have normal wired ethernet. But is has one
on USB, and this one is used for booting. For this, enable
CO
And start collecting qemu log earlier, so it isn't lost in case of a
timeout during domain startup.
Signed-off-by: Marek Marczykowski-Górecki
---
automation/scripts/qemu-alpine-x86_64.sh| 2 +-
automation/scripts/qemu-smoke-dom0-arm32.sh | 2 +-
automation/scripts/qemu-smoke-dom0-arm64.sh |
On Thu, Apr 03, 2025 at 01:32:38PM +0200, Jan Beulich wrote:
> On 03.04.2025 13:04, Marek Marczykowski-Górecki wrote:
> > It appears as sometimes it takes more time for Xen even start booting,
> > mostly due to firmware and fetching large boot files by grub. In some
> > jobs the current timeout is
On Thu, Apr 03, 2025 at 12:00:39PM +0200, Jan Beulich wrote:
> On 03.04.2025 11:35, Orzel, Michal wrote:
> > A different question (also to other people who knows this stuff).
> > MPU requires to specify Xen start address using CONFIG_XEN_START_ADDRESS
> > that is
> > set to invalid default value t
On 03.04.2025 15:15, Anthony PERARD wrote:
> On Thu, Apr 03, 2025 at 09:30:21AM +0200, Jan Beulich wrote:
>> On 01.04.2025 03:17, Volodymyr Babchuk wrote:
>>> --- a/xen/Rules.mk
>>> +++ b/xen/Rules.mk
>>> @@ -138,6 +138,9 @@ ifeq ($(CONFIG_CC_IS_CLANG),y)
>>> COV_FLAGS := -fprofile-instr-gener
On 03/04/2025 1:58 pm, Jan Beulich wrote:
> On 03.04.2025 14:44, Teddy Astie wrote:
>> Signed-off-by: Teddy Astie
>> ---
>> RFC:
>> - is this change actually safe ?
> Well, before getting here with reading I was already about to ask this very
> question. It's really you who needs to prove it.
>
>
On Tue, Apr 01, 2025 at 03:47:03PM +0100, Andrew Cooper wrote:
> diff --git a/xen/arch/arm/Makefile b/xen/arch/arm/Makefile
> index 129a109d6ec5..811adf3567c4 100644
> --- a/xen/arch/arm/Makefile
> +++ b/xen/arch/arm/Makefile
> @@ -96,21 +96,19 @@ ifeq ($(CONFIG_ARM_64),y)
> ln -sf $(@F) $@.e
Change how PCI device lookup is done to handle also USB devices, in
which case get the USB controller. Instead of taking basename of the
'device' symlink, resolve the full path (example:
/sys/devices/pci:00/:00:09.0/usb4/4-7/4-7:1.0) and take the
first part after pci:00. Theoretically i
On 02.04.2025 23:44, dm...@proton.me wrote:
> From: Denis Mukhin
>
> Use %pd in all logs issued from arch_domain_create().
>
> Also, expand error message in arch_domain_create() under
> !emulation_flags_ok() case to help debugging.
>
> Signed-off-by: Denis Mukhin
A few nits:
> --- a/xen/arch
87 matches
Mail list logo