| Message ID | 20230711025649.708-1-gurchetansingh@chromium.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | gfxstream + rutabaga_gfx | expand |
Gurchetan Singh <gurchetansingh@chromium.org> writes: > In terms of API stability/versioning/packaging, once this series is > reviewed, the plan is to cut a "gfxstream upstream release branch". We > will have the same API guarantees as any other QEMU project then, i.e no > breaking API changes for 5 years. What about Rutabaga?
On Mon, Jul 24, 2023 at 2:56 AM Alyssa Ross <hi@alyssa.is> wrote: > > Gurchetan Singh <gurchetansingh@chromium.org> writes: > > > In terms of API stability/versioning/packaging, once this series is > > reviewed, the plan is to cut a "gfxstream upstream release branch". We > > will have the same API guarantees as any other QEMU project then, i.e no > > breaking API changes for 5 years. > > What about Rutabaga? Yes, rutabaga + gfxstream will both be versioned and maintain API backwards compatibility in line with QEMU guidelines.
Gurchetan Singh <gurchetansingh@chromium.org> writes: > On Mon, Jul 24, 2023 at 2:56 AM Alyssa Ross <hi@alyssa.is> wrote: >> >> Gurchetan Singh <gurchetansingh@chromium.org> writes: >> >> > In terms of API stability/versioning/packaging, once this series is >> > reviewed, the plan is to cut a "gfxstream upstream release branch". We >> > will have the same API guarantees as any other QEMU project then, i.e no >> > breaking API changes for 5 years. >> >> What about Rutabaga? > > Yes, rutabaga + gfxstream will both be versioned and maintain API > backwards compatibility in line with QEMU guidelines. In that case, I should draw your attention to <https://crrev.com/c/4584252>, which I've just realised while testing v2 of your series here breaks the build of the rutabaga ffi, and which will require the addition of a "prot" field to struct rutabaga_handle (a breaking change). I'll push a new version of that CL to fix rutabaga ffi in the next few days. Since this is already coming up, before the release has even been made, is it worth exploring how to limit the rutabaga API to avoid more breaking changes after the release? Could there be more use of opaque structs, for example? (CCing the crosvm list)
On Tue, Aug 1, 2023 at 8:18 AM Alyssa Ross <hi@alyssa.is> wrote: > Gurchetan Singh <gurchetansingh@chromium.org> writes: > > > On Mon, Jul 24, 2023 at 2:56 AM Alyssa Ross <hi@alyssa.is> wrote: > >> > >> Gurchetan Singh <gurchetansingh@chromium.org> writes: > >> > >> > In terms of API stability/versioning/packaging, once this series is > >> > reviewed, the plan is to cut a "gfxstream upstream release branch". > We > >> > will have the same API guarantees as any other QEMU project then, i.e > no > >> > breaking API changes for 5 years. > >> > >> What about Rutabaga? > > > > Yes, rutabaga + gfxstream will both be versioned and maintain API > > backwards compatibility in line with QEMU guidelines. > > In that case, I should draw your attention to > <https://crrev.com/c/4584252>, which I've just realised while testing v2 > of your series here breaks the build of the rutabaga ffi, and which will > require the addition of a "prot" field to struct rutabaga_handle (a > breaking change). I'll push a new version of that CL to fix rutabaga > ffi in the next few days. > Sorry, I didn't see this until now. At first glance, do we need to modify the rutabaga_handle? Can't we do fcntl(.., GET_FL) to get the access flags when needed? Since this is already coming up, before the release has even been made, > is it worth exploring how to limit the rutabaga API to avoid more > breaking changes after the release? Could there be more use of opaque > structs, for example? > > (CCing the crosvm list) >
Gurchetan Singh <gurchetansingh@chromium.org> writes: > On Tue, Aug 1, 2023 at 8:18 AM Alyssa Ross <hi@alyssa.is> wrote: > >> Gurchetan Singh <gurchetansingh@chromium.org> writes: >> >> > On Mon, Jul 24, 2023 at 2:56 AM Alyssa Ross <hi@alyssa.is> wrote: >> >> >> >> Gurchetan Singh <gurchetansingh@chromium.org> writes: >> >> >> >> > In terms of API stability/versioning/packaging, once this series is >> >> > reviewed, the plan is to cut a "gfxstream upstream release branch". We >> >> > will have the same API guarantees as any other QEMU project then, i.e no >> >> > breaking API changes for 5 years. >> >> >> >> What about Rutabaga? >> > >> > Yes, rutabaga + gfxstream will both be versioned and maintain API >> > backwards compatibility in line with QEMU guidelines. >> >> In that case, I should draw your attention to >> <https://crrev.com/c/4584252>, which I've just realised while testing v2 >> of your series here breaks the build of the rutabaga ffi, and which will >> require the addition of a "prot" field to struct rutabaga_handle (a >> breaking change). I'll push a new version of that CL to fix rutabaga >> ffi in the next few days. > > Sorry, I didn't see this until now. At first glance, do we need to modify > the rutabaga_handle? Can't we do fcntl(.., GET_FL) to get the access flags > when needed? That was my original approach[1], but it was difficult to make work on Windows and not popular. [1]: https://crrev.com/c/4543310
From: Gurchetan Singh <gurchetansingh@google.com> Latest iteration of rutabaga_gfx + gfxstream patches. Previous version and more background available here: https://patchew.org/QEMU/20230421011223.718-1-gurchetansingh@chromium.org/ Changes since RFC: - All important memory tests pass - Went with separate virtio-gpu-rutabaga device as suggested by Bernard Berschow - Incorporated review feedback, mostly from Akihiko Odaki - gfxstream has new unified guest/host repo + build system improvements - added documentation on virtio-gpu - new instructions on how to build available in the tracking bug [a] In terms of API stability/versioning/packaging, once this series is reviewed, the plan is to cut a "gfxstream upstream release branch". We will have the same API guarantees as any other QEMU project then, i.e no breaking API changes for 5 years. The Android Emulator will build both gfxstream (to get bug fixes fast) and QEMU8.0+ (due to regulatory requirements) from sources. So we haven't created a gfxstream Debian/Ubuntu package since we actually don't need it. Though, we plan to upload our QEMU8.0+ gfxstream enabled builds somewhere on AOSP when it's ready. It's more important for us to be in-tree to reduce technical debt given this. Let us know if there are any strong opinions on packaging. Otherwise, feedback + reviews welcome! [a] https://gitlab.com/qemu-project/qemu/-/issues/1611 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 | 80 ++ hw/display/meson.build | 22 + hw/display/virtio-gpu-base.c | 6 +- hw/display/virtio-gpu-pci-rutabaga.c | 48 ++ hw/display/virtio-gpu-pci.c | 14 + hw/display/virtio-gpu-rutabaga.c | 1088 ++++++++++++++++++++++++++ hw/display/virtio-gpu.c | 17 +- hw/display/virtio-vga-rutabaga.c | 52 ++ 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 | 34 + 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, 1431 insertions(+), 20 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