1. 11 Sep, 2021 15 commits
    • Alexandre Courbot's avatar
      [DO-NOT-SUBMIT] virtio: video: decoder: add ffmpeg-based software decoder backend · 3c4410ea
      Alexandre Courbot authored and Daniel Almeida's avatar Daniel Almeida committed
      The virtio video decoder device is currently only available under very
      drastic conditions: a build linked against libvda (a ChromeOS-only
      library that needs the cros chroot to be built and linked against), and
      a ChromeOS-flavored Chrome instance running alongside crosvm, so the
      browser can provide the video decoding service through Mojo.
      
      This makes the decoder device very difficult to develop on for
      non-Chromies, and also for Chromies actually since they will always need
      a DUT in order to test the decoder.
      
      This patch introduces an alternative decoder backend based on
      libavcodec that performs decoding on the host's CPU. It supports both
      guest pages and virtio objects as target, and can be considered a
      cannonical, reliable way to test the decoder in any environment.
      
      The ffmpeg bindings used are ffmpeg-sys [1]. They only provide a
      direct interface to the C ffmpeg API, so there is a bit of unsafe code
      involved. In order to be built, these bindings need one or several
      environment variables to be set ; see [1] for details.
      
      Although decoding is done purely in software at the moment, ffmpeg
      supports various hardware-accelerated backends like vaapi, so maybe we
      can try and enable that in the future as well.
      
      [1] https://crates.io/crates/ffmpeg-sys
      
      Conditions for merging:
      * Complete drain/reset sequences which seem to be a bit buggy,
      * [DONE] Validate with ARCVM as a client,
      
      BUG=b:169295147
      TEST=cargo test --features "video-decoder,video-encoder" ffmpeg passes
      TEST=v4l2r's decoder example is able to decode and dump a H.264 stream,
           and the frames are correct.
      TEST=Android youtube plays videos correctly when the ffmpeg backend is
           used.
      
      Change-Id: Ic9c586193f7939f2a3fe59d009c3666585a8bbc7
      3c4410ea
    • Alexandre Courbot's avatar
      sys_util: add semaphore semantics for eventfd · b57d3fef
      Alexandre Courbot authored and Daniel Almeida's avatar Daniel Almeida committed
      The ffmpeg decoding backend will use this to signal its events to the
      decoder device.
      
      BUG=b:169295147
      TEST=`cargo build` passes.
      
      Change-Id: I367989e58e79ac8bc188ab9ac835f768bfad8188
      b57d3fef
    • Alexandre Courbot's avatar
      [DO NOT SUBMIT] support dynamic memory type · 9bbdbcc5
      Alexandre Courbot authored and Daniel Almeida's avatar Daniel Almeida committed
      TODO: do the same on the encoder side.
      
      BUG=b:161774071
      BUG=b:169295147
      TEST=Android Youtube plays properly on Hatch.
      
      Change-Id: If74dc6dcd6603937387b067c5251bd58e961b5cb
      9bbdbcc5
    • Alexandre Courbot's avatar
      Cargo: do not add the libvda feature by default · c4e2eb02
      Alexandre Courbot authored and Daniel Almeida's avatar Daniel Almeida committed
      Libvda can only be successfully used and linked against on Chrome OS.
      Making the video decoder and encoder depend on it makes it impossible to
      use these features on non-Chrome OS platforms. Remove the libvda feature
      by default since the Chrome OS builders have been updated to specify it
      explicitly.
      
      BUG=b:161774071
      TEST="cargo build --feature "video-decoder,video-encoder" succeeds.
      TEST="cargo build --feature "video-decoder,video-encoder,libvda"
           succeeds and embeds the libvda backends.
      Cq-Depend: chromium:3023696
      
      Change-Id: I54d31312e87e5d9a8e5c1a39955416bf892270d5
      c4e2eb02
    • Alexandre Courbot's avatar
      virtio: video: make libvda a selectable feature · 05aacbff
      Alexandre Courbot authored and Daniel Almeida's avatar Daniel Almeida committed
      For the crosvm externalization project, we want to be able to compile
      video support without libvda, which is only supported on Chrome OS.
      
      Add an explicit "libvda" feature to crosvm and make all the libvda code
      depend on that feature, so any trace of libvda can effectively be
      compiled out.
      
      For compatibility, the "libvda" feature is selected by the
      "video-decoder" or "video-encoder" features.
      
      BUG=b:161774071
      BUG=b:169295147
      TEST=`cargo build --features="video-decoder,video-encoder"` results in a
           crosvm binary with libvda enabled.
      
      Change-Id: Ice3d3089b73b77f6b009400953063f2cf8f385da
      05aacbff
    • Alexandre Courbot's avatar
      virtio: video: enable runtime selection of video backend · 47018e4b
      Alexandre Courbot authored and Daniel Almeida's avatar Daniel Almeida committed
      Make the "video-decoder" and "video-encoder" capable of taking an
      argument to explicitly specify which backend should be used. At the
      moment there is only one backend (libvda), but this is going to change
      soon and this change prepares for that.
      
      The argument-less forms of "video-decoder" and "video-encoder" are also
      kept and will select the libvda backend for compatibility.
      
      BUG=b:161774071
      BUG=b:169295147
      TEST=Android Youtube plays properly on Hatch.
      
      Change-Id: Ia2afd8932dbeabf381a3a2a81424812d50b99d50
      47018e4b
    • Alexandre Courbot's avatar
      virtio: video: build backends separately from the codec device · 5d1afcd4
      Alexandre Courbot authored and Daniel Almeida's avatar Daniel Almeida committed
      The current way for building a codec device is to call the corresponding
      constructor method of the backend we want to use. However doing forces
      us to pass the resource bridge to these constructors, introducing
      dependencies from the backend to parts of the code that are not used
      otherwise.
      
      Switch the construction method to one constructor per backend, which
      only takes the arguments relevant to the backend, and one device
      constructor that takes the backend to use as parameter.
      
      BUG=b:161774071
      BUG=b:169295147
      TEST=Android Youtube plays properly on Hatch.
      
      Change-Id: I493f421e982a1d2ba8292a69bae575afeee17e4c
      5d1afcd4
    • Alexandre Courbot's avatar
      virtio: video: simplify video device creation · 08d526df
      Alexandre Courbot authored and Daniel Almeida's avatar Daniel Almeida committed
      There doesn't seem to be any reason why we cannot create the video
      device before the GPU one ; the tubes should ensure proper
      synchronization and the fact that both devices create their own worker
      thread should make any order here moot anyway.
      
      BUG=b:161774071
      TEST=Android Youtube plays properly on Hatch.
      
      Change-Id: Ib548c1b249b13ae2af64b8d2a23ec61a58870942
      08d526df
    • Alexandre Courbot's avatar
      virtio: video: compile out decoder or encoder if corresponding feature not selected · 76aa5ae8
      Alexandre Courbot authored and Daniel Almeida's avatar Daniel Almeida committed
      We have two separate features for video decoder and encoder, but
      selecting any of them results in all the video code being included. Add
      some #[cfg] statements to compile out the unneeded code if only one of
      the features is selected.
      
      BUG=b:161774071
      TEST=`cargo build` passes
      TEST=`cargo build --features "video-decoder"` passes
      TEST=`cargo build --features "video-encoder"` passes
      TEST=`cargo build --features "video-decoder,video-encoder"` passes
      
      Change-Id: I3e5f2173695ee9dd5e8d26ace14374d426e570a6
      76aa5ae8
    • Alexandre Courbot's avatar
      [WIP] virtio: video: add support for contiguous guest memory · 6577d879
      Alexandre Courbot authored and Daniel Almeida's avatar Daniel Almeida committed
      BUG=b:169295147
      TEST=Android Youtube plays properly on Hatch.
      TEST=v4l2r's test decoder can allocate MMAP buffers.
      
      Change-Id: I9864113ca2b88a23db8204ee7dd8d38801857c25
      6577d879
    • Alexandre Courbot's avatar
      virtio: video: make backends accept GuestResources as inputs · f3173688
      Alexandre Courbot authored and Daniel Almeida's avatar Daniel Almeida committed
      Make the backends accept our generic resource types as inputs instead of
      expecting virtio objects. This makes the backends able to deal with any
      kind of resource, the counterpart being that they must now check what
      kind of resource they received. The VDA can only deal with virtio
      objects and will reject other kinds of resources.
      
      On top of making backends not limited to virtio objects, this is also
      safer than passing FDs because it becomes clear when we are transferring
      ownership of a resource, and when we need to clone them. Also since
      resources carry information about their layout, the number of arguments
      we need to pass to the backends is reduced.
      
      BUG=b:161774071
      BUG=b:169295147
      TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
      TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
      TEST=GtsExoPlayerTestCases com.google.android.exoplayer.gts.DashTest
      passes on hatch
      
      Change-Id: I09dd81bac13a46fa908a4107a376fa7d59fb9759
      f3173688
    • Alexandre Courbot's avatar
      virtio: video: introduce basis for proper resource management · 2a71173f
      Alexandre Courbot authored and Daniel Almeida's avatar Daniel Almeida committed
      Currently the video device only accepts virtio objects (as file
      descriptors) for resources, and file descriptors are hard-coded a bit
      all over the place to represent buffers and frames. This causes two issues:
      
      1) Multiple buffers cannot currently be used to represent frames, i.e. 1
         frame is exactly one virtio object,
      2) Resources that are not virtio objects, like guest memory, cannot
         be used at the moment.
      
      This patch introduces more flexibility in the way resources are handled:
      first, all the resource-related code, including their resolution using
      the resource bridge, is consolidated into a new resource module. Then,
      the command module does not arbitrarily decide that all resources are
      virtio objects, and leaves that decision to the queues. Finally,
      resources now have their enum type that can unfold into any of the
      resource types we will support (currently only virtio objects). This
      forces consumers of resources to check their type before using them.
      
      Semantically, very little should change. The only noticeable side-effect
      should be that we now call the resource bridge only once per input
      buffer instead of once per decoder operation.
      
      BUG=b:161774071
      BUG=b:169295147
      TEST=arc.VideoDecodeAccel.h264_vm passes on hatch
      TEST=arc.VideoEncodeAccel.h264_360p_i420_vm passes on hatch
      
      Change-Id: I93b203117b5c96e91d4f1b8007e95ec5c501ea5f
      2a71173f
    • Alexandre Courbot's avatar
      virtio: video: don't advertize support for non-contiguous memory · 18e18cd5
      Alexandre Courbot authored and Daniel Almeida's avatar Daniel Almeida committed
      We don't support non-contiguous guest memory buffers at the moment.
      Advertizing this capability did not matter when we were only supporting
      virtio objects, but now that we will also support guest memory it is
      important that we stop lying to the guest.
      
      BUG=b:161774071
      BUG=b:169295147
      TEST=Android Youtube plays properly on Hatch.
      Cq-Depend: chromium:3023911
      
      Change-Id: I0d0f1c571bceb37e77bd65f1092049ae04426dfb
      18e18cd5
    • Alexandre Courbot's avatar
      virtio: video: reject resources with more than one entry · eb557ab5
      Alexandre Courbot authored and Daniel Almeida's avatar Daniel Almeida committed
      The crosvm video device cannot currently work with resources that have
      more than one memory/object entry. Enforce this rule at the command
      level.
      
      BUG=b:161774071
      BUG=b:169295147
      TEST=Android Youtube plays properly on Hatch.
      Cq-Depend: chromium:3023908
      Cq-Depend: chromium:3023912
      
      Change-Id: Ibfe2e420b4a77062cca940c5e97e7053aa4b76a7
      eb557ab5
    • Alexandre Courbot's avatar
      virtio: video: remove suspicious code · f6afe7a4
      Alexandre Courbot authored and Daniel Almeida's avatar Daniel Almeida committed
      When outputting a picture there is a bit of code that updates the size
      of each output plane to the size of the visible rect. This looks wrong
      on several accounts:
      
      1) The plane size should already have been computed when we received the
         buffers,
      2) With this code each plane is assigned the same size, which is
         obviously wrong with formats such as NV12,
      3) The size in bytes of a plane depends on the coded size, not the
         visible size.
      
      Looking at the git history it appears that this code has been here since
      the initial revision of the decoder, and then moved around. Maybe it was
      just here to make things work in the beginning and slipped under the
      radar. In any case, removing that code does not seem to hurt.
      
      BUG=b:161774071
      BUG=b:169295147
      TEST=Android Youtube plays properly on Hatch.
      
      Change-Id: I6c8949c49c070daaa3540b757dd35469b571c43c
      f6afe7a4
  2. 09 Sep, 2021 5 commits
  3. 07 Sep, 2021 4 commits
  4. 06 Sep, 2021 1 commit
    • Chirantan Ekbote's avatar
      fs: Fix enable_verity() impl · e3364b74
      Chirantan Ekbote authored
      The fsverity_enable_arg struct contains optional pointers to additional
      data.  Check for them and try to copy them in if necessary.  This
      requires a corresponding kernel change where the fuse driver also
      reads the struct and copies the relevant data from the userspace
      application.
      
      Steps to test this change:
      
      // Create a test file
      head -c 1000000 /dev/urandom > file
      
      // Generate a new certificate and private key:
      openssl req -newkey rsa:4096 -nodes -keyout key.pem -x509 -out cert.pem
      
      // Convert the certificate from PEM to DER format:
      openssl x509 -in cert.pem -out cert.der -outform der
      
      // Load the certificate into the fs-verity keyring.  This step MUST be
      // done on the host kernel.
      keyctl padd asymmetric '' %keyring:.fs-verity < cert.der
      
      // Now set up fs-verity on the test file:
      fsverity sign file file.sig --key=key.pem --cert=cert.pem \
          --salt 12345678
      fsverity enable file --signature=file.sig --salt 12345678
      
      BUG=b:141632062
      TEST=See above
      
      Change-Id: Ied7106cfbd2919f1f0c7f605166769d4916925b0
      Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/crosvm/+/3141298
      
      Tested-by: default avatarkokoro <noreply+kokoro@google.com>
      Reviewed-by: default avatarDaniel Verkamp <dverkamp@chromium.org>
      Reviewed-by: default avatarKeiichi Watanabe <keiichiw@chromium.org>
      Commit-Queue: Chirantan Ekbote <chirantan@chromium.org>
      e3364b74
  5. 03 Sep, 2021 6 commits
  6. 02 Sep, 2021 9 commits