linux-kernel - Re: [PATCH v2 01/16] iommu: introduce bind_pasid

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 10 Oct 2017 14:32:14 -0700
From:   Jacob Pan <jacob.jun.pan@...ux.intel.com>
To:     Joerg Roedel <joro@...tes.org>
Cc:     iommu@...ts.linux-foundation.org,
        LKML <linux-kernel@...r.kernel.org>,
        David Woodhouse <dwmw2@...radead.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rafael Wysocki <rafael.j.wysocki@...el.com>,
        Jean-Philippe Brucker <jean-philippe.brucker@....com>,
        "Liu, Yi L" <yi.l.liu@...el.com>,
        Lan Tianyu <tianyu.lan@...el.com>,
        "Tian, Kevin" <kevin.tian@...el.com>,
        Raj Ashok <ashok.raj@...el.com>,
        Alex Williamson <alex.williamson@...hat.com>, Liu@...tes.org,
        Yi L <yi.l.liu@...ux.intel.com>, jacob.jun.pan@...ux.intel.com
Subject: Re: [PATCH v2 01/16] iommu: introduce bind_pasid_table API function

On Tue, 10 Oct 2017 15:14:33 +0200
Joerg Roedel <joro@...tes.org> wrote:

> Hi Jacob,
> 
> On Thu, Oct 05, 2017 at 04:03:29PM -0700, Jacob Pan wrote:
> > +int iommu_unbind_pasid_table(struct iommu_domain *domain, struct
> > device *dev) +{
> > +	if (unlikely(!domain->ops->unbind_pasid_table))
> > +		return -EINVAL;
> > +
> > +	return domain->ops->unbind_pasid_table(domain, dev);
> > +}
> > +EXPORT_SYMBOL_GPL(iommu_unbind_pasid_table);  
> 
> Are there other reasons to let the unbind fail? Otherwise I'd suggest
> to just make this a void function. Also not sure what the user of this
> function should do when the unbind really fails.
> 
Agreed, void should do. There is no action for the callers.
> > +enum pasid_table_model {
> > +	PASID_TABLE_FORMAT_HOST,  
> 
> What is this FORMAT_HOST for?
> 
I was thinking it indicates whatever the host format is, if the guest
does not care.
> > +	PASID_TABLE_FORMAT_ARM_1LVL,
> > +	PASID_TABLE_FORMAT_ARM_2LVL,
> > +	PASID_TABLE_FORMAT_AMD,
> > +	PASID_TABLE_FORMAT_INTEL,
> > +};
> > +
> > +/**
> > + * PASID table data used to bind guest PASID table to the host
> > IOMMU. This will
> > + * enable guest managed first level page tables.
> > + * @version: for future extensions and identification of the data
> > format
> > + * @bytes: size of this structure
> > + * @base_ptr:	PASID table pointer
> > + * @pasid_bits:	number of bits supported in the guest PASID
> > table, must be less
> > + *		or equal than the host table size.
> > + * @model:	PASID table format for different IOMMU models
> > + */
> > +struct pasid_table_config {
> > +	__u32 version;  
> 
> Can you also add a define for the version number? Userspace needs it
> to initialize the struct and the kernel to check against it.
> 
Good point.
> > +	__u32 bytes;
> > +	__u64 base_ptr;
> > +	__u8 pasid_bits;
> > +	enum pasid_table_model model;
> > +	union {
> > +		struct {
> > +			/* Intel specific fields */
> > +		} intel;
> > +
> > +		struct {
> > +			/* ARM specific fields */
> > +			bool pasid0_dma_no_pasid;
> > +		} arm;
> > +
> > +		struct {
> > +			/* AMD specific fields */
> > +		} amd;  
> 
> Thinking more about this, we can omit the sub-structs for models that
> don't need them. For the amd-model for example the base_ptr and
> pasid_bits fields are sufficient.
> 
> 
Sounds good, we can always add later and bump up the version. Intel does
not need model data for now.
> Regards,
> 
> 	Joerg

[Jacob Pan]