> From: Jason Gunthorpe
> Sent: Friday, March 18, 2022 9:46 PM
>
> On Fri, Mar 18, 2022 at 07:01:19AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Tuesday, March 15, 2022 10:55 PM
> > >
> > > The first level iommu_domain has the 'type1' map and unmap and pins
> > > the
On Fri, Mar 18, 2022 at 07:01:19AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Tuesday, March 15, 2022 10:55 PM
> >
> > The first level iommu_domain has the 'type1' map and unmap and pins
> > the pages. This is the 1:1 map with the GPA and ends up pinning all
> > guest memory
> From: Jason Gunthorpe
> Sent: Tuesday, March 15, 2022 10:55 PM
>
> The first level iommu_domain has the 'type1' map and unmap and pins
> the pages. This is the 1:1 map with the GPA and ends up pinning all
> guest memory because the point is you don't want to take a memory pin
> on your
On 3/15/22 1:25 PM, Jason Gunthorpe wrote:
On Tue, Mar 15, 2022 at 12:29:02PM -0400, Matthew Rosato wrote:
On 3/15/22 10:38 AM, Jason Gunthorpe wrote:
On Tue, Mar 15, 2022 at 09:49:01AM -0400, Matthew Rosato wrote:
The rationale for splitting steps 1 and 2 are that VFIO_SET_IOMMU doesn't
On Tue, Mar 15, 2022 at 12:29:02PM -0400, Matthew Rosato wrote:
> On 3/15/22 10:38 AM, Jason Gunthorpe wrote:
> > On Tue, Mar 15, 2022 at 09:49:01AM -0400, Matthew Rosato wrote:
> >
> > > The rationale for splitting steps 1 and 2 are that VFIO_SET_IOMMU doesn't
> > > have a mechanism for
On Tue, Mar 15, 2022 at 12:04:35PM -0400, Matthew Rosato wrote:
> > You can't pin/unpin in this path, there is no real way to handle error
> > and ulimit stuff here, plus it is really slow. I didn't notice any of
> > this in your patches, so what do you mean by 'pin' above?
>
> patch 18 does
On 3/15/22 10:17 AM, Matthew Rosato wrote:
On 3/15/22 3:57 AM, Tian, Kevin wrote:
From: Jason Gunthorpe
Sent: Tuesday, March 15, 2022 7:18 AM
On Mon, Mar 14, 2022 at 04:50:33PM -0600, Alex Williamson wrote:
+/*
+ * The KVM_IOMMU type implies that the hypervisor will control the
mappings
+
On 3/15/22 10:38 AM, Jason Gunthorpe wrote:
On Tue, Mar 15, 2022 at 09:49:01AM -0400, Matthew Rosato wrote:
The rationale for splitting steps 1 and 2 are that VFIO_SET_IOMMU doesn't
have a mechanism for specifying more than the type as an arg, no? Otherwise
yes, you could specify a kvm fd at
On 3/15/22 10:55 AM, Jason Gunthorpe wrote:
On Tue, Mar 15, 2022 at 09:36:08AM -0400, Matthew Rosato wrote:
If we do try to stick this into VFIO it should probably use the
VFIO_TYPE1_NESTING_IOMMU instead - however, we would like to delete
that flag entirely as it was never fully implemented,
On Tue, Mar 15, 2022 at 09:36:08AM -0400, Matthew Rosato wrote:
> > If we do try to stick this into VFIO it should probably use the
> > VFIO_TYPE1_NESTING_IOMMU instead - however, we would like to delete
> > that flag entirely as it was never fully implemented, was never used,
> > and isn't part
On Tue, Mar 15, 2022 at 09:49:01AM -0400, Matthew Rosato wrote:
> The rationale for splitting steps 1 and 2 are that VFIO_SET_IOMMU doesn't
> have a mechanism for specifying more than the type as an arg, no? Otherwise
> yes, you could specify a kvm fd at this point and it would have some other
>
On 3/15/22 3:57 AM, Tian, Kevin wrote:
From: Jason Gunthorpe
Sent: Tuesday, March 15, 2022 7:18 AM
On Mon, Mar 14, 2022 at 04:50:33PM -0600, Alex Williamson wrote:
+/*
+ * The KVM_IOMMU type implies that the hypervisor will control the
mappings
+ * rather than userspace
+ */
+#define
On 3/14/22 5:38 PM, Jason Gunthorpe wrote:
On Mon, Mar 14, 2022 at 03:44:34PM -0400, Matthew Rosato wrote:
diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
index 9394aa9444c1..0bec97077d61 100644
+++ b/drivers/vfio/vfio_iommu_type1.c
@@ -77,6 +77,7 @@ struct
On 3/14/22 7:18 PM, Jason Gunthorpe wrote:
On Mon, Mar 14, 2022 at 04:50:33PM -0600, Alex Williamson wrote:
+/*
+ * The KVM_IOMMU type implies that the hypervisor will control the mappings
+ * rather than userspace
+ */
+#define VFIO_KVM_IOMMU 11
Then why is this hosted in
> From: Jason Gunthorpe
> Sent: Tuesday, March 15, 2022 7:18 AM
>
> On Mon, Mar 14, 2022 at 04:50:33PM -0600, Alex Williamson wrote:
>
> > > +/*
> > > + * The KVM_IOMMU type implies that the hypervisor will control the
> mappings
> > > + * rather than userspace
> > > + */
> > > +#define
On Mon, Mar 14, 2022 at 04:50:33PM -0600, Alex Williamson wrote:
> > +/*
> > + * The KVM_IOMMU type implies that the hypervisor will control the mappings
> > + * rather than userspace
> > + */
> > +#define VFIO_KVM_IOMMU 11
>
> Then why is this hosted in the type1 code that
On Mon, 14 Mar 2022 15:44:34 -0400
Matthew Rosato wrote:
> s390x will introduce a new IOMMU domain type where the mappings are
> managed by KVM rather than in response to userspace mapping ioctls. Allow
> for specifying this type on the VFIO_SET_IOMMU ioctl and triggering the
> appropriate
On Mon, Mar 14, 2022 at 03:44:34PM -0400, Matthew Rosato wrote:
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 9394aa9444c1..0bec97077d61 100644
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -77,6 +77,7 @@ struct vfio_iommu {
> bool
s390x will introduce a new IOMMU domain type where the mappings are
managed by KVM rather than in response to userspace mapping ioctls. Allow
for specifying this type on the VFIO_SET_IOMMU ioctl and triggering the
appropriate iommu interface for overriding the default domain.
Signed-off-by:
19 matches
Mail list logo
