FYI: Since this affects qemu (and VTE) git head I added an upstream-qemu
task to the bug.
** Tags added: champagne rls-ee-incoming
--
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:
Thank you Boris and Tstrike for the report and your help.
It was a great bug to identify and fix before the release of 20.04, I
appreciate you using (and hereby testing) it ahead of time!
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to
** 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
** Changed in: qemu (Ubuntu)
Status: Confirmed => Fix Committed
--
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 VF detach
Status in QEMU:
Fix Committed
Sent to seabios for their consideration:
=>
https://mail.coreboot.org/hyperkitty/list/seab...@seabios.org/thread/IXAWMA2HWW75LSR3NBBYQKWT3TI5WVVP/
I deleted the experimental PPAs that we had and created a new one with a new
seabios:
=>
** Changed in: qemu
Status: New => Invalid
** Changed in: qemu (Ubuntu)
Status: Incomplete => Invalid
** Also affects: seabios (Ubuntu)
Importance: Undecided
Status: New
** Changed in: seabios (Ubuntu)
Status: New => Triaged
--
You received this bug notification
Starting from the Disco build env that I had I changed the packages
Step #1 binutils:
Unpacking binutils-x86-64-linux-gnu (2.33-2ubuntu1.2) over (2.32-7ubuntu4) ...
Unpacking libbinutils:amd64 (2.33-2ubuntu1.2) over (2.32-7ubuntu4) ...
Unpacking binutils (2.33-2ubuntu1.2) over (2.32-7ubuntu4) ...
Turns out 1.12 is a fairly old build and the working version in Ubuntu was from
in Disco, therefore about a year ago.
=> https://launchpad.net/ubuntu/+source/seabios/1.12.0-1/+build/16284605
Therefore I built it in Eoan and even Disco.
As an overview:
Disco: gcc 4:8.3.0-1ubuntu3 binutils
I wanted to make sure why different qemu configs make it trigger or not,
and after finding seabios to be related the candidates were obvious.
Default config gets us:
BIOS directory/usr/local/share/qemu
The long conf had:
--firmwarepath=/usr/share/qemu:/usr/share/seabios:/usr/lib/ipxe/qemu
With that confirmed I checked if I can just point to a bios to break it, and
indeed adding
-bios /root/seabios_1.12.0-1/usr/share/seabios/bios.bin
-bios /root/seabios_1.13.0-1/usr/share/seabios/bios.bin
respectively is a make or break change.
As a next step I reproduced the error with
I regularly before a release pull in fixes that were posted for qemu-stable.
This is one of them, I'll again do such a build and retest this issue with it.
I identified and backported (only one needed modification) 33 patches.
But as usual there might be some context needed on top - I have build
I've tested smoe more cmbinations and found that I van have v4.2 work on focal.
Eventually I have realized that when I install start the qemu from Ubuntu not
only that but also the formerly working build of v4.2.0 from git start to fail
(without rebuilding).
A bit of package bisect later I
Might be
https://git.qemu.org/?p=qemu.git;a=commit;h=0446f8121723b134ca1d1ed0b73e96d4a0a8689d
This would also match the backtrace path.
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed
At the breaking function we have:
29 void notifier_remove(Notifier *notifier)
30 {
31 QLIST_REMOVE(notifier, node);
32 }
(gdb) p notifier
$1 = (Notifier *) 0x55d2f40c5078
(gdb) p *notifier
$2 = {notify = 0x0, node = {le_next = 0x0, le_prev = 0x0}}
And since QLIST_REMOVE
I changed the bug task to Qemu (Ubuntu) as this isn't a libvirt error.
I also added an upstream qemu task in case this is a known issue for the
developers there. Someone might be able to point us at a known
discussion/fix.
The Backtrace I added in the last comment should help to identify known
I re-run the above, full PCI passthrough still attaches/detaches fine.
VFs attach fine
VFs break on detach
I've thrown qemu into GDB and this is the backtrace
Thread 4 "CPU 0/KVM" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f82f0e31700 (LWP 3998)]
0x55d2f322d45d in
Thanks David!
While bisecting on upstream git with just "-cpu Penryn" we have seen that it
always works there.
So it might be an interaction with some Ubuntu build/packaging/configure detail
together with these old chips.
While we still can't be sure if the VMX warnings are a red-herring
Andreas was so kind to try kenels 4.4, 4.15 and 5.6 all fail (with qemu 4.2)
He then tried Eoan (qemu 4.0) and Focal (qemu 4.2).
4.0 worked and 4.2 failed.
We will set up a bisect run on Monday and hopefully find the offending
change.
@David - I agree that the messages might be a red-herring,
Yeah @Boris - it really seems to be an issue bound to the Merom/Penryn
processor generation.
I asked Andreas to check through some kernels and qemu versions so that
we maybe eventually can consider bisecting something. But that will take
a bit of time.
Of course everyone able to spend some time
By using host-model Andreas also was able to get the same signature:
2020-03-12T15:06:22.560159Z qemu-system-x86_64: warning: host doesn't support
requested feature: MSR(48EH).vmx-vnmi-pending [bit 22]
2020-03-12T15:06:22.560708Z qemu-system-x86_64: warning: host doesn't support
requested
It detects host as Penryn as well for @tstrike.
Which is fine if it is a chip of around that era.
He reported to have an "Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz"
And for that chip the detection and chip used might be correct.
So to summarize all repro fails, but on Penryn ERA chips 2/2 cases
Thanks Boris!
@tstrike - is your system also "really an old penryn" or is it something newer?
Maybe share /proc/cpuinfo?
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1866870
Title:
KVM Guest
@Boris - in your log I've seen that you also got the Penryn cpu which I find
odd.
"-cpu
Penryn,vme=on,vmx=on,x2apic=on,tsc-deadline=on,xsave=on,hypervisor=on,arat=on,tsc-adjust=on,arch-capabilities=on,skip-l1dfl-vmentry=on
\"
Assuming you also only used default I wonder how it got to that,
I fetched
https://download.fedoraproject.org/pub/fedora/linux/releases/31/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-31-1.9.iso
And installed it on Ubuntu 20.04 via virt-manager (keeping all things on
its default).
- New
- Local Media
- select ISO (Autodetects F31)
- Forward, Forward,
Thanks Boris for chiming in!
Maybe it is something in the guest (or the way virt-manager sets things up)
after all - will install an F31 via virt-manager as well ...
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
I tried with a guest XML matching yours (other than disk setup).
I didn't get those errors you reported even when using your config.
Notable differences to my default - your guest has:
- a rather old chip type (Penryn is a 2007 chip)
- a rather old machine type (uses xenial which matches
Thank you @tstrike:
In your logs I see a bunch of qemu warnings right at the beginning:
2020-02-12T15:09:37.773025Z qemu-system-x86_64: warning: host doesn't support
requested feature: MSR(48FH).vmx-exit-load-perf-global-ctrl [bit 12]
2020-02-12T15:09:37.773107Z qemu-system-x86_64: warning: host
@tstrike: finally for the sake of apparmor denials or any other odd
error that might be mentioned in there attaching the output of `dmesg`
on your host might be useful as well.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
@tstrike - can you trigger the same issue with all your guests?
You list Windows and Centos guests, does it triggers with Centos as well or
only the Windows guests?
Also if you have a chance (just to be sure) does it trigger with an Ubuntu
guest as well? This would help for people retrying not
Hi tstrike,
thanks for the report.
I have slightly modified the description and changed the bug tasks accordingly
for you.
** Bug watch added: Red Hat Bugzilla #1378006
https://bugzilla.redhat.com/show_bug.cgi?id=1378006
** Bug watch added: Red Hat Bugzilla #1464654
I first checked the related known fixes from the old case that is linked.
Just in case if we might miss one in Ubuntu 20.04 that you are using.
Kernel:
=> https://marc.info/?l=kvm=155085391830663=2
Tested and verified https://bugs.launchpad.net/qemu/+bug/1813165/comments/13
This got upstream and
Copied here from the other bug about the system setup that is in use:
L0 DistroRelease: Ubuntu 20.04 on Kernel Linux 5.4.0-14-generic x86_64
L1 3 guests Windows 10, Centos 8
No L2s
No guests are enabled for UEFI Boot
libvirt: 6.0.0-0ubuntu4
qemu 1:4.2-3ubuntu1
Issue triggers without nesting
** Description changed:
+ Symptom:
+ Error unpausing domain: internal error: unable to execute QEMU command
'cont': Resetting the Virtual Machine is required
+
+ Traceback (most recent call last):
+ File "/usr/share/virt-manager/virtManager/asyncjob.py", line 75, in
cb_wrapper
+
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** No longer affects: ubuntu
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1866870
Title:
KVM Guest pauses after upgrade
/msg5.html
[2]: https://lists.nongnu.org/archive/html/qemu-devel/2020-03/msg01593.html
[3]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3961
[4]:
https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/libvirt/+merge/380469
Christian Ehrhardt (1):
modules: load modules
in packaging can be seen in:
https://git.launchpad.net/~paelzer/ubuntu/+source/qemu/log/?h=bug-1847361-miss-old-so-on-upgrade-UBUNTU
Fixes: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1847361
Signed-off-by: Christian Ehrhardt
---
configure | 15 +++
util/module.c | 14
On Tue, Mar 10, 2020 at 1:10 PM Daniel P. Berrangé
wrote:
> On Tue, Mar 10, 2020 at 09:39:10AM +, Stefan Hajnoczi wrote:
> > On Fri, Mar 06, 2020 at 02:26:48PM +0100, Christian Ehrhardt wrote:
> > > On upgrades the old .so files usually are replaced. But on the other
>
On Tue, Mar 10, 2020 at 10:39 AM Stefan Hajnoczi wrote:
> On Fri, Mar 06, 2020 at 02:26:48PM +0100, Christian Ehrhardt wrote:
> > On upgrades the old .so files usually are replaced. But on the other
> > hand since a qemu process represents a guest instance it is usually
mu-doc.
The test build even runs with config:
module supportno
Which even means all my changes except the include are removed by the
preprocessor.
Do I need to do anything to reset the state of this patch to not be marked
as failed?
> ---
> Email generated automatically by Patchew [https://patchew.org/].
> Please send your feedback to patchew-de...@redhat.com
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
On Fri, Mar 6, 2020 at 11:54 AM Stefan Hajnoczi wrote:
> On Wed, Mar 04, 2020 at 10:39:46AM +0100, Christian Ehrhardt wrote:
>
> Please start a new email thread. Patches sent as replies to existing
> email threads are easily missed by humans and tooling also doesn't
> recogniz
in packaging can be seen in:
https://git.launchpad.net/~paelzer/ubuntu/+source/qemu/log/?h=bug-1847361-miss-old-so-on-upgrade-UBUNTU
Fixes: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1847361
Signed-off-by: Christian Ehrhardt
---
util/module.c | 7 +++
1 file changed, 7 insertions(+)
diff
in packaging can be seen in:
https://git.launchpad.net/~paelzer/ubuntu/+source/qemu/log/?h=bug-1847361-miss-old-so-on-upgrade-UBUNTU
Fixes: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1847361
Signed-off-by: Christian Ehrhardt
---
util/module.c | 7 +++
1 file changed, 7 insertions(+)
diff
On Fri, Nov 1, 2019 at 10:34 AM Daniel P. Berrangé
wrote:
> On Fri, Nov 01, 2019 at 08:14:08AM +0100, Christian Ehrhardt wrote:
> > Hi everyone,
> > we've got a bug report recently - on handling qemu .so's through
> > upgrades - that got me wondering how to best handle i
OR
Maas can boot from network (always) and if not deploying just issue a "reboot
from disk" command
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859656
Title:
[2.6] Unable to reboot s390x KVM
The assumption from here was that this only appeared to be working due
to:
a) Deploy = netboot + reboot from disk = working
but at the same time
b) Start = netboot (fail) + no fallback = fail
To get that from Maas UI we stopped the guest (it went down as expected).
Then from Maas we said
@sfeole - after initial deployment just do the change to your guest XMLs
you see in comment #27
@maas - as I said in comment #26 (and before) this needs coding in maas
to switch the XML content (or waiting a long time on IBM)
--
You received this bug notification because you are a member of
I flipped
to
And JFH started it from the MAAS UI again.
Now things work (obviously as expected)
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859656
Title:
[2.6] Unable to
Here are the interesting bits from the log:
1 LOADPARM=[]^M
2 Network boot device detected^M
3 ^M
** Attachment added: "Guest XML "as it was once working""
https://bugs.launchpad.net/maas/+bug/1859656/+attachment/5327027/+files/vm1-as-deployed-by-maas.xml
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
The one that currently is deployed is using the same "list network and hd"
which should not work.
It will boot network but should not internally fall back to disk.
10
11 hvm
12
** Attachment added: "Serial log "as it was once working""
https://bugs.launchpad.net/maas/+bug/1859656/+attachment/5327028/+files/working-guest-serial.log
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
FYI - Focal now contains 4.2 which might (or not) have the bits you need.
You most likely get further, but I can't give guarantees if enough of march=z13
is supported to work for a full Focal (not sure on vector instructions for
example) including all of userspace.
Marking it incomplete - if
I asked around a bit without going into the "why" and got confirmation from IBM
that fallthrough from netboot never existed.
In addition a RH engineer jumped in and said that they have this bug as well
and would appreciate if IBM would implement it (that is the RH ticket I added
to the other
First check - as assumed - the old style config always failed.
It went into netboot, netboot fails and then it bails out.
root@testkvm-bionic-from:~# virsh start netboot --console
Domain netboot started
Connected to domain netboot
Escape character is ^]
done
Using IPv4 address: 192.168.122.33
TBH I'd really want to see how this worked as we didn't push anything to
Bionic that would have changed this recently.
I checked and the only change in that regard is really old.
It was for bug 1790901 which was a prereq for real IPXE on s390x.
So I doubt that MAAS could have worked before that.
qemu-kvm doesn't exist for years, I have marked it for qemu instead.
Thanks Frank for making me aware.
Sean got everything right in comment #6, it can only boot one and that is the
first boot entry.
There is no fallback/fallthrough on s390x.
If you stick with global boot options the host would
** Project changed: qemu-kvm => qemu
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1859656
Title:
[2.6] Unable to reboot s390x KVM machine after initial deploy
Status in MAAS:
Incomplete
Status
Eoan - without fix -> hang
With fix:
qemu-img check http://10.193.37.117/cloud/eoan-server-cloudimg-amd64.img
No errors were found on the image.
This was tonight first accepted and then immediately rejected as it was
surpassed by a security fix.
=> Rebased and uploaded 1:4.0+dfsg-0ubuntu9.2 to eoan-unapproved again.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Hi Colin,
I didn't read much if the details but I think it is clear.
Per request of IBM focal got -march=z13 but tcg has no emulation for some
of the instructions of this cpu.
That is the breakage that you are seeing and afaik there is nothing we can
do than waiting for qemu to grow that
Focal is complete the MPs reviewed, SRU Teamplates ready and pre-tests done.
Uploading to E-unapproved for the SRU Teams consideration.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1848556
Title:
On Fri, Nov 1, 2019 at 10:34 AM Daniel P. Berrangé wrote:
>
> On Fri, Nov 01, 2019 at 08:14:08AM +0100, Christian Ehrhardt wrote:
> > Hi everyone,
> > we've got a bug report recently - on handling qemu .so's through
> > upgrades - that got me wondering how to best handl
would require fake hotplugs
which seems wrong
- Required additional upgrade pre-planning
- kills most benefits of modular code without an actual need for it
being loaded
c) go back to non modular build
- No :-)
d) anything else out there?
--
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd
FYI: uploaded to 20.04 Focal, considering SRUs (Eoan) after this
completes
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1848556
Title:
qemu-img check failing on remote image in Eoan
Status in
Now that Focal is open I have opened proper Focal MP replacing the old one and
also an Eoan SRU MP right away.
=>
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/374770
=>
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/374771
--
You received
** Changed in: qemu (Ubuntu Eoan)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
** 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 subs
For me with the version from the PPA works fine on local as well as remote http
connections.
Thanks @Max for the fix.
@Rod:
Waiting for you to test and verify based on the PPA.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
@Rod: Your self built issue seems like at config/make time there were
not all build deps available. I have put a test build in PPA [1], could
you give that one a try on your end as well?
[1]: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1848556-qemu-
img-curl-hang-eoan
--
You received
** Description changed:
+ Ubuntu SRU Template:
+
+ [Impact]
+
+ * There is fallout due to changes in libcurl that affect qemu and might
+lead to a hang.
+
+ * Fix by backporting the upstream fix
+
+ [Test Case]
+
+ * If you have network just run
+$ qemu-img check
Hi Max,
libcurl 7.65.3-1ubuntu3 and was >7.59 for several releases (more than a year at
least) - so there must be something else going on that this triggers now.
But never the less with the fix from [1] I can again get it to work
successfully.
I think I should backport that to our qemu 4.0 in
Since it seemed so easy, while bisecting I found that it hangs with
v4.0.0 and v3.1.0 from git and even v3.0.0.
Since the reported good version was 3.1 I began to wonder if I might have
overlooked something.
I wondered if it might be e.g. the apache version providing a different
behavior on
Quick checks:
- does not depend on the exact image, e.g.
https://cloud-images.ubuntu.com/eoan/current/eoan-server-cloudimg-amd64.img or
https://download.fedoraproject.org/pub/fedora/linux/releases/30/Cloud/x86_64/images/Fedora-Cloud-Base-30-1.2.x86_64.qcow2
hang as well
- the former qemu 3.1
The stuck poll is at:
#0 0x7fafb935ad26 in __GI_ppoll (fds=0x560dba615670, nfds=1,
timeout=, timeout@entry=0x0, sigmask=sigmask@entry=0x0) at
../sysdeps/unix/sysv/linux/ppoll.c:39
#1 0x560db89550b9 in ppoll (__ss=0x0, __timeout=0x0, __nfds=, __fds=) at
Hi Rod,
I did try to recreate with the qemu version that you have.
$ apt install apache2 qemu-system-x86
$ qemu-img create -f qcow2 /var/www/html/test.img 1G
# local
$ qemu-img check test.img
No errors were found on the image.
# remote
$ qemu-img check http://localhost:80/test.img
** Attachment added: "strace of the hanging qemu-img"
https://bugs.launchpad.net/qemu/+bug/1848556/+attachment/5298128/+files/qemu-img-hangs.strace
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
I forked that new discussion into
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1848497
Please follow there and leave this bug here to the originally reported error
signature.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
> I'd bet on this being the one fixed by
> 2bbadb08ce272d65e1f78621002008b07d1e0f03
But wasn't the breakage this fixes only added in qemu 4.0?
He reports his change is from qemu 2.10 to 2.11.
Unfortunately 2bbadb08 doesn't have a "fixes" line, maybe Ubuntu has
something backported that makes the
> I'd bet on this being the one fixed by
> 2bbadb08ce272d65e1f78621002008b07d1e0f03
But wasn't the breakage this fixes only added in qemu 4.0?
He reports his change is from qemu 2.10 to 2.11.
Unfortunately 2bbadb08 doesn't have a "fixes" line, maybe Ubuntu has
something backported that makes the
That seems to be the Libvirt of Ubuntu in Xenial.
In the past similar issues were uncommon configs or changed behavior on
updates that triggered apparmor or SELinux protection.
=> https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1747442
=> https://bugzilla.redhat.com/show_bug.cgi?id=731243
In regard to "similar bugs" it sounds more like [1] to me.
Which was around needing [2].
But just like the commit David mentioned is in 2.8 this one is in since
2.6 (and backported).
[1]: https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1647389
[2]:
** Also affects: qemu (Ubuntu)
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/1838569
Title:
virtio-balloon change breaks post 4.0 upgrade
Status in
That crash seems to be from sessioninstaller which is not related to
virt-manager.
But never the less from your log:
"ValueError: Namespace GtK not available"
But virt-manager could require the same.
In fact things are provided by gir1.2-gtk-3.0 and virt-manager has:
Depends: ...
That is a long list of install commands Hans Peter, wouldn't dependencies just
take care of it as well?
Anyway, I installed the same set of packages and it works fine for me.
Which Ubuntu release are you on?
What machine are you on?
Any further configuration done to libvirt yet?
Maybe a list of
ound this topic being almost a month old.
And related to this fedora bug [1] was closed by adding [2] which
matches [3] that was nacked in the discussion here.
Since I found nothing later (neither qemu commits nor further
discussions) I wonder if it has fallen through the cracks OR if there
was a kernel fix/change to resolve it (if that is the case a pointer
to the related kernel change would be nice)?
[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1718926
[2]:
https://src.fedoraproject.org/rpms/qemu/blob/master/f/0005-NOT-UPSTREAM-Build-fix-with-latest-kernel.patch
[3]: https://patchew.org/QEMU/20190604071915.288045-1-borntrae...@de.ibm.com/
> Thanks,
> Laurent
>
--
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
Hi Avi,
for the sake of giving it a try I had a second level guest and
suspended/resumed the first level guest a few times. I can't reproduce it.
OTOH you seem to have a hard time to identify which change introduced
this - if it was any change at all and not just by accident not showing
up
Related changes are
3 * SECURITY UPDATE: DoS via incorrect permissions check
4 - debian/patches/CVE-2019-3886-1.patch: disallow virDomainGetHostname
5 for read-only connections in src/libvirt-domain.c.
6 -
Hi,
Ken - I think all I said in comment #2 still applies (and likely won't change).
It really is a non-issue warning - and even if you e.g. have a zero-
warning-allowed policy then you can easily avoid that by using a CPU
type that doesn't enable it by default or switch it on/off as needed. In
This is done upstream, no need for the upstream bug task.
For Ubuntu I'll update the tasks to match the statement of sbeattie.
There are discussions to reconsider some of the backports, but unfortunately
the IA32_ARCH_CAPABILITIES infrastructure is a rather big set of changes.
** Changed in:
** Tags added: qemu-19.10
--
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
Status in intel:
New
Status in QEMU:
New
Bug description:
I only saw this because it expired now :-/
Anyone affected by this might want to take a look at bug 1776189 where
Ubuntu added a special machine type to more easily set "host-phys-bits"
which is the qemu flag to have more (usually the host has more)
available (at the cost of migratability). That
> @cpaelzer, if you have any suggestions for specific tests/configurations
> that might be good to test the specific code changed here, please let me
> know.
I have ran the few test that would cover that area in the past on PPAs already.
Unfortunately this is a very specific path and I don't have
I agree to Thomas, and in that case referring to your comment #2 - qemu
versions in Ubuntu are associated with the base Ubuntu version - so Ubuntu
16.04 will stick to qemu 2.5 + fixes.
Ubuntu 19.10 released next week has qemu 3.1 btw, see [1]
And vice versa for an upstream report (which is
$ ll /usr/bin/qemu-system-x86_64-spice
lrwxrwxrwx 1 root root 18 Mär 25 13:32 /usr/bin/qemu-system-x86_64-spice ->
qemu-system-x86_64*
This is just a compat symlink for a very old history.
It should not be used directly anymore, but then also not matter.
I have not seen the same with Ubuntu
Ubuntu Ee-series)
Status: New => Triaged
** Changed in: qemu (Ubuntu Ee-series)
Assignee: (unassigned) => 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
or version 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
root@pre-node1:~# cat /var/log/libvirt/qemu/instance-0038.log
2019-03-10 20:39:36.510+: starting up libvirt version: 4.0.0, package:
1ubuntu8.6 (Christian Ehrhard
:~# cat /var/log/libvirt/qemu/instance-0038.log
2019-03-10 20:39:36.510+: starting up libvirt version: 4.0.0, package:
1ubuntu8.6 (Christian Ehrhardt Fri, 09 Nov
2018 07:42:01 +0100), qemu version: 2.11.1(Debian 1:2.11+dfsg-1ubuntu7.9),
hostname: pre-node1
LC_ALL=C PATH=/usr/local
The PPA was built against -proposed so I had to enable that to install all libs.
That done the 19.0.0~rc6-1ubuntu0.1 with the set affinity change reverted works
quite nicely.
It would be great to get that into Ubuntu 19.04 until the involved
upstreams agreed how to proceed with it and we can
Hi Timo,
I tried to test with the mesa from ppa:canonical-x/x-staging
But there is a dependency issue in that PPA - I can't install all packages from
there.
It seems most of the X* packages will need a transition for the new mesa and
those are not in this ppa right now.
Installing all that I
** Also affects: mesa (Ubuntu Disco)
Importance: Medium
Status: Confirmed
** Also affects: qemu (Ubuntu Disco)
Importance: Undecided
Status: Triaged
** No longer affects: qemu (Ubuntu Disco)
** Changed in: mesa (Ubuntu Disco)
Status: Confirmed => Triaged
** Changed
Thanks Daniel and MarcAndre for chiming in here.
Atfer thinking more about it I agree to Daniel that actually mesa should honor
and stick with its affinity assignment.
For documentation purpose: the solution proposed on the ML is at
101 - 200 of 267 matches
Mail list logo
