flight 184660 xen-unstable real [real]
flight 184664 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184660/
http://logs.test-lab.xenproject.org/osstest/logs/184664/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
Hi,
On 07/02/2024 15:55, Roger Pau Monne wrote:
>
>
> And use it to replace CODE_ALIGN in assembly. This allows to generalize the
> way the code alignment gets set across all architectures.
>
> No functional change intended.
>
> Signed-off-by: Roger Pau Monné
In xen/linkage.h, there is still
On 13.02.2024 23:33, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini
> ---
> docs/misra/rules.rst | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
> index c185366966..931158b354 100644
> --- a/docs/misra/rules.rst
> +++ b/do
On Wed, Feb 14, 2024 at 08:45:28AM +0100, Jan Beulich wrote:
> On 13.02.2024 23:37, Andrew Cooper wrote:
> > On 12/02/2024 2:38 pm, Jan Beulich wrote:
> >> On 07.02.2024 16:34, Roger Pau Monne wrote:
> >>> Use the newly introduced generic unity map checker.
> >>>
> >>> Also drop the message recomme
On 14/02/2024 8:45 am, Roger Pau Monné wrote:
> On Wed, Feb 14, 2024 at 08:45:28AM +0100, Jan Beulich wrote:
>> On 13.02.2024 23:37, Andrew Cooper wrote:
>>> On 12/02/2024 2:38 pm, Jan Beulich wrote:
On 07.02.2024 16:34, Roger Pau Monne wrote:
> Use the newly introduced generic unity map c
On 14.02.2024 09:45, Roger Pau Monné wrote:
> On Wed, Feb 14, 2024 at 08:45:28AM +0100, Jan Beulich wrote:
>> On 13.02.2024 23:37, Andrew Cooper wrote:
>>> It's very likely something in this series, but the link to Intel might
>>> just be chance of which hardware got selected, and I've got no clue
On 13.02.2024 17:58, Stewart Hildebrand wrote:
> On 2/13/24 04:05, Jan Beulich wrote:
>> On 13.02.2024 10:01, Roger Pau Monné wrote:
>>> On Tue, Feb 13, 2024 at 09:44:58AM +0100, Jan Beulich wrote:
On 13.02.2024 09:35, Roger Pau Monné wrote:
> On Fri, Feb 02, 2024 at 04:33:05PM -0500, Stew
Hi Julien,
> On 13/02/2024 17:40, Julien Grall wrote:
> > Hi Oleksii,
> >
> > On 09/02/2024 18:00, Oleksii Kurochko wrote:
> > > The header is shared between several archs so it is
> > > moved to asm-generic.
> > >
> > > Switch partly Arm and PPC to asm-generic/monitor.h and only
> > > arch_mo
On Mon, 2024-02-12 at 15:19 +0100, Jan Beulich wrote:
> 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_D
On Wed, Feb 14, 2024 at 10:01:43AM +0100, Jan Beulich wrote:
> On 14.02.2024 09:45, Roger Pau Monné wrote:
> > On Wed, Feb 14, 2024 at 08:45:28AM +0100, Jan Beulich wrote:
> >> On 13.02.2024 23:37, Andrew Cooper wrote:
> >>> It's very likely something in this series, but the link to Intel might
> >
On Wed, Feb 14, 2024 at 09:00:25AM +, Andrew Cooper wrote:
> On 14/02/2024 8:45 am, Roger Pau Monné wrote:
> > On Wed, Feb 14, 2024 at 08:45:28AM +0100, Jan Beulich wrote:
> >> On 13.02.2024 23:37, Andrew Cooper wrote:
> >>> On 12/02/2024 2:38 pm, Jan Beulich wrote:
> On 07.02.2024 16:34,
On Tue, 2024-02-13 at 18:09 +, Julien Grall wrote:
> Hi Oleksii,
>
> On 09/02/2024 18:00, Oleksii Kurochko wrote:
> > diff --git a/xen/include/asm-generic/device.h b/xen/include/asm-
> > generic/device.h
> > new file mode 100644
> > index 00..6e56658271
> > --- /dev/null
> > +++ b/xen/
flight 184662 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184662/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184655
test-armhf-armhf-libvirt-qcow2 15 saveres
Hi Julien,
On Tue, 2024-02-13 at 18:12 +, Julien Grall wrote:
> Hi Oleksii,
>
> On 09/02/2024 18:00, Oleksii Kurochko wrote:
> > The following changes were done as a result of switching to
> > asm-generic/device.h:
> > * DEVICE_GIC was renamed to DEVICE_INTERRUPT_CONTROLLER according
> >
On Mon, 2024-02-12 at 15:15 +0100, Jan Beulich wrote:
> 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
Hi Julien,
On Tue, 2024-02-13 at 17:18 +, Julien Grall wrote:
> Hi Oleksii,
>
> On 09/02/2024 17: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
>
Make clear they are not changed in the functions.
Signed-off-by: Frediano Ziglio
Reviewed-by: Jan Beulich
--
v2:
- fixed typo in commit message.
---
xen/arch/x86/pv/callback.c | 4 ++--
xen/common/sched/compat.c | 2 +-
xen/common/sched/core.c| 2 +-
xen/xsm/flask/flask_op.c | 8
On 05.02.2024 16:32, Oleksii Kurochko wrote:
> Signed-off-by: Oleksii Kurochko
> ---
> Changes in V4:
> - Update version of GCC (12.2) and GNU Binutils (2.39) to the version
> which are in Xen's contrainter for RISC-V
> ---
> Changes in V3:
> - new patch
> ---
> README | 3 +++
> 1 file
On Mon, 2024-02-12 at 16:03 +0100, Jan Beulich wrote:
> 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):
> Wit
On Mon, 2024-02-12 at 16:05 +0100, Jan Beulich wrote:
> 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/
On Mon, 2024-02-12 at 16:07 +0100, Jan Beulich wrote:
> On 05.02.2024 16:32, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
>
> Acked-by: Jan Beulich
Thanks!
~ Oleksii
On 14.02.2024 10:54, Oleksii wrote:
> On Mon, 2024-02-12 at 16:03 +0100, Jan Beulich wrote:
>> On 05.02.2024 16:32, Oleksii Kurochko wrote:
>>> As [PATCH v6 0/9] Introduce generic headers
>>> (
>>> https://lore.kernel.org/xen-devel/cover.1703072575.git.oleksii.kuroc...@gmail.com
>>> /)
>>> is no
On Mon, 2024-02-12 at 16:10 +0100, Jan Beulich wrote:
> 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 "s
On 14/02/2024 8:45 am, Roger Pau Monné wrote:
> I've found it:
>
> for ( addr = start; mfn_x(addr) <= mfn_x(end); mfn_add(addr, 1) )
>
> Should be:
>
> for ( addr = start; mfn_x(addr) <= mfn_x(end); addr = mfn_add(addr, 1) )
Coverity did end up spotting this.
> New defect(s) Reported-by:
find_ring_mfn() already holds a page reference when trying to obtain a
writable type reference. We shouldn't make assumptions on the general
reference count limit being effectively "infinity". Obtain merely a type
ref, re-using the general ref by only dropping the previously acquired
one in the cas
Hi Carlo,
On 29/01/2024 18:17, Carlo Nonato wrote:
>
>
> LLC coloring needs to know the last level cache layout in order to make the
> best use of it. This can be probed by inspecting the CLIDR_EL1 register,
> so the Last Level is defined as the last level visible by this register.
> Note that t
... if available only, of course.
Signed-off-by: Jan Beulich
---
I don't really like issuing an IPI (and having another cf_check
function) here, yet then again this is issued only when the debug key
is actually used, and given how simple the handling function is
(including that it doesn't use its
On 13.02.24 19:03, Anthony PERARD wrote:
On Thu, Feb 08, 2024 at 05:55:39PM +0100, Juergen Gross wrote:
+struct libxl__aop9_state {
+libxl__spawn_state spawn;
+libxl__ao_device *aodev;
+libxl_device_p9 p9;
+uint32_t domid;
+void (*callback)(libxl__egc *, libxl__aop9_state *,
We just pushed a 8-bytes zero and exception constants are
small so we can just write a single byte saving 3 bytes for
instruction.
With ENDBR64 this reduces the size of many entry points from 32 to
16 bytes (due to alignment).
Similar code is already used in autogen_stubs.
Signed-off-by: Frediano
On Mon, 2024-02-12 at 16:58 +0100, Jan Beulich wrote:
> 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 *
On Mon, 2024-02-12 at 16:13 +0100, Jan Beulich wrote:
> On 05.02.2024 16:32, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
>
> Acked-by: Jan Beulich
Thanks for Ack.
~ Oleksii
From: Bui Quang Minh
This commit adds support for x2APIC transitions when writing to
MSR_IA32_APICBASE register and finally adds CPUID_EXT_X2APIC to
TCG_EXT_FEATURES.
The set_base in APICCommonClass now returns an integer to indicate error in
execution. apic_set_base return -1 on invalid APIC st
On 14.02.2024 12:06, Oleksii wrote:
> On Mon, 2024-02-12 at 16:58 +0100, Jan Beulich wrote:
>> On 05.02.2024 16:32, Oleksii Kurochko wrote:
>>> +({ \
>>> + unsigned long __res, __mask; \
>>
>> Leftover leading underscore
Certain macros are allowed to violate the Rule, since their meaning and
intended use is well-known to all Xen developers.
Variadic macros that rely on the GCC extension for removing a trailing
comma when token pasting the variable argument are similarly
well-understood and therefore allowed.
No f
On 14/02/24 09:28, Jan Beulich wrote:
On 13.02.2024 23:33, Stefano Stabellini wrote:
Signed-off-by: Stefano Stabellini
---
docs/misra/rules.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index c185366966..931158b354 100644
--- a/docs
On Wed, Feb 14, 2024 at 8:12 AM Jan Beulich wrote:
>
> On 08.02.2024 10:13, Christian Lindig wrote:
> >> On 7 Feb 2024, at 22:04, Petr Beneš wrote:
> >> Add the missing `vmtrace_buf_kb` field to the OCaml bindings to match the
> >> vm.cfg configuration, correcting an oversight from its initial
>
On Tue, 2024-02-13 at 12:05 +0100, Jan Beulich wrote:
> On 05.02.2024 16:32, Oleksii Kurochko wrote:
> > The header taken form Linux 6.4.0-rc1 and is based on
> > arch/riscv/include/asm/mmio.h.
> >
> > Addionally, to the header was added definions of ioremap_*().
> >
> > Signed-off-by: Oleksii Ku
On 02.02.2024 22:33, Stewart Hildebrand wrote:
> --- a/xen/arch/x86/physdev.c
> +++ b/xen/arch/x86/physdev.c
> @@ -123,7 +123,9 @@ int physdev_map_pirq(domid_t domid, int type, int *index,
> int *pirq_p,
>
> case MAP_PIRQ_TYPE_MSI:
> case MAP_PIRQ_TYPE_MULTI_MSI:
> +pcidevs_loc
mfn_add() doesn't store the incremented value in the parameter, and instead
returns it to the caller. As a result, the loop in iommu_unity_region_ok()
didn't make progress. Fix it by storing the incremented value.
Fixes: e45801dea17b ('iommu/x86: introduce a generic IVMD/RMRR range validity
hel
Adjust the code in the checker to use full addresses rather than frame numbers,
as it's only page_get_ram_type() that requires an mfn parameter.
Suggested-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
xen/drivers/passthrough/x86/iommu.c | 23 ++-
1 file changed, 10 in
It's not obvious from the function itself whether the incremented value will be
stored in the parameter, or returned to the caller. That has leads to bugs in
the past as callers assume the incremented value is stored in the parameter.
Add the __must_check attribute to the function to easily spot
It's easier to correlate with the physical memory map if the addresses are
fully printed, instead of using frame numbers.
Requested-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
xen/drivers/passthrough/x86/iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xe
Hello,
First patch is a fix for a silly mistake I introduced in
iommu_unity_region_ok(). The rest are additional chances requested in
that context. Last patch adds __must_check to the gfn/mfn addition
handlers.
Thanks, Roger.
Roger Pau Monne (5):
iommu/x86: fix IVMD/RMRR range checker loop i
Provide more information in case the page can't be converted, and print the
original type(s).
Requested-by: Andrew Cooper
Signed-off-by: Roger Pau Monné
---
xen/drivers/passthrough/x86/iommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/drivers/passthrough/x86/io
On 14/02/2024 7:11 am, Jan Beulich wrote:
> On 08.02.2024 10:13, Christian Lindig wrote:
>>> On 7 Feb 2024, at 22:04, Petr Beneš wrote:
>>> Add the missing `vmtrace_buf_kb` field to the OCaml bindings to match the
>>> vm.cfg configuration, correcting an oversight from its initial introduction.
>>>
On 14.02.2024 12:26, Nicola Vetrini wrote:
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -387,6 +387,16 @@ in assignments."
> {safe, "left_right(^[(,\\[]$,^[),\\]]$)"}
> -doc_end
>
> +-doc_begin="The token pasting in varia
On 14.02.2024 11:37, Roger Pau Monne wrote:
> mfn_add() doesn't store the incremented value in the parameter, and instead
> returns it to the caller. As a result, the loop in iommu_unity_region_ok()
> didn't make progress. Fix it by storing the incremented value.
>
> Fixes: e45801dea17b ('iommu/
Hi,
On 14/02/2024 10:37, Roger Pau Monne wrote:
It's not obvious from the function itself whether the incremented value will be
stored in the parameter, or returned to the caller. That has leads to bugs in
the past as callers assume the incremented value is stored in the parameter.
Add the __m
On Wed, Feb 14, 2024 at 12:51:36PM +0100, Jan Beulich wrote:
> On 14.02.2024 11:37, Roger Pau Monne wrote:
> > mfn_add() doesn't store the incremented value in the parameter, and instead
> > returns it to the caller. As a result, the loop in iommu_unity_region_ok()
> > didn't make progress. Fix i
Hi Oleksii,
On 14/02/2024 09:32, Oleksii wrote:
On Tue, 2024-02-13 at 18:09 +, Julien Grall wrote:
+#ifdef CONFIG_HAS_PASSTHROUGH
+ struct iommu_fwspec *iommu_fwspec; /* per-device IOMMU
instance data */
+#endif
+};
+
+typedef struct device device_t;
+
+#ifdef CONFIG_HAS_DEVICE_TREE
+
On Tue, 2024-02-13 at 12:36 +0100, Jan Beulich wrote:
> On 05.02.2024 16:32, Oleksii Kurochko wrote:
> > From: Bobby Eshleman
> >
> > Additionally, this patch introduces macros in fence.h,
> > which are utilized in atomic.h.
>
> These are used in an earlier patch already, so either you want to
>
On Mon, 2024-02-12 at 16:16 +0100, Jan Beulich wrote:
> 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-Iden
On Mon, 2024-02-12 at 16:18 +0100, Jan Beulich wrote:
> 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-Ident
On Mon, 2024-02-12 at 16:20 +0100, Jan Beulich wrote:
> 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-Licen
On Wed, 2024-02-14 at 10:52 +0100, Jan Beulich wrote:
> On 05.02.2024 16:32, Oleksii Kurochko wrote:
> > Signed-off-by: Oleksii Kurochko
> > ---
> > Changes in V4:
> > - Update version of GCC (12.2) and GNU Binutils (2.39) to the
> > version
> > which are in Xen's contrainter for RISC-V
> >
On 14.02.2024 13:42, GitLab wrote:
>
>
> Pipeline #1176167215 has failed!
>
> Project: xen ( https://gitlab.com/xen-project/xen )
> Branch: staging ( https://gitlab.com/xen-project/xen/-/commits/staging )
>
> Commit: d670c1a3 (
> https://gitlab.com/xen-project/xen/-/commit/d670c1a38ba3561296f6
On 14.02.2024 13:21, Oleksii wrote:
> On Wed, 2024-02-14 at 10:52 +0100, Jan Beulich wrote:
>> On 05.02.2024 16:32, Oleksii Kurochko wrote:
>>> Signed-off-by: Oleksii Kurochko
>>> ---
>>> Changes in V4:
>>> - Update version of GCC (12.2) and GNU Binutils (2.39) to the
>>> version
>>> which
On 14.02.2024 13:11, Oleksii wrote:
> On Tue, 2024-02-13 at 12:36 +0100, Jan Beulich wrote:
>> On 05.02.2024 16:32, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/include/asm/atomic.h
>>> @@ -0,0 +1,395 @@
>>> +/* SPDX-License-Identifier: GPL-2.0-only */
>>> +/*
>>> + * Taken an
On 14.02.2024 13:16, Oleksii wrote:
> On Mon, 2024-02-12 at 16:20 +0100, Jan Beulich wrote:
>> 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.
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 Stabellini wrote:
>>> Signed-off-by: Stefano Stabellini
>>> ---
>>> docs/misra/rules.rst | 6 ++
>>> 1 file changed, 6 insertions(+)
>>>
>>> diff --git a/docs/misra/rules.rs
On 14.02.2024 11:37, Roger Pau Monne wrote:
> It's easier to correlate with the physical memory map if the addresses are
> fully printed, instead of using frame numbers.
>
> Requested-by: Andrew Cooper
> Signed-off-by: Roger Pau Monné
In principle
Reviewed-by: Jan Beulich
I'm not sure though t
On 14.02.2024 11:37, Roger Pau Monne wrote:
> Adjust the code in the checker to use full addresses rather than frame
> numbers,
> as it's only page_get_ram_type() that requires an mfn parameter.
>
> Suggested-by: Andrew Cooper
> Signed-off-by: Roger Pau Monné
In this very shape I'd like to lea
> On 14 Feb 2024, at 11:45, Andrew Cooper wrote:
>
> Xapi is the only consumer of this interface. I've fixed up the build
> against staging, but we're not going to be running KFX under Xapi any
> time soon.
>
> Ultimately it's Christian's call.
After a discussion with Andrew, we will not b
On 14.02.2024 11:37, Roger Pau Monne wrote:
> Provide more information in case the page can't be converted, and print the
> original type(s).
>
> Requested-by: Andrew Cooper
> Signed-off-by: Roger Pau Monné
Acked-by: Jan Beulich
On 14.02.2024 11:37, Roger Pau Monne wrote:
> It's not obvious from the function itself whether the incremented value will
> be
s/the function itself/just the function name/ ?
> stored in the parameter, or returned to the caller. That has leads to bugs in
> the past as callers assume the increm
Hi Michal,
On Wed, Feb 14, 2024 at 11:14 AM Michal Orzel wrote:
>
> Hi Carlo,
>
> On 29/01/2024 18:17, Carlo Nonato wrote:
> >
> >
> > LLC coloring needs to know the last level cache layout in order to make the
> > best use of it. This can be probed by inspecting the CLIDR_EL1 register,
> > so th
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 Stabellini wrote:
Signed-off-by: Stefano Stabellini
---
docs/misra/rules.rst | 6 ++
1 file changed, 6 insertions(+)
diff --git a/do
On 14.02.2024 11:35, Frediano Ziglio wrote:
> We just pushed a 8-bytes zero
This part is now somewhat stale.
> and exception constants are
> small so we can just write a single byte saving 3 bytes for
> instruction.
> With ENDBR64 this reduces the size of many entry points from 32 to
> 16 bytes (
On Wed, Feb 14, 2024 at 02:42:46PM +0100, Jan Beulich wrote:
> On 14.02.2024 11:37, Roger Pau Monne wrote:
> > It's not obvious from the function itself whether the incremented value
> > will be
>
> s/the function itself/just the function name/ ?
>
> > stored in the parameter, or returned to the
On Wed, Feb 14, 2024 at 02:22:09PM +0100, Jan Beulich wrote:
> On 14.02.2024 11:37, Roger Pau Monne wrote:
> > It's easier to correlate with the physical memory map if the addresses are
> > fully printed, instead of using frame numbers.
> >
> > Requested-by: Andrew Cooper
> > Signed-off-by: Roger
On Wed, Feb 14, 2024 at 02:29:35PM +0100, Jan Beulich wrote:
> On 14.02.2024 11:37, Roger Pau Monne wrote:
> > Adjust the code in the checker to use full addresses rather than frame
> > numbers,
> > as it's only page_get_ram_type() that requires an mfn parameter.
> >
> > Suggested-by: Andrew Coop
flight 184666 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184666/
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
It's not obvious from just the function name whether the incremented value will
be stored in the parameter, or returned to the caller. That has leads to bugs
in the past as callers may assume the incremented value is stored in the
parameter.
Add the __must_check attribute to the function to easil
Hi Jan,
On Wed, Feb 14, 2024 at 8:55 AM Jan Beulich wrote:
>
> On 13.02.2024 18:29, Carlo Nonato wrote:
> > On Tue, Feb 13, 2024 at 4:25 PM Jan Beulich wrote:
> >> On 29.01.2024 18:18, Carlo Nonato wrote:
> >>> @@ -218,9 +230,44 @@ static void xen_pt_enforce_wnx(void)
> >>> --- a/xen/common/llc-
On 14.02.2024 11:35, Frediano Ziglio wrote:
> @@ -898,105 +898,105 @@ END(handle_exception)
> FUNC(entry_DE)
> ENDBR64
> pushq $0
> -movl $X86_EXC_DE, 4(%rsp)
> +movb $X86_EXC_DE, 4(%rsp)
As we're trying to compact things: This writes 0 over the previously
push
On 14.02.2024 15:05, Roger Pau Monné wrote:
> On Wed, Feb 14, 2024 at 02:29:35PM +0100, Jan Beulich wrote:
>> On 14.02.2024 11:37, Roger Pau Monne wrote:
>>> Adjust the code in the checker to use full addresses rather than frame
>>> numbers,
>>> as it's only page_get_ram_type() that requires an mf
On 14.02.2024 15:11, Roger Pau Monne wrote:
> It's not obvious from just the function name whether the incremented value
> will
> be stored in the parameter, or returned to the caller. That has leads to bugs
> in the past as callers may assume the incremented value is stored in the
> parameter.
>
The `which` command is not standard, may not exist on the build host,
or may not behave as expected. It is recommanded to use `command -v`
to find out if a command exist and have it's path, and it's part of a
POSIX shell standard.
Signed-off-by: Anthony PERARD
---
xen/Makefile | 4 ++--
1 file c
On Wed, Feb 14, 2024 at 10:35:58AM +, Frediano Ziglio wrote:
> We just pushed a 8-bytes zero and exception constants are
> small so we can just write a single byte saving 3 bytes for
> instruction.
> With ENDBR64 this reduces the size of many entry points from 32 to
> 16 bytes (due to alignment
On 14.02.2024 16:02, Roger Pau Monné wrote:
> On Wed, Feb 14, 2024 at 10:35:58AM +, Frediano Ziglio wrote:
>> We just pushed a 8-bytes zero and exception constants are
>> small so we can just write a single byte saving 3 bytes for
>> instruction.
>> With ENDBR64 this reduces the size of many en
On 14.02.2024 15:34, Anthony PERARD wrote:
> The `which` command is not standard, may not exist on the build host,
> or may not behave as expected. It is recommanded to use `command -v`
> to find out if a command exist and have it's path, and it's part of a
> POSIX shell standard.
>
> Signed-off-b
On 14.02.2024 15:34, Anthony PERARD wrote:
> The `which` command is not standard, may not exist on the build host,
> or may not behave as expected. It is recommanded to use `command -v`
> to find out if a command exist and have it's path, and it's part of a
> POSIX shell standard.
Just to mention
On Wed, Feb 14, 2024 at 02:34:11PM +, Anthony PERARD wrote:
> The `which` command is not standard, may not exist on the build host,
> or may not behave as expected. It is recommanded to use `command -v`
> to find out if a command exist and have it's path, and it's part of a
> POSIX shell standa
On Wed, Feb 14, 2024 at 04:08:12PM +0100, Jan Beulich wrote:
> On 14.02.2024 16:02, Roger Pau Monné wrote:
> > On Wed, Feb 14, 2024 at 10:35:58AM +, Frediano Ziglio wrote:
> >> We just pushed a 8-bytes zero and exception constants are
> >> small so we can just write a single byte saving 3 bytes
W=1 builds now warn if module is built without a MODULE_DESCRIPTION().
Add descriptions to the Xen backend network module.
Signed-off-by: Breno Leitao
Acked-by: Paul Durrant
---
drivers/net/xen-netback/netback.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/xen-netback/netback
flight 184665 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184665/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow 20
guest-start/debianhvm.repeat fail in 184660 pass in 184665
On 2024-02-14 12:49, Jan Beulich wrote:
On 14.02.2024 12:26, Nicola Vetrini wrote:
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -387,6 +387,16 @@ in assignments."
{safe, "left_right(^[(,\\[]$,^[),\\]]$)"}
-doc_end
+-doc_begin
On 02.02.2024 22:33, Stewart Hildebrand wrote:
> @@ -836,9 +870,20 @@ static int cf_check init_header(struct pci_dev *pdev)
> if ( pdev->ignore_bars )
> return 0;
>
> -/* Disable memory decoding before sizing. */
> cmd = pci_conf_read16(pdev->sbdf, PCI_COMMAND);
> -if (
On 14.02.2024 16:31, Nicola Vetrini wrote:
> On 2024-02-14 12:49, Jan Beulich wrote:
>> On 14.02.2024 12:26, Nicola Vetrini wrote:
>>> +-config=MC3R1.R20.12,macros+={deliberate,
>>> "name(ASSERT||BUILD_BUG_ON||BUILD_BUG_ON_ZERO||GENERATE_CASE)"}
>>
>> I said in another context already that it is n
On 14/02/2024 3:29 pm, Roger Pau Monné wrote:
> On Wed, Feb 14, 2024 at 04:08:12PM +0100, Jan Beulich wrote:
>> On 14.02.2024 16:02, Roger Pau Monné wrote:
>>> On Wed, Feb 14, 2024 at 10:35:58AM +, Frediano Ziglio wrote:
We just pushed a 8-bytes zero and exception constants are
small
On Wed, Feb 14, 2024 at 03:53:24PM +, Andrew Cooper wrote:
> On 14/02/2024 3:29 pm, Roger Pau Monné wrote:
> > On Wed, Feb 14, 2024 at 04:08:12PM +0100, Jan Beulich wrote:
> >> On 14.02.2024 16:02, Roger Pau Monné wrote:
> >>> On Wed, Feb 14, 2024 at 10:35:58AM +, Frediano Ziglio wrote:
> >
When using Linux for dom0 there are a bunch of drivers that need to do SMC
SIP calls into the firmware to enable certain hardware bits like the
watchdog.
Provide a basic platform glue that implements the needed SMC forwarding.
The format of these calls are as follows:
- reg 0: service ID
- reg
The iMX lpuart driver added at 44e17aa60d47 ("xen/arm: Add i.MX lpuart driver")
is not enough to boot a Linux based dom0 when certain drivers, such as the
watchdog driver, are enabled.
We're also fixing compatibles in imx-lpuart to allow Xen to use the UART
on the QXP variant as well.
NOTE:
There
Allow the uart to probe also with iMX8QXP. The ip-block is the same as in
the QM.
Since the fsl,imx8qm-lpuart compatible in Linux exists in name only and is
not used in the driver any iMX8QM device tree that can boot Linux must set
fsl,imx8qxp-lpuart compatible as well as the QM one.
Thus we repl
On 2024-02-14 16:45, Jan Beulich wrote:
On 14.02.2024 16:31, Nicola Vetrini wrote:
On 2024-02-14 12:49, Jan Beulich wrote:
On 14.02.2024 12:26, Nicola Vetrini wrote:
+-config=MC3R1.R20.12,macros+={deliberate,
"name(ASSERT||BUILD_BUG_ON||BUILD_BUG_ON_ZERO||GENERATE_CASE)"}
I said in another c
On 12/02/24 09:43, Jan Beulich wrote:
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:
O
On Thu, Feb 08, 2024 at 05:55:40PM +0100, Juergen Gross wrote:
> Add support for the new 9pfs backend "xen_9pfsd". For this backend type
> the tag defaults to "Xen" and the host side path to
> "/var/log/xen/guests/".
>
> Do most of the default settings in libxl. Unfortunately the default
> path ca
On Thu, Feb 08, 2024 at 05:55:42PM +0100, Juergen Gross wrote:
> diff --git a/tools/include/libxl.h b/tools/include/libxl.h
> index a554f2ccd6..e6ab5ddb94 100644
> --- a/tools/include/libxl.h
> +++ b/tools/include/libxl.h
> @@ -583,6 +583,13 @@
> * libxl_console_add_xenstore() in libxl.
> */
>
On Thu, Feb 08, 2024 at 05:55:45PM +0100, Juergen Gross wrote:
> 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-o
flight 184667 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184667/
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
1 - 100 of 138 matches
Mail list logo
