On 22.03.24 07:39, Jiapeng Chong wrote:
./arch/x86/xen/enlighten.c: linux/memblock.h is included more than once.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=8610
Signed-off-by: Jiapeng Chong
Reviewed-by: Juergen Gross
Juergen
./arch/x86/xen/enlighten.c: linux/memblock.h is included more than once.
Reported-by: Abaci Robot
Closes: https://bugzilla.openanolis.cn/show_bug.cgi?id=8610
Signed-off-by: Jiapeng Chong
---
arch/x86/xen/enlighten.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/x86/xen/enlighten.c
flight 185136 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185136/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-xsm 6 xen-buildfail REGR. vs. 185119
Tests which did not
On 3/21/2024 12:54 PM, Ingo Molnar wrote:
* Xin Li (Intel) wrote:
The stack of a task has been separated from the memory of a task_struct
struture for a long time on x86, as a result __{start,end}_init_task no
longer mark the start and end of the init_task structure, but its stack
only.
Rena
On Wed, Mar 20, 2024 at 11:19 PM Peter Xu wrote:
> On Wed, Mar 20, 2024 at 07:49:07AM +0100, Cédric Le Goater wrote:
> > Now that the log_global*() handlers take an Error** parameter and
> > return a bool, do the same for memory_global_dirty_log_start() and
> > memory_global_dirty_log_stop(). The
flight 185124 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185124/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-qemuu-freebsd12-amd64 21 guest-start/freebsd.repeat fail in
185117 pass in 185124
test-amd64-
Hi Stefano,
I haven't fully read the thread. But I wanted to clarify something.
On 21/03/2024 19:03, Stefano Stabellini wrote:
Or possibly unsigned long depending on the parameter.
You're contradicting yourself: You mean to advocate for fixed-width types,
yet then you suggest "unsigned long".
flight 185132 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/185132/
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
flight 185119 linux-linus real [real]
flight 185134 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185119/
http://logs.test-lab.xenproject.org/osstest/logs/185134/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
* Xin Li (Intel) wrote:
> The stack of a task has been separated from the memory of a task_struct
> struture for a long time on x86, as a result __{start,end}_init_task no
> longer mark the start and end of the init_task structure, but its stack
> only.
>
> Rename __{start,end}_init_task to __
On Thu, 21 Mar 2024, Jan Beulich wrote:
> On 21.03.2024 02:46, Stefano Stabellini wrote:
> > On Wed, 20 Mar 2024, Jan Beulich wrote:
> >>> - the public interface is described in a C header so it makes sense for
> >>> the corresponding implementation to be in C
> >>>
> >>> - the C entry point is o
Hi Shawn,
On 14/03/2024 22:15, Shawn Anastasio wrote:
Enable usage of bootfdt for populating the boot info struct from the
firmware-provided device tree. Also enable the Xen boot page allocator.
Includes minor changes to bootfdt.c's boot_fdt_info() to tolerate the
scenario in which the FDT ove
On Thu, 21 Mar 2024, Jan Beulich wrote:
> On 21.03.2024 02:50, Stefano Stabellini wrote:
> > On Wed, 20 Mar 2024, Jan Beulich wrote:
> >> On 20.03.2024 09:50, Simone Ballarin wrote:
> >>> MISRA C:2012 Rule 17.1 states:
> >>> The features of `' shall not be used
> >>>
> >>> The Xen community wants t
Hi,
On 14/03/2024 22:15, Shawn Anastasio wrote:
diff --git a/xen/common/device-tree/Makefile b/xen/common/device-tree/Makefile
new file mode 100644
index 00..c97b2bd88c
--- /dev/null
+++ b/xen/common/device-tree/Makefile
@@ -0,0 +1 @@
+obj-y += bootinfo.o
AFAICT everything in the new f
Hi Shawn,
On 14/03/2024 22:15, Shawn Anastasio wrote:
Move Arm's bootfdt.c to xen/common so that it can be used by other
device tree architectures like PPC and RISCV.
Suggested-by: Julien Grall
Signed-off-by: Shawn Anastasio
Acked-by: Julien Grall
---
Changes in v2:
- Drop #if defined(CON
Hi Shawn,
On 14/03/2024 22:15, Shawn Anastasio wrote:
Arm's setup.c contains a collection of functions for parsing memory map
and other boot information from a device tree. Since these routines are
generally useful on any architecture that supports device tree booting,
move them into xen/common/
Hi Jan,
On 21/03/2024 07:42, Jan Beulich wrote:
On 20.03.2024 19:07, Shawn Anastasio wrote:
On 3/15/24 4:16 AM, Jan Beulich wrote:
On 14.03.2024 23:15, Shawn Anastasio wrote:
Arm's setup.c contains a collection of functions for parsing memory map
and other boot information from a device tree.
Hi Shawn,
On 14/03/2024 22:15, Shawn Anastasio wrote:
Add the definitions used by ARM's bootfdt.c, which will be moved into
xen/common in a later patch, to PPC's setup.h
This read as the definition should be in include/xen/... rather than per
arch. In particular, ...
+/*
+ * bootinfo.c
+ *
On Thu, Mar 21, 2024 at 4:57 PM Jan Beulich wrote:
>
> On 21.03.2024 16:04, Carlo Nonato wrote:
> > On Tue, Mar 19, 2024 at 4:30 PM Jan Beulich wrote:
> >> On 15.03.2024 11:58, Carlo Nonato wrote:
> >>> --- a/docs/misc/xen-command-line.pandoc
> >>> +++ b/docs/misc/xen-command-line.pandoc
> >>> @@
Hi Shawn,
On 14/03/2024 22:15, Shawn Anastasio wrote:
On architectures with no EFI support, define an inline stub
implementation of efi_enabled in efi.h that always returns false.
Suggested-by: Jan Beulich
Signed-off-by: Shawn Anastasio
Acked-by: Julien Grall
Cheers,
--
Julien Grall
flight 185125 xen-unstable-smoke real [real]
flight 185130 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185125/
http://logs.test-lab.xenproject.org/osstest/logs/185130/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
Hi Jan,
On Thu, Mar 21, 2024 at 4:53 PM Jan Beulich wrote:
>
> On 21.03.2024 16:03, Carlo Nonato wrote:
> > On Tue, Mar 19, 2024 at 3:58 PM Jan Beulich wrote:
> >> On 15.03.2024 11:58, Carlo Nonato wrote:
> >>> --- a/docs/misc/xen-command-line.pandoc
> >>> +++ b/docs/misc/xen-command-line.pandoc
On 21.03.2024 17:10, Julien Grall wrote:
> On 21/03/2024 16:07, Julien Grall wrote:
>> On 15/03/2024 10:58, Carlo Nonato wrote:
>>> PGC_static and PGC_extra needs to be preserved when assigning a page.
>>> Define a new macro that groups those flags and use it instead of or'ing
>>> every time.
>>>
>
Hi John,
> On 21 Mar 2024, at 17:05, John Ernberg wrote:
>
> Hi Bertrand,
>
> On 3/21/24 08:41, Bertrand Marquis wrote:
>> Hi,
>>
>>> On 20 Mar 2024, at 18:40, Julien Grall wrote:
>>>
>>> Hi John,
>>>
>>> On 20/03/2024 16:24, John Ernberg wrote:
Hi Bertrand,
On 3/13/24 11:07, Bert
On 21/03/2024 16:07, Julien Grall wrote:
(+ Roger)
Hi Carlo,
On 15/03/2024 10:58, Carlo Nonato wrote:
PGC_static and PGC_extra needs to be preserved when assigning a page.
Define a new macro that groups those flags and use it instead of or'ing
every time.
To make preserved flags even more
(+ Roger)
Hi Carlo,
On 15/03/2024 10:58, Carlo Nonato wrote:
PGC_static and PGC_extra needs to be preserved when assigning a page.
Define a new macro that groups those flags and use it instead of or'ing
every time.
To make preserved flags even more meaningful, they are kept also when
switching
Hi Bertrand,
On 3/21/24 08:41, Bertrand Marquis wrote:
> Hi,
>
>> On 20 Mar 2024, at 18:40, Julien Grall wrote:
>>
>> Hi John,
>>
>> On 20/03/2024 16:24, John Ernberg wrote:
>>> Hi Bertrand,
>>> On 3/13/24 11:07, Bertrand Marquis wrote:
Hi,
> On 8 Mar 2024, at 15:04, Julien Grall
On 21.03.2024 16:36, Carlo Nonato wrote:
> On Tue, Mar 19, 2024 at 5:43 PM Jan Beulich wrote:
>> On 15.03.2024 11:58, Carlo Nonato wrote:
>>> +static void __init init_color_heap_pages(struct page_info *pg,
>>> + unsigned long nr_pages)
>>> +{
>>> +unsign
On 21.03.2024 16:04, Carlo Nonato wrote:
> On Tue, Mar 19, 2024 at 4:30 PM Jan Beulich wrote:
>> On 15.03.2024 11:58, Carlo Nonato wrote:
>>> --- a/docs/misc/xen-command-line.pandoc
>>> +++ b/docs/misc/xen-command-line.pandoc
>>> @@ -963,6 +963,15 @@ Controls for the dom0 IOMMU setup.
>>>
>>> Spe
On 21.03.2024 16:03, Carlo Nonato wrote:
> On Tue, Mar 19, 2024 at 3:58 PM Jan Beulich wrote:
>> On 15.03.2024 11:58, Carlo Nonato wrote:
>>> --- a/docs/misc/xen-command-line.pandoc
>>> +++ b/docs/misc/xen-command-line.pandoc
>>> @@ -1706,6 +1706,43 @@ This option is intended for debugging purpose
Hi Jan,
On Tue, Mar 19, 2024 at 5:43 PM Jan Beulich wrote:
>
> On 15.03.2024 11:58, Carlo Nonato wrote:
> > Add a new memory page allocator that implements the cache coloring
> > mechanism.
> > The allocation algorithm enforces equal frequency distribution of cache
> > partitions, following the
Hi Jan
On Tue, Mar 19, 2024 at 4:54 PM Jan Beulich wrote:
>
> On 15.03.2024 11:59, Carlo Nonato wrote:
> > From: Luca Miccio
> >
> > Add a new command line parameter to configure Xen cache colors.
> > These colors can be dumped with the cache coloring info debug-key.
> >
> > By default, Xen uses
Hi Jan,
On Tue, Mar 19, 2024 at 4:41 PM Jan Beulich wrote:
>
> On 15.03.2024 11:58, Carlo Nonato wrote:
> > --- a/xen/common/llc-coloring.c
> > +++ b/xen/common/llc-coloring.c
> > @@ -253,6 +253,37 @@ int domain_set_llc_colors(struct domain *d,
> > return 0;
> > }
> >
> > +int __init domain
Hi Jan,
On Tue, Mar 19, 2024 at 4:37 PM Jan Beulich wrote:
>
> On 15.03.2024 11:58, Carlo Nonato wrote:
> > @@ -219,6 +220,39 @@ void domain_llc_coloring_free(struct domain *d)
> > xfree(__va(__pa(d->llc_colors)));
> > }
> >
> > +int domain_set_llc_colors(struct domain *d,
> > +
Hi Jan,
On Tue, Mar 19, 2024 at 4:30 PM Jan Beulich wrote:
>
> On 15.03.2024 11:58, Carlo Nonato wrote:
> > --- a/docs/misc/xen-command-line.pandoc
> > +++ b/docs/misc/xen-command-line.pandoc
> > @@ -963,6 +963,15 @@ Controls for the dom0 IOMMU setup.
> >
> > Specify a list of IO ports to be exc
Hi Jan,
(adding Andrea Bastoni in cc)
On Tue, Mar 19, 2024 at 3:58 PM Jan Beulich wrote:
>
> On 15.03.2024 11:58, Carlo Nonato wrote:
> > +Background
> > +**
> > +
> > +Cache hierarchy of a modern multi-core CPU typically has first levels
> > dedicated
> > +to each core (hence using mul
On 21.03.2024 14:45, Jason Andryuk wrote:
> On 2024-03-20 10:39, Jan Beulich wrote:
>> On 19.03.2024 21:58, Jason Andryuk wrote:
>>> +/* Find an e820 RAM region that fits the kernel at a suitable alignment. */
>>> +static paddr_t __init find_kernel_memory(
>>> +const struct domain *d, struct el
On 2024-03-20 10:39, Jan Beulich wrote:
On 19.03.2024 21:58, Jason Andryuk wrote:
--- a/xen/arch/x86/hvm/dom0_build.c
+++ b/xen/arch/x86/hvm/dom0_build.c
@@ -537,6 +537,97 @@ static paddr_t __init find_memory(
return INVALID_PADDR;
}
+static bool __init check_load_address(
+const
On 15.03.2024 19:06, Oleksii Kurochko wrote:
> --- a/xen/arch/riscv/include/asm/mm.h
> +++ b/xen/arch/riscv/include/asm/mm.h
> @@ -3,11 +3,246 @@
> #ifndef _ASM_RISCV_MM_H
> #define _ASM_RISCV_MM_H
>
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> #include
>
> #defin
On 15.03.2024 19:06, Oleksii Kurochko wrote:
> The cpu_relax() function, introduced in this commit, is anticipated to
> support _zihintpause by the CPU.
>
> Signed-off-by: Oleksii Kurochko
Acked-by: Jan Beulich
Looks like this can go in ahead of the other 14 patches?
Jan
On 15.03.2024 19:06, Oleksii Kurochko wrote:
> Initially the patch was introduced by Bobby, who takes the header from
> Linux kernel.
>
> The following changes were done on top of Linux kernel header:
> - atomic##prefix##_*xchg_*(atomic##prefix##_t *v, c_t n) were updated
> to use__*xchg_gen
flight 185117 xen-unstable real [real]
flight 185122 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185117/
http://logs.test-lab.xenproject.org/osstest/logs/185122/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
On 15.03.2024 19:06, Oleksii Kurochko wrote:
> --- /dev/null
> +++ b/xen/arch/riscv/include/asm/io.h
> @@ -0,0 +1,167 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * The header taken form Linux 6.4.0-rc1 and is based on
> + * arch/riscv/include/asm/mmio.h with the following changes:
On 21.03.2024 12:05, Roger Pau Monne wrote:
> The current console_lock_recursive_irqsave() implementation is not speculation
> safe, however it's only used to prevent interleaved output. Note this in the
> function declaration in order for callers to be aware of the limitation.
>
> No functional
flight 185120 xen-unstable-smoke real [real]
flight 185121 xen-unstable-smoke real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185120/
http://logs.test-lab.xenproject.org/osstest/logs/185121/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which co
On 15.03.2024 19:06, Oleksii Kurochko wrote:
> The header was taken from Linux kernl 6.4.0-rc1.
>
> Addionally, were updated:
> * add emulation of {cmp}xchg for 1/2 byte types using 32-bit atomic
> access.
> * replace tabs with spaces
> * replace __* variale with *__
> * introduce generic versio
The current console_lock_recursive_irqsave() implementation is not speculation
safe, however it's only used to prevent interleaved output. Note this in the
function declaration in order for callers to be aware of the limitation.
No functional change.
Signed-off-by: Roger Pau Monné
---
xen/incl
On 21.03.2024 11:28, Teddy Astie wrote:
> No hardware has VT-d support while not having cx16 support, consider
> disabling IOMMU in this case to avoid potentially buggy code.
Like in patch 2 (which for whatever reason made it through quite a bit earlier),
why "consider"? Your change does disable
On 21.03.2024 11:28, Teddy Astie wrote:
> No hardware has VT-d support while not having cx16 support, consider
> disabling IOMMU in this case to avoid potentially buggy code.
VT-d? That's Intel, not AMD. Also alongside bare hardware you also want to
not completely leave out Xen running virtualize
This flag was only used in case cx16 is not available, as those code paths no
longer exist, this flag now does basically nothing.
Signed-off-by Teddy Astie
---
xen/drivers/passthrough/vtd/iommu.c | 12 +++-
xen/drivers/passthrough/vtd/vtd.h | 5 ++---
2 files changed, 5 insertions(+)
No hardware has VT-d support while not having cx16 support, consider disabling
IOMMU in this case to avoid potentially buggy code.
Now that IOMMU is only enabled if cx16 is supported, drop dead code that
handles cases where cx16 isn't supported.
Signed-off-by Teddy Astie
---
xen/drivers/passt
No hardware has VT-d support while not having cx16 support, consider disabling
IOMMU in this case to avoid potentially buggy code.
Now that IOMMU is only enabled if cx16 is supported, drop dead code that
handles cases where cx16 isn't supported.
Signed-off-by Teddy Astie
---
xen/drivers/passt
All hardware that supports VT-d/AMD-Vi that exists also supports cx16 (aside
specifically crafted virtual machines).
Some IOMMU code paths in Xen consider cases where VT-d/AMD-Vi is supported
while cx16 isn't, those paths may be bugged and are barely tested, dead code in
practice.
Consider dis
On 21.03.2024 11:07, Oleksii wrote:
> On Wed, 2024-03-20 at 17:03 +0100, Jan Beulich wrote:
>> On 15.03.2024 19:06, Oleksii Kurochko wrote:
>>> --- /dev/null
>>> +++ b/xen/arch/riscv/include/asm/bitops.h
>>> @@ -0,0 +1,144 @@
>>> +/* SPDX-License-Identifier: GPL-2.0 */
>>> +/* Copyright (C) 2012 Re
On 21.03.2024 10:57, Roger Pau Monné wrote:
> On Thu, Mar 21, 2024 at 10:17:25AM +0100, Jan Beulich wrote:
>> On 21.03.2024 10:10, Roger Pau Monné wrote:
>>> On Thu, Mar 21, 2024 at 09:07:10AM +0100, Jan Beulich wrote:
On 20.03.2024 17:29, Roger Pau Monné wrote:
> On Wed, Mar 20, 2024 at 0
On 20 Mar 2024 17:08, Anthony PERARD wrote:
On Fri, Mar 08, 2024 at 04:19:20PM +0100, zithro / Cyril Rébert wrote:
Questions (unblocking):
- why a double space between all sentences ?
It's an English thing maybe?
Wikipedia has an article about it:
https://en.wikipedia.org/wiki/Sentence_spa
On Wed, 2024-03-20 at 17:03 +0100, Jan Beulich wrote:
> On 15.03.2024 19:06, Oleksii Kurochko wrote:
> > Taken from Linux-6.4.0-rc1
> >
> > Xen's bitops.h consists of several Linux's headers:
> > * linux/arch/include/asm/bitops.h:
> > * The following function were removed as they aren't used in
On Thu, Mar 21, 2024 at 10:17:25AM +0100, Jan Beulich wrote:
> On 21.03.2024 10:10, Roger Pau Monné wrote:
> > On Thu, Mar 21, 2024 at 09:07:10AM +0100, Jan Beulich wrote:
> >> On 20.03.2024 17:29, Roger Pau Monné wrote:
> >>> On Wed, Mar 20, 2024 at 04:09:33PM +0100, Jan Beulich wrote:
> On 2
On 2024-03-20 12:01, Nicola Vetrini wrote:
On 2024-03-18 17:35, Andrew Cooper wrote:
Rework the trace API to unify it (remove the HVM specific
obfuscation), and
remove MISRA violations.
v3:
* Delete TRACE_PARAM64()
Andrew Cooper (7):
xen/trace: Introduce new API
xen/credit2: Clean up tra
On Wed, 2024-03-20 at 16:42 +0100, Jan Beulich wrote:
> On 15.03.2024 19:06, Oleksii Kurochko wrote:
> > --- a/xen/lib/find-next-bit.c
> > +++ b/xen/lib/find-next-bit.c
> > @@ -9,6 +9,7 @@
> > * 2 of the License, or (at your option) any later version.
> > */
> > #include
> > +#include
> >
On Wed, 2024-03-20 at 16:30 +0100, Jan Beulich wrote:
> On 15.03.2024 19:06, Oleksii Kurochko wrote:
> > The patch introduces the following generic functions:
> > * test_bit
> > * generic___test_and_set_bit
> > * generic___test_and_clear_bit
> > * generic___test_and_change_bit
> >
> > Also, the pa
On Thu, Mar 21, 2024 at 09:31:59AM +0100, Jan Beulich wrote:
> On 20.03.2024 20:44, Conor Dooley wrote:
> > On Wed, Mar 20, 2024 at 07:58:05PM +0100, Oleksii wrote:
> >> On Mon, 2024-03-18 at 17:58 +0100, Jan Beulich wrote:
> >>> On 15.03.2024 19:05, Oleksii Kurochko wrote:
> Currently, RISC-V
On 21.03.2024 10:10, Roger Pau Monné wrote:
> On Thu, Mar 21, 2024 at 09:07:10AM +0100, Jan Beulich wrote:
>> On 20.03.2024 17:29, Roger Pau Monné wrote:
>>> On Wed, Mar 20, 2024 at 04:09:33PM +0100, Jan Beulich wrote:
On 20.03.2024 14:57, Roger Pau Monne wrote:
> There's no reason to forc
On Thu, Mar 21, 2024 at 09:07:10AM +0100, Jan Beulich wrote:
> On 20.03.2024 17:29, Roger Pau Monné wrote:
> > On Wed, Mar 20, 2024 at 04:09:33PM +0100, Jan Beulich wrote:
> >> On 20.03.2024 14:57, Roger Pau Monne wrote:
> >>> There's no reason to force HVM guests to have a valid vcpu_info area whe
On Wed, 2024-03-20 at 19:44 +, Conor Dooley wrote:
> IIRC this only "works" because the OpenSBI devs assume that there are
> no
> non-normative behaviours and all CSRs have their ~God~ RVI defined
> meanings. Reading a CSR to see if it traps is not behaviour you can
> really
> rely on unless th
Hi Luca,
On 20/03/2024 15:53, Luca Fancellu wrote:
>
>
>> On 20 Mar 2024, at 10:57, Michal Orzel wrote:
>>
>> Hi Luca,
>>
>> On 12/03/2024 14:03, Luca Fancellu wrote:
>>>
>>>
>>> The function find_unallocated_memory is using the same code to
>>> loop through 3 structure of the same type, in ord
On Wed, Mar 20, 2024 at 03:51:55PM +0100, Jan Beulich wrote:
> On 20.03.2024 15:06, Roger Pau Monné wrote:
> > On Wed, Mar 20, 2024 at 11:58:50AM +0100, Jan Beulich wrote:
> >> On 20.03.2024 11:46, Roger Pau Monné wrote:
> >>> On Tue, Mar 19, 2024 at 02:28:12PM +0100, Jan Beulich wrote:
> With
On 20.03.2024 20:44, Conor Dooley wrote:
> On Wed, Mar 20, 2024 at 07:58:05PM +0100, Oleksii wrote:
>> On Mon, 2024-03-18 at 17:58 +0100, Jan Beulich wrote:
>>> On 15.03.2024 19:05, Oleksii Kurochko wrote:
Currently, RISC-V requires two extensions: _zbb and _zihintpause.
>>>
>>> Do we really r
On 21.03.2024 02:46, Stefano Stabellini wrote:
> On Wed, 20 Mar 2024, Jan Beulich wrote:
>>> - the public interface is described in a C header so it makes sense for
>>> the corresponding implementation to be in C
>>>
>>> - the C entry point is often both the entry point in C and also common
>>>
On 21.03.2024 02:50, Stefano Stabellini wrote:
> On Wed, 20 Mar 2024, Jan Beulich wrote:
>> On 20.03.2024 09:50, Simone Ballarin wrote:
>>> MISRA C:2012 Rule 17.1 states:
>>> The features of `' shall not be used
>>>
>>> The Xen community wants to avoid using variadic functions except for
>>> specif
On 20.03.2024 17:29, Roger Pau Monné wrote:
> On Wed, Mar 20, 2024 at 04:09:33PM +0100, Jan Beulich wrote:
>> On 20.03.2024 14:57, Roger Pau Monne wrote:
>>> There's no reason to force HVM guests to have a valid vcpu_info area when
>>> initializing a vCPU, as the vCPU can also be brought online usi
On 20.03.2024 16:20, Andrew Cooper wrote:
> On 20/03/2024 3:09 pm, Jan Beulich wrote:
>> On 20.03.2024 14:57, Roger Pau Monne wrote:
>>> There's no reason to force HVM guests to have a valid vcpu_info area when
>>> initializing a vCPU, as the vCPU can also be brought online using the local
>>> APIC
Hi,
> On 20 Mar 2024, at 18:40, Julien Grall wrote:
>
> Hi John,
>
> On 20/03/2024 16:24, John Ernberg wrote:
>> Hi Bertrand,
>> On 3/13/24 11:07, Bertrand Marquis wrote:
>>> Hi,
>>>
On 8 Mar 2024, at 15:04, Julien Grall wrote:
Hi John,
Thank you for the reply.
On 20.03.2024 19:07, Shawn Anastasio wrote:
> On 3/15/24 4:16 AM, Jan Beulich wrote:
>> On 14.03.2024 23:15, Shawn Anastasio wrote:
>>> Arm's setup.c contains a collection of functions for parsing memory map
>>> and other boot information from a device tree. Since these routines are
>>> generally u
flight 185114 linux-linus real [real]
flight 185118 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/185114/
http://logs.test-lab.xenproject.org/osstest/logs/185118/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-armhf-
75 matches
Mail list logo
