On 13/04/18 14:21, Peter Maydell wrote:
On 27 March 2018 at 14:15, Suzuki K Poulose <suzuki.poulose@xxxxxxx> wrote:
Expose the maximum physical address size supported by the host
for a VM. This could be later used by the userspace to choose the
appropriate size for a given VM. The limit is determined as the
minimum of actual CPU limit, the kernel limit (i.e, either 48 or 52)
and the stage2 page table support limit (which is 40bits at the moment).
For backward compatibility, we support a minimum of 40bits. The limit
will be lifted as we add support for the stage2 to support the host
kernel PA limit.
This value may be different from what is exposed to the VM via
CPU ID registers. The limit only applies to the stage2 page table.
Cc: Christoffer Dall <cdall@xxxxxxxxxx>
Cc: Marc Zyngier <marc.zyngier@xxxxxxx>
Cc: Peter Maydel <peter.maydell@xxxxxxxxxx>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@xxxxxxx>
---
Documentation/virtual/kvm/api.txt | 14 ++++++++++++++
arch/arm/include/asm/kvm_mmu.h | 5 +++++
arch/arm64/include/asm/kvm_mmu.h | 5 +++++
include/uapi/linux/kvm.h | 6 ++++++
virt/kvm/arm/arm.c | 6 ++++++
5 files changed, 36 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 792fa87..55908a8 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -3500,6 +3500,20 @@ Returns: 0 on success; -1 on error
This ioctl can be used to unregister the guest memory region registered
with KVM_MEMORY_ENCRYPT_REG_REGION ioctl above.
+4.113 KVM_ARM_GET_MAX_VM_PHYS_SHIFT
+Capability: basic
+Architectures: arm, arm64
+Type: system ioctl
+Parameters: none
+Returns: log2(Maximum physical address space size) supported by the
+hyperviosr.
typo: "hypervisor".
Will fix it.
+
+This ioctl can be used to identify the maximum physical address space size
+supported by the hypervisor.
Is that the physical address space on the host, or the physical
address space size we present to the guest?
It is the size of the address space we present to the guest. I will update
the documentation to make it more clear.
The returned value indicates the maximum size
+of the address that can be resolved by the stage2 translation table on
+arm/arm64. On arm64, the value is decided based on the host kernel
+configuration and the system wide safe value of ID_AA64MMFR0_EL1:PARange.
+This may not match the value exposed to the VM in CPU ID registers.
Isn't it likely to confuse the guest if we lie to it about the PA range it
sees? When would the two values differ?
On a heterogeneous system, the guest could see different values
of PARange on the same VCPU. So that is not safe for a guest at the moment.
Ideally, we should emulate the PARange to provide the system wide safe value, which the
guest can read.
We don't touch the emulation of PARange in the ID registers in this set.
All we do is (in the next patches) limiting the address space size provided
to the guest. May be we could update PARange to the limit imposed and emulate
the field.
Do we also need a 'set' operation, so userspace can create a VM
that has a 40 bit userspace on a CPU that supports more than that,
or does it just work?
It just works as before, creating a 40bit userspace, without any additional
steps. All we do is, allowing to create a VM with bigger address space
by specifying the size in the "type" field. The other question is, does
it really matter what a guest sees in PARange and what it is provided
with ? e.g, on my Juno, the A53's have 40bit and A57 has 44bit, while
the system uses only 40bit.
This will be true even with the new change. i.e, we don't allow a size
beyond the limit supported by all the CPUs on the system.
What's the x86 API for KVM to tell userspace about physical address
range restrictions?
From a quick look, the limit comes from cpuid (leaf 0x80000008 ?). So, it
could be via the existing per-VCPU get/set_cpuid{,2}() API on x86.
Suzuki
