Re: [PATCH v2 1/2] spapr: Disable legacy virtio devices for pseries-5.0 and later

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 3037 bytes --]

On Thu, Feb 13, 2020 at 03:34:25PM +0100, Greg Kurz wrote:
> On Thu, 13 Feb 2020 11:58:36 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > PAPR specifies a kind of odd, paravirtualized PCI bus, which looks to
> > the guess mostly like classic PCI, even if some of the individual
> > devices on the bus are PCI Express.  One consequence of that is that
> > virtio-pci devices still default to being in transitional mode, though
> > legacy mode is now disabled by default on current q35 x86 machine
> > types.
> > 
> > Legacy mode virtio devices aren't really necessary any more, and are
> > causing some problems for future changes.  Therefore, for the
> > pseries-5.0 machine type (and onwards), switch to modern-only
> > virtio-pci devices by default.
> > 
> > This does mean we no longer support guest kernels prior to 4.0, unless
> > they have modern virtio support backported (which some distro kernels
> > like that in RHEL7 do).
> > 
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> >  hw/ppc/spapr.c | 14 +++++++++++++-
> >  1 file changed, 13 insertions(+), 1 deletion(-)
> > 
> > diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
> > index cb220fde45..6e1e467cc6 100644
> > --- a/hw/ppc/spapr.c
> > +++ b/hw/ppc/spapr.c
> > @@ -65,6 +65,7 @@
> >  
> >  #include "hw/pci/pci.h"
> >  #include "hw/scsi/scsi.h"
> > +#include "hw/virtio/virtio-pci.h"
> >  #include "hw/virtio/virtio-scsi.h"
> >  #include "hw/virtio/vhost-scsi-common.h"
> >  
> > @@ -4567,7 +4568,14 @@ static void spapr_machine_latest_class_options(MachineClass *mc)
> >   */
> >  static void spapr_machine_5_0_class_options(MachineClass *mc)
> >  {
> > -    /* Defaults for the latest behaviour inherited from the base class */
> 
> Hmm... and so it seems we still have to carry this around when we
> add a new machine version. At least, that's what I had to do when
> adding a dummy 5.1 machine. This is because it is the old machine
> type that calls the class_options() function of the new one, not
> the other way around.

Uh.. no. It can just go in latest_class_options.  I thought I'd
already moved it there, but obviously not.  I've fixed that up for the
next spin.

> I was thinking about adapting Michael's patch. Instead of having
> a class_options() function that we only call for the latest
> machine type, we need a function that sets the default behaviour
> and call it for all machine types (which can still change the
> behaviour in their own class_options() function).

This will be confusing in a different way.  It will reset the default
options on each of the chained old machine types, which means anything
set in the "default" options needs to be overriden in *all* old
machine types that don't want it, not just the latest which doesn't
want it.

-- 
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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]