Still a bug, resetting status per new bug tracker guidance.
Also, re-tested with v6.0.0-11869-g800a25ea45-dirty. Results in error:
ERROR:../../../util/oslib-win32.c:61:qemu_try_memalign: assertion failed:
(is_power_of_2(alignment))
** Changed in: qemu
Status: Incomplete => New
--
You
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
ed
Use the test from Makefile to check if vhost-user-gpu is being built,
and if so require pixman.
Signed-off-by: Rafael Kitover
---
configure | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/configure b/configure
index 2acc4d1465..181b465861
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
** 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
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,
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)
/dev/bca
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 image
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:
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
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 rcu_call_r
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, whic
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.
https://bugs.launchpad.net/bugs/1805256
** 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 ./disk01.q
** 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
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.
https://bugs.
** 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 subscri
Public bug reported:
When attempting to convert Microsoft's 10X emulator image (19563) vhdx
[1], qemu-img terminates abruptly with an assertion failure. (Newer
versions of the vhdx exhibit the same issue.)
> qemu-img.exe convert flash.vhdx flash.vhd
**
ERROR:util/iov.c:335:qemu_iovec_concat_iov:
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:
https://lore.kernel.org/qe
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 memor
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 sufficient
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 sufficie
>>> 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 devic
** 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: In
> 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:
> 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
** 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" wit
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).
>
> *** If
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 <+32>
fbf1b6b9c in thread_start
QUESTION:
- Should qemu_event_set() check return code from
qemu_futex_wake()->qemu_futex()->syscall() in order to know if ANY
waiter was ever woken up ? Maybe even loop until at least 1 is awaken ?
Tks in advance,
Rafael D. Tinoco
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 ye
** 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
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 (ev=ev@entry=0xaac8
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
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 ../sysdeps/unix/s
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 and
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 subs
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 m
** 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 a
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 u
*** 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
*** 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 dupli
** 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
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
s not seem
to work. Any suggestions? At the moment, I am looking for a solution for
x86_64 (user emulation mode).
Kind regards,
Rafael
Solved. The reason I was not able to get the symbols is because logging
has to be enabled, otherwise the symbols are not loaded. In "elfload.c"
there is the condition:
if (qemu_log_enabled()) {
load_symbols(ehdr, image_fd, load_bias);
}
Thanks!
Kind regards,
Rafael
On 5/1/20
This logging flag prints what I want. But I really wanted is to get this
info inside the QEMU source code. Why am I not able to lookup the
symbols in the translator.c file the way I showed?
Kind regards,
Rafael
On 5/1/2018 6:04 PM, Alex Bennée wrote:
Rafael Kioji writes:
Dear all,
During
/disas.c". I am
compiling my application with symbols (-g). My target arch is ARM.
Thanks!
Kind regards,
Rafael
();
tcg_gen_ld_i64(v, cpu_env, fp_reg_offset(s, reg, MO_64));
return v;
}
Thanks!
--
Att.,
Rafael
For Mitaka, this bug will be included in UCA together with the fix for:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1656480
When it becomes available.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.ne
*** This bug is a duplicate of bug 1317491 ***
https://bugs.launchpad.net/bugs/1317491
Upstream "fixed" the issue - by finishing "block-commit" - in v1.3. That
is why I'm marking this bug as a duplicate of the Ubuntu bug. I'll
provide more comments in that bug.
** This bug has been marked a d
Public bug reported:
[nested] virt-install falls to SLOF: after starting installer (ISO/CDROM), it
crashes w/ a kernel panic due to an HTM (Hardware Transactional Memory)
exception.
Scenario:
Host=Ubuntu 16.04 Xenial (Ubuntu KVM ppc64el POWER8E 8247-22L)
Guest=Ubuntu 16.04 Xenial (Ubuntu Xenia
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
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 QE
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: 1:2.6.1+dfsg-0u
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: 1:2.5+dfsg-5ubun
@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 fal
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 h
** 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.
https://bugs.l
** 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,
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:
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
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 mechani
** 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.
https://bu
** 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
till cause migration problems, but, likely, those are the vast
minority.
commit 0d34fbabc13891da41582b0823867dc5733fffef
Author: Rafael David Tinoco
Date: Mon Oct 24 15:35:03 2016 +
vhost: migration blocker only if shared log is used
Commit 31190ed7 added a migration blocker in vhost_dev
** 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)
** 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 mem
Hello,
> On Tue, Nov 8, 2016 at 4:49 PM Rafael David Tinoco
> wrote:
> Hello Michael, André,
>
> Could you do a quick review before a final submission ?
>
> http://paste.ubuntu.com/23446279/
> ...
> (André) > Could it be only a filename? This would simpli
vided as a "file" ?
Should i keep vhostlog being a directory also ? (i know we are unlinking the
file so might not be needed BUT a static file might have a race condition in
between different instances and providing a directory - that creates random
files on it - might be better approach).
On Sun, Oct 30, 2016 at 5:26 PM, Michael S. Tsirkin wrote:
>
> On Sat, Oct 22, 2016 at 07:00:41AM +, 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 blocker first
> >
doesn't support it).
Signed-off-by: Rafael David Tinoco
Reviewed-by: Marc-André Lureau
---
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 bd051ab..742d0aa 100644
--- a/hw/virtio/vhost.c
+++ b/hw/virtio/vh
> Begin forwarded message:
>
> From: Rafael David Tinoco
> 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
> Cc: Rafael David Tinoco , qemu-devel
>
> Begin forwarded message:
>
> From: Marc-André Lureau
> 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
> Cc: QEMU
>
> Hi
>
> On Sat, O
Hello,
> On Oct 22, 2016, at 05:18, Marc-André Lureau
> wrote:
>
> Hi
>
> On Sat, Oct 22, 2016 at 10:01 AM 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 bloc
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 do
-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
---
hw/net/vhost_net.c| 4 +-
hw/sc
apparmor labelling on 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
> wrote:
>
>
more.
> On Oct 21, 2016, at 01:03, Rafael David Tinoco
> wrote:
>
> Also, if possible, I would like comments about a draft:
>
> https://pastebin.canonical.com/168579/
> (please disregard printfs and minor problems)
> 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 with a
> open+unlink+ftrunc
> 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 should clean it up when
> > leavin
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 o
Let me work on it. I'll get back soon.
Tks Daniel.
> On Oct 04, 2016, at 05:36, Daniel P. Berrange wrote:
>
> On Mon, Oct 03, 2016 at 04:15:55PM -0300, Rafael David Tinoco wrote:
>> Yes, definitely. Check this:
>
> [snip]
>
> So in that case, I think w
ing implemented:
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
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).
>>
>> If you check v
Hello Marc,
> On Sep 27, 2016, at 08:13, Marc-André Lureau 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 filenames should be det
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 kerne
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 its creation
>> (due t
> On Sep 27, 2016, at 05:36, Daniel P. Berrange 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 memfd_create syscall (started
>
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.
"c" fsuid=107 ouid=107
Per VM name (if no UUID is specified):
kernel: [26447.505653] type=1400 audit(1474944963.985:72): apparmor=
"DENIED" operation="mknod" profile="libvirt-----
" name="/tmp/memfd-instance-teste-osYpHh"
"c" fsuid=107 ouid=107
Per VM name (if no UUID is specified):
kernel: [26447.505653] type=1400 audit(1474944963.985:72): apparmor=
"DENIED" operation="mknod" profile="libvirt-----
" name="/tmp/memfd-instance-teste-osYpHh"
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.
h
roved 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)
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:
bvirt-2afa1131-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 comput
corrects the gigantic compound page initialization so that
> we can retain the optimization in
> 11feeb498086a3a5907b8148bdf1786a9b18fc55. The cacheline was already
> modified in order to set PG_tail so this won't affect the boot time of
> large memory systems.
>
> Report
ock for as long as possible. In the
> event there are no free pages in the pageblock then the lock will not be
> acquired at all which reduces contention on zone->lock.
>
> Signed-off-by: Mel Gorman
> Acked-by: Rik van Riel
> ---
Acked-by: Rafael Aquini
Waiting until memory pressure is relieved would
> cause compaction to continually fail instead of using reclaim/compaction
> to try allocate the page. The time-based mechanism is clumsy but a better
> option is not obvious.
>
> Signed-off-by: Mel Gorman
> Acked-by: Rik van Riel
> ---
Acked-by: Rafael Aquini
On Fri, Sep 21, 2012 at 11:46:17AM +0100, Mel Gorman wrote:
> This reverts
> mm-compaction-abort-compaction-loop-if-lock-is-contended-or-run-too-long.patch
> as it is replaced by a later patch in the series.
>
> Signed-off-by: Mel Gorman
Acked-by: Rafael Aquini
1 - 100 of 118 matches
Mail list logo
