[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-ppc] [PATCH 03/12] target/ppc: Re-enable RMLS on POWER9 for vi
From: |
David Gibson |
Subject: |
Re: [Qemu-ppc] [PATCH 03/12] target/ppc: Re-enable RMLS on POWER9 for virtual hypervisors |
Date: |
Tue, 19 Feb 2019 14:46:49 +1100 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
On Fri, Feb 15, 2019 at 06:00:20PM +0100, Cédric Le Goater wrote:
> From: Benjamin Herrenschmidt <address@hidden>
>
> Historically the 64-bit server MMU supports two way of configuring the
> guest "real mode" mapping:
>
> - The "RMA" with is a single chunk of physically contiguous
> memory remapped as guest real, and controlled by the RMLS
> field in the LPCR register and the RMOR register.
>
> - The "VRMA" which uses special PTEs inserted in the partition
> hash table by the hypervisor.
>
> POWER9 deprecates the former, which is reflected by the filtering
> done in ppc_store_lpcr() which effectively prevents setting of
> the RMLS field.
>
> However, when using fully emulated SPAPR machines, our qemu code
> currently only knows how to define the guest real mode memory using
> RMLS.
>
> Thus you cannot run a SPAPR machine anymore with a POWER9 CPU
> model today.
>
> This works around it with a quirk in ppc_store_lpcr() to continue
> allowing the RMLS field to be set when using a virtual hypervisor.
>
> Ultimately we will want to implement configuring a VRMA instead
> which will also be necessary if we want to migrate a SPAPR guest
> between TCG and KVM but this is a lot more work.
Urgh. I'm applying this because it fixes a real bug, but it's not
really the right solution.
We will want to support VRMAs at some point in order to let emulated
powernv machines run guests, but implementing VRMA doesn't really make
sense in the context of a PAPR machine.
The real problem here is that we're using the LPCR - which notionally
doesn't even exist in a PAPR machine - to trick the softmmu code,
which is written from the point of view of bare metal - into doing
more or less the right thing for a PAPR machine.
The correct solution, I think, is to put a test on cpu->vhyp into the
guts of the softmmu code so that in non-HV real mode it doesn't even
consult the LPCR and just goes directly to GPAs (which is the only
think that the pseries machine knows about).
Although then I guess we'd need some way in the vhyp of representing
the permissible max address of real mode accesses.
--
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
- [Qemu-ppc] [PATCH 00/12] ppc: add native hash and radix support for POWER9, Cédric Le Goater, 2019/02/15
- [Qemu-ppc] [PATCH 10/12] target/ppc: Rename PATB/PATBE -> PATE, Cédric Le Goater, 2019/02/15
- [Qemu-ppc] [PATCH 03/12] target/ppc: Re-enable RMLS on POWER9 for virtual hypervisors, Cédric Le Goater, 2019/02/15
- Re: [Qemu-ppc] [PATCH 03/12] target/ppc: Re-enable RMLS on POWER9 for virtual hypervisors,
David Gibson <=
- [Qemu-ppc] [PATCH 11/12] target/ppc: Support for POWER9 native hash, Cédric Le Goater, 2019/02/15
- [Qemu-ppc] [PATCH 07/12] target/ppc: Add basic support for "new format" HPTE as found on POWER9, Cédric Le Goater, 2019/02/15
- [Qemu-ppc] [PATCH 05/12] target/ppc: Cleanup 64-bit MMU includes, Cédric Le Goater, 2019/02/15
- [Qemu-ppc] [PATCH 08/12] target/ppc: Fix synchronization of mttcg with broadcast TLB flushes, Cédric Le Goater, 2019/02/15
- [Qemu-ppc] [PATCH 12/12] target/ppc: Basic POWER9 bare-metal radix MMU support, Cédric Le Goater, 2019/02/15
- [Qemu-ppc] [PATCH 09/12] target/ppc: Flush the TLB locally when the LPIDR is written, Cédric Le Goater, 2019/02/15
- [Qemu-ppc] [PATCH 01/12] target/ppc/spapr: Set LPCR:HR when using Radix mode, Cédric Le Goater, 2019/02/15