From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id 1349C25E7; Wed, 09 Jul 2025 17:58:45 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id B65BD25E3; Wed, 09 Jul 2025 17:58:41 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on atuin.qyliss.net X-Spam-Level: X-Spam-Status: No, score=-0.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_PASS,SPF_HELO_NONE autolearn=unavailable autolearn_force=no version=4.0.1 Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) by atuin.qyliss.net (Postfix) with ESMTPS id 2FADF2685 for ; Wed, 09 Jul 2025 17:58:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1752083920; bh=KSEPl1vQRI7wziNlb2yMY+HnFkVu98iyDsAzvYHtVLo=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=CJc/w0azSZO4c3pQKK8Hhti5mLxlapp4KvbNQ1qSOysIJoF1HHmlX9uPMGbCq0pcH f4hkYMMTmA7aYIm1la+N/HetoZGCUwcoZGUYDlv/VQc3kd/mPYpe4AjHpEPc70rt28 cXUIT2OMImTehDA6+uwgoXWnqjcaNdNYC3V+YToJ+bQbhhE9tk9mQtSsySucYMbGXf uJmy8AvPRm/sIvNsDed0FVM4FqCsK+X1SF+OVUhKoxtJdCBXRNgcbSS7sGVE2a66HZ PHvPhURJr1UPdtoshk6tEUrBrtKIGh1pawYIfkgbBHQDfW57rqIiWjG4RealD9GQr4 b/U9jVPDO8wVw== Received: from [IPv6:2606:6d00:17:b699::5ac] (unknown [IPv6:2606:6d00:17:b699::5ac]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: nicolas) by bali.collaboradmins.com (Postfix) with ESMTPSA id DE5A117E0FA8; Wed, 9 Jul 2025 19:58:37 +0200 (CEST) Message-ID: Subject: Re: [PATCH v9 0/1] virtio-media: Add device specification From: Nicolas Dufresne To: Demi Marie Obenour , Albert Esteve , virtio-comment@lists.linux.dev Date: Wed, 09 Jul 2025 13:58:35 -0400 In-Reply-To: References: <20250709093456.350242-1-aesteve@redhat.com> Autocrypt: addr=nicolas.dufresne@collabora.com; prefer-encrypt=mutual; keydata=mQGiBEUQN0MRBACQYceNSezSdMjx7sx6gwKkMghrrODgl3B0eXBTgNp6c431IfOOEsdvk oOh1kwoYcQgbg4MXw6beOltysX4e8fFWsiRkc2nvvRW9ir9kHDm49MkBLqaDjTqOkYKNMiurFW+go zpr/lUW15QqT6v68RYe0zRdtwGZqeLzX2LVuukGwCg4AISzswrrYHNV7vQLcbaUhPgIl0D+gILYT9 TJgAEK4YHW+bFRcY+cgUFoLQqQayECMlctKoLOE69nIYOc/hDr9uih1wxrQ/yL0NJvQCohSPyoyLF 9b2EuIGhQVp05XP7FzlTxhYvGO/DtO08ec85+bTfVBMV6eeY4MS3ZU+1z7ObD7Pf29YjyTehN2Dan 6w1g2rBk5MoA/9nDocSlk4pbFpsYSFmVHsDiAOFje3+iY4ftVDKunKYWMhwRVBjAREOByBagmRau0 cLEcElpf4hX5f978GoxSGIsiKoDAlXX+ICDOWC1/EXhEEmBR1gL0QJgiVviNyLfGJlZWnPjw6xhhm tHYWTDxBOP5peztyc2PqeKsLsLWzAr7QnTmljb2xhcyBEdWZyZXNuZSA8bmljb2xhc0BuZHVmcmVz bmUuY2E+iGIEExECACIFAlXA3CACGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEHFTAi2sB qgcJngAnRDBTr8bhzuH0KQwFP1nEYtfgpKdAKCrQ/sJfuG/8zsd7J8wVl7y3e8ARbRDTmljb2xhcy BEdWZyZXNuZSAoQi4gU2MuIEluZm9ybWF0aXF1ZSkgPG5pY29sYXMuZHVmcmVzbmVAZ21haWwuY29 tPohgBBMRAgAgBQJFlCyOAhsDBgsJCAcDAgQVAggDBBYCAwECHgECF4AACgkQcVMCLawGqBwhLQCg zYlrLBj6KIAZ4gmsfjXD6ZtddT8AoIeGDicVq5WvMHNWign6ApQcZUihtElOaWNvbGFzIER1ZnJlc 25lIChCLiBTYy4gSW5mb3JtYXRpcXVlKSA8bmljb2xhcy5kdWZyZXNuZUBjb2xsYWJvcmEuY28udW s+iGIEExECACIFAkuzca8CGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEHFTAi2sBqgcQX8 An2By6LDEeMxi4B9hUbpvRnzaaeNqAJ9Rox8rfqHZnSErw9bCHiBwvwJZ77QxTmljb2xhcyBEdWZy ZXNuZSA8bmljb2xhcy5kdWZyZXNuZUBjb2xsYWJvcmEuY29tPohiBBMRAgAiBQJNzZzPAhsDBgsJC AcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBxUwItrAaoHLlxAKCYAGf4JL7DYDLs/188CPMGuwLypw CfWKc9DorA9f5pyYlD5pQo6SgSoiC0R05pY29sYXMgRHVmcmVzbmUgKEIgU2MuIEluZm9ybWF0aXF 1ZSkgPG5pY29sYXMuZHVmcmVzbmVAdXNoZXJicm9va2UuY2E+iGAEExECACAFAkUQN0MCGwMGCwkI BwMCBBUCCAMEFgIDAQIeAQIXgAAKCRBxUwItrAaoHPTnAJ0WGgJJVspoctAvEcI00mtp5WAFGgCgr +E7ItOqZEHAs+xabBgknYZIFPU= Organization: Collabora Canada Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ft98Rt8e2yL6JADeZrsJ" User-Agent: Evolution 3.56.2 (3.56.2-1.fc42) MIME-Version: 1.0 Message-ID-Hash: L4YGWPETX4EYLCWIYBY4OMQ6QPGJG24H X-Message-ID-Hash: L4YGWPETX4EYLCWIYBY4OMQ6QPGJG24H X-MailFrom: nicolas.dufresne@collabora.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; header-match-devel.spectrum-os.org-3; header-match-devel.spectrum-os.org-4; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: ribalda@google.com, alex.bennee@linaro.org, adelva@google.com, cohuck@redhat.com, mvaralar@redhat.com, hverkuil@xs4all.nl, gurchetansingh@google.com, daniel.almeida@collabora.com, changyeon@google.com, acourbot@google.com, mst@redhat.com, eballetb@redhat.com, agordeev@qti.qualcomm.com, gnurou@gmail.com, dverkamp@chromium.org, Spectrum OS Development , Alyssa Ross X-Mailman-Version: 3.3.9 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --=-ft98Rt8e2yL6JADeZrsJ Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Demi, Le mercredi 09 juillet 2025 =C3=A0 13:26 -0400, Demi Marie Obenour a =C3=A9= crit=C2=A0: > On 7/9/25 05:34, Albert Esteve wrote: > >=20 [...] >=20 > It's probably too late, but I have some serious concerns about this > device.=C2=A0 Specifically: >=20 > 1. I don't see a reasonable way to support untrusted virtio-media > =C2=A0=C2=A0 devices.=C2=A0 v4l2 has too many ioctls and I can't realisti= cally > =C2=A0=C2=A0 see a way to enforce that the return values from all of them > =C2=A0=C2=A0 are consistent with each other.=C2=A0 It is possible to only= allow > =C2=A0=C2=A0 a fixed format (such as uncompressed ARGB) and only allow th= e > =C2=A0=C2=A0 video source and/or sink to provide resolutions and frame ra= tes, > =C2=A0=C2=A0 but this means losing a lot of performance and abandoning an= y > =C2=A0=C2=A0 attempt at zero-copy. >=20 > =C2=A0=C2=A0 The use-case for untrusted virtio-media devices is not > =C2=A0=C2=A0 confidential computing, but rather disaggregated systems whe= re > =C2=A0=C2=A0 video sources (like webcams) may be attached to untrusted vi= rtual > =C2=A0=C2=A0 machines. Please consider that you are posting broadly and understanding of what you = mean by untrusted virtio-media can be difficult for non-virtio devs like me. With the enclosed information, I believe implementer are not forced to map = to a host V4L2 driver. You can implement a userspace layer in between, and possi= bly even implement reclaiming by simulation some hot-unplug of the devices, or = by not scheduling any work for M2M. I don't really see the relation between "trust" and the pixel format select= ion. Nor why preventing zero-copy would help handling untrusted virtual machines= . I do believe you should not attempt this if you don't have the required knowl= edge though, as its unlikely the end-result will be safe. For me the main issue for untrusted VM is the lack of control measure, such= as cgroup for resource usage. This is being worked on though, Maxime Ripard ha= ve given an update at the Linux Media Summit in Nice. >=20 > 2. v4l2 is a chatty protocol and using it implies a lot of > =C2=A0=C2=A0 guest <=3D> host round-trips.=C2=A0 This is bad for performa= nce. > =C2=A0=C2=A0 Is this overhead actually significant, and if so, are there > =C2=A0=C2=A0 plans to reduce it? You should try and demonstrate this. Virtio Video tried to make their own a= nd endup with something kind of similar with about the same level of back and forth. We already had few concerns with ioctl() overhead, and some measure = have been implemented, notably s_ctrl_ext. Nicolas --=-ft98Rt8e2yL6JADeZrsJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQSScpfJiL+hb5vvd45xUwItrAaoHAUCaG6tywAKCRBxUwItrAao HBywAJwM/uH1SB8Kry9ynjTyvrN9iDTdCgCfXqRntUU4NVmr3v4MFWBibzsNp5I= =bBkt -----END PGP SIGNATURE----- --=-ft98Rt8e2yL6JADeZrsJ--