qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 for-2.11.2] spapr: make pseries-2.11 the defa


From: Michael Roth
Subject: Re: [Qemu-devel] [PATCH v2 for-2.11.2] spapr: make pseries-2.11 the default machine type
Date: Tue, 17 Jul 2018 12:02:23 -0500
User-agent: alot/0.6

Quoting David Gibson (2018-07-17 05:50:06)
> On Thu, Jun 21, 2018 at 03:23:21PM +0200, Greg Kurz wrote:
> > On Thu, 21 Jun 2018 11:18:09 +1000
> > David Gibson <address@hidden> wrote:
> > 
> > > On Wed, Jun 20, 2018 at 02:54:15PM +0200, Greg Kurz wrote:
> > > > The spapr capability framework was introduced in QEMU 2.12. It allows
> > > > to have an explicit control on how host features are exposed to the
> > > > guest. This is especially needed to handle migration between hetero-
> > > > geneous hosts (eg, POWER8 to POWER9). It is also used to expose fixes/
> > > > workarounds against speculative execution vulnerabilities to guests.
> > > > The framework was hence backported to QEMU 2.11.1, especially these
> > > > commits:
> > > > 
> > > > 0fac4aa93074 spapr: Add pseries-2.12 machine type
> > > > 9070f408f491 spapr: Treat Hardware Transactional Memory (HTM) as an
> > > >  optional capability
> > > > 
> > > > 0fac4aa93074 has the confusing effect of making pseries-2.12 the default
> > > > machine type for QEMU 2.11.1, instead of the expected pseries-2.11. This
> > > > patch changes the default machine back to pseries-2.11.
> > > > 
> > > > Unfortunately, 9070f408f491 enforces the HTM capability for pseries-2.11
> > > > to be enabled by default, ie, when not passing cap-htm on the command
> > > > line. This breaks several 'make check' testcases that run 
> > > > qemu-system-ppc64
> > > > with TCG.
> > > > 
> > > > The only sane way to fix this is to adapt the impacted testcases so that
> > > > they all pass cap-htm=off in this case. This patch does that as well.
> > > > 
> > > > Signed-off-by: Greg Kurz <address@hidden>
> > > > ---
> > > > v2: - have the testcases to pass cap-htm=off instead of violating the
> > > >       capabilities logic.
> > > > 
> > > > Upstream doesn't need anything like that since newer pseries machine 
> > > > types
> > > > start with HTM disabled by default. This is really a oneshot fix for 
> > > > 2.11.2,
> > > > and I've tried to make it as small as possible.
> > > > 
> > > > This is a full replacement of the previous version. It is based on 
> > > > Mike's
> > > > staging tree for 2.11:  
> > > 
> > > Thanks for fixing this up
> > > 
> > > Reviewed-by: David Gibson <address@hidden>
> > > 
> > > Btw, 2.11.z should probably have the 2.12 machine type removed
> > > entirely, as well as (obviously) not being the default.  Not within
> > > scope for this patch, though.
> > > 
> > 
> > Well... it is indeed weird but I don't think it hurts. Also, people
> > may have started using pseries-2.12 with QEMU 2.11.1 (I seem to
> > remember Mike told me about something like this the other day)...
> 
> I came back to thinking about this and realized this is a terrible
> idea.  The problem is that because of the way we define the latest
> machine type, then backwards compat props for the earlier ones, it's
> very likely that the "pseries-2.12" in 2.11 won't be the same as
> pseries-2.12 in 2.12, simply because 2.11 won't have the necessary
> features to implement pseries-2.12 as in 2.12.

What I saw was likely a holdover from early Ubuntu 18.04 p9 testing
before HTM emulation had made it's way into their kernel. In that
particular case Ubuntu doesn't support it at all now, but it remains
the only option for anyone else who happens to find themselves in
that situation and doesn't have a libvirt/Openstack with appropriate
machine capabilities.

Given that it was at least possible to run that config (however
broken) with QEMU 2.11.0, it seemed fair to leave some sort of
"out". But really it just seems like we don't have much to gain
by removing it at this point.

I agree in general though and probably would've handled this
differently if I'd thought through it a bit more.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]