On 14.06.2022 18:22, Anthony PERARD wrote:
> The command line generated for headers++.chk by make is quite long,
> and in some environment it is too long. This issue have been seen in
> Yocto build environment.
>
> Error messages:
> make[9]: execvp: /bin/sh: Argument list too long
> make[9
Hi Oleksandr,
On Mon, Jun 6, 2022 at 10:16 AM Oleksandr Tyshchenko
wrote:
> The high level idea is to create new Xen’s grant table based DMA-mapping
> layer for the guest Linux whose main
> purpose is to provide a special 64-bit DMA address which is formed by using
> the grant reference (for a
On 14.06.2022 18:22, Anthony PERARD wrote:
> --- a/xen/Makefile
> +++ b/xen/Makefile
> @@ -22,6 +22,7 @@ PYTHON_INTERPRETER := $(word 1,$(shell which python3
> python python2 2>/dev/null)
> export PYTHON?= $(PYTHON_INTERPRETER)
>
> export CHECKPOLICY ?= checkpolicy
> +export
On Tue, 14 Jun 2022 17:24:48 +0100,
Mark Rutland wrote:
>
> On Wed, Jun 08, 2022 at 04:27:46PM +0200, Peter Zijlstra wrote:
> > Ever since commit d3afc7f12987 ("arm64: Allow IPIs to be handled as
> > normal interrupts") this function is called in regular IRQ context.
> >
> > Signed-off-by: Peter
Hi,
Adding Aaro Koskinen and Peter Vasil for pm24xx for n800 and n810 related
idle.
* Peter Zijlstra [220614 22:07]:
> On Mon, Jun 13, 2022 at 03:39:05PM +0300, Tony Lindgren wrote:
> > OMAP4 uses full SoC suspend modes as idle states, as such it needs the
> > whole power-domain and clock-domain
On Mon, Jun 13, 2022 at 07:23:13PM +, Nadav Amit wrote:
> On Jun 13, 2022, at 11:48 AM, Srivatsa S. Bhat wrote:
>
> > ⚠ External Email
> >
> > On 6/8/22 4:27 PM, Peter Zijlstra wrote:
> >> vmlinux.o: warning: objtool: acpi_idle_enter_s2idle+0xde: call to wbinvd()
> >> leaves .noinstr.text s
On Tue, Jun 14, 2022 at 05:13:16PM +0100, Mark Rutland wrote:
> On Wed, Jun 08, 2022 at 04:27:38PM +0200, Peter Zijlstra wrote:
> > All callers should still have RCU enabled.
>
> IIUC with that true we should be able to drop the RCU_NONIDLE() from
> drivers/perf/arm_pmu.c, as we only needed that f
On Tue, Jun 14, 2022 at 01:41:13PM +0100, Mark Rutland wrote:
> On Wed, Jun 08, 2022 at 04:27:37PM +0200, Peter Zijlstra wrote:
> > --- a/kernel/time/tick-broadcast.c
> > +++ b/kernel/time/tick-broadcast.c
> > @@ -622,9 +622,13 @@ struct cpumask *tick_get_broadcast_onesh
> > * to avoid a deep idl
On Tue, Jun 14, 2022 at 12:19:29PM +0100, Mark Rutland wrote:
> On Wed, Jun 08, 2022 at 04:27:23PM +0200, Peter Zijlstra wrote:
> > Hi All! (omg so many)
>
> Hi Peter,
>
> Sorry for the delay; my plate has also been rather full recently. I'm
> beginning
> to page this in now.
No worries; we all
On Mon, Jun 13, 2022 at 03:39:05PM +0300, Tony Lindgren wrote:
> OMAP4 uses full SoC suspend modes as idle states, as such it needs the
> whole power-domain and clock-domain code from the idle path.
>
> All that code is not suitable to run with RCU disabled, as such push
> RCU-idle deeper still.
>
On Wed, Jun 08, 2022 at 04:27:39PM +0200, Peter Zijlstra wrote:
> Current rcu_idle_exit() is terminally broken because it uses
> local_irq_{save,restore}(), which are traced which uses RCU.
>
> However, now that all the callers are sure to have IRQs disabled, we
> can remove these calls.
>
> Sign
On Tue, Jun 14, 2022 at 06:58:30PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 14, 2022 at 12:19:29PM +0100, Mark Rutland wrote:
> > On Wed, Jun 08, 2022 at 04:27:23PM +0200, Peter Zijlstra wrote:
> > > Hi All! (omg so many)
> >
> > Hi Peter,
> >
> > Sorry for the delay; my plate has also been rat
On Tue, Jun 14, 2022 at 06:42:14PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 14, 2022 at 05:13:16PM +0100, Mark Rutland wrote:
> > On Wed, Jun 08, 2022 at 04:27:38PM +0200, Peter Zijlstra wrote:
> > > All callers should still have RCU enabled.
> >
> > IIUC with that true we should be able to drop
On Tue, Jun 14, 2022 at 06:40:53PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 14, 2022 at 01:41:13PM +0100, Mark Rutland wrote:
> > On Wed, Jun 08, 2022 at 04:27:37PM +0200, Peter Zijlstra wrote:
> > > --- a/kernel/time/tick-broadcast.c
> > > +++ b/kernel/time/tick-broadcast.c
> > > @@ -622,9 +622,
On Wed, Jun 08, 2022 at 04:27:39PM +0200, Peter Zijlstra wrote:
> Current rcu_idle_exit() is terminally broken because it uses
> local_irq_{save,restore}(), which are traced which uses RCU.
>
> However, now that all the callers are sure to have IRQs disabled, we
> can remove these calls.
>
> Sign
On Wed, Jun 08, 2022 at 04:27:43PM +0200, Peter Zijlstra wrote:
> Current arch_cpu_idle() is called with IRQs disabled, but will return
> with IRQs enabled.
>
> However, the very first thing the generic code does after calling
> arch_cpu_idle() is raw_local_irq_disable(). This means that
> archite
On Wed, Jun 08, 2022 at 04:27:48PM +0200, Peter Zijlstra wrote:
> No callers left that have already disabled RCU.
>
> Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Mark Rutland
Mark.
> ---
> kernel/time/tick-broadcast-hrtimer.c | 29 -
> 1 file changed, 12 ins
On Wed, Jun 08, 2022 at 04:27:46PM +0200, Peter Zijlstra wrote:
> Ever since commit d3afc7f12987 ("arm64: Allow IPIs to be handled as
> normal interrupts") this function is called in regular IRQ context.
>
> Signed-off-by: Peter Zijlstra (Intel)
[adding Marc since he authored that commit]
Makes
On Wed, Jun 08, 2022 at 04:27:38PM +0200, Peter Zijlstra wrote:
> All callers should still have RCU enabled.
IIUC with that true we should be able to drop the RCU_NONIDLE() from
drivers/perf/arm_pmu.c, as we only needed that for an invocation via a pm
notifier.
I should be able to give that a spi
flight 171170 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171170/
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
virt_vtimer_save is calculating the new time for the vtimer and
has a potential risk of timer flip in:
"v->arch.virt_timer.cval + v->domain->arch.virt_timer_base.offset
- boot_count".
In this formula, "cval + offset" could make uint64_t overflow.
Generally speaking, this is difficult to trigger. Bu
flight 171167 linux-5.4 real [real]
flight 171169 linux-5.4 real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171167/
http://logs.test-lab.xenproject.org/osstest/logs/171169/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
t
On Tue, 14 Jun 2022, Oleksandr wrote:
> On 11.06.22 02:55, Stefano Stabellini wrote:
>
> Hello Stefano
>
> > On Thu, 9 Jun 2022, Oleksandr wrote:
> > > On 04.06.22 00:19, Stefano Stabellini wrote:
> > > Hello Stefano
> > >
> > > Thank you for having a look and sorry for the late response.
> > >
On Tue, 14 Jun 2022, Oleksandr wrote:
> On 11.06.22 03:12, Stefano Stabellini wrote:
> > On Wed, 8 Jun 2022, Oleksandr wrote:
> > > 2. Drop the "page_list" entirely and use "dma_pool" for all (contiguous
> > > and
> > > non-contiguous) allocations. After all, all pages are initially contiguous
> >
On Tue, 14 Jun 2022, Julien Grall wrote:
> From: Julien Grall
>
> Commit 5047cd1d5dea "xen/common: Use enhanced ASSERT_ALLOC_CONTEXT in
> xmalloc()" extended the checks in _xmalloc() to catch any use of the
> helpers from context with interrupts disabled.
>
> Unfortunately, the rule is not follo
On Tue, 14 Jun 2022, Michal Orzel wrote:
> On 14.06.2022 13:08, Julien Grall wrote:
> >>> + unsigned int rc = 0;
> >> ... here you are setting rc to 0 even though it will be reassigned.
> >> Furthermore, if rc is used only in case of CPU_UP_PREPARE, why not moving
> >> the definition there?
> >
flight 171165 qemu-mainline real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171165/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-xl-qemuu-win7-amd64 19 guest-stopfail like 171149
test-armhf-armhf-libvirt 16 sav
flight 171161 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171161/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 170714
test-amd64-amd64-xl
Hello Jens,
Sorry for late review, I was busy with internal projects.
This is preliminary review. I gave up at scatter-gather operations. Need
more time to review them properly.
One thing that bothers me is that Xen is non-preemptive and there are
plenty potentially long-running operations.
J
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Xen Security Advisory CVE-2022-21123,CVE-2022-21124,CVE-2022-21166 / XSA-404
x86: MMIO Stale Data vulnerabilities
ISSUE DESCRIPTION
=
This issue is related to the SRBDS, TAA and MDS vulnerabilities. Please
see:
On 11.06.22 02:55, Stefano Stabellini wrote:
Hello Stefano
On Thu, 9 Jun 2022, Oleksandr wrote:
On 04.06.22 00:19, Stefano Stabellini wrote:
Hello Stefano
Thank you for having a look and sorry for the late response.
On Tue, 17 May 2022, Oleksandr Tyshchenko wrote:
From: Oleksandr Tyshche
On 11.06.22 03:12, Stefano Stabellini wrote:
Hello Stefano
On Wed, 8 Jun 2022, Oleksandr wrote:
2. Drop the "page_list" entirely and use "dma_pool" for all (contiguous and
non-contiguous) allocations. After all, all pages are initially contiguous in
fill_list() as they are built from the r
The command line generated for headers++.chk by make is quite long,
and in some environment it is too long. This issue have been seen in
Yocto build environment.
Error messages:
make[9]: execvp: /bin/sh: Argument list too long
make[9]: *** [include/Makefile:181: include/headers++.chk] Erro
The get-fields.sh which generate all the include/compat/.xlat/*.h
headers is quite slow. It takes for example nearly 3 seconds to
generate platform.h on a recent machine, or 2.3 seconds for memory.h.
Since it's only text processing, rewriting the mix of shell/sed/python
into a single perl script m
We are going to use it in a moment.
Also update README about Perl requirement.
Signed-off-by: Anthony PERARD
---
Notes:
v2:
- update ./README
xen/Makefile | 1 +
README | 1 +
2 files changed, 2 insertions(+)
diff --git a/xen/Makefile b/xen/Makefile
index 82f5310b12..a6650a2acc
Now that the command line generating "xlat.h" is check on rebuild, the
header will be regenerated whenever the list of xlat headers changes
due to change in ".config". We don't need to force a regeneration for
every changes in ".config".
Signed-off-by: Anthony PERARD
Acked-by: Jan Beulich
---
x
Patch series available in this git branch:
https://xenbits.xen.org/git-http/people/aperard/xen-unstable.git
br.build-system-xen-include-rework-v2
v2:
- new patch [1/4] to fix issue with command line that can be way too long
- other small changes, and reorder patches
Hi,
This patch series is abo
On 14.06.2022 18:00, Anthony PERARD wrote:
> On Tue, Jun 14, 2022 at 05:40:27PM +0200, Jan Beulich wrote:
>> GNU make 3.82 apparently has a quirk where exporting an undefined
>> variable prevents its value from subsequently being updated. This
>> situation can arise due to our adding of -rR to MAKE
When some FMA set of insns is included in the base instruction set (XOP,
AVX512F, and AVX512-FP16 at present), simd_test() simply invokes
fma_test(), negating its return value. In case of a failure this would
yield a value close to 4G, which doesn't lend itself to easy
identification of the failing
On Tue, Jun 14, 2022 at 05:40:27PM +0200, Jan Beulich wrote:
> GNU make 3.82 apparently has a quirk where exporting an undefined
> variable prevents its value from subsequently being updated. This
> situation can arise due to our adding of -rR to MAKEFLAGS, which takes
> effect also on make simply
On 14.06.2022 17:40, Jan Beulich wrote:
> GNU make 3.82 apparently has a quirk where exporting an undefined
> variable prevents its value from subsequently being updated. This
> situation can arise due to our adding of -rR to MAKEFLAGS, which takes
> effect also on make simply re-invoking itself. O
GNU make 3.82 apparently has a quirk where exporting an undefined
variable prevents its value from subsequently being updated. This
situation can arise due to our adding of -rR to MAKEFLAGS, which takes
effect also on make simply re-invoking itself. Once these flags are in
effect, CC (in particular
Hi Juergen,
On 14/06/2022 16:31, Juergen Gross wrote:
The loop handling input and output of connections of xenstored is
open coding list_for_each_entry_safe() in an incredibly complicated
way.
Use list_for_each_entry_safe() instead, making it much more clear how
the code is working.
Signed-off
The loop handling input and output of connections of xenstored is
open coding list_for_each_entry_safe() in an incredibly complicated
way.
Use list_for_each_entry_safe() instead, making it much more clear how
the code is working.
Signed-off-by: Juergen Gross
---
tools/xenstore/xenstored_core.c
t:
git://git.kraxel.org/qemu tags/kraxel-20220614-pull-request
for you to fetch changes up to b95b56311a0890da0c9f7fc624529c3d7f8dbce0:
virtio-gpu: Respect UI refresh rate for EDID (2022-06-14 10:34:37 +0200)
usb: add CanoKey device,
On 03.05.22 15:22, Juergen Gross wrote:
x86_has_pat_wp() is using a wrong test, as it relies on the normal
PAT configuration used by the kernel. In case the PAT MSR has been
setup by another entity (e.g. BIOS or Xen hypervisor) it might return
false even if the PAT configuration is allowing WP ma
On Thu, 9 Jun 2022 15:02:20 +0200
Petr Mladek wrote:
> > I'm somewhat curious whether we can actually remove that trace event.
>
> Good question.
>
> Well, I think that it might be useful. It allows to see trace and
> printk messages together.
Yes people still use it. I was just asked about
flight 171160 qemu-mainline real [real]
flight 171163 qemu-mainline real-retest [real]
http://logs.test-lab.xenproject.org/osstest/logs/171160/
http://logs.test-lab.xenproject.org/osstest/logs/171163/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be
On Thu 2022-05-26 13:25:57, Guilherme G. Piccoli wrote:
> OK, so it seems we have some points in which agreement exists, and some
> points that there is no agreement and instead, we have antagonistic /
> opposite views and needs. Let's start with the easier part heh
>
> It seems everybody agrees th
On Wed, Jun 08, 2022 at 04:27:37PM +0200, Peter Zijlstra wrote:
> --- a/kernel/time/tick-broadcast.c
> +++ b/kernel/time/tick-broadcast.c
> @@ -622,9 +622,13 @@ struct cpumask *tick_get_broadcast_onesh
> * to avoid a deep idle transition as we are about to get the
> * broadcast IPI right away.
From: Dongwon Kim
It only needs to update the scanouts containing the rect area
coming with the resource-flush request from the guest.
Cc: Gerd Hoffmann
Cc: Vivek Kasireddy
Signed-off-by: Dongwon Kim
Message-Id: <20220505214030.4261-1-dongwon@intel.com>
Signed-off-by: Gerd Hoffmann
---
From: Joelle van Dyne
When launching QEMU with "-loadvm", usbredir_create_parser() should avoid
setting up the hello packet (just as with "-incoming". On the latest version
of libusbredir, usbredirparser_unserialize() will return error if the parser
is not "pristine."
Signed-off-by: Joelle van D
On Mon, Jun 13, 2022 at 08:52:21AM -0700, Richard Henderson wrote:
> On 6/13/22 04:36, Gerd Hoffmann wrote:
> > The following changes since commit dcb40541ebca7ec98a14d461593b3cd7282b4fac:
> >
> >Merge tag 'mips-20220611' of https://github.com/philmd/qemu into staging
> > (2022-06-11 21:13:27
From: Akihiko Odaki
This change adds a new member, refresh_rate to QemuUIInfo in
include/ui/console.h. It represents the refresh rate of the
physical display backend, and it is more appropriate than
GUI update interval as the refresh rate which the emulated device
reports:
- sdl may set GUI updat
From: Akihiko Odaki
Signed-off-by: Akihiko Odaki
Message-Id: <20220226115516.59830-4-akihiko.od...@gmail.com>
Signed-off-by: Gerd Hoffmann
---
include/hw/virtio/virtio-gpu.h | 1 +
hw/display/virtio-gpu-base.c | 1 +
hw/display/virtio-gpu.c| 1 +
3 files changed, 3 insertions(+)
dif
From: Arnout Engelen
The 'active' bit passes control over a qTD between the guest and the
controller: set to 1 by guest to enable execution by the controller,
and the controller sets it to '0' to hand back control to the guest.
ehci_state_writeback write two dwords to main memory using DMA:
the
From: Akihiko Odaki
The returned value is not used and misleading.
Signed-off-by: Akihiko Odaki
Message-Id: <20220226115516.59830-2-akihiko.od...@gmail.com>
Signed-off-by: Gerd Hoffmann
---
include/ui/console.h | 2 +-
hw/display/virtio-gpu-base.c | 6 +++---
hw/display/virtio-vga.c
From: "Hongren (Zenithal) Zheng"
Signed-off-by: Hongren (Zenithal) Zheng
Message-Id:
Signed-off-by: Gerd Hoffmann
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 0df25ed4b0a3..4cf6174f9f37 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@
From: "Hongren (Zenithal) Zheng"
Signed-off-by: Hongren (Zenithal) Zheng
Message-Id:
Signed-off-by: Gerd Hoffmann
---
hw/usb/canokey.c| 13 +
hw/usb/trace-events | 16
2 files changed, 29 insertions(+)
diff --git a/hw/usb/canokey.c b/hw/usb/canokey.c
index 6c
From: "Hongren (Zenithal) Zheng"
Signed-off-by: Hongren (Zenithal) Zheng
Message-Id:
Signed-off-by: Gerd Hoffmann
---
docs/system/device-emulation.rst | 1 +
docs/system/devices/canokey.rst | 168 +++
2 files changed, 169 insertions(+)
create mode 100644 docs/s
From: "Hongren (Zenithal) Zheng"
Signed-off-by: Hongren (Zenithal) Zheng
Message-Id:
Signed-off-by: Gerd Hoffmann
---
meson_options.txt | 2 ++
hw/usb/Kconfig| 5 +
hw/usb/meson.build| 5 +
meson.build | 6 ++
scripts/meson
From: "Hongren (Zenithal) Zheng"
This commit added a new emulated device called CanoKey to QEMU.
CanoKey implements platform independent features in canokey-core
https://github.com/canokeys/canokey-core, and leaves the USB implementation
to the platform.
In this commit the USB part was implemen
From: "Hongren (Zenithal) Zheng"
Signed-off-by: Hongren (Zenithal) Zheng
Message-Id:
Signed-off-by: Gerd Hoffmann
---
docs/system/devices/usb.rst | 4
1 file changed, 4 insertions(+)
diff --git a/docs/system/devices/usb.rst b/docs/system/devices/usb.rst
index afb7d6c2268d..872d9167589b
From: Volker Rümelin
The counterpart function for gd_gl_area_create_context() is
currently empty. Implement the gd_gl_area_destroy_context()
function to avoid GL context leaks.
Signed-off-by: Volker Rümelin
Message-Id: <20220605085131.7711-1-vr_q...@t-online.de>
Signed-off-by: Gerd Hoffmann
--
From: Volker Rümelin
Since about 2018 virglrenderer (commit fa835b0f88 "vrend: don't
hardcode context version") tries to open the highest available GL
context version. This is done by creating the known GL context
versions from the highest to the lowest until (*create_gl_context)
returns a contex
From: Akihiko Odaki
Signed-off-by: Akihiko Odaki
Reviewed-by: Philippe Mathieu-Daudé
Message-Id: <20220529082508.89097-1-akihiko.od...@gmail.com>
Signed-off-by: Gerd Hoffmann
---
ui/cocoa.m | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/ui/cocoa.m b/ui/cocoa.m
index
The following changes since commit debd0753663bc89c86f5462a53268f2e3f680f60:
Merge tag 'pull-testing-next-140622-1' of https://github.com/stsquad/qemu
into staging (2022-06-13 21:10:57 -0700)
are available in the Git repository at:
git://git.kraxel.org/qemu tags/kraxel-202
> > Hmm, build worked here and CI passed too.
> >
> > I think this is one of those cases where the build directory must be
> > deleted because one subdirectory is replaced by a compatibility
> > symlink.
>
> Except 'configure' deals with that, as it explicitly rm -rf's the
> symlink target:
>
>
On Wed, Jun 08, 2022 at 04:27:23PM +0200, Peter Zijlstra wrote:
> Hi All! (omg so many)
Hi Peter,
Sorry for the delay; my plate has also been rather full recently. I'm beginning
to page this in now.
> These here few patches mostly clear out the utter mess that is cpuidle vs
> rcuidle.
>
> At t
flight 171157 xen-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171157/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-arm64-pvops 6 kernel-build fail REGR. vs. 171151
Tests which did no
On 14.06.2022 13:08, Julien Grall wrote:
>>> + unsigned int rc = 0;
>> ... here you are setting rc to 0 even though it will be reassigned.
>> Furthermore, if rc is used only in case of CPU_UP_PREPARE, why not moving
>> the definition there?
>
> Because I forgot to replace "return NOTIFY_DON
On 14/06/2022 12:05, Michal Orzel wrote:
Hi Julien,
On 14.06.2022 11:41, Julien Grall wrote:
From: Julien Grall
Commit 5047cd1d5dea "xen/common: Use enhanced ASSERT_ALLOC_CONTEXT in
xmalloc()" extended the checks in _xmalloc() to catch any use of the
helpers from context with interrupts di
On 14/06/2022 12:02, Michal Orzel wrote:
Hi Julien,
Hi Michal,
On 14.06.2022 11:41, Julien Grall wrote:
From: Julien Grall
Commit 5047cd1d5dea "xen/common: Use enhanced ASSERT_ALLOC_CONTEXT in
xmalloc()" extended the checks in _xmalloc() to catch any use of the
helpers from context with
Hi Julien,
On 14.06.2022 11:41, Julien Grall wrote:
> From: Julien Grall
>
> Commit 5047cd1d5dea "xen/common: Use enhanced ASSERT_ALLOC_CONTEXT in
> xmalloc()" extended the checks in _xmalloc() to catch any use of the
> helpers from context with interrupts disabled.
>
> Unfortunately, the rule
Hi Julien,
On 14.06.2022 11:41, Julien Grall wrote:
> From: Julien Grall
>
> Commit 5047cd1d5dea "xen/common: Use enhanced ASSERT_ALLOC_CONTEXT in
> xmalloc()" extended the checks in _xmalloc() to catch any use of the
> helpers from context with interrupts disabled.
>
> Unfortunately, the rule
On Tue, Jun 14, 2022 at 11:40:38AM +0200, Gerd Hoffmann wrote:
> On Mon, Jun 13, 2022 at 08:52:21AM -0700, Richard Henderson wrote:
> > On 6/13/22 04:36, Gerd Hoffmann wrote:
> > > The following changes since commit
> > > dcb40541ebca7ec98a14d461593b3cd7282b4fac:
> > >
> > >Merge tag 'mips-20
On 14.06.2022 11:38, Roger Pau Monné wrote:
> On Tue, Jun 14, 2022 at 11:13:07AM +0200, Jan Beulich wrote:
>> On 14.06.2022 10:32, Roger Pau Monné wrote:
>>> On Tue, Jun 14, 2022 at 10:10:03AM +0200, Jan Beulich wrote:
On 14.06.2022 08:52, Roger Pau Monné wrote:
> On Mon, Jun 13, 2022 at 0
From: Julien Grall
Commit 5047cd1d5dea "xen/common: Use enhanced ASSERT_ALLOC_CONTEXT in
xmalloc()" extended the checks in _xmalloc() to catch any use of the
helpers from context with interrupts disabled.
Unfortunately, the rule is not followed when initializing the per-CPU
IRQs:
(XEN) Xen call
From: Julien Grall
Commit 5047cd1d5dea "xen/common: Use enhanced ASSERT_ALLOC_CONTEXT in
xmalloc()" extended the checks in _xmalloc() to catch any use of the
helpers from context with interrupts disabled.
Unfortunately, the rule is not followed when allocating the CPU
sibling/core maps.
(XEN) X
On Mon, Jun 13, 2022 at 08:52:21AM -0700, Richard Henderson wrote:
> On 6/13/22 04:36, Gerd Hoffmann wrote:
> > The following changes since commit dcb40541ebca7ec98a14d461593b3cd7282b4fac:
> >
> >Merge tag 'mips-20220611' of https://github.com/philmd/qemu into staging
> > (2022-06-11 21:13:27
On Tue, Jun 14, 2022 at 11:13:07AM +0200, Jan Beulich wrote:
> On 14.06.2022 10:32, Roger Pau Monné wrote:
> > On Tue, Jun 14, 2022 at 10:10:03AM +0200, Jan Beulich wrote:
> >> On 14.06.2022 08:52, Roger Pau Monné wrote:
> >>> On Mon, Jun 13, 2022 at 03:56:54PM +0200, Jan Beulich wrote:
> On 1
On 14.06.2022 10:32, Roger Pau Monné wrote:
> On Tue, Jun 14, 2022 at 10:10:03AM +0200, Jan Beulich wrote:
>> On 14.06.2022 08:52, Roger Pau Monné wrote:
>>> On Mon, Jun 13, 2022 at 03:56:54PM +0200, Jan Beulich wrote:
On 13.06.2022 14:32, Roger Pau Monné wrote:
> On Mon, Jun 13, 2022 at 1
flight 171156 linux-linus real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171156/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-arm64-arm64-examine 8 reboot fail REGR. vs. 170714
test-amd64-amd64-xl
flight 171159 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/171159/
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 Tue, Jun 14, 2022 at 10:32:53AM +0200, Roger Pau Monné wrote:
> On Tue, Jun 14, 2022 at 10:10:03AM +0200, Jan Beulich wrote:
> > On 14.06.2022 08:52, Roger Pau Monné wrote:
> > > On Mon, Jun 13, 2022 at 03:56:54PM +0200, Jan Beulich wrote:
> > >> On 13.06.2022 14:32, Roger Pau Monné wrote:
> > >
On Tue, Jun 14, 2022 at 10:10:03AM +0200, Jan Beulich wrote:
> On 14.06.2022 08:52, Roger Pau Monné wrote:
> > On Mon, Jun 13, 2022 at 03:56:54PM +0200, Jan Beulich wrote:
> >> On 13.06.2022 14:32, Roger Pau Monné wrote:
> >>> On Mon, Jun 13, 2022 at 11:18:49AM +0200, Jan Beulich wrote:
> On 1
On 14.06.2022 08:52, Roger Pau Monné wrote:
> On Mon, Jun 13, 2022 at 03:56:54PM +0200, Jan Beulich wrote:
>> On 13.06.2022 14:32, Roger Pau Monné wrote:
>>> On Mon, Jun 13, 2022 at 11:18:49AM +0200, Jan Beulich wrote:
On 13.06.2022 11:04, Roger Pau Monné wrote:
> On Mon, Jun 13, 2022 at 1
87 matches
Mail list logo
