[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

For me we had enough tests already. Upstream development/tests, Zesty, Yakkety. Christian, could you please move Xenial for me ? I have some end users waiting for this. Thank you very much. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

Thanks Christian! Will do!! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1626972 Title: QEMU memfd_create fallback mechanism change for security drivers Status in Ubuntu Cloud Archive: Invalid

Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fallback mechanism

Let me work on it. I'll get back soon. Tks Daniel. > On Oct 04, 2016, at 05:36, Daniel P. Berrange <berra...@redhat.com> wrote: > > On Mon, Oct 03, 2016 at 04:15:55PM -0300, Rafael David Tinoco wrote: >> Yes, definitely. Check this: > > [snip] > > So in that

Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fallback mechanism

True. What about having a single config parameter as a place to put all vhost logs for all drives for a single instance ? Remove the memfd implementation with all the memfd shared_memory option ? Replace it with a open+unlink+ftruncate+mmap approach only. This way every device would get its

Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fallback mechanism

> On Oct 04, 2016, at 10:10, Marc-André Lureau > wrote: > > > How will this path be used? Is it going to be global to qemu for various > > use (kinda like $TMP), or per-device, or for memfd fallback only? Should > > the path pre-exist? (I suppose, if not, qemu

Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fallback mechanism

> On Oct 04, 2016, at 10:50, Marc-André Lureau > wrote: > > What about having a single config parameter as a place to put all vhost logs > for all drives for a single instance ? Remove the memfd implementation with > all the memfd shared_memory option ? Replace it

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

Related: https://bugs.launchpad.net/nova/+bug/1613423 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1626972 Title: QEMU memfd_create fallback mechanism change for security drivers Status in QEMU:

[Qemu-devel] [Bug 1626972] [NEW] QEMU memfd_create fallback mechanism change for security drivers

-bc8c-43d2-9c4a-962c1bf7723e" name="/var/tmp/" pid=12625 comm="qemu-system-x86" requested_mask="r" denied_mask="r" fsuid=107 ouid=0 When leaving libvirt without apparmor capabilities (thus not confining virtual machines on compute nodes, the live mi

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

it a little bit: http://paste.ubuntu.com/23217333/ And fixed it: http://paste.ubuntu.com/23219599/ (Probable the version to be suggested to upstream) ** Changed in: qemu Status: New => In Progress ** Changed in: qemu Assignee: (unassigned) => Rafael David Tinoco (inaddy) -- You re

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

Fixed it according to checkpatch.pl as stated in http://wiki.qemu.org/Contribute/SubmitAPatch. http://paste.ubuntu.com/23220104/ Will submit to mailing list after testing everything. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

Re: [Qemu-devel] [PATCH] util: secure memfd_create fallback mechanism

Hello! > On Sep 27, 2016, at 08:13, Marc-André Lureau wrote: > >> Note that the filename, per se, is not as important as other files, >> since qemu won't provide it for being accessed by external programs, and, >> deletes the file, while keeping the descriptor, right after

Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fallback mechanism

Sorry, I was only able to come back to this today. > On Sep 27, 2016, at 09:18, Daniel Berrange <1626...@bugs.launchpad.net> wrote: > >> There are numerous people relying on older kernels in openstack >> deployments - sometimes with specific drivers (ovswitch, dpdk, >> infiniband) holding

Re: [Qemu-devel] [PATCH] util: secure memfd_create fallback mechanism

Hello Marc, > On Sep 27, 2016, at 08:13, Marc-André Lureau <mlur...@redhat.com> wrote: > >>> On Tue, Sep 27, 2016 at 03:06:21AM +, Rafael David Tinoco wrote: >>> We should not have QEMU creating unpredictabile filenames in the >>> first place - any fi

Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fallback mechanism

Hello Daniel, > On Oct 03, 2016, at 14:55, Daniel P. Berrange wrote: > >> Well, it unlinks the file but the references are still there while the >> descriptor isn't closed by this process, or by the one that receives the >> descriptor (that is why is the "unlink" so early).

Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fallback mechanism

mplemented: vhost_user_set_log_base -> VhostUserMsg = VHOST_USER_SET_LOG_BASE vhost_user_write(with the VHOST_USER_GET_LOG_BASE message): - configures the file descriptors(... , fds, fd_num) qemu_chr_fe_set_msgfds - writes them down the char driver qemu_chr_fe_write_all > On Oct 03, 2016, at 15:46, Raf

[Qemu-devel] [PATCH] util: secure memfd_create fallback mechanism

pid=74648 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=107 ouid=107 Signed-off-by: Rafael David Tinoco <rafael.tin...@canonical.com> --- util/memfd.c | 26 +- 1 file changed, 25 insertions(+), 1 deletion(-) diff --gi

[Qemu-devel] [PATCH] util: secure memfd_create fallback mechanism

pid=74648 comm="qemu-system-x86" requested_mask="c" denied_mask="c" fsuid=107 ouid=107 Signed-off-by: Rafael David Tinoco <rafael.tin...@canonical.com> --- util/memfd.c | 26 +- 1 file changed, 25 insertions(+), 1 deletion(-) diff --gi

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

I'll follow to see if patch was accepted upstream: https://lists.gnu.org/archive/html/qemu-devel/2016-09/msg06191.html https://www.mail-archive.com/qemu-devel@nongnu.org/msg400892.html -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

Re: [Qemu-devel] [PATCH] util: secure memfd_create fallback mechanism

> On Sep 27, 2016, at 05:36, Daniel P. Berrange <berra...@redhat.com> wrote: > > On Tue, Sep 27, 2016 at 03:06:21AM +0000, Rafael David Tinoco wrote: >> Commit: 35f9b6ef3acc9d0546c395a566b04e63ca84e302 added a fallback >> mechanism for systems not supporting me

Re: [Qemu-devel] [PATCH] vhost: secure vhost shared log files using argv paremeter

Hello, > On Tue, Nov 8, 2016 at 4:49 PM Rafael David Tinoco > <rafael.tin...@canonical.com> wrote: > Hello Michael, André, > > Could you do a quick review before a final submission ? > > http://paste.ubuntu.com/23446279/ > ... > (André) > Could it be

Re: [Qemu-devel] [PATCH] vhost: secure vhost shared log files using argv paremeter

re anything else ? Thank you Rafael Tinoco On Mon, Oct 31, 2016 at 8:30 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Mon, Oct 31, 2016 at 08:35:33AM -0200, Rafael David Tinoco wrote: >> On Sun, Oct 30, 2016 at 5:26 PM, Michael S. Tsirkin <m...@redhat.com> wrote: >&

[Qemu-devel] [PATCH] vhost: secure vhost shared log files using argv paremeter

Commit 31190ed7 added a migration blocker in vhost_dev_init() to check if memfd would succeed. It is better if this blocker first checks if vhost backend requires shared log. This will avoid a situation where a blocker is added inappropriately (e.g. shared log allocation fails when vhost backend

Re: [Qemu-devel] [PATCH] vhost: secure vhost shared log files using argv paremeter

Hello, > On Oct 22, 2016, at 05:18, Marc-André Lureau <marcandre.lur...@gmail.com> > wrote: > > Hi > > On Sat, Oct 22, 2016 at 10:01 AM Rafael David Tinoco > <rafael.tin...@canonical.com> wrote: > Commit 31190ed7 added a migration blocker in vhost_dev_init

[Qemu-devel] [Bug 1626972] Fwd: [PATCH] vhost: secure vhost shared log files using argv paremeter

> Begin forwarded message: > > From: Rafael David Tinoco <rafael.tin...@canonical.com> > Subject: Re: [Qemu-devel] [PATCH] vhost: secure vhost shared log files using > argv paremeter > Date: October 22, 2016 at 19:52:31 GMT-2 > To: Marc-André Lureau <marcandre.

[Qemu-devel] [Bug 1626972] Fwd: [PATCH] vhost: secure vhost shared log files using argv paremeter

> Begin forwarded message: > > From: Marc-André Lureau <marcandre.lur...@gmail.com> > Subject: Re: [Qemu-devel] [PATCH] vhost: secure vhost shared log files using > argv paremeter > Date: October 22, 2016 at 05:18:02 GMT-2 > To: Rafael David Tinoco <rafael.tin...@c

[Qemu-devel] [PATCH] vhost: secure vhost shared log files using argv paremeter

n-existent, or a directory, random files are going to be created in the specified directory (or, for non-existent, in tmpdir). If vhostlog is specified, the filepath is always used when allocating vhost log files. Signed-off-by: Rafael David Tinoco <rafael.tin...@canonical.com> --- hw/net/vhost_ne

[Qemu-devel] [PATCH] vhost: migration blocker only if shared log is used

doesn't support it). Signed-off-by: Rafael David Tinoco <rafael.tin...@canonical.com> Reviewed-by: Marc-André Lureau <marcandre.lur...@redhat.com> --- hw/virtio/vhost.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/virtio/vhost.c b/hw/virtio/vhost.c index bd05

Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fallback mechanism

n tmp files (and because file descriptors can be passed away, like we discussed before). If that is okay I'll provide a patch asap. Let me know if you prefer something else. Thank you, Rafael > On Oct 04, 2016, at 12:29, Rafael David Tinoco <rafael.tin...@canonical.com> > wrote:

Re: [Qemu-devel] [Bug 1626972] Re: [PATCH] util: secure memfd_create fallback mechanism

> On Oct 21, 2016, at 01:03, Rafael David Tinoco <rafael.tin...@canonical.com> > wrote: > > Also, if possible, I would like comments about a draft: > > https://pastebin.canonical.com/168579/ > (please disregard printfs and minor problems)

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

Right now Zesty is behind Yakkety because of a Security Update. Not sure you need me to attach a debdiff for Zesty as well. Let me know. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1626972 Title:

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

** Patch added: "zesty_qemu_2.6.1+dfsg-0ubuntu7.debdiff" https://bugs.launchpad.net/qemu/+bug/1626972/+attachment/4781485/+files/zesty_qemu_2.6.1+dfsg-0ubuntu7.debdiff -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

** Description changed: - And, when libvirt starts using apparmor, and creating apparmor profiles - for every virtual machine created in the compute nodes, mitaka qemu (2.5 - - and upstream also) uses a fallback mechanism for creating shared - memory for live-migrations. This fall back mechanism,

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

Thanks Christian, Then I'll finish this SRU first. Will work in the vhost mmap log file right after. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1626972 Title: QEMU memfd_create fallback

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

Took some more time here because of LP: #1621269. ** Patch added: "yakkety_qemu_2.6.1+dfsg-0ubuntu5.2.debdiff" https://bugs.launchpad.net/qemu/+bug/1626972/+attachment/4781464/+files/yakkety_qemu_2.6.1+dfsg-0ubuntu5.2.debdiff -- You received this bug notification because you are a member of

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

** Patch added: "xenial_qemu_2.5+dfsg-5ubuntu10.7.debdiff" https://bugs.launchpad.net/qemu/+bug/1626972/+attachment/4781425/+files/xenial_qemu_2.5+dfsg-5ubuntu10.7.debdiff -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

** Changed in: cloud-archive Status: New => In Progress ** Changed in: cloud-archive Assignee: (unassigned) => Rafael David Tinoco (inaddy) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.ne

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

** Changed in: qemu (Ubuntu Xenial) Status: New => In Progress ** Changed in: qemu (Ubuntu Yakkety) Status: New => In Progress ** Changed in: qemu (Ubuntu Xenial) Assignee: (unassigned) => Rafael David Tinoco (inaddy) ** Changed in: qemu (Ubuntu Yakkety)

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

migration problems, but, likely, those are the vast minority. commit 0d34fbabc13891da41582b0823867dc5733fffef Author: Rafael David Tinoco <rafael.tin...@canonical.com> Date: Mon Oct 24 15:35:03 2016 + vhost: migration blocker only if shared log is used Commit 31190ed7 added a mig

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

** Also affects: qemu (Ubuntu) Importance: Undecided Status: New ** Changed in: qemu (Ubuntu) Status: New => In Progress ** Changed in: qemu (Ubuntu) Assignee: (unassigned) => Rafael David Tinoco (inaddy) -- You received this bug notification because you are a

Re: [Qemu-devel] [PATCH] vhost: secure vhost shared log files using argv paremeter

On Sun, Oct 30, 2016 at 5:26 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > > On Sat, Oct 22, 2016 at 07:00:41AM +0000, Rafael David Tinoco wrote: > > Commit 31190ed7 added a migration blocker in vhost_dev_init() to > > check if memfd would succeed. It is better if this

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

@jamespage, @cpaelzer, I'll verify this fix in couple of days so it can be released. Thank you! Rafael -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1626972 Title: QEMU memfd_create fallback

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

Hello Antonio (@arcimboldo) The fix only makes sense for newer QEMUs (>= Xenial, like the one from Mitaka Ubuntu Cloud Archive). OBS: The "migration check" is done in VHOST initialization functions when the devices are virtually attached to the virtual machine. If you are using kernel 3.13 and

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

Yakkety Verification (with 3.13 kernel from Trusty since a <= 3.17 kernel is needed). This verifies that Ubuntu Cloud Archive repositories will be alright with this new packages (from Xenial / Yakkety). ## CURRENT inaddy@(ykvm01):~$ apt-cache policy qemu-kvm qemu-kvm: Installed:

[Qemu-devel] [Bug 1626972] Re: QEMU memfd_create fallback mechanism change for security drivers

Xenial Verification (with 3.13 kernel from Trusty since a <= 3.17 kernel is needed). This verifies that Ubuntu Cloud Archive repositories will be alright with this new packages (from Xenial / Yakkety). ## CURRENT inaddy@(xkvm01):~$ apt-cache policy qemu-kvm qemu-kvm: Installed:

[Qemu-devel] [Bug 1830821] Re: Expose ARCH_CAP_MDS_NO in guest

** Changed in: qemu (Ubuntu) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1830821 Title: Expose ARCH_CAP_MDS_NO in guest

[Qemu-devel] [Bug 1830821] Re: Expose ARCH_CAP_MDS_NO in guest

This effort, if done, would be done together with: https://bugs.launchpad.net/intel/+bug/1828495 Please read comments: https://bugs.launchpad.net/intel/+bug/1828495/comments/8 and https://bugs.launchpad.net/intel/+bug/1828495/comments/10 -- You received this bug notification because you are

[Qemu-devel] [Bug 1830821] Re: Expose ARCH_CAP_MDS_NO in guest

*** This bug is a duplicate of bug 1828495 *** https://bugs.launchpad.net/bugs/1828495 I'm marking this bug as a duplicate of LP: #1828495 since both are asking for mitigations pass-through to i386 kvm guests and I'm preparing a fix for both simultaneously. ** This bug has been marked a

[Qemu-devel] [Bug 1834113] Re: QEMU touchpad input erratic after wakeup from sleep

Avi, Something I have realized we missed as a feedback here - or maybe I missed checking previous comments - is how your mouse is being setup for the guest. Is it being PS/2 emulated (default) or is it being given as an USB device (when qemu cmd line has "-usb -device usb-tablet"). Also, are you

[Qemu-devel] [Bug 1805256] Re: qemu-img hangs on high core count ARM system

** Changed in: qemu (Ubuntu) Status: Confirmed => In Progress ** Changed in: qemu (Ubuntu) Assignee: (unassigned) => Rafael David Tinoco (rafaeldtinoco) ** Changed in: qemu (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are

Re: [Qemu-devel] qemu_futex_wait() lockups in ARM64: 2 possible issues

> Zhengui's theory that notify_me doesn't work properly on ARM is more > promising, but he couldn't provide a clear explanation of why he thought > notify_me is involved. In particular, I would have expected notify_me to > be wrong if the qemu_poll_ns call came from aio_ctx_dispatch, for example:

[Qemu-devel] [Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

** Also affects: qemu (Ubuntu Ff-series) Importance: Undecided Status: New ** Also affects: qemu (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: qemu (Ubuntu Eoan) Importance: Medium Assignee: Rafael David Tinoco (rafaeldtinoco) Status

[Qemu-devel] [Bug 1805256] Re: qemu-img hangs on high core count ARM system

Alright, I couldn't reproduce this yet, I'm running same test case in a 24 cores box and causing lots of context switches and CPU migrations in parallel (trying to exhaust the logic). Will let this running for sometime to check. Unfortunately this can be related QEMU AIO BH locking/primitives

Re: [Qemu-devel] qemu_futex_wait() lockups in ARM64: 2 possible issues

Quick update... > value INT_MAX (4294967295) seems WRONG for qemu_futex_wait(): > > - EV_BUSY, being -1, and passed as an argument qemu_futex_wait(void *, > unsigned), is a two's complement, making argument into a INT_MAX when > that's not what is expected (unless I missed something). > > ***

[Qemu-devel] [Bug 1805256] Re: qemu-img hangs on high core count ARM system

Alright, here is what is happening: Whenever program is stuck, thread #2 backtrace is this: (gdb) bt #0 syscall () at ../sysdeps/unix/sysv/linux/aarch64/syscall.S:38 #1 0xaabd41b0 in qemu_futex_wait (val=, f=) at ./util/qemu-thread-posix.c:438 #2 qemu_event_wait

[Qemu-devel] [Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

QEMU BUG: #1 Alright, one of the issues is (according to comment #14): """ Meaning that code is waiting for a futex inside kernel. (gdb) print rcu_call_ready_event $4 = {value = 4294967295, initialized = true} The QemuEvent "rcu_call_ready_event->value" is set to INT_MAX and I don't know why

[Qemu-devel] qemu_futex_wait() lockups in ARM64: 2 possible issues

Paolo, While debugging hungs in ARM64 while doing a simple: qemu-img convert -f qcow2 -O qcow2 file.qcow2 output.qcow2 I might have found 2 issues which I'd like you to review, if possible. ISSUE #1 I've caught the following stack trace after an HUNG in qemu-img convert: (gdb) bt #0

[Qemu-devel] [Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

In comment #14, please disregard the second half of the issue, related to: 0xaabd4100 <+16>: cbz w1, 0xaabd4108 0xaabd4104 <+20>: ret 0xaabd4108 <+24>: ldaxr w1, [x0] 0xaabd410c <+28>: orr w1, w1, #0x1 => 0xaabd4110

[Qemu-devel] [Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

** Summary changed: - qemu-img hangs on high core count ARM system + qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images ** Changed in: qemu Status: Confirmed => In Progress ** Changed in: qemu Assignee: (unassigned) => Rafael David Tinoco (rafaeld

[Qemu-devel] [Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

** Description changed: + Command: + + qemu-img convert -m 1 -f qcow2 -O qcow2 ./disk01.qcow2 ./output.qcow2 + + Hangs indefinitely approximately 30% of the runs. + + + + Workaround: + + qemu-img convert -m 1 -f qcow2 -O qcow2 ./disk01.qcow2 ./output.qcow2 + + Run "qemu-img convert"

[Qemu-devel] [Bug 1805256] Re: qemu-img hangs on high core count ARM system

Alright, with a d06 aarch64 machine I was able to reproduce it after 8 attempts.I'll debug it today and provide feedback on my findings. (gdb) bt full #0 0xb0b2181c in __GI_ppoll (fds=0xce5ab770, nfds=4, timeout=, timeout@entry=0x0, sigmask=sigmask@entry=0x0) at

[Qemu-devel] [Bug 1805256] Re: qemu-img hangs on high core count ARM system

Alright, I'm still investigating this but wanted to share some findings... I haven't got a kernel dump yet after the task is frozen, I have analyzed only the userland part of it (although I have checked if code was running inside kernel with perf cycles:u/cycles:k at some point). The big picture

[Qemu-devel] [Bug 1805256] Re: qemu-img hangs on high core count ARM system

Hello Liz, I'll try to reproduce this issue in a Cortex-A53 aarch64 real environment (w/ 24 HW threads) AND in a virtual environment w/ lots of vCPUs... but, if it's a barrier missing - or the lack of atomicity and/or ordering in a primitive - then, I'm afraid the context switch in between vCPUs

[Qemu-devel] [Bug 1805256] Re: qemu-img hangs on high core count ARM system

OOhh nm on the virtual environment test, as I just remembered we don't have KVM on 2nd level for aarch64 yet (at least in ARMv8 implementing virt extension). I'll try to reproduce in the real env only. -- You received this bug notification because you are a member of qemu- devel-ml, which is

Re: [Qemu-devel] qemu_futex_wait() lockups in ARM64: 2 possible issues

> Note that the RCU thread is expected to sit most of the time doing > nothing, so I don't think this matters. Agreed. > Zhengui's theory that notify_me doesn't work properly on ARM is more > promising, but he couldn't provide a clear explanation of why he thought > notify_me is involved. In

[Qemu-devel] [Bug 1830821] Re: Expose ARCH_CAP_MDS_NO in guest

*** This bug is a duplicate of bug 1828495 *** https://bugs.launchpad.net/bugs/1828495 Commit: https://bugs.launchpad.net/intel/+bug/1828495/comments/42 Addresses exactly this bug fix. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to

Re: Thoughts on VM fence infrastructure

>>> There are times when the main loop can get blocked even though the CPU >>> threads can be running and can in some configurations perform IO >>> even without the main loop (I think!). >> Ah, that's a very good point. Indeed, you can perform IO in those >> cases specially when using vhost

[Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

On Wed, 2019-10-02 at 15:20 +0200, Paolo Bonzini wrote: > On 02/10/19 13:05, Jan Glauber wrote: >> The arm64 code generated for the >> atomic_[add|sub] accesses of ctx->notify_me doesn't contain any >> memory barriers. It is just plain ldaxr/stlxr. >> >> From my understanding this is not

[Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

On 02/10/19 16:58, Torvald Riegel wrote: > This example looks like Dekker synchronization (if I get the intent right). It is the same pattern. However, one of the two synchronized variables is a counter rather than just a flag. > Two possible implementations of this are either (1) with all

[Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

Documenting this here as bug# was dropped from the mail thread: On 02/10/19 13:05, Jan Glauber wrote: > The arm64 code generated for the > atomic_[add|sub] accesses of ctx->notify_me doesn't contain any > memory barriers. It is just plain ldaxr/stlxr. > > From my understanding this is not

[Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

Hello Fred, Based on Dann's feedback on testing, I'm failing to see where your patch fixes the "root" cause (despite being able to mitigate the issue by changing the aio notification mechanism). I think the root cause is best described in this 2 emails from the thread:

[Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

** Changed in: qemu (Ubuntu Eoan) Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned) ** Changed in: qemu Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned) -- You received this bug notification because you are a member of qemu- devel-ml, which is subs

[Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

FYIO, from now on all the "merge" work will be done in the merge requests being linked to this BUG (at the top). @paelzer will be verifying those. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

Hello Ike, Please, let me know if you want me to go after the needed SRUs for this fix or if you will. I'll wait for the final feedback from tests with your PPA. Cheers! -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU.

[Bug 1878134] Re: Assertion failures in ati_reg_read_offs/ati_reg_write_offs

Hello Alexander, I believe your fuzz test result was meant to the upstream project so I moved it. o/ ** Also affects: qemu Importance: Undecided Status: New ** No longer affects: qemu-kvm (Ubuntu) -- You received this bug notification because you are a member of qemu- devel-ml,

[Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

** Description changed: + [Impact] + + * QEMU locking primitives might face a race condition in QEMU Async I/O + bottom halves scheduling. This leads to a dead lock making either QEMU + or one of its tools to hang indefinitely. + + [Test Case] + + * qemu-img convert -f qcow2 -O qcow2

[Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

** Changed in: qemu (Ubuntu) Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned) ** Changed in: qemu Status: In Progress => Fix Released ** Changed in: qemu (Ubuntu Focal) Status: Incomplete => In Progress ** Changed in: qemu (Ubuntu Eoan) Status: I

Re: [PATCH] configure: actually disable 'git_update' mode with --disable-git-update

Assuming you're just using git for conveniently applying local downstream patches, you don't need the git repo to exist once getting to the build stage. IOW just delete the .git dir after applying patches before running a build. ...then what do you do if the build fails and you want to

[Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

Status from old attempts to solve same nature issues: Older (2018) merge request from @raharper: https://github.com/koverstreet/bcache-tools/pull/1 addressing the fact that kernel uevents would not always emit CACHED_UUID parameters, making udev to delete (whenever that happens)

[Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

I've hidden last post as it was posted in the wrong bug. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1805256 Title: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting

[Bug 1886811] Re: systemd complains Failed to enqueue loopback interface start request: Operation not supported

qemu (1:5.0-5ubuntu3) groovy; urgency=medium has the merge with this fix: - linux-user-add-netlink-RTM_SETLINK-command.patch (Closes: #964289) ** Changed in: qemu (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of qemu- devel-ml,

[Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

** Description changed: + + SRU TEAM REVIEWER: This has already been SRUed for Focal, Eoan and Bionic. Unfortunately the Bionic SRU did not work and we had to reverse the change. Since then we had another update and now I'm retrying the SRU. + + After discussing with @paelzer (and @dannf as a

[Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

I just pushed/uploaded a SRU for bionic from: https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/qemu/+git/qemu/+merge/387269 Waiting for SRU on it. ** Changed in: qemu (Ubuntu Bionic) Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned) -- You received this

[Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

Started working on this again... ** Changed in: qemu (Ubuntu Bionic) Status: Triaged => In Progress -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1805256 Title: qemu-img hangs on

[Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

Worked being done for the Bionic SRU: BUG: https://bugs.launchpad.net/qemu/+bug/1805256 (fix for the bionic regression demonstrated at LP: #1885419) PPA: https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1805256-bionic MERGE: https://tinyurl.com/y8sucs6x Merge proposal currently going under

[Bug 1805256] Re: qemu-img hangs on rcu_call_ready_event logic in Aarch64 when converting images

Thanks @dannf! I spoke to Christian and him and I agreed to confine this change into ARM builds only (as SRU for Bionic). Preparing it... -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1805256 Title: