On 02.08.2023 00:54, Shawn Anastasio wrote:
> On 8/1/23 6:19 AM, Jan Beulich wrote:
>> On 28.07.2023 23:35, Shawn Anastasio wrote:
>>> +static void opal_putchar(char c)
>>
>> Can't this be __init?
>
> Unlike OpenFirmware, OPAL calls are expected to be used by the OS during
> its entire lifecycle,
On 02.08.2023 02:11, Shawn Anastasio wrote:
> --- a/xen/arch/ppc/include/asm/asm-defns.h
> +++ b/xen/arch/ppc/include/asm/asm-defns.h
> @@ -16,6 +16,13 @@
> lis reg, (val) @h;
> \
> ori reg, reg, (val) @l;
On 01.08.2023 23:02, Julien Grall wrote:
> Hi,
>
> Title: This patch is not arm32 specific anymore. So I would replace
> 'arm32' with 'arm'. This can be done on commit.
>
> On 01/08/2023 18:49, Khem Raj wrote:
>> Assembler from binutils 2.41 rejects [1] this syntax
>>
>> .section "name"[, flags.
Add missing parameter names to address violations of MISRA C:2012
Rule 8.2 ("Function types shall be in prototype form with named
parameters").
No functional changes.
Signed-off-by: Federico Serafini
---
xen/include/xen/string.h | 42
1 file changed, 21
On 01.08.2023 18:14, Daniel P. Smith wrote:
> This refactors reusable code from Arm's bootfdt.c and device-tree.h that is
> general fdt handling code. The Kconfig parameter CORE_DEVICE_TREE is
> introduced for when the ability of parsing DTB files is needed by a capability
> such as hyperlaunch.
>
Il 02/08/2023 02:08 Stefano Stabellini ha scritto:
On Wed, 2 Aug 2023, Marek Marczykowski-Górecki wrote:
On Tue, Aug 01, 2023 at 03:55:20PM -0700, Stefano Stabellini wrote:
> On Tue, 1 Aug 2023, Simone Ballarin wrote:
> > This patch introduces six new ECLAIR jobs that run only
> > when triggered
On 02.08.2023 02:24, Stefano Stabellini wrote:
> On Tue, 1 Aug 2023, Daniel P. Smith wrote:
>> --- a/xen/include/xen/sched.h
>> +++ b/xen/include/xen/sched.h
>> @@ -1058,6 +1058,13 @@ void scheduler_disable(void);
>> void watchdog_domain_init(struct domain *d);
>> void watchdog_domain_destroy(str
Il 02/08/2023 00:54 Stefano Stabellini ha scritto:
On Tue, 1 Aug 2023, Simone Ballarin wrote:
The ECLAIR jobs fail when triggered by tag pipelines (e.g.
xen-project/patchew/xen).
This patch extends the integration to support such pipelines.
Signed-off-by: Simone Ballarin
Acked-by: Stefano S
On 01.08.2023 22:20, Daniel P. Smith wrote:
> A legacy concept is that the initial domain will have a domain id of zero. As
> a
> result there are places where a check that a domain is the inital domain is
> determined by an explicit check that the domid is zero.
It might help if you at least out
On 01.08.2023 22:20, Daniel P. Smith wrote:
> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -340,6 +340,14 @@ static int late_hwdom_init(struct domain *d)
> setup_io_bitmap(dom0);
> #endif
>
> +/*
> + * "dom0" may have been created under the unbounded role, demote it fr
Hi Jan,
On 02/08/2023 08:22, Jan Beulich wrote:
On 01.08.2023 23:02, Julien Grall wrote:
Hi,
Title: This patch is not arm32 specific anymore. So I would replace
'arm32' with 'arm'. This can be done on commit.
On 01/08/2023 18:49, Khem Raj wrote:
Assembler from binutils 2.41 rejects [1] this
On 02.08.2023 09:54, Julien Grall wrote:
> On 02/08/2023 08:22, Jan Beulich wrote:
>> On 01.08.2023 23:02, Julien Grall wrote:
>>> Title: This patch is not arm32 specific anymore. So I would replace
>>> 'arm32' with 'arm'. This can be done on commit.
>>>
>>> On 01/08/2023 18:49, Khem Raj wrote:
>>>
flight 182108 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182108/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d11968fcc56cbbffef7d906048b00faea9415447
baseline version:
ovmf 677f2c6f1509da21258e0
The empty feature set 'str_7c1' in 'tools/misc/xen-cpuid.c' causes the
struct declaration to have no named members, hence violating
Rule 1.3:
"There shall be no occurrence of undefined or critical unspecified behaviour"
because it is forbidden by ISO/IEC 9899:1999(E), Section 6.7.2.1.7:
"If the str
Structures or unions without any named members aren't liked by Misra
(nor the C standard). Avoid emitting such for leaves without any known
bits.
At this occasion also add the script to the X86 section in ./MAINTAINERS.
Signed-off-by: Jan Beulich
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -601,6 +6
Some variables are renamed or deleted in this series to avoid shadowing, which
violates MISRA C:2012 Rule 5.3, whose headline is:
"An identifier declared in an inner scope shall not hide an
identifier declared in an outer scope".
Nicola Vetrini (4):
x86/mce: address MISRA C:2012 Rule 5.3
x86/m
Rename variables to avoid shadowing and thus address
MISRA C:2012 Rule 5.3:
"An identifier declared in an inner scope shall not hide an
identifier declared in an outer scope"
No functional changes.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/hvm/mtrr.c | 32
The extern variable 'irq_desc' defined in 'irq.h' is shadowed by
local variables in the changed file. To avoid this, the variable is
renamed to 'irq_description'.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/hvm/hvm.c | 2 +-
xen/arch/x86/include/asm/irq.h | 2
Suitable mechanical renames are made to avoid shadowing, thus
addressing violations of MISRA C:2012 Rule 5.3:
"An identifier declared in an inner scope shall not hide an
identifier declared in an outer scope"
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/cpu/mcheck/barrier.c | 8
xen/a
The parameters renamed in the function declaration caused shadowing
with the homonymous variable in 'xen/common/efi/boot.c'. Renaming
them also addresses Rule 8.3:
"All declarations of an object or function shall use the same names
and type qualifiers".
The local variable 'mask' is removed because
On 02.08.2023 10:57, Nicola Vetrini wrote:
> The empty feature set 'str_7c1' in 'tools/misc/xen-cpuid.c' causes the
> struct declaration to have no named members, hence violating
> Rule 1.3:
> "There shall be no occurrence of undefined or critical unspecified behaviour"
> because it is forbidden by
On 02/08/2023 11:47, Jan Beulich wrote:
On 02.08.2023 10:57, Nicola Vetrini wrote:
The empty feature set 'str_7c1' in 'tools/misc/xen-cpuid.c' causes the
struct declaration to have no named members, hence violating
Rule 1.3:
"There shall be no occurrence of undefined or critical unspecified
beh
flight 182096 qemu-mainline real [real]
flight 182113 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/182096/
http://logs.test-lab.xenproject.org/osstest/logs/182113/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 02/08/2023 10:43 am, Jan Beulich wrote:
> Structures or unions without any named members aren't liked by Misra
> (nor the C standard). Avoid emitting such for leaves without any known
> bits.
>
> At this occasion also add the script to the X86 section in ./MAINTAINERS.
>
> Signed-off-by: Jan Beu
On 01.08.2023 18:06, Daniel P. Smith wrote:
> This patch reworks the console rotation logic to provide a general mechanism
> to
> incorporate domU in to the rotation. It does so by walking the domain list
> using the XSM console privlege check to determine if the domain is given
> access.
>
> In
On 02.08.2023 12:01, Nicola Vetrini wrote:
> On 02/08/2023 11:47, Jan Beulich wrote:
>> On 02.08.2023 10:57, Nicola Vetrini wrote:
>>> The empty feature set 'str_7c1' in 'tools/misc/xen-cpuid.c' causes the
>>> struct declaration to have no named members, hence violating
>>> Rule 1.3:
>>> "There sha
flight 182111 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182111/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 5cadb8ce2148979b6c464f6da5a8cd97425c5165
baseline version:
ovmf d11968fcc56cbbffef7d9
flight 182112 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182112/
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
Add the script to the X86 section in ./MAINTAINERS.
Structures or unions without any named members aren't liked by Misra
(nor the C standard). Avoid emitting such for leaves without any known
bits.
The placeholders are affected similarly, but are only visible to MISRA in the
middle of a patch ser
On 02.08.2023 15:10, Andrew Cooper wrote:
> Add the script to the X86 section in ./MAINTAINERS.
>
> Structures or unions without any named members aren't liked by Misra
> (nor the C standard). Avoid emitting such for leaves without any known
> bits.
>
> The placeholders are affected similarly, bu
On 01.08.23 16:54, Yue Haibing wrote:
Commit 67473b8194bc ("xen/events: Remove disfunct affinity spreading")
leave this unused declaration.
Signed-off-by: Yue Haibing
Reviewed-by: Juergen Gross
Juergen
OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key
OpenPGP_signature
De
On 02/08/2023 2:22 pm, Jan Beulich wrote:
> On 02.08.2023 15:10, Andrew Cooper wrote:
>> Add the script to the X86 section in ./MAINTAINERS.
>>
>> Structures or unions without any named members aren't liked by Misra
>> (nor the C standard). Avoid emitting such for leaves without any known
>> bits.
Hi Yue,
> On 1 Aug 2023, at 3:54 pm, Yue Haibing wrote:
>
> Commit 67473b8194bc ("xen/events: Remove disfunct affinity spreading")
> leave this unused declaration.
>
> Signed-off-by: Yue Haibing
Reviewed-by: Rahul Singh
Regards,
Rahul Singh
> ---
> include/xen/events.h | 1 -
> 1 file chang
Introduce Kconfig GICV2 to be able to compile the GICv2 driver only
when needed, the option is active by default.
Introduce Kconfig VGICV2 that depends on GICV2 or GICV3 and compiles
the GICv2 emulation for guests, it is required only when using GICV2
driver, otherwise using GICV3 it is optional a
Hi Luca,
On 02/08/2023 15:53, Luca Fancellu wrote:
>
>
> Introduce Kconfig GICV2 to be able to compile the GICv2 driver only
> when needed, the option is active by default.
>
> Introduce Kconfig VGICV2 that depends on GICV2 or GICV3 and compiles
> the GICv2 emulation for guests, it is required
The variable declaration is moved where it's actually used, rather
than being declared in the switch before any clause, thus being
classified as unreachable code.
No functional changes.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/efi/efi-boot.h | 5 ++---
1 file changed, 2 insertions(+), 3 d
Variable declarations between a switch statement guard and before
any case label are unreachable code, and hence violate Rule 2.1:
"A project shall not contain unreachable code".
Therefore the variable declarations are moved in the smallest enclosing
scope, near other variable definitions.
Signed
Variable declarations between a switch statement guard and before
any case label are unreachable code, and hence violate Rule 2.1:
"A project shall not contain unreachable code".
Therefore the declarations are moved in the smallest enclosing
scope, near other variable definitions.
Signed-off-by:
The headline for Rule 2.1 states:
"A project shall not contain unreachable code". Violations of this rule
addressed
by this patch are caused by two constructs:
1. Declarations inside switch statements, before any clause. This construct is
allowed by the language, but is considered unreachable
The variable declarations inside macros {put,get}_unsafe_size are
considered unreachable code, as they appear in a switch statement, before
any clause. They are moved in the enclosing scope to resolve the violation.
No functional changes.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/include/a
Rule 2.1 states: "A project shall not contain unreachable code".
The functions
- machine_halt
- maybe_reboot
- machine_restart
are not supposed to return, hence the following break statement
is marked as intentionally unreachable with the ASSERT_UNREACHABLE()
macro to justify the violation of the
Declarations between a switch statement guard and before
any case label are unreachable code, and hence violate Rule 2.1:
"A project shall not contain unreachable code".
Therefore the variable declarations are moved in the smallest enclosing
scope, near other variable definitions.
Signed-off-by:
Variable declarations between a switch statement guard and before
any case label are unreachable code, and hence violate Rule 2.1:
"A project shall not contain unreachable code".
Therefore the variable declarations are moved in the smallest enclosing
scope, near other variable definitions.
Signed
Variable declarations between a switch statement guard and before
any case label are unreachable code, and hence violate Rule 2.1:
"A project shall not contain unreachable code".
Therefore the variable declarations are moved in the only clause
scope that uses it.
Signed-off-by: Nicola Vetrini
--
Variable declarations between a switch statement guard and before
any case label are unreachable code, and hence violate Rule 2.1:
"A project shall not contain unreachable code".
Therefore the variable declarations are moved in the smallest enclosing
scope, near other variable definitions.
Signed
The ASSERT_UNREACHABLE() assertion is added before a definitely
unreachable return statement to address MISRA C:2012 Rule 2.1,
because the explicit return from a non-void function is a defensive
coding measure, and thus intended to be unreachable.
No functional changes.
Signed-off-by: Nicola Vetr
The break statement after the return statement is definitely unreachable.
As such, an call to the ASSERT_UNREACHABLE() macro is added to signal
the intentionality of such construct.
Signed-off-by: Nicola Vetrini
---
The break in the clause is mandated by Required Rule 16.3, which is
not yet an ac
flight 182110 xen-4.17-testing real [real]
flight 182117 xen-4.17-testing real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/182110/
http://logs.test-lab.xenproject.org/osstest/logs/182117/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could
> On 2 Aug 2023, at 15:26, Michal Orzel wrote:
>
> Hi Luca,
>
> On 02/08/2023 15:53, Luca Fancellu wrote:
>>
>>
>> Introduce Kconfig GICV2 to be able to compile the GICv2 driver only
>> when needed, the option is active by default.
>>
>> Introduce Kconfig VGICV2 that depends on GICV2 or GIC
On 02/08/2023 3:38 pm, Nicola Vetrini wrote:
> diff --git a/xen/arch/x86/domain.c b/xen/arch/x86/domain.c
> index 5f66c2ae33..015f7b14ab 100644
> --- a/xen/arch/x86/domain.c
> +++ b/xen/arch/x86/domain.c
> @@ -2268,6 +2268,17 @@ int domain_relinquish_resources(struct domain *d)
> {
> int ret;
Hi,
On 02/08/2023 16:42, Luca Fancellu wrote:
>
>
>> On 2 Aug 2023, at 15:26, Michal Orzel wrote:
>>
>> Hi Luca,
>>
>> On 02/08/2023 15:53, Luca Fancellu wrote:
>>>
>>>
>>> Introduce Kconfig GICV2 to be able to compile the GICv2 driver only
>>> when needed, the option is active by default.
>>>
On 31/07/2023 9:25 am, Jan Beulich wrote:
> On 28.07.2023 21:43, Andrew Cooper wrote:
>> This is used in an assertion only, which is somewhat dubious to begin with
>> and
>> won't surivive the x86-S work (where TR will become be a NUL selector).
> I'm kind of okay with the removal, but I can't rea
> On 2 Aug 2023, at 15:48, Michal Orzel wrote:
>
> Hi,
>
> On 02/08/2023 16:42, Luca Fancellu wrote:
>>
>>
>>> On 2 Aug 2023, at 15:26, Michal Orzel wrote:
>>>
>>> Hi Luca,
>>>
>>> On 02/08/2023 15:53, Luca Fancellu wrote:
Introduce Kconfig GICV2 to be able to compile the
From: Julien Grall
expand_xsave_states() is not meant to modify the vCPU. So the parameter
can be const.
Signed-off-by: Julien Grall
---
xen/arch/x86/include/asm/xstate.h | 2 +-
xen/arch/x86/xstate.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x
Hello all,
I report here following a discussion on #xen-devel about Debian bug
1042842 (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042842).
When using more than 10 vifs in a domU on Xen 4.14 (deb11), the
attributions are like :
vifX.0 <> eth0
vifX.1 <> eth1
vifX.2 <> eth2
[...]
vifX
From: Petr Tesarik
After removing the conditional return from xen_create_contiguous_region(),
the accompanying comment was left in place, but it now precedes an
unrelated conditional and confuses readers.
Fixes: 989513a735f5 ("xen: cleanup pvh leftovers from pv-only sources")
Signed-off-by: Petr
Hi Luca,
On 02/08/2023 16:05, Luca Fancellu wrote:
On 2 Aug 2023, at 15:48, Michal Orzel wrote:
Hi,
On 02/08/2023 16:42, Luca Fancellu wrote:
On 2 Aug 2023, at 15:26, Michal Orzel wrote:
Hi Luca,
On 02/08/2023 15:53, Luca Fancellu wrote:
Introduce Kconfig GICV2 to be able to compile
> On 2 Aug 2023, at 18:39, Julien Grall wrote:
>
> Hi Luca,
>
> On 02/08/2023 16:05, Luca Fancellu wrote:
>>> On 2 Aug 2023, at 15:48, Michal Orzel wrote:
>>>
>>> Hi,
>>>
>>> On 02/08/2023 16:42, Luca Fancellu wrote:
> On 2 Aug 2023, at 15:26, Michal Orzel wrote:
>
>>>
flight 182097 xen-unstable real [real]
flight 182122 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/182097/
http://logs.test-lab.xenproject.org/osstest/logs/182122/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
Hi,
On 02/08/2023 18:54, Luca Fancellu wrote:
On 2 Aug 2023, at 18:39, Julien Grall wrote:
Hi Luca,
On 02/08/2023 16:05, Luca Fancellu wrote:
On 2 Aug 2023, at 15:48, Michal Orzel wrote:
Hi,
On 02/08/2023 16:42, Luca Fancellu wrote:
On 2 Aug 2023, at 15:26, Michal Orzel wrote:
Hi
> On 2 Aug 2023, at 19:39, Julien Grall wrote:
>
> Hi,
>
> On 02/08/2023 18:54, Luca Fancellu wrote:
>>> On 2 Aug 2023, at 18:39, Julien Grall wrote:
>>>
>>> Hi Luca,
>>>
>>> On 02/08/2023 16:05, Luca Fancellu wrote:
> On 2 Aug 2023, at 15:48, Michal Orzel wrote:
>
> Hi,
>
On 8/2/23 12:31 PM, Petr Tesarik wrote:
From: Petr Tesarik
After removing the conditional return from xen_create_contiguous_region(),
the accompanying comment was left in place, but it now precedes an
unrelated conditional and confuses readers.
Fixes: 989513a735f5 ("xen: cleanup pvh leftove
flight 182099 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182099/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 182068
test-armhf-armhf-libvirt-qcow2 15 saveres
Hi Luca,
On 02/08/2023 19:48, Luca Fancellu wrote:
diff --git a/xen/arch/arm/Kconfig b/xen/arch/arm/Kconfig
index 5cdba07df964..93309cd49144 100644
--- a/xen/arch/arm/Kconfig
+++ b/xen/arch/arm/Kconfig
@@ -18,6 +18,7 @@ config ARM
select HAS_PMAP
select HAS_UBSAN
selec
flight 182124 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182124/
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
flight 182121 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182121/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf fa789cc68a85a5781c18c64b9112c779750b2125
baseline version:
ovmf 5cadb8ce2148979b6c464
On 8/2/23 02:13, Henry Wang wrote:
Hi Daniel,
Hey Henry!
-Original Message-
Subject: [PATCH 2/2] fdt: make fdt handling reusable across arch
This refactors reusable code from Arm's bootfdt.c and device-tree.h that is
general fdt handling code. The Kconfig parameter CORE_DEVICE_TREE
On 8/2/23 03:27, Jan Beulich wrote:
On 01.08.2023 18:14, Daniel P. Smith wrote:
This refactors reusable code from Arm's bootfdt.c and device-tree.h that is
general fdt handling code. The Kconfig parameter CORE_DEVICE_TREE is
introduced for when the ability of parsing DTB files is needed by a ca
Hi Jan,
On 02/08/2023 09:01, Jan Beulich wrote:
On 02.08.2023 09:54, Julien Grall wrote:
On 02/08/2023 08:22, Jan Beulich wrote:
On 01.08.2023 23:02, Julien Grall wrote:
Title: This patch is not arm32 specific anymore. So I would replace
'arm32' with 'arm'. This can be done on commit.
On 01/
Is there a freeze on that I'm unaware of? Is there so much traffic from
other developers that smaller output ones are being missed? I'm
wondering about the initial revision of this series not getting any
feedback:
https://lists.xenproject.org/archives/html/xen-devel/2023-07/msg01264.html
Due to
Some arguments included a name, but not all did. Now use "cfg" for
all uses of XLU_Config * and "list" for uses of XLU_ConfigList *.
Also fix some spaces missing from xlu_cfg_get_defbool()'s prototype.
Rename the "b" argument of xlu_cfg_get_defbool() to "value_r". Similar
to other functions thi
This was added at b104c3762dc. Appears this was fixed in the intervening
decade. Otherwise this could have been an issue from using advanced
features of Bison. Now this appears unnecessary.
Signed-off-by: Elliott Mitchell
---
tools/libs/util/libxlu_cfg_i.h | 6 --
1 file changed, 6 deleti
Warnings from Bison seem less likely to be urgent, but on general
principle enable everything.
Signed-off-by: Elliott Mitchell
---
tools/libs/util/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/libs/util/Makefile b/tools/libs/util/Makefile
index c3b21875dc..d2
The upper layer disk string parser doesn't need the internals of the
lower layer file parser. Split the layers apart. This looks to have
been a copy&paste issue.
Fixes: 5c206536ad ("libxl: disks: new xlu_disk_parse function")
Signed-off-by: Elliott Mitchell
---
tools/libs/util/libxlu_disk.c |
Bison has added the ability to emit declarations in its header. As such
everything can instead be dumped in Bison's header instead of having a
private one.
This resolves the mixed up situation with the libxlu headers. Problem is
libxlu_cfg_i.h was trying to function as a wrapper for libxlu_cfg_y
The CfgParseContext structure/typedef is used inside the parser. Whereas
most #include's of libxlu_internal.h need the common declarations, not
the parser internals. Due to this, the structure should be near the top
of libxlu_cfg_y.h (libxlu_cfg_i.h @b104c3762d), and not towards the
middle of lib
XLU_ConfigSetting is only used inside libxl_cfg.c, so no need for it in
the internal header. Keep the type definition in libxlu_internal.h as
the incomplete definition is needed for xlu__cfg_set_free().
There is no longer any need for XLU_ConfigSetting to be transparent.
Fixes: b104c3762d, 1a09c
Update per Bison's obsolete warnings. Testing indicates these are simple
and safe.
Signed-off-by: Elliott Mitchell
---
Someone check for acceptable Bison versions?
I'm testing with Flex 2.6.4 and Bison 3.7.5.
---
tools/libs/util/libxlu_cfg_y.y | 11 +--
1 file changed, 5 insertions(+),
At no point was the complete type for XLU_ConfigValue used anywhere
besides libxlu_cfg.c, overdue for a move.
Fixes: 1a09c5113a ("libxlu: rework internal representation of setting")
Signed-off-by: Elliott Mitchell
---
tools/libs/util/libxlu_cfg.c | 9 +
tools/libs/util/libxlu_intern
The definition was needed due to XLU_ConfigValue being before Bison's
declaration of YYLTYPE. Since XLU_ConfigValue has moved to libxlu_cfg.c,
the duplication is now unnecessary.
Fixes: 1a09c5113a, 6ec86e91c8 ("libxlu: record location when parsing values")
Signed-off-by: Elliott Mitchell
---
Had
Hopefully make it clearer to others this is the key associated with the
storage value to retrieve.
Signed-off-by: Elliott Mitchell
---
tools/include/libxlutil.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/tools/include/libxlutil.h b/tools/include/libxlutil.
bison -Wall declares %name-prefix deprecated. The suggested replacement
is "api.prefix". "api.prefix" though effects rather a lot more places
than %name-prefix does. As a result, rename YYLTYPE/YYSTYPE to match.
As a quick workaround #define YYLTYPE/YYSTYPE to convince flex to
interface correct
Only the lowest layer of configuration handling looks inside XLU_Config.
As such the structure can move to this header instead of the shared
header.
Mark ->config_source as constant. Most places it truly is constant, only
the free() violates the constant.
Signed-off-by: Elliott Mitchell
---
Thi
This better breaks layers apart. xlu_cfg_destroy() now only knows about
the XLU_Config structure, while xlu__cfg_set_free() knows about
XLU_ConfigSetting.
Move declaration of xlu__cfg_set_free() to shared header to indicate it
will bridge layers.
Signed-off-by: Elliott Mitchell
---
This is the
There are far more printf()s inside libxlu_cfg.c, so these had been left
alone briefly. Now attack all of these.
Signed-off-by: Elliott Mitchell
---
Note, several messages change mildly. The message in parse() didn't
previously include the filename.
---
tools/libs/util/libxlu_cfg.c | 78 ++
Hi,
On 01/08/2023 22:49, Khem Raj wrote:
On Tue, Aug 1, 2023 at 2:03 PM Julien Grall wrote:
Hi,
Title: This patch is not arm32 specific anymore. So I would replace
'arm32' with 'arm'. This can be done on commit.
On 01/08/2023 18:49, Khem Raj wrote:
Assembler from binutils 2.41 rejects [1]
Potentially allowing a different parser to be substituted.
Omit libxlu_internal.h from libxlu_cfg_i.c, since it is kept in
libxlu_cfg_y.h.
Signed-off-by: Elliott Mitchell
---
tools/libs/util/Makefile | 1 +
tools/libs/util/libxlu_cfg.c | 662 -
Isolate the lower layer configuration handling from the upper layer. Now
only the lowest layer of configuration handling looks inside XLU_Config.
Also make error messages a bit more consistent. Now PCI device parsing
will report filename.
Replace the XLU__PCI_ERR() with xlu_cfg_printf(). The n
The better to isolate the shared portion of the interface from the
low-level implementation.
Signed-off-by: Elliott Mitchell
---
tools/libs/util/libxlu_cfg.c | 7 ++-
tools/libs/util/libxlu_internal.h | 2 ++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/tools/libs/util/
Rather than needing the full structure, for many operations the settings
pointer is enough.
Signed-off-by: Elliott Mitchell
---
tools/libs/util/libxlu_cfg.c | 13 -
tools/libs/util/libxlu_cfg_y.y | 1 +
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/tools/libs/util
With XLU_ConfigValue now in libxlu_cfg.c, XLU_ConfigList can follow.
Fixes: 1a09c5113a ("libxlu: rework internal representation of setting")
Signed-off-by: Elliott Mitchell
---
Placing XLU_ConfigValue/XLU_ConfigList in libxlu_internal.h was certainly
*wrong*.
---
tools/libs/util/libxlu_cfg.c
This enumerated value is never used outside of the lowest layer of the
configuration parser. As such, move to the internal header.
Fixes: a30910bfd7 ("libxlu: Handle += in config files")
Signed-off-by: Elliott Mitchell
---
I'm unsure whether this is fixing a30910bfd7. Placing XLU_Operation in
l
These functions needs to cross the boundary between core and lower-layer.
As such split them in two. Pass most of the values from XLU_Config as
they can be used by the lower-layer.
Signed-off-by: Elliott Mitchell
---
tools/libs/util/libxlu_cfg.c | 47 ++-
tools/
Hi,
On 01/08/2023 10:59, Jan Beulich wrote:
On 01.08.2023 11:46, Oleksii wrote:
On Mon, 2023-07-31 at 15:24 +0200, Jan Beulich wrote:
On 27.07.2023 18:45, Oleksii Kurochko wrote:
@@ -654,6 +674,9 @@ static void ns16550_init_common(struct ns16550
*uart)
/* Default lsr_mask = UART_LSR_
flight 182101 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/182101/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-libvirt-raw 13 guest-start fail REGR. vs. 180278
test-arm64-arm64-xl
A few files treewide depend on defininitions in headers that they
don't include. This works when arch headers end up including the
required headers by chance, but broke on ppc64 with only minimal/stub
arch headers.
Signed-off-by: Shawn Anastasio
---
xen/common/memory.c | 1 +
xen/common/sy
Implement bitops.h, based on Linux's implementation as of commit
5321d1b1afb9a17302c6cec79f0cbf823eb0d3fc
Signed-off-by: Shawn Anastasio
---
xen/arch/ppc/include/asm/bitops.h | 331 +-
1 file changed, 327 insertions(+), 4 deletions(-)
diff --git a/xen/arch/ppc/includ
Implement atomic.h for PPC, based off of the original Xen 3.2
implementation.
Signed-off-by: Shawn Anastasio
---
xen/arch/ppc/include/asm/atomic.h | 387 ++
xen/arch/ppc/include/asm/memory.h | 34 +++
2 files changed, 421 insertions(+)
create mode 100644 xen/arch/pp
Signed-off-by: Shawn Anastasio
---
xen/include/public/arch-ppc.h | 140 ++
1 file changed, 140 insertions(+)
create mode 100644 xen/include/public/arch-ppc.h
diff --git a/xen/include/public/arch-ppc.h b/xen/include/public/arch-ppc.h
new file mode 100644
index 000
Hello all,
This patch series performs all of the additions necessary to drop the
build overrides for PPC and enable the full Xen build. Except in cases
where compatibile implementations already exist (e.g. atomic.h and
bitops.h), the newly added definitions are simple, unimplemented stubs
that jus
1 - 100 of 121 matches
Mail list logo
