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]
Message-ID: <dd7eb37f-13c6-4c6e-8adc-954ad9974b93@linux.intel.com>
Date: Tue, 22 Oct 2024 16:59:07 +0800
From: Baolu Lu <baolu.lu@...ux.intel.com>
To: Nicolin Chen <nicolinc@...dia.com>
Cc: baolu.lu@...ux.intel.com, jgg@...dia.com, kevin.tian@...el.com,
 will@...nel.org, joro@...tes.org, suravee.suthikulpanit@....com,
 robin.murphy@....com, dwmw2@...radead.org, shuah@...nel.org,
 linux-kernel@...r.kernel.org, iommu@...ts.linux.dev,
 linux-arm-kernel@...ts.infradead.org, linux-kselftest@...r.kernel.org,
 eric.auger@...hat.com, jean-philippe@...aro.org, mdf@...nel.org,
 mshavit@...gle.com, shameerali.kolothum.thodi@...wei.com,
 smostafa@...gle.com, yi.l.liu@...el.com, aik@....com,
 zhangfei.gao@...aro.org, patches@...ts.linux.dev
Subject: Re: [PATCH v4 02/11] iommufd: Introduce IOMMUFD_OBJ_VIOMMU and its
 related struct

On 2024/10/22 12:40, Nicolin Chen wrote:
> On Tue, Oct 22, 2024 at 10:28:30AM +0800, Baolu Lu wrote:
>> On 2024/10/22 8:19, Nicolin Chen wrote:
>>> + * @viommu_alloc: Allocate an iommufd_viommu on a physical IOMMU instance behind
>>> + *                the @dev, as the set of virtualization resources shared/passed
>>> + *                to user space IOMMU instance. And associate it with a nesting
>>> + *                @parent_domain. The @viommu_type must be defined in the header
>>> + *                include/uapi/linux/iommufd.h
>>> + *                It is suggested to call iommufd_viommu_alloc() helper for
>>> + *                a bundled allocation of the core and the driver structures,
>>> + *                using the given @ictx pointer.
>>>     * @pgsize_bitmap: bitmap of all possible supported page sizes
>>>     * @owner: Driver module providing these ops
>>>     * @identity_domain: An always available, always attachable identity
>>> @@ -591,6 +601,10 @@ struct iommu_ops {
>>>        void (*remove_dev_pasid)(struct device *dev, ioasid_t pasid,
>>>                                 struct iommu_domain *domain);
>>>
>>> +     struct iommufd_viommu *(*viommu_alloc)(
>>> +             struct device *dev, struct iommu_domain *parent_domain,
>>> +             struct iommufd_ctx *ictx, unsigned int viommu_type);
>> Is the vIOMMU object limited to a parent domain?
> Yes, for each vIOMMU (a slice of physical IOMMU per VM), one S2
> parent domain is enough. Typically, it has the mappings between
> gPAs and hPAs. If its format/compatibility allows, this single
> parent domain can be shared with other vIOMMUs.

Is it feasible to make vIOMMU object more generic, rather than strictly
tying it to nested translation? For example, a normal paging domain that
translates gPAs to hPAs could also have a vIOMMU object associated with
it.

While we can only support vIOMMU object allocation uAPI for S2 paging
domains in the context of this series, we could consider leaving the
option open to associate a vIOMMU object with other normal paging
domains that are not a nested parent?

Thanks,
baolu

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