When xenwatchdogd is invoked with -h/--help (or any non-number), the
argument value is converted to 0, which immediately shutdowns dom0.
So make sure only numbers are passed to the program, otherwise fail.
For the help, use getopt_long as suggested.
While there, reformat the code a bit
Hi Anthony,
On 3/25/2024 11:35 PM, Anthony PERARD wrote:
On Fri, Mar 08, 2024 at 09:54:35AM +0800, Henry Wang wrote:
diff --git a/tools/helpers/init-dom0less.c b/tools/helpers/init-dom0less.c
index fee93459c4..92c612f6da 100644
--- a/tools/helpers/init-dom0less.c
+++
On Mon, Mar 25, 2024 at 08:55:56AM +0100, Jan Beulich wrote:
> On 22.03.2024 20:22, Elliott Mitchell wrote:
> > On Fri, Mar 22, 2024 at 04:41:45PM +, Kelly Choi wrote:
> >>
> >> I can see you've recently engaged with our community with some issues you'd
> >> like help with.
> >> We love the
Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers. For Linux, this defaults to 0x100 (16MB), but
it can be configured.
Unfortunately there exist firmwares that have reserved regions at this
address, so Xen fails to load the dom0 kernel since it's
Consolidate to a single set of common macros for tools.
MB() will gain another use in libelf, so this movement makes it
available.
Signed-off-by: Jason Andryuk
---
v4:
New
---
tools/firmware/hvmloader/util.h | 3 ---
tools/helpers/init-xenstore-domain.c| 1 -
The XEN_ELFNOTE_L1_MFN_VALID is an array of pairs of values, but it is
printed as:
(XEN) ELF: note: L1_MFN_VALID = 0
This is a limitation of only printing either string or numeric values.
Switch from the boolean to an enum which allows more flexibility in
printing the values. Introduce
The local MB() & GB() macros will be replaced with a common
implementation, but those only work with constant values. Introduce a
static inline mb_to_bytes() in place of the MB() macro to convert the
variable values.
Signed-off-by: Jason Andryuk
---
v4:
New
---
Xen tries to load a PVH dom0 kernel at the fixed guest physical address
from the elf headers. For Linux, this defaults to 0x100 (16MB), but
it can be configured.
Unfortunately there exist firmwares that have reserved regions at this
address, so Xen fails to load the dom0 kernel since it's
A new ELF note will specify the alignment for a relocatable PVH kernel.
ELF notes are suitable for vmlinux and other ELF files, so this
Linux-specific bzImage parsing in unnecessary.
This reverts commit c44cac229067faeec8f49247d1cf281723ac2d40.
Signed-off-by: Jason Andryuk
---
flight 185158 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185158/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185154
On 19/03/2024 17:55, Roger Pau Monné wrote:
> On Tue, Jan 09, 2024 at 03:38:30PM +, Alejandro Vallejo wrote:
>> Move struct xc_cpu_policy data structure out of xg_private.h and into
>> the public xenguest.h so it can be used by libxl.
>
> I will let Andrew comment on this one, IIRC the
AMD have updated the SRSO whitepaper[1] with further information.
There's a new SRSO_U/S_NO enumeration saying that SRSO attacks can't cross the
user/supervisor boundary. i.e. we don't need to use IBPB-on-entry for PV.
There's also a new SRSO_MSR_FIX identifying that the BP_SPEC_REDUCE bit is
Hi,
On 25/03/2024 16:45, Jan Beulich wrote:
> On 09.01.2024 16:38, Alejandro Vallejo wrote:
>> --- a/xen/arch/x86/domain.c
>> +++ b/xen/arch/x86/domain.c
>> @@ -288,7 +288,10 @@ void update_guest_memory_policy(struct vcpu *v,
>> static void cpu_policy_updated(struct vcpu *v)
>> {
>> if (
Hi,
Would it be possible to backport 18a36b4a9b08 ("tools: ipxe: update for
fixing build with GCC12") to Xen 4.17 ?
This would be to allow building Xen 4.17 on Debian Bookworm, and to allow
osstest to test Xen 4.18 with Debian Bookworm. osstest always tries to
migration from N-1 to N, so it
On 20.03.2024 09:52, Roger Pau Monné wrote:
> On Tue, Jan 09, 2024 at 03:38:32PM +, Alejandro Vallejo wrote:
>> As part of topology correction efforts, APIC IDs can no longer be derived
>> strictly through the vCPU ID alone. Bring in the machinery for policy
>> retrieval and parsing in order
On 20/03/2024 09:33, Roger Pau Monné wrote:
>>
>> Why not just return the x2apic_id field from the cpu_policy object?
>> (topo.subleaf[X].x2apic_id)
>
> Scratch that, the cpu policy is per-domain, not per-vcpu, and hence
> cannot hold the x{,2}apic IDs.
Yes, that :)
Originally I tried to make
On 09.01.2024 16:38, Alejandro Vallejo wrote:
> A future patch will use these in hvmloader, which is freestanding, but
> lacks the Xen code. The following changes fix the compilation errors.
>
> * string.h => Remove memset() usages and bzero through assignments
But hvmloader does have memset().
On 09.01.2024 16:38, Alejandro Vallejo wrote:
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -288,7 +288,10 @@ void update_guest_memory_policy(struct vcpu *v,
> static void cpu_policy_updated(struct vcpu *v)
> {
> if ( is_hvm_vcpu(v) )
> +{
>
On 15.03.2024 18:52, Matthew Barnes wrote:
> Last Branch Record and Bus Lock Detect both belong to the same MSR.
>
> The same mechanism that restores LBR also restores BLD.
>
> Therefore, the name of the feature that enables this mechanism should
> reflect restoring the MSR, instead of one
On Sun, Oct 22, 2023 at 04:14:30PM +0200, Marek Marczykowski-Górecki wrote:
> On Mon, Aug 28, 2023 at 11:50:36PM +0200, Marek Marczykowski-Górecki wrote:
> > Hi,
> >
> > I've noticed in Qubes's CI failure like this:
> >
> > [ 871.271292] BUG: kernel NULL pointer dereference, address:
> >
On 15.03.2024 18:52, Matthew Barnes wrote:
> --- a/xen/arch/x86/cpu/common.c
> +++ b/xen/arch/x86/cpu/common.c
> @@ -623,6 +623,11 @@ void identify_cpu(struct cpuinfo_x86 *c)
> }
>
> setup_doitm();
> +
> + if (cpu_has(c, X86_FEATURE_BLD)) {
> + host_msr_debugctl |=
Hi,
I'll answer the policy-related feedback in the next email, as you
corrected yourself for that.
On 19/03/2024 16:20, Roger Pau Monné wrote:
> On Tue, Jan 09, 2024 at 03:38:29PM +, Alejandro Vallejo wrote:
>> This allows the initial x2APIC ID to be sent on the migration stream. The
>>
On 14.03.2024 23:15, Shawn Anastasio wrote:
> --- a/xen/arch/ppc/mm-radix.c
> +++ b/xen/arch/ppc/mm-radix.c
> @@ -21,69 +21,101 @@ void enable_mmu(void);
> #define radix_dprintk(...)
> #endif
>
> -#define INITIAL_LVL1_PD_COUNT 1
> -#define INITIAL_LVL2_LVL3_PD_COUNT 2
> -#define
On Fri, Mar 08, 2024 at 09:54:35AM +0800, Henry Wang wrote:
> diff --git a/tools/helpers/init-dom0less.c b/tools/helpers/init-dom0less.c
> index fee93459c4..92c612f6da 100644
> --- a/tools/helpers/init-dom0less.c
> +++ b/tools/helpers/init-dom0less.c
> @@ -23,16 +23,30 @@ static int
On 14.03.2024 23:15, Shawn Anastasio wrote:
> Now that we have common code building, there's no need to keep the old
> itoa64+debug print function in mm-radix.c
>
> Signed-off-by: Shawn Anastasio
Reviewed-by: Jan Beulich
Just to clarify: Is this dependent upon any of the earlier patches in
On 14.03.2024 23:15, Shawn Anastasio wrote:
> Required for bootfdt.c to build.
>
> Signed-off-by: Shawn Anastasio
As a temporary workaround this may be okay, but was the alternative
considered to properly provide stubs in a single central place for
anything !CONFIG_STATIC_SHM?
Jan
> ---
On 14.03.2024 23:15, Shawn Anastasio wrote:
> Introduce a generic acpi.h header that provides the required definitions
> to allow files including xen/acpi.h to be compiled. The definitions were
> largely derived from the !CONFIG_ACPI parts of ARM's acpi.h.
As said a couple of times in discussion
On Mon, Mar 25, 2024 at 12:09:40PM +0100, Rafaël Kooi wrote:
> Makes sense. To be honest I don't even know what arguments one would pass
> to xenconsoled other than setting the log level to begin with. I would
> assume this to be a niche enough use case where very few users would be
> affected if
On 25.03.2024 15:47, Nicola Vetrini wrote:
> On 2024-03-25 10:38, Jan Beulich wrote:
>> On 22.03.2024 17:01, Nicola Vetrini wrote:
>>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
>>> of macro parameters shall be enclosed in parentheses". Therefore, some
>>> macro
On 2024-03-25 10:38, Jan Beulich wrote:
On 22.03.2024 17:01, Nicola Vetrini wrote:
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that
all
Hi,
On 14/03/2024 13:50, Jan Beulich wrote:
> On 13.03.2024 16:35, Matthew Barnes wrote:
>> libacpi is a tool that is used by libxl (for PVH guests) and hvmloader
>> (for HVM guests) to construct ACPI tables for guests.
>>
>> Currently, libacpi only uses APIC entries to enumerate processors for
flight 185155 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185155/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 185152
test-amd64-amd64-xl-qemuu-win7-amd64
On 2024-03-25 10:25, Jan Beulich wrote:
On 22.03.2024 17:01, Nicola Vetrini wrote:
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that
all
On 25/03/2024 12:21, Jesper Dangaard Brouer wrote:
Hi Arthur,
(Answer inlined below, which is custom on this mailing list)
On 23/03/2024 14.23, Arthur Borsboom wrote:
Hi Jesper,
After a recent kernel upgrade 6.7.6 > 6.8.1 all my Xen guests on Arch
Linux are dumping kernel traces.
It seems to
flight 185157 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185157/
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
Hi Arthur,
(Answer inlined below, which is custom on this mailing list)
On 23/03/2024 14.23, Arthur Borsboom wrote:
Hi Jesper,
After a recent kernel upgrade 6.7.6 > 6.8.1 all my Xen guests on Arch
Linux are dumping kernel traces.
It seems to be indirectly caused by the page pool memory leak
Hi Bertrand,
On 3/21/24 17:15, Bertrand Marquis wrote:
> Hi John,
>
>> On 21 Mar 2024, at 17:05, John Ernberg wrote:
>>
>> Hi Bertrand,
>>
>> On 3/21/24 08:41, Bertrand Marquis wrote:
>>> Hi,
>>>
On 20 Mar 2024, at 18:40, Julien Grall wrote:
Hi John,
On 20/03/2024
Hi Anthony,
On Mon, Mar 25, 2024 at 11:55 AM Anthony PERARD
wrote:
>
> On Fri, Mar 15, 2024 at 11:58:54AM +0100, Carlo Nonato wrote:
> > diff --git a/tools/libs/light/libxl_create.c
> > b/tools/libs/light/libxl_create.c
> > index 5546335973..79f206f616 100644
> > ---
Hi Jan,
On 25/03/2024 11:16, Jan Beulich wrote:
On 22.03.2024 00:17, Julien Grall wrote:
Hi Stefano,
I haven't fully read the thread. But I wanted to clarify something.
On 21/03/2024 19:03, Stefano Stabellini wrote:
Or possibly unsigned long depending on the parameter.
You're
On 22.03.2024 00:17, Julien Grall wrote:
> Hi Stefano,
>
> I haven't fully read the thread. But I wanted to clarify something.
>
> On 21/03/2024 19:03, Stefano Stabellini wrote:
Or possibly unsigned long depending on the parameter.
>>>
>>> You're contradicting yourself: You mean to advocate
On 25/03/2024 11:32, Anthony PERARD wrote:
On Wed, Mar 20, 2024 at 08:48:33AM +0100, Rafaël Kooi wrote:
The systemd xenconsoled.service uses the XENCONSOLED_ARGS variable, but
it was missing from the xencommons file.
Actually, I'm tempted to go the other way and remove XENCONSOLED_ARGS
from
On Fri, Mar 15, 2024 at 11:58:54AM +0100, Carlo Nonato wrote:
> diff --git a/tools/libs/light/libxl_create.c b/tools/libs/light/libxl_create.c
> index 5546335973..79f206f616 100644
> --- a/tools/libs/light/libxl_create.c
> +++ b/tools/libs/light/libxl_create.c
> @@ -726,6 +726,15 @@ int
On Wed, Mar 20, 2024 at 08:48:33AM +0100, Rafaël Kooi wrote:
> The systemd xenconsoled.service uses the XENCONSOLED_ARGS variable, but
> it was missing from the xencommons file.
Actually, I'm tempted to go the other way and remove XENCONSOLED_ARGS
from the systemd's service file. In the other
On 16.01.2024 20:25, Elias El Yandouzi wrote:
> Elias El Yandouzi (3):
> xen/x86: Add build assertion for fixmap entries
> Rename mfn_to_virt() calls
> Rename maddr_to_virt() calls
>
> Hongyan Xia (13):
> acpi: vmap pages in acpi_os_alloc_memory
> xen/numa: vmap the pages for memnodemap
On 20.03.2024 14:57, Roger Pau Monne wrote:
> There's no reason to force HVM guests to have a valid vcpu_info area when
> initializing a vCPU, as the vCPU can also be brought online using the local
> APIC, and on that path there's no requirement for vcpu_info to be setup ahead
> of the bring up.
flight 185156 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185156/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf cf58f47623c40a66b160face4f04e08efb4c7f5b
baseline version:
ovmf
Move memory sharing routines into a separate file for easier navigation
in the source code.
Add ffa_shm_domain_destroy() to isolate the ffa_shm things in
ffa_domain_teardown_continue().
Signed-off-by: Jens Wiklander
---
xen/arch/arm/tee/Makefile | 1 +
xen/arch/arm/tee/ffa.c |
Prepare to separate into modules by renaming functions that will need
new names when becoming non-static in the following commit.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/tee/ffa.c | 125 +
1 file changed, 65 insertions(+), 60 deletions(-)
diff
Move partition info get routines into a separate file for easier
navigation in the source code.
Add ffa_partinfo_init(), ffa_partinfo_domain_init(), and
ffa_partinfo_domain_destroy() to handle the ffa_partinfo internal things
on initialization and teardown.
Signed-off-by: Jens Wiklander
---
Add support for the mandatory FF-A ABI function FFA_FEATURES.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/tee/ffa.c | 57 ++
1 file changed, 57 insertions(+)
diff --git a/xen/arch/arm/tee/ffa.c b/xen/arch/arm/tee/ffa.c
index 4f7775b8c890..8665201e34a9
Move rxtx buffer routines into a spearate file for easier navigation in
the source code.
Add ffa_rxtx_init(), ffa_rxtx_destroy(), and ffa_rxtx_domain_destroy() to
handle the ffa_rxtx internal things on initialization and teardown.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/tee/Makefile
Hi,
The FF-A mediator is reorganized into modules for easier maintenance and to
prepare for future changes. This patch set is not expected add any changed
behaviour, except for the "xen/arm: ffa: support FFA_FEATURES" patch.
Thanks,
Jens
Jens Wiklander (6):
xen/arm: ffa: rename functions to
Prepare to separate ffa.c into modules by moving common things into the
new internal header file ffa_private.h.
Signed-off-by: Jens Wiklander
---
xen/arch/arm/tee/ffa.c | 298 +-
xen/arch/arm/tee/ffa_private.h | 318 +
2 files
On 22.03.2024 17:01, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be
On 22.03.2024 17:01, Nicola Vetrini wrote:
> --- a/xen/common/page_alloc.c
> +++ b/xen/common/page_alloc.c
> @@ -150,7 +150,7 @@
> #include
> #else
> #define p2m_pod_offline_or_broken_hit(pg) 0
Seeing this in context: Does Misra also have a rule demanding evaluation
of macro arguments?
>
On 22.03.2024 17:01, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be
On 22.03.2024 17:01, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be
On 22.03.2024 17:01, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be
On 22.03.2024 17:01, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be
flight 185154 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185154/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 185143
test-armhf-armhf-libvirt 16
Hi Luca,
On 12/03/2024 14:03, Luca Fancellu wrote:
>
>
> Currently Xen is not exporting the static shared memory regions
> to the device tree as /memory node, this commit is fixing this
> issue.
Looking at the implementation, you will always call make_shm_memory_node()
twice. For the first
On 22.03.2024 13:25, Oleksii wrote:
> On Thu, 2024-03-21 at 14:03 +0100, Jan Beulich wrote:
>> On 15.03.2024 19:06, Oleksii Kurochko wrote:
>>> + */
>>> +static always_inline void read_atomic_size(const volatile void *p,
>>> + void *res,
>>> +
Hi Luca,
On 12/03/2024 14:03, Luca Fancellu wrote:
>
>
> From: Penny Zheng
>
> In case there is a /reserved-memory node already present in the host dtb,
> current Xen codes would create yet another /reserved-memory node when
> the static shared memory feature is enabled and static shared
On 2024-03-25 09:00, Jan Beulich wrote:
On 22.03.2024 17:01, Nicola Vetrini wrote:
Hi all,
this series aims to refactor some macros that cause violations of
MISRA C Rule
20.7 ("Expressions resulting from the expansion of macro parameters
shall be
enclosed in parentheses"). All the macros
On 22.03.2024 17:01, Nicola Vetrini wrote:
> Hi all,
>
> this series aims to refactor some macros that cause violations of MISRA C Rule
> 20.7 ("Expressions resulting from the expansion of macro parameters shall be
> enclosed in parentheses"). All the macros touched by these patches are in some
>
On 22.03.2024 20:22, Elliott Mitchell wrote:
> On Fri, Mar 22, 2024 at 04:41:45PM +, Kelly Choi wrote:
>>
>> I can see you've recently engaged with our community with some issues you'd
>> like help with.
>> We love the fact you are participating in our project, however, our
>> developers
On 22.03.2024 15:24, Jason Andryuk wrote:
> On 2024-03-21 09:45, Jason Andryuk wrote:
>> On 2024-03-20 10:39, Jan Beulich wrote:
>>> On 19.03.2024 21:58, Jason Andryuk wrote:
>
@@ -536,6 +565,10 @@ elf_errorstatus elf_xen_parse(struct elf_binary
*elf,
parms->p2m_base =
On 22.03.2024 16:07, Carlo Nonato wrote:
> Hi guys,
>
> On Thu, Mar 21, 2024 at 5:23 PM Jan Beulich wrote:
>>
>> On 21.03.2024 17:10, Julien Grall wrote:
>>> On 21/03/2024 16:07, Julien Grall wrote:
On 15/03/2024 10:58, Carlo Nonato wrote:
> PGC_static and PGC_extra needs to be
68 matches
Mail list logo
