From: Shenming Lu <lushenming@huawei.com>
To: Alex Williamson <alex.williamson@redhat.com>,
Lu Baolu <baolu.lu@linux.intel.com>
Cc: Eric Auger <eric.auger@redhat.com>,
Cornelia Huck <cohuck@redhat.com>, Will Deacon <will@kernel.org>,
Robin Murphy <robin.murphy@arm.com>,
"Joerg Roedel" <joro@8bytes.org>,
Jean-Philippe Brucker <jean-philippe@linaro.org>,
<kvm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<iommu@lists.linux-foundation.org>, <linux-api@vger.kernel.org>,
Kevin Tian <kevin.tian@intel.com>, <yi.l.liu@intel.com>,
Christoph Hellwig <hch@infradead.org>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Barry Song <song.bao.hua@hisilicon.com>,
<wanghaibin.wang@huawei.com>, <yuzenghui@huawei.com>
Subject: Re: [RFC PATCH v3 8/8] vfio: Add nested IOPF support
Date: Thu, 27 May 2021 19:03:14 +0800 [thread overview]
Message-ID: <90b00e7d-7934-ee79-7643-e2949e2d3af4@huawei.com> (raw)
In-Reply-To: <20210524161129.085503ad@x1.home.shazbot.org>
On 2021/5/25 6:11, Alex Williamson wrote:
> On Mon, 24 May 2021 21:11:11 +0800
> Shenming Lu <lushenming@huawei.com> wrote:
>
>> On 2021/5/21 15:59, Shenming Lu wrote:
>>> On 2021/5/19 2:58, Alex Williamson wrote:
>>>> On Fri, 9 Apr 2021 11:44:20 +0800
>>>> Shenming Lu <lushenming@huawei.com> wrote:
>>>>
>>>>> To set up nested mode, drivers such as vfio_pci need to register a
>>>>> handler to receive stage/level 1 faults from the IOMMU, but since
>>>>> currently each device can only have one iommu dev fault handler,
>>>>> and if stage 2 IOPF is already enabled (VFIO_IOMMU_ENABLE_IOPF),
>>>>> we choose to update the registered handler (a consolidated one) via
>>>>> flags (set FAULT_REPORT_NESTED_L1), and further deliver the received
>>>>> stage 1 faults in the handler to the guest through a newly added
>>>>> vfio_device_ops callback.
>>>>
>>>> Are there proposed in-kernel drivers that would use any of these
>>>> symbols?
>>>
>>> I hope that such as Eric's SMMUv3 Nested Stage Setup series [1] can
>>> use these symbols to consolidate the two page fault handlers into one.
>>>
>>> [1] https://patchwork.kernel.org/project/kvm/cover/20210411114659.15051-1-eric.auger@redhat.com/
>>>
>>>>
>>>>> Signed-off-by: Shenming Lu <lushenming@huawei.com>
>>>>> ---
>>>>> drivers/vfio/vfio.c | 81 +++++++++++++++++++++++++++++++++
>>>>> drivers/vfio/vfio_iommu_type1.c | 49 +++++++++++++++++++-
>>>>> include/linux/vfio.h | 12 +++++
>>>>> 3 files changed, 141 insertions(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
>>>>> index 44c8dfabf7de..4245f15914bf 100644
>>>>> --- a/drivers/vfio/vfio.c
>>>>> +++ b/drivers/vfio/vfio.c
>>>>> @@ -2356,6 +2356,87 @@ struct iommu_domain *vfio_group_iommu_domain(struct vfio_group *group)
>>>>> }
>>>>> EXPORT_SYMBOL_GPL(vfio_group_iommu_domain);
>>>>>
>>>>> +/*
>>>>> + * Register/Update the VFIO IOPF handler to receive
>>>>> + * nested stage/level 1 faults.
>>>>> + */
>>>>> +int vfio_iommu_dev_fault_handler_register_nested(struct device *dev)
>>>>> +{
>>>>> + struct vfio_container *container;
>>>>> + struct vfio_group *group;
>>>>> + struct vfio_iommu_driver *driver;
>>>>> + int ret;
>>>>> +
>>>>> + if (!dev)
>>>>> + return -EINVAL;
>>>>> +
>>>>> + group = vfio_group_get_from_dev(dev);
>>>>> + if (!group)
>>>>> + return -ENODEV;
>>>>> +
>>>>> + ret = vfio_group_add_container_user(group);
>>>>> + if (ret)
>>>>> + goto out;
>>>>> +
>>>>> + container = group->container;
>>>>> + driver = container->iommu_driver;
>>>>> + if (likely(driver && driver->ops->register_handler))
>>>>> + ret = driver->ops->register_handler(container->iommu_data, dev);
>>>>> + else
>>>>> + ret = -ENOTTY;
>>>>> +
>>>>> + vfio_group_try_dissolve_container(group);
>>>>> +
>>>>> +out:
>>>>> + vfio_group_put(group);
>>>>> + return ret;
>>>>> +}
>>>>> +EXPORT_SYMBOL_GPL(vfio_iommu_dev_fault_handler_register_nested);
>>>>> +
>>>>> +int vfio_iommu_dev_fault_handler_unregister_nested(struct device *dev)
>>>>> +{
>>>>> + struct vfio_container *container;
>>>>> + struct vfio_group *group;
>>>>> + struct vfio_iommu_driver *driver;
>>>>> + int ret;
>>>>> +
>>>>> + if (!dev)
>>>>> + return -EINVAL;
>>>>> +
>>>>> + group = vfio_group_get_from_dev(dev);
>>>>> + if (!group)
>>>>> + return -ENODEV;
>>>>> +
>>>>> + ret = vfio_group_add_container_user(group);
>>>>> + if (ret)
>>>>> + goto out;
>>>>> +
>>>>> + container = group->container;
>>>>> + driver = container->iommu_driver;
>>>>> + if (likely(driver && driver->ops->unregister_handler))
>>>>> + ret = driver->ops->unregister_handler(container->iommu_data, dev);
>>>>> + else
>>>>> + ret = -ENOTTY;
>>>>> +
>>>>> + vfio_group_try_dissolve_container(group);
>>>>> +
>>>>> +out:
>>>>> + vfio_group_put(group);
>>>>> + return ret;
>>>>> +}
>>>>> +EXPORT_SYMBOL_GPL(vfio_iommu_dev_fault_handler_unregister_nested);
>>>>> +
>>>>> +int vfio_transfer_iommu_fault(struct device *dev, struct iommu_fault *fault)
>>>>> +{
>>>>> + struct vfio_device *device = dev_get_drvdata(dev);
>>>>> +
>>>>> + if (unlikely(!device->ops->transfer))
>>>>> + return -EOPNOTSUPP;
>>>>> +
>>>>> + return device->ops->transfer(device->device_data, fault);
>>>>> +}
>>>>> +EXPORT_SYMBOL_GPL(vfio_transfer_iommu_fault);
>>>>> +
>>>>> /**
>>>>> * Module/class support
>>>>> */
>>>>> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
>>>>> index ba2b5a1cf6e9..9d1adeddb303 100644
>>>>> --- a/drivers/vfio/vfio_iommu_type1.c
>>>>> +++ b/drivers/vfio/vfio_iommu_type1.c
>>>>> @@ -3821,13 +3821,32 @@ static int vfio_iommu_type1_dma_map_iopf(struct iommu_fault *fault, void *data)
>>>>> struct vfio_batch batch;
>>>>> struct vfio_range *range;
>>>>> dma_addr_t iova = ALIGN_DOWN(fault->prm.addr, PAGE_SIZE);
>>>>> - int access_flags = 0;
>>>>> + int access_flags = 0, nested;
>>>>> size_t premap_len, map_len, mapped_len = 0;
>>>>> unsigned long bit_offset, vaddr, pfn, i, npages;
>>>>> int ret;
>>>>> enum iommu_page_response_code status = IOMMU_PAGE_RESP_INVALID;
>>>>> struct iommu_page_response resp = {0};
>>>>>
>>>>> + if (vfio_dev_domian_nested(dev, &nested))
>>>>> + return -ENODEV;
>>>>> +
>>>>> + /*
>>>>> + * When configured in nested mode, further deliver the
>>>>> + * stage/level 1 faults to the guest.
>>>>> + */
>>>>> + if (nested) {
>>>>> + bool l2;
>>>>> +
>>>>> + if (fault->type == IOMMU_FAULT_PAGE_REQ)
>>>>> + l2 = fault->prm.flags & IOMMU_FAULT_PAGE_REQUEST_L2;
>>>>> + if (fault->type == IOMMU_FAULT_DMA_UNRECOV)
>>>>> + l2 = fault->event.flags & IOMMU_FAULT_UNRECOV_L2;
>>>>> +
>>>>> + if (!l2)
>>>>> + return vfio_transfer_iommu_fault(dev, fault);
>>>>> + }
>>>>> +
>>>>> if (fault->type != IOMMU_FAULT_PAGE_REQ)
>>>>> return -EOPNOTSUPP;
>>>>>
>>>>> @@ -4201,6 +4220,32 @@ static void vfio_iommu_type1_notify(void *iommu_data,
>>>>> wake_up_all(&iommu->vaddr_wait);
>>>>> }
>>>>>
>>>>> +static int vfio_iommu_type1_register_handler(void *iommu_data,
>>>>> + struct device *dev)
>>>>> +{
>>>>> + struct vfio_iommu *iommu = iommu_data;
>>>>> +
>>>>> + if (iommu->iopf_enabled)
>>>>> + return iommu_update_device_fault_handler(dev, ~0,
>>>>> + FAULT_REPORT_NESTED_L1);
>>>>> + else
>>>>> + return iommu_register_device_fault_handler(dev,
>>>>> + vfio_iommu_type1_dma_map_iopf,
>>>>> + FAULT_REPORT_NESTED_L1, dev);
>>>>> +}
>>>>> +
>>>>> +static int vfio_iommu_type1_unregister_handler(void *iommu_data,
>>>>> + struct device *dev)
>>>>> +{
>>>>> + struct vfio_iommu *iommu = iommu_data;
>>>>> +
>>>>> + if (iommu->iopf_enabled)
>>>>> + return iommu_update_device_fault_handler(dev,
>>>>> + ~FAULT_REPORT_NESTED_L1, 0);
>>>>> + else
>>>>> + return iommu_unregister_device_fault_handler(dev);
>>>>> +}
>>>>
>>>>
>>>> The path through vfio to register this is pretty ugly, but I don't see
>>>> any reason for the the update interfaces here, the previously
>>>> registered handler just changes its behavior.
>>>
>>> Yeah, this seems not an elegant way...
>>>
>>> If IOPF(L2) enabled, the fault handler has already been registered, so for
>>> nested mode setup, we only need to change the flags of the handler in the
>>> IOMMU driver to receive L1 faults.
>>> (assume that L1 IOPF is configured after L2 IOPF)
>>>
>>> Currently each device can only have one iommu dev fault handler, and L1
>>> and L2 IOPF are configured separately in nested mode, I am also wondering
>>> that is there a better solution for this.
>
> I haven't fully read all the references, but who imposes the fact that
> there's only one fault handler per device? If type1 could register one
> handler and the vfio-pci bus driver another for the other level, would
> we need this path through vfio-core?
If we could register more than one handler per device, things would become
much more simple, and the path through vfio-core would not be needed.
Hi Baolu,
Is there any restriction for having more than one handler per device?
>
>> Let me simply add, maybe there is another way for this:
>> Would it be better to set host IOPF enabled (L2 faults) in the VFIO_IOMMU_MAP_DMA
>> ioctl (no need to add a new ioctl, and we can specify whether this mapping is IOPF
>> available or statically pinned), and set guest IOPF enabled (L1 faults) in the
>> VFIO_IOMMU_SET_PASID_TABLE (from Eric's series) ioctl?
>> And we have no requirement for the sequence of these two ioctls. The first called
>> one will register the handler, and the later one will just update the handler...
>
> This is looking more and more like it belongs with the IOASID work. I
> think Eric has shifted his focus there too. Thanks,
I will pay more attention to the IOASID work.
Thanks,
Shenming
>
> Alex
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-05-27 11:08 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-09 3:44 [RFC PATCH v3 0/8] Add IOPF support for VFIO passthrough Shenming Lu
2021-04-09 3:44 ` [RFC PATCH v3 1/8] iommu: Evolve the device fault reporting framework Shenming Lu
2021-05-18 18:58 ` Alex Williamson
2021-05-21 6:37 ` Shenming Lu
2021-04-09 3:44 ` [RFC PATCH v3 2/8] vfio/type1: Add a page fault handler Shenming Lu
2021-05-18 18:58 ` Alex Williamson
2021-05-21 6:38 ` Shenming Lu
2021-05-24 22:11 ` Alex Williamson
2021-05-27 11:16 ` Shenming Lu
2021-04-09 3:44 ` [RFC PATCH v3 3/8] vfio/type1: Add an MMU notifier to avoid pinning Shenming Lu
2021-05-18 18:58 ` Alex Williamson
2021-05-21 6:37 ` Shenming Lu
2021-04-09 3:44 ` [RFC PATCH v3 4/8] vfio/type1: Pre-map more pages than requested in the IOPF handling Shenming Lu
2021-05-18 18:58 ` Alex Williamson
2021-05-21 6:37 ` Shenming Lu
2021-04-09 3:44 ` [RFC PATCH v3 5/8] vfio/type1: VFIO_IOMMU_ENABLE_IOPF Shenming Lu
2021-05-18 18:58 ` Alex Williamson
2021-05-21 6:38 ` Shenming Lu
2021-05-24 22:11 ` Alex Williamson
2021-05-27 11:15 ` Shenming Lu
2021-04-09 3:44 ` [RFC PATCH v3 6/8] vfio/type1: No need to statically pin and map if IOPF enabled Shenming Lu
2021-05-18 18:58 ` Alex Williamson
2021-05-21 6:39 ` Shenming Lu
2021-04-09 3:44 ` [RFC PATCH v3 7/8] vfio/type1: Add selective DMA faulting support Shenming Lu
2021-05-18 18:58 ` Alex Williamson
2021-05-21 6:39 ` Shenming Lu
2021-04-09 3:44 ` [RFC PATCH v3 8/8] vfio: Add nested IOPF support Shenming Lu
2021-05-18 18:58 ` Alex Williamson
2021-05-21 7:59 ` Shenming Lu
2021-05-24 13:11 ` Shenming Lu
2021-05-24 22:11 ` Alex Williamson
2021-05-27 11:03 ` Shenming Lu [this message]
2021-05-27 11:18 ` Lu Baolu
2021-06-01 4:36 ` Shenming Lu
2021-04-26 1:41 ` [RFC PATCH v3 0/8] Add IOPF support for VFIO passthrough Shenming Lu
2021-05-11 11:30 ` Shenming Lu
2021-05-18 18:57 ` Alex Williamson
2021-05-21 6:37 ` Shenming Lu
2021-05-24 22:11 ` Alex Williamson
2021-05-27 11:25 ` Shenming Lu
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=90b00e7d-7934-ee79-7643-e2949e2d3af4@huawei.com \
--to=lushenming@huawei.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=alex.williamson@redhat.com \
--cc=baolu.lu@linux.intel.com \
--cc=cohuck@redhat.com \
--cc=eric.auger@redhat.com \
--cc=hch@infradead.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jean-philippe@linaro.org \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robin.murphy@arm.com \
--cc=song.bao.hua@hisilicon.com \
--cc=wanghaibin.wang@huawei.com \
--cc=will@kernel.org \
--cc=yi.l.liu@intel.com \
--cc=yuzenghui@huawei.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).