spapr: Simplify selection of radix/hash during CAS
commitb4b83312e72461540ee155006f0d49e33bf0c58d
authorGreg Kurz <groug@kaod.org>
Wed, 25 Mar 2020 15:25:36 +0000 (25 16:25 +0100)
committerDavid Gibson <david@gibson.dropbear.id.au>
Thu, 7 May 2020 01:10:50 +0000 (7 11:10 +1000)
treef0b97a65847737c899a4c6539b27e80a7d76087c
parent01b552b05b0f21f8ff57a508f7ad26f7abbcd123
spapr: Simplify selection of radix/hash during CAS

The guest can select the MMU mode by setting bits 0-1 of byte 24
in OV5 to to 0b00 for hash or 0b01 for radix. As required by the
architecture, we terminate the boot process if any other value
is found there.

The usual way to negotiate features in OV5 is basically ANDing
the bitfield provided by the guest and the bitfield of features
supported by QEMU, previously populated at machine init.

For some not documented reason, MMU is treated differently : bit 1
of byte 24 (the radix/hash bit) is cleared from the guest OV5 and
explicitely set in the final negotiated OV5 if radix was requested.

Since the only expected input from the guest is the radix/hash bit
being set or not, it seems more appropriate to handle this like we
do for XIVE.

Set the radix bit in spapr->ov5 at machine init if it has a chance
to work (ie. power9, either TCG or a radix capable KVM) and rely
exclusively on spapr_ovec_intersect() to set the radix bit in
spapr->ov5_cas.

Signed-off-by: Greg Kurz <groug@kaod.org>
Message-Id: <158514993621.478799.4204740354545734293.stgit@bahia.lan>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
hw/ppc/spapr.c
hw/ppc/spapr_hcall.c