All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhangfei Gao <zhangfei.gao@linaro.org>
To: Jason Gunthorpe <jgg@nvidia.com>, Robin Murphy <robin.murphy@arm.com>
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>,
	kvm@vger.kernel.org, Vivek Kumar Gautam <Vivek.Gautam@arm.com>,
	Cornelia Huck <cohuck@redhat.com>,
	iommu@lists.linux-foundation.org,
	Alex Williamson <alex.williamson@redhat.com>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] vfio: Remove VFIO_TYPE1_NESTING_IOMMU
Date: Thu, 12 May 2022 15:07:09 +0800	[thread overview]
Message-ID: <6c6f3ecb-6339-4093-a15a-fcf95a7c61fb@linaro.org> (raw)
In-Reply-To: <20220510181327.GM49344@nvidia.com>

Hi, Jason

On 2022/5/11 上午2:13, Jason Gunthorpe via iommu wrote:
> On Tue, May 10, 2022 at 06:52:06PM +0100, Robin Murphy wrote:
>> On 2022-05-10 17:55, Jason Gunthorpe via iommu wrote:
>>> This control causes the ARM SMMU drivers to choose a stage 2
>>> implementation for the IO pagetable (vs the stage 1 usual default),
>>> however this choice has no visible impact to the VFIO user. Further qemu
>>> never implemented this and no other userspace user is known.
>>>
>>> The original description in commit f5c9ecebaf2a ("vfio/iommu_type1: add
>>> new VFIO_TYPE1_NESTING_IOMMU IOMMU type") suggested this was to "provide
>>> SMMU translation services to the guest operating system" however the rest
>>> of the API to set the guest table pointer for the stage 1 was never
>>> completed, or at least never upstreamed, rendering this part useless dead
>>> code.
>>>
>>> Since the current patches to enable nested translation, aka userspace page
>>> tables, rely on iommufd and will not use the enable_nesting()
>>> iommu_domain_op, remove this infrastructure. However, don't cut too deep
>>> into the SMMU drivers for now expecting the iommufd work to pick it up -
>>> we still need to create S2 IO page tables.
>>>
>>> Remove VFIO_TYPE1_NESTING_IOMMU and everything under it including the
>>> enable_nesting iommu_domain_op.
>>>
>>> Just in-case there is some userspace using this continue to treat
>>> requesting it as a NOP, but do not advertise support any more.
>> I assume the nested translation/guest SVA patches that Eric and Vivek were
>> working on pre-IOMMUFD made use of this, and given that they got quite far
>> along, I wouldn't be too surprised if some eager cloud vendors might have
>> even deployed something based on the patches off the list.
> With upstream there is no way to make use of this flag, if someone is
> using it they have other out of tree kernel, vfio, kvm and qemu
> patches to make it all work.
>
> You can see how much is still needed in Eric's tree:
>
> https://github.com/eauger/linux/commits/v5.15-rc7-nested-v16
>
>> I can't help feeling a little wary about removing this until IOMMUFD
>> can actually offer a functional replacement - is it in the way of
>> anything upcoming?
>  From an upstream perspective if someone has a patched kernel to
> complete the feature, then they can patch this part in as well, we
> should not carry dead code like this in the kernel and in the uapi.
>
> It is not directly in the way, but this needs to get done at some
> point, I'd rather just get it out of the way.

We are using this interface for nested mode.

Is the replacing patch ready?
Can we remove this until submitting the new one?

Thanks


WARNING: multiple messages have this Message-ID (diff)
From: Zhangfei Gao <zhangfei.gao@linaro.org>
To: Jason Gunthorpe <jgg@nvidia.com>, Robin Murphy <robin.murphy@arm.com>
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>,
	kvm@vger.kernel.org, Cornelia Huck <cohuck@redhat.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	Vivek Kumar Gautam <Vivek.Gautam@arm.com>,
	iommu@lists.linux-foundation.org, Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] vfio: Remove VFIO_TYPE1_NESTING_IOMMU
Date: Thu, 12 May 2022 15:07:09 +0800	[thread overview]
Message-ID: <6c6f3ecb-6339-4093-a15a-fcf95a7c61fb@linaro.org> (raw)
In-Reply-To: <20220510181327.GM49344@nvidia.com>

Hi, Jason

