| Message ID | 20230823012541.485-1-gurchetansingh@chromium.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | rutabaga_gfx + gfxstream | expand |
Gurchetan Singh <gurchetansingh@chromium.org> writes: > - Official "release commits" issued for rutabaga_gfx_ffi, > gfxstream, aemu-base. For example, see crrev.com/c/4778941 > > - The release commits can make packaging easier, though once > again all known users will likely just build from sources > anyways It's a small thing, but could there be actual tags, rather than just blessed commits? It'd just make them easier to find, and save a bit of time in review for packages.
On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross <hi@alyssa.is> wrote: > Gurchetan Singh <gurchetansingh@chromium.org> writes: > > > - Official "release commits" issued for rutabaga_gfx_ffi, > > gfxstream, aemu-base. For example, see crrev.com/c/4778941 > > > > - The release commits can make packaging easier, though once > > again all known users will likely just build from sources > > anyways > > It's a small thing, but could there be actual tags, rather than just > blessed commits? It'd just make them easier to find, and save a bit of > time in review for packages. > I added: https://crosvm.dev/book/appendix/rutabaga_gfx.html#latest-releases-for-potential-packaging Tags are possible, but I want to clarify the use case before packaging. Where are you thinking of packaging it for (Debian??)? Are you mostly interested in Wayland passthrough (my guess) or gfxstream too? Depending your use case, we may be able to minimize the work involved.
Gurchetan Singh <gurchetansingh@chromium.org> writes: > On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross <hi@alyssa.is> wrote: > >> Gurchetan Singh <gurchetansingh@chromium.org> writes: >> >> > - Official "release commits" issued for rutabaga_gfx_ffi, >> > gfxstream, aemu-base. For example, see crrev.com/c/4778941 >> > >> > - The release commits can make packaging easier, though once >> > again all known users will likely just build from sources >> > anyways >> >> It's a small thing, but could there be actual tags, rather than just >> blessed commits? It'd just make them easier to find, and save a bit of >> time in review for packages. >> > > I added: > > https://crosvm.dev/book/appendix/rutabaga_gfx.html#latest-releases-for-potential-packaging > > Tags are possible, but I want to clarify the use case before packaging. > Where are you thinking of packaging it for (Debian??)? Are you mostly > interested in Wayland passthrough (my guess) or gfxstream too? Depending > your use case, we may be able to minimize the work involved. Packaging for Nixpkgs (where I already maintain what to my knowledge is the only crosvm distro package). I'm personally mostly interested in Wayland passthroug, but I wouldn't be surprised if others are interested in gfxstream. The packaging work is already done, I've just been holding off actually pushing the packages waiting for the stable releases. The reason that tags would be useful is that it allows a reviewer of the package to see at a glance that the package is built from a stable release. If it's just built from a commit hash, they have to go and verify that it's a stable release, which is mildly annoying and unconventional.
On Fri, Aug 25, 2023 at 12:11 AM Alyssa Ross <hi@alyssa.is> wrote: > Gurchetan Singh <gurchetansingh@chromium.org> writes: > > > On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross <hi@alyssa.is> wrote: > > > >> Gurchetan Singh <gurchetansingh@chromium.org> writes: > >> > >> > - Official "release commits" issued for rutabaga_gfx_ffi, > >> > gfxstream, aemu-base. For example, see crrev.com/c/4778941 > >> > > >> > - The release commits can make packaging easier, though once > >> > again all known users will likely just build from sources > >> > anyways > >> > >> It's a small thing, but could there be actual tags, rather than just > >> blessed commits? It'd just make them easier to find, and save a bit of > >> time in review for packages. > >> > > > > I added: > > > > > https://crosvm.dev/book/appendix/rutabaga_gfx.html#latest-releases-for-potential-packaging > > > > Tags are possible, but I want to clarify the use case before packaging. > > Where are you thinking of packaging it for (Debian??)? Are you mostly > > interested in Wayland passthrough (my guess) or gfxstream too? Depending > > your use case, we may be able to minimize the work involved. > > Packaging for Nixpkgs (where I already maintain what to my knowledge is > the only crosvm distro package). I'm personally mostly interested in > Wayland passthroug, but I wouldn't be surprised if others are interested > in gfxstream. The packaging work is already done, I've just been > holding off actually pushing the packages waiting for the stable > releases. > > The reason that tags would be useful is that it allows a reviewer of the > package to see at a glance that the package is built from a stable > release. If it's just built from a commit hash, they have to go and > verify that it's a stable release, which is mildly annoying and > unconventional. > Understood. Request to have gfxstream and AEMU v0.1.2 release tags made. For rutabaga_gfx_ffi, is the crates.io upload sufficient? https://crates.io/crates/rutabaga_gfx_ffi Debian, for example, treats crates.io as the source of truth and builds tooling around that. I wonder if Nixpkgs as similar tooling around crates.io.
Gurchetan Singh <gurchetansingh@chromium.org> writes: > On Fri, Aug 25, 2023 at 12:11 AM Alyssa Ross <hi@alyssa.is> wrote: > >> Gurchetan Singh <gurchetansingh@chromium.org> writes: >> >> > On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross <hi@alyssa.is> wrote: >> > >> >> Gurchetan Singh <gurchetansingh@chromium.org> writes: >> >> >> >> > - Official "release commits" issued for rutabaga_gfx_ffi, >> >> > gfxstream, aemu-base. For example, see crrev.com/c/4778941 >> >> > >> >> > - The release commits can make packaging easier, though once >> >> > again all known users will likely just build from sources >> >> > anyways >> >> >> >> It's a small thing, but could there be actual tags, rather than just >> >> blessed commits? It'd just make them easier to find, and save a bit of >> >> time in review for packages. >> >> >> > >> > I added: >> > >> > >> https://crosvm.dev/book/appendix/rutabaga_gfx.html#latest-releases-for-potential-packaging >> > >> > Tags are possible, but I want to clarify the use case before packaging. >> > Where are you thinking of packaging it for (Debian??)? Are you mostly >> > interested in Wayland passthrough (my guess) or gfxstream too? Depending >> > your use case, we may be able to minimize the work involved. >> >> Packaging for Nixpkgs (where I already maintain what to my knowledge is >> the only crosvm distro package). I'm personally mostly interested in >> Wayland passthroug, but I wouldn't be surprised if others are interested >> in gfxstream. The packaging work is already done, I've just been >> holding off actually pushing the packages waiting for the stable >> releases. >> >> The reason that tags would be useful is that it allows a reviewer of the >> package to see at a glance that the package is built from a stable >> release. If it's just built from a commit hash, they have to go and >> verify that it's a stable release, which is mildly annoying and >> unconventional. >> > > Understood. Request to have gfxstream and AEMU v0.1.2 release tags made. > > For rutabaga_gfx_ffi, is the crates.io upload sufficient? > > https://crates.io/crates/rutabaga_gfx_ffi > > Debian, for example, treats crates.io as the source of truth and builds > tooling around that. I wonder if Nixpkgs as similar tooling around > crates.io. We do, and I'll use the crates.io release for the package — good suggestion, but it's still useful to also have a tag in a git repo. It makes it easier if I need to do a bisect, for example. As a distro developer, I'm frequently jumping across codebases I am not very familiar with to try to track down regressions, etc., and it's much easier when I don't have to learn some special quirk of the package like not having git tags.
Alyssa Ross <hi@alyssa.is> writes: > Gurchetan Singh <gurchetansingh@chromium.org> writes: > >> On Fri, Aug 25, 2023 at 12:11 AM Alyssa Ross <hi@alyssa.is> wrote: >> >>> Gurchetan Singh <gurchetansingh@chromium.org> writes: >>> >>> > On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross <hi@alyssa.is> wrote: >>> > >>> >> Gurchetan Singh <gurchetansingh@chromium.org> writes: >>> >> >>> >> > - Official "release commits" issued for rutabaga_gfx_ffi, >>> >> > gfxstream, aemu-base. For example, see crrev.com/c/4778941 >>> >> > >>> >> > - The release commits can make packaging easier, though once >>> >> > again all known users will likely just build from sources >>> >> > anyways >>> >> >>> >> It's a small thing, but could there be actual tags, rather than just >>> >> blessed commits? It'd just make them easier to find, and save a bit of >>> >> time in review for packages. >>> >> >>> > >>> > I added: >>> > >>> > >>> https://crosvm.dev/book/appendix/rutabaga_gfx.html#latest-releases-for-potential-packaging >>> > >>> > Tags are possible, but I want to clarify the use case before packaging. >>> > Where are you thinking of packaging it for (Debian??)? Are you mostly >>> > interested in Wayland passthrough (my guess) or gfxstream too? Depending >>> > your use case, we may be able to minimize the work involved. >>> >>> Packaging for Nixpkgs (where I already maintain what to my knowledge is >>> the only crosvm distro package). I'm personally mostly interested in >>> Wayland passthroug, but I wouldn't be surprised if others are interested >>> in gfxstream. The packaging work is already done, I've just been >>> holding off actually pushing the packages waiting for the stable >>> releases. >>> >>> The reason that tags would be useful is that it allows a reviewer of the >>> package to see at a glance that the package is built from a stable >>> release. If it's just built from a commit hash, they have to go and >>> verify that it's a stable release, which is mildly annoying and >>> unconventional. >>> >> >> Understood. Request to have gfxstream and AEMU v0.1.2 release tags made. >> >> For rutabaga_gfx_ffi, is the crates.io upload sufficient? >> >> https://crates.io/crates/rutabaga_gfx_ffi >> >> Debian, for example, treats crates.io as the source of truth and builds >> tooling around that. I wonder if Nixpkgs as similar tooling around >> crates.io. > > We do, and I'll use the crates.io release for the package — good > suggestion, but it's still useful to also have a tag in a git repo. It > makes it easier if I need to do a bisect, for example. As a distro > developer, I'm frequently jumping across codebases I am not very > familiar with to try to track down regressions, etc., and it's much > easier when I don't have to learn some special quirk of the package like > not having git tags. Aha, trying to switch my package over to it has revealed that there is actually a reason not to use the crates.io release. It doesn't include a Cargo.lock, which would mean we'd have to obtain one from elsewhere. Either from the crosvm git repo, at which point we might just get all the sources from there, or by vendoring a Cargo.lock into our own git tree for packages, which we try to avoid because when you have a lot of them, they become quite a large proportion of the overall size of the repo. (This probably differs from Debian, etc., because in Nixpkgs, we don't package each crate dependency separately. We only have packages for applications (or occasionally, C ABI libraries written in Rust), and each of those gets to bring in whatever crate dependencies it wants as part of its build. This means we use the upstream Cargo.lock, and accept that different Rust packages will use lots of different versions of dependencies, which I don't believe is the case with other distros that take a more purist approach to Rust packaging.)
On Fri, Aug 25, 2023 at 12:37 PM Alyssa Ross <hi@alyssa.is> wrote: > Alyssa Ross <hi@alyssa.is> writes: > > > Gurchetan Singh <gurchetansingh@chromium.org> writes: > > > >> On Fri, Aug 25, 2023 at 12:11 AM Alyssa Ross <hi@alyssa.is> wrote: > >> > >>> Gurchetan Singh <gurchetansingh@chromium.org> writes: > >>> > >>> > On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross <hi@alyssa.is> wrote: > >>> > > >>> >> Gurchetan Singh <gurchetansingh@chromium.org> writes: > >>> >> > >>> >> > - Official "release commits" issued for rutabaga_gfx_ffi, > >>> >> > gfxstream, aemu-base. For example, see crrev.com/c/4778941 > >>> >> > > >>> >> > - The release commits can make packaging easier, though once > >>> >> > again all known users will likely just build from sources > >>> >> > anyways > >>> >> > >>> >> It's a small thing, but could there be actual tags, rather than just > >>> >> blessed commits? It'd just make them easier to find, and save a > bit of > >>> >> time in review for packages. > >>> >> > >>> > > >>> > I added: > >>> > > >>> > > >>> > https://crosvm.dev/book/appendix/rutabaga_gfx.html#latest-releases-for-potential-packaging > >>> > > >>> > Tags are possible, but I want to clarify the use case before > packaging. > >>> > Where are you thinking of packaging it for (Debian??)? Are you mostly > >>> > interested in Wayland passthrough (my guess) or gfxstream too? > Depending > >>> > your use case, we may be able to minimize the work involved. > >>> > >>> Packaging for Nixpkgs (where I already maintain what to my knowledge is > >>> the only crosvm distro package). I'm personally mostly interested in > >>> Wayland passthroug, but I wouldn't be surprised if others are > interested > >>> in gfxstream. The packaging work is already done, I've just been > >>> holding off actually pushing the packages waiting for the stable > >>> releases. > >>> > >>> The reason that tags would be useful is that it allows a reviewer of > the > >>> package to see at a glance that the package is built from a stable > >>> release. If it's just built from a commit hash, they have to go and > >>> verify that it's a stable release, which is mildly annoying and > >>> unconventional. > >>> > >> > >> Understood. Request to have gfxstream and AEMU v0.1.2 release tags > made. > >> > >> For rutabaga_gfx_ffi, is the crates.io upload sufficient? > >> > >> https://crates.io/crates/rutabaga_gfx_ffi > >> > >> Debian, for example, treats crates.io as the source of truth and builds > >> tooling around that. I wonder if Nixpkgs as similar tooling around > >> crates.io. > > > > We do, and I'll use the crates.io release for the package — good > > suggestion, but it's still useful to also have a tag in a git repo. It > > makes it easier if I need to do a bisect, for example. As a distro > > developer, I'm frequently jumping across codebases I am not very > > familiar with to try to track down regressions, etc., and it's much > > easier when I don't have to learn some special quirk of the package like > > not having git tags. > > Aha, trying to switch my package over to it has revealed that there is > actually a reason not to use the crates.io release. It doesn't include > a Cargo.lock, which would mean we'd have to obtain one from elsewhere. > Either from the crosvm git repo, at which point we might just get all > the sources from there, or by vendoring a Cargo.lock into our own git > tree for packages, which we try to avoid because when you have a lot of > them, they become quite a large proportion of the overall size of the > repo. > Ack. Request to have a rutabaga release tag in crosvm also made, should be complete in a few days. > > (This probably differs from Debian, etc., because in Nixpkgs, we don't > package each crate dependency separately. We only have packages for > applications (or occasionally, C ABI libraries written in Rust), and > each of those gets to bring in whatever crate dependencies it wants as > part of its build. This means we use the upstream Cargo.lock, and > accept that different Rust packages will use lots of different versions > of dependencies, which I don't believe is the case with other distros > that take a more purist approach to Rust packaging.) >
Gurchetan Singh <gurchetansingh@chromium.org> writes: > On Fri, Aug 25, 2023 at 12:37 PM Alyssa Ross <hi@alyssa.is> wrote: > >> Alyssa Ross <hi@alyssa.is> writes: >> >> > Gurchetan Singh <gurchetansingh@chromium.org> writes: >> > >> >> On Fri, Aug 25, 2023 at 12:11 AM Alyssa Ross <hi@alyssa.is> wrote: >> >> >> >>> Gurchetan Singh <gurchetansingh@chromium.org> writes: >> >>> >> >>> > On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross <hi@alyssa.is> wrote: >> >>> > >> >>> >> Gurchetan Singh <gurchetansingh@chromium.org> writes: >> >>> >> >> >>> >> > - Official "release commits" issued for rutabaga_gfx_ffi, >> >>> >> > gfxstream, aemu-base. For example, see crrev.com/c/4778941 >> >>> >> > >> >>> >> > - The release commits can make packaging easier, though once >> >>> >> > again all known users will likely just build from sources >> >>> >> > anyways >> >>> >> >> >>> >> It's a small thing, but could there be actual tags, rather than just >> >>> >> blessed commits? It'd just make them easier to find, and save a >> bit of >> >>> >> time in review for packages. >> >>> >> >> >>> > >> >>> > I added: >> >>> > >> >>> > >> >>> >> https://crosvm.dev/book/appendix/rutabaga_gfx.html#latest-releases-for-potential-packaging >> >>> > >> >>> > Tags are possible, but I want to clarify the use case before >> packaging. >> >>> > Where are you thinking of packaging it for (Debian??)? Are you mostly >> >>> > interested in Wayland passthrough (my guess) or gfxstream too? >> Depending >> >>> > your use case, we may be able to minimize the work involved. >> >>> >> >>> Packaging for Nixpkgs (where I already maintain what to my knowledge is >> >>> the only crosvm distro package). I'm personally mostly interested in >> >>> Wayland passthroug, but I wouldn't be surprised if others are >> interested >> >>> in gfxstream. The packaging work is already done, I've just been >> >>> holding off actually pushing the packages waiting for the stable >> >>> releases. >> >>> >> >>> The reason that tags would be useful is that it allows a reviewer of >> the >> >>> package to see at a glance that the package is built from a stable >> >>> release. If it's just built from a commit hash, they have to go and >> >>> verify that it's a stable release, which is mildly annoying and >> >>> unconventional. >> >>> >> >> >> >> Understood. Request to have gfxstream and AEMU v0.1.2 release tags >> made. >> >> >> >> For rutabaga_gfx_ffi, is the crates.io upload sufficient? >> >> >> >> https://crates.io/crates/rutabaga_gfx_ffi >> >> >> >> Debian, for example, treats crates.io as the source of truth and builds >> >> tooling around that. I wonder if Nixpkgs as similar tooling around >> >> crates.io. >> > >> > We do, and I'll use the crates.io release for the package — good >> > suggestion, but it's still useful to also have a tag in a git repo. It >> > makes it easier if I need to do a bisect, for example. As a distro >> > developer, I'm frequently jumping across codebases I am not very >> > familiar with to try to track down regressions, etc., and it's much >> > easier when I don't have to learn some special quirk of the package like >> > not having git tags. >> >> Aha, trying to switch my package over to it has revealed that there is >> actually a reason not to use the crates.io release. It doesn't include >> a Cargo.lock, which would mean we'd have to obtain one from elsewhere. >> Either from the crosvm git repo, at which point we might just get all >> the sources from there, or by vendoring a Cargo.lock into our own git >> tree for packages, which we try to avoid because when you have a lot of >> them, they become quite a large proportion of the overall size of the >> repo. >> > > Ack. Request to have a rutabaga release tag in crosvm also made, should be > complete in a few days. Thanks! I've found the rutabaga tag, but I still don't see any relevant tags for aemu or gfxstream. Any news there?
On Tue, Sep 12, 2023 at 1:53 AM Alyssa Ross <hi@alyssa.is> wrote: > Gurchetan Singh <gurchetansingh@chromium.org> writes: > > > On Fri, Aug 25, 2023 at 12:37 PM Alyssa Ross <hi@alyssa.is> wrote: > > > >> Alyssa Ross <hi@alyssa.is> writes: > >> > >> > Gurchetan Singh <gurchetansingh@chromium.org> writes: > >> > > >> >> On Fri, Aug 25, 2023 at 12:11 AM Alyssa Ross <hi@alyssa.is> wrote: > >> >> > >> >>> Gurchetan Singh <gurchetansingh@chromium.org> writes: > >> >>> > >> >>> > On Wed, Aug 23, 2023 at 4:07 AM Alyssa Ross <hi@alyssa.is> wrote: > >> >>> > > >> >>> >> Gurchetan Singh <gurchetansingh@chromium.org> writes: > >> >>> >> > >> >>> >> > - Official "release commits" issued for rutabaga_gfx_ffi, > >> >>> >> > gfxstream, aemu-base. For example, see crrev.com/c/4778941 > >> >>> >> > > >> >>> >> > - The release commits can make packaging easier, though once > >> >>> >> > again all known users will likely just build from sources > >> >>> >> > anyways > >> >>> >> > >> >>> >> It's a small thing, but could there be actual tags, rather than > just > >> >>> >> blessed commits? It'd just make them easier to find, and save a > >> bit of > >> >>> >> time in review for packages. > >> >>> >> > >> >>> > > >> >>> > I added: > >> >>> > > >> >>> > > >> >>> > >> > https://crosvm.dev/book/appendix/rutabaga_gfx.html#latest-releases-for-potential-packaging > >> >>> > > >> >>> > Tags are possible, but I want to clarify the use case before > >> packaging. > >> >>> > Where are you thinking of packaging it for (Debian??)? Are you > mostly > >> >>> > interested in Wayland passthrough (my guess) or gfxstream too? > >> Depending > >> >>> > your use case, we may be able to minimize the work involved. > >> >>> > >> >>> Packaging for Nixpkgs (where I already maintain what to my > knowledge is > >> >>> the only crosvm distro package). I'm personally mostly interested > in > >> >>> Wayland passthroug, but I wouldn't be surprised if others are > >> interested > >> >>> in gfxstream. The packaging work is already done, I've just been > >> >>> holding off actually pushing the packages waiting for the stable > >> >>> releases. > >> >>> > >> >>> The reason that tags would be useful is that it allows a reviewer of > >> the > >> >>> package to see at a glance that the package is built from a stable > >> >>> release. If it's just built from a commit hash, they have to go and > >> >>> verify that it's a stable release, which is mildly annoying and > >> >>> unconventional. > >> >>> > >> >> > >> >> Understood. Request to have gfxstream and AEMU v0.1.2 release tags > >> made. > >> >> > >> >> For rutabaga_gfx_ffi, is the crates.io upload sufficient? > >> >> > >> >> https://crates.io/crates/rutabaga_gfx_ffi > >> >> > >> >> Debian, for example, treats crates.io as the source of truth and > builds > >> >> tooling around that. I wonder if Nixpkgs as similar tooling around > >> >> crates.io. > >> > > >> > We do, and I'll use the crates.io release for the package — good > >> > suggestion, but it's still useful to also have a tag in a git repo. > It > >> > makes it easier if I need to do a bisect, for example. As a distro > >> > developer, I'm frequently jumping across codebases I am not very > >> > familiar with to try to track down regressions, etc., and it's much > >> > easier when I don't have to learn some special quirk of the package > like > >> > not having git tags. > >> > >> Aha, trying to switch my package over to it has revealed that there is > >> actually a reason not to use the crates.io release. It doesn't include > >> a Cargo.lock, which would mean we'd have to obtain one from elsewhere. > >> Either from the crosvm git repo, at which point we might just get all > >> the sources from there, or by vendoring a Cargo.lock into our own git > >> tree for packages, which we try to avoid because when you have a lot of > >> them, they become quite a large proportion of the overall size of the > >> repo. > >> > > > > Ack. Request to have a rutabaga release tag in crosvm also made, should > be > > complete in a few days. > > Thanks! I've found the rutabaga tag, but I still don't see any relevant > tags for aemu or gfxstream. Any news there? > It's harder to get the attention of the Android build team than the Chrome build team. Though, there are a few issues with AEMU/gfxstream packaging we also need to figure out -- see "[PATCH v13 0/9] rutabaga_gfx + gfxstream" for details -- interested in your opinion on the matter!
Gurchetan Singh <gurchetansingh@chromium.org> writes: > It's harder to get the attention of the Android build team than the Chrome > build team. Though, there are a few issues with AEMU/gfxstream packaging > we also need to figure out -- see "[PATCH v13 0/9] rutabaga_gfx + > gfxstream" for details -- interested in your opinion on the matter! None of the other points there are issues for me — in Nixpkgs, every package is installed to a unique prefix (different versions of the same package, or even just different build recipes for the same version, or different dependencies result in different prefixes), so library versioning and the /usr/include directories are not blockers. Static libraries are also fine for Nixpkgs — any change to a library, static or dynamic, causes all dependents to be rebuild against the new library, so the only real disadvantage to static libraries is the duplication on disk, which isn't a big deal. All that's to say, I'm ready to have rutabaga support, including gfxstream, in our QEMU package, as soon as a release of QEMU including it is made. Everything Marc-André has identified would still be nice to have fixed, but for us specifically, none of it is a blocker, even the tags I asked for.
From: Gurchetan Singh <gurchetansingh@google.com> Changes since v10: - Licensing and comment fixes - Official "release commits" issued for rutabaga_gfx_ffi, gfxstream, aemu-base. For example, see crrev.com/c/4778941 - The release commits can make packaging easier, though once again all known users will likely just build from sources anyways 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.freedesktop.org/gurchetansingh/qemu-gfxstream/-/commits/qemu-gfxstream-v11 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 Gurchetan Singh (5): gfxstream + rutabaga prep: added need defintions, fields, and options gfxstream + rutabaga: add initial support for gfxstream gfxstream + rutabaga: meson support gfxstream + rutabaga: enable rutabaga docs/system: add basic virtio-gpu documentation docs/system/device-emulation.rst | 1 + docs/system/devices/virtio-gpu.rst | 112 +++ hw/display/meson.build | 22 + hw/display/virtio-gpu-base.c | 6 +- hw/display/virtio-gpu-pci-rutabaga.c | 50 ++ hw/display/virtio-gpu-pci.c | 14 + hw/display/virtio-gpu-rutabaga.c | 1121 ++++++++++++++++++++++++++ hw/display/virtio-gpu.c | 16 +- hw/display/virtio-vga-rutabaga.c | 53 ++ hw/display/virtio-vga.c | 33 +- hw/virtio/virtio-pci.c | 18 + include/hw/virtio/virtio-gpu-bswap.h | 18 + include/hw/virtio/virtio-gpu.h | 41 + include/hw/virtio/virtio-pci.h | 4 + meson.build | 7 + meson_options.txt | 2 + scripts/meson-buildoptions.sh | 3 + softmmu/qdev-monitor.c | 3 + softmmu/vl.c | 1 + 19 files changed, 1506 insertions(+), 19 deletions(-) create mode 100644 docs/system/devices/virtio-gpu.rst create mode 100644 hw/display/virtio-gpu-pci-rutabaga.c create mode 100644 hw/display/virtio-gpu-rutabaga.c create mode 100644 hw/display/virtio-vga-rutabaga.c