| Message ID | 20231003204500.518-1-gurchetansingh@chromium.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | rutabaga_gfx + gfxstream | expand |
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> > >
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