Back to Home / #xen / 2022 / 04 / Prev Day | Next Day
#xen IRC Logs for 2022-04-22

---Logopened Fri Apr 22 00:00:47 2022
02:18-!-jgross_ is now known as jgross
03:25<mjt>andyhhp: so on arm, qemu-system-i386 is not used for actual domUs, only on x86, right? And generally, the pre-spawned qemu is actually not used except of the cases where one has qcow domU images (which is, I guess, rare)?
04:04<gwd>mjt: To be precise: 1) it's not (yet) used for emulation (although this may change)
04:04<gwd>2) It's only spawned as a disk backend when the backendtype is set to "qdisk"
04:05<gwd>This is the default when using qcow or vhd I believe. But you could manually set it to qdisk even for other types.
04:08<mjt>I'm not a xen guy. I know right to nothing about xen, - I come here "from" qemu side. In debian we found it is a bit difficult to have xen depending on full-blown qemu-system-i386 which pulls in whole GUI stack, and it is difficult for regular qemu to pull whole xen
04:09<mjt>so I'm trying to understand what's needed by xen on the qemu side
04:10<mjt>for the 2) I see a different picture: qemu-system-i386 is spawned at boot just if it exists, by xen-utils-4.16's initscript
04:10<mjt>if [ -x $QEMU ]; then $QEMU $QEMU_ARGS; fi
04:11<mjt>qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor none -serial none -parallel none
04:11<gwd>OK -- I *think* that's to help dom0 mount guest disks which may qcow2 / vhd encoded
04:12<gwd>royger may be able to give a more confident answer ^
04:12<mjt>that's I thought too from andyhhp answer
04:12<royger>yes, that's for pygrub. If the disk is not directly accessible dom0 will local-attach it as a xvd* in order to run pygrbu against it
04:13<royger>ie: not directly accessible == not in raw format
04:13<mjt>tho it was a surprize for me to know xen can work with qcow files :)
04:13<royger>it should handle any format that qemu can handle
04:13<royger>qcow, vhd, qcow2
04:14<mjt>can't it use something like qemu-nbd for that? just curious, I understand it is the way it is for quite some time
04:14<gwd>We heavily depend on QEMU, no reason not to use functionality that's there. :_)
04:14<mjt>heh
04:14<mjt>now *that* is interesting
04:14<mjt>so far I heard xen depending on qemu less and less, just for some rare corner cases
04:15<mjt>that's why f.e. debian xen package does not depend on qemu, but only recommends it
04:15<gwd>I mean historically we have depended on QEMU.
04:16<royger>we have new modes (like PVH) that don't depend on QEMU emulated devices, but use QEMU as a backed for some PV devices
04:16<royger>in this case, disk devices that use non-raw formats
04:16<mjt>now I wonder. Should I build qemu-system-i386 for arm, or should it be qemu-system-arm instead?
04:17<mjt>(for block devices it doesn't matter)
04:17<royger>AFAICT it doesn't matter as long as it has the Xen PV backends. none of the emulation there will be used on Arm
04:18<gwd>As long as the toolstack is able to start up the binary appropriately
04:18<mjt>I refer to the first answer by gwd here, the 1) it's not (yet) used for emulation (although this may change)
04:18<gwd>(i.e., it knows the path / binary name / arguments)
04:19<gwd>I don't work on the ARM side, but my understanding was that they were working on getting QEMU emulation on ARM working. It may be a few release down the line.
04:19<gwd>(And of course I may have misunderstood / the plan may have chanded.)
04:19<gwd>*changed
04:19<mjt>ok. We'll be able to adopt too when this happens
04:20<mjt>when xen encounters a non-raw disk image, does it just fail if qemu isn't running? where's this place? I'd love to include something like "please install qemu-system-xen for this to work" message in there
04:20<mjt>(and it'd be interesting to know how often people use qemu in this context)
04:22<mjt>Please excuse me for these stupid questions. I never run xen before :))
04:22<gwd>No, they're not stupid at all -- unfortunately there's a lot of complexity which we do our best to hide, but can't help poke through the wallpaper pretty quickly
04:23<gwd>PV / PVH guests (and ARM could be considered the latter) don't have a built-in BIOS
04:23<mjt>heh. qemu can't build qemu-system-i386 without emulation (tcg) AND without native kvm support. For arm neither of these are useful :)
04:24<gwd>So the question is how the kernel gets loaded.
04:25<gwd>You can use pvgrub, which runs inside the guest, but that's more complicated to build (and on x86 you have to know ahead of time whether you're going to boot a 32-bit or 64-bit kernel)
04:25<mjt>in debian we have: Suggests: qemu-utils [amd64], seabios [amd64], ovmf
04:25<mjt>which is *suggests*, which is even lower than recommends
04:25<gwd>Right, seabios has been the default for HVM guests
04:26<gwd>OVMF is another option, but I don't think it has feature parity yet.
04:26<mjt>(and recommends: grub-xen-host [amd64])
04:26<gwd>Oh, maybe grub-xen-host is pvgrub?
04:27<gwd>The admin can manually specify a kernel / initrd, but that's a pain, because you can't just "apt-get update" from within the guest and get a new kernel
04:27<mjt>grub-xen-host: This package arranges for GRUB binary images which can be used to boot a Xen guest (i.e. PV-GRUB) to be present in the control domain filesystem.
04:27<gwd>So pygrub, which runs in dom0 and fishes the kernel out of the guest image, is the simplest thing to do
04:27<gwd>grub-xen-host> OK, good
04:27<jgross>pygrub is deprecated due to security reasons
04:28<gwd>security> Indeed it is; but it's still the most convenient.
04:29<gwd>jgross: Do you know what the default PVH boot path is now? If OVMF is sufficient maybe we should try to make that the default.
04:29<jgross>Then there is pvgrub based on legacy grub and Mini-OS, which is deprectaed,too.
04:30<jgross>And grub-pv, which is upstream grub2 configured for Xen PV guest support
04:30<gwd>Actually, grub-pv in PV should be able to handle both 32 and 64-bit kernels, right?
04:30<jgross>gwd: the most convenient way is to use grub-pvh
04:31<jgross>No, grub-pv exists in two flavors, one for 32- and one for 64-bit mode
04:31<jgross>Same as pvgrub
04:31<gwd>Sorry, mis-typed; I meant grub in PVH.
04:31<jgross>Yes, grub-pvh handles both kernel flavors
04:32<gwd>OK, so in short, the Debian dependency recommendations are correct
04:32<gwd>People should be encouraged to use PVH guests (on ARM or x86) and use grub-pvh.
04:33<gwd>If you want to use qcow* / vhd files, you need some form of QEMU.
04:33<jgross>Same for pvusb
04:33<gwd>If you try to create a guest w/ a qcow2 disk on a system w/o QEMU, the toolstack will fail; I'm not sure how useful the error message will be.
04:34<mjt>i'm interested to find it out :)
04:34<mjt>Knorrie: can you try it on your testground? :)
04:36<jgross>I think it will tell you the device model couldn't be spawned.
04:37<mjt>we're moving things around a bit in debian and I don't let people to face a failure without any hint about how to resolve it
04:37<gwd>...whereas, ideally it would say, "Please install qemu-system-i386" or something.
04:37<mjt>don't want to let*
04:38<jgross>I think it would be rather beneficial to split backend and platform emulation for Xen. So one qemu for HVM guests doing the platform emulation, and another one acting as the backend. Basically a similar approach like a HVM domain with ioemu-stubdom.
04:39<jgross>PVH and PV guests would require only the backend variant, and this could be arch agnostic and be used on Arm, too
04:43<mjt>hmm. The docs, everywhere, refer to qemu(1) manpage for details.. but there's no such manpage.. :(
04:44<mjt>I guess it was done long time ago when qemu was providing system emulation only. This thing (qemu(1) manpage) does not exist since qemu started providing user emulation too
04:44<gwd>The Xen docs?
04:44<mjt>yes
04:44<jgross>mjt: on openSUSE the man page is there.
04:45<mjt>it is qemu-system and qemu-user, two *entirely* different beasts. I'd rather not provide qemu(1) because of this confusion
04:45<mjt>but that's minor thing for sure
04:46<gwd>IN a number of cases we just pass guest config strings directly to QEMU; so using QEMU's docs is the best way to keep things accurate
04:46<gwd>If you can recommend alternate wording, I'm sure it's an easy change to make. :-)
04:46<mjt>that's entirely okay. I'm commenting about *which* manpage to refer to :)
04:47<gwd>IF Debian is renaming the QEMU man pages, they should probably be carrying a patch to maintain appropriate references as well. :-)
04:48<gwd>Although it looks like 4 of the 5 references are about a single topic (keymaps)
04:48<jgross>On openSUSE the qemu man-page seems to refer to qemu-system
04:49<mjt>that's still a very minor thing. Yes it turns out it is me who renames qemu.1 in debian, and the comment there says to bring this upstream :)
04:51<mjt>I wonder how many years this comment is there.. a bit less than 10 it looks like :)
04:51<mjt>so.. n/m :)
04:52<gwd>Haha -- there's a comment in the Xen code I wrote in 2006 that says, "When we implement shadow superpages, we'll have to..."
04:52<gwd>We stil haven't implemented shadow superpages...
04:53<mjt>I bet the name for the manpage is a bit easier ;))
06:11<Knorrie>in Debian, we have all the PV/PVH grub conveniently packaged, so I really am looking to try ship next Debian release without pygrub (but, it will need some work, mostly to provide proper documentation and reach out to users to make them change something :) )
06:47-!-inisider [~inisider@176.120.99.237] has joined #xen
06:47-!-inisider is "realname" on #xen #kernelnewbies
06:52<inisider>Hello. I would like to understand how can i debug xenmem_reservation_increase()? The problem is that xenmem_reservation_increase() function returns number of pages not equal to number of pages there were passed as function argument.
07:01<mjt>ok. qemu-system-i386 can't be built on arm without tcg, it says "no accelerator available"
07:01<mjt>so I guess it should be qemu-system-arm not qemu-system-i386
09:12-!-Tonux_ [~Tonux@185.195.232.155] has joined #xen
09:12-!-Tonux_ is "Tonux" on #xen #kernelnewbies #oftc #fdroid
09:12-!-Tonux [~Tonux@0002ad88.user.oftc.net] has quit [Ping timeout: 480 seconds]
09:12<mjt>..and it turned out qemu can not be built with xen support on non-x86 to start with, so it does not understand -xen-woodoo options on arm, so it can't be started at boot to handle qdisks (I assume it is the right term to refer to qemu-based didks in xen)
09:21<andyhhp>23:21 < andyhhp> and it's qemu-system-i386 because of how intertwined the Xen support is with i386 in Qemu
09:21<andyhhp>yes, it's a bug/misfeature in qemu
09:22<andyhhp>which noone has addressed
09:23<andyhhp>it would be fantastic if someone could find the time to fix this
09:47-!-ccw [~ccw@0002a6fe.user.oftc.net] has quit [Quit: ZNC - https://znc.in]
09:48-!-ccw [~ccw@97-122-67-169.hlrn.qwest.net] has joined #xen
09:48-!-ccw is "Cheyenne Wills" on #xen
09:59-!-zkrx [~slimshady@adsl-89-217-230-95.adslplus.ch] has quit [Quit: zkrx]
12:04-!-XCPngXOTeam [~XCPngXOTe@2a01:240:ab08::2] has quit [Remote host closed the connection]
12:04-!-XCPngXOTeam [~XCPngXOTe@2a01:240:ab08::2] has joined #xen
12:04-!-XCPngXOTeam is "XCPngXOTeam" on #xen #xen-orchestra #xsxoteams #xcp-ng #xensummit #xendevel
14:56-!-inisider [~inisider@176.120.99.237] has quit [Remote host closed the connection]
15:12-!-overholts [~overholts@192.18.128.79] has quit [Quit: overholts]
15:13-!-overholts [~overholts@192.18.128.79] has joined #xen
15:13-!-overholts is "overholts" on #xen #xcp-ng
17:03-!-Tonux_ [~Tonux@185.195.232.155] has quit [Remote host closed the connection]
17:04-!-Tonux [~Tonux@185.195.232.155] has joined #xen
17:04-!-Tonux is "Tonux" on #xen #kernelnewbies #oftc #fdroid
22:21-!-jgross_ [~juergen_g@2a01:41e1:2d03:bf00:e4e5:bb7d:51d3:f10d] has joined #xen
22:21-!-jgross_ is "realname" on #xen
22:27-!-jgross [~juergen_g@2a01:41e1:2cd2:d500:a6ef:e08b:dce2:ee24] has quit [Ping timeout: 480 seconds]
---Logclosed Sat Apr 23 00:00:49 2022