The existing SPAPR TCE driver advertises both VFIO_SPAPR_TCE_IOMMU and
VFIO_SPAPR_TCE_v2_IOMMU types to the userspace and the userspace usually
picks the v2.
Normally the userspace would create a container, attach an IOMMU group
to it and only then set the IOMMU type (which would normally be v2).
However a specific IOMMU group may not support v2, in other words
it may not implement set_window/unset_window/take_ownership/
release_ownership and such a group should not be attached to
a v2 container.
This adds extra checks that a new group can do what the selected IOMMU
type suggests. The userspace can then test the return value from
ioctl(VFIO_SET_IOMMU, VFIO_SPAPR_TCE_v2_IOMMU) and try
VFIO_SPAPR_TCE_IOMMU.
Signed-off-by: Alexey Kardashevskiy <redacted>
---
This is one of the patches needed to do nested VFIO - for either
second level guest or DPDK running in a guest.
---
drivers/vfio/vfio_iommu_spapr_tce.c | 8 ++++++++
1 file changed, 8 insertions(+)
From: Alex Williamson <hidden> Date: 2017-03-24 20:29:08
On Fri, 24 Mar 2017 17:44:06 +1100
Alexey Kardashevskiy [off-list ref] wrote:
The existing SPAPR TCE driver advertises both VFIO_SPAPR_TCE_IOMMU and
VFIO_SPAPR_TCE_v2_IOMMU types to the userspace and the userspace usually
picks the v2.
Normally the userspace would create a container, attach an IOMMU group
to it and only then set the IOMMU type (which would normally be v2).
However a specific IOMMU group may not support v2, in other words
it may not implement set_window/unset_window/take_ownership/
release_ownership and such a group should not be attached to
a v2 container.
This adds extra checks that a new group can do what the selected IOMMU
type suggests. The userspace can then test the return value from
ioctl(VFIO_SET_IOMMU, VFIO_SPAPR_TCE_v2_IOMMU) and try
VFIO_SPAPR_TCE_IOMMU.
Signed-off-by: Alexey Kardashevskiy <redacted>
---
This is one of the patches needed to do nested VFIO - for either
second level guest or DPDK running in a guest.
---
drivers/vfio/vfio_iommu_spapr_tce.c | 8 ++++++++
1 file changed, 8 insertions(+)
I'm not sure I understand why you're labeling this "guest kernel", is a
VM the only case where we can have combinations that only a subset of
the groups might support v2? What terrible things happen when such a
combination is created? The fix itself seems sane, but I'm trying to
figure out whether it should be marked for stable, should go in for
v4.11, or be queued for v4.12. Thanks,
Alex
On Fri, 24 Mar 2017 17:44:06 +1100
Alexey Kardashevskiy [off-list ref] wrote:
quoted
The existing SPAPR TCE driver advertises both VFIO_SPAPR_TCE_IOMMU and
VFIO_SPAPR_TCE_v2_IOMMU types to the userspace and the userspace usually
picks the v2.
Normally the userspace would create a container, attach an IOMMU group
to it and only then set the IOMMU type (which would normally be v2).
However a specific IOMMU group may not support v2, in other words
it may not implement set_window/unset_window/take_ownership/
release_ownership and such a group should not be attached to
a v2 container.
This adds extra checks that a new group can do what the selected IOMMU
type suggests. The userspace can then test the return value from
ioctl(VFIO_SET_IOMMU, VFIO_SPAPR_TCE_v2_IOMMU) and try
VFIO_SPAPR_TCE_IOMMU.
Signed-off-by: Alexey Kardashevskiy <redacted>
---
This is one of the patches needed to do nested VFIO - for either
second level guest or DPDK running in a guest.
---
drivers/vfio/vfio_iommu_spapr_tce.c | 8 ++++++++
1 file changed, 8 insertions(+)
I'm not sure I understand why you're labeling this "guest kernel", is a
That is my script :)
VM the only case where we can have combinations that only a subset of
the groups might support v2?
powernv (non-virtualized, and it runs HV KVM) host provides v2-capable
groups, they all the same, and a pseries host (which normally runs as a
guest but it can do nested KVM as well - it is called PR KVM) can do only
v1 (after this patch, without it - no vfio at all).
What terrible things happen when such a
combination is created?
There is no mixture at the moment, I just needed a way to tell userspace
that a group cannot do v2.
The fix itself seems sane, but I'm trying to
figure out whether it should be marked for stable, should go in for
v4.11, or be queued for v4.12. Thanks,
On Fri, 24 Mar 2017 17:44:06 +1100
Alexey Kardashevskiy [off-list ref] wrote:
quoted
The existing SPAPR TCE driver advertises both VFIO_SPAPR_TCE_IOMMU and
VFIO_SPAPR_TCE_v2_IOMMU types to the userspace and the userspace usually
picks the v2.
Normally the userspace would create a container, attach an IOMMU group
to it and only then set the IOMMU type (which would normally be v2).
However a specific IOMMU group may not support v2, in other words
it may not implement set_window/unset_window/take_ownership/
release_ownership and such a group should not be attached to
a v2 container.
This adds extra checks that a new group can do what the selected IOMMU
type suggests. The userspace can then test the return value from
ioctl(VFIO_SET_IOMMU, VFIO_SPAPR_TCE_v2_IOMMU) and try
VFIO_SPAPR_TCE_IOMMU.
Signed-off-by: Alexey Kardashevskiy <redacted>
---
This is one of the patches needed to do nested VFIO - for either
second level guest or DPDK running in a guest.
---
drivers/vfio/vfio_iommu_spapr_tce.c | 8 ++++++++
1 file changed, 8 insertions(+)
I'm not sure I understand why you're labeling this "guest kernel", is a
That is my script :)
quoted
VM the only case where we can have combinations that only a subset of
the groups might support v2?
powernv (non-virtualized, and it runs HV KVM) host provides v2-capable
groups, they all the same, and a pseries host (which normally runs as a
guest but it can do nested KVM as well - it is called PR KVM) can do only
v1 (after this patch, without it - no vfio at all).
quoted
What terrible things happen when such a
combination is created?
There is no mixture at the moment, I just needed a way to tell userspace
that a group cannot do v2.
quoted
The fix itself seems sane, but I'm trying to
figure out whether it should be marked for stable, should go in for
v4.11, or be queued for v4.12. Thanks,
On Fri, 24 Mar 2017 17:44:06 +1100
Alexey Kardashevskiy [off-list ref] wrote:
quoted
The existing SPAPR TCE driver advertises both VFIO_SPAPR_TCE_IOMMU and
VFIO_SPAPR_TCE_v2_IOMMU types to the userspace and the userspace usually
picks the v2.
Normally the userspace would create a container, attach an IOMMU group
to it and only then set the IOMMU type (which would normally be v2).
However a specific IOMMU group may not support v2, in other words
it may not implement set_window/unset_window/take_ownership/
release_ownership and such a group should not be attached to
a v2 container.
This adds extra checks that a new group can do what the selected IOMMU
type suggests. The userspace can then test the return value from
ioctl(VFIO_SET_IOMMU, VFIO_SPAPR_TCE_v2_IOMMU) and try
VFIO_SPAPR_TCE_IOMMU.
Signed-off-by: Alexey Kardashevskiy <redacted>
---
This is one of the patches needed to do nested VFIO - for either
second level guest or DPDK running in a guest.
---
drivers/vfio/vfio_iommu_spapr_tce.c | 8 ++++++++
1 file changed, 8 insertions(+)
I'm not sure I understand why you're labeling this "guest kernel", is a
That is my script :)
quoted
VM the only case where we can have combinations that only a subset of
the groups might support v2?
powernv (non-virtualized, and it runs HV KVM) host provides v2-capable
groups, they all the same, and a pseries host (which normally runs as a
guest but it can do nested KVM as well - it is called PR KVM) can do only
v1 (after this patch, without it - no vfio at all).
quoted
What terrible things happen when such a
combination is created?
There is no mixture at the moment, I just needed a way to tell userspace
that a group cannot do v2.
quoted
The fix itself seems sane, but I'm trying to
figure out whether it should be marked for stable, should go in for
v4.11, or be queued for v4.12. Thanks,
No need for stable.
So what is the next step with this patch?
Unless there are objections or further comments, I'll put this in my
next branch for v4.12, probably this week. Thanks,
Alex