Hi Julien,
On 16.05.2022 19:02, Julien Grall wrote:
> +static int cpu_callback(struct notifier_block *nfb, unsigned long action,
> +void *hcpu)
> +{
> +unsigned long cpu = (unsigned long)hcpu;
As cpu does not change in this function, shouldn't we mark it as const?
> +
flight 170492 xen-unstable real [real]
flight 170502 xen-unstable real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/170492/
http://logs.test-lab.xenproject.org/osstest/logs/170502/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd6
Hi Julien
> -Original Message-
> From: Julien Grall
> Sent: Tuesday, May 17, 2022 2:29 AM
> To: Penny Zheng ; xen-devel@lists.xenproject.org
> Cc: Wei Chen ; Andrew Cooper
> ; George Dunlap ;
> Jan Beulich ; Stefano Stabellini ;
> Wei Liu
> Subject: Re: [PATCH v4 6/6] xen: retrieve reser
Hi Oleksandr,
> -Original Message-
> From: Oleksandr Tyshchenko
> Subject: [PATCH V1] libxl/arm: Insert "xen,dev-domid" property to virtio-
> mmio device node
>
> From: Oleksandr Tyshchenko
>
> Use specific binding for the virtio devices for which the restricted
> memory access using X
flight 170498 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170498/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170489 qemu-mainline real [real]
flight 170496 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/170489/
http://logs.test-lab.xenproject.org/osstest/logs/170496/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-am
flight 170497 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170497/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170495 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170495/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170494 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170494/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Julien,
> -Original Message-
> From: Julien Grall
> Sent: 2022年5月17日 1:15
> To: Wei Chen ; xen-devel@lists.xenproject.org
> Cc: nd ; Stefano Stabellini ; Bertrand
> Marquis ; Volodymyr Babchuk
> ; Jiamei Xie ; Julien
> Grall
> Subject: Re: [PATCH v3 1/9] xen/arm: Print a 64-bit number
flight 170493 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170493/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Sat, May 07, 2022 at 09:19:06PM +0300, Oleksandr Tyshchenko wrote:
> From: Oleksandr Tyshchenko
>
> Introduce Xen specific binding for the virtualized device (e.g. virtio)
> to be used by Xen grant DMA-mapping layer in the subsequent commit.
>
> This binding indicates that Xen grant mappings
flight 170491 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170491/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170486 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170486/
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 170490 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170490/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170488 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170488/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170478 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170478/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 7 xen-install fail in
170468 pass in 170478
test-amd64-i
On 5/16/22 2:30 PM, Oleksandr wrote:
On 16.05.22 19:00, Boris Ostrovsky wrote:
With the error handling in gnttab_init() fixed
yes, this is a diff that I am going to apply for the next version:
[snip]
@@ -1596,19 +1601,20 @@ static int gnttab_expand(unsigned int req_entries)
int gntt
flight 170487 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170487/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 16.05.22 19:00, Boris Ostrovsky wrote:
Hello Boris
On 5/16/22 1:59 AM, Juergen Gross wrote:
On 14.05.22 04:34, Boris Ostrovsky wrote:
On 5/13/22 1:33 AM, Juergen Gross wrote:
On 12.05.22 22:01, Boris Ostrovsky wrote:
On 5/7/22 2:19 PM, Oleksandr Tyshchenko wrote:
+/* Rebuilds
Hi Penny,
On 10/05/2022 03:27, Penny Zheng wrote:
When static domain populates memory through populate_physmap on runtime,
Typo: s/when static/when a static/ or "when static domains populate"
s/on runtime/at runtime/
other than allocating from heap, it shall retrieve reserved pages from
I
Hi Penny,
On 10/05/2022 03:27, Penny Zheng wrote:
Pages used as guest RAM for static domain, shall be reserved to this
domain only.
So in case reserved pages being used for other purpose, users
shall not free them back to heap, even when last ref gets dropped.
free_staticmem_pages will be calle
flight 170485 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170485/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 5/13/22 5:19 PM, Stefano Stabellini wrote:
From: Stefano Stabellini
Sync the xs_wire.h header file in Linux with the one in Xen.
Signed-off-by: Stefano Stabellini
---
Changes in v5:
- add XSD_ERROR(E2BIG)
- Boris gave his reviewed-by but due to this change I removed it
Reviewed-by: B
Hi Penny,
On 10/05/2022 03:27, Penny Zheng wrote:
The code in free_heap_pages() will try to merge pages with the
successor/predecessor if pages are suitably aligned. So if the pages
reserved are right next to the pages given to the heap allocator,
free_heap_pages() will merge them, and give the
Hi Jan,
On 06/05/2022 14:46, Jan Beulich wrote:
On 06.05.2022 15:43, Julien Grall wrote:
You say future, has this option been merged or still in discussion on
the ML?
"future" as in "no released version yet". The change is present on the
binutils master branch.
Thanks for the clarification.
Hi Catalin,
On 10/05/2022 09:55, Catalin Marinas wrote:
On Tue, May 10, 2022 at 09:27:29AM +0100, Julien Grall wrote:
Hi,
On 10/05/2022 07:49, Michal Orzel wrote:
On 05.05.2022 14:13, Catalin Marinas wrote:
On Thu, May 05, 2022 at 01:59:06PM +0200, Michal Orzel wrote:
Value of macro MIDR_IM
On 10/05/2022 15:21, Andrew Cooper wrote:
On 10/05/2022 15:05, Anthony PERARD wrote:
Signed-off-by: Anthony PERARD
Acked-by: Andrew Cooper
Committed.
Thanks,
--
Julien Grall
Hi,
On 11/05/2022 02:46, Wei Chen wrote:
Current putn function that is using for early print
only can print low 32-bit of AArch64 register. This
will lose some important messages while debugging
with early console. For example:
(XEN) Bringing up CPU5
- CPU 00010100 booting -
Will be trun
On 15/05/2022 11:58, Julien Grall wrote:
On 07/05/2022 03:54, Henry Wang wrote:
With the enhanced ASSERT_ALLOC_CONTEXT, calling request_irq before
local_irq_enable on secondary cores will lead to
(XEN) Xen call trace:
(XEN) [<0021d86c>] alloc_xenheap_pages+0x74/0x194 (PC)
(XEN) [<000
From: Julien Grall
Commit 88a037e2cfe1 "page_alloc: assert IRQs are enabled in heap
alloc/free" extended the checks in the buddy allocator to catch any
use of the helpers from context with interrupts disabled.
Unfortunately, the rule is not followed in the LPI code when allocating
the pending ta
On 16/05/2022 10:50, Julien Grall wrote:
@@ -381,6 +410,7 @@ integer_param("max_lpi_bits", max_lpi_bits);
int gicv3_lpi_init_host_lpis(unsigned int host_lpi_bits)
{
unsigned int nr_lpi_ptrs;
+ int rc;
/* We rely on the data structure being atomically accessible. */
BUILD_BUG_ON
flight 170484 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170484/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On 16/05/2022 13:18, Luck, Tony wrote:
>> [...]
> Would it be possible to have some global "kdump is configured + enabled" flag?
>
> Then notifiers could make an informed choice on whether to deep dive to
> get all the possible details (when there is no kdump) or just skim the high
> level stuff (
On 16/05/2022 07:21, Petr Mladek wrote:
> [...]
> Ah, it should have been:
>
> + notifiers vs. kmsg_dump
> + notifiers vs. crash_dump
> + crash_dump vs. kmsg_dump
>
> I am sorry for the confusion. Even "crash_dump" is slightly
> misleading because there is no function with this nam
> So, my reasoning here is: this notifier should fit the info list,
> definitely! But...it's very high risk for kdump. It deep dives into the
> regmap API (there are locks in such code) plus there is an (MM)IO write
> to the device and an ARM firmware call. So, despite the nature of this
> notifier
On 10/05/2022 14:29, Steven Rostedt wrote:
> [...]
> Also, don't sprinkle #ifdef in C code. Instead:
>
> if (IS_ENABLED(CONFIG_DEBUG_NOTIFIERS))
> pr_info("notifers: regsiter %ps()\n",
> n->notifer_call);
>
>
> Or define a print macro at the start of the
On 16/05/2022 11:56, Petr Mladek wrote:
> [...]
> I really like both changes. Just please split it them into two
> patchset. I mean one patch for the new "panic_console_replay"
> parameter and 2nd that moves "printk_info" into the notifier.
>
OK sure, will do that in V2.
Thanks,
Guilherme
On Mon, May 16, 2022 at 8:07 AM Guilherme G. Piccoli
wrote:
>
> Thanks for the review!
>
> I agree with the blinking stuff, I can rework and add all LED/blinking
> stuff into the loop list, it does make sense. I'll comment a bit in the
> others below...
>
> On 16/05/2022 11:01, Petr Mladek wrote:
On 16/05/2022 11:50, Petr Mladek wrote:
> [...]
> Shame on me that I do not care that much about the style of the commit
> message :-)
>
> Anyway, the code looks good to me. With the better commit message:
>
> Reviewed-by: Petr Mladek
>
Heheh, cool - I'll add your tag and improve the message i
On 16/05/2022 11:45, Petr Mladek wrote:
> [...]
>
> The patch looks good to me. I would just suggest two changes.
>
> 1. I would rename the list to "panic_loop_list" instead of
>"panic_post_reboot_list".
>
>It will be more clear that it includes things that are
>needed before panic()
On 5/16/22 1:59 AM, Juergen Gross wrote:
On 14.05.22 04:34, Boris Ostrovsky wrote:
On 5/13/22 1:33 AM, Juergen Gross wrote:
On 12.05.22 22:01, Boris Ostrovsky wrote:
On 5/7/22 2:19 PM, Oleksandr Tyshchenko wrote:
+/* Rebuilds the free grant list and tries to find count consecutive ent
Thanks again for the review! Comments inline below:
On 16/05/2022 11:33, Petr Mladek wrote:
> [...]
>> --- a/drivers/edac/altera_edac.c
>> +++ b/drivers/edac/altera_edac.c
>> @@ -2163,7 +2162,7 @@ static int altr_edac_a10_probe(struct platform_device
>> *pdev)
>> int dberror, err_ad
flight 170472 linux-linus real [real]
flight 170482 linux-linus real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/170472/
http://logs.test-lab.xenproject.org/osstest/logs/170482/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-arm64-
flight 170483 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170483/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
> On May 16, 2022, at 4:20 PM, Julien Grall wrote:
>
>
>
> On 16/05/2022 16:04, Andrew Cooper wrote:
>> On 13/05/2022 15:33, George Dunlap wrote:
>
>> IMO, a commit message saying "port $X from project $Y" makes it crystal
>> clear that the original code change isn't mine, but the porting ef
On 16/05/2022 16:04, Andrew Cooper wrote:
On 13/05/2022 15:33, George Dunlap wrote:
Starting a new thread to make it clear that we’re discussing a wider policy
here.
This question is aimed at Jan and Andy in particular, as I think they’ve
probably done the most of this; so I’m looking to t
> On May 16, 2022, at 4:04 PM, Andrew Cooper wrote:
>
>>
>> 4) When importing an entire file from an upstream like Linux, what tags do
>> we need?
>
> Any clear reference to where it came from.
>
> Nothing is ever imported verbatim. If nothing else, paths have to be
> changed, and usually
Thanks for the review!
I agree with the blinking stuff, I can rework and add all LED/blinking
stuff into the loop list, it does make sense. I'll comment a bit in the
others below...
On 16/05/2022 11:01, Petr Mladek wrote:
> [...]
>> --- a/arch/mips/sgi-ip22/ip22-reset.c
>> +++ b/arch/mips/sgi-ip2
On 13/05/2022 15:33, George Dunlap wrote:
> Starting a new thread to make it clear that we’re discussing a wider policy
> here.
>
> This question is aimed at Jan and Andy in particular, as I think they’ve
> probably done the most of this; so I’m looking to them to find out what our
> “standard p
On Wed 2022-04-27 19:49:19, Guilherme G. Piccoli wrote:
> Currently the parameter "panic_print" relies in a function called
> directly on panic path; one of the flags the users can set for
> panic_print triggers a console replay mechanism, to show the
> entire kernel log buffer (from the beginning)
flight 170481 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170481/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Wed 2022-05-11 17:03:51, Guilherme G. Piccoli wrote:
> On 10/05/2022 14:40, Steven Rostedt wrote:
> > On Wed, 27 Apr 2022 19:49:17 -0300
> > "Guilherme G. Piccoli" wrote:
> >
> >> Currently we don't have a way to check if there are dumpers set,
> >> except counting the list members maybe. This
On 16/05/2022 15:31, Roger Pau Monne wrote:
> Booting with Shadow Stacks leads to the following assert on a debug
> hypervisor:
>
> (XEN) [ 11.625166] Assertion 'local_irq_is_enabled()' failed at
> arch/x86/smp.c:265
> (XEN) [ 11.629410] [ Xen-4.17.0-10.24-d x86_64 debug=y Not tainted
On Wed 2022-04-27 19:49:16, Guilherme G. Piccoli wrote:
> Currently we have 3 notifier lists in the panic path, which will
> be wired in a way to allow the notifier callbacks to run in
> different moments at panic time, in a subsequent patch.
>
> But there is also an odd set of architecture calls
On Mon, May 16, 2022 at 01:12:03PM +0200, Roger Pau Monne wrote:
> Booting with Shadow Stacks leads to the following assert on a debug
> hypervisor:
>
> (XEN) [ 11.625166] Assertion 'local_irq_is_enabled()' failed at
> arch/x86/smp.c:265
> (XEN) [ 11.629410] [ Xen-4.17.0-10.24-d x86_64
Booting with Shadow Stacks leads to the following assert on a debug
hypervisor:
(XEN) [ 11.625166] Assertion 'local_irq_is_enabled()' failed at
arch/x86/smp.c:265
(XEN) [ 11.629410] [ Xen-4.17.0-10.24-d x86_64 debug=y Not tainted
]
(XEN) [ 11.633679] CPU:0
(XEN) [ 11.63783
On Wed 2022-04-27 19:49:15, Guilherme G. Piccoli wrote:
> This patch renames the panic_notifier_list to panic_pre_reboot_list;
> the idea is that a subsequent patch will refactor the panic path
> in order to better split the notifiers, running some of them very
> early, some of them not so early [b
On 16/05/2022 11:11, Petr Mladek wrote:
> [...]
>
> All notifiers moved in this patch seems to fit well the "info"
> notifier list. The patch looks good from this POV.
>
> I still have to review the rest of the patches to see if it
> is complete.
>
> Best Regards,
> Petr
Thanks a bunch for the
On Wed 2022-04-27 19:49:14, Guilherme G. Piccoli wrote:
> The goal of this new panic notifier is to allow its users to
> register callbacks to run earlier in the panic path than they
> currently do. This aims at informational mechanisms, like dumping
> kernel offsets and showing device error data (
flight 170480 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170480/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
On Wed 2022-04-27 19:49:13, Guilherme G. Piccoli wrote:
> The goal of this new panic notifier is to allow its users to register
> callbacks to run very early in the panic path. This aims hypervisor/FW
> notification mechanisms as well as simple LED functions, and any other
> simple and safe mechani
On Mon, May 16, 2022 at 08:48:17AM +0200, Juergen Gross wrote:
> On 14.05.22 17:55, Demi Marie Obenour wrote:
> > In https://github.com/QubesOS/qubes-issues/issues/7481, a user reported
> > that Xorg locked up when resizing a VM window. While I do not have the
> > same hardware the user does and t
On 16.05.22 15:12, George Dunlap wrote:
On May 13, 2022, at 3:52 PM, Juergen Gross wrote:
On 13.05.22 16:33, George Dunlap wrote:
Starting a new thread to make it clear that we’re discussing a wider policy
here.
This question is aimed at Jan and Andy in particular, as I think they’ve
prob
> On May 13, 2022, at 3:52 PM, Juergen Gross wrote:
>
> On 13.05.22 16:33, George Dunlap wrote:
>> Starting a new thread to make it clear that we’re discussing a wider policy
>> here.
>> This question is aimed at Jan and Andy in particular, as I think they’ve
>> probably done the most of this
flight 170477 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170477/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
flight 170468 qemu-mainline real [real]
flight 170475 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/170468/
http://logs.test-lab.xenproject.org/osstest/logs/170475/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On 13/05/2022 16:39, Roger Pau Monné wrote:
> On Wed, May 11, 2022 at 04:14:23PM +0100, Jane Malalane wrote:
>> Have is_hvm_pv_evtchn_vcpu() return true for vector callbacks for
>> evtchn delivery set up on a per-vCPU basis via
>> HVMOP_set_evtchn_upcall_vector.
>>
>> is_hvm_pv_evtchn_vcpu() return
Hi Julien,
> On 16 May 2022, at 10:50, Julien Grall wrote:
>
>
>
> On 16/05/2022 10:24, Bertrand Marquis wrote:
>> Hi Julien,
>
> Hi Bertrand,
>
>>> On 16 May 2022, at 09:45, Julien Grall wrote:
>>>
>>> From: Julien Grall
>>>
>>> Commit 88a037e2cfe1 "page_alloc: assert IRQs are enabled i
flight 170476 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170476/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Booting with Shadow Stacks leads to the following assert on a debug
hypervisor:
(XEN) [ 11.625166] Assertion 'local_irq_is_enabled()' failed at
arch/x86/smp.c:265
(XEN) [ 11.629410] [ Xen-4.17.0-10.24-d x86_64 debug=y Not tainted
]
(XEN) [ 11.633679] CPU:0
(XEN) [ 11.63783
On 16/05/2022 11:36, Roger Pau Monne wrote:
> Fixes: 5a211704e8 ('mwait-idle: prevent SKL-H boot failure when C8+C9+C10
> enabled')
> Signed-off-by: Roger Pau Monné
Acked-by: Andrew Cooper
flight 170474 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170474/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Fixes: 5a211704e8 ('mwait-idle: prevent SKL-H boot failure when C8+C9+C10
enabled')
Signed-off-by: Roger Pau Monné
---
xen/arch/x86/cpu/mwait-idle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/cpu/mwait-idle.c b/xen/arch/x86/cpu/mwait-idle.c
index 6add64dc5f.
On Sun 2022-05-15 19:47:39, Guilherme G. Piccoli wrote:
> On 12/05/2022 11:03, Petr Mladek wrote:
> > This talks only about kdump. The reality is much more complicated.
> > The level affect the order of:
> >
> > + notifiers vs. kdump
> > + notifiers vs. crash_dump
> > + crash_dump vs.
Hi Michal,
On 06/05/2022 10:42, Michal Orzel wrote:
Modify macros to evaluate all the arguments and make sure the arguments
are evaluated only once. Introduce following intermediate macros:
gnttab_status_gfn_, gnttab_shared_gfn_ that do not take domain as a
parameter. These are to be used locall
flight 170470 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170470/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-armhf-libvirt 6 libvirt-buildfail REGR. vs. 151777
build-amd64-libvirt
On 16/05/2022 10:24, Bertrand Marquis wrote:
Hi Julien,
Hi Bertrand,
On 16 May 2022, at 09:45, Julien Grall wrote:
From: Julien Grall
Commit 88a037e2cfe1 "page_alloc: assert IRQs are enabled in heap
alloc/free" extended the checks in the buddy allocator to catch any
use of the helpers
flight 170473 ovmf real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170473/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-xsm 6 xen-buildfail REGR. vs. 168254
build-amd64
Hi Julien,
> On 16 May 2022, at 09:45, Julien Grall wrote:
>
> From: Julien Grall
>
> Commit 88a037e2cfe1 "page_alloc: assert IRQs are enabled in heap
> alloc/free" extended the checks in the buddy allocator to catch any
> use of the helpers from context with interrupts disabled.
>
> Unfortun
From: Julien Grall
Commit 88a037e2cfe1 "page_alloc: assert IRQs are enabled in heap
alloc/free" extended the checks in the buddy allocator to catch any
use of the helpers from context with interrupts disabled.
Unfortunately, the rule is not followed in the LPI code when allocating
the pending ta
flight 170465 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/170465/
Failures :-/ but no regressions.
Tests which are failing intermittently (not blocking):
test-amd64-amd64-qemuu-nested-intel 12 debian-hvm-install fail in 170404 pass
in 170465
test-armhf-armhf-xl-rt
On Sun, May 08, 2022 at 10:34:43AM +0200, Jan Beulich wrote:
> On 06.05.2022 17:35, Roger Pau Monné wrote:
> > On Fri, May 06, 2022 at 03:31:12PM +0200, Roger Pau Monné wrote:
> >> On Fri, May 06, 2022 at 02:56:56PM +0200, Jan Beulich wrote:
> >>> On 05.05.2022 16:21, Roger Pau Monne wrote:
>
83 matches
Mail list logo
