On 12/04/2024 11:35, Edgar E. Iglesias wrote: > On Fri, Apr 12, 2024 at 1:23 AM Stefano Stabellini > <sstabell...@kernel.org> wrote: > > -Vikram +Edgar > > On Thu, 11 Apr 2024, Andrei Cherechesu wrote: >>> I've managed to successfully get a DomU up and running with the rootfs >>> based on virtio-blk. I'm running QEMU 8.2.1, Xen 4.18 + Vikram's downstream >>> patches, Linux 6.6.12-rt, built through yocto with some changes to >>> xen-tools and QEMU recipes. >>> >>> However, when also enabling PV networking through virtio-net, it seems that >>> DomU cannot successfully boot. The device model args passed by xen-tools >>> when invoking QEMU look exactly like what Vikram said they should. >>> >>> While executing `xl -v create ..` I can see some error regarding the device >>> model crashing: >>> >>> libxl: debug: libxl_exec.c:127:libxl_report_child_exitstatus: >>> domain 1 device model (dying as expected) [300] died due to fatal signal >>> Killed >>> >>> But the error is not fatal and the DomU spawn goes on, it boots but never >>> reaches prompt. It seems that kernel crashes silently at some point. >>> Though, the networking interface is present since udev tries to rename it >>> right before boot hangs: >>> >>> [ 4.376715] vif vif-0 enX0: renamed from eth1 >>> >>> Why would the QEMU DM process be killed, though? Invalid memory access? >>> >>> Here are the full logs for the "xl create" command [0] and for DomU's dmesg >>> [1]. >>> Any ideas as to why that might happen, some debugging insights, or maybe >>> some configuration details I could have overlooked? >>> >>> Thank you very much for your help once again. > Hi Andrei, > > I'll share some info about my setup: > I'm using: > > Xen upstream/master + virtio patches that Vikram shared > Commit 63f66058b5 on this repo/branch: > https://github.com/edgarigl/xen/tree/edgar/virtio-base > > QEMU 02e16ab9f4 upstream/master > Linux 09e5c48fea17 upstream/master (from March) > Yocto rootfs. > I had a look at your logs but I can't tell why it's failing on your side. > I've not tried using a virtio-blk as a rootfs on my side, perhaps related. > It would be useful to see a diff of your Xen tree compared to plain > 4.18 or whatever base you've got. > You probably don't have > https://github.com/edgarigl/xen/commit/63f66058b508180107963ea37217bc88d813df8f > but if that was the problem, I'd thought virtio wouldn't work at all > with your kernel it could also be related. > > My guest config looks like this: > name = "g0" > memory = 1024 > vcpus = 1 > kernel = "Image" > ramdisk = "core-image-minimal-qemuarm64.rootfs.cpio.gz" > extra = "root=/dev/ram0 console=ttyAMA0" > vif = [ 'model=virtio-net,type=ioemu,bridge=xenbr0' ] > disk = [ '/etc/xen/file.img,,xvda,backendtype=qdisk,specification=virtio' ] Hi Edgar, Stefano,
Thank you for your support. Just wanted to let you know that I've managed to run everything just fine. After some more debugging, I figured the fix I needed was actually in QEMU, one which had been already merged upstream (available in v9.0.0) by Peng Fan [0], following a discussion a few months ago on this list. And since I'm running v8.2.1, my QEMU did not have it. So I can confirm granting DomU access to rootfs from an SDCard partition over virtio-blk also works. However, if I use the usual Xen PV drivers for block + virtio-net, it does not work (device model fails to spawn). But if I'm using virtio-blk + Xen PV Net, it works :). Also both VirtIOs at the same time work. This is the configuration: vif = [ 'model=virtio-net,type=ioemu' ] disk = [ 'phy:/dev/mmcblk0p3,xvda,backendtype=qdisk,specification=virtio' ] extra = "root=/dev/vda ..." Also tested them with foreign mappings and with grant based transports. Are there any other virtio device types you managed to test so far besides these ones (over virtio-mmio/virtio-grant)? Has anyone tested the rust-vmm vhost-device backends from Viresh with Xen? Regards, Andrei C [0] https://github.com/qemu/qemu/commit/9253d83062268209533df4b29859e5b51a2dc324 > > xl launches QEMU with the following args: > /usr/bin/qemu-system-aarch64 -xen-domid 1 -no-shutdown -chardev > socket,id=libxl-cmd,path=/var/run/xen/qmp-libxl-1,server=on,wait=off > -mon chardev=libxl-cmd,mode=control -chardev > socket,id=libxenstat-cmd,path=/var/run/xen/qmp-libxenstat-1,server=on,wait=off > -mon chardev=libxenstat-cmd,mode=control -nodefaults -no-user-config > -xen-attach -name g0 -vnc none -display none -nographic -global > virtio-mmio.force-legacy=false -device > virtio-net-device,id=nic0,netdev=net0,mac=00:16:3e:13:86:9c,iommu_platform=on > -netdev type=tap,id=net0,ifname=vif1.0-emu,br=xenbr0,script=no,downscript=no > -machine xenpvh -m 1024 -device > virtio-blk-device,drive=image,iommu_platform=on -drive > if=none,id=image,format=raw,file=/etc/xen/file.img -global > virtio-mmio.force-legacy=false > > Cheers, > Edgar > > >> Edgar (CCed) has recently setup a working system with QEMU and the >> xenpvh machine for ARM. He should be able to help you. >> >> Cheers, >> >> Stefano >> >>
