|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [VirtIO] Support for various devices in Xen
Hi Stefano, Vikram, Viresh, Thank you for your answers and support, and sorry for my late reply. On 12/01/2024 02:56, Vikram Garhwal wrote: > Hi Andrei & Stefano, > > Actually, QEMU patches are already upstreamed for virtio-blk and virtio-net > devices available in v8.2.0. > For virtio with grants, the patches are WiP. > > On Xen side, we are yet to upstream xen-tools patches which basically generate > the right arguments when invoking QEMU. > Here are down stream patches if you want: > 1. > https://github.com/Xilinx/xen/commit/be35b46e907c7c78fd23888d837475eb28334638 > 2. For Virtio disk backend: > > https://github.com/Xilinx/xen/commit/947280803294bbb963f428423f679d074c60d632 > 3. For Virtio-net: > > https://github.com/Xilinx/xen/commit/32fcc702718591270e5c8928b7687d853249c882 > 4. For changing the machine name to Xenpvh(to align with QEMU changes): > > https://github.com/Xilinx/xen/commit/5f669949c9ffdb1947cb47038956b5fb8eeb072a >> The libxl changes are lagging behind a bit and you might have to use >> device_model_args to enable virtio backends in QEMU. > But QEMU 8.2.0 can still be used for virtio-net on ARM. > > @Andrei here is an example on how to use virtio-net with QEMU: > -device virtio-net-device,id=nic0,netdev=net0,mac=00:16:3e:4f:43:05 \ > -netdev > type=tap,id=net0,ifname=vif1.0-emu,br=xenbr0,script=no,downscript=no\ > -machine xenpvh > > Please make sure to use xenpvh as QEMU machine. > > Regards, > Vikram 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. Regards, Andrei Cherechesu [0] https://privatebin.net/?0fc1db27433dbcb5#4twCBMayizr7x89pxPzNqQ198z92q8YxVheHvNDsVAtd [1] https://privatebin.net/?ec3cb13fe2a086a1#F1zynLYQJCUDfZiwikZtRBEPJTACR2GZX6jn2ShXxmae >> For SCMI, I'll let Bertrand (CCed) comment. >> >> Cheers, >> >> Stefano >> >> >> On Thu, 11 Jan 2024, Andrei Cherechesu (OSS) wrote: >>> Hello, >>> >>> As I've mentioned in previous discussion threads in the xen-devel >>> community, we are running Xen 4.17 (uprev to 4.18 in progress) on NXP >>> S32G automotive processors (Cortex-A53 cores) and we wanted to know more >>> about the support for various VirtIO device types in Xen. >>> >>> In the Xen 4.17 release notes, the VirtIO standalone backends mentioned >>> as supported and tested are: virtio-disk, virtio-net, virtio-i2c and >>> virtio-gpio. >>> >>> However, we've only managed to successfully set up and try some >>> use-cases with the virtio-disk standalone backend [0] (which Olexandr >>> provided) based on the virtio-mmio transport. >>> >>> As such, we have a few questions, which we haven't been able to figure >>> out from the mailing list discussions and/or code: >>> 1. Are there any plans for the virtio-disk repo to have a stable >>> version? Is it going to be long-term hosted and maintained in the >>> xen-troops github repo? Or was it just an one-time PoC implementation >>> >>> and the strategy for future VirtIO devices will be based on a more >>> generic >>> >>> approach (i.e., without need for a specific standalone app)? >>> >>> >>> 2. With regards to the other backends, we want to try out and provide PV >>> >>> networking to a DomU based on virtio-net, but we haven't found any >>> available >>> >>> resources for it (e.g., the standalone backend implementation if needed >>> for >>> >>> control plane, configuration examples, presentations, demos, docs). >>> Does it >>> >>> rely on the QEMU virtio-net or vhost implementation? Are there any >>> examples >>> >>> on how to set it up? Any required Xen/Linux Kernel/QEMU versions? >>> >>> >>> 3. What other VirtIO device types are there planned to be supported in >>> Xen? >>> >>> I'm supposing libxl will also need changes to accomodate new >>> configuration >>> >>> parameters for each of them. Or is there something I'm missing? >>> >>> >>> 4. Also, while we're at it, are there any plans regarding SCMI >>> awareness for Xen (e.g., SCMI Mediator - where the RFC thread from 2022 >>> >>> seems discontinued)? Or is the preferred approach for sharing SCMI >>> access >>> >>> to guests through virtio-scmi? >>> >>> Thank you very much for the support, once again, and we're also looking >>> forward to the progress on the rust-vmm initiative. >>> >>> Regards, >>> Andrei Cherechesu, >>> NXP Semiconductors >>> >>> [0] https://github.com/xen-troops/virtio-disk >>> >>> >>>
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |