linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Auger Eric <eric.auger@redhat.com>
To: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>
Cc: "eric.auger.pro@gmail.com" <eric.auger.pro@gmail.com>,
	"iommu@lists.linux-foundation.org"
	<iommu@lists.linux-foundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
	"joro@8bytes.org" <joro@8bytes.org>,
	"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
	"yi.l.liu@linux.intel.com" <yi.l.liu@linux.intel.com>,
	Will Deacon <Will.Deacon@arm.com>,
	Robin Murphy <Robin.Murphy@arm.com>,
	"kevin.tian@intel.com" <kevin.tian@intel.com>,
	"ashok.raj@intel.com" <ashok.raj@intel.com>,
	Marc Zyngier <Marc.Zyngier@arm.com>,
	Christoffer Dall <Christoffer.Dall@arm.com>,
	"peter.maydell@linaro.org" <peter.maydell@linaro.org>,
	Vincent Stehle <Vincent.Stehle@arm.com>
Subject: Re: [PATCH v5 05/22] iommu: Introduce cache_invalidate API
Date: Mon, 18 Mar 2019 13:44:08 +0100	[thread overview]
Message-ID: <e0247f45-dbb7-9be6-90a6-d71475d6e9a3@redhat.com> (raw)
In-Reply-To: <71bec2ed-97ed-d543-7ebd-9fb03c093e77@arm.com>

Hi Jean,

