Hi Peng, Please see my comments below. On Wed, Jan 03, 2024 at 05:38:07AM +0000, Peng Fan wrote: > Hi Vikram, Oleksii > > I follow the slide virtio for Xen on ARM[1], but I met some issues, and > stuck for about two days. > > I use upstream lastest qemu repo master branch, not qemu-xen.git > repo. This is right. > > My start command as below[2], but seems I need first `xl create domu.cfg`, > otherwise it will fail, because xen hypervisor > dm_op->rcu_lock_remote_domain_by_id will return failure if domu > not created. My domu cfg is simple: > kernel = "/run/media/boot-mmcblk1p1/Image" > disk = [ '/etc/xen/disk_1.img,,xvda,specification=virtio' ] > cmdline = "console=hvc0 root=/dev/xvda rw" > name = "DomU" > memory = 512 > serial = "pty" > > I drop qdisk in the disk entry, because xen tool report qdisk and virtio > not compatible. > > And the arg xen_domid should be same as domu domain id? Is > there any dynamic way to set xen_domid, start qemu when start > domu? Yes, it should be xen_domid. Below virtio-disk patches will take care of invoking QEMU with right domid. > > Does the domu dts still needed to include the virtio,mmio node? > > however xl create domu.cfg relies virtio disk ready, which needs qemu > start first. This confuses me. How do you address this > or I do something wrong? > > Then after xl create, I quickly start qemu, but met: > failed to create ioreq server, then I see there is mismatch. > qemu use HVM_IOREQSRV_BUFIOREQ_ATOMIC to create ioreq server, > but xen ioreq_server_create will return failure: > if ( !IS_ENABLED(CONFIG_X86) && bufioreq_handling ) > > return -EINVAL; > There is a downstream patch for this: https://github.com/Xilinx/xen/commit/be35b46e907c7c78fd23888d837475eb28334638
> So I change HVM_IOREQSRV_BUFIOREQ_OFF in qemu, but met: > qemu-system-aarch64: failed to map ioreq server resources: error 2 > handle=0xaaaad26c7f30 > qemu-system-aarch64: xen hardware virtual machine initialisation failed > > Do you have out of box repo that works well? Including Qemu and Xen, > I am trying virtio disk, but will move to test virtio gpu soon. > > I am not sure there are some downstream patches in your side to > address and make it work well. > We have a few downstream patches for xen-tools. For Virtio disk backend: https://github.com/Xilinx/xen/commit/947280803294bbb963f428423f679d074c60d632 For Virtio-net: https://github.com/Xilinx/xen/commit/32fcc702718591270e5c8928b7687d853249c882 For changing the machine name to Xenpvh(to align with QEMU changes): https://github.com/Xilinx/xen/commit/5f669949c9ffdb1947cb47038956b5fb8eeb072a With above 4 patches it should work for you. Please re-compile Xen and Xen-tools first and finally compile QEMU with this Xen. > Thanks for your help. > > Thanks, > Peng. > > [1]https://www.youtube.com/watch?v=boRQ8UHc760 > > [2]qemu-system-aarch64 -xen-domid 1 \ > -chardev socket,id=libxl-cmd,path=qmp-libxl-1,server=on,wait=off \ > -mon chardev=libxl-cmd,mode=control \ > -chardev socket,id=libxenstat-cmd,path=qmp-libxenstat-1,server=on,wait=off \ > -mon chardev=libxenstat-cmd,mode=control \ > -xen-attach -name guest0 -vnc none -display none -nographic \ > -machine xenpvh -m 513 &
