This is reported against 5.4.0-30.34 (in the guest I assume).
Per [1] that date window is the change from
2020-05-08 12:58:43 Published Focal proposedmaindevel
5.4.0-31.35
2020-05-08 13:00:19 Superseded Focal proposedmaindevel
5.4.0-30.34
2020-05-05 12:18:15
FYI: other (than qemu build) hit due to the same error
https://lkml.org/lkml/2020/2/12/93
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1877123
Title:
4.15.0-100.101 breaks userspace bu
Public bug reported:
This started as a debug session why qemu no more builds in
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1847361/comments/55
The summary of the kernel bug discovered is:
$ diff -Naur swab.h.4.15.0-99.100.good swab.h.4.15.0-100.101.bad
--- swab.h.4.15.0-99.100.good 2020
Assigned to klebers who seems to own it (per IRC discussion on this
topic).
Please give me a ping here once a re-spin of this is in Bionic-proposed.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.n
The case with the module parameter in SEV needs a fix similar to
https://libvirt.org/git/?p=libvirt.git;a=commit;h=b183a75319b90d0af5512be513743e1eab950612
as it can be re-loaded at any time.
Essentially the checks in virQEMUCapsLoadCache check qemu/kernel version and
many other things.
They a
FYI:
19.04:
ii dmidecode 3.2-2amd64SMBIOS/DMI table decoder
$ sudo cat /sys/class/dmi/id/product_serial
VMware-42 18 59 50 7a fe ee b9-86 41 a6 c8 5a 5a 23 a6
$ sudo dmidecode | grep -i serial | grep VM
Serial Number: VMware-42 18 59 50 7a fe ee b9-86 41 a6 c8 5a 5a 2
Since ages qemu is locking the image files (I think since 18.04) and
that seems to block the command here.
IIRC Read-only readers can flag their open calls to skip that (e.g.
qemu-img has an option --force-share). Not sure what virt-clone uses
here, but whatever it is needs the similar treatment.
Agreed @cborntra, if that is your use case then those two ways are not
equivalent.
Then for now I only know of the "workaround to specify kernel/initramfs
directly" that you are aware of as well.
Let's see what feedback Andrew gets when asking to change the path back.
--
You received this bug
Actually the following works pretty well for getting to the old-style installer
on s390x.
Instead of a location to the install-dir, just hand it an ISO (can also be a
local file).
virt-install --name ubuntu20-guest1 --memory 4096 --vcpus 4 --disk
"size=4" --cdrom http://cdimage.ubuntu.com/ubuntu
in the function _set_url_paths it makes up the defaults:
# generic
url_prefix = "current/images"
...
# s390x specific as it can't find "normal" kernel/initrd there
hvmroot = "%s/generic/" % url_prefix
kernel_basename = "kernel.%s" % self._debname
That will construct
http://ports.ubunt
Thanks David, so it might be issues with special HW types.
I'm glad you identified quirks to loas uas with to mitigate the issue - this
might help others being affected.
But until I have a local reproducer to debug in-depth I'm not sure I can
do more on the libvirt side (and even then no promises
There is no power box free this week, but indeed I'm +1 as well.
Test results look good as well (I've re-run them just to be extra sure) btw:
prep (x86_64): Pass 20 F/S/N 0/0/0 - RC 0 (15 min 55036 lin)
migrate (x86_64) : Pass 288 F/S/N 0/0/0 - RC 0 (60 min 214809 lin)
cross (x86_64)
Chances are high that this -fixed was brought in via a bug/discussion,
lets check the changelog to find it.
9 gcc-9 (9.3.0-1) unstable; urgency=medium
...
16 * Stop shipping the include-fixed directory.
...
2
Hmm, there is a very suspicious dir showing up:
echo "#include " | gcc -E -Wp,-v -
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/9/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include
this still had one indirection
this is even better:
$ cat > test.c << EOF
> /*
> * Test FTBFS 1867316
> */
>
> #include
> EOF
ubuntu@focal-ftbfs:~/chrony-3.5$ gcc -c test.c
In file included from test.c:5:
/usr/include/limits.h:124:26: error: no include path in which to search for
limits.h
1
** Changed in: alsa-topology-conf (Ubuntu)
Assignee: (unassigned) => Didier Roche (didrocks)
** Changed in: alsa-ucm-conf (Ubuntu)
Assignee: (unassigned) => Didier Roche (didrocks)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
Ping for FF closing in and this holding back some DPDK functionality.
Any updates on getting this in time into 20.04?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1836708
Title:
Please
The mentioned commit 6ab79a20af3a7b3bf610ba9aebb446a9f0b05930 is in qemu 4.1
and later.
Since we will have qemu 4.2 in 20.04 please retry with that once available.
I'll set a bug tak reference in the changelog of the update.
** Tags removed: qemu-19.10
** Tags added: qemu-20.04
--
You received
Thank you for your report.
This looks like a valid warning to me, rather than a bug in Ubuntu.
Also the bug lacks some details to go any further on it.
You can find pointers to get help for this sort of problem here:
http://www.ubuntu.com/support/community
Since we use this bug tracker to track
Yep, agreeing tho You-Sheng.
People are seeing this when e.g. using lm-sensores as it will trigger the hwmon
interfaces which have plenty of these old calls.
Here an example list:
Documentation/hwmon/hwmon-kernel-api.rst:27:
hwmon_device_register_with_groups(struct device *dev, const char *name
Ping, what is up with this nowadays?
I'm still not seeing this in Focals kernels (but as mentioned before in
Debian).
This blocks XDP support in DPDK for 20.04.
And most likely will make us need a Delta to Debian :-/
Therefore I wanted to ask if there is any update on this, a clear
blocker so I
I found no obvious regressions with this build in a run of our usual set
of tests.
@IBM - for SRu verification - can you give the actual testcase it was
intended for a shot in your environment as you had that set up int he
past?
--
You received this bug notification because you are a member of K
5.4 is around and will be in Focal soon.
If you could test there then that it is good the kernel team can consider
backports.
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
** Changed in: strongswan (Ubuntu)
Status: Triaged => Invalid
--
You received this bug notif
** Changed in: strongswan (Ubuntu)
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1828035
Title:
StrongSwan with GCM and large packet sizes produces
This got surpassed by a security upload while waiting for SRU Team.
I have uploaded rebased versions to -unapproved.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1842774
Title:
Enhance
This got surpassed by a security upload while waiting for SRU Team.
I have uploaded rebased versions to -unapproved.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1847948
Title:
Improve
** Changed in: qemu (Ubuntu)
Assignee: Rafael David Tinoco (rafaeldtinoco) => (unassigned)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1849720
Title:
KVM with e1000e and WinGuest
On Tue, Nov 12, 2019 at 5:35 AM Zach Graceffa
<1849...@bugs.launchpad.net> wrote:
>
> @Christian - 5.4-rc7 worked for both e1000e and virtio NICs. No crash as
> of about 15 minutes.
Great, thanks Zach for the check!
@kernel-team, that means there likely is something in 5.3 -> 5.4 that
you could i
I did a retry on my own as well (kernel 5.3, virtual e1000e card, win
server guest), but it just won't fail for me. That confirmed Rafaels
much more various tests :-/
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https:/
@Rafael - IIRC you said all combinations you tried didn't trigger anything for
you - is that correct?
If so please state it here and mark the bug on the qemu task invalid and
unassign yourself as it seems much more a kernel issue right now.
Or did you have combinations left to try?
--
You recei
@Kernel Team - this has enough affected people that I'd rate this at least high
severity.
Unfortunately none of "us" could reproduce it on our side yet to bisect on our
own.
As you see above affected users were so kind to test mainline kernels and
identified 5.2.21-050221 - 5.3.0-050300 already.
This doesn't need kernel logs at this state of the bug, bot pleas stop
spamming :-)
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchp
Zach, thanks for the feedback.
Since we still struggle to recreate this on our side is there a chance that you
could test kernels from [1] to help spotting which version bump exactly it was?
Going further we might even need to bisect things, but one step at a time.
I'd not want to put this on you
Most likely we will have qemu 4.2 in Ubuntu 20.04.
But we already closed this bug for qemu with the patches you identified in the
past.
If you need - for tracking purposes - a bug that closes once these further
changes are in I'd ask you to open a new one.
--
You received this bug notification
Uploaded for SRU Team review and acceptance into proposed.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1847948
Title:
Improve NVMe guest performance on Bionic QEMU
Status in The Ubun
Uploaded the Disco version along the upload to Bionic for SRU Team
review and acceptance into proposed.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1842774
Title:
Enhanced Hardware Su
As outlined in the past conceptually there is nothing that qemu can do.
The kernel can in theory get memory zeroing to become concurrent and thereby
scale with CPUs but that is an effort that was already started twice and didn't
get into the kernel yet.
Workarounds are known to shrink that size
Hi Rafael,
thanks for giving it try. We knew it might be complex when we first saw the
changes.
And I consider it wise to - at some point - step back and realize this won't be
SRUable.
I'll summarize what we know about the libvirt portion of this:
## SRUability ##
The changes are rather complex,
Actually the bug here has nothing to so with the kernel bug which was
just a build issue, lets remove the kernel task to not distract.
** No longer affects: linux (Ubuntu)
** No longer affects: linux (Ubuntu Bionic)
** No longer affects: linux (Ubuntu Disco)
** No longer affects: linux (Ubuntu
Next issue is around skb_frag_size_sub skb_frag_dma_map skb_frag_address
/usr/src/dpdk-rte-kni-18.11.2/ethtool/igb/igb_main.c:5352:12: error: assignment
to ‘struct skb_frag_struct *’ from incompatible pointer type ‘skb_frag_t *’
{aka ‘struct bio_vec *’} [-Werror=incompatible-pointer-types]
5352
Fix the next issue around num_online_cpus
** Patch added: "num-online-cpus"
https://bugs.launchpad.net/ubuntu/eoan/+source/dpdk/+bug/1848585/+attachment/5298831/+files/dpdk-kni-fix-num_online_cpus.patch
--
You received this bug notification because you are a member of Kernel
Packages, which
Probably related to kernel change:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c09ab96fc820109d63097a2adcbbd20836b655f
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchp
Here is the fix for the first issue that was hit (attached), but there
is more after that, now I hit:
/usr/src/dpdk-rte-kni-18.11.2/ethtool/ixgbe/kcompat.h:239:27: error:
‘smp_num_cpus’ undeclared (first use in this function)
239 | #define num_online_cpus() smp_num_cpus
** Patch added: "fix f
## DPDK in Ubuntu ##
18.11.x:
$ grep -Hrn pci-aspm *
kernel/linux/kni/ethtool/ixgbe/kcompat.h:2225:#include
kernel/linux/kni/ethtool/igb/kcompat.h:2417:#include
The same is true for DPDK 17.11.x in Bionic.
That is in the file of dpdk-rte-kni-dkms:
/usr/src/dpdk-rte-kni-18.11.2/ethtool/ixgbe/kcomp
After that detour now back to DKMS on DPDK.
The issue is this:
make: Entering directory '/usr/src/linux-headers-5.4.0-050400rc3-generic'
CC [M] /var/lib/dkms/dpdk-rte-kni/18.11.2/build/kni_net.o
CC [M] /var/lib/dkms/dpdk-rte-kni/18.11.2/build/kni_misc.o
CC [M] /var/lib/dkms/dpdk-rte-kni/1
Confirmed the new rebuild of the mainline kernels resolved the issue
** Changed in: linux (Ubuntu)
Status: Incomplete => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/
[23:45] I'm trying to perform a test build against a 5.4 mainline
kernel, it appears that the Makefile is missing from the linux headers (it's a
broken symlink)
[23:45] I'm pulling the linux stuff from:
https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.4-rc3/
[23:46] (the test build is for a
I marked it to affect kernel as well, but it seems from above discussion that
it might already be solved by a rebuild now.
Checking ...
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/18485
I opened up the MP for review again after pushing the extra patches that you
tested.
Once that is done I can push it to the SRU teams queue ...
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bu
Thanks Murilo, I need no test with the basic kernel yet.
But later when we really SRU this it will be good to do both a old and a HWE
kernel check.
Let me add that to the verification steps ...
** Description changed:
[Impact]
- * In the past qemu has generally not allowd MSI-X BAR mapping
Thanks for your feedback and tests Murilo*2 (There seems to be a team of
Murilo's on this :-) - thanks for your efforts and fast responses
bringing this case forward.)
With the main changes requested I really think we need the patch in #8
to avoid issues on other HW setups that due to the new code
@Murilo: I was wondering - I think we might want/need also [1] to not
run into fatal false positives. What is your opinion on this?
[1]:
https://git.qemu.org/?p=qemu.git;a=commit;h=567b5b309abe744b1098018a2eb157e7109c9f30
** Description changed:
+ [Impact]
+
+ * In the past qemu has generally
And on top of the former question most likely then also [1].
[1]:
https://git.qemu.org/?p=qemu.git;a=commit;h=5c08600547c059e3fd072995f9f367cdaf3c7d9d
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad
** Description changed:
+ @SRU Team: For SRU template of Qemu please scroll down ...
+
SRU Justification Kernel:
=
[Impact]
* Add / activate support for IBM z15 and LinuxONE III systems
[Fix]
* a0e2251132995b962281aa80ab54a9288f9e0b6b a0e2251 "s390:
All systems I could easily get a hold of already had their NVME drives
in use so I couldn't pass them through easily. Therefore I'd like to
come back to your offer to check the test build.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to li
FYI: Test builds are in [1]. It isn't required, but would be great if
you could give it a check as well ahead of the actual SRU.
[1]:
https://launchpad.net/~paelzer/+archive/ubuntu/bug-1847948-nvmeperf-1842774
-z15name-bionic
--
You received this bug notification because you are a member of Kern
@SRU Team:
As outlined above this is important for IBM to get product names right
everywhere. But at the same time this is "only" a change in a description which
doesn't qualify an SRU on its own. So we agreed to only upload it once there is
another SRU.
I now have an Qemu SRU for Bionic that I
I must have been blind, of course your testcase in the description is
fine. Sorry for even asking.
I'll give it a try if it also works to reflect the improvement on some
HW I can access, but if not thanks for offer to test it on your side.
--
You received this bug notification because you are a
FYI kernel commit is [1] I haven't checked if any context is needed.
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1847948
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1847948
Tit
The kernel part of this is in since 4.16 so it either needs a HWE kernel
or to add a kernel Task to backport the related change for the kernel as
well. I'll add a task but it depends the Kernelteam (doability) and the
reporters request (for which kernel it is needed).
** Also affects: linux (Ubunt
For Qemu the code is in 2.12, therefore as requested we only need to
consider Bionic.
@Murilo: do you have a good testcase for this to verify the bug when it became
an accepted SRU?
Could you outline what has to be done and if it requires special HW or a rather
complex setup maybe even commit to
Thanks Andreas for already commenting on the upstream ZFS issue!
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to zfs-linux in Ubuntu.
https://bugs.launchpad.net/bugs/1847105
Title:
very slow disk creation, snapshotting
Status in virt-m
FYI - it seems upstream of libvirt/virt-manager settles on the new
behavior actually being preferable. I tend to agree, and the pain only
happens if you also run things on ZFS which would be resolved if [1] is
ever fully resolved.
Adding a ZFS task for that.
[1]: https://github.com/zfsonlinux/zfs
** Also affects: qemu (Ubuntu Eoan)
Importance: Undecided
Status: Invalid
** Also affects: linux (Ubuntu Eoan)
Importance: Medium
Status: In Progress
** Changed in: linux (Ubuntu Bionic)
Status: In Progress => Won't Fix
--
You received this bug notification because yo
In fact while I was waiting to submit this the MP got reviewed.
Uploaded to Eoan ...
But since beta freeze is in place acceptance there might have to wait a
few days.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https:
Test build [1] seems ok and MP opened [2].
But the change is trivial so that should be quick ...
[1]:
https://launchpad.net/~paelzer/+archive/ubuntu/fix-1842774-z15-model-name-eoan
[2]:
https://code.launchpad.net/~paelzer/ubuntu/+source/qemu/+git/qemu/+merge/373118
--
You received this bug not
Hi,
since [1] doesn't change the identifier (it stays gen15a), so the only thing
that is changing is the description of e.g. seen here:
$ qemu-system-s390x -cpu ? | grep gen15
s390 gen15a-base IBM 8561 GA1(static,
migration-safe)
s390 gen15a IBM 8561 GA1
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1842774
Title:
Enhanced Hardware Support - Finalize Naming
Stat
It was already clear on the bug that for qemu I can't do much more as-is.
So I had a discussion with the Maas Team today.
To core issue for me stays that it seems it is unreproducible outside of Maas.
We agree that:
- they try to recreate it in a MAAS
- Once they can we sync and find day(s) to sit
After discussing this with the Team I really think it is ok to release this.
As stated before we confirmed:
- that on a good kernel the fix works
- the fix doesn't break features if not running on the new kernel
- the fix is confirmed to get in the kernel soon (this kernel cycle)
In addition relea
Thanks a lot Fabiano!
So I summarize:
- #7 is in no way a degradation to #4:
- all cap-ibs= modes are failing on that before and after
- that means the new qemu didn't break anything in that regard
- #9 confirms that as soon as we have a fixed kernel under that new disco-qemu
it will work for
Thanks a lot faro...@br.ibm.com.
Especially for noting the known firmware featues influencing this in your case
and then combining cap-ibs=workaround,cap-ccf-assist=on to prove the new
features work.
I see that cap-ccf-assist=on can be used and successfully grants the guest
[0.00] count-
Per my Tests we already know that on DD2.0 HW things are fine, you can't enable
CCF which is expected, but it doesn't break formerly working cases there.
And I'm not sure if there is DD2.3 HW in the wild already.
Furthermore I was in contact with Leonardo yesterday, he is working with
the Authors
I think I found the missing kernel bit.
As reported it needs:
2b57ecd0208f KVM: PPC: Book3S: Add count cache flush parameters to
kvmppc_get_cpu_char()
Which was brought into Bionic/Cosmic already as part of bug LP1822870.
This is only needed when I'd be on new HW/FW
Bionic: $ grep -Hrn KVM_PPC
Back in bug 1822870 it was reported that the Disco kernel is only
missing 92edf8df which is still applied to Disco these days. Maybe due
to that 2b57ecd0208f was lost.
@Kernel Team - could you go through all changes that made up bug 1822870
and ensure whatever is missing will be added to Disco?
-
BTW - Thanks for the work on this Rafael!
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1834522
Title:
Bionic QEMU with Bionic Kernel hangs in AMD FX-8350 with cpu-host as
passthrough
Lacking better options I gave this some extra testing on a pre DD2.3 P9 box.
revision: 2.2 (pvr 004e 1202)
I though at least CCF=off I should be able to test with these chips and that
worked fine.
Summary:
- the new versions make cap-ibs=fixed-ibs work on DD2.2
- CCF=off works with Bionic
FYI - the related autopkgtest issues would now be resolved.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1832622
Title:
QEMU - count cache flush Spectre v2 mitigation (CVE) (required
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu Disco)
Status: New => Confirmed
** Changed in: linux (Ubuntu Disco)
Importance: Undecided => High
** No longer affects: linux (Ubuntu Cosmic)
** No longer affects: linux (Ubuntu Eo
As qemu (seems) to be unable to do much I'll set it to triaged (we
understand what is going on) and low (can't do much).
** Changed in: qemu (Ubuntu)
Status: Incomplete => Triaged
** Changed in: qemu (Ubuntu)
Importance: Medium => Low
--
You received this bug notification because you
This is a silly but useful distribution check with log10 of the allocation
sizes:
Fast:
108 3
1293 4
12133 5
113330 6
27794 7
1119 8
Slow:
194 3
1738 4
17375 5
143411 6
55 7
3 8
I got no warnings about missed call
I modified the kernel to have a few functions non-inlined to be better tracable:
vfio_dma_do_map
vfio_dma_do_unmap
mutex_lock
mutex_unlock
kzalloc
vfio_link_dma
vfio_pin_map_dma
vfio_pin_pages_remote
vfio_iommu_map
Then run tracing on this load with limited to the functions in my focus:
$ sudo tra
(systemtap)
probe module("vfio_iommu_type1").function("vfio_iommu_type1_ioctl") {
printf("New vfio_iommu_type1_ioctl\n");
start_stopwatch("vfioioctl");
}
probe module("vfio_iommu_type1").function("vfio_iommu_type1_ioctl").return {
timer=read_stopwatch_ns("vfioioctl")
printf("Complet
The iommu is locked in there early and the iommu element is what is passed from
userspace.
That represents the vfio container for this device (container->fd)
qemu:
if (ioctl(container->fd, VFIO_IOMMU_MAP_DMA, &map) == 0
kernel:
static long vfio_iommu_type1_ioctl(void *iommu_data,
unsigne
Each qemu (version) is slightly different in the road to this, but then
seems to behave.
This one is slightly better to get "in front" of the slow call to map all the
memory.
$ virsh nodedev-detach pci__21_00_1 --driver vfio
$ gdb /usr/bin/qemu-system-x86_64
(gdb) b vfio_dma_map
(gdb) command
I could next build a test kernel with some debug around the vfio iommu dma map
to check how time below that call is spent.
I'm sure that data already is hidden in some of my trace data, but to
eventually change/experiment I need to build one anyway.
I expect anyway to summarize and go into a dis
Reference:
this is the call from qemu that I think we see above (on x86) is at [1].
If this time the assumption is correct the kernel place would be at
vfio_iommu_type1_ioctl.
For debugging:
$ gdb qemu/x86_64-softmmu/qemu-system-x86_64
(gdb) catch syscall 16
(gdb) run -m 131072 -smp 1 -no-user-co
Many ioctls (as expected) but they are all fast and match what we knew from
strace.
Thread 1 "qemu-system-x86" hit Catchpoint 1 (call to syscall ioctl),
0x772fae0b in ioctl () at ../sysdeps/unix/syscall-template.S:78
78 in ../sysdeps/unix/syscall-template.S
(gdb) bt
#0 0x772
Just when I thought I understood the pattern.
Sixth run (again kill and restart)
6384 9.826097 <... ioctl resumed> , 0x7ffcc8ed6e20) = 0 <19.495688>
So for now lets summarize that it varies :-/
But it always seems slow.
--
You received this bug notification because you are a member of Ker
The above was through libvirt, doing that directly in qemu now to throw
it into debugging more easily:
$ virsh nodedev-detach pci__21_00_1 --driver vfio
$ qemu/x86_64-softmmu/qemu-system-x86_64 -name guest=test-vfio-slowness
-m 131072 -smp 1 -no-user-config -drive
file=/var/lib/uvtool/libvirt
On x86 this looks pretty similar and at the place we have seen before:
45397 0.73 readlink("/sys/bus/pci/devices/:21:00.1/iommu_group",
"../../../../kernel/iommu_groups/"..., 4096) = 34 <0.20>
45397 0.53 openat(AT_FDCWD, "/dev/vfio/45", O_RDWR|O_CLOEXEC) = 31
<0.33>
I built qemu head from git
$ export CFLAGS="-O0 -g"
$ ./configure --disable-user --disable-linux-user --disable-docs
--disable-guest-agent --disable-sdl --disable-gtk --disable-vnc --disable-xen
--disable-brlapi --enable-fdt --disable-bluez --disable-vde --disable-rbd
--disable-libiscsi --disab
I was by accident changing the kernel task, fixed now.
** Changed in: linux (Ubuntu Eoan)
Status: Fix Released => In Progress
** Changed in: libvirt (Ubuntu Eoan)
Status: In Progress => Fix Released
** Changed in: libvirt (Ubuntu Eoan)
Assignee: Christian Ehrhardt (p
Tests confirmed that the recent libvirt did in fact work fine.
FYI - this was analyzed in bug 1841066 which will also be the bug to track this
little qemu addition which has to go alongside the libvirt portion of this once
considering SRUs.
** Changed in: linux (Ubuntu Eoan)
Status: In Pr
Hmm, with strace showing almost a hang on a single of those ioctl calls
you'D think that is easy to spot :-/
But this isn't as clear as expected:
sudo trace-cmd record -p function_graph -l vfio_pci_ioctl -O graph-time
Disable all but 1 CPUs to have less concurrency in the trace.
=> Not much bet
On this platform strace still confirms the same paths:
And perf as well (slight arch differences, but still mem setup).
46.85% [kernel] [k] lruvec_lru_size
16.89% [kernel] [k] clear_user_page
5.74% [kernel] [k] inacti
As assumed this really seems to be cross arch and for all sizes.
Here 16 PU, 128G on ppc64el:
#1: 54 seconds
#2: 7 seconds
#3: 23 seconds
Upped to 192GB this has:
#1: 75 seconds
#2: 5 seconds
#3: 23 seconds
As a note, in this case I checked there are ~7 seconds before it does
into thi
Another bunch of related changes might be important.
Not sure how much of that will go into SRUs - I hope not all of it.
Already in Eoan we should try to use a reduced set or we could go directly to
5.5 which has other known issues.
63acb7bf qemu_process: Prefer generic qemuMonitorGetGuestCPU
cc
I started a test PPA [1] and an MP [2] to get this into Eoan.
@Rafael could you test this on the same system you used last time and review
the MP?
[1]: https://launchpad.net/~paelzer/+archive/ubuntu/bug-1828495-archcap-eoan
[2]:
https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/lib
Recent libvirt versions (5.5) added more for arch_capabilities.
Lets get that into Eoan before considering the SRUs back to Bionic afterwards.
commit ver subject
2674d00e 5.5 qemu: Drop MSR features from host-model with old QEMU
8eb4a89f 5.5 qemu: Forbid MSR features with old QEMU
c8ec678f 5.5 c
301 - 400 of 693 matches
Mail list logo