On 3/18/19 12:01 PM, Jean-Philippe Brucker wrote:
> On 17/03/2019 16:43, Auger Eric wrote:
>>>> diff --git a/include/uapi/linux/iommu.h b/include/uapi/linux/iommu.h
>>>> index 532a64075f23..e4c6a447e85a 100644
>>>> --- a/include/uapi/linux/iommu.h
>>>> +++ b/include/uapi/linux/iommu.h
>>>> @@ -159,4 +159,75 @@ struct iommu_pasid_table_config {
>>>>  	};
>>>>  };
>>>>  
>>>> +/* defines the granularity of the invalidation */
>>>> +enum iommu_inv_granularity {
>>>> +	IOMMU_INV_GRANU_DOMAIN,	/* domain-selective
>>>> invalidation */
>>>> +	IOMMU_INV_GRANU_PASID,	/* pasid-selective
>>>> invalidation */
>>>> +	IOMMU_INV_GRANU_ADDR,	/* page-selective invalidation
>>>> */ +};
>>>> +
>>>> +/**
>>>> + * Address Selective Invalidation Structure
>>>> + *
>>>> + * @flags indicates the granularity of the address-selective
>>>> invalidation
>>>> + * - if PASID bit is set, @pasid field is populated and the
>>>> invalidation
>>>> + *   relates to cache entries tagged with this PASID and matching the
>>>> + *   address range.
>>>> + * - if ARCHID bit is set, @archid is populated and the invalidation
>>>> relates
>>>> + *   to cache entries tagged with this architecture specific id and
>>>> matching
>>>> + *   the address range.
>>>> + * - Both PASID and ARCHID can be set as they may tag different
>>>> caches.
>>>> + * - if neither PASID or ARCHID is set, global addr invalidation
>>>> applies
>>>> + * - LEAF flag indicates whether only the leaf PTE caching needs to
>>>> be
>>>> + *   invalidated and other paging structure caches can be preserved.
>>>> + * @pasid: process address space id
>>>> + * @archid: architecture-specific id
>>>> + * @addr: first stage/level input address
>>>> + * @granule_size: page/block size of the mapping in bytes
>>>> + * @nb_granules: number of contiguous granules to be invalidated
>>>> + */
>>>> +struct iommu_inv_addr_info {
>>>> +#define IOMMU_INV_ADDR_FLAGS_PASID	(1 << 0)
>>>> +#define IOMMU_INV_ADDR_FLAGS_ARCHID	(1 << 1)
>>>> +#define IOMMU_INV_ADDR_FLAGS_LEAF	(1 << 2)
>>>> +	__u32	flags;
>>>> +	__u32	archid;
>>>> +	__u64	pasid;
>>>> +	__u64	addr;
>>>> +	__u64	granule_size;
>>>> +	__u64	nb_granules;
>>>> +};
>>>> +
>>>> +/**
>>>> + * First level/stage invalidation information
>>>> + * @cache: bitfield that allows to select which caches to invalidate
>>>> + * @granularity: defines the lowest granularity used for the
>>>> invalidation:
>>>> + *     domain > pasid > addr
>>>> + *
>>>> + * Not all the combinations of cache/granularity make sense:
>>>> + *
>>>> + *         type |   DEV_IOTLB   |     IOTLB     |      PASID    |
>>>> + * granularity	|		|		|
>>>> cache	|
>>>> + * -------------+---------------+---------------+---------------+
>>>> + * DOMAIN	|	N/A	|       Y	|
>>>> Y	|
>>>> + * PASID	|	Y	|       Y	|
>>>> Y	|
>>>> + * ADDR		|       Y	|       Y	|
>>>> N/A	|
>>>> + */
>>>> +struct iommu_cache_invalidate_info {
>>>> +#define IOMMU_CACHE_INVALIDATE_INFO_VERSION_1 1
>>>> +	__u32	version;
>>>> +/* IOMMU paging structure cache */
>>>> +#define IOMMU_CACHE_INV_TYPE_IOTLB	(1 << 0) /* IOMMU IOTLB */
>>>> +#define IOMMU_CACHE_INV_TYPE_DEV_IOTLB	(1 << 1) /* Device
>>>> IOTLB */ +#define IOMMU_CACHE_INV_TYPE_PASID	(1 << 2) /* PASID
>>>> cache */
>>>> +	__u8	cache;
>>>> +	__u8	granularity;
>>>> +	__u8	padding[2];
>>>> +	union {
>>>> +		__u64	pasid;
>>> just realized there is already a pasid field in the addr_info, do we
>>> still need this?
>> I think so. Either you do a PASID based invalidation and you directly
>> use the pasid field or you do an address based invalidation and you use
>> the addr_info where the pasid may or not be passed.
> 
> I guess a comment would be useful?
> 
>     - Invalidations by %IOMMU_INV_GRANU_ADDR use field @addr_info.
>     - Invalidations by %IOMMU_INV_GRANU_PASID use field @pasid.
>     - Invalidations by %IOMMU_INV_GRANU_DOMAIN don't take an argument.

OK. I will add those comments in v7.

Thanks

Eric
> 
> Thanks,
> Jean
> 
>>
>> Thanks
>>
>> Eric
>>>> +		struct iommu_inv_addr_info addr_info;
>>>> +	};
>>>> +};
>>>> +
>>>> +
>>>>  #endif /* _UAPI_IOMMU_H */
>>>
>>> [Jacob Pan]
>>>
> 

  reply	other threads:[~2019-03-18 12:44 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-15 16:08 [PATCH v5 00/22] SMMUv3 Nested Stage Setup Eric Auger
2019-03-15 16:08 ` [PATCH v5 01/22] driver core: add per device iommu param Eric Auger
2019-03-15 16:08 ` [PATCH v5 02/22] iommu: introduce device fault data Eric Auger
2019-03-15 16:08 ` [PATCH v5 03/22] iommu: introduce device fault report API Eric Auger
2019-03-15 16:08 ` [PATCH v5 04/22] iommu: Introduce attach/detach_pasid_table API Eric Auger
2019-03-15 16:08 ` [PATCH v5 05/22] iommu: Introduce cache_invalidate API Eric Auger
2019-03-15 18:37   ` Jacob Pan
2019-03-17 16:43     ` Auger Eric
2019-03-18 11:01       ` Jean-Philippe Brucker
2019-03-18 12:44         ` Auger Eric [this message]
2019-03-15 16:08 ` [PATCH v5 06/22] iommu: Introduce bind/unbind_guest_msi Eric Auger
2019-03-15 16:08 ` [PATCH v5 07/22] vfio: VFIO_IOMMU_ATTACH/DETACH_PASID_TABLE Eric Auger
2019-03-15 16:08 ` [PATCH v5 08/22] vfio: VFIO_IOMMU_CACHE_INVALIDATE Eric Auger
2019-03-15 16:08 ` [PATCH v5 09/22] vfio: VFIO_IOMMU_BIND/UNBIND_MSI Eric Auger
2019-03-15 16:08 ` [PATCH v5 10/22] iommu/arm-smmu-v3: Link domains and devices Eric Auger
2019-03-15 16:08 ` [PATCH v5 11/22] iommu/arm-smmu-v3: Maintain a SID->device structure Eric Auger
2019-03-15 16:08 ` [PATCH v5 12/22] iommu/smmuv3: Get prepared for nested stage support Eric Auger
2019-03-15 16:08 ` [PATCH v5 13/22] iommu/smmuv3: Implement attach/detach_pasid_table Eric Auger
2019-03-15 16:08 ` [PATCH v5 14/22] iommu/smmuv3: Implement cache_invalidate Eric Auger
2019-03-15 16:08 ` [PATCH v5 15/22] dma-iommu: Implement NESTED_MSI cookie Eric Auger
2019-03-15 16:09 ` [PATCH v5 16/22] iommu/smmuv3: Implement bind/unbind_guest_msi Eric Auger
2019-03-15 16:09 ` [PATCH v5 17/22] iommu/smmuv3: Report non recoverable faults Eric Auger
2019-03-15 16:09 ` [PATCH v5 18/22] vfio-pci: Add a new VFIO_REGION_TYPE_NESTED region type Eric Auger
2019-03-15 16:09 ` [PATCH v5 19/22] vfio-pci: Register an iommu fault handler Eric Auger
2019-03-15 16:09 ` [PATCH v5 20/22] vfio_pci: Allow to mmap the fault queue Eric Auger
2019-03-15 16:09 ` [PATCH v5 21/22] vfio-pci: Add VFIO_PCI_DMA_FAULT_IRQ_INDEX Eric Auger
2019-03-15 16:09 ` [PATCH v5 22/22] vfio: Document nested stage control Eric Auger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e0247f45-dbb7-9be6-90a6-d71475d6e9a3@redhat.com \
    --to=eric.auger@redhat.com \
    --cc=Christoffer.Dall@arm.com \
    --cc=Marc.Zyngier@arm.com \
    --cc=Robin.Murphy@arm.com \
    --cc=Vincent.Stehle@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=eric.auger.pro@gmail.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=jean-philippe.brucker@arm.com \
    --cc=joro@8bytes.org \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter.maydell@linaro.org \
    --cc=yi.l.liu@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).