Hi Stefano,
> On 5 Apr 2024, at 01:57, Stefano Stabellini wrote:
>
> On Thu, 4 Apr 2024, Bertrand Marquis wrote:
>> Hi Stefano,
>>
>>> On 4 Apr 2024, at 03:12, Stefano Stabellini wrote:
>>>
>>> Xen makes assumptions about the size of integer types on the various
>>> architectures. Document th
flight 185241 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185241/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185236
test-amd64-amd64-xl-qemut-win7-amd64
On Fri, 2024-04-05 at 08:11 +0200, Jan Beulich wrote:
> On 04.04.2024 18:24, Oleksii wrote:
> > On Thu, 2024-04-04 at 18:12 +0200, Jan Beulich wrote:
> > > On 04.04.2024 17:45, Oleksii wrote:
> > > > On Thu, 2024-04-04 at 15:22 +0200, Jan Beulich wrote:
> > > > > On 03.04.2024 12:19, Oleksii Kuroch
On 05.04.2024 09:56, Oleksii wrote:
> On Fri, 2024-04-05 at 08:11 +0200, Jan Beulich wrote:
>> On 04.04.2024 18:24, Oleksii wrote:
>>> On Thu, 2024-04-04 at 18:12 +0200, Jan Beulich wrote:
On 04.04.2024 17:45, Oleksii wrote:
> On Thu, 2024-04-04 at 15:22 +0200, Jan Beulich wrote:
>> On
Use try_cmpxchg() instead of cmpxchg(*ptr, old, new) == old.
The x86 CMPXCHG instruction returns success in the ZF flag,
so this change saves a compare after CMPXCHG.
Also, try_cmpxchg() implicitly assigns old *ptr value to "old"
when CMPXCHG fails. There is no need to explicitly assign
old *ptr
Remove unneded blank lines between switch clauses.
Refactor the clauses so that a MISRA C Rule 16.2 violation is resolved
(A switch label shall only be used when the most closely-enclosing
compound statement is the body of a switch statement).
Note that the switch clause ending with the pseudo key
Remove unneded blank lines between switch clauses.
Refactor the last clauses so that a violation of
MISRA C Rule 16.2 is resolved (A switch label shall only be used
when the most closely-enclosing compound statement is the body of
a switch statement). The switch clause ending with the
pseudo keywo
Refactor the first clauses so that a violation of
MISRA C Rule 16.2 is resolved (a switch label should be immediately
enclosed in the compound statement of the switch).
Note that the switch clause ending with the pseudo
keyword "fallthrough" is an allowed exception to Rule 16.3.
Convert fallthroug
MISRA C Rule 16.2 states:
"A switch label shall only be used when the most closely-enclosing
compound statement is the body of a switch statement".
The PROGRESS_VCPU local helper specifies a case that is directly
inside the compound statement of a for loop, hence violating the rule.
To avoid this,
MISRA C Rule 16.2 states:
"A switch label shall only be used when the most closely-enclosing
compound statement is the body of a switch statement".
Since complying with this rule of the x86 emulator would lead to
a lot of code duplication, it is deemed better to exempt those
files for this guideli
Refactor the switch so that a violation of
MISRA C Rule 16.2 is resolved (A switch label shall only be used
when the most closely-enclosing compound statement is the body of
a switch statement).
Note that the switch clause ending with the pseudo
keyword "fallthrough" is an allowed exception to Rule
Refactor the switch so that a violation of MISRA C Rule 16.2 is resolved
(A switch label shall only be used when the most closely-enclosing
compound statement is the body of a switch statement).
Note that the switch clause ending with the pseudo
keyword "fallthrough" is an allowed exception to Rule
Refactor the first clauses so that a violation of
MISRA C Rule 16.2 is resolved (a switch label, "default" in this
case, should be immediately enclosed in the compound statement
of the switch). Note that the switch clause ending with the pseudo
keyword "fallthrough" is an allowed exception to Rule
Continuing the work done in [1], these patches make this rule clean (i.e., no
residual violation of the rule). Some switches are refactored to avoid
interleaving a case label inside an if statement. In some cases this leads to
some duplication, but the files where this would have had the greatest i
Refactor the switch so that a violation of
MISRA C Rule 16.2 is resolved (a switch label should be immediately
enclosed in the compound statement of the switch).
The switch clause ending with the pseudo
keyword "fallthrough" is an allowed exception to Rule 16.3.
Signed-off-by: Nicola Vetrini
---
Introduce configuration variables to make it possible to selectively turn
on/off CPU microcode management code in the build for AMD and Intel CPUs.
This is to allow build configuration for a specific CPU, not compile and
load what will not be used anyway.
Signed-off-by: Sergiy Kibrik
---
xen/ar
On Fri, 2024-04-05 at 08:08 +0200, Jan Beulich wrote:
> On 04.04.2024 18:17, Oleksii wrote:
> > On Thu, 2024-04-04 at 17:43 +0200, Jan Beulich wrote:
> > > On 04.04.2024 17:18, Oleksii wrote:
> > > > On Thu, 2024-04-04 at 12:07 +0200, Jan Beulich wrote:
> > > > > On 03.04.2024 12:19, Oleksii Kuroch
On 05/04/2024 11:30 am, Sergiy Kibrik wrote:
> Introduce configuration variables to make it possible to selectively turn
> on/off CPU microcode management code in the build for AMD and Intel CPUs.
>
> This is to allow build configuration for a specific CPU, not compile and
> load what will not be u
On Fri, 2024-04-05 at 10:05 +0200, Jan Beulich wrote:
> On 05.04.2024 09:56, Oleksii wrote:
> > On Fri, 2024-04-05 at 08:11 +0200, Jan Beulich wrote:
> > > On 04.04.2024 18:24, Oleksii wrote:
> > > > On Thu, 2024-04-04 at 18:12 +0200, Jan Beulich wrote:
> > > > > On 04.04.2024 17:45, Oleksii wrote:
On Fri, 2024-04-05 at 13:53 +0200, Oleksii wrote:
> On Fri, 2024-04-05 at 10:05 +0200, Jan Beulich wrote:
> > On 05.04.2024 09:56, Oleksii wrote:
> > > On Fri, 2024-04-05 at 08:11 +0200, Jan Beulich wrote:
> > > > On 04.04.2024 18:24, Oleksii wrote:
> > > > > On Thu, 2024-04-04 at 18:12 +0200, Jan
Refactor and introduce --force option to xen-ucode, which skips microcode
version check when updating x86 CPU micocode. A new hypercall introduced
with flags field to facilitate the new option and allow for future flags
as needed.
Fouad Hilly (5):
x86: Remove x86 low level version check of micro
Refactor microcode_update() hypercall by adding flags field.
Introduce XENPF_microcode_update2 hypercall to handle flags field.
Signed-off-by: Fouad Hilly
---
xen/arch/x86/cpu/microcode/core.c| 12 +---
xen/arch/x86/include/asm/microcode.h | 2 +-
xen/arch/x86/platform_hypercall.c
Use getopt_long() to handle command line arguments.
Introduce ext_err for common exit with errors.
Signed-off-by: Fouad Hilly
---
tools/misc/xen-ucode.c | 49 +-
1 file changed, 39 insertions(+), 10 deletions(-)
diff --git a/tools/misc/xen-ucode.c b/tools
Refactor xen-ucode tool by adding usage() to handle usage\help messages
Signed-off-by: Fouad Hilly
---
tools/misc/xen-ucode.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/tools/misc/xen-ucode.c b/tools/misc/xen-ucode.c
index c6ae6498d659..1edcebfb9f9c 100644
-
Introduce --force option to xen-ucode to force skipping microcode version
check, which allows the user to update x86 microcode even if both versions
are the same.
Signed-off-by: Fouad Hilly
---
Suggested-by: Andrew Cooper
---
tools/include/xenctrl.h | 2 +-
tools/libs/ctrl/xc_misc.c | 12 ++
Remove microcode version check at Intel and AMD Level.
Microcode version check will be at higher and common level.
Signed-off-by: Fouad Hilly
---
xen/arch/x86/cpu/microcode/amd.c | 8 ++--
xen/arch/x86/cpu/microcode/intel.c | 11 +++
2 files changed, 5 insertions(+), 14 deletions(
With recent sanity checks for topology information added, there are now
warnings issued for APs when running as a Xen PV guest:
[Firmware Bug]: CPU 1: APIC ID mismatch. CPUID: 0x APIC: 0x0001
This is due to the initial APIC ID obtained via CPUID for PV guests is
always 0.
Avoid the warni
These are 2 fixes for issues introduced by topology related changes
added in the 6.9 merge window.
Juergen Gross (2):
x86/cpu: fix BSP detection when running as Xen PV guest
x86/xen: return a sane initial apic id when running as PV guest
arch/x86/kernel/cpu/topology.c | 2 +-
arch/x86/xen/e
Hi all,
The April community call recording has been uploaded:
https://www.youtube.com/watch?v=fpcxKWdaJyw&ab_channel=TheXenProject
This has also been saved in the Cryptpad file.
Many thanks,
Kelly Choi
Community Manager
Xen Project
On 05.04.2024 13:56, Oleksii wrote:
> On Fri, 2024-04-05 at 13:53 +0200, Oleksii wrote:
>> On Fri, 2024-04-05 at 10:05 +0200, Jan Beulich wrote:
>>> On 05.04.2024 09:56, Oleksii wrote:
On Fri, 2024-04-05 at 08:11 +0200, Jan Beulich wrote:
> On 04.04.2024 18:24, Oleksii wrote:
>> On Thu
On 05/04/2024 1:34 pm, Juergen Gross wrote:
> With recent sanity checks for topology information added, there are now
> warnings issued for APs when running as a Xen PV guest:
>
> [Firmware Bug]: CPU 1: APIC ID mismatch. CPUID: 0x APIC: 0x0001
>
> This is due to the initial APIC ID obtained
On 05.04.24 14:50, Andrew Cooper wrote:
On 05/04/2024 1:34 pm, Juergen Gross wrote:
With recent sanity checks for topology information added, there are now
warnings issued for APs when running as a Xen PV guest:
[Firmware Bug]: CPU 1: APIC ID mismatch. CPUID: 0x APIC: 0x0001
This is d
The rule states:
"All identifiers used in the controlling expression of #if or #elif
preprocessing directives shall be #define'd before evaluation".
In this case, using defined(identifier) is a MISRA-compliant
way to achieve the same effect.
Signed-off-by: Nicola Vetrini
---
This is the only outs
On 04/04/2024 2:32 pm, Jan Beulich wrote:
> On 04.04.2024 15:22, Andrew Cooper wrote:
>> On 04/04/2024 1:45 pm, Jan Beulich wrote:
>>> For the write-discard property, how was that determined? Does it affect all
>>> writable bits?
>> Marek kindly ran a debugging patch for me last night to try and fi
It turns out there is something wonky on some but not all CPUs with
MSR_TSX_FORCE_ABORT. The presence of RTM_ALWAYS_ABORT causes Xen to think
it's safe to offer HLE/RTM to guests, but in this case, XBEGIN instructions
genuinely #UD.
Spot this case and try to back out as cleanly as we can.
Signed
On 05.04.2024 15:01, Andrew Cooper wrote:
> On 04/04/2024 2:32 pm, Jan Beulich wrote:
>> On 04.04.2024 15:22, Andrew Cooper wrote:
>>> On 04/04/2024 1:45 pm, Jan Beulich wrote:
> + * Spot this case, and treat it as if no TSX is available at
> all.
> + * This wil
On 05.04.2024 14:59, Nicola Vetrini wrote:
> The rule states:
> "All identifiers used in the controlling expression of #if or #elif
> preprocessing directives shall be #define'd before evaluation".
> In this case, using defined(identifier) is a MISRA-compliant
> way to achieve the same effect.
>
>
On 05.04.2024 15:07, Andrew Cooper wrote:
> It turns out there is something wonky on some but not all CPUs with
> MSR_TSX_FORCE_ABORT. The presence of RTM_ALWAYS_ABORT causes Xen to think
> it's safe to offer HLE/RTM to guests, but in this case, XBEGIN instructions
> genuinely #UD.
>
> Spot this
flight 185243 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185243/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 185228
Tests which did not
On Thu, Mar 28, 2024 at 05:54:04PM +, Anthony PERARD wrote:
> On Mon, Mar 18, 2024 at 04:55:09PM +, Anthony PERARD wrote:
I've now pushed
"production-config: Set Bookworm's debian-installer version"
and these two:
> > Switch to Debian Bookworm as default suite
> > make-hosts-flight:
flight 185244 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185244/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185235
test-amd64-amd64-libvirt-xsm 15 migrate-s
On Fri, 5 Apr 2024, Jan Beulich wrote:
> On 05.04.2024 02:27, Stefano Stabellini wrote:
> > On Thu, 28 Mar 2024, Simone Ballarin wrote:
> >> The Xen community wants to avoid using variadic functions except for
> >> specific circumstances where it feels appropriate by strict code review.
> >>
> >> F
Conditionalize xen/acpi.h's inclusion of acpi/acpi.h and asm/acpi.h on
CONFIG_ACPI and import ARM's !CONFIG_ACPI stub for acpi_disabled() so
that the header can be included on architectures without ACPI support,
like ppc.
This change revealed some missing #includes across the ARM tree, so fix
thos
On Fri, 5 Apr 2024, Jan Beulich wrote:
> On 05.04.2024 01:56, Stefano Stabellini wrote:
> > On Thu, 4 Apr 2024, Jan Beulich wrote:
> >> On 04.04.2024 03:12, Stefano Stabellini wrote:
> >>> --- a/docs/misra/C-language-toolchain.rst
> >>> +++ b/docs/misra/C-language-toolchain.rst
> >>> @@ -480,4 +480
Xen makes assumptions about the size of integer types on the various
architectures. Document these assumptions.
Signed-off-by: Stefano Stabellini
---
Changes in v4:
- list the architectures explicitly
- add ARMv7-A
---
docs/misra/C-language-toolchain.rst | 73 +
1 fil
On Fri, 5 Apr 2024, Jan Beulich wrote:
> On 05.04.2024 02:18, Stefano Stabellini wrote:
> > On Wed, 3 Apr 2024, Nicola Vetrini wrote:
> >> On 2024-04-03 08:33, Jan Beulich wrote:
> >>> On 02.04.2024 09:22, Federico Serafini wrote:
> Use pseudo-keyword fallthrough to meet the requirements to de
flight 185249 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185249/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 185251 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185251/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl 1
flight 185246 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185246/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185241
test-amd64-amd64-xl-qemut-win7-amd64
flight 185247 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185247/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 185228
test-amd64-amd64-xl-qemut-win7-amd64
50 matches
Mail list logo
