| Message ID | 20230829003629.410-1-gurchetansingh@chromium.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | rutabaga_gfx + gfxstream | expand |
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> > > 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 | 47 ++ > hw/display/virtio-gpu-pci.c | 14 + > hw/display/virtio-gpu-rutabaga.c | 1119 ++++++++++++++++++++++++++ > hw/display/virtio-gpu.c | 16 +- > hw/display/virtio-vga-rutabaga.c | 50 ++ > hw/display/virtio-vga.c | 33 +- > hw/virtio/virtio-pci.c | 18 + > include/hw/virtio/virtio-gpu-bswap.h | 15 + > 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, 1495 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 > > -- > 2.42.0.rc2.253.gd59a3bf2b4-goog >
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! > > > > > 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 | 47 ++ > > hw/display/virtio-gpu-pci.c | 14 + > > hw/display/virtio-gpu-rutabaga.c | 1119 ++++++++++++++++++++++++++ > > hw/display/virtio-gpu.c | 16 +- > > hw/display/virtio-vga-rutabaga.c | 50 ++ > > hw/display/virtio-vga.c | 33 +- > > hw/virtio/virtio-pci.c | 18 + > > include/hw/virtio/virtio-gpu-bswap.h | 15 + > > 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, 1495 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 > > > > -- > > 2.42.0.rc2.253.gd59a3bf2b4-goog > > >
Hi 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! > I can take it, or Michael (since Gerd is not focused on QEMU atm). Michael, are you prepping a virtio PR? thanks
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? 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
On Tue, Sep 12, 2023 at 6:59 AM Marc-André Lureau < marcandre.lureau@gmail.com> wrote: > 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: crrev.com/c/4860836 <http://crrev.com/c4860836> 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 > https://android-review.googlesource.com/c/platform/hardware/google/gfxstream/+/2749095 > > > (packaging is important so we can build the new code in CI too!) > > thanks > > -- > Marc-André Lureau >
Hi On Wed, Sep 13, 2023 at 5:08 AM Gurchetan Singh <gurchetansingh@chromium.org> wrote: > On Tue, Sep 12, 2023 at 6:59 AM Marc-André Lureau <marcandre.lureau@gmail.com> wrote: >> 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: > > crrev.com/c/4860836 > > 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! > I would rather have standard packaging of the various projects, so we can test and develop easily. For rutabaga, I ended up having to patch a little bit the shared library, to fix SONAME: diff --git a/ffi/Makefile b/ffi/Makefile index d2f0d38..7efc8f3 100644 --- a/ffi/Makefile +++ b/ffi/Makefile @@ -47,13 +47,13 @@ build: install: build ifeq ($(UNAME), Linux) - install -D -m 755 -t $(DESTDIR)$(libdir) $(OUT)/$(LIB_NAME) + install -D -m 755 $(OUT)/$(LIB_NAME) $(DESTDIR)$(libdir)/$(LIB_NAME).$(RUTABAGA_VERSION) endif ifeq ($(UNAME), Darwin) - install_name_tool -id $(DESTDIR)$(libdir)/$(LIB_NAME) $(DESTDIR)$(libdir)/$(LIB_NAME) + install_name_tool -id $(DESTDIR)$(libdir)/$(LIB_NAME).$(RUTABAGA_VERSION) $(DESTDIR)$(libdir)/$(LIB_NAME) endif - ln -sf $(DESTDIR)$(libdir)/$(LIB_NAME) $(DESTDIR)$(libdir)/$(LIB_NAME).$(RUTABAGA_VERSION) - ln -sf $(DESTDIR)$(libdir)/$(LIB_NAME) $(DESTDIR)$(libdir)/$(LIB_NAME).$(RUTABAGA_VERSION_MAJOR) + ln -s $(LIB_NAME).$(RUTABAGA_VERSION) $(DESTDIR)$(libdir)/$(LIB_NAME).$(RUTABAGA_VERSION_MAJOR) + ln -s $(LIB_NAME).$(RUTABAGA_VERSION) $(DESTDIR)$(libdir)/$(LIB_NAME) ifeq ($(UNAME), Linux) install -D -m 0644 $(SRC)/share/rutabaga_gfx_ffi.pc $(DESTDIR)$(libdir)/pkgconfig/rutabaga_gfx_ffi.pc install -D -m 0644 $(SRC)/include/rutabaga_gfx_ffi.h $(DESTDIR)$(includedir)/rutabaga_gfx_ffi.h diff --git a/ffi/build.rs b/ffi/build.rs new file mode 100644 index 0000000..efa18d3 --- /dev/null +++ b/ffi/build.rs @@ -0,0 +1,3 @@ +fn main() { + println!("cargo:rustc-cdylib-link-arg=-Wl,-soname,librutabaga_gfx_ffi.so.0"); +} The package is a bit unconventional, since it's a rust project providing a C shared library. I am not sure I did Fedora packaging right, let see: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2238751
Am 6. September 2023 06:25:39 UTC schrieb "Marc-André Lureau" <marcandre.lureau@gmail.com>: >Hi > >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! >> > >I can take it, or Michael (since Gerd is not focused on QEMU atm). I've added a review comment on v11: https://lore.kernel.org/qemu-devel/B1A4DF8C-3078-48AD-BC8B-F2FD7BA413CF@gmail.com/ Best regards, Bernhard > >Michael, are you prepping a virtio PR? > >thanks >
On Wed, Sep 13, 2023 at 6:49 AM Marc-André Lureau < marcandre.lureau@gmail.com> wrote: > Hi > > On Wed, Sep 13, 2023 at 5:08 AM Gurchetan Singh > <gurchetansingh@chromium.org> wrote: > > On Tue, Sep 12, 2023 at 6:59 AM Marc-André Lureau < > marcandre.lureau@gmail.com> wrote: > >> 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: > > > > crrev.com/c/4860836 > > > > 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! > > > > I would rather have standard packaging of the various projects, so we > can test and develop easily. > Ack. Here are the requested changes: - https://android-review.googlesource.com/q/topic:%22aemu-package-fix%22 - crrev.com/c/4865171 The main change is: https://android-review.googlesource.com/c/platform/hardware/google/aemu/+/2751066 Once that's okay for packaging, I'll ping harder on v0.1.2 gfxstream/AEMU release tags. Let me know if you want another release tag for rutabaga, or if just patching in upstream changes would be acceptable. For rutabaga, I ended up having to patch a little bit the shared > library, to fix SONAME: > Landed as crrev.com/c/4863380. > > diff --git a/ffi/Makefile b/ffi/Makefile > index d2f0d38..7efc8f3 100644 > --- a/ffi/Makefile > +++ b/ffi/Makefile > @@ -47,13 +47,13 @@ build: > > install: build > ifeq ($(UNAME), Linux) > - install -D -m 755 -t $(DESTDIR)$(libdir) $(OUT)/$(LIB_NAME) > + install -D -m 755 $(OUT)/$(LIB_NAME) > $(DESTDIR)$(libdir)/$(LIB_NAME).$(RUTABAGA_VERSION) > endif > ifeq ($(UNAME), Darwin) > - install_name_tool -id $(DESTDIR)$(libdir)/$(LIB_NAME) > $(DESTDIR)$(libdir)/$(LIB_NAME) > + install_name_tool -id > $(DESTDIR)$(libdir)/$(LIB_NAME).$(RUTABAGA_VERSION) > $(DESTDIR)$(libdir)/$(LIB_NAME) > endif > - ln -sf $(DESTDIR)$(libdir)/$(LIB_NAME) > $(DESTDIR)$(libdir)/$(LIB_NAME).$(RUTABAGA_VERSION) > - ln -sf $(DESTDIR)$(libdir)/$(LIB_NAME) > $(DESTDIR)$(libdir)/$(LIB_NAME).$(RUTABAGA_VERSION_MAJOR) > + ln -s $(LIB_NAME).$(RUTABAGA_VERSION) > $(DESTDIR)$(libdir)/$(LIB_NAME).$(RUTABAGA_VERSION_MAJOR) > + ln -s $(LIB_NAME).$(RUTABAGA_VERSION) $(DESTDIR)$(libdir)/$(LIB_NAME) > ifeq ($(UNAME), Linux) > install -D -m 0644 $(SRC)/share/rutabaga_gfx_ffi.pc > $(DESTDIR)$(libdir)/pkgconfig/rutabaga_gfx_ffi.pc > install -D -m 0644 $(SRC)/include/rutabaga_gfx_ffi.h > $(DESTDIR)$(includedir)/rutabaga_gfx_ffi.h > diff --git a/ffi/build.rs b/ffi/build.rs > new file mode 100644 > index 0000000..efa18d3 > --- /dev/null > +++ b/ffi/build.rs > @@ -0,0 +1,3 @@ > +fn main() { > + > println!("cargo:rustc-cdylib-link-arg=-Wl,-soname,librutabaga_gfx_ffi.so.0"); > +} > > > The package is a bit unconventional, since it's a rust project > providing a C shared library. I am not sure I did Fedora packaging > right, let see: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2238751 > > > -- > Marc-André Lureau >
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 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 | 47 ++ hw/display/virtio-gpu-pci.c | 14 + hw/display/virtio-gpu-rutabaga.c | 1119 ++++++++++++++++++++++++++ hw/display/virtio-gpu.c | 16 +- hw/display/virtio-vga-rutabaga.c | 50 ++ hw/display/virtio-vga.c | 33 +- hw/virtio/virtio-pci.c | 18 + include/hw/virtio/virtio-gpu-bswap.h | 15 + 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, 1495 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