From: Jean-Philippe Brucker <jean-philippe@linaro.org>
To: Vivek Kumar Gautam <vivek.gautam@arm.com>
Cc: linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
iommu@lists.linux-foundation.org,
virtualization@lists.linux-foundation.org, joro@8bytes.org,
will.deacon@arm.com, mst@redhat.com, robin.murphy@arm.com,
eric.auger@redhat.com, kevin.tian@intel.com,
jacob.jun.pan@linux.intel.com, yi.l.liu@intel.com,
Lorenzo.Pieralisi@arm.com, shameerali.kolothum.thodi@huawei.com
Subject: Re: [PATCH RFC v1 10/11] uapi/virtio-iommu: Add a new request type to send page response
Date: Wed, 6 Oct 2021 10:55:14 +0100 [thread overview]
Message-ID: <YV1ygu5URvuHB4qb@myrica> (raw)
In-Reply-To: <d40ea85b-3612-10b3-0add-40d07e6d9ca5@arm.com>
On Thu, Sep 30, 2021 at 02:54:05PM +0530, Vivek Kumar Gautam wrote:
> > > +struct virtio_iommu_req_page_resp {
> > > + struct virtio_iommu_req_head head;
> > > + __le32 domain;
> >
> > I don't think we need this field, since the fault report doesn't come with
> > a domain.
>
> But here we are sending the response which would be consumed by the vfio
> ultimately. In kvmtool, I am consuming this "virtio_iommu_req_page_resp"
> request in the virtio/iommu driver, extracting the domain from it, and using
> that to call the respective "page_response" ops from "vfio_iommu_ops" in the
> vfio/core driver.
>
> Is this incorrect way of passing on the page-response back to the host
> kernel?
That works for the host userspace-kernel interface because the device is
always attached to a VFIO container.
For virtio-iommu the domain info is redundant. The endpoint information
needs to be kept through the whole response path in order to target the
right endpoint in the end. In addition the guest could enable PRI without
attaching the endpoint to a domain, or fail to disable PRI before
detaching the endpoint. Sure it's weird, but the host can still inject the
recoverable page fault in this case, and the guest answers with "invalid"
status but no domain. We could mandate domains for recoverable faults but
that forces a synchronization against attach/detach and I think it
needlessly deviates from other IOMMUs.
Thanks,
Jean
next prev parent reply other threads:[~2021-10-06 9:55 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-23 9:51 [PATCH RFC v1 00/11] iommu/virtio: vSVA support with Arm Vivek Gautam
2021-04-23 9:51 ` [PATCH RFC v1 01/11] uapi/virtio-iommu: Add page request grp-id and flags information Vivek Gautam
2021-09-21 15:58 ` Jean-Philippe Brucker
2021-09-30 4:56 ` Vivek Kumar Gautam
2021-09-30 8:49 ` Jean-Philippe Brucker
2021-09-30 10:57 ` Vivek Kumar Gautam
2021-04-23 9:51 ` [PATCH RFC v1 02/11] iommu/virtio: Maintain a list of endpoints served by viommu_dev Vivek Gautam
2021-09-21 15:59 ` Jean-Philippe Brucker
2021-09-30 9:17 ` Vivek Kumar Gautam
2021-04-23 9:51 ` [PATCH RFC v1 03/11] iommu/virtio: Handle incoming page faults Vivek Gautam
2021-09-21 16:03 ` Jean-Philippe Brucker
2021-10-11 8:11 ` Vivek Gautam
2021-10-11 9:16 ` Jean-Philippe Brucker
2021-10-11 9:20 ` Vivek Kumar Gautam
2021-04-23 9:51 ` [PATCH RFC v1 04/11] iommu/virtio: Add a io page fault queue Vivek Gautam
2021-04-23 9:51 ` [PATCH RFC v1 05/11] iommu/virtio: Add SVA feature and related enable/disable callbacks Vivek Gautam
2021-09-21 16:04 ` Jean-Philippe Brucker
2021-04-23 9:51 ` [PATCH RFC v1 06/11] iommu/pasid-table: Add pasid table ops for shared context management Vivek Gautam
2021-04-23 9:51 ` [PATCH RFC v1 07/11] iommu/arm-smmu-v3: Move shared context descriptor code to cd-lib Vivek Gautam
2021-04-23 9:51 ` [PATCH RFC v1 08/11] iommu/arm-smmu-v3: Implement shared context alloc and free ops Vivek Gautam
2021-09-21 16:07 ` Jean-Philippe Brucker
2021-09-30 9:50 ` Vivek Kumar Gautam
2021-04-23 9:51 ` [PATCH RFC v1 09/11] iommu/virtio: Implement sva bind/unbind calls Vivek Gautam
2021-09-21 16:09 ` Jean-Philippe Brucker
2021-04-23 9:51 ` [PATCH RFC v1 10/11] uapi/virtio-iommu: Add a new request type to send page response Vivek Gautam
2021-09-21 16:16 ` Jean-Philippe Brucker
2021-09-30 9:24 ` Vivek Kumar Gautam
2021-10-06 9:55 ` Jean-Philippe Brucker [this message]
2021-04-23 9:51 ` [PATCH RFC v1 11/11] iommu/virtio: Add support " Vivek Gautam
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=YV1ygu5URvuHB4qb@myrica \
--to=jean-philippe@linaro.org \
--cc=Lorenzo.Pieralisi@arm.com \
--cc=eric.auger@redhat.com \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@linux.intel.com \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
--cc=robin.murphy@arm.com \
--cc=shameerali.kolothum.thodi@huawei.com \
--cc=virtualization@lists.linux-foundation.org \
--cc=vivek.gautam@arm.com \
--cc=will.deacon@arm.com \
--cc=yi.l.liu@intel.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).