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 ?