Re: [PATCH v13 0/9] rutabaga_gfx + gfxstream

[Gurchetan Singh]

On Wed, Sep 13, 2023 at 6:49 AM Marc-André Lureau <
marcandre.lur...@gmail.com> wrote:

> Hi
>
> On Wed, Sep 13, 2023 at 5:08 AM Gurchetan Singh
>  wrote:
> > On Tue, Sep 12, 2023 at 6:59 AM Marc-André Lureau <
> marcandre.lur...@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 000..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:
> 

Re: [PATCH v13 0/9] rutabaga_gfx + gfxstream

[Bernhard Beschow]

Am 6. September 2023 06:25:39 UTC schrieb "Marc-André Lureau" 
:
>Hi
>
>On Wed, Sep 6, 2023 at 5:22 AM Gurchetan Singh
> wrote:
>>
>>
>>
>> On Wed, Aug 30, 2023 at 7:26 PM Huang Rui  wrote:
>>>
>>> On Tue, Aug 29, 2023 at 08:36:20AM +0800, Gurchetan Singh wrote:
>>> > From: Gurchetan Singh 
>>> >
>>> > 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 
>>
>>
>> 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-f2fd7ba41...@gmail.com/

Best regards,
Bernhard

>
>Michael, are you prepping a virtio PR?
>
>thanks
>

Re: [PATCH v13 0/9] rutabaga_gfx + gfxstream

[Marc-André Lureau]

Hi

On Wed, Sep 13, 2023 at 5:08 AM Gurchetan Singh
 wrote:
> On Tue, Sep 12, 2023 at 6:59 AM Marc-André Lureau 
>  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 000..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

Re: [PATCH v13 0/9] rutabaga_gfx + gfxstream

[Gurchetan Singh]

On Tue, Sep 12, 2023 at 6:59 AM Marc-André Lureau <
marcandre.lur...@gmail.com> wrote:

> Hi Gurchetan
>
> On Wed, Sep 6, 2023 at 5:22 AM Gurchetan Singh
>  wrote:
> >
> >
> >
> > On Wed, Aug 30, 2023 at 7:26 PM Huang Rui  wrote:
> >>
> >> On Tue, Aug 29, 2023 at 08:36:20AM +0800, Gurchetan Singh wrote:
> >> > From: Gurchetan Singh 
> >> >
> >> > 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 
> >
> >
> > 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 

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
>

Re: [PATCH v13 0/9] rutabaga_gfx + gfxstream

[Marc-André Lureau]

Hi Gurchetan

On Wed, Sep 6, 2023 at 5:22 AM Gurchetan Singh
 wrote:
>
>
>
> On Wed, Aug 30, 2023 at 7:26 PM Huang Rui  wrote:
>>
>> On Tue, Aug 29, 2023 at 08:36:20AM +0800, Gurchetan Singh wrote:
>> > From: Gurchetan Singh 
>> >
>> > 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 
>
>
> 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

-- 
Marc-André Lureau

Re: [PATCH v13 0/9] rutabaga_gfx + gfxstream

[Marc-André Lureau]

Hi

On Wed, Sep 6, 2023 at 5:22 AM Gurchetan Singh
 wrote:
>
>
>
> On Wed, Aug 30, 2023 at 7:26 PM Huang Rui  wrote:
>>
>> On Tue, Aug 29, 2023 at 08:36:20AM +0800, Gurchetan Singh wrote:
>> > From: Gurchetan Singh 
>> >
>> > 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 
>
>
> 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

-- 
Marc-André Lureau

Re: [PATCH v13 0/9] rutabaga_gfx + gfxstream

[Gurchetan Singh]

On Wed, Aug 30, 2023 at 7:26 PM Huang Rui  wrote:

> On Tue, Aug 29, 2023 at 08:36:20AM +0800, Gurchetan Singh wrote:
> > From: Gurchetan Singh 
> >
> > 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 
>

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
> >
>

Re: [PATCH v13 0/9] rutabaga_gfx + gfxstream

[Huang Rui]

On Tue, Aug 29, 2023 at 08:36:20AM +0800, Gurchetan Singh wrote:
> From: Gurchetan Singh 
> 
> 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 

> 
> 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
> 

[PATCH v13 0/9] rutabaga_gfx + gfxstream

[Gurchetan Singh]

From: Gurchetan Singh 

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

-- 
2.42.0.rc2.253.gd59a3bf2b4-goog