On 2022/5/11 上午2:13, Jason Gunthorpe via iommu wrote:
> On Tue, May 10, 2022 at 06:52:06PM +0100, Robin Murphy wrote:
>> On 2022-05-10 17:55, Jason Gunthorpe via iommu wrote:
>>> This control causes the ARM SMMU drivers to choose a stage 2
>>> implementation for the IO pagetable (vs the stage 1 usual default),
>>> however this choice has no visible impact to the VFIO user. Further qemu
>>> never implemented this and no other userspace user is known.
>>>
>>> The original description in commit f5c9ecebaf2a ("vfio/iommu_type1: add
>>> new VFIO_TYPE1_NESTING_IOMMU IOMMU type") suggested this was to "provide
>>> SMMU translation services to the guest operating system" however the rest
>>> of the API to set the guest table pointer for the stage 1 was never
>>> completed, or at least never upstreamed, rendering this part useless dead
>>> code.
>>>
>>> Since the current patches to enable nested translation, aka userspace page
>>> tables, rely on iommufd and will not use the enable_nesting()
>>> iommu_domain_op, remove this infrastructure. However, don't cut too deep
>>> into the SMMU drivers for now expecting the iommufd work to pick it up -
>>> we still need to create S2 IO page tables.
>>>
>>> Remove VFIO_TYPE1_NESTING_IOMMU and everything under it including the
>>> enable_nesting iommu_domain_op.
>>>
>>> Just in-case there is some userspace using this continue to treat
>>> requesting it as a NOP, but do not advertise support any more.
>> I assume the nested translation/guest SVA patches that Eric and Vivek were
>> working on pre-IOMMUFD made use of this, and given that they got quite far
>> along, I wouldn't be too surprised if some eager cloud vendors might have
>> even deployed something based on the patches off the list.
> With upstream there is no way to make use of this flag, if someone is
> using it they have other out of tree kernel, vfio, kvm and qemu
> patches to make it all work.
>
> You can see how much is still needed in Eric's tree:
>
> https://github.com/eauger/linux/commits/v5.15-rc7-nested-v16
>
>> I can't help feeling a little wary about removing this until IOMMUFD
>> can actually offer a functional replacement - is it in the way of
>> anything upcoming?
>  From an upstream perspective if someone has a patched kernel to
> complete the feature, then they can patch this part in as well, we
> should not carry dead code like this in the kernel and in the uapi.
>
> It is not directly in the way, but this needs to get done at some
> point, I'd rather just get it out of the way.

We are using this interface for nested mode.

Is the replacing patch ready?
Can we remove this until submitting the new one?

Thanks

_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

WARNING: multiple messages have this Message-ID (diff)
From: Zhangfei Gao <zhangfei.gao@linaro.org>
To: Jason Gunthorpe <jgg@nvidia.com>, Robin Murphy <robin.murphy@arm.com>
Cc: Jean-Philippe Brucker <jean-philippe@linaro.org>,
	kvm@vger.kernel.org, Vivek Kumar Gautam <Vivek.Gautam@arm.com>,
	Cornelia Huck <cohuck@redhat.com>,
	iommu@lists.linux-foundation.org,
	Alex Williamson <alex.williamson@redhat.com>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] vfio: Remove VFIO_TYPE1_NESTING_IOMMU
Date: Thu, 12 May 2022 15:07:09 +0800	[thread overview]
Message-ID: <6c6f3ecb-6339-4093-a15a-fcf95a7c61fb@linaro.org> (raw)
In-Reply-To: <20220510181327.GM49344@nvidia.com>

Hi, Jason

