[PATCH v2 0/2] spapr: Use vIOMMU translation for virtio by default

David Gibson posted 2 patches 1 week ago
Failed in applying to current master (apply log)
hw/ppc/spapr.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)

[PATCH v2 0/2] spapr: Use vIOMMU translation for virtio by default

Posted by David Gibson 1 week ago
Upcoming Secure VM support for pSeries machines introduces some
complications for virtio, since the transfer buffers need to be
explicitly shared so that the hypervisor can access them.

While it's not strictly speaking dependent on it, the fact that virtio
devices bypass normal platform IOMMU translation complicates the issue
on the guest side.  Since there are some significan downsides to
bypassing the vIOMMU anyway, let's just disable that.

There's already a flag to do this in virtio, just turn it on by
default for forthcoming pseries machine types.

Any opinions on whether dropping support for the older guest kernels
is acceptable at this point?

Changes since v1:
 * Added information on which guest kernel versions will no longer
   work with these changes
 * Use Michael Tsirkin's suggested better way of handling the machine
   type change

David Gibson (2):
  spapr: Disable legacy virtio devices for pseries-5.0 and later
  spapr: Enable virtio iommu_platform=on by default

 hw/ppc/spapr.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

-- 
2.24.1


Re: [PATCH v2 0/2] spapr: Use vIOMMU translation for virtio by default

Posted by Greg Kurz 1 week ago
On Thu, 13 Feb 2020 11:58:35 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> Upcoming Secure VM support for pSeries machines introduces some
> complications for virtio, since the transfer buffers need to be
> explicitly shared so that the hypervisor can access them.
> 
> While it's not strictly speaking dependent on it, the fact that virtio
> devices bypass normal platform IOMMU translation complicates the issue
> on the guest side.  Since there are some significan downsides to
> bypassing the vIOMMU anyway, let's just disable that.
> 
> There's already a flag to do this in virtio, just turn it on by
> default for forthcoming pseries machine types.
> 
> Any opinions on whether dropping support for the older guest kernels
> is acceptable at this point?
> 

As expected, this breaks compatibility with existing RHEL 6.10 guests. Each
patch in this series requires an extra -global option to be specified on
the command line in order to boot successfully.

Patch 1: -global virtio-pci.disable-legacy=auto
Patch 2: -global virtio-pci.iommu_platform=off

As seen on the RH site [1], RHEL6 will reach "End of Maintenance Support
or Maintenance Support 2 (Product retirement)" on November 30, 2020 and
"End of Extended Life-cycle Support" on June 30, 2024.

Not sure if it's okay to drop support for RHEL6 this soon.

RHEL 7.7 guests seem to be unaffected.

[1] https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates

> Changes since v1:
>  * Added information on which guest kernel versions will no longer
>    work with these changes
>  * Use Michael Tsirkin's suggested better way of handling the machine
>    type change
> 
> David Gibson (2):
>   spapr: Disable legacy virtio devices for pseries-5.0 and later
>   spapr: Enable virtio iommu_platform=on by default
> 
>  hw/ppc/spapr.c | 16 +++++++++++++++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 


Re: [PATCH v2 0/2] spapr: Use vIOMMU translation for virtio by default

Posted by David Gibson 1 week ago
On Thu, Feb 13, 2020 at 12:46:43PM +0100, Greg Kurz wrote:
> On Thu, 13 Feb 2020 11:58:35 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > Upcoming Secure VM support for pSeries machines introduces some
> > complications for virtio, since the transfer buffers need to be
> > explicitly shared so that the hypervisor can access them.
> > 
> > While it's not strictly speaking dependent on it, the fact that virtio
> > devices bypass normal platform IOMMU translation complicates the issue
> > on the guest side.  Since there are some significan downsides to
> > bypassing the vIOMMU anyway, let's just disable that.
> > 
> > There's already a flag to do this in virtio, just turn it on by
> > default for forthcoming pseries machine types.
> > 
> > Any opinions on whether dropping support for the older guest kernels
> > is acceptable at this point?
> > 
> 
> As expected, this breaks compatibility with existing RHEL 6.10 guests. Each
> patch in this series requires an extra -global option to be specified on
> the command line in order to boot successfully.
> 
> Patch 1: -global virtio-pci.disable-legacy=auto
> Patch 2: -global virtio-pci.iommu_platform=off

Right, or setting an older machine type.

> As seen on the RH site [1], RHEL6 will reach "End of Maintenance Support
> or Maintenance Support 2 (Product retirement)" on November 30, 2020 and
> "End of Extended Life-cycle Support" on June 30, 2024.
> 
> Not sure if it's okay to drop support for RHEL6 this soon.

Hm, yeah.  I'm happy enough to do this upstream, downstream will
require some discussion.

> RHEL 7.7 guests seem to be unaffected.

Yeah, I already checked and RHEL7 has backported support for modern
virtio and the iommu platform flag.

> 
> [1] https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates
> 
> > Changes since v1:
> >  * Added information on which guest kernel versions will no longer
> >    work with these changes
> >  * Use Michael Tsirkin's suggested better way of handling the machine
> >    type change
> > 
> > David Gibson (2):
> >   spapr: Disable legacy virtio devices for pseries-5.0 and later
> >   spapr: Enable virtio iommu_platform=on by default
> > 
> >  hw/ppc/spapr.c | 16 +++++++++++++++-
> >  1 file changed, 15 insertions(+), 1 deletion(-)
> > 
> 

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson