Re: [PATCH v3 4/4] spapr: Forbid nested KVM-HV in pre-power9 compat mode

[David Gibson]

On Wed, Jul 15, 2020 at 01:14:42PM +0200, Greg Kurz wrote:
> On Mon, 13 Jul 2020 14:53:30 +1000
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > On Fri, Jul 03, 2020 at 04:19:24PM +0200, Greg Kurz wrote:
> > > On Mon, 15 Jun 2020 11:20:31 +0200
> > > Greg Kurz <groug@kaod.org> wrote:
> > > 
> > > > On Sat, 13 Jun 2020 17:18:04 +1000
> > > > David Gibson <david@gibson.dropbear.id.au> wrote:
> > > > 
> > > > > On Thu, Jun 11, 2020 at 03:40:33PM +0200, Greg Kurz wrote:
> > > > > > Nested KVM-HV only works on POWER9.
> > > > > > 
> > > > > > Signed-off-by: Greg Kurz <groug@kaod.org>
> > > > > > Reviewed-by: Laurent Vivier <lvivier@redhat.com>
> > > > > 
> > > > > Hrm.  I have mixed feelings about this.  It does bring forward an
> > > > > error that we'd otherwise only discover when we try to load the kvm
> > > > > module in the guest.
> > > > > 
> > > > > On the other hand, it's kind of a layering violation - really it's
> > > > > KVM's business to report what it can and can't do, rather than having
> > > > > qemu anticipate it.
> > > > > 
> > > > 
> > > > Agreed and it seems that we can probably get KVM to report that
> > > > already. I'll have closer look.
> > > > 
> > > 
> > > Checking the KVM_CAP_PPC_NESTED_HV extension only reports what the host
> > > supports. It can't reasonably take into account that we're going to
> > > switch vCPUs in some compat mode later on. KVM could possibly check
> > > that it has a vCPU in pre-power9 compat mode when we try to enable
> > > the capability and fail... but it would be a layering violation all
> > > the same. The KVM that doesn't like pre-power9 CPUs isn't the one in
> > > the host, it is the one in the guest, and it's not even directly
> > > related to the CPU type but to the MMU mode currently in use:
> > > 
> > > long kvmhv_nested_init(void)
> > > {
> > >   long int ptb_order;
> > >   unsigned long ptcr;
> > >   long rc;
> > > 
> > >   if (!kvmhv_on_pseries())
> > >           return 0;
> > > ==>       if (!radix_enabled())
> > >           return -ENODEV;
> > > 
> > > We cannot know either for sure the MMU mode the guest will run in
> > > when we enable the nested cap during the initial machine reset.
> > > So it seems we cannot do anything better than denylisting well
> > > known broken setups, in which case QEMU seems a better fit than
> > > KVM.
> > > 
> > > Makes sense ?
> > 
> > Yeah, good points.
> > 
> 
> So, should I just rebase/repost this or do you think of another
> way ?

Urgh... I've kind of forgotten the context while I've been away.  So,
I guess repost and I'll take another look at them.

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

signature.asc
Description: PGP signature