From: Gurchetan Singh <gurchetansingh@google.com>

Prior version:

https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg07402.html

Branch containing changes:

https://gitlab.com/gurchetansingh/qemu/-/commits/qemu-gfxstream-v15

Changes since v14:

- Thomas Huth suggested the use of the "x-" prefix for experimental
  properties. Now, we have "x-gfxstream-gles" and "x-gfxstream-composer"
  since those capsets are only runnable with Android guests and we're
  not sure if anybody else will use them.

https://lists.gnu.org/archive/html/qemu-devel/2023-09/msg07465.html

What still needs to happen:

- As mentioned in v14:
    * AEMU: d6e6b99 "Delete VpxFrameParser.cpp"
    * gfxstream: 2131f78d Merge "gfxstream: add egl & gles deps.."

are the proposed v.0.1.2 release points.  If those commits are sufficient
for packaging AEMU + gfxstream, let me know and I'll have official release
tags made.  If additional changes are required for packaging, let me know
as well.

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     | 1122 ++++++++++++++++++++++++++
 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       |   40 +
 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, 1497 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.582.g8ccd20d70d-goog

Hi Gurchetan,

Gurchetan Singh <gurchetansingh@chromium.org> writes:

> - As mentioned in v14:
>     * AEMU: d6e6b99 "Delete VpxFrameParser.cpp"
>     * gfxstream: 2131f78d Merge "gfxstream: add egl & gles deps.."
>
> are the proposed v.0.1.2 release points.  If those commits are sufficient
> for packaging AEMU + gfxstream, let me know and I'll have official release
> tags made.  If additional changes are required for packaging, let me know
> as well.

Were these releases ever made?

The gfxstream ref mentioned here isn't compatible with
v0.1.2-rutabaga-release, because it no longer provides logging_base.pc,
and this email is the last mention I can find of these releases.

In Nixpkgs, I've gone for packaging gfxstream and aemu with your initial
proposed release points, which works fine, but it would be great to have
this clearer upstream.

On Tue, Jan 16, 2024 at 2:42 AM Alyssa Ross <hi@alyssa.is> wrote:
>
> Hi Gurchetan,
>
> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>
> > - As mentioned in v14:
> >     * AEMU: d6e6b99 "Delete VpxFrameParser.cpp"
> >     * gfxstream: 2131f78d Merge "gfxstream: add egl & gles deps.."
> >
> > are the proposed v.0.1.2 release points.  If those commits are sufficient
> > for packaging AEMU + gfxstream, let me know and I'll have official release
> > tags made.  If additional changes are required for packaging, let me know
> > as well.
>
> Were these releases ever made?

Thanks for the reminder.  I did make a request to create the release
tags, but changes were requested by Fedora packaging effort:

https://bugzilla.redhat.com/show_bug.cgi?id=2242058
https://bugzilla.redhat.com/show_bug.cgi?id=2241701

So the request was canceled, but never re-requested.  I'll fire off
another request, with:

