On 26.02.2024 18:38, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
albeit ...
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/fence.h
> @@ -0,0 +1,9 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +#ifndef _ASM_RISCV_FENCE_H
> +#define
On 04.03.2024 17:10, Andrew Cooper wrote:
> --- a/xen/include/xen/nospec.h
> +++ b/xen/include/xen/nospec.h
> @@ -9,6 +9,29 @@
>
> #include
>
> +/*
> + * Protect a conditional branch from bad speculation. Architectures *must*
> + * provide arch_evaluate_nospec() for this to be effective.
>
On 04.03.2024 17:10, Andrew Cooper wrote:
> --- a/xen/include/xen/nospec.h
> +++ b/xen/include/xen/nospec.h
> @@ -18,6 +18,15 @@ static always_inline bool evaluate_nospec(bool cond)
> #ifndef arch_evaluate_nospec
> #define arch_evaluate_nospec(cond) cond
> #endif
> +
> +/*
> + * If the
On 04.03.2024 17:10, Andrew Cooper wrote:
> It is daft to require all architectures to provide empty implementations of
> this functionality.
>
> Provide evaluate_nospec() and block_speculation() unconditionally in
> xen/nospec.h with architectures able to opt in by providing suitable arch
>
On 04.03.2024 18:40, Julien Grall wrote:
> Hi Andrew,
>
> On 04/03/2024 17:07, Andrew Cooper wrote:
>> On 04/03/2024 4:55 pm, Jan Beulich wrote:
>>> On 04.03.2024 17:46, Julien Grall wrote:
On 04/03/2024 16:41, Jan Beulich wrote:
> On 04.03.2024 17:31, Julien Grall wrote:
>> On
On 05.03.2024 03:03, Stefano Stabellini wrote:
> On Mon, 4 Mar 2024, Jan Beulich wrote:
>> On 02.03.2024 02:37, Stefano Stabellini wrote:
>>> On Fri, 1 Mar 2024, Jan Beulich wrote:
On 29.02.2024 23:57, Stefano Stabellini wrote:
> On Thu, 29 Feb 2024, Nicola Vetrini wrote:
>> MISRA C
On 05.03.2024 02:49, Stefano Stabellini wrote:
> On Mon, 4 Mar 2024, Jan Beulich wrote:
>> On 04.03.2024 16:39, Federico Serafini wrote:
>>> On 04/03/24 15:17, Jan Beulich wrote:
On 04.03.2024 14:31, Federico Serafini wrote:
> On 01/03/24 09:06, Jan Beulich wrote:
>> On 01.03.2024
flight 184905 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184905/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt-raw 15 saverestore-support-check fail blocked in
184833
test-armhf-armhf-libvirt 16
From: Alexei Starovoitov
There are various users of get_vm_area() + ioremap_page_range() APIs.
Enforce that get_vm_area() was requested as VM_IOREMAP type and range
passed to ioremap_page_range() matches created vm_area to avoid
accidentally ioremap-ing into wrong address range.
Reviewed-by:
From: Alexei Starovoitov
vmap/vmalloc APIs are used to map a set of pages into contiguous kernel
virtual space.
get_vm_area() with appropriate flag is used to request an area of kernel
address range. It's used for vmalloc, vmap, ioremap, xen use cases.
- vmalloc use case dominates the usage.
From: Alexei Starovoitov
v3 -> v4
- dropped VM_XEN patch for now. It will be in the follow up.
- fixed constant as pointed out by Mike
v2 -> v3
- added Christoph's reviewed-by to patch 1
- cap commit log lines to 75 chars
- factored out common checks in patch 3 into helper
- made
On Mon, 4 Mar 2024, Jan Beulich wrote:
> On 02.03.2024 02:37, Stefano Stabellini wrote:
> > On Fri, 1 Mar 2024, Jan Beulich wrote:
> >> On 29.02.2024 23:57, Stefano Stabellini wrote:
> >>> On Thu, 29 Feb 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the
On Mon, 4 Mar 2024, Federico Serafini wrote:
> Update ECLAIR configuration to take into account the deviations
> agreed during MISRA meetings.
>
> Signed-off-by: Federico Serafini
Reviewed-by: Stefano Stabellini
On Mon, 4 Mar 2024, Jan Beulich wrote:
> On 04.03.2024 16:39, Federico Serafini wrote:
> > On 04/03/24 15:17, Jan Beulich wrote:
> >> On 04.03.2024 14:31, Federico Serafini wrote:
> >>> On 01/03/24 09:06, Jan Beulich wrote:
> On 01.03.2024 00:28, Stefano Stabellini wrote:
> > On Wed, 14
On Mon, 4 Mar 2024, Nicola Vetrini wrote:
> Hi,
>
> as the maintainers of this subsystem, would you prefer Jan's version or the
> one in the patch?
> Both are fine w.r.t MISRA Rule 20.7 because the macro arguments themselves are
> parenthesized.
I prefer Jan's version. Thanks for asking Nicola.
> From: Jan Beulich
> Sent: Monday, March 4, 2024 5:28 PM
>
> We'd like to thank the VT-x maintainers for their past contributions,
> while at the same time we'd like to reflect reality as it has been for
> quite some time. Have VT-x maintainership (and for symmetry also AMD
> SVM's) fall back
On Sun, Mar 3, 2024 at 11:55 PM Mike Rapoport wrote:
>
> On Fri, Feb 23, 2024 at 03:57:27PM -0800, Alexei Starovoitov wrote:
> > From: Alexei Starovoitov
> >
> > xen grant table and xenbus ring are not ioremap the way arch specific code
> > is using it,
> > so let's add VM_XEN flag to separate
On Mon, Mar 04, 2024 at 11:55:07PM +, Andrew Cooper wrote:
> On 25/01/2024 8:24 pm, Elliott Mitchell wrote:
> > The original observation features MD-RAID1 using a pair of Samsung
> > SATA-attached flash devices. The main line shows up in `xl dmesg`:
> >
> > (XEN) AMD-Vi: IO_PAGE_FAULT:
Hi Julien,
On 3/5/2024 2:38 AM, Julien Grall wrote:
On 01/03/2024 03:03, Henry Wang wrote:
Hi Julien,
Hi Henry,
On 2/28/2024 8:27 PM, Julien Grall wrote:
Hi Henry,
...here basically means we want to do the finding of the unused
region in toolstack. Since currently what we care about is
On 25/01/2024 8:24 pm, Elliott Mitchell wrote:
> The original observation features MD-RAID1 using a pair of Samsung
> SATA-attached flash devices. The main line shows up in `xl dmesg`:
>
> (XEN) AMD-Vi: IO_PAGE_FAULT: :bb:dd.f d0 addr ff???000 flags 0x8 I
You have a device which is
Hi Paul,
On 01/03/2024 19:37, Paul Leiber wrote:
Stopping xen-watchdog prevents the reboot. However, when triggering
traffic on the VLAN, Dom0 and DomU become completely unresponsive. No
error or kernel message is printed in the serial console.
Thanks for providing some logs. See some
On 04/03/2024, Andrew Panyakin wrote:
> On 04/03/2024, Greg KH wrote:
> > On Sat, Mar 02, 2024 at 08:03:57AM -0800, Andrew Panyakin wrote:
> > > From: Maximilian Heyne
> > >
> > > Commit fa765c4b4aed2d64266b694520ecb025c862c5a9 upstream
> [...]
> > Where is the 5.15.y version of this commit? We
From: Maximilian Heyne
Commit fa765c4b4aed2d64266b694520ecb025c862c5a9 upstream
shutdown_pirq and startup_pirq are not taking the
irq_mapping_update_lock because they can't due to lock inversion. Both
are called with the irq_desc->lock being taking. The lock order,
however, is first
flight 184903 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184903/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 918288ab5a7c3abe9c58d576ccc0ae32e2c7dea0
baseline version:
ovmf
On Mon, Feb 12, 2024 at 03:23:00PM -0800, Elliott Mitchell wrote:
> On Thu, Jan 25, 2024 at 12:24:53PM -0800, Elliott Mitchell wrote:
> > Apparently this was first noticed with 4.14, but more recently I've been
> > able to reproduce the issue:
> >
> > https://bugs.debian.org/988477
> >
> > The
From: Maximilian Heyne
Commit fa765c4b4aed2d64266b694520ecb025c862c5a9 upstream
shutdown_pirq and startup_pirq are not taking the
irq_mapping_update_lock because they can't due to lock inversion. Both
are called with the irq_desc->lock being taking. The lock order,
however, is first
flight 184890 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184890/
Failures and problems with tests :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-libvirt broken
Tests which are
On 04/03/2024, Greg KH wrote:
> On Sat, Mar 02, 2024 at 08:03:57AM -0800, Andrew Panyakin wrote:
> > From: Maximilian Heyne
> >
> > Commit fa765c4b4aed2d64266b694520ecb025c862c5a9 upstream
[...]
> Where is the 5.15.y version of this commit? We have to have that before
> we can take a 5.10.y
On 01/03/2024 03:03, Henry Wang wrote:
Hi Julien,
Hi Henry,
On 2/28/2024 8:27 PM, Julien Grall wrote:
Hi Henry,
...here basically means we want to do the finding of the unused
region in toolstack. Since currently what we care about is only a
couple of pages instead of the whole memory
flight 184899 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184899/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf bff9815b616669f1cf743e412bcefe22dfb4
baseline version:
ovmf
Hi,
as the maintainers of this subsystem, would you prefer Jan's version or
the one in the patch?
Both are fine w.r.t MISRA Rule 20.7 because the macro arguments
themselves are parenthesized.
--- a/xen/arch/arm/include/asm/vgic-emul.h
+++ b/xen/arch/arm/include/asm/vgic-emul.h
@@ -6,11
On 04/03/2024 5:40 pm, Julien Grall wrote:
> Hi Andrew,
>
> On 04/03/2024 17:07, Andrew Cooper wrote:
>> On 04/03/2024 4:55 pm, Jan Beulich wrote:
>>> On 04.03.2024 17:46, Julien Grall wrote:
On 04/03/2024 16:41, Jan Beulich wrote:
> On 04.03.2024 17:31, Julien Grall wrote:
>> On
Hi Andrew,
On 04/03/2024 17:07, Andrew Cooper wrote:
On 04/03/2024 4:55 pm, Jan Beulich wrote:
On 04.03.2024 17:46, Julien Grall wrote:
On 04/03/2024 16:41, Jan Beulich wrote:
On 04.03.2024 17:31, Julien Grall wrote:
On 04/03/2024 16:10, Andrew Cooper wrote:
It is daft to require all
On 04/03/2024 4:55 pm, Jan Beulich wrote:
> On 04.03.2024 17:46, Julien Grall wrote:
>> On 04/03/2024 16:41, Jan Beulich wrote:
>>> On 04.03.2024 17:31, Julien Grall wrote:
On 04/03/2024 16:10, Andrew Cooper wrote:
> It is daft to require all architectures to provide empty implementations
On 04.03.2024 17:46, Julien Grall wrote:
> On 04/03/2024 16:41, Jan Beulich wrote:
>> On 04.03.2024 17:31, Julien Grall wrote:
>>> On 04/03/2024 16:10, Andrew Cooper wrote:
It is daft to require all architectures to provide empty implementations of
this functionality.
>>>
>>> Oleksii
On 04/03/2024 4:41 pm, Jan Beulich wrote:
> On 04.03.2024 17:31, Julien Grall wrote:
>> On 04/03/2024 16:10, Andrew Cooper wrote:
>>> It is daft to require all architectures to provide empty implementations of
>>> this functionality.
>> Oleksii recenlty sent a similar patch [1]. This was pushed
Hi Jan,
On 04/03/2024 16:41, Jan Beulich wrote:
On 04.03.2024 17:31, Julien Grall wrote:
On 04/03/2024 16:10, Andrew Cooper wrote:
It is daft to require all architectures to provide empty implementations of
this functionality.
Oleksii recenlty sent a similar patch [1]. This was pushed back
On 04/03/2024 4:45 pm, Jan Beulich wrote:
> On 04.03.2024 17:10, Andrew Cooper wrote:
>> --- a/xen/arch/x86/include/asm/nospec.h
>> +++ b/xen/arch/x86/include/asm/nospec.h
>> @@ -23,20 +23,20 @@ static always_inline bool barrier_nospec_false(void)
>> return false;
>> }
>>
>> -/* Allow to
On 04.03.2024 17:10, Andrew Cooper wrote:
> --- a/xen/arch/x86/include/asm/nospec.h
> +++ b/xen/arch/x86/include/asm/nospec.h
> @@ -23,20 +23,20 @@ static always_inline bool barrier_nospec_false(void)
> return false;
> }
>
> -/* Allow to protect evaluation of conditionals with respect to
flight 184886 linux-linus real [real]
flight 184898 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184886/
http://logs.test-lab.xenproject.org/osstest/logs/184898/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
On 04.03.2024 17:31, Julien Grall wrote:
> On 04/03/2024 16:10, Andrew Cooper wrote:
>> It is daft to require all architectures to provide empty implementations of
>> this functionality.
>
> Oleksii recenlty sent a similar patch [1]. This was pushed back because
> from naming, it sounds like the
On 04.03.2024 16:39, Federico Serafini wrote:
> On 04/03/24 15:17, Jan Beulich wrote:
>> On 04.03.2024 14:31, Federico Serafini wrote:
>>> On 01/03/24 09:06, Jan Beulich wrote:
On 01.03.2024 00:28, Stefano Stabellini wrote:
> On Wed, 14 Feb 2024, Federico Serafini wrote:
>> On
Hi Andrew,
On 04/03/2024 16:10, Andrew Cooper wrote:
It is daft to require all architectures to provide empty implementations of
this functionality.
Oleksii recenlty sent a similar patch [1]. This was pushed back because
from naming, it sounds like the helpers ought to be non-empty on every
When the compiler can reduce the condition to a constant, it can elide the
conditional and one of the basic blocks. However, arch_evaluate_nospec() will
still insert speculation protection, despite there being nothing to protect.
Allow the speculation protection to be skipped entirely when the
Andrew Cooper (2):
xen/*/nospec: Provide common versions of evaluate_nospec/block_speculation
xen/nospec: Allow evaluate_nospec() to short circuit constant expressions
xen/arch/arm/include/asm/nospec.h | 9
xen/arch/ppc/include/asm/nospec.h | 9
It is daft to require all architectures to provide empty implementations of
this functionality.
Provide evaluate_nospec() and block_speculation() unconditionally in
xen/nospec.h with architectures able to opt in by providing suitable arch
variants.
Rename x86's implementation to the arch_*()
On 04/03/24 15:17, Jan Beulich wrote:
On 04.03.2024 14:31, Federico Serafini wrote:
On 01/03/24 09:06, Jan Beulich wrote:
On 01.03.2024 00:28, Stefano Stabellini wrote:
On Wed, 14 Feb 2024, Federico Serafini wrote:
On 14/02/24 14:15, Jan Beulich wrote:
On 14.02.2024 12:27, Federico Serafini
On 04.03.2024 14:31, Federico Serafini wrote:
> On 01/03/24 09:06, Jan Beulich wrote:
>> On 01.03.2024 00:28, Stefano Stabellini wrote:
>>> On Wed, 14 Feb 2024, Federico Serafini wrote:
On 14/02/24 14:15, Jan Beulich wrote:
> On 14.02.2024 12:27, Federico Serafini wrote:
>> On
On 01/03/24 09:06, Jan Beulich wrote:
On 01.03.2024 00:28, Stefano Stabellini wrote:
On Wed, 14 Feb 2024, Federico Serafini wrote:
On 14/02/24 14:15, Jan Beulich wrote:
On 14.02.2024 12:27, Federico Serafini wrote:
On 14/02/24 09:28, Jan Beulich wrote:
On 13.02.2024 23:33, Stefano
On 04/03/2024 8:42 am, Jan Beulich wrote:
> On 01.03.2024 12:28, Andrew Cooper wrote:
>> --- a/xen/arch/x86/cpu-policy.c
>> +++ b/xen/arch/x86/cpu-policy.c
>> @@ -464,6 +464,16 @@ static void __init
>> guest_common_max_feature_adjustments(uint32_t *fs)
>> raw_cpu_policy.feat.clwb )
flight 184891 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184891/
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
On Sat, Mar 02, 2024 at 08:03:57AM -0800, Andrew Panyakin wrote:
> From: Maximilian Heyne
>
> Commit fa765c4b4aed2d64266b694520ecb025c862c5a9 upstream
>
> shutdown_pirq and startup_pirq are not taking the
> irq_mapping_update_lock because they can't due to lock inversion. Both
> are called with
On 04.03.2024 11:02, Roger Pau Monné wrote:
> On Mon, Mar 04, 2024 at 08:32:22AM +0100, Jan Beulich wrote:
>> BARs of size 2Gb and up can't possibly fit below 4Gb: Both the bottom of
>> the lower 2Gb range and the top of the higher 2Gb range have special
>> purpose. Don't even have them influence
flight 184892 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184892/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 1ae5bee967bffcd6dbbabca913ea3c65d8f09c76
baseline version:
ovmf
On 04/03/2024 8:33 am, Jan Beulich wrote:
> On 29.02.2024 23:14, Andrew Cooper wrote:
>> PV guests can't write to MSR_APIC_BASE (in order to set EXTD), nor can they
>> access any of the x2APIC MSR range. Therefore they mustn't see the x2APIC
>> CPUID bit saying that they can.
> This argumentation
Hi all,
Please add your proposed agenda items below.
https://cryptpad.fr/pad/#/2/pad/edit/VlIkjPmILf0abDG3j1Wn0091/
If any action items are missing or have been resolved, please add/remove
them from the sheet.
*CALL LINK: https://meet.jit.si/XenProjectCommunityCall
Hi,
On 04/03/2024 07:32, Jan Beulich wrote:
> BARs of size 2Gb and up can't possibly fit below 4Gb: Both the bottom of
> the lower 2Gb range and the top of the higher 2Gb range have special
> purpose. Don't even have them influence whether to (perhaps) relocate
> low RAM.
>
> Reported-by:
Hi Marek,
Try this link, it should show the sessions for 2023.
https://xen2023.sched.com/
Many thanks,
Kelly Choi
Community Manager
Xen Project
On Sun, Mar 3, 2024 at 3:01 AM Marek Marczykowski-Górecki <
marma...@invisiblethingslab.com> wrote:
> Hi,
>
> The link to the last year schedule at
Hi everyone,
Good news, our CFP deadline for Xen Summit has been extended by one week to
Sunday 10th March 2024.
Please submit your talks before then!
Many thanks,
Kelly Choi
Community Manager
Xen Project
On Tue, Feb 27, 2024 at 10:22 AM Kelly Choi wrote:
> Hi everyone,
>
> *Just a
On Mon, Mar 04, 2024 at 10:27:44AM +0100, Jan Beulich wrote:
> We'd like to thank the VT-x maintainers for their past contributions,
> while at the same time we'd like to reflect reality as it has been for
> quite some time. Have VT-x maintainership (and for symmetry also AMD
> SVM's) fall back to
On Tue, Feb 27, 2024 at 6:32 PM Anthony PERARD wrote:
>
> On Tue, Feb 27, 2024 at 01:26:28PM +, Fouad Hilly wrote:
> > diff --git a/tools/libs/stat/xenstat_linux.c
> > b/tools/libs/stat/xenstat_linux.c
> > index cbba54aa83ee..6d82e204aad4 100644
> > --- a/tools/libs/stat/xenstat_linux.c
> >
On 04/03/24 11:28, Federico Serafini wrote:
Update ECLAIR configuration to take into account the deviations
agreed during MISRA meetings.
Signed-off-by: Federico Serafini
---
Changes in v2:
- rephrased to make sure the deviation is not interpreted as a suggestion.
---
Update ECLAIR configuration to take into account the deviations
agreed during MISRA meetings.
Signed-off-by: Federico Serafini
---
Changes in v2:
- rephrased to make sure the deviation is not interpreted as a suggestion.
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 4
On Mon, Mar 04, 2024 at 08:32:22AM +0100, Jan Beulich wrote:
> BARs of size 2Gb and up can't possibly fit below 4Gb: Both the bottom of
> the lower 2Gb range and the top of the higher 2Gb range have special
> purpose. Don't even have them influence whether to (perhaps) relocate
> low RAM.
Here
flight 184889 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184889/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3775122ede395d934198ffdb0c173875a5e94c00
baseline version:
ovmf
On 04/03/2024 9:27 am, Jan Beulich wrote:
> We'd like to thank the VT-x maintainers for their past contributions,
> while at the same time we'd like to reflect reality as it has been for
> quite some time. Have VT-x maintainership (and for symmetry also AMD
> SVM's) fall back to general x86.
>
>
On Tue, Feb 27, 2024 at 12:47 AM Andrew Cooper
wrote:
>
> On 06/02/2024 1:20 am, George Dunlap wrote:
> > Changeset ef3e8db8068 ("x86/hvm: Corrections and improvements to
> > unhandled vmexit logging") introduced a printk to the default path of
> > the switch statement in
On 29.02.2024 16:28, 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
We'd like to thank the VT-x maintainers for their past contributions,
while at the same time we'd like to reflect reality as it has been for
quite some time. Have VT-x maintainership (and for symmetry also AMD
SVM's) fall back to general x86.
Signed-off-by: Jan Beulich
--- a/MAINTAINERS
+++
From: Wei Liu
Previously FPU is lazily switched. Due to the fact that a malicious
guest can speculatively read the not yet switched out register states,
we need to eagerly switch FPU states when a domain is scheduled to
run.
In the new world, Xen will eagerly switch FPU context in the
From: Wei Liu
No functional change
Signed-off-by: Wei Liu
Signed-off-by: Fouad Hilly
---
CC: Jan Beulich
CC: Andrew Cooper
CC: "Roger Pau Monné"
CC: Wei Liu
---
xen/arch/x86/i387.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/i387.c
X86 Xen will only eagerly switch FPU context in the scheduler.
Xen itslef won't set CR0.TS other than for the purpose of servicing
a PV guset.
Signed-off-by: Wei Liu
Signed-off-by: Roger Pau Monné
Signed-off-by: Fouad Hilly
---
CC: Jan Beulich
CC: Andrew Cooper
CC: "Roger Pau Monné"
CC: Wei
From: Wei Liu
Factor out xrstor__ and introduce xstate_zero, which zeros all the
state components specified in the mask.
Signed-off-by: Wei Liu
Signed-off-by: Fouad Hilly
---
CC: Jan Beulich
CC: Andrew Cooper
CC: "Roger Pau Monné"
CC: Wei Liu
---
xen/arch/x86/include/asm/xstate.h | 1 +
As TOP_OF_KERNEL_STACK_PADDING is defined as 0 on x86_64, no one noticed
it's missing in the calculation of the .sp field in INIT_THREAD until it
is defined to 16 with CONFIG_X86_FRED=y.
Subtract TOP_OF_KERNEL_STACK_PADDING from the .sp field of INIT_THREAD.
Fixes: 65c9cc9e2c14 ("x86/fred:
On 04.03.2024 09:50, Roger Pau Monné wrote:
> On Mon, Mar 04, 2024 at 08:54:34AM +0100, Jan Beulich wrote:
>> On 01.03.2024 13:42, Roger Pau Monne wrote:
>>> The current usage of a cmpxchg loop to increase the value of page count is
>>> not
>>> optimal on amd64, as there's already an instruction
On Mon, Mar 04, 2024 at 08:54:34AM +0100, Jan Beulich wrote:
> On 01.03.2024 13:42, Roger Pau Monne wrote:
> > The current usage of a cmpxchg loop to increase the value of page count is
> > not
> > optimal on amd64, as there's already an instruction to do an atomic add to a
> > 64bit integer.
> >
On 01.03.2024 12:28, Andrew Cooper wrote:
> --- a/xen/arch/x86/cpu-policy.c
> +++ b/xen/arch/x86/cpu-policy.c
> @@ -464,6 +464,16 @@ static void __init
> guest_common_max_feature_adjustments(uint32_t *fs)
> raw_cpu_policy.feat.clwb )
> __set_bit(X86_FEATURE_CLWB, fs);
>
On 29.02.2024 23:14, Andrew Cooper wrote:
> PV guests can't write to MSR_APIC_BASE (in order to set EXTD), nor can they
> access any of the x2APIC MSR range. Therefore they mustn't see the x2APIC
> CPUID bit saying that they can.
This argumentation could then be used equally for the APIC bit.
On 04/03/24 09:04, Jan Beulich wrote:
On 01.03.2024 16:04, Federico Serafini wrote:
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -322,6 +322,12 @@ Deviations related to MISRA C:2012 Rules:
- /\* Fallthrough \*/
- /\* Fallthrough. \*/
+ * - R16.6
On 01.03.2024 18:21, Oleksii wrote:
> * limit passing around of cpu_user_regs [
> https://lore.kernel.org/xen-devel/ebc330a9-eafa-4858-b5cf-5694c4da9...@suse.com/
> ]:
> new patch series version was sent.
This was committed already a while ago.
> * [PATCH v2 0/5] xen/livepatch: fixes for
On 01.03.2024 16:04, Federico Serafini wrote:
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -322,6 +322,12 @@ Deviations related to MISRA C:2012 Rules:
> - /\* Fallthrough \*/
> - /\* Fallthrough. \*/
>
> + * - R16.6
> + - A switch statement
On 02.03.2024 02:37, Stefano Stabellini wrote:
> On Fri, 1 Mar 2024, Jan Beulich wrote:
>> On 29.02.2024 23:57, Stefano Stabellini wrote:
>>> On Thu, 29 Feb 2024, Nicola Vetrini wrote:
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be
82 matches
Mail list logo
