Upstream QEMU guest support policy ? Re: [PATCH v3 0/2] spapr: Use vIOMMU translation for virtio by default

[Daniel P . Berrangé]

On Thu, Mar 05, 2020 at 03:30:07PM +1100, David Gibson 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.

Breaking existing guest OS to support a new secure VM feature that
may not even be used/wanted doesn't seems like a sensible tradeoff
for default out of the box behaviour.

IOW, if Secure VM needs this, can we tie the change in virtio and
IOMMU defaults to the machine type flag that enables the use of
Secure VM.

That way the changed virtio defaults only take effect if a user/mgmt
app has explicitly opted in to the new Secure VM feature, and existing
users won't be broken by a new feature they don't even use.

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


I think this question has different answers depending on whether you
are considering downstream vendor policy, current upstream policy,
and a possible new downstream policy on guest support. IOW a bit of a
can of worms...


In the case of RHEL downstream there is a very narrow matrix for
what guest OS are considered supported.

In the case of current upstream, there has essentially never been
any documented guest matrix. The unwritten implicit rule upstream
has followed is to not change defaults in a way that would break
ability to run existing guest OS.


As an example, on x86 upstream defaults to i440fx and thus still
uses virtio devices in transitional mode by default, while downstream
RHEL used its narrow support matrix as a justification for why it was
ok to switch to q35 by default & loose guest support in many cases.
Even that was problematic though, because RHEL still needed to support
RHEL-6 guest which are broken by default with q35 since they only
support legacy mode virtio. Thus we needed work in management apps
to enable RHEL-6 to continue working with q35 chipset, by placing
the devices onto a PCI bridge, instead of a PCIe root port, or by
explicitly using i440fx instead.

Thus if we follow our *current* upstream guest support policy, I don't
think it is acceptable to break existing guests with the new machine
type upstream.  It is reasonable to do it downstream if the downstream
is willing to sacrifice these guests, or invest to make any mgmt apps 
add workaround/revert QEMU changes.


With that all said, I do *NOT* think current upstream practice is good
or sustainable long term (though I admit I've argued on the other side
in the past).

This policy is why we're still using a machine designed in 1995 on x86
by default, in order that we avoid breaking the popular guest OS of the
day, like Windows 95.

This is similar to the problem we had with host build platforms, where
we afraid to make any change which would break an existing build platform,
or on the flipside made arbitrary ad-hoc changes with no consistent
approach across different subsystems.


I think that we should aim define some clearer policy around how we
want to support guest OS in upstream. As we did with our host build
platforms policy, any guest support policy should aim to move forward
at a reasonable pace so that we are not locked at a specific point in
time forever.

I can imagine three tiers

 1. Recommended. Expected to work well with machine type defaults
 2. Supported. Should work with QEMU but may need special settings applied
 3. Unsupported. Will not work with QEMU regardless of settings

I don't have an opinion right now on what guest OS should fall in which
category. One possible way to classify them would be to look at whether
the vendor themselves still supported the OS.  IOW, to be in the
"Recommended" criteria, it must be actively supported by the vendor.
Once EOL by the vendor it would be capped at the "Supported" tier.

That definition wouldn't help your pseries issue though, because RHEL-6
is still considered a supported OS.

Another possible way to classify guest OS would be to look purely at
the original release date, and set a cap of "$TODAY - 5 years" for
the "Recommended" tier. That would exclude RHEL-6.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|