On 28/02/24 10:06, Jan Beulich wrote:
On 28.02.2024 09:53, Federico Serafini wrote:
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
Comments below apply similarly to text added to this file.
--- a/docs/misra/deviations.rst
+++ b/d
On 28.02.2024 17:15, Andrew Cooper wrote:
> On 28/02/2024 1:53 pm, Jan Beulich wrote:
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -539,6 +544,50 @@ static void show_trace(const struct cpu_
>> !is_active_kernel_text(tos) )
>> printk(" [<%p>] R %pS\n", _p(re
On 29.02.2024 09:01, Federico Serafini wrote:
> On 28/02/24 10:06, Jan Beulich wrote:
>> On 28.02.2024 09:53, Federico Serafini wrote:
>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>
>> Comments below apply similarly to text a
On 29.02.2024 02:10, Andrew Cooper wrote:
> On 28/02/2024 2:48 pm, Jan Beulich wrote:
>> Linux commit 25a068b8e9a4e ("x86/apic: Add extra serialization for non-
>> serializing MSRs") explains why an MFENCE+LFENCE pair is generally
>> needed ahead of ICR writes in x2APIC mode, and also why at least
On 28.02.2024 16:16, Andrew Cooper wrote:
> On 28/02/2024 1:52 pm, Jan Beulich wrote:
>> We will want to use that value for call trace generation, and likely
>> also to eliminate the somewhat fragile shadow stack searching done in
>> fixup_exception_return(). For those purposes, guest-only entry po
Hello,
The following series limits the supported versions of Clang to what I
actually care about, as I seem to be the only one that actively uses
Clang/LLVM builds of Xen.
Patch 2 adds non-debug tests for -clang builds.
Thanks, Roger.
Roger Pau Monne (2):
README: bump minimum required clang/l
The generated code between the debug and release builds can be quite
different, as a note 2ce562b2a413 only manifested in non-debug builds due to
the usage of -O2.
Duplicate the clang based test in order to test with both debug and non-debug
Xen builds.
Signed-off-by: Roger Pau Monné
---
automa
We no longer have a way to build with the minimum required clang/llvm version
stated in the README on the gitlab CI loop, since we dropped the Debian Jessie
container that had Clang 3.5.0.
Bump the minimum required Clang/LLVM to the one used in the oldest production
FreeBSD version (13.2 currently
On 2024-02-28 23:38, Stefano Stabellini wrote:
On Wed, 28 Feb 2024, Julien Grall wrote:
Hi Nicola,
On 28/02/2024 11:09, Nicola Vetrini wrote:
> > I asked Roberto if void casts are an option for compliance.
> >
>
> void casts are an option for sure. The rationale for the rule explicitly
> lists
On 28/02/2024 23:27, Stefano Stabellini wrote:
>
>
> On Wed, 28 Feb 2024, Michal Orzel wrote:
>> Hi Julien,
>>
>> On 28/02/2024 12:42, Julien Grall wrote:
>>>
>>>
>>> Hi Michal,
>>>
>>> On 28/02/2024 10:35, Michal Orzel wrote:
Commit 0441c3acc7e9 forgot to rename FIXMAP_CONSOLE to FIX_CON
Hi,
On 29/02/2024 10:07, Michal Orzel wrote:
On 28/02/2024 23:27, Stefano Stabellini wrote:
On Wed, 28 Feb 2024, Michal Orzel wrote:
Hi Julien,
On 28/02/2024 12:42, Julien Grall wrote:
Hi Michal,
On 28/02/2024 10:35, Michal Orzel wrote:
Commit 0441c3acc7e9 forgot to rename FIXMAP_CON
On 29/02/2024 07:58, Jan Beulich wrote:
On 28.02.2024 23:58, Julien Grall wrote:
On 27/02/2024 07:55, Jan Beulich wrote:
On 26.02.2024 18:39, Oleksii Kurochko wrote:
This patch doesn't represent a strict lower bound for GCC and
GNU Binutils; rather, these versions are specifically employed
flight 184817 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184817/
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
Hi Julien,
Thank you for your quick answer.
You will find below our answers (in red) to your questions.
To summarize our request : what we would like is to use USB 3.0 driver with
high speed configuration.
Today, it is not possible to do that.
The driver stay in full speed mode, and more often
Right now, the host x2APIC setting filters into the PV max and default
policies, yet PV guests cannot set MSR_APIC_BASE.EXTD or access any of the
x2APIC MSR range. Therefore they absolutely shouldn't see the x2APIC bit.
Linux has workarounds for the collateral damage caused by this leakage; it
un
Hi Dominique,
On 29/02/2024 10:33, LARRIEU Dominique wrote:
Thank you for your quick answer.
You will find below our answers (in red) to your questions.
To summarize our request : what we would like is to use USB 3.0 driver with
high speed configuration.
Today, it is not possible to do that.
On 29.02.2024 11:23, Julien Grall wrote:
> On 29/02/2024 07:58, Jan Beulich wrote:
>> Therefore being too
>> eager there would mean I can't really / easily (smoke) test Xen
>> anymore on ancient hardware every once in a while. When afaict we do
>> too little of such testing already anyway, despite
On Thu, Feb 29, 2024 at 10:43:04AM +, Andrew Cooper wrote:
> Right now, the host x2APIC setting filters into the PV max and default
> policies, yet PV guests cannot set MSR_APIC_BASE.EXTD or access any of the
> x2APIC MSR range. Therefore they absolutely shouldn't see the x2APIC bit.
>
> Linu
On 29.02.2024 12:56, Jan Beulich wrote:
> On 29.02.2024 11:23, Julien Grall wrote:
>> On 29/02/2024 07:58, Jan Beulich wrote:
>>> (And
>>> no, upgrading the ancient distros on that ancient hardware is not an
>>> option for me.)
>>
>> May I ask why? Is it because newer distros don't support your HW?
On 29/02/2024 10:23 am, Julien Grall wrote:
IOW it is hard for me to see why RISC-V needs stronger restrictions
here
than other architectures. It ought to be possible to determine a
baseline
version. Even if taking the desire to have "pause" available as a
requirement,
flight 184818 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184818/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf dc7cfa9bab7487aa0cec02d13aa8c34ff24b37a8
baseline version:
ovmf d9a6e7b0b8a67392a5778
On 29.02.2024 10:55, Roger Pau Monne wrote:
> --- a/README
> +++ b/README
> @@ -41,7 +41,7 @@ provided by your OS distributor:
> - GCC 4.1.2_20070115 or later
> - GNU Binutils 2.16.91.0.5 or later
> or
> -- Clang/LLVM 3.5 or later
> +- Clang/LLVM 14.0.0 or
Since commit bd1001db0af1 ("xen/arm: arm32: Allow Xen to boot on
unidentified CPUs"), it's been possible to boot 32-bit Xen on ARMv8A CPUs
in AArch32 state (assuming HW supports EL2 execution in AArch32). Clarify
the support statement and mark it as Tech Preview, as this use case is
uncommon and ha
On 29.02.2024 13:05, Andrew Cooper wrote:
> On 29/02/2024 10:23 am, Julien Grall wrote:
> IOW it is hard for me to see why RISC-V needs stronger restrictions
> here
> than other architectures. It ought to be possible to determine a
> baseline
> version. Even if taking the desire
Hi Andrew,
On 29/02/2024 12:05, Andrew Cooper wrote:
On 29/02/2024 10:23 am, Julien Grall wrote:
IOW it is hard for me to see why RISC-V needs stronger restrictions
here
than other architectures. It ought to be possible to determine a
baseline
version. Even if taking the desire to have "pause"
Hi,
On 29/02/2024 12:17, Jan Beulich wrote:
On 29.02.2024 13:05, Andrew Cooper wrote:
On 29/02/2024 10:23 am, Julien Grall wrote:
IOW it is hard for me to see why RISC-V needs stronger restrictions
here
than other architectures. It ought to be possible to determine a
baseline
version. Even if
On 29/02/2024 11:10, Julien Grall wrote:
>
>
> Hi,
>
> On 29/02/2024 10:07, Michal Orzel wrote:
>>
>>
>> On 28/02/2024 23:27, Stefano Stabellini wrote:
>>>
>>>
>>> On Wed, 28 Feb 2024, Michal Orzel wrote:
Hi Julien,
On 28/02/2024 12:42, Julien Grall wrote:
>
>
> Hi
Hi Michal,
On 29/02/2024 12:13, Michal Orzel wrote:
Since commit bd1001db0af1 ("xen/arm: arm32: Allow Xen to boot on
unidentified CPUs"), it's been possible to boot 32-bit Xen on ARMv8A CPUs
in AArch32 state (assuming HW supports EL2 execution in AArch32). Clarify
the support statement and mark
Hi Julien,
On 29/02/2024 13:35, Julien Grall wrote:
>
>
> Hi Michal,
>
> On 29/02/2024 12:13, Michal Orzel wrote:
>> Since commit bd1001db0af1 ("xen/arm: arm32: Allow Xen to boot on
>> unidentified CPUs"), it's been possible to boot 32-bit Xen on ARMv8A CPUs
>> in AArch32 state (assuming HW sup
On 29/02/2024 12:37, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 29/02/2024 13:35, Julien Grall wrote:
On 29/02/2024 12:13, Michal Orzel wrote:
Since commit bd1001db0af1 ("xen/arm: arm32: Allow Xen to boot on
unidentified CPUs"), it's been possible to boot 32-bit Xen on ARMv8A CPUs
in
On Thu, Feb 29, 2024 at 01:11:55PM +0100, Jan Beulich wrote:
> On 29.02.2024 10:55, Roger Pau Monne wrote:
> > --- a/README
> > +++ b/README
> > @@ -41,7 +41,7 @@ provided by your OS distributor:
> > - GCC 4.1.2_20070115 or later
> > - GNU Binutils 2.16.91.0.5 or later
> >
On 29/02/2024 13:40, Julien Grall wrote:
>
>
> On 29/02/2024 12:37, Michal Orzel wrote:
>> Hi Julien,
>
> Hi Michal,
>
>>
>> On 29/02/2024 13:35, Julien Grall wrote:
>>> On 29/02/2024 12:13, Michal Orzel wrote:
Since commit bd1001db0af1 ("xen/arm: arm32: Allow Xen to boot on
uniden
On 29.02.2024 11:43, Andrew Cooper wrote:
> Right now, the host x2APIC setting filters into the PV max and default
> policies, yet PV guests cannot set MSR_APIC_BASE.EXTD or access any of the
> x2APIC MSR range. Therefore they absolutely shouldn't see the x2APIC bit.
>
> Linux has workarounds for
Update the Mini-OS upstream revision.
Signed-off-by: Juergen Gross
---
V9:
- new patch
---
Config.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Config.mk b/Config.mk
index 6f6e0425ba..a962f095ca 100644
--- a/Config.mk
+++ b/Config.mk
@@ -224,7 +224,7 @@ QEMU_UPSTREAM_URL
Mount the 9pfs device in stubdom enabling it to use files.
This has to happen in a worker thread in order to allow the main thread
handling the required Xenstore accesses in parallel.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
Reviewed-by: Julien Grall
---
V3:
- add logging in cas
This series is adding 9pfs support to Xenstore-stubdom, enabling it
to do logging to a dom0 directory.
This is a prerequisite for the final goal to add live update support
to Xenstore-stubdom, as it enables the stubdom to store its state in
a dom0 file.
Reposting the rest series. CI-test has pass
Extend the config files of the Xenstore stubdoms to include XENBUS
and 9PFRONT items in order to support file based logging.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
---
stubdom/xenstore-minios.cfg| 2 +-
stubdom/xenstorepvh-minios.cfg | 2 +-
2 files changed, 2 insertions(+)
With 9pfs being fully available in Xenstore-stubdom now, there is no
reason to not fully support all logging capabilities in stubdom.
Open the logfile on stubdom only after the 9pfs file system has been
mounted.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
Reviewed-by: Julien Grall
Add some helpers for handling filenames which might need different
implementations between stubdom and daemon environments:
- expansion of relative filenames (those are not really defined today,
just expand them to be relative to /var/lib/xen/xenstore)
- expansion of xenstore_daemon_rundir() (us
With 9pfs now available in Xenstore-stubdom, there is no reason to
have distinct do_control_memreport() variants for the daemon and the
stubdom implementations.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
---
tools/xenstored/control.c | 27 +++
1 file changed
On 29.02.2024 13:32, Julien Grall wrote:
> On 29/02/2024 12:17, Jan Beulich wrote:
>> On 29.02.2024 13:05, Andrew Cooper wrote:
>>> On 29/02/2024 10:23 am, Julien Grall wrote:
>>> IOW it is hard for me to see why RISC-V needs stronger restrictions
>>> here
>>> than other architectures.
On 29.02.2024 13:40, Roger Pau Monné wrote:
> On Thu, Feb 29, 2024 at 01:11:55PM +0100, Jan Beulich wrote:
>> On 29.02.2024 10:55, Roger Pau Monne wrote:
>>> --- a/README
>>> +++ b/README
>>> @@ -41,7 +41,7 @@ provided by your OS distributor:
>>> - GCC 4.1.2_20070115 or later
>>>
On 29.02.2024 13:48, Juergen Gross wrote:
> Update the Mini-OS upstream revision.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
On 29.02.2024 13:48, Juergen Gross wrote:
> Extend the config files of the Xenstore stubdoms to include XENBUS
> and 9PFRONT items in order to support file based logging.
>
> Signed-off-by: Juergen Gross
> Reviewed-by: Jason Andryuk
Was an ack from Samuel lost here? Or was it dropped on purpose
On 29.02.2024 14:01, Jan Beulich wrote:
> On 29.02.2024 13:40, Roger Pau Monné wrote:
>> On Thu, Feb 29, 2024 at 01:11:55PM +0100, Jan Beulich wrote:
>>> On 29.02.2024 10:55, Roger Pau Monne wrote:
--- a/README
+++ b/README
@@ -41,7 +41,7 @@ provided by your OS distributor:
On 29/02/2024 11:56 am, Roger Pau Monné wrote:
> On Thu, Feb 29, 2024 at 10:43:04AM +, Andrew Cooper wrote:
>> Right now, the host x2APIC setting filters into the PV max and default
>> policies, yet PV guests cannot set MSR_APIC_BASE.EXTD or access any of the
>> x2APIC MSR range. Therefore the
Currently vpci_deassign_device() is called without holding the per-domain
pci_lock in pci_remove_device(), which leads to:
Assertion 'rw_is_write_locked(&pdev->domain->pci_lock)' failed at
../drivers/vpci/vpci.c:47
[...]
Xen call trace:
[] R vpci_deassign_device+0x10d/0x1b9
[] S pci_remove_
On 29.02.2024 14:15, Roger Pau Monne wrote:
> Currently vpci_deassign_device() is called without holding the per-domain
> pci_lock in pci_remove_device(), which leads to:
>
> Assertion 'rw_is_write_locked(&pdev->domain->pci_lock)' failed at
> ../drivers/vpci/vpci.c:47
> [...]
> Xen call trace:
>
On 29/02/2024 12:47 pm, Jan Beulich wrote:
> On 29.02.2024 11:43, Andrew Cooper wrote:
>> Right now, the host x2APIC setting filters into the PV max and default
>> policies, yet PV guests cannot set MSR_APIC_BASE.EXTD or access any of the
>> x2APIC MSR range. Therefore they absolutely shouldn't se
flight 184811 xen-unstable real [real]
flight 184819 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184811/
http://logs.test-lab.xenproject.org/osstest/logs/184819/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armh
On 29.02.24 14:05, Jan Beulich wrote:
On 29.02.2024 13:48, Juergen Gross wrote:
Extend the config files of the Xenstore stubdoms to include XENBUS
and 9PFRONT items in order to support file based logging.
Signed-off-by: Juergen Gross
Reviewed-by: Jason Andryuk
Was an ack from Samuel lost he
On 29.02.2024 14:23, Andrew Cooper wrote:
> On 29/02/2024 12:47 pm, Jan Beulich wrote:
>> On 29.02.2024 11:43, Andrew Cooper wrote:
>>> Right now, the host x2APIC setting filters into the PV max and default
>>> policies, yet PV guests cannot set MSR_APIC_BASE.EXTD or access any of the
>>> x2APIC MS
Hi Jan,
On 29/02/2024 12:51, Jan Beulich wrote:
On 29.02.2024 13:32, Julien Grall wrote:
On 29/02/2024 12:17, Jan Beulich wrote:
On 29.02.2024 13:05, Andrew Cooper wrote:
On 29/02/2024 10:23 am, Julien Grall wrote:
IOW it is hard for me to see why RISC-V needs stronger restrictions
here
than
Hi Oleksii,
On 26/02/2024 17:38, Oleksii Kurochko wrote:
From the unpriviliged doc:
No standard hints are presently defined.
We anticipate standard hints to eventually include memory-system spatial
and temporal locality hints, branch prediction hints, thread-scheduling
hints, securi
On 12.12.2023 10:47, Juergen Gross wrote:
> In order to prepare a type-safe recursive spinlock structure, add
> explicitly non-recursive locking functions to be used for non-recursive
> locking of spinlocks, which are used recursively, too.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
Hi Oleksii,
On 26/02/2024 17:38, Oleksii Kurochko wrote:
These functions can be useful for architectures that don't
have corresponding arch-specific instructions.
Signed-off-by: Oleksii Kurochko
---
Changes in V5:
- new patch
---
xen/include/asm-generic/bitops/fls.h | 18 +
On 29.02.24 14:49, Jan Beulich wrote:
On 12.12.2023 10:47, Juergen Gross wrote:
In order to prepare a type-safe recursive spinlock structure, add
explicitly non-recursive locking functions to be used for non-recursive
locking of spinlocks, which are used recursively, too.
Signed-off-by: Juergen
On 12.12.2023 10:47, Juergen Gross wrote:
> @@ -377,25 +388,25 @@ void _spin_unlock_irqrestore(spinlock_t *lock, unsigned
> long flags)
> local_irq_restore(flags);
> }
>
> +static int always_inline spin_is_locked_common(const spinlock_tickets_t *t)
> +{
> +return t->head != t->tail;
>
On 29.02.2024 14:49, Julien Grall wrote:
> On 26/02/2024 17:38, Oleksii Kurochko wrote:
>> --- /dev/null
>> +++ b/xen/arch/riscv/include/asm/nospec.h
>> @@ -0,0 +1,25 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>
> New file should use the SPDX tag GPL-2.0-only. I guess this could be
> fixed on
On 2/29/24 08:23, Jan Beulich wrote:
> On 29.02.2024 14:15, Roger Pau Monne wrote:
>> Currently vpci_deassign_device() is called without holding the per-domain
>> pci_lock in pci_remove_device(), which leads to:
>>
>> Assertion 'rw_is_write_locked(&pdev->domain->pci_lock)' failed at
>> ../drivers/
On 29.02.2024 14:54, Julien Grall wrote:
> On 26/02/2024 17:38, Oleksii Kurochko wrote:
>> These functions can be useful for architectures that don't
>> have corresponding arch-specific instructions.
>>
>> Signed-off-by: Oleksii Kurochko
>> ---
>> Changes in V5:
>> - new patch
>> ---
>> xe
On 29.02.2024 14:44, Julien Grall wrote:
> Hi Jan,
>
> On 29/02/2024 12:51, Jan Beulich wrote:
>> On 29.02.2024 13:32, Julien Grall wrote:
>>> On 29/02/2024 12:17, Jan Beulich wrote:
On 29.02.2024 13:05, Andrew Cooper wrote:
> On 29/02/2024 10:23 am, Julien Grall wrote:
> IOW it i
Hi Jan,
On 29/02/2024 14:03, Jan Beulich wrote:
On 29.02.2024 14:54, Julien Grall wrote:
On 26/02/2024 17:38, Oleksii Kurochko wrote:
These functions can be useful for architectures that don't
have corresponding arch-specific instructions.
Signed-off-by: Oleksii Kurochko
---
Changes in V5
On 12.12.2023 10:47, Juergen Gross wrote:
> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -458,6 +458,23 @@ void _spin_barrier(spinlock_t *lock)
> spin_barrier_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
> }
>
> +int rspin_is_locked(const rspinlock_t *lock)
> +{
On 29/02/2024 14:07, Jan Beulich wrote:
On 29.02.2024 14:44, Julien Grall wrote:
Hi Jan,
On 29/02/2024 12:51, Jan Beulich wrote:
On 29.02.2024 13:32, Julien Grall wrote:
On 29/02/2024 12:17, Jan Beulich wrote:
On 29.02.2024 13:05, Andrew Cooper wrote:
On 29/02/2024 10:23 am, Julien Grall
On 29.02.24 15:14, Jan Beulich wrote:
On 12.12.2023 10:47, Juergen Gross wrote:
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -458,6 +458,23 @@ void _spin_barrier(spinlock_t *lock)
spin_barrier_common(&lock->tickets, &lock->debug, LOCK_PROFILE_PAR);
}
+int rspin_is_locked
On Thu, Feb 29, 2024 at 02:12:26PM +0100, Jan Beulich wrote:
> On 29.02.2024 14:01, Jan Beulich wrote:
> > On 29.02.2024 13:40, Roger Pau Monné wrote:
> >> On Thu, Feb 29, 2024 at 01:11:55PM +0100, Jan Beulich wrote:
> >>> On 29.02.2024 10:55, Roger Pau Monne wrote:
> --- a/README
> +++ b
On 29/02/2024 1:29 pm, Jan Beulich wrote:
> On 29.02.2024 14:23, Andrew Cooper wrote:
>> On 29/02/2024 12:47 pm, Jan Beulich wrote:
>>> On 29.02.2024 11:43, Andrew Cooper wrote:
Right now, the host x2APIC setting filters into the PV max and default
policies, yet PV guests cannot set MSR_A
On 29.02.2024 15:21, Roger Pau Monné wrote:
> On Thu, Feb 29, 2024 at 02:12:26PM +0100, Jan Beulich wrote:
>> Bah, that's not even Clang, only LLVM.
>
> I'm confused by this, doesn't your llvm package include clang?
No, there are quite a few RPMs in general in SLES to cover everything,
yet on the
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 safe with respect to expansions that
can possibly alter
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
way involved in violations, and the strategy adopted to
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 safe with respect to expansions that
can possibly alter
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 safe with respect to expansions that
can possibly alter
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 safe with respect to expansions that
can possibly alter
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 safe with respect to expansions that
can possibly alter
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 safe with respect to expansions that
can possibly alter
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 safe with respect to expansions that
can possibly alter
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore
the macro XEN_DEFINE_UUID_ should wrap its parameters in parentheses.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/include/public/xen.h | 2 +-
1 f
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 safe with respect to expansions that
can possibly alter
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 safe with respect to expansions that
can possibly alter
On 12.12.2023 10:47, Juergen Gross wrote:
> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -541,6 +541,55 @@ void rspin_unlock_irqrestore(rspinlock_t *lock, unsigned
> long flags)
> local_irq_restore(flags);
> }
>
> +int nrspin_trylock(rspinlock_t *lock)
> +{
> +check_l
On 12.12.2023 10:47, Juergen Gross wrote:
> In reality all spin_*() functions are macros which are defined to just
> call a related real function.
>
> Remove this macro layer, as it is adding complexity without any gain.
>
> Signed-off-by: Juergen Gross
Acked-by: Jan Beulich
with the same rema
On 29.02.24 16:32, Jan Beulich wrote:
On 12.12.2023 10:47, Juergen Gross wrote:
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -541,6 +541,55 @@ void rspin_unlock_irqrestore(rspinlock_t *lock, unsigned
long flags)
local_irq_restore(flags);
}
+int nrspin_trylock(rspinlock_
On 12.12.2023 10:47, Juergen Gross wrote:
> Allow 16 bits per cpu number, which is the limit imposed by
> spinlock_tickets_t.
>
> This will allow up to 65535 cpus, while increasing only the size of
> recursive spinlocks in debug builds from 8 to 12 bytes.
I think we want to be more conservative h
From: Kunwu Chan
[ Upstream commit 3693bb4465e6e32a204a5b86d3ec7e6b9f7e67c2 ]
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Signed-off-by: Kunwu Chan
Reported-by: kernel test
From: Kunwu Chan
[ Upstream commit 3693bb4465e6e32a204a5b86d3ec7e6b9f7e67c2 ]
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Signed-off-by: Kunwu Chan
Reported-by: kernel test
From: Kunwu Chan
[ Upstream commit 3693bb4465e6e32a204a5b86d3ec7e6b9f7e67c2 ]
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Signed-off-by: Kunwu Chan
Reported-by: kernel test
From: Kunwu Chan
[ Upstream commit 3693bb4465e6e32a204a5b86d3ec7e6b9f7e67c2 ]
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Signed-off-by: Kunwu Chan
Reported-by: kernel test
From: Kunwu Chan
[ Upstream commit 3693bb4465e6e32a204a5b86d3ec7e6b9f7e67c2 ]
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Signed-off-by: Kunwu Chan
Reported-by: kernel test
From: Kunwu Chan
[ Upstream commit 3693bb4465e6e32a204a5b86d3ec7e6b9f7e67c2 ]
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Signed-off-by: Kunwu Chan
Reported-by: kernel test
From: Kunwu Chan
[ Upstream commit 3693bb4465e6e32a204a5b86d3ec7e6b9f7e67c2 ]
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
Signed-off-by: Kunwu Chan
Reported-by: kernel test
On 26.02.2024 18:38, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/bitops/fls.h
> @@ -0,0 +1,18 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_GENERIC_BITOPS_FLS_H_
> +#define _ASM_GENERIC_BITOPS_FLS_H_
> +
> +/**
> + * fls - find last (most-significant) bit
On Tue, Feb 27, 2024 at 05:31:28PM -0800, Alexei Starovoitov wrote:
> What would it look like with a cookie?
> A static inline wrapper around get_vm_area() that returns area->addr ?
> And the start address of vmap range will be such a cookie?
Hmm, just making the kernel virtual address the cookie
On Thu, 2024-02-29 at 15:01 +0100, Jan Beulich wrote:
> On 29.02.2024 14:49, Julien Grall wrote:
> > On 26/02/2024 17:38, Oleksii Kurochko wrote:
> > > --- /dev/null
> > > +++ b/xen/arch/riscv/include/asm/nospec.h
> > > @@ -0,0 +1,25 @@
> > > +/* SPDX-License-Identifier: GPL-2.0 */
> >
> > New fil
On 29/02/2024 3:27 pm, Nicola Vetrini wrote:
> diff --git a/xen/include/xen/kconfig.h b/xen/include/xen/kconfig.h
> index c25dc0f6c2a9..b7e70289737b 100644
> --- a/xen/include/xen/kconfig.h
> +++ b/xen/include/xen/kconfig.h
> @@ -25,7 +25,7 @@
> #define __ARG_PLACEHOLDER_1 0,
> #define config_ena
Hi Julien,
On Thu, 2024-02-29 at 13:54 +, Julien Grall wrote:
> Hi Oleksii,
>
> On 26/02/2024 17:38, Oleksii Kurochko wrote:
> > These functions can be useful for architectures that don't
> > have corresponding arch-specific instructions.
> >
> > Signed-off-by: Oleksii Kurochko
> > ---
> >
On 2024-02-29 17:10, Andrew Cooper wrote:
On 29/02/2024 3:27 pm, Nicola Vetrini wrote:
diff --git a/xen/include/xen/kconfig.h b/xen/include/xen/kconfig.h
index c25dc0f6c2a9..b7e70289737b 100644
--- a/xen/include/xen/kconfig.h
+++ b/xen/include/xen/kconfig.h
@@ -25,7 +25,7 @@
#define __ARG_PLACE
On 29.02.2024 16:27, Nicola Vetrini wrote:
> --- a/xen/include/xen/kconfig.h
> +++ b/xen/include/xen/kconfig.h
> @@ -25,7 +25,7 @@
> #define __ARG_PLACEHOLDER_1 0,
> #define config_enabled(cfg) _config_enabled(cfg)
> #define _config_enabled(value) __config_enabled(__ARG_PLACEHOLDER_##value)
> -#
On 26/02/2024 5:38 pm, Oleksii Kurochko wrote:
> These functions can be useful for architectures that don't
> have corresponding arch-specific instructions.
>
> Signed-off-by: Oleksii Kurochko
> ---
> Changes in V5:
>- new patch
> ---
> xen/include/asm-generic/bitops/fls.h | 18
On 26.02.2024 18:38, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/nospec.h
> @@ -0,0 +1,25 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright (C) 2024 Vates */
> +
> +#ifndef _ASM_GENERIC_NOSPEC_H
> +#define _ASM_GENERIC_NOSPEC_H
Btw, at the very last second
1 - 100 of 153 matches
Mail list logo
