On Wed, Aug 19, 2026 at 07:30:15PM +0800, Linlin Zhang wrote:
> 
> 
> On 8/19/2026 12:33 PM, Eric Biggers wrote:
> > On Fri, Aug 14, 2026 at 07:23:01AM -0700, Linlin Zhang wrote:
> >> When the feature is negotiated, the device reports inline encryption
> >> characteristics through virtio_blk_enc_characteristics. Add
> >> VIRTIO_BLK_T_GET_CRYPTO_MODES, VIRTIO_BLK_T_CRYPTO_IN, and
> >> VIRTIO_BLK_T_CRYPTO_OUT so that the driver can discover supported
> >> crypto modes and submit inline-encrypted I/O requests.
> > 
> > How is the driver expected to program and evict keyslots?
> 
> There are 2 new added drivers, one is virtio blk extension driver which is
> generic, and the other is crypto virtualization driver which is vendor
> specific.
> 
> The virtio blk extension driver manages the initialization of blk-crypto-profile,
> and implements the interfaces of blk_crypto_ll_ops.
> 
> The crypto virtualization driver performs similar operation like the key handling
> part in ufs-qcom and ice drivers. It forwards the key program/eviction request to
> Trust Zone via SMC call.
> 
> For QCOM, the whole flow of key program/eviction is like
>   - block layer passes the request to virtio_blk extension driver via blk_crypto_ll_ops
>   - virtio_blk extension -> crypto virtualization -> qcom_scm -> SCM -> HYP ->TZ

Can you annotate this with "guest" and "host"? Here is my guess:
- virtio_blk + extension driver: guest
- crypto virtualization + qcom_scm + SCM: guest
- HYP: host
- TZ: host

If this is correct, then it's unclear to me why a vendor-specific guest
component is involved?

What is the advantage of shipping qcom_scm inside the guest versus
defining a standard virtio-blk interface for blk_crypto_ll_ops that the
hypervisor's virtio-blk device implements via TZ on the host?

(We talked about this in the past, but I am still not familiar enough
with the Qualcomm hypervisor architecture to understand.)

Thanks,
Stefan