[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [VirtIO] Support for various devices in Xen
On 12/04/2024
11:35, Edgar E. Iglesias wrote:
On Fri, Apr 12, 2024 at 1:23 AM Stefano Stabellini <sstabellini@xxxxxxxxxx> 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. Hi Edgar, Stefano,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' ] 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |