While the bugzilla case wasn't updated this landed in v8.7.0 via a series around
https://gitlab.com/libvirt/libvirt/-/commit/e6c29f09e5b75d7a8d79ae670407060446282c78
v9.0.0 of libvirt is in Ubuntu Lunar, due to that - from now on - one
can control the physical bit settings in a defined way
have any background on this but stumbled over this and wondered,
is there any particular reason why this wasn't applied yet?
It seemed to fix a former mistake, was acked and then ... silence
> >
> > /* FP and SSE are always allowed regardless of XSAVE/XCR0. */
> > *ecx |= XSTATE_FP_MASK | XSTATE_SSE_MASK;
>
--
Christian Ehrhardt
Senior Staff Engineer, Ubuntu Server
Canonical Ltd
On Wed, Mar 1, 2023 at 9:04 AM Laszlo Ersek wrote:
>
> Hello Christian,
>
> On 3/1/23 08:17, Christian Ehrhardt wrote:
> > On Thu, Jan 5, 2023 at 8:14 AM Laszlo Ersek wrote:
> >>
> >> On 1/4/23 13:35, Michael S. Tsirkin wrote:
> >>> On Wed, Jan
case an FYI to everyone involved
back then,
the fix seems to have caused a regression [1] in - as far as I've
found - an edge case.
[1]: https://gitlab.com/qemu-project/qemu/-/issues/1520
...
> Laszlo
>
>
--
Christian Ehrhardt
Senior Staff Engineer, Ubuntu Server
Canonical Ltd
On Wed, Mar 23, 2022 at 11:54 AM Philippe Mathieu-Daudé
wrote:
>
> On 23/3/22 10:07, christian.ehrha...@canonical.com wrote:
> > From: Christian Ehrhardt
> >
> > Some of the roms build with -march=i486 -m16 which is incompatible
> > with -fcf-protection. That in
From: Christian Ehrhardt
Some of the roms build with -march=i486 -m16 which is incompatible
with -fcf-protection. That in turn is can be set by default, for
example in Ubuntu [1].
That causes:
cc1: error: ‘-fcf-protection’ is not compatible with this target
This won't work on -march=i486 -m16
uot;)
Reported-by: Christian Ehrhardt
Tested-by: Christian Ehrhardt
> This bug was detected when running the 'arm' emulator on an s390
> system. The s390 uses TCG_TARGET_EXTEND_ARGS which triggers code
> in tcg_gen_callN to extend 32 bit values to 64 bits; the incorrect
> sign data
From: Christian Ehrhardt
The virtiofsd currently crashes when used with glibc 2.35.
That is due to the rseq system call being added to every thread
creation [1][2].
[1]: https://www.efficios.com/blog/2019/02/08/linux-restartable-sequences/
[2]: https://sourceware.org/pipermail/libc-alpha/2022
Thank you Frank for that extra confirmation,
by now also all the blockers on the other bug fixed are good. I expect this to
be released as soon as the SRU Team is back from the Christmas shutdown.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is
FYI the release of this is slowed down by the slow verification of bug
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1929926
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1749393
Title:
Focal
old
$ sudo apt install --reinstall qemu-user-static=1:4.2-3ubuntu6.18
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 21.3 MB of archives.
After this
Uploaded to F-unapproved, waiting for the SRU team to accept 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/1749393
Title:
sbrk() not working under qemu-user with a PIE-compiled binary?
Status
** Changed in: qemu (Ubuntu Focal)
Status: Triaged => In Progress
** Changed in: qemu (Ubuntu Focal)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
SRU template updated, PPA rebuilt, Merge requests updated.
Also bundled another bug fix.
Waiting for MR review now.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1749393
Title:
sbrk() not working
Hi,
sorry this has fallen through the cracks, but bug 1928075 made me re-discover
it and it is time finally to complete that.
** Tags added: server-next
** Description changed:
[Impact]
- * The current space reserved can be too small and we can end up
-with no space at all for BRK.
Yeah Sebastian, a new ticket (with a reference to this bug as being
similar) would be preferred.
** Changed in: qemu (Ubuntu)
Assignee: Christian Ehrhardt (paelzer) => (unassigned)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscri
Hmm, thanks for the hint Thomas.
Of the two formerly referenced same-source different result builds:
[1] => built 2021-03-23 in Hirsute => works
[2] => built 2021-04-12 in Hirsute => fails
[1]:
https://launchpad.net/ubuntu/+source/qemu/1:5.2+dfsg-9ubuntu1/+build/21196422
[2]:
** Tags added: qemu-21.10
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** Changed in: qemu (Ubuntu)
Status: New => Triaged
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
@Thomas - there is a leftover task here and I've filed [1] for it in the new
tracker.
What is the right state to move this bug here into now?
[1]: https://gitlab.com/qemu-project/qemu/-/issues/137
** Bug watch added: gitlab.com/qemu-project/qemu/-/issues #137
For Focal:
- SRU Template added to the bug
- MP:
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/401771
- PPA:
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4535/+packages
(still building)
I'd ask anyone affected by this on Focal to give it a try on the
** Description changed:
+ [Impact]
+
+ * The current space reserved can be too small and we can end up
+with no space at all for BRK. It can happen to any case, but is
+much more likely with the now common PIE binaries.
+
+ * Backport the upstream fix which reserves a bit more space
Also I've rebuilt the most recent master c1e90def01 about ~55 commits newer
than 6.0-rc2.
As in the experiments of Tommy I was unable to reproduce it there.
But with the data from the tests before it is very likely that this is more
likely an accident by having a slightly different timing than a
Thanks @Babu for the clarifications!
I really hope that the qemu patch makes it in v6.0 - then I can better consider
picking it up as backport for qemu (already have a bug about that in bug
1921754 - therefore I'm setting the qemu task here as invalid)
The last step I can provide for the kernel
David used "5.6.0-1042.46-oem", the closest I had was "5.6.0-1052-oem"
so I tried that one.
With that my win10 install immediately crashed into the reported issue.
So to summarize:
1. I can reproduce it
2. Chances are high that it is fixed by kernel commit 841c2be0 "kvm: x86:
replace
Finally I'm able to test on a Threadripper myself now.
Note: In regard to the commit that Babu identified - I'm on kernel
5.10.0-1020-oem so that patch would be applied already. I need to find
an older kernel to retry with that as well
(on that new kernel) I did a full Win10 install and it
Thanks Babu/Igor for chiming in!
@Babu
That exposed STIBP but not IBRS - isn't that what you tried to solve (for
userspace) in qemu via a v2 for the Rome chips?
=> https://lists.gnu.org/archive/html/qemu-devel/2021-03/msg01020.html
I was recently pinging that, as it wasn't merged into the qemu
Ok, so you should be able to drop these lines one by one:
If that does not yet make it work, add those one by one (removing the features
of the named type)
That is awesome David,
qemu64 is like a very low common denominator with only very basic CPU features.
While "copy host" means "enable all you can".
We can surely work with that a bit, but until I get access to the same
HW I need you to do it.
If you run in a console `$virsh domcapabilities` it
Thanks David,
I have no threadripper around atm, I think I can next week get hands on an EPYC
Rome, but that isn't 100% the same.
But gladly you tried this on the latest qemu 5.2 and since it is failing there
as well it might be worth to also report it upstream. That is a great community
which
@Sadoon - yes, that is the same fix that Laurent pointed to a few hours
before.
@Frank - the kernel I had before was 5.11.0-11-generic (failing). I've
tested "5.11.0-13-generic #14~lp1920784" from your PPA and can confirm
that this fixes the issue.
Thanks Laurent for identifying the fix and
And gladly this was only added in >=5.9 and we have Groovy (5.8) and
Hirsute (5.11) so only the Hirsute kernel is needed to adapt, but
further backports are not needed.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
I might be spoiled by the s390x-POP style to define instructions, but in
the following doc about the PowerISA unfortunately there is no list of
reasons-for-SIGILL. Therefore I'm out of options on this waiting for
someone - most likely IBM - to chime in.
As my other repro-code didn't trigger the issue I looked at qemu again
and found that before the failing ioctl->scv call there are plenty other
even some very similar (same?) calls that work just fine.
I wonder if on guest setup qemu (or e.g. the rom we load) might set some
arch-bits or such
qemu calls this ioctl on ppc64 as:
sysdeps/unix/sysv/linux/powerpc/ioctl.c
result = INLINE_SYSCALL (ioctl, 3, fd, request, arg);
The mapping of macros in sysdeps/unix/sysv/linux/powerpc/sysdep.h seems to be:
INTERNAL_SYSCALL -> INTERNAL_SYSCALL_NCS -> TRY_SYSCALL_SCV -> SYSCALL_SCV
76 #define
[10] outlined to use PPC_FEATURE2_SCV but [4] does just that.
In addition [6] added power9 machine settings as only on this ISA it
is available - like:
+ .machine "push"
+ .machine "power9"
scv 0
+ .machine "pop"
Maybe there is some generated "scv 0" left that needs
Since this seems to be broken on all Distributions as soon as the triggering
combination of kernel/glibc is present I think we'd want to open that up to
upstream qemu for a wider discussion and to also hit the ppc64 architecture
experts.
Furthermore I'm not entirely sure if this needs to be fixed
Hi Sadoon,
thanks for the report!
There isn't much to find about this issue yet.
One automatic syscaller crash report [1].
On the emulation side there is [2][3].
On the glibc side we have [4][5] adding the use of it with [6] being a fix.
All those seem to be in glibc 2.33 - so I'd expect with [6]
in open-vm-tools we've found to follow
https://developer.gnome.org/glib/stable/glib-Version-Information.html#GLIB-VERSION-MIN-REQUIRED:CAPS
to be an easy fix for the time being.
Which in the autoconf magic there was just:
+AC_DEFINE(GLIB_VERSION_MIN_REQUIRED, GLIB_VERSION_2_34, [Ignore
post 2.34
On Tue, Feb 23, 2021 at 5:12 PM Daniel P. Berrangé wrote:
>
> On Tue, Feb 23, 2021 at 03:43:48PM +, Peter Maydell wrote:
> > On Tue, 23 Feb 2021 at 15:03, Christian Ehrhardt
> > wrote:
> > >
> > > glib2.0 introduced a change in 2.67.3 and later which tr
itlab.gnome.org/GNOME/glib/-/issues/2331
Signed-off-by: Christian Ehrhardt
---
disas/arm-a64.cc | 2 +-
disas/nanomips.cpp | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/disas/arm-a64.cc b/disas/arm-a64.cc
index 9fa779e175..27613d4b25 100644
--- a/disas/arm-a64.c
e-case of LDFLAGS_NOPIE
in .mak, therefore we can also remove it from being added there.
[1]: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=983d925d
[2]: https://sourceware.org/bugzilla/show_bug.cgi?id=27050#c5
Signed-off-by: Christian Ehrhardt
---
configure | 3 ---
p
I was seeing in my manual tests that the delete->Event was taking a bit
longer, maybe your retry logic kicks in before it is complete now. And
due to that the problem takes place.
So with the PPA you should get:
a) a warning, but no more the cancelled/undefined behavior on double delete
b) can
Thanks Lee,
builds are most reliably done in Lauchpad IMHO and the Ubuntu Delta is a quilt
stack which isn't as easily bisectable.
If we end up searching not between Ubuntu Delta I can help to get you qemu
built from git for that.
But for some initially probing which range of changes we want to
Trying to connect using
novnc latest/stable:1.2.0 2020-07-31 (6) 18MB -
as-is failing to connect
Keeping VNC up and refreshing qemu.
Updating to the new qemu from focal proposed (by now resolved the archive
publishing issues we had before this morning).
Get:67
Thanks James, but now I'm unsure where to go from here as it isn't
reproducible with many tries at different scales that James and I did.
@Sean/Lee
Since you wondered if it might be due to Ubuntu Delta on top of 4.2 - there are
two things we could compare Ubuntu's qemu to then:
1. qemu 4.2 as
SRU Template for qemu added and MP linked to fix this in Ubuntu 20.04
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1849644
Title:
QEMU VNC websocket proxy requires non-standard 'binary'
** Description changed:
- When running a machine using "-vnc" and the "websocket" option QEMU
- seems to require the subprotocol called 'binary'. This subprotocol does
- not exist in the WebSocket specification. In fact it has never existed
- in the spec, in one of the very early drafts of
I can confirm the test steps mentioned above. In an unchanged scenario a
formerly failing-to-connect case got working when replacing the qemu (on
Focal) in use with a patched one.
Adding an SRU Template for Focal to the bug description ...
--
You received this bug notification because you are a
As outlined before the time from device_del to the DEVICE_DELETED is
indeed "a bit longer" in Focal (from ~0.1s to ~6s), but other than that
I couldn't find anything else yet.
We were wondering due to [1] in a related bug if it might be dependent to
(over)load.
I was consuming Disk and CPU in a
Repro steps:
$ sudo apt install qemu-system-x86 novnc
/usr/share/novnc
python3 -m http.server
Connect browser to http://:8000/vnc.html
Click "Settings"
Open "advanced"
Open "websocket"
Set port 5700
Clear path
Click "Connect"
And it works ...
Turns out my former check on the
This is in v5.0.0 so fixed in Groovy.
The related noVNC change is in upstream version >=v1.0.0 which correlates with
Ubuntu >=20.04, threfore fixing this in Focals Qemu seems good.
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** Also affects: qemu (Ubuntu Focal)
Hi,
interesting bug report - thanks lee, Kashyap and Sean - as well as Danil for
taking a look already.
If this would always fail no unplugs would work ever which I knew can't
be right as I test that. So we need to find what is different...
@Openstack people - is that reliably triggering at
** Tags removed: server-next
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1589923
Title:
https websockets not working in 2.5 or 2.6
Status in QEMU:
Fix Released
Status in qemu package in
old version
sudo apt install qemu-system-s390x=1:4.2-3ubuntu6.4
...test as listed in the test instructions ...
ubuntu@focal-sqxbr:~$ ./a.out
Segmentation fault
(qemu is dead at this point)
$ sudo apt install qemu-system-s390x=1:4.2-3ubuntu6.5
Reading package lists... Done
Building dependency
Note: final upstream commit link
https://git.qemu.org/?p=qemu.git;a=commit;h=9bf728a09bf7509b27543664f9cca6f4f337f608
** Changed in: qemu (Ubuntu)
Assignee: Christian Ehrhardt (paelzer) => (unassigned)
--
You received this bug notification because you are a member of qemu-
devel
** Description changed:
+ [Impact]
+
+ * An instruction was described wrong so that on usage the program would
+crash.
+
+ [Test Case]
+
+ * Run s390x in emulation and there use this program:
+For simplicity and speed you can use KVM guest as usual on s390x, that
+after prep of
SRU need the bug 1890881 fix to be really helpful, but the dependency chain of
that is not SRUable.
See: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1890881/comments/17
Users (of this valid but rare use case) can either use Groovy which will
fix this or wait until Openstack Victoria will
To fully work this also needs the fix for bug 1890881 as identified
there.
** Changed in: qemu (Ubuntu Focal)
Status: New => Triaged
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1886811
Sorry, posted this on the wrong bug :-/
I beg your pardon for the noise.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1823790
Title:
QEMU mishandling of SO_PEERSEC forces systemd into tight loop
Bisect worked and once you find it it seems obvious that this is exactly
our case:
commit 65b261a63a48fbb3b11193361d4ea0c38a3c3dfd
Author: Laurent Vivier
Date: Thu Jul 9 09:23:32 2020 +0200
linux-user: add netlink RTM_SETLINK command
This command is needed to be able to boot
@Ryutaroh - could you test [1] if it gets you around this bug (1886811)
and if bug 1890881 is present in focal as well?
[1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4197
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to
** Also affects: qemu (Ubuntu Focal)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1886811
Title:
systemd complains Failed to enqueue loopback interface
I haven't seen any similar reports nor any updates here.
Might I ask if you have got any further since then?
Qemu 5.0 is available in Ubuntu 20.10 now, if you are willing to upgrade or
install a test system that might be worth a try (new libvirt is still WIP, but
unlikely to play a role here).
** Also affects: qemu (Ubuntu Focal)
Importance: Undecided
Status: New
** Changed in: qemu (Ubuntu Focal)
Status: New => Triaged
** Changed in: qemu (Ubuntu Focal)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of qemu-
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** Changed in: qemu (Ubuntu)
Status: New => In Progress
** Changed in: qemu (Ubuntu)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
--
You received this bug notification because you are a
y: Robert Foley
> Cc: BALATON Zoltan
> Cc: Christian Ehrhardt
> Message-Id: <20200724064509.331-7-alex.ben...@linaro.org>
>
I beg your pardon for the late reply, but I was out a week.
I see this is already the pull request and my former feedback was included
- thanks.
Neve
advisory so any users of it shouldn't just
> > fail if we can't work it out.
> >
> > The win32 stub currently returns 0 until someone with a Windows system
> > can develop and test a patch.
> >
> > Signed-off-by: Alex Bennée
> > Cc: BALATON Zoltan
&g
achine under increased memory pressure. Detect these low
> memory situations and reduce tb_size appropriately.
>
> Fixes: 600e17b261
> Signed-off-by: Alex Bennée
> Cc: BALATON Zoltan
> Cc: Christian Ehrhardt
> ---
> accel/tcg/translate-all.c | 7 ++-
> 1 file changed,
On Fri, Jul 17, 2020 at 4:07 PM Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:
> Since v5.0.0 and 600e17b2 "accel/tcg: increase default code gen buffer
> size for 64 bit" in particular qemu with TCG regularly gets OOM Killed
> on small hosts.
>
>
n/Max check in place to not reach ridiculously small values.
Fixes: 600e17b2
Signed-off-by: Christian Ehrhardt
---
accel/tcg/translate-all.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/accel/tcg/translate-all.c b/accel/tcg/translate-all.c
index 2afa46bd2
On Thu, Jul 16, 2020 at 6:27 PM Alex Bennée wrote:
>
> Christian Ehrhardt writes:
>
> > On Wed, Jul 15, 2020 at 5:58 PM BALATON Zoltan
> wrote:
> >
> >> See commit 47a2def4533a2807e48954abd50b32ecb1aaf29a and the next two
> >> following it.
>
ut it is enough to discuss it.
That should serve all cases - small and large - better as a pure
static default of 1G or always ram/4?
P.S. I added Alex being the Author of the offending patch and Richard/Paolo
for being listed in the Maintainers file for TCG.
--
Christian Ehrhardt
Staff Engineer
es [1] list anything that sounds related
But if this already rings a bell for someone please let me know.
Thanks in advance!
[1]: https://wiki.qemu.org/ChangeLog/5.0#TCG
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
This will re-open again for Bionic due to bug 1885419 forcing a revert of the
former backports.
After a deeper evaluation if the assert is wrong in the backport or just
flagging a problem formerly already existing in Bionic this will be re-fixed.
** Changed in: qemu (Ubuntu Bionic)
** Changed in: qemu (Ubuntu)
Assignee: Richard Henderson (rth) => Christian Ehrhardt (paelzer)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1749393
Title:
sbrk() not working under q
We had the 14 (instead f 7) days in -proposed for some extended maturing.
Nothing came up in regard to this and all validations were good.
Dropping block-proposed to be released once the SRU Team gets to it.
** Tags removed: block-proposed-bionic block-proposed-eoan block-
proposed-focal
--
On Tue, Jun 9, 2020 at 1:15 PM Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:
>
>
> On Thu, Jun 4, 2020 at 3:43 PM Christian Ehrhardt <
> christian.ehrha...@canonical.com> wrote:
>
>>
>>
>> On Thu, Jun 4, 2020 at 11:46 AM Marc-André L
On Thu, Jun 4, 2020 at 3:43 PM Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:
>
>
> On Thu, Jun 4, 2020 at 11:46 AM Marc-André Lureau <
> marcandre.lur...@redhat.com> wrote:
>
>> Since commit 781f2b3d1e ("qga: process_event() simplifi
I've looked and retried the tests - all green now.
Let us give it a few extra days in proposed as planned, but other than that it
looks ok to be released.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
n with QCO_NO_SUCCESS_RESP commands, such as
> "guest-shutdown".
>
> Fixes: 781f2b3d1e5ef389b44016a897fd55e7a780bf35
> Cc: Michael Roth
> Reported-by: Christian Ehrhardt
> Signed-off-by: Marc-André Lureau
> ---
> qga/main.c | 6 +-
> 1 file changed, 5 inser
ntainer of qga and the Author aware.
[1]: https://git.qemu.org/?p=qemu.git;a=commit;h=125b310e1d62
[2]: https://git.qemu.org/?p=qemu.git;a=commit;h=781f2b3d1e5e
[3]: https://git.qemu.org/?p=qemu.git;a=commit;h=48ff7a625b36
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
Migrated right now, sponsoring the related SRU portions into B/E/F ...
for consideration by the SRU Team.
--
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
FYI: sponsored into groovy
--
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 images
Status in kunpeng920:
In
@Andreas - If we find nothing else to try I'll ping you when I have a
newer qemu build for Ubuntu 20.10 for you to try.
** Tags added: qemu-20.10
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
The warnings in the report like "MSR(48FH).vmx-exit-load-perf-global-ctrl" are
unrelated (in regard to guest hang).
Those happen on
a) too old kernels that don't support the feature
b) mismatch of expectations of a chips vs its actual capabilities
E.g. if libvirt thinks a feature should be
** No longer affects: qemu (Ubuntu Disco)
--
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 images
Status in
** Changed in: qemu (Ubuntu)
Status: Triaged => Invalid
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1868116
Title:
QEMU monitor no longer works
Status in QEMU:
New
Status in qemu
Note: might be related (or not) to bug 1866870
Let's analyze as independent and dup if it turns out to be a dup.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1877052
Title:
KVM Win 10 guest
Hi Andreas,
so the only upgrade you did to trigger this for you was to bump the kernel from
5.4.0-28.33 to 5.4.0-29.34 - nothing else? I have not (yet?) heard other
similar reports, but it might be just too early?
At least on my system for now things still work with the new kernel like before.
Will be merged in 20.10 with qemu >=5.0 where this came upstream.
** Tags added: qemu-20.10
** Changed in: qemu (Ubuntu)
Status: Confirmed => Triaged
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Thanks Ken!
I verified it and the new version indeed fixes the issue in focal.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1868116
Title:
QEMU monitor no longer works
Status in QEMU:
New
As Vte-upstream long term would want to get rid of this implementation
style Christian Persch provided a qemu patch [1]. That is too much UI
for me to really have an in-depth opinion, but I can say that it builds
and input works fine with it.
I suggested on [2] to send it to qemu-devel, but in
Subscribed and Assigned to Ubuntu Desktop to get to 0.60.1 before Focal
releases.
I'd be happy about an update here that this surely is on your todo list.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
>From IRC:
[16:10] cpaelzer, @vte, we should get 0.60.1 for focal, 0.59.91 is a
rc1 for 0.60, we are lacking behind merging the stable version from Debian but
it's on our backlog (kenvandine was look at that one), the .1 is part of GNOME
3.36.1 which we plan to get before release (I would
I'm not sure how many of you are tracking the Vte bug [1] so here a
summary of the latest insight from there.
- Short term it seems that new behavior will be reverted in Vte 0.60.1.
- Long term the Vte devs might want to deprecate no-pty use cases or at least
better understand why apps use it
I'm not really a UI guy, so I was checking what I might have lost by disabling
VTE and found the very old [1]. That list of features really seems to make
disabling VTE not an real option:
"It's also screen reader accessible, supports copy/paste, proper scrolling and
most of the other
For a bit of reverse-confirmation of the findings so far.
If I build qemu without VTE, like (configure)
GTK support yes (3.24.14)
VTE support no
It works, due to the fallback implemented by [1][2].
But obviously without all the VTE features, I'd prefer a more fine grained fix
than
Thank you Egmont for the bug for VTE in the gnome tracker!
Graphics isn't something I'm usually at home - the related qemu code is
mostly in ui/gtk.c per Maintainers file Gerd Hoffmann is the expert. I
subscribed him to the bug here to raise visibility for him.
--
You received this bug
** Merge proposal unlinked:
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/381033
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1867519
Title:
qemu 4.2 segfaults on
Last commit mentioning VTE is a while ago:
6415994 Thu Oct 11 17:30:39 2018 +0200 gtk: Don't vte_terminal_set_encoding()
on new VTE versions
I built head of qemu against head of vte - to check if I even need to look for
existing fixes.
=> That still fails, so it is probably time for a bug
1 - 100 of 267 matches
Mail list logo
