Hi All
We have some significant updates on the use cases and interest in the
virtio interfaces from a mobile perspective. Further insight helping us
gather information and thus do the most relevant work appreciated.
https://collaborate.linaro.org/display/STR/Virtio+Interfaces
--
Mike Holmes | Director, Foundation Technologies, Linaro
Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org>
"Work should be fun and collaborative, the rest follows"
Hi all,
I would like to suggest having the Stratos meetings again at 8AM
California time / 4PM UK time to make it easier for people on the West
Coast to participate. (So far, we have been meeting mostly at 8AM,
except for a couple of occurrences.)
Thanks for your help! :-)
Cheers,
Stefano
Hi,
I've uploaded a couple of variants of the AGL demo to compare KVM vs Xen
Dom0. You can find them on the Linaro fileserver via:
https://fileserver.linaro.org/s/wC9AT25Erd5S2Eq
They are:
1. agl-arm64-kvm-virtio-gpu-2020-11-10_11.11.55.mkv
Recorded on my MachiatoBin machine with KVM enabled. Using entirely
stock AGL Jellyfish images.
2. agl-arm64-xen-dom0-virtio-gpu-2020-11-10_11.19.57.mkv
Recorded on my developer machine running under QEMU TCG emulation
(hence the slowness). The run uses the stock AGL kernel which is why
you don't see the messages from the Dom0 kernel console.
3. agl-arm64-xen-dom0-virtio-gpu-custom-kernel-2020-11-10_11.25.44.mkv
Same as above, but this time running a stock 5.9 stable kernel which I
did a "make olddefconfig" and then enabled the Xen paravirtualised
console (which is why you can see the kernel messages on boot up). You
can see some services fail to start on boot-up but I suspect those are
just timeouts due to the slowness of emulation. You can ssh into it
once it's up.
As I've mentioned before Dom0 isn't nearly as impressive as running as a
DomU image which is still the main goal. That said it certainly shows
the image doesn't really care which hypervisor it's being run under.
--
Alex Bennée
Hi All
We have an interesting call this week with input from Huawei, Windriver and
a discussion on the use of Greybus to solve the i2c, SPI and GPIO
virtualization cases.
- Salil Mehta - discussion on Huawei's interest in the Stratos project
- Dan Milea, Josh Pincus - OpenAMP App-services topics from WindRiver
- A couple of slides on Immediate goals, some research, some results,
and then immediate next steps
- Notes from recent presentations here
https://github.com/OpenAMP/open-amp/wiki/OpenAMP-Application-Services-Subgr…
- Viresh, Alex Elder, Bill Mills Greybus as a solution for I2C, SPI
and GPIO
------
Project Stratos Sync
Home page: https://collaborate.linaro.org/display/STR/Stratos+Home
<https://collaborate.linaro.org/display/STR/Stratos+Home>
Virtual meeting: meet.google.com/uak-yrcj-tyd
Thursday, 12 November⋅3:00 – 4:00 pm GMT
Every 2 weeks on Thursday
Mike
--
Mike Holmes | Director, Foundation Technologies, Linaro
Mike.Holmes(a)linaro.org <mike.holmes(a)linaro.org>
"Work should be fun and collaborative, the rest follows"
Hi Alex,
Thank you for doing this. I am looking forward to STR-20, I have been
wanting a clean-up in that area for years. Also STR-19 is well worded
and looks mostly fine. I only have a comment on the last statement:
> QEMU should also be able to act as the stub setup to pass IOREQ events
> to a separate vhost-user daemon as a stepping stone to a future Xen
> aware vhost-user stub program.
Xen can actually have multiple IOREQ servers running for the same
domain. Given that the code for receiving IOREQs is minimal and easily
portable, it would be better to make any other daemon a proper IOREQ
server talking to Xen directly, rather than having to go via QEMU. The
architecture would look cleaner and would lead to far better
performance, removing a step in the hot path. In other words I think the
vhost-user daemon should be run as its own IOREQ server.
On Wed, 4 Nov 2020, Alex Bennée via Stratos-dev wrote:
> Hi Stefano,
>
> I've re-written STR-19 (https://projects.linaro.org/browse/STR-19) now I
> have a hopefully better understanding of the relationship between IOREQ
> backends and how QEMU is launched with Xen. I see this approach as a
> stop-gap for testing additional virtio devices. Eventually we need to
> specify a new card for a Xen aware vhost-user launching stub that will
> link our hypervisor agnostic user-space daemons to the Xen specific
> virtio instance. I think we can hold off on that until we have a better
> idea of the sort of interface Xen and other type-1's need to provide for
> them.
>
> I've also raised STR-20 (https://projects.linaro.org/browse/STR-20) to
> cover the work to fix up the current build and allow for using a leaner
> native qemu-system-aarch64 to be used instead of qemu-system-i386 and
> it's additional baggage. I have patches in train for that which I'll
> post soon.
>
> Could you have a look over both for any obvious snafus?
>
> --
> Alex Bennée
> --
> Stratos-dev mailing list
> Stratos-dev(a)op-lists.linaro.org
> https://op-lists.linaro.org/mailman/listinfo/stratos-dev
>
Hello,
I'm interested in the virtio-camera interface.
https://collaborate.linaro.org/display/STR/Virtio+Interfaces
Would it include video-cam input (e.g. V4L2) or still camera only?
Also, are there any ideas to virtualize image processing units?
It is possible to send the image to the other guest which processes the
image and gets back, but it may involve many copies. If virtio-camera
has such features, it will help to avoid copying so much.
(something like USB-UVC)
BTW, is it possible to expose USB-gadget functions via virtio? (virtio-usb?)
Thank you,
--
Masami Hiramatsu
Hi Stefano,
I've re-written STR-19 (https://projects.linaro.org/browse/STR-19) now I
have a hopefully better understanding of the relationship between IOREQ
backends and how QEMU is launched with Xen. I see this approach as a
stop-gap for testing additional virtio devices. Eventually we need to
specify a new card for a Xen aware vhost-user launching stub that will
link our hypervisor agnostic user-space daemons to the Xen specific
virtio instance. I think we can hold off on that until we have a better
idea of the sort of interface Xen and other type-1's need to provide for
them.
I've also raised STR-20 (https://projects.linaro.org/browse/STR-20) to
cover the work to fix up the current build and allow for using a leaner
native qemu-system-aarch64 to be used instead of qemu-system-i386 and
it's additional baggage. I have patches in train for that which I'll
post soon.
Could you have a look over both for any obvious snafus?
--
Alex Bennée
Hi,
I think I've mentioned them in other threads but to bring it all in one
place. Using the images from:
https://download.automotivelinux.org/AGL/release/jellyfish/10.0.0/qemuarm64…
You just need the kernel image and the
agl-demo-platform-crosssdk-qemuarm64.ext4 filesystem. The initrd is a
slimmed down rootfs in a RAM disk.
To run with a simple VGA-like frame buffer:
./aarch64-softmmu/qemu-system-aarch64 -cpu host -enable-kvm \
-smp 2 -machine type=virt -serial mon:stdio \
-netdev user,id=unet,hostfwd=tcp::2222-:22 \
-device virtio-net-device,netdev=unet,id=virt-net \
-drive id=disk0,file=agl-demo-platform-crosssdk-qemuarm64.ext4,if=none,format=raw \
-device virtio-blk-device,drive=disk0 \
-soundhw hda \
-device qemu-xhci \
-device usb-tablet \
-device usb-kbd \
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-pci,rng=rng0 \
-device virtio-serial-device \
-chardev null,id=virtcon
-device virtconsole,chardev=virtcon -m 4096 \
-kernel ~/images/agl/Image \
-append "console=ttyAMA0 root=/dev/vda" \
-display gtk,show-cursor=on \
-device VGA,edid=on,xmax=1024,ymax=768
Running with virtio-gpu should give a similar 2D frame buffer experience,
making the last two lines:
-display gtk,show-cursor=on \
-device virtio-gpu-pci
And finally enabling VirGL for accelerated pass-through you get:
-display gtk,show-cursor=on,gl-on \
-device virtio-gpu-pci,virgl=on
although obviously if your host ends up sending it to softpipe in the
end the results won't be as impressive. I've also replicated the config
(find it in /boot) and re-built my own kernel current stable kernel and
it worked fine.
--
Alex Bennée
