On 28.01.24 18:09, Markus Elfring wrote:
From: Markus Elfring
Date: Sun, 28 Jan 2024 17:50:43 +0100
* The function “memdup_array_user” was added with the
commit 313ebe47d75558511aa1237b6e35c663b5c0ec6f ("string.h: add
array-wrappers for (v)memdup_user()").
Thus use it accordingly.
On 13.02.2024 04:43, Marek Marczykowski wrote:
> On Mon, Feb 12, 2024 at 10:04:38AM +0100, Jan Beulich wrote:
>> On 08.02.2024 23:00, Julien Grall wrote:
>>> On 05/02/2024 13:27, Jan Beulich wrote:
In preparation of dropping the register parameters from
serial_[rt]x_interrupt() and in
On 13.02.2024 00:18, Stefano Stabellini wrote:
> On Mon, 12 Feb 2024, Jan Beulich wrote:
>> On 10.02.2024 02:00, Stefano Stabellini wrote:
>>> Update docs/misra/rules.rst to reflect the MISRA C rules accepted in the
>>> last couple of months.
>>>
>>> Signed-off-by: Stefano Stabellini
>>> ---
>>>
On 12.02.2024 19:38, Julien Grall wrote:
> An alternative would be to introduced arch_grant_cache_flush() and move
> the if/else logic there. Something like:
>
> diff --git a/xen/arch/arm/include/asm/page.h
> b/xen/arch/arm/include/asm/page.h
> index 69f817d1e68a..4a3de49762a1 100644
> ---
Hi,
On 2/12/24 18:43, Andrew Cooper wrote:
> On 12/02/2024 5:27 pm, zithro wrote:
>> Hey all,
>>
>> the Debian project is focused on the "2038 time_t" switch.
>> So the maintainers of the Debian Xen package must ensure that all
>> imported Xen code conforms to the new Debian standards.
>>
>> I
flight 184653 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184653/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184648
On Mon, Feb 12, 2024 at 10:04:38AM +0100, Jan Beulich wrote:
> On 08.02.2024 23:00, Julien Grall wrote:
> > On 05/02/2024 13:27, Jan Beulich wrote:
> >> In preparation of dropping the register parameters from
> >> serial_[rt]x_interrupt() and in turn from IRQ handler functions,
> >> register state
flight 184652 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184652/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 184649
test-amd64-amd64-xl-qemuu-win7-amd64
Hi Daniil,
Against which Linux branch was this patch generated?
Cheers,
Stefano
On Sun, 11 Feb 2024, Daniil Dulov wrote:
> In this case hwdev cannot be NULL, so remove redundant NULL check.
>
> Found by Linux Verification Center (linuxtesting.org) with SVACE.
>
> Fixes: b097186fd29d
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 original observation features MD-RAID1 using a pair of Samsung
> SATA-attached
On Mon, 12 Feb 2024, Jan Beulich wrote:
> On 10.02.2024 02:00, Stefano Stabellini wrote:
> > Update docs/misra/rules.rst to reflect the MISRA C rules accepted in the
> > last couple of months.
> >
> > Signed-off-by: Stefano Stabellini
> > ---
> >
> > In the notes section I added some info about
Hi all,
As we continue our journey toward Xen Safety Certifiability, one of the
next challenges is safety requirements and their traceability. We need
to be able to link high level requirements documents to mid and low
level requirements documents, to test specifications and to gitlab
tests.
flight 184651 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184651/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-xtf-amd64-amd64-3 broken
test-xtf-amd64-amd64-35
On Mon, Feb 12, 2024 at 10:13:28AM +0100, Roger Pau Monné wrote:
> On Fri, Feb 09, 2024 at 03:05:49PM -0600, Bjorn Helgaas wrote:
> > On Thu, Feb 01, 2024 at 09:39:49AM +0100, Roger Pau Monné wrote:
> > > On Wed, Jan 31, 2024 at 01:00:14PM -0600, Bjorn Helgaas wrote:
> > > > On Wed, Jan 31, 2024
Hi Nicola,
On 12/02/2024 14:56, Nicola Vetrini wrote:
On 2024-02-12 09:26, Jan Beulich wrote:
On 10.02.2024 11:17, Julien Grall wrote:
Hi,
On 09/02/2024 22:02, Stefano Stabellini wrote:
On Fri, 9 Feb 2024, Nicola Vetrini wrote:
Hi all,
In the context of violations of MISRA C:2012 Rule
On 12/02/2024 5:27 pm, zithro wrote:
> Hey all,
>
> the Debian project is focused on the "2038 time_t" switch.
> So the maintainers of the Debian Xen package must ensure that all
> imported Xen code conforms to the new Debian standards.
>
> I was asked by Andrew Cooper to post here about this,
Hey all,
the Debian project is focused on the "2038 time_t" switch.
So the maintainers of the Debian Xen package must ensure that all
imported Xen code conforms to the new Debian standards.
I was asked by Andrew Cooper to post here about this, I'll quote him :
"So I had been idly wondering
On 19.01.24 10:49, Kunwu Chan wrote:
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 robot
Closes:
On 12.02.2024 16:38, Roger Pau Monné wrote:
> On Mon, Feb 12, 2024 at 11:45:33AM +0100, Jan Beulich wrote:
>> On 12.02.2024 10:39, Roger Pau Monné wrote:
>>> On Thu, Feb 08, 2024 at 04:49:46PM +0100, Jan Beulich wrote:
On 08.02.2024 12:49, Roger Pau Monné wrote:
> On Mon, Feb 05, 2024 at
On 05.02.2024 16:32, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/bitops.h
> @@ -0,0 +1,164 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/* Copyright (C) 2012 Regents of the University of California */
> +
> +#ifndef _ASM_RISCV_BITOPS_H
> +#define
On Mon, Feb 12, 2024 at 11:45:33AM +0100, Jan Beulich wrote:
> On 12.02.2024 10:39, Roger Pau Monné wrote:
> > On Thu, Feb 08, 2024 at 04:49:46PM +0100, Jan Beulich wrote:
> >> On 08.02.2024 12:49, Roger Pau Monné wrote:
> >>> On Mon, Feb 05, 2024 at 02:55:43PM +0100, Jan Beulich wrote:
>
On 12.01.24 19:59, SeongJae Park wrote:
Commit 2e85d32b1c86 ("xen/xenbus: Add 'will_handle' callback support in
xenbus_watch_path()") added will_handle argument to xenbus_watch_path()
and its wrapper, xenbus_watch_pathfmt(), but didn't document it on the
kerneldoc comments of the function. This
On 05.02.2024 16:32, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/early_printk.c
> +++ b/xen/arch/riscv/early_printk.c
> @@ -207,4 +207,3 @@ void printk(const char *format, ...)
> }
>
> #endif
> -
Unrelated change?
> --- a/xen/arch/riscv/traps.c
> +++ b/xen/arch/riscv/traps.c
> @@ -4,6
On 05.02.2024 16:32, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
again with a nit, though:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/event.h
> @@ -0,0 +1,40 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_RISCV_EVENT_H__
>
On 05.02.2024 16:32, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
> Acked-by: Jan Beulich
Nevertheless ...
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/time.h
> @@ -0,0 +1,29 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_RISCV_TIME_H__
> +#define
On 05.02.2024 16:32, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
with two more nits:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/p2m.h
> @@ -0,0 +1,102 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_RISCV_P2M_H__
> +#define
On 05.02.2024 16:32, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
On 05.02.2024 16:32, Oleksii Kurochko wrote:
> asm/iommu.h shouldn't
... need to ...
> be included when CONFIG_HAS_PASSTHROUGH
> isn't enabled.
> As is ifdef-ed by CONFIG_HAS_PASSTHROUGH it should
> be also ifdef-ed field "struct arch_iommu arch" in struct domain_iommu
> as definition of
On 05.02.2024 16:32, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
On 05.02.2024 16:32, Oleksii Kurochko wrote:
> No specific header is needed to include in public/hvm/save.h for
> PPC and RISC-V for now.
>
> Code related to PPC was changed based on the comment:
> https://lore.kernel.org/xen-devel/c2f3280e-2208-496b-a0b5-fda1a2076...@raptorengineering.com/
>
>
On 05.02.2024 16:32, Oleksii Kurochko wrote:
> Some headers are the same as asm-generic verions of them
> so use them instead of arch-specific headers.
Just to mention it (I'll commit this as is, unless asked to do otherwise):
With this description I'd expect those "some headers" to be removed by
On 2024-02-12 09:26, Jan Beulich wrote:
On 10.02.2024 11:17, Julien Grall wrote:
Hi,
On 09/02/2024 22:02, Stefano Stabellini wrote:
On Fri, 9 Feb 2024, Nicola Vetrini wrote:
Hi all,
In the context of violations of MISRA C:2012 Rule 17.7: "The value
returned by
a function having non-void
On 07.02.2024 16:34, Roger Pau Monne wrote:
> Use the newly introduced generic unity map checker.
>
> Also drop the message recommending the usage of iommu_inclusive_mapping: the
> ranges would end up being mapped anyway even if some of the checks above
> failed, regardless of whether
On 07.02.2024 16:34, Roger Pau Monne wrote:
> IVMD and RMRR ranges are functionally equivalent, and as so could use the same
> validity checker.
>
> Move the IVMD to x86 common IOMMU code and adjust the function to take a pair
> of [start, end] mfn parameters.
>
> So far only the AMD-Vi side is
flight 184649 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184649/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemut-win7-amd64 19 guest-stopfail like 184647
test-amd64-amd64-xl-qemuu-win7-amd64
On 07.02.2024 04:07, George Dunlap wrote:
> On Thu, Feb 1, 2024 at 10:15 PM Jan Beulich wrote:
> --- a/xen/arch/x86/mm/p2m.c
> +++ b/xen/arch/x86/mm/p2m.c
> @@ -379,7 +379,7 @@ struct page_info *p2m_get_page_from_gfn(
> return page;
> =20
> /* Error path: not a suitable GFN
On 09.02.2024 19:00, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/include/asm-generic/device.h
> @@ -0,0 +1,149 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +#ifndef __ASM_GENERIC_DEVICE_H__
> +#define __ASM_GENERIC_DEVICE_H__
> +
> +#include
> +
> +enum device_type
> +{
> +#ifdef
On 09.02.2024 18:58, Oleksii Kurochko wrote:
> find-next-bit.c is common for Arm64, PPC and RISCV64,
> so it is moved to xen/lib.
>
> PPC has been transitioned to generic functions from find-next-bit.c
> since it now shares the same implementation as the PPC-specific code.
>
> The MISRA exclude
On 09.02.2024 12:40, Roger Pau Monne wrote:
> @@ -1378,6 +1379,10 @@ static int construct_vmcs(struct vcpu *v)
> rc = vmx_add_msr(v, MSR_PRED_CMD, PRED_CMD_IBPB,
> VMX_MSR_HOST);
>
> +/* Set any bits we don't allow toggling in the mask field. */
> +if (
Move logic independent of c->apicid's initialization status out of
the if/else, leveraging that cpu_data[] now doesn't start out zero-
initialized. Constify c and have it have an initializer.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/cpu/mcheck/mce.c
+++ b/xen/arch/x86/cpu/mcheck/mce.c
@@
Forever since its introduction x86_mc_get_cpu_info() has been checking a
structure field against BAD_APICID which would never have been set to
that particular value. Arrange for this to actually be true ahead of
CPU detection having run, which then also includes pruning after CPU
removal.
For
Kind of fallout from looking through the AP bringup acceleration series.
1: CPU: re-work populating of cpu_data[]
2: MCE: adjust x86_mc_get_cpu_info()
Jan
Hi Jens,
> On 5 Feb 2024, at 16:49, Jens Wiklander wrote:
>
> When an FF-A enabled guest is destroyed it may leave behind memory
> shared with SPs. This memory must be reclaimed before it's reused or an
> SP may make changes to memory used by a new unrelated guest. So when the
> domain is
flight 184650 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184650/
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
On 08.02.2024 13:42, Roger Pau Monné wrote:
> On Mon, Feb 05, 2024 at 02:56:14PM +0100, Jan Beulich wrote:
>> When the flag is set, permit Dom0 to control the device (no worse than
>> what we had before and in line with other "best effort" behavior we use
>> when it comes to Dom0), but suppress
On Thu, Feb 01, 2024 at 01:30:20PM -0500, Jason Andryuk wrote:
> This patch re-introduces blktap support to libxl. Unlike earlier
> versions, it does not link against any blktap library. libxl changes
> are needed to write to the vbd3 backend XenStore nodes.
>
> blktap has three components.
On 12.02.2024 10:39, Roger Pau Monné wrote:
> On Thu, Feb 08, 2024 at 04:49:46PM +0100, Jan Beulich wrote:
>> On 08.02.2024 12:49, Roger Pau Monné wrote:
>>> On Mon, Feb 05, 2024 at 02:55:43PM +0100, Jan Beulich wrote:
Make the variable a tristate, with (as done elsewhere) a negative value
On Thu, Feb 01, 2024 at 01:30:24PM -0500, Jason Andryuk wrote:
> diff --git a/tools/libs/light/libxl_disk.c b/tools/libs/light/libxl_disk.c
> @@ -1337,10 +1338,18 @@ char *libxl__device_disk_find_local_path(libxl__gc
> *gc,
> LOGD(DEBUG, guest_domid, "Attempting to read node %s",
On Thu, Feb 01, 2024 at 01:30:23PM -0500, Jason Andryuk wrote:
> Implement a sharing check like the regular block script.
>
> Checking tapback inside block-tap is too late since it needs to be
> running to transition the backend to InitWait before block-tap is run.
>
> tap-ctl check will be
On Thu, Feb 01, 2024 at 01:30:22PM -0500, Jason Andryuk wrote:
> This patch re-introduces blktap support to libxl. Unlike earlier
> versions, it does not link against any blktap library. libxl changes
> are needed to write to the vbd3 backend XenStore nodes.
>
> blktap has three components.
On Mon, Feb 12, 2024 at 10:46:55AM +0100, Jan Beulich wrote:
> On 09.02.2024 09:39, Roger Pau Monné wrote:
> > On Mon, Feb 05, 2024 at 02:57:30PM +0100, Jan Beulich wrote:
> >> ..., thus allowing them to become static. There's nothing x86-specific
> >> about these functions anyway.
> >>
> >> Since
On Mon, Feb 12, 2024 at 10:32:00AM +0100, Jan Beulich wrote:
> On 09.02.2024 10:00, Roger Pau Monné wrote:
> > On Thu, Feb 08, 2024 at 04:29:34PM +0100, Jan Beulich wrote:
> >> On 08.02.2024 10:17, Roger Pau Monné wrote:
> >>> On Mon, Feb 05, 2024 at 02:55:17PM +0100, Jan Beulich wrote:
> +
On Mon, 2024-02-12 at 09:39 +0100, Michal Orzel wrote:
> Hi Oleksii,
Hi Michal,
>
> On 09/02/2024 19:00, Oleksii Kurochko wrote:
> >
> >
> > This patch introduces the file riscv-fixed-randconfig.yaml,
> > which includes all configurations that should be disabled for
> > randconfig builds.
> >
On 09.02.2024 09:39, Roger Pau Monné wrote:
> On Mon, Feb 05, 2024 at 02:57:30PM +0100, Jan Beulich wrote:
>> ..., thus allowing them to become static. There's nothing x86-specific
>> about these functions anyway.
>>
>> Since only the "iommu_inclusive_mapping" parameter declaration would be
>>
On Mon, 2024-02-12 at 09:12 +0100, Michal Orzel wrote:
> Hi Oleksii,
Hi Michal,
>
> On 09/02/2024 19:00, Oleksii Kurochko wrote:
> >
> >
> > Kconfig tool expects each configuration to be on a new line.
> >
> > The current version of the build script puts all of
> > ${EXTRA_FIXED_RANDCONFIG}
>
On Thu, Feb 08, 2024 at 04:49:46PM +0100, Jan Beulich wrote:
> On 08.02.2024 12:49, Roger Pau Monné wrote:
> > On Mon, Feb 05, 2024 at 02:55:43PM +0100, Jan Beulich wrote:
> >> Make the variable a tristate, with (as done elsewhere) a negative value
> >> meaning "default". Since all use sites need
On 09.02.2024 10:00, Roger Pau Monné wrote:
> On Thu, Feb 08, 2024 at 04:29:34PM +0100, Jan Beulich wrote:
>> On 08.02.2024 10:17, Roger Pau Monné wrote:
>>> On Mon, Feb 05, 2024 at 02:55:17PM +0100, Jan Beulich wrote:
+{
+dprintk(XENLOG_WARNING VTDPREFIX,
+
flight 184648 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184648/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184645
A customer is complaining to be unable to create multiple "channel" devices
in a HVM domain. I've verified the same happens with upstream Xen.
The "channel" configuration is:
channel = [ "connection=socket, name=test.ch1, path=/run/testsocket1",
"connection=socket, name=test.ch2,
On 08.02.2024 23:09, Julien Grall wrote:
> On 05/02/2024 13:28, Jan Beulich wrote:
>> In preparation for further removal of regs parameters, drop it here. In
>> the two places where it's actually needed, retrieve IRQ context if
>> available, or else guest context.
>>
>> Suggested-by: Andrew Cooper
On Fri, Feb 09, 2024 at 03:05:49PM -0600, Bjorn Helgaas wrote:
> On Thu, Feb 01, 2024 at 09:39:49AM +0100, Roger Pau Monné wrote:
> > On Wed, Jan 31, 2024 at 01:00:14PM -0600, Bjorn Helgaas wrote:
> > > On Wed, Jan 31, 2024 at 09:58:19AM +0100, Roger Pau Monné wrote:
> > > > On Tue, Jan 30, 2024
On 08.02.2024 23:00, Julien Grall wrote:
> On 05/02/2024 13:27, Jan Beulich wrote:
>> In preparation of dropping the register parameters from
>> serial_[rt]x_interrupt() and in turn from IRQ handler functions,
>> register state needs making available another way for the few key
>> handlers which
On 09.02.2024 10:50, Federico Serafini wrote:
> On 08/02/24 12:14, Jan Beulich wrote:
>> On 08.02.2024 11:45, Federico Serafini wrote:
>>> On 07/02/24 17:19, Jan Beulich wrote:
On 07.02.2024 16:58, Federico Serafini wrote:
> On 07/02/24 16:24, Jan Beulich wrote:
>> On 07.02.2024
Hi Oleksii,
On 09/02/2024 19:00, Oleksii Kurochko wrote:
>
>
> This patch introduces the file riscv-fixed-randconfig.yaml,
> which includes all configurations that should be disabled for
> randconfig builds.
>
> Suggested-by: Stefano Stabellini
> Signed-off-by: Oleksii Kurochko
> ---
> The
On 10.02.2024 11:17, Julien Grall wrote:
> Hi,
>
> On 09/02/2024 22:02, Stefano Stabellini wrote:
>> On Fri, 9 Feb 2024, Nicola Vetrini wrote:
>>> Hi all,
>>>
>>> In the context of violations of MISRA C:2012 Rule 17.7: "The value returned
>>> by
>>> a function having non-void return type shall
On 10.02.2024 02:00, Stefano Stabellini wrote:
> Update docs/misra/rules.rst to reflect the MISRA C rules accepted in the
> last couple of months.
>
> Signed-off-by: Stefano Stabellini
> ---
>
> In the notes section I added some info about the deviations, but in any
> case the appropriate info
Hi Oleksii,
On 09/02/2024 19:00, Oleksii Kurochko wrote:
>
>
> Kconfig tool expects each configuration to be on a new line.
>
> The current version of the build script puts all of ${EXTRA_FIXED_RANDCONFIG}
> in a single line and configs are seperated by spaces.
>
> As a result, only the first
67 matches
Mail list logo
