[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [VirtIO] Support for various devices in Xen


  • To: "Edgar E. Iglesias" <edgar.iglesias@xxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Andrei Cherechesu <andrei.cherechesu@xxxxxxxxxxx>
  • Date: Tue, 30 Apr 2024 03:11:13 +0300
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oss.nxp.com; dmarc=pass action=none header.from=oss.nxp.com; dkim=pass header.d=oss.nxp.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9YunsvWqqtQ5s6eFa057QKSD7Sa8jVj08zEQzNNlggk=; b=XStPd9raW1GE84JMbOTWGjIaUPWhUnsmESEhHk9qJya0PIW6NsA5jaqYulyDyeolmrJm+pU2/D0yqCPjJwSGreQO9DAXITZ5iDYq8B+7Xxfk9W0n1dRtaujZnsIbGDyXZGh8n7ReDFo7e/u5r4pu0VX7Z4exc2T9JIU03UH8dP2qAl2QO2CGZGUSE2zC8UyebXz8FJQ0VvX75smxtg8IRc3n4FOsE8EOuZ+whEfEMsg1uoeewePAAaqQThoXvzVrYLF8UC+/nK+AuPGBDld55Y60xIKZlZz+3jyEzboZ/34qhNUw1wR2jjNsj0FA2f4o5qoWL2PLKwZqc8mv/CJiRw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T2oicx69g3NndI4oBwZm9eoG6KnzJwoOrvDco+Pyjl2U83662zfOKx5Y/ojQdcx8c3evUWGBwzTTTfIO4TyxsAYQY+uVacWFv63pcCRc/+2zghDHs27drW9H8rJ3MtaVNY7eQY6063ffYabU9HkjxSQOmkZ880CPr3JnSatkKVQ/VX8HmwNQiVwcNqUiW4NBayndAhkoqr+lO3OJ0ZSMBJvLCGHT+UfzpOdl3sDKTF5iunNio3ySLOjEvkqhfAN7G19j7Giqyr4AyKZv2k+ggQv5BJoaJv7Yr3yecPeukKQswuBJSuy2NbdsGT32hngevGiYCfq0HHO8zjWfsUlaqQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=oss.nxp.com;
  • Cc: "viresh.kumar@xxxxxxxxxx" <viresh.kumar@xxxxxxxxxx>, "olekstysh@xxxxxxxxx" <olekstysh@xxxxxxxxx>, Julien Grall <julien@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrei Cherechesu <andrei.cherechesu@xxxxxxx>, Bertrand.Marquis@xxxxxxx, michal.orzel@xxxxxxx, Artem_Mygaiev@xxxxxxxx, Edgar.Iglesias@xxxxxxx
  • Delivery-date: Tue, 30 Apr 2024 00:12:24 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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.
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



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.