On 2022/5/11 上午2:13, Jason Gunthorpe via iommu wrote:
> On Tue, May 10, 2022 at 06:52:06PM +0100, Robin Murphy wrote:
>> On 2022-05-10 17:55, Jason Gunthorpe via iommu wrote:
>>> This control causes the ARM SMMU drivers to choose a stage 2
>>> implementation for the IO pagetable (vs the stage 1 usual default),
>>> however this choice has no visible impact to the VFIO user. Further qemu
>>> never implemented this and no other userspace user is known.
>>>
>>> The original description in commit f5c9ecebaf2a ("vfio/iommu_type1: add
>>> new VFIO_TYPE1_NESTING_IOMMU IOMMU type") suggested this was to "provide
>>> SMMU translation services to the guest operating system" however the rest
>>> of the API to set the guest table pointer for the stage 1 was never
>>> completed, or at least never upstreamed, rendering this part useless dead
>>> code.
>>>
>>> Since the current patches to enable nested translation, aka userspace page
>>> tables, rely on iommufd and will not use the enable_nesting()
>>> iommu_domain_op, remove this infrastructure. However, don't cut too deep
>>> into the SMMU drivers for now expecting the iommufd work to pick it up -
>>> we still need to create S2 IO page tables.
>>>
>>> Remove VFIO_TYPE1_NESTING_IOMMU and everything under it including the
>>> enable_nesting iommu_domain_op.
>>>
>>> Just in-case there is some userspace using this continue to treat
>>> requesting it as a NOP, but do not advertise support any more.
>> I assume the nested translation/guest SVA patches that Eric and Vivek were
>> working on pre-IOMMUFD made use of this, and given that they got quite far
>> along, I wouldn't be too surprised if some eager cloud vendors might have
>> even deployed something based on the patches off the list.
> With upstream there is no way to make use of this flag, if someone is
> using it they have other out of tree kernel, vfio, kvm and qemu
> patches to make it all work.
>
> You can see how much is still needed in Eric's tree:
>
> https://github.com/eauger/linux/commits/v5.15-rc7-nested-v16
>
>> I can't help feeling a little wary about removing this until IOMMUFD
>> can actually offer a functional replacement - is it in the way of
>> anything upcoming?
>  From an upstream perspective if someone has a patched kernel to
> complete the feature, then they can patch this part in as well, we
> should not carry dead code like this in the kernel and in the uapi.
>
> It is not directly in the way, but this needs to get done at some
> point, I'd rather just get it out of the way.

We are using this interface for nested mode.

Is the replacing patch ready?
Can we remove this until submitting the new one?

Thanks


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-05-12  7:07 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-10 16:55 [PATCH] vfio: Remove VFIO_TYPE1_NESTING_IOMMU Jason Gunthorpe
2022-05-10 16:55 ` Jason Gunthorpe
2022-05-10 16:55 ` Jason Gunthorpe via iommu
2022-05-10 17:52 ` Robin Murphy
2022-05-10 17:52   ` Robin Murphy
2022-05-10 17:52   ` Robin Murphy
2022-05-10 18:13   ` Jason Gunthorpe via iommu
2022-05-10 18:13     ` Jason Gunthorpe
2022-05-10 18:13     ` Jason Gunthorpe
2022-05-12  7:07     ` Zhangfei Gao [this message]
2022-05-12  7:07       ` Zhangfei Gao
2022-05-12  7:07       ` Zhangfei Gao
2022-05-12 11:32       ` Jason Gunthorpe
2022-05-12 11:32         ` Jason Gunthorpe
2022-05-12 11:32         ` Jason Gunthorpe via iommu
2022-05-12 11:57         ` zhangfei.gao
2022-05-12 11:57           ` zhangfei.gao
2022-05-12 11:57           ` zhangfei.gao
2022-05-12 11:59           ` Jason Gunthorpe
2022-05-12 11:59             ` Jason Gunthorpe
2022-05-12 11:59             ` Jason Gunthorpe via iommu
2022-05-12 12:07             ` zhangfei.gao
2022-05-12 12:07               ` zhangfei.gao
2022-05-12 12:07               ` zhangfei.gao
2022-05-12 17:27     ` Eric Auger
2022-05-12 17:27       ` Eric Auger
2022-05-12 17:27       ` Eric Auger
2022-05-10 18:31 ` Nicolin Chen
2022-05-10 18:31   ` Nicolin Chen
2022-05-10 18:31   ` Nicolin Chen via iommu
2022-05-12  5:04 ` Tian, Kevin
2022-05-12  5:04   ` Tian, Kevin
2022-05-12  5:04   ` Tian, Kevin
2022-05-16  6:39 ` Christoph Hellwig
2022-05-16  6:39   ` Christoph Hellwig
2022-05-16  6:39   ` Christoph Hellwig
2022-05-17 20:26 ` Alex Williamson
2022-05-17 20:26   ` Alex Williamson
2022-05-17 20:26   ` Alex Williamson
2022-05-20  7:38   ` Joerg Roedel
2022-05-20  7:38     ` Joerg Roedel
2022-05-20  7:38     ` Joerg Roedel
2022-05-20 11:02 ` Robin Murphy
2022-05-20 11:02   ` Robin Murphy
2022-05-20 11:02   ` Robin Murphy
2022-05-20 12:00   ` Will Deacon
2022-05-20 12:00     ` Will Deacon
2022-05-20 12:00     ` Will Deacon
2022-05-20 12:28     ` Jason Gunthorpe
2022-05-20 12:28       ` Jason Gunthorpe
2022-05-20 12:28       ` Jason Gunthorpe via iommu
2022-05-20 12:18   ` Jason Gunthorpe
2022-05-20 12:18     ` Jason Gunthorpe
2022-05-20 12:18     ` Jason Gunthorpe via iommu

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=6c6f3ecb-6339-4093-a15a-fcf95a7c61fb@linaro.org \
    --to=zhangfei.gao@linaro.org \
    --cc=Vivek.Gautam@arm.com \
    --cc=alex.williamson@redhat.com \
    --cc=cohuck@redhat.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jean-philippe@linaro.org \
    --cc=jgg@nvidia.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=robin.murphy@arm.com \
    --cc=will@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.