Hi Gurchetan
On Wed, Sep 6, 2023 at 5:22 AM Gurchetan Singh
<gurchetansingh@chromium.org> wrote:
>
>
>
> On Wed, Aug 30, 2023 at 7:26 PM Huang Rui <ray.huang@amd.com> wrote:
>>
>> On Tue, Aug 29, 2023 at 08:36:20AM +0800, Gurchetan Singh wrote:
>> > From: Gurchetan Singh <gurchetansingh@google.com>
>> >
>> > Changes since v12:
>> > - Added r-b tags from Antonio Caggiano and Akihiko Odaki
>> > - Removed review version from commit messages
>> > - I think we're good to merge since we've had multiple people test and review this series??
>> >
>> > How to build both rutabaga and gfxstream guest/host libs:
>> >
>> > https://crosvm.dev/book/appendix/rutabaga_gfx.html
>> >
>> > Branch containing this patch series:
>> >
>> > https://gitlab.com/gurchetansingh/qemu/-/commits/qemu-gfxstream-v13
>> >
>> > Antonio Caggiano (2):
>> > virtio-gpu: CONTEXT_INIT feature
>> > virtio-gpu: blob prep
>> >
>> > Dr. David Alan Gilbert (1):
>> > virtio: Add shared memory capability
>> >
>> > Gerd Hoffmann (1):
>> > virtio-gpu: hostmem
>>
>> Patch 1 -> 4 are
>>
>> Acked-and-Tested-by: Huang Rui <ray.huang@amd.com>
>
>
> Thanks Ray, I've rebased https://gitlab.com/gurchetansingh/qemu/-/commits/qemu-gfxstream-v13 and added the additional acks in the commit message.
>
> UI/gfx maintainers, since everything is reviewed and there hasn't been any additional review comments, may we merge the gfxstream + rutabaga_gfx series? Thank you!
>
>
Packaging aemu and gfxstream is a bit problematic. I have some WIP
Fedora packages.
AEMU:
- installs files under /usr/include/host-common and
/usr/include/snapshot. Can this be moved under /usr/include/aemu
instead?
- builds only static versions of libaemu-host-common.a and
liblogging-base.a (distros don't like static libs much)
- could liblogging-base(.a,.so,..) also have "aemu" name in it?
- libaemu-base.so is not versioned
- I can't find a release tarball, nor the (v0.1.2) release tag
- could have a README file
I am not very familiar with cmake, so it's not obvious how to make the
required changes. Would you like me to open an issue (where?) or try
to make some patches?
I filed an internal bug with all the issues you listed: Android side should fix this internally.
I see a few options for packaging:
1) Punt on gfxstream/AEMU packaging, just do rutabaga
gfxstream is mostly useful for Android guests, and I didn't expect anyone to actually package it at this point since most here are interested in Linux guests (where gfxstream VK is headless only right now). Plus ioctl-fowarding > API forwarding for security and performance, so I'm not sure if it'll have any sticking power even if everything is supported (outside of a few niche use cases).
Though, I sense interest in Wayland passthrough for dual Linux use cases. I put up:
that'll allow packaging on rutabaga_gfx and even CI testing without gfxstream, since it is designed to function without it. We could issue another rutabaga-release tag, or you can simply add a patch (a common packaging practice) on the Fedora package with the "UPSTEAM label".
2) Actually package gfxstream only
Probably an intermediate solution that doesn't introduce versioning/static library issues would be just to have a copy of AEMU in the gfxstream repo, and link it statically. Will need another release tag/commit of gfxstream.
3) Don't package at all
For my particular use case since we have to build QEMU for sources, this is fine. If upstream breaks virtio-gpu-rutabaga.c, we'll send a patch and fix it. Being in-tree is most important.
Let me know what you prefer!
gfxstream:
- libgfxtream_backend.so is not versioned
- I can't find a release tarball, nor the (v0.1.2) release tag
(packaging is important so we can build the new code in CI too!)
thanks
--
Marc-André Lureau