Re: [PATCH 2/2] iommu/iova: Free global iova rcache on iova alloc failure
On 8/12/2020 8:46 PM, Joerg Roedel wrote: > On Mon, Aug 03, 2020 at 03:30:48PM +0530, Vijayanand Jitta wrote: >> ping? > > Please repost when v5.9-rc1 is released and add > > Robin Murphy > > on your Cc list. > > Thanks, > > Joerg > Sure, will do. Thanks, Vijay -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 2/7] iommu/uapi: Add argsz for user filled data
Hi,
On 7/30/20 2:21 AM, Jacob Pan wrote:
> As IOMMU UAPI gets extended, user data size may increase. To support
> backward compatibiliy, this patch introduces a size field to each UAPI
s/compatibiliy/compatibility
> data structures. It is *always* the responsibility for the user to fill in
> the correct size. Padding fields are adjusted to ensure 8 byte alignment.
>
> Specific scenarios for user data handling are documented in:
> Documentation/userspace-api/iommu.rst
you may mention the struct version does not need to be incremented as no
IOCTL uses the structs yet.
>
> Signed-off-by: Liu Yi L
> Signed-off-by: Jacob Pan
> ---
> include/uapi/linux/iommu.h | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h
> index e907b7091a46..d5e9014f690e 100644
> --- a/include/uapi/linux/iommu.h
> +++ b/include/uapi/linux/iommu.h
> @@ -135,6 +135,7 @@ enum iommu_page_response_code {
>
> /**
> * struct iommu_page_response - Generic page response information
> + * @argsz: User filled size of this data
> * @version: API version of this structure
> * @flags: encodes whether the corresponding fields are valid
> * (IOMMU_FAULT_PAGE_RESPONSE_* values)
> @@ -143,6 +144,7 @@ enum iommu_page_response_code {
> * @code: response code from iommu_page_response_code
> */
> struct iommu_page_response {
> + __u32 argsz;
> #define IOMMU_PAGE_RESP_VERSION_11
> __u32 version;
> #define IOMMU_PAGE_RESP_PASID_VALID (1 << 0)
> @@ -218,6 +220,7 @@ struct iommu_inv_pasid_info {
> /**
> * struct iommu_cache_invalidate_info - First level/stage invalidation
> * information
> + * @argsz: User filled size of this data
> * @version: API version of this structure
> * @cache: bitfield that allows to select which caches to invalidate
> * @granularity: defines the lowest granularity used for the invalidation:
> @@ -246,6 +249,7 @@ struct iommu_inv_pasid_info {
> * must support the used granularity.
> */
> struct iommu_cache_invalidate_info {
> + __u32 argsz;
> #define IOMMU_CACHE_INVALIDATE_INFO_VERSION_1 1
> __u32 version;
> /* IOMMU paging structure cache */
> @@ -255,7 +259,7 @@ struct iommu_cache_invalidate_info {
> #define IOMMU_CACHE_INV_TYPE_NR (3)
> __u8cache;
> __u8granularity;
> - __u8padding[2];
> + __u8padding[6];
> union {
> struct iommu_inv_pasid_info pasid_info;
> struct iommu_inv_addr_info addr_info;
> @@ -292,6 +296,7 @@ struct iommu_gpasid_bind_data_vtd {
>
> /**
> * struct iommu_gpasid_bind_data - Information about device and guest PASID
> binding
> + * @argsz: User filled size of this data
> * @version: Version of this data structure
> * @format: PASID table entry format
> * @flags: Additional information on guest bind request
> @@ -309,17 +314,18 @@ struct iommu_gpasid_bind_data_vtd {
> * PASID to host PASID based on this bind data.
> */
> struct iommu_gpasid_bind_data {
> + __u32 argsz;
> #define IOMMU_GPASID_BIND_VERSION_1 1
> __u32 version;
> #define IOMMU_PASID_FORMAT_INTEL_VTD 1
> __u32 format;
> + __u32 addr_width;
> #define IOMMU_SVA_GPASID_VAL (1 << 0) /* guest PASID valid */
> __u64 flags;
> __u64 gpgd;
> __u64 hpasid;
> __u64 gpasid;
> - __u32 addr_width;
> - __u8 padding[12];
> + __u8 padding[8];
> /* Vendor specific data */
> union {
> struct iommu_gpasid_bind_data_vtd vtd;
>
Reviewed-by: Eric Auger
Thanks
Eric
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v7 1/7] docs: IOMMU user API
Hi Jacob, On 7/30/20 2:21 AM, Jacob Pan wrote: > IOMMU UAPI is newly introduced to support communications between guest > virtual IOMMU and host IOMMU. There has been lots of discussions on how > it should work with VFIO UAPI and userspace in general. > > This document is intended to clarify the UAPI design and usage. The > mechanics of how future extensions should be achieved are also covered > in this documentation. > > Signed-off-by: Liu Yi L > Signed-off-by: Jacob Pan > --- > Documentation/userspace-api/iommu.rst | 212 > ++ > MAINTAINERS | 1 + > 2 files changed, 213 insertions(+) > create mode 100644 Documentation/userspace-api/iommu.rst > > diff --git a/Documentation/userspace-api/iommu.rst > b/Documentation/userspace-api/iommu.rst > new file mode 100644 > index ..b2f5b3256d85 > --- /dev/null > +++ b/Documentation/userspace-api/iommu.rst > @@ -0,0 +1,212 @@ > +.. SPDX-License-Identifier: GPL-2.0 > +.. iommu: > + > += > +IOMMU Userspace API > += > + > +IOMMU UAPI is used for virtualization cases where communications are > +needed between physical and virtual IOMMU drivers. For baremetal > +usage, the IOMMU is a system device which does not need to communicate > +with user space directly. > + > +The primary use cases are guest Shared Virtual Address (SVA) and > +guest IO virtual address (IOVA), wherin the vIOMMU implementation > +relies on the physical IOMMU and for this reason requires interactions > +with the host driver. > + > +.. contents:: :local: > + > +Functionalities > +=== > +Communications of user and kernel involve both directions. The > +supported user-kernel APIs are as follows: > + > +1. Alloc/Free PASID > +2. Bind/unbind guest PASID (e.g. Intel VT-d) nit: s/unbind/Unbind to match above Free > +3. Bind/unbind guest PASID table (e.g. ARM SMMU) > +4. Invalidate IOMMU caches requested by guests s/requested by guests/upon guest requests > +5. Report errors to the guest and serve page requests > + > +Requirements > + > +The IOMMU UAPIs are generic and extensible to meet the following > +requirements: > + > +1. Emulated and para-virtualised vIOMMUs > +2. Multiple vendors (Intel VT-d, ARM SMMU, etc.) > +3. Extensions to the UAPI shall not break existing user space > + > +Interfaces > +== > +Although the data structures defined in IOMMU UAPI are self-contained, > +there is no user API functions introduced. Instead, IOMMU UAPI is > +designed to work with existing user driver frameworks such as VFIO. > + > +Extension Rules & Precautions > +- > +When IOMMU UAPI gets extended, the data structures can *only* be > +modified in two ways: > + > +1. Adding new fields by re-purposing the padding[] field. No size change. > +2. Adding new union members at the end. May increase the structure sizes. > + > +No new fields can be added *after* the variable sized union in that it > +will break backward compatibility when offset moves. A new flag must > +be introduced whenever a change affects the structure using either > +method. The IOMMU driver processes the data based on flags which > +ensures backward compatibility. > + > +Version field is only reserved for the unlikely event of UAPI upgrade > +at its entirety. > + > +It's *always* the caller's responsibility to indicate the size of the > +structure passed by setting argsz appropriately. > +Though at the same time, argsz is user provided data which is not > +trusted. The argsz field allows the user app to indicate how much data > +it is providing, it's still the kernel's responsibility to validate > +whether it's correct and sufficient for the requested operation. > + > +Compatibility Checking > +-- > +When IOMMU UAPI extension results in some structure size increase, > +IOMMU UAPI code shall handle the following cases: > + > +1. User and kernel has exact size match > +2. An older user with older kernel header (smaller UAPI size) running on a > + newer kernel (larger UAPI size) > +3. A newer user with newer kernel header (larger UAPI size) running > + on an older kernel. > +4. A malicious/misbehaving user pass illegal/invalid size but within > + range. The data may contain garbage. > + > +Feature Checking > + > +While launching a guest with vIOMMU, it is important to ensure that host > +can support the UAPI data structures to be used for vIOMMU-pIOMMU > +communications. Without upfront compatibility checking, the future errors > +can lead to catastrophic failures for the users. I would rather say: it is strongly advised to check the compatibility upfront, as some subsequent errors happening during vIOMMU operation, such as cache invalidation failures cannot be nicely escaladated to the guest due to IOMMU specifications. > + > +User applications such as QEMU are expected to import kernel UAPI > +headers.
Re: [PATCH 2/2] iommu/iova: Free global iova rcache on iova alloc failure
On Mon, Aug 03, 2020 at 03:30:48PM +0530, Vijayanand Jitta wrote: > ping? Please repost when v5.9-rc1 is released and add Robin Murphy on your Cc list. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
