Hello Laszlo, Thank you for the rundown. I enabled the additional LIBGUESTFS_BACKEND_SETTINGS, and I have attached a follow up to the libguestfs-test-tool output.
I also checked out my CPU settings (cat /proc/cpuinfo output attached), and the host does appear to support PCLMULQDQ (AMD Ryzen 7 5700X). I also checked the cpuinfo in one of the guests I have created (Ubuntu 18.04, unstable due to intermittent kernel panics), and the cpuinfo indicates that this feature seems to be passed down to my guest as well. I noticed that the libguestfs-test-tool didn't seem to like the qemu settings it tried to boot with. So, I went back to basics and built a disk using qemu-img (qcow2) and utilized qemu-system-x86_64 to do the base install (Ubuntu 18.04). The resulting image boots and I import the resulting image with virt-install. However, the GUI/console seems to want to lock up shortly after boot if I am using virt-tools. The guest seems more stable when I boot it directly with `qemu-system,` and this may be my workaround for now. In virt-tools, I can consistently get a panic on the guest by trying to enable the qemu-guest-agent: `systemctl enable qemu-guest-agent.` Unfortunately, I cannot get the full output from that panic (attached). It would seem that this problem is more than just libguestfs-tools. Is there a KVM listserv that this might be more appropriate for? Sincerely, On Mon, Mar 20, 2023 at 1:31 AM Laszlo Ersek <ler...@redhat.com> wrote: > On 3/17/23 16:10, Justin Churchey wrote: > > Hello Everyone, > > > > I was having some difficulties converting OVA images yesterday. At > > first, I thought it may have been a compatibility issue with > > VirtualBox 7.0. However, when I went to run libguestfs-test-tool, it > > began failing with the exact same error as the conversions, which > > leads me to believe the issue may lie with libguestfs and not the > > images themselves. > > > > To test further, I created a fresh install of Ubuntu 22.04, and the > > libguestfs-test-tool seems to fail with the same error, even on a > > fresh install. I am attaching the libguestfs-test-tool output for > > reference. > > > > Ubuntu 22.04 is running libguestfs-tools 1.46.2-10ubuntu3 > > > > If anybody has any insight into the issue, or if you feel a bug report > > needs to be filed, please let me know. > > Your appliance kernel crashes. > > Here's my theory on why this might happen, based on your log. > > The guestfish appliance runs with KVM acceleration. > > The crash happens after/while inserting the modules crc32-pclmul.ko and > crct10dif-pclmul.ko. > > The "pclmul" in the names of those modules indicates that these modules > calculate various (crc32) checksums with the PCLMULQDQ instruction. I > believe that PCLMULQDQ is an advanced / accelerated instruction and not > all CPUs may support it. > > Your appliance guest is started with "-cpu max" on the QEMU command line > (from libguestfs commit 30f74f38bd6e, "appliance: Use -cpu max.", > 2021-01-28). This is probably why the appliance kernel thinks PCLMULQDQ > is available. > > I think the PCLMULQDQ instruction may cause an issue here. I don't know > why it misbehaves under KVM, but that's my suspicion anyway. > > Note that the kernel crash log provides the following instruction > (assembly binary) dump: > > 46 70 48 8b 56 68 48 03 97 90 01 00 00 48 c1 e0 06 48 03 46 20 48 89 97 > 08 02 00 00 48 be ab aa aa aa aa aa aa aa 48 8b 48 10 <48> 89 0a 48 8b > 50 20 48 8b 8f 08 02 00 00 48 89 d0 48 f7 e6 48 c1 > > with the instruction starting at <48> causing the page fault, as the > direct symptom. Now, we can disassemble this: > > printf \ > '%b' \ > > '\x46\x70\x48\x8b\x56\x68\x48\x03\x97\x90\x01\x00\x00\x48\xc1\xe0\x06\x48\x03\x46\x20\x48\x89\x97\x08\x02\x00\x00\x48\xbe\xab\xaa\xaa\xaa\xaa\xaa\xaa\xaa\x48\x8b\x48\x10\x48\x89\x0a\x48\x8b\x50\x20\x48\x8b\x8f\x08\x02\x00\x00\x48\x89\xd0\x48\xf7\xe6\x48\xc1' > \ > > bin > > $ ndisasm -b64 bin > > 00000000 467048 jo 0x4b > 00000003 8B5668 mov edx,[rsi+0x68] > 00000006 48039790010000 add rdx,[rdi+0x190] > 0000000D 48C1E006 shl rax,byte 0x6 > 00000011 48034620 add rax,[rsi+0x20] > 00000015 48899708020000 mov [rdi+0x208],rdx > 0000001C 48BEABAAAAAAAAAA mov rsi,0xaaaaaaaaaaaaaaab > -AAAA > 00000026 488B4810 mov rcx,[rax+0x10] > 0000002A 48890A mov [rdx],rcx <----------- crash > 0000002D 488B5020 mov rdx,[rax+0x20] > 00000031 488B8F08020000 mov rcx,[rdi+0x208] > 00000038 4889D0 mov rax,rdx > 0000003B 48F7E6 mul rsi > 0000003E 48 rex.w > 0000003F C1 db 0xc1 > > Note the constant 0xaaaaaaaaaaaaaaab; that seems very special. We can > search the kernel tree for it (I'm not bothering about checking out the > particular ubuntu kernel version for now): > > $ git grep -i aaaaaaaaaaaaaaab > arch/x86/math-emu/poly_atan.c:/* 0xaaaaaaaaaaaaaaabLL, transferred to > fixedpterm[] */ > arch/x86/math-emu/poly_sin.c: 0xaaaaaaaaaaaaaaabLL, > arch/x86/math-emu/poly_tan.c:static const unsigned long long twothirds = > 0xaaaaaaaaaaaaaaabLL; > > In particular, in the last file (poly_tan.c) contains a snippet like > > mul64_Xsig(&accum, &twothirds); > > which seems vagely related to > > 0000001C 48BEABAAAAAAAAAA mov rsi,0xaaaaaaaaaaaaaaab > -AAAA > ... > 0000003B 48F7E6 mul rsi > > Now this does not seem connected to PCLMULQDQ, but it does somehow look > connected to multiplication. > > I don't really know where to go with this, except for asking KVM experts. > > For now, can you try: > > export LIBGUESTFS_BACKEND_SETTINGS=force_tcg > > from <https://libguestfs.org/guestfs.3.html#backend-settings>, and see > if that makes a difference? > > Laszlo > >
cpuinfo.out
Description: Binary data
libguestfs-test-tool.out
Description: Binary data
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://listman.redhat.com/mailman/listinfo/libguestfs
