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 by
>>> the Xen RISC-V container
On 22.02.2024 10:05, Roger Pau Monne wrote:
> The usage of a cmpxchg loop in get_next_handle() is unnecessary, as the same
> can be achieved with an atomic increment, which is both simpler to read, and
> avoid any need for a loop.
>
> The cmpxchg usage is likely a remnant of 32bit support, which
On 28.02.2024 23:45, Stefano Stabellini wrote:
> On Wed, 28 Feb 2024, Julien Grall wrote:
>> On 28/02/2024 12:58, Jan Beulich wrote:
>>> On 28.02.2024 12:50, Julien Grall wrote:
On 27/02/2024 13:19, Jan Beulich wrote:
> the release is due in two to three weeks. Please point out backports
The xl command doesn't provide suspend/resume, so add them :
xl suspend-to-ram
xl resume
This patch follows a discussion on XenDevel: when you want the
virtualized equivalent of "sleep"-ing a host, it's better to
suspend/resume than to pause/unpause a domain.
Suggested-by: Andrew Cooper
On 28.02.2024 17:56, Roger Pau Monné wrote:
> On Wed, Feb 28, 2024 at 03:28:25PM +0100, Jan Beulich wrote:
>> On 28.02.2024 14:59, Roger Pau Monne wrote:
>>> The usage in ALT_CALL_ARG() on clang of:
>>>
>>> register union {
>>> typeof(arg) e;
>>> const unsigned long r;
>>> } ...
>>>
>>>
flight 184815 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184815/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf d9a6e7b0b8a67392a57788d97634256546207a64
baseline version:
ovmf
flight 184802 linux-linus real [real]
flight 184814 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184802/
http://logs.test-lab.xenproject.org/osstest/logs/184814/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
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 in
> theory such is also needed ahead of
On 28/02/2024 10:58 pm, Julien Grall wrote:
> Hi Jan,
>
> 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 by
>>> the Xen
Hi Jan,
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 by
the Xen RISC-V container and are anticipated to undergo continuous
On Wed, 28 Feb 2024, Julien Grall wrote:
> Hi Jan,
>
> On 28/02/2024 12:58, Jan Beulich wrote:
> > On 28.02.2024 12:50, Julien Grall wrote:
> > > On 27/02/2024 13:19, Jan Beulich wrote:
> > > > All,
> > > >
> > > > the release is due in two to three weeks. Please point out backports you
> > > >
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 them as a compliance mechanism.
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_CONSOLE in
> >> TEMPORARY_EARLY_UART_VIRTUAL_ADDRESS macro.
flight 184812 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184812/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf 5c37e0b719c925207db50e89a5b11d7ce78cf1fb
baseline version:
xtf
flight 184810 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184810/
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
flight 184804 xen-4.16-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184804/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 16 saverestore-support-checkfail like 184530
flight 184809 xtf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184809/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
xtf ad98fbacc7ed6b709f87bf0ef64b81eafb557cce
baseline version:
xtf
flight 184796 xen-unstable real [real]
flight 184808 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/184796/
http://logs.test-lab.xenproject.org/osstest/logs/184808/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
flight 184806 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184806/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl
On Mon, Jan 29, 2024 at 06:18:02PM +0100, Carlo Nonato wrote:
> diff --git a/tools/include/xenctrl.h b/tools/include/xenctrl.h
> index 2ef8b4e054..4b541fffd2 100644
> --- a/tools/include/xenctrl.h
> +++ b/tools/include/xenctrl.h
> @@ -2653,6 +2653,15 @@ int xc_livepatch_replace(xc_interface *xch,
On Tue, 2024-02-27 at 08:55 +0100, 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 by
> > the Xen RISC-V container and are anticipated to undergo
On Wed, Feb 28, 2024 at 03:28:25PM +0100, Jan Beulich wrote:
> On 28.02.2024 14:59, Roger Pau Monne wrote:
> > The usage in ALT_CALL_ARG() on clang of:
> >
> > register union {
> > typeof(arg) e;
> > const unsigned long r;
> > } ...
> >
> > When `arg` is the first argument to
On 28.02.24 17:02, Jan Beulich wrote:
On 28.02.2024 16:43, Jürgen Groß wrote:
On 28.02.24 16:19, Jan Beulich wrote:
On 12.12.2023 10:47, Juergen Gross wrote:
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -538,19 +538,31 @@ static void spinlock_profile_iterate(lock_profile_subfunc
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(regs->rip), _p(regs->rip));
>
> +if (
On 28.02.2024 16:43, Jürgen Groß wrote:
> On 28.02.24 16:19, Jan Beulich wrote:
>> On 12.12.2023 10:47, Juergen Gross wrote:
>>> --- a/xen/common/spinlock.c
>>> +++ b/xen/common/spinlock.c
>>> @@ -538,19 +538,31 @@ static void
>>> spinlock_profile_iterate(lock_profile_subfunc *sub, void *par)
>>>
On Tue, Jan 09, 2024 at 12:05:40PM -0500, Jason Andryuk wrote:
> @@ -3430,7 +3431,7 @@ void libxl__spawn_qdisk_backend(libxl__egc *egc,
> libxl__dm_spawn_state *dmss)
> * because we will call this from unprivileged driver domains,
> * so save it in the current domain libxl private
On 28.02.24 16:19, Jan Beulich wrote:
On 12.12.2023 10:47, Juergen Gross wrote:
--- a/xen/common/spinlock.c
+++ b/xen/common/spinlock.c
@@ -538,19 +538,31 @@ static void spinlock_profile_iterate(lock_profile_subfunc
*sub, void *par)
static void cf_check spinlock_profile_print_elem(struct
On Tue, Jan 09, 2024 at 12:05:39PM -0500, Jason Andryuk wrote:
> libxl__spawn_qdisk_backend() explicitly sets guest_config to NULL when
> starting QEMU (the usual launch through libxl__spawn_local_dm() has a
> guest_config though).
>
> Bail early on a NULL guest_config/d_config. This skips the
On 28.02.2024 16:21, Andrew Cooper wrote:
> On 28/02/2024 1:52 pm, Jan Beulich wrote:
>> --- a/xen/arch/x86/traps.c
>> +++ b/xen/arch/x86/traps.c
>> @@ -837,24 +825,26 @@ static void fixup_exception_return(struc
>> {
>> if ( IS_ENABLED(CONFIG_XEN_SHSTK) )
>> {
>> -unsigned long
On 28.02.24 16:09, Jan Beulich wrote:
On 12.12.2023 10:47, Juergen Gross wrote:
Instead of special casing rspin_lock_irqsave() and
rspin_unlock_irqrestore() for the console lock, add those functions
to spinlock handling and use them where needed.
Signed-off-by: Juergen Gross
---
V2:
- new
On 28/02/2024 1:52 pm, Jan Beulich wrote:
> --- a/xen/arch/x86/traps.c
> +++ b/xen/arch/x86/traps.c
> @@ -837,24 +825,26 @@ static void fixup_exception_return(struc
> {
> if ( IS_ENABLED(CONFIG_XEN_SHSTK) )
> {
> -unsigned long ssp, *ptr, *base;
> +unsigned long ssp =
On 12.12.2023 10:47, Juergen Gross wrote:
> --- a/xen/common/spinlock.c
> +++ b/xen/common/spinlock.c
> @@ -538,19 +538,31 @@ static void
> spinlock_profile_iterate(lock_profile_subfunc *sub, void *par)
> static void cf_check spinlock_profile_print_elem(struct lock_profile *data,
> int32_t
On Tue, Feb 27, 2024 at 11:25 AM Roger Pau Monne wrote:
>
> The purpose of the norevert test is to install a dummy handler that replaces
> the internal Xen revert code, and then perform the revert in the post-revert
> hook. For that purpose the usage of the previous common_livepatch_revert() is
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 points do
> not need to record that value.
>
>
flight 184805 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184805/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 15 migrate-support-checkfail never pass
test-armhf-armhf-xl
On 12.12.2023 10:47, Juergen Gross wrote:
> Instead of special casing rspin_lock_irqsave() and
> rspin_unlock_irqrestore() for the console lock, add those functions
> to spinlock handling and use them where needed.
>
> Signed-off-by: Juergen Gross
> ---
> V2:
> - new patch
In how far is this a
On 12.12.2023 10:47, Juergen Gross wrote:
> Rename the recursive spin_lock() functions by replacing the trailing
> "_recursive" with a leading "r".
>
> Switch the parameter to be a pointer to rspinlock_t.
>
> Remove the indirection through a macro, as it is adding only complexity
> without any
On 18.02.2024 19:01, Julien Grall wrote:
> On 14/02/2024 10:12, Jan Beulich wrote:
>> 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
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 in
theory such is also needed ahead of TSC_DEADLINE writes. A comment of
our own in
On Tue, Feb 27, 2024 at 1:08 PM Andrew Cooper wrote:
>
> On 27/02/2024 11:25 am, Roger Pau Monne wrote:
> > diff --git a/xen/common/virtual_region.c b/xen/common/virtual_region.c
> > index ddac5c9147e5..e3a4dc8540df 100644
> > --- a/xen/common/virtual_region.c
> > +++
On 2024-02-26 11:51, Jan Beulich wrote:
On 23.02.2024 08:58, Nicola Vetrini wrote:
On 2024-02-19 16:14, Nicola Vetrini wrote:
The cache clearing and invalidation helpers in x86 and Arm didn't
comply with MISRA C Rule 17.7: "The value returned by a function
having non-void return type shall be
On Tue, Feb 27, 2024 at 11:25 AM Roger Pau Monne wrote:
>
> Group the payload hooks between the pre/post handlers, and the apply/revert
> replacements. Also attempt to comment the context in which the hooks are
> executed.
>
> No functional change.
>
> Signed-off-by: Roger Pau Monné
> ---
>
Juergen Gross, le lun. 26 févr. 2024 09:39:55 +0100, a ecrit:
> Xenstore stubdom needs some more symbols exported.
>
> Signed-off-by: Juergen Gross
Reviewed-by: Samuel Thibault
Thanks!
> ---
> xenbus.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/xenbus.c b/xenbus.c
> index
On 28.02.2024 14:59, Roger Pau Monne wrote:
> The usage in ALT_CALL_ARG() on clang of:
>
> register union {
> typeof(arg) e;
> const unsigned long r;
> } ...
>
> When `arg` is the first argument to alternative_{,v}call() and
> const_vlapic_vcpu() is used results in clang 3.5.0
The usage in ALT_CALL_ARG() on clang of:
register union {
typeof(arg) e;
const unsigned long r;
} ...
When `arg` is the first argument to alternative_{,v}call() and
const_vlapic_vcpu() is used results in clang 3.5.0 complaining with:
arch/x86/hvm/vlapic.c:141:47: error: non-const static
On 28/02/2024 1:51 pm, Jan Beulich wrote:
> As of 72d51813d631 ("x86: amend cpu_has_xen_{ibt,shstk}") this has been
> integrated into cpu_has_xen_shstk.
>
> Signed-off-by: Jan Beulich
Acked-by: Andrew Cooper
I'm vaguely recall noticing that after your original patch, but never
got around to
Shadow stacks contain little more than return addresses, and they in
particular allow precise call traces also without FRAME_POINTER.
Signed-off-by: Jan Beulich
---
While the 'E' for exception frames is probably okay, I'm not overly
happy with the 'C' (for CET). I would have preferred 'S' (for
With the value recorded on entry there's no need anymore to go hunt for
the respective exception frame on the shadow stack. By deriving "ptr"
from that field (without any offset), it then ends up pointin one slot
lower than before. Therefore all array indexes need incrementing, nicely
doing away
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 points do
not need to record that value.
To keep the saving code simple, record our own SSP
As of 72d51813d631 ("x86: amend cpu_has_xen_{ibt,shstk}") this has been
integrated into cpu_has_xen_shstk.
Signed-off-by: Jan Beulich
--- a/xen/arch/x86/setup.c
+++ b/xen/arch/x86/setup.c
@@ -810,7 +810,7 @@ static void __init noreturn reinit_bsp_s
if ( rc )
panic("Error %d
One might think of this as follow-on to XSA-451, but that's not quite
the right order of events.
There are a few open aspects; see individual patches.
1: remove redundant XEN_SHSTK check from reinit_bsp_stack()
2: record SSP at non-guest entry points
3: traps: use entry_ssp in
Hi Jan,
On 28/02/2024 12:58, Jan Beulich wrote:
On 28.02.2024 12:50, Julien Grall wrote:
On 27/02/2024 13:19, Jan Beulich wrote:
All,
the release is due in two to three weeks. Please point out backports you find
missing from the respective staging branch, but which you consider relevant.
On Wed, Feb 28, 2024 at 8:28 AM Roger Pau Monné wrote:
>
> On Wed, Feb 28, 2024 at 12:18:31PM +0100, Jan Beulich wrote:
> > On 28.02.2024 11:53, Roger Pau Monné wrote:
> > > On Fri, Feb 23, 2024 at 08:43:24AM +0100, Jan Beulich wrote:
> > >> On 22.02.2024 19:03, Tamas K Lengyel wrote:
> > >>> On
On Wed, Feb 28, 2024 at 12:18:31PM +0100, Jan Beulich wrote:
> On 28.02.2024 11:53, Roger Pau Monné wrote:
> > On Fri, Feb 23, 2024 at 08:43:24AM +0100, Jan Beulich wrote:
> >> On 22.02.2024 19:03, Tamas K Lengyel wrote:
> >>> On Thu, Feb 22, 2024 at 5:06 AM Jan Beulich wrote:
> On
On 28/02/2024 1:26 pm, Roger Pau Monné wrote:
> On Wed, Feb 28, 2024 at 02:04:23PM +0100, Jan Beulich wrote:
>> On 28.02.2024 13:19, Andrew Cooper wrote:
>>> Take 2, hopefully with Stewart's correct email address this time.
>>>
>>> ~Andrew
>>>
>>> On 28/02/2024 12:17 pm, Andrew Cooper wrote:
On Wed, Feb 28, 2024 at 02:04:23PM +0100, Jan Beulich wrote:
> On 28.02.2024 13:19, Andrew Cooper wrote:
> > Take 2, hopefully with Stewart's correct email address this time.
> >
> > ~Andrew
> >
> > On 28/02/2024 12:17 pm, Andrew Cooper wrote:
> >> Not sure how well this is going to be
On 28.02.2024 13:19, Andrew Cooper wrote:
> Take 2, hopefully with Stewart's correct email address this time.
>
> ~Andrew
>
> On 28/02/2024 12:17 pm, Andrew Cooper wrote:
>> Not sure how well this is going to be formatted, but there's one new and
>> potentially interesting issue found by
On 28.02.2024 12:50, Julien Grall wrote:
> On 27/02/2024 13:19, Jan Beulich wrote:
>> All,
>>
>> the release is due in two to three weeks. Please point out backports you find
>> missing from the respective staging branch, but which you consider relevant.
>
> For Arm:
>
> e11f576650 ("xen/arm:
Hi Julien,
On 2/28/2024 8:27 PM, Julien Grall wrote:
Hi Henry,
After checking the code flow, below rough plan came to my mind, I
think what we need to do is:
(1) Find a range of un-used memory using similar method in
find_unallocated_memory()/find_domU_holes()
AFAIK, the toolstack doesn't
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_CONSOLE in
>> TEMPORARY_EARLY_UART_VIRTUAL_ADDRESS macro. This results in a build
>> failure on arm32, when early
Hi Henry,
On 28/02/2024 11:53, Henry Wang wrote:
On 2/28/2024 6:35 PM, Julien Grall wrote:
Hi Henry,
Force populate_physmap to take the "normal" memory allocation route
for
the magic pages even for 1:1 Dom0less DomUs. This should work as long
as the 1:1 Dom0less DomU doesn't have anything
Take 2, hopefully with Stewart's correct email address this time.
~Andrew
On 28/02/2024 12:17 pm, Andrew Cooper wrote:
> Not sure how well this is going to be formatted, but there's one new and
> potentially interesting issue found by Coverity.
>
> ~Andrew
>
> 8<
>
> New defect(s)
Hi everyone,
Thank you for contributing your feedback to the recent survey.
A lot of you wrote detailed responses and gave specific feedback as to what
the community was doing well on, and what we could improve.
I've spent a significant amount of time collating these responses and would
like to
Not sure how well this is going to be formatted, but there's one new and
potentially interesting issue found by Coverity.
~Andrew
8<
New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)
** CID 1592633: (LOCK_EVASION)
/xen/drivers/vpci/header.c: 229 in
On 28/02/2024 11:42, Julien Grall wrote:
Hi Michal,
On 28/02/2024 10:35, Michal Orzel wrote:
Commit 0441c3acc7e9 forgot to rename FIXMAP_CONSOLE to FIX_CONSOLE in
TEMPORARY_EARLY_UART_VIRTUAL_ADDRESS macro. This results in a build
failure on arm32, when early printk is enabled:
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
since it now shares the same implementation as the PPC-specific code.
The MISRA exclude
Hi Julien,
On 2/28/2024 6:35 PM, Julien Grall wrote:
Hi Henry,
Force populate_physmap to take the "normal" memory allocation route
for
the magic pages even for 1:1 Dom0less DomUs. This should work as long
as the 1:1 Dom0less DomU doesn't have anything else mapped at the same
guest address
Hi Jan,
On 27/02/2024 13:19, Jan Beulich wrote:
All,
the release is due in two to three weeks. Please point out backports you find
missing from the respective staging branch, but which you consider relevant.
For Arm:
e11f576650 ("xen/arm: Fix UBSAN failure in start_xen()")
Cheers,
--
On 28/02/2024 8:27 am, Jan Beulich wrote:
> On 27.02.2024 15:57, Andrew Cooper wrote:
>> Looking at the XenServer patchqueue, a couple to consider but nothing
>> jumps out as critically urgent.
>>
>> b6cf604207fd and 098d868e52ac as oxenstored perf fixes, although there's
>> one incremental
Hi Michal,
On 28/02/2024 10:35, Michal Orzel wrote:
Commit 0441c3acc7e9 forgot to rename FIXMAP_CONSOLE to FIX_CONSOLE in
TEMPORARY_EARLY_UART_VIRTUAL_ADDRESS macro. This results in a build
failure on arm32, when early printk is enabled:
arch/arm/arm32/mmu/head.S:311: Error: invalid operands
From: Pritha Srivastava
xl now knows how to drive tapdisk, so modify libxenstat to
understand vbd3 statistics.
Signed-off-by: Pritha Srivastava
Signed-off-by: Jorge Martin
Signed-off-by: Fouad Hilly
---
CC: Wei Liu
CC: Anthony PERARD
CC: Juergen Gross
v2:
- Fix order of SoB
- Fix Syntax
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 them as a compliance mechanism. An interesting aspect is what
would be the consensus around void
On 28/02/2024 9:10 am, Jan Beulich wrote:
> On 27.02.2024 17:09, Andrew Cooper wrote:
>> From v6.8-rc8
> Typo or time leap? There wasn't even rc7 yet ...
Oops yes. A typo.
d206a76d7d27 - (tag: v6.8-rc6) Linux 6.8-rc6 (3 days ago)
>
>> Signed-off-by: Andrew Cooper
> Acked-by: Jan Beulich
On 28.02.2024 12:06, Nicola Vetrini wrote:
> On 2024-02-27 13:47, Jan Beulich wrote:
>> On 27.02.2024 12:52, Julien Grall wrote:
>>> Do you have another proposal? As Stefano said, we adopted the rule
>>> 17.7.
>>> So we know need a solution to address it.
>>
>> One possibility that was circulated
On 28.02.2024 11:53, Roger Pau Monné wrote:
> On Fri, Feb 23, 2024 at 08:43:24AM +0100, Jan Beulich wrote:
>> On 22.02.2024 19:03, Tamas K Lengyel wrote:
>>> On Thu, Feb 22, 2024 at 5:06 AM Jan Beulich wrote:
On 22.02.2024 10:05, Roger Pau Monne wrote:
> The usage of a cmpxchg loop in
On 2024-02-28 03:10, Stefano Stabellini wrote:
On Tue, 27 Feb 2024, Jan Beulich wrote:
On 27.02.2024 12:52, Julien Grall wrote:
> Hi Jan,
>
> On 27/02/2024 07:28, Jan Beulich wrote:
>> On 27.02.2024 01:26, Stefano Stabellini wrote:
>>> On Mon, 26 Feb 2024, Jan Beulich wrote:
On 23.02.2024
On 2024-02-27 13:47, Jan Beulich wrote:
On 27.02.2024 12:52, Julien Grall wrote:
Hi Jan,
On 27/02/2024 07:28, Jan Beulich wrote:
On 27.02.2024 01:26, Stefano Stabellini wrote:
On Mon, 26 Feb 2024, Jan Beulich wrote:
On 23.02.2024 10:35, Nicola Vetrini wrote:
Refactor
On Fri, Feb 23, 2024 at 08:43:24AM +0100, Jan Beulich wrote:
> On 22.02.2024 19:03, Tamas K Lengyel wrote:
> > On Thu, Feb 22, 2024 at 5:06 AM Jan Beulich wrote:
> >> On 22.02.2024 10:05, Roger Pau Monne wrote:
> >>> The usage of a cmpxchg loop in get_next_handle() is unnecessary, as the
> >>>
Commit 0441c3acc7e9 forgot to rename FIXMAP_CONSOLE to FIX_CONSOLE in
TEMPORARY_EARLY_UART_VIRTUAL_ADDRESS macro. This results in a build
failure on arm32, when early printk is enabled:
arch/arm/arm32/mmu/head.S:311: Error: invalid operands (*UND* and *ABS*
sections) for `*'
Fixes: 0441c3acc7e9
Hi Henry,
On 27/02/2024 13:17, Henry Wang wrote:
(-RISC-V and PPC people to avoid spamming their inbox as this is quite
Arm specific)
Hi Julien,
On 2/26/2024 5:13 PM, Julien Grall wrote:
Hi Henry,
Welcome back!
Thanks!
On 26/02/2024 01:19, Henry Wang wrote:
An error message can seen
flight 184786 xen-4.17-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184786/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-i386-xl-qemuu-win7-amd64 19 guest-stop fail like 184564
test-armhf-armhf-libvirt 16
On Tue, 2024-02-27 at 08:38 +0100, Jan Beulich wrote:
> On 26.02.2024 18: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,
On 27.02.2024 17:09, Andrew Cooper wrote:
> From v6.8-rc8
Typo or time leap? There wasn't even rc7 yet ...
> Signed-off-by: Andrew Cooper
Acked-by: Jan Beulich
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/docs/misra/deviations.rst
> @@
flight 184803 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/184803/
Perfect :-)
All tests in this flight passed as required
version targeted for testing:
ovmf 3e91e421365027ee3e655feab33c67a4f544c777
baseline version:
ovmf
Update ECLAIR configuration to deviate more cases where an
unintentional fallthrough cannot happen.
Signed-off-by: Federico Serafini
---
.../eclair_analysis/ECLAIR/deviations.ecl | 15 +--
docs/misra/deviations.rst | 19 ++-
2 files changed,
On 27.02.2024 15:57, Andrew Cooper wrote:
> Looking at the XenServer patchqueue, a couple to consider but nothing
> jumps out as critically urgent.
>
> b6cf604207fd and 098d868e52ac as oxenstored perf fixes, although there's
> one incremental (non-functional) fix I'm still waiting on an ack on.
87 matches
Mail list logo