gfxstream: 23d05703b94035ac045df60823fb1fc4be0fdf1c ("gfxstream:
manually add debug logic")
AEMU: dd8b929c247ce9872c775e0e5ddc4300011d0e82 ("aemu: improve licensing")

as the commits.  These match the Fedora requests, and the AEMU one has
been merged into Fedora already it seems.

>
>
> The gfxstream ref mentioned here isn't compatible with
> v0.1.2-rutabaga-release, because it no longer provides logging_base.pc,
> and this email is the last mention I can find of these releases.
>
> In Nixpkgs, I've gone for packaging gfxstream and aemu with your initial
> proposed release points, which works fine, but it would be great to have
> this clearer upstream.

Hi Gurchetan,

> Thanks for the reminder.  I did make a request to create the release
> tags, but changes were requested by Fedora packaging effort:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2242058
> https://bugzilla.redhat.com/show_bug.cgi?id=2241701
>
> So the request was canceled, but never re-requested.  I'll fire off
> another request, with:
>
> gfxstream: 23d05703b94035ac045df60823fb1fc4be0fdf1c ("gfxstream:
> manually add debug logic")
> AEMU: dd8b929c247ce9872c775e0e5ddc4300011d0e82 ("aemu: improve licensing")
>
> as the commits.  These match the Fedora requests, and the AEMU one has
> been merged into Fedora already it seems.

These revisions have the problem I mentioned in my previous message:

>> The gfxstream ref mentioned here isn't compatible with
>> v0.1.2-rutabaga-release, because it no longer provides logging_base.pc,

rutabaga was not fixed to use the new AEMU package names until after the
v0.1.2-rutabaga-release tag, in commit 5dfd74a06.  So will there be a
new Rutabaga release that's compatible with these release versions of
gfxstream and AEMU?

On Fri, Jan 19, 2024 at 1:13 PM Alyssa Ross <hi@alyssa.is> wrote:
>
> Hi Gurchetan,
>
> > Thanks for the reminder.  I did make a request to create the release
> > tags, but changes were requested by Fedora packaging effort:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=2242058
> > https://bugzilla.redhat.com/show_bug.cgi?id=2241701
> >
> > So the request was canceled, but never re-requested.  I'll fire off
> > another request, with:
> >
> > gfxstream: 23d05703b94035ac045df60823fb1fc4be0fdf1c ("gfxstream:
> > manually add debug logic")
> > AEMU: dd8b929c247ce9872c775e0e5ddc4300011d0e82 ("aemu: improve licensing")
> >
> > as the commits.  These match the Fedora requests, and the AEMU one has
> > been merged into Fedora already it seems.
>
> These revisions have the problem I mentioned in my previous message:
>
> >> The gfxstream ref mentioned here isn't compatible with
> >> v0.1.2-rutabaga-release, because it no longer provides logging_base.pc,
>
> rutabaga was not fixed to use the new AEMU package names until after the
> v0.1.2-rutabaga-release tag, in commit 5dfd74a06.  So will there be a
> new Rutabaga release that's compatible with these release versions of
> gfxstream and AEMU?

Good catch.

One possible workaround is to build gfxstream as a shared library.  I
think that would avoid rutabaga looking for AEMU package config files.

But if another rutabaga release is desired with support for a static
library, then we can make that happen too.

Gurchetan Singh <gurchetansingh@chromium.org> writes:

> On Fri, Jan 19, 2024 at 1:13 PM Alyssa Ross <hi@alyssa.is> wrote:
>>
>> Hi Gurchetan,
>>
>> > Thanks for the reminder.  I did make a request to create the release
>> > tags, but changes were requested by Fedora packaging effort:
>> >
>> > https://bugzilla.redhat.com/show_bug.cgi?id=2242058
>> > https://bugzilla.redhat.com/show_bug.cgi?id=2241701
>> >
>> > So the request was canceled, but never re-requested.  I'll fire off
>> > another request, with:
>> >
>> > gfxstream: 23d05703b94035ac045df60823fb1fc4be0fdf1c ("gfxstream:
>> > manually add debug logic")
>> > AEMU: dd8b929c247ce9872c775e0e5ddc4300011d0e82 ("aemu: improve licensing")
>> >
>> > as the commits.  These match the Fedora requests, and the AEMU one has
>> > been merged into Fedora already it seems.
>>
>> These revisions have the problem I mentioned in my previous message:
>>
>> >> The gfxstream ref mentioned here isn't compatible with
>> >> v0.1.2-rutabaga-release, because it no longer provides logging_base.pc,
>>
>> rutabaga was not fixed to use the new AEMU package names until after the
>> v0.1.2-rutabaga-release tag, in commit 5dfd74a06.  So will there be a
>> new Rutabaga release that's compatible with these release versions of
>> gfxstream and AEMU?
>
> Good catch.
>
> One possible workaround is to build gfxstream as a shared library.  I
> think that would avoid rutabaga looking for AEMU package config files.
>
> But if another rutabaga release is desired with support for a static
> library, then we can make that happen too.

We're exclusively building gfxstream as a shared library.

Looking at rutabaga's build.rs, it appears to me like pkg-config is
always used for gfxstream unless overridden by GFXSTREAM_PATH.

On Sat, Jan 20, 2024 at 4:19 AM Alyssa Ross <hi@alyssa.is> wrote:

> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>
> > On Fri, Jan 19, 2024 at 1:13 PM Alyssa Ross <hi@alyssa.is> wrote:
> >>
> >> Hi Gurchetan,
> >>
> >> > Thanks for the reminder.  I did make a request to create the release
> >> > tags, but changes were requested by Fedora packaging effort:
> >> >
> >> > https://bugzilla.redhat.com/show_bug.cgi?id=2242058
> >> > https://bugzilla.redhat.com/show_bug.cgi?id=2241701
> >> >
> >> > So the request was canceled, but never re-requested.  I'll fire off
> >> > another request, with:
> >> >
> >> > gfxstream: 23d05703b94035ac045df60823fb1fc4be0fdf1c ("gfxstream:
> >> > manually add debug logic")
> >> > AEMU: dd8b929c247ce9872c775e0e5ddc4300011d0e82 ("aemu: improve
> licensing")
> >> >
> >> > as the commits.  These match the Fedora requests, and the AEMU one has
> >> > been merged into Fedora already it seems.
> >>
> >> These revisions have the problem I mentioned in my previous message:
> >>
> >> >> The gfxstream ref mentioned here isn't compatible with
> >> >> v0.1.2-rutabaga-release, because it no longer provides
> logging_base.pc,
> >>
> >> rutabaga was not fixed to use the new AEMU package names until after the
> >> v0.1.2-rutabaga-release tag, in commit 5dfd74a06.  So will there be a
> >> new Rutabaga release that's compatible with these release versions of
> >> gfxstream and AEMU?
> >
> > Good catch.
> >
> > One possible workaround is to build gfxstream as a shared library.  I
> > think that would avoid rutabaga looking for AEMU package config files.
> >
> > But if another rutabaga release is desired with support for a static
> > library, then we can make that happen too.
>
> We're exclusively building gfxstream as a shared library.
>
> Looking at rutabaga's build.rs, it appears to me like pkg-config is
> always used for gfxstream unless overridden by GFXSTREAM_PATH.
>

Hmm, it seems we should be checking pkg-config --static before looking for
AEMU in build.rs -- oh well.

Would this be a suitable commit for the 0.1.3 release of rutabaga?

https://chromium.googlesource.com/crosvm/crosvm/+/5dfd74a0680d317c6edf44138def886f47cb1c7c

The gfxstream/AEMU commits would remain unchanged.

Gurchetan Singh <gurchetansingh@chromium.org> writes:

> On Sat, Jan 20, 2024 at 4:19 AM Alyssa Ross <hi@alyssa.is> wrote:
>
>> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>>
>> > On Fri, Jan 19, 2024 at 1:13 PM Alyssa Ross <hi@alyssa.is> wrote:
>> >>
>> >> Hi Gurchetan,
>> >>
>> >> > Thanks for the reminder.  I did make a request to create the release
>> >> > tags, but changes were requested by Fedora packaging effort:
>> >> >
>> >> > https://bugzilla.redhat.com/show_bug.cgi?id=2242058
>> >> > https://bugzilla.redhat.com/show_bug.cgi?id=2241701
>> >> >
>> >> > So the request was canceled, but never re-requested.  I'll fire off
>> >> > another request, with:
>> >> >
>> >> > gfxstream: 23d05703b94035ac045df60823fb1fc4be0fdf1c ("gfxstream:
>> >> > manually add debug logic")
>> >> > AEMU: dd8b929c247ce9872c775e0e5ddc4300011d0e82 ("aemu: improve
>> licensing")
>> >> >
>> >> > as the commits.  These match the Fedora requests, and the AEMU one has
>> >> > been merged into Fedora already it seems.
>> >>
>> >> These revisions have the problem I mentioned in my previous message:
>> >>
>> >> >> The gfxstream ref mentioned here isn't compatible with
>> >> >> v0.1.2-rutabaga-release, because it no longer provides
>> logging_base.pc,
>> >>
>> >> rutabaga was not fixed to use the new AEMU package names until after the
>> >> v0.1.2-rutabaga-release tag, in commit 5dfd74a06.  So will there be a
>> >> new Rutabaga release that's compatible with these release versions of
>> >> gfxstream and AEMU?
>> >
>> > Good catch.
>> >
>> > One possible workaround is to build gfxstream as a shared library.  I
>> > think that would avoid rutabaga looking for AEMU package config files.
>> >
>> > But if another rutabaga release is desired with support for a static
>> > library, then we can make that happen too.
>>
>> We're exclusively building gfxstream as a shared library.
>>
>> Looking at rutabaga's build.rs, it appears to me like pkg-config is
>> always used for gfxstream unless overridden by GFXSTREAM_PATH.
>>
>
> Hmm, it seems we should be checking pkg-config --static before looking for
> AEMU in build.rs -- oh well.
>
> Would this be a suitable commit for the 0.1.3 release of rutabaga?
>
> https://chromium.googlesource.com/crosvm/crosvm/+/5dfd74a0680d317c6edf44138def886f47cb1c7c
>
> The gfxstream/AEMU commits would remain unchanged.

That combination works for me.

On Fri, Jan 26, 2024 at 6:23 AM Alyssa Ross <hi@alyssa.is> wrote:

> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>
> > On Sat, Jan 20, 2024 at 4:19 AM Alyssa Ross <hi@alyssa.is> wrote:
> >
> >> Gurchetan Singh <gurchetansingh@chromium.org> writes:
> >>
> >> > On Fri, Jan 19, 2024 at 1:13 PM Alyssa Ross <hi@alyssa.is> wrote:
> >> >>
> >> >> Hi Gurchetan,
> >> >>
> >> >> > Thanks for the reminder.  I did make a request to create the
> release
> >> >> > tags, but changes were requested by Fedora packaging effort:
> >> >> >
> >> >> > https://bugzilla.redhat.com/show_bug.cgi?id=2242058
> >> >> > https://bugzilla.redhat.com/show_bug.cgi?id=2241701
> >> >> >
> >> >> > So the request was canceled, but never re-requested.  I'll fire off
> >> >> > another request, with:
> >> >> >
> >> >> > gfxstream: 23d05703b94035ac045df60823fb1fc4be0fdf1c ("gfxstream:
> >> >> > manually add debug logic")
> >> >> > AEMU: dd8b929c247ce9872c775e0e5ddc4300011d0e82 ("aemu: improve
> >> licensing")
> >> >> >
> >> >> > as the commits.  These match the Fedora requests, and the AEMU one
> has
> >> >> > been merged into Fedora already it seems.
> >> >>
> >> >> These revisions have the problem I mentioned in my previous message:
> >> >>
> >> >> >> The gfxstream ref mentioned here isn't compatible with
> >> >> >> v0.1.2-rutabaga-release, because it no longer provides
> >> logging_base.pc,
> >> >>
> >> >> rutabaga was not fixed to use the new AEMU package names until after
> the
> >> >> v0.1.2-rutabaga-release tag, in commit 5dfd74a06.  So will there be a
> >> >> new Rutabaga release that's compatible with these release versions of
> >> >> gfxstream and AEMU?
> >> >
> >> > Good catch.
> >> >
> >> > One possible workaround is to build gfxstream as a shared library.  I
> >> > think that would avoid rutabaga looking for AEMU package config files.
> >> >
> >> > But if another rutabaga release is desired with support for a static
> >> > library, then we can make that happen too.
> >>
> >> We're exclusively building gfxstream as a shared library.
> >>
> >> Looking at rutabaga's build.rs, it appears to me like pkg-config is
> >> always used for gfxstream unless overridden by GFXSTREAM_PATH.
> >>
> >
> > Hmm, it seems we should be checking pkg-config --static before looking
> for
> > AEMU in build.rs -- oh well.
> >
> > Would this be a suitable commit for the 0.1.3 release of rutabaga?
> >
> >
> https://chromium.googlesource.com/crosvm/crosvm/+/5dfd74a0680d317c6edf44138def886f47cb1c7c
> >
> > The gfxstream/AEMU commits would remain unchanged.
>
> That combination works for me.
>

Just FYI, still working on it.  Could take 1-2 more weeks.

On Tue, Jan 30, 2024 at 7:10 PM Gurchetan Singh <gurchetansingh@chromium.org>
wrote:

>
>
> On Fri, Jan 26, 2024 at 6:23 AM Alyssa Ross <hi@alyssa.is> wrote:
>
>> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>>
>> > On Sat, Jan 20, 2024 at 4:19 AM Alyssa Ross <hi@alyssa.is> wrote:
>> >
>> >> Gurchetan Singh <gurchetansingh@chromium.org> writes:
>> >>
>> >> > On Fri, Jan 19, 2024 at 1:13 PM Alyssa Ross <hi@alyssa.is> wrote:
>> >> >>
>> >> >> Hi Gurchetan,
>> >> >>
>> >> >> > Thanks for the reminder.  I did make a request to create the
>> release
>> >> >> > tags, but changes were requested by Fedora packaging effort:
>> >> >> >
>> >> >> > https://bugzilla.redhat.com/show_bug.cgi?id=2242058
>> >> >> > https://bugzilla.redhat.com/show_bug.cgi?id=2241701
>> >> >> >
>> >> >> > So the request was canceled, but never re-requested.  I'll fire
>> off
>> >> >> > another request, with:
>> >> >> >
>> >> >> > gfxstream: 23d05703b94035ac045df60823fb1fc4be0fdf1c ("gfxstream:
>> >> >> > manually add debug logic")
>> >> >> > AEMU: dd8b929c247ce9872c775e0e5ddc4300011d0e82 ("aemu: improve
>> >> licensing")
>> >> >> >
>> >> >> > as the commits.  These match the Fedora requests, and the AEMU
>> one has
>> >> >> > been merged into Fedora already it seems.
>> >> >>
>> >> >> These revisions have the problem I mentioned in my previous message:
>> >> >>
>> >> >> >> The gfxstream ref mentioned here isn't compatible with
>> >> >> >> v0.1.2-rutabaga-release, because it no longer provides
>> >> logging_base.pc,
>> >> >>
>> >> >> rutabaga was not fixed to use the new AEMU package names until
>> after the
>> >> >> v0.1.2-rutabaga-release tag, in commit 5dfd74a06.  So will there be
>> a
>> >> >> new Rutabaga release that's compatible with these release versions
>> of
>> >> >> gfxstream and AEMU?
>> >> >
>> >> > Good catch.
>> >> >
>> >> > One possible workaround is to build gfxstream as a shared library.  I
>> >> > think that would avoid rutabaga looking for AEMU package config
>> files.
>> >> >
>> >> > But if another rutabaga release is desired with support for a static
>> >> > library, then we can make that happen too.
>> >>
>> >> We're exclusively building gfxstream as a shared library.
>> >>
>> >> Looking at rutabaga's build.rs, it appears to me like pkg-config is
>> >> always used for gfxstream unless overridden by GFXSTREAM_PATH.
>> >>
>> >
>> > Hmm, it seems we should be checking pkg-config --static before looking
>> for
>> > AEMU in build.rs -- oh well.
>> >
>> > Would this be a suitable commit for the 0.1.3 release of rutabaga?
>> >
>> >
>> https://chromium.googlesource.com/crosvm/crosvm/+/5dfd74a0680d317c6edf44138def886f47cb1c7c
>> >
>> > The gfxstream/AEMU commits would remain unchanged.
>>
>> That combination works for me.
>>
>
> Just FYI, still working on it.  Could take 1-2 more weeks.
>

FYI:

https://android.googlesource.com/platform/hardware/google/gfxstream/+/refs/tags/v0.1.2-gfxstream-release

https://android.googlesource.com/platform/hardware/google/aemu/+/refs/tags/v0.1.2-aemu-release

https://chromium.googlesource.com/crosvm/crosvm/+/refs/tags/v0.1.3-rutabaga-release


>
>
>

Hi Gurchetan,

> >> > Would this be a suitable commit for the 0.1.3 release of rutabaga?
> >> >
> >> > https://chromium.googlesource.com/crosvm/crosvm/+/5dfd74a0680d317c6edf44138def886f47cb1c7c
> >> >
> >> > The gfxstream/AEMU commits would remain unchanged.
> >>
> >> That combination works for me.
> >
> > Just FYI, still working on it.  Could take 1-2 more weeks.
>
> FYI:
>
> https://android.googlesource.com/platform/hardware/google/gfxstream/+/refs/tags/v0.1.2-gfxstream-release
>
> https://android.googlesource.com/platform/hardware/google/aemu/+/refs/tags/v0.1.2-aemu-release
>
> https://chromium.googlesource.com/crosvm/crosvm/+/refs/tags/v0.1.3-rutabaga-release

Unlike the commit I tested for you, the commit that ended up being
tagged as v0.1.3-rutabaga-release doesn't work for me:

	qemu: The errno is EBADF: Bad file number
	qemu: CHECK failed in rutabaga_cmd_resource_map_blob() ../hw/display/virtio-gpu-rutabaga.c:655
	qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x208, error 0x1200
	qemu: CHECK failed in rutabaga_cmd_resource_unmap_blob() ../hw/display/virtio-gpu-rutabaga.c:723
	qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x209, error 0x1200
	qemu: The errno is EBADF: Bad file number
	qemu: CHECK failed in rutabaga_cmd_resource_map_blob() ../hw/display/virtio-gpu-rutabaga.c:655
	qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x208, error 0x1200
	qemu: CHECK failed in rutabaga_cmd_resource_unmap_blob() ../hw/display/virtio-gpu-rutabaga.c:723
	qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x209, error 0x1200
	qemu: The errno is EBADF: Bad file number
	qemu: CHECK failed in rutabaga_cmd_resource_map_blob() ../hw/display/virtio-gpu-rutabaga.c:655
	qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x208, error 0x1200
	qemu: invalid resource id
	qemu: CHECK failed in rutabaga_cmd_submit_3d() ../hw/display/virtio-gpu-rutabaga.c:341
	qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x207, error 0x1200
	qemu: CHECK failed in rutabaga_cmd_resource_unmap_blob() ../hw/display/virtio-gpu-rutabaga.c:723
	qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x209, error 0x1200

I bisected it to:

	commit f3dbf20eedadb135e2fd813474fbb9731d465f3a
	Author: Andrew Walbran <qwandor@google.com>
	Date:   Wed Nov 29 17:23:45 2023 +0000

	    rutabaga_gfx: Uprev nix to 0.27.1

	    The new version of nix uses OwnedFd in various places, which allows us
	    to have less unsafe code.

	    TEST=CQ
	    BUG=b:293289578

	    Change-Id: I61aa80c4105eaf1182c5c325109b5aba11cf60de
	    Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5072293
	    Auto-Submit: Andrew Walbran <qwandor@google.com>
	    Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
	    Reviewed-by: Frederick Mayle <fmayle@google.com>
	    Commit-Queue: Frederick Mayle <fmayle@google.com>

On Sat, Mar 2, 2024 at 6:38 AM Alyssa Ross <hi@alyssa.is> wrote:

> Hi Gurchetan,
>
> > >> > Would this be a suitable commit for the 0.1.3 release of rutabaga?
> > >> >
> > >> >
> https://chromium.googlesource.com/crosvm/crosvm/+/5dfd74a0680d317c6edf44138def886f47cb1c7c
> > >> >
> > >> > The gfxstream/AEMU commits would remain unchanged.
> > >>
> > >> That combination works for me.
> > >
> > > Just FYI, still working on it.  Could take 1-2 more weeks.
> >
> > FYI:
> >
> >
> https://android.googlesource.com/platform/hardware/google/gfxstream/+/refs/tags/v0.1.2-gfxstream-release
> >
> >
> https://android.googlesource.com/platform/hardware/google/aemu/+/refs/tags/v0.1.2-aemu-release
> >
> >
> https://chromium.googlesource.com/crosvm/crosvm/+/refs/tags/v0.1.3-rutabaga-release
>
> Unlike the commit I tested for you, the commit that ended up being
> tagged as v0.1.3-rutabaga-release doesn't work for me:
>
>         qemu: The errno is EBADF: Bad file number
>         qemu: CHECK failed in rutabaga_cmd_resource_map_blob()
> ../hw/display/virtio-gpu-rutabaga.c:655
>         qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x208, error 0x1200
>         qemu: CHECK failed in rutabaga_cmd_resource_unmap_blob()
> ../hw/display/virtio-gpu-rutabaga.c:723
>         qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x209, error 0x1200
>         qemu: The errno is EBADF: Bad file number
>         qemu: CHECK failed in rutabaga_cmd_resource_map_blob()
> ../hw/display/virtio-gpu-rutabaga.c:655
>         qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x208, error 0x1200
>         qemu: CHECK failed in rutabaga_cmd_resource_unmap_blob()
> ../hw/display/virtio-gpu-rutabaga.c:723
>         qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x209, error 0x1200
>         qemu: The errno is EBADF: Bad file number
>         qemu: CHECK failed in rutabaga_cmd_resource_map_blob()
> ../hw/display/virtio-gpu-rutabaga.c:655
>         qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x208, error 0x1200
>         qemu: invalid resource id
>         qemu: CHECK failed in rutabaga_cmd_submit_3d()
> ../hw/display/virtio-gpu-rutabaga.c:341
>         qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x207, error 0x1200
>         qemu: CHECK failed in rutabaga_cmd_resource_unmap_blob()
> ../hw/display/virtio-gpu-rutabaga.c:723
>         qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x209, error 0x1200
>

Thank you for the bug report .. does crrev.com/c/5342655 fix this for you?


I bisected it to:
>
>         commit f3dbf20eedadb135e2fd813474fbb9731d465f3a
>         Author: Andrew Walbran <qwandor@google.com>
>         Date:   Wed Nov 29 17:23:45 2023 +0000
>
>             rutabaga_gfx: Uprev nix to 0.27.1
>
>             The new version of nix uses OwnedFd in various places, which
> allows us
>             to have less unsafe code.
>
>             TEST=CQ
>             BUG=b:293289578
>
>             Change-Id: I61aa80c4105eaf1182c5c325109b5aba11cf60de
>             Reviewed-on:
> https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5072293
>             Auto-Submit: Andrew Walbran <qwandor@google.com>
>             Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
>             Reviewed-by: Frederick Mayle <fmayle@google.com>
>             Commit-Queue: Frederick Mayle <fmayle@google.com>
>

On Mon, Mar 04, 2024 at 04:23:20PM -0800, Gurchetan Singh wrote:
> On Sat, Mar 2, 2024 at 6:38 AM Alyssa Ross <hi@alyssa.is> wrote:
>
> > Hi Gurchetan,
> >
> > > >> > Would this be a suitable commit for the 0.1.3 release of rutabaga?
> > > >> >
> > > >> > https://chromium.googlesource.com/crosvm/crosvm/+/5dfd74a0680d317c6edf44138def886f47cb1c7c
> > > >> >
> > > >> > The gfxstream/AEMU commits would remain unchanged.
> > > >>
> > > >> That combination works for me.
> > > >
> > > > Just FYI, still working on it.  Could take 1-2 more weeks.
> > >
> > > FYI:
> > >
> > > https://android.googlesource.com/platform/hardware/google/gfxstream/+/refs/tags/v0.1.2-gfxstream-release
> > >
> > > https://android.googlesource.com/platform/hardware/google/aemu/+/refs/tags/v0.1.2-aemu-release
> > >
> > >
> > https://chromium.googlesource.com/crosvm/crosvm/+/refs/tags/v0.1.3-rutabaga-release
> >
> > Unlike the commit I tested for you, the commit that ended up being
> > tagged as v0.1.3-rutabaga-release doesn't work for me:
> >
> >         qemu: The errno is EBADF: Bad file number
> >         qemu: CHECK failed in rutabaga_cmd_resource_map_blob()
> > ../hw/display/virtio-gpu-rutabaga.c:655
> >         qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x208, error 0x1200
> >         qemu: CHECK failed in rutabaga_cmd_resource_unmap_blob()
> > ../hw/display/virtio-gpu-rutabaga.c:723
> >         qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x209, error 0x1200
> >         qemu: The errno is EBADF: Bad file number
> >         qemu: CHECK failed in rutabaga_cmd_resource_map_blob()
> > ../hw/display/virtio-gpu-rutabaga.c:655
> >         qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x208, error 0x1200
> >         qemu: CHECK failed in rutabaga_cmd_resource_unmap_blob()
> > ../hw/display/virtio-gpu-rutabaga.c:723
> >         qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x209, error 0x1200
> >         qemu: The errno is EBADF: Bad file number
> >         qemu: CHECK failed in rutabaga_cmd_resource_map_blob()
> > ../hw/display/virtio-gpu-rutabaga.c:655
> >         qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x208, error 0x1200
> >         qemu: invalid resource id
> >         qemu: CHECK failed in rutabaga_cmd_submit_3d()
> > ../hw/display/virtio-gpu-rutabaga.c:341
> >         qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x207, error 0x1200
> >         qemu: CHECK failed in rutabaga_cmd_resource_unmap_blob()
> > ../hw/display/virtio-gpu-rutabaga.c:723
> >         qemu: virtio_gpu_rutabaga_process_cmd: ctrl 0x209, error 0x1200
> >
>
> Thank you for the bug report .. does crrev.com/c/5342655 fix this for you?

Hi Gurchetan, thanks for looking into it, and sorry for the late reply.

Alas it doesn't seem to make a difference.

(The commit message is also incorrect.  AsFd is implemented for
SafeDescriptor in rutabaga_gfx/src/rutabaga_os/sys/linux/descriptor.rs.)

> I bisected it to:
> >
> >         commit f3dbf20eedadb135e2fd813474fbb9731d465f3a
> >         Author: Andrew Walbran <qwandor@google.com>
> >         Date:   Wed Nov 29 17:23:45 2023 +0000
> >
> >             rutabaga_gfx: Uprev nix to 0.27.1
> >
> >             The new version of nix uses OwnedFd in various places, which allows us
> >             to have less unsafe code.
> >
> >             TEST=CQ
> >             BUG=b:293289578
> >
> >             Change-Id: I61aa80c4105eaf1182c5c325109b5aba11cf60de
> >             Reviewed-on: https://chromium-review.googlesource.com/c/crosvm/crosvm/+/5072293
> >             Auto-Submit: Andrew Walbran <qwandor@google.com>
> >             Reviewed-by: Gurchetan Singh <gurchetansingh@chromium.org>
> >             Reviewed-by: Frederick Mayle <fmayle@google.com>
> >             Commit-Queue: Frederick Mayle <fmayle@google.com>
> >