On Wed, Jul 15, 2020 at 01:14:42PM +0200, Greg Kurz wrote: > On Mon, 13 Jul 2020 14:53:30 +1000 > David Gibson <da...@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 <gr...@kaod.org> wrote: > > > > > > > On Sat, 13 Jun 2020 17:18:04 +1000 > > > > David Gibson <da...@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 <gr...@kaod.org> > > > > > > Reviewed-by: Laurent Vivier <lviv...@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