Date:   Thu, 9 Dec 2021 11:40:46 -0400
From:   Jason Gunthorpe <jgg@nvidia.com>
To:     Eric Auger <eric.auger@redhat.com>
Cc:     Jean-Philippe Brucker <jean-philippe@linaro.org>,
        Lu Baolu <baolu.lu@linux.intel.com>,
        Joerg Roedel <joro@8bytes.org>, peter.maydell@linaro.org,
        kvm@vger.kernel.org, vivek.gautam@arm.com,
        kvmarm@lists.cs.columbia.edu, eric.auger.pro@gmail.com,
        ashok.raj@intel.com, maz@kernel.org, vsethi@nvidia.com,
        zhangfei.gao@linaro.org, kevin.tian@intel.com, will@kernel.org,
        alex.williamson@redhat.com, wangxingang5@huawei.com,
        linux-kernel@vger.kernel.org, lushenming@huawei.com,
        iommu@lists.linux-foundation.org, robin.murphy@arm.com
Subject: Re: [RFC v16 1/9] iommu: Introduce attach/detach_pasid_table API
Message-ID: <20211209154046.GQ6385@nvidia.com>
References: <20211027104428.1059740-1-eric.auger@redhat.com>
 <20211027104428.1059740-2-eric.auger@redhat.com>
 <Ya3qd6mT/DpceSm8@8bytes.org>
 <c7e26722-f78c-a93f-c425-63413aa33dde@redhat.com>
 <e6733c59-ffcb-74d4-af26-273c1ae8ce68@linux.intel.com>
 <fbeabcff-a6d4-dcc5-6687-7b32d6358fe3@redhat.com>
 <20211208125616.GN6385@nvidia.com>
 <YbDpZ0pf7XeZcc7z@myrica>
 <20211208183102.GD6385@nvidia.com>
 <b576084b-482f-bcb7-35a6-d786dbb305e1@redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <b576084b-482f-bcb7-35a6-d786dbb305e1@redhat.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?AmWECveVl0khzBIjkYpqVgvDp6aacsV5FLTpnaK5yY7wpjN4KG/1skL71DrM?=
 =?us-ascii?Q?Se4PBknmKJ34u0r6qoa8OV+oBkE24nXyxNgEHctbrNrYz5ihJ313wSRbFGxg?=
 =?us-ascii?Q?+ZG3lNQXkmnJyTIVksChBoPM0qPQt9EXmd5DiyYFIZOpiX7tCsX85n7LmQRh?=
 =?us-ascii?Q?U8Dsj3QHgqZ5Wi7dij/Wwqz7Zr3hJAA3yM/I2M/ArW6fxSgCn0ojcUeNhJTK?=
 =?us-ascii?Q?zSQvAeeWML7fGJRIZITslkfBdxIXWlN9ENLr8josQxCnWyBIJpZLeOI/D1vK?=
 =?us-ascii?Q?xBskEdBfMOqPXkg/oWxYBXwVFrSIH72BswRyqwTzE8Peqqd8/cjjorUqk++n?=
 =?us-ascii?Q?4ZE2x9hqjiC+nUF8yKhW/VKOgUbw9varhsu20FTMujWQgZKDFWcuX+JRaBYs?=
 =?us-ascii?Q?PCCsaNHJW1RUr4qutymkNu93x4kbgn06O9fAXdcxc0cRmhqx2E+SkcF11kcq?=
 =?us-ascii?Q?ScWa9/5TcakLBno/1z0PDXaWXf0zVjvO9kqiuV9S6tLVmL5yo8Mb9+AQ0gNV?=
 =?us-ascii?Q?5JWfjc8ef1rLRXQSY2qppN7pHtnx9Y8E2TQDX3Favzq8e+FVc/55HpQtu7xO?=
 =?us-ascii?Q?brKXeBYgHO4LiFMVXG49ViWitOuJZ4f9BkgMc+2rOa21uwwoQEXNTel4lsha?=
 =?us-ascii?Q?3eSHMvFuNEb4W/dpcKzIo2eiKPaWH17UNQu1wV25btP+qxQTMGwemKCazB/i?=
 =?us-ascii?Q?8sTI7P03ObAbTvK+36AVhwHKDdnmRBWs15UlMdILHPdry9Zm76veQASED4OS?=
 =?us-ascii?Q?W1V1H/glVGSrugys2M5P8JbPFqUwSqTJCkO8pl+hspMZvIRJnMH0b1vpHfdt?=
 =?us-ascii?Q?E12/U6r8meBnRzcFuMJ8gLqJhWeGP5soC0mbZhPUW8ncBwmxQhR7+U97RmTT?=
 =?us-ascii?Q?3K94oiCI+QeHnnmvq5XRilXdpIZbi3bk4d5Zh0v/hm1U6VhaULCVpi7P0yM6?=
 =?us-ascii?Q?qzt4DtLxqz0/ss8AHwMm1EK3J0eYQHCzzSUMETJ4pQoIP9VZ4G/eR8AuVx3+?=
 =?us-ascii?Q?ORevJ/23BEj6UXQKHBu7X6XoDaTKQBPEbsdgRq0Pn4DE2i8Uac216urzZ11+?=
 =?us-ascii?Q?1RXeffuZy3+eaETxy7dgag5IBQFT2dHfoeC55/ziyahKs5W9aGTSV/lqD+ur?=
 =?us-ascii?Q?k2qaoUaUdMV11dR4O8jsv3/UmzkkL/5qBG/nnJBKXb/qBZaP1aQPiAdQTN2u?=
 =?us-ascii?Q?XRJYXZYzMowIrXithBgo/xjZmdzZC1HD6D70aztggQaNmVCoG9Xkg2PIxlWy?=
 =?us-ascii?Q?REmxZOOtnIYjTFWUJoV3LFOOFttuqJwi5DXZxjgKdtwoPp9tK37+2JwPJ2ts?=
 =?us-ascii?Q?nYzwK2Ov3Ocj+zVRerI4EZNYZQ2oDyNxpU/YBR5wsBNiYnJkqWg5MbkhfEhX?=
 =?us-ascii?Q?nnqHa8vB+JfIT514Tx7DY40v+kxGcNnWPISk4MnW7I4w3s0IxztxbjZvpPYb?=
 =?us-ascii?Q?ealwf3oOSsb0+X+bLZ1Oz3FUPhJgV1qFWwbyJmFXbayC8AWNIm/AKXaNdETW?=
 =?us-ascii?Q?DFaYlghbCJD3VIH4N0Bu7DIm1XJgWdT0Euca1wQ2Be4eRuIFRV7aOgEeKEYn?=
 =?us-ascii?Q?xXvHh9BEI4pde5RSXBk=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c4c0ec46-88a6-4a6e-6649-08d9bb2a4520
X-MS-Exchange-CrossTenant-AuthSource: BL0PR12MB5506.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Dec 2021 15:40:47.4294
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: 7hjE6hRRaHC6txDwQsYkggU8ETG1B/onPG84QW6DyTSaDTPkYQ8YZEWW8ogYMcYu
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL1PR12MB5030
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Dec 09, 2021 at 08:50:04AM +0100, Eric Auger wrote:

> > The kernel API should accept the S1ContextPtr IPA and all the parts of
> > the STE that relate to the defining the layout of what the S1Context
> > points to an thats it.

> Yes that's exactly what is done currently. At config time the host must
> trap guest STE changes (format and S1ContextPtr) and "incorporate" those
> changes into the stage2 related STE information. The STE is owned by the
> host kernel as it contains the stage2 information (S2TTB).

[..]

> Note this series only coped with a single CD in the Context Descriptor
> Table.

I'm confused, where does this limit arise?

The kernel accepts as input all the bits in the STE that describe the
layout of the CDT owned by userspace, shouldn't userspace be able to
construct all forms of CDT with any number of CDs in them?

Or do you mean this is some qemu limitation?

Jason