mirror of
https://github.com/BobTheBlinker/android_kernel_motorola_sm6375.git
synced 2026-10-28 18:51:56 -04:00
- ARM: GICv3 ITS emulation and various fixes. Removal of the old
VGIC implementation. - s390: support for trapping software breakpoints, nested virtualization (vSIE), the STHYI opcode, initial extensions for CPU model support. - MIPS: support for MIPS64 hosts (32-bit guests only) and lots of cleanups, preliminary to this and the upcoming support for hardware virtualization extensions. - x86: support for execute-only mappings in nested EPT; reduced vmexit latency for TSC deadline timer (by about 30%) on Intel hosts; support for more than 255 vCPUs. - PPC: bugfixes. The ugly bit is the conflicts. A couple of them are simple conflicts due to 4.7 fixes, but most of them are with other trees. There was definitely too much reliance on Acked-by here. Some conflicts are for KVM patches where _I_ gave my Acked-by, but the worst are for this pull request's patches that touch files outside arch/*/kvm. KVM submaintainers should probably learn to synchronize better with arch maintainers, with the latter providing topic branches whenever possible instead of Acked-by. This is what we do with arch/x86. And I should learn to refuse pull requests when linux-next sends scary signals, even if that means that submaintainers have to rebase their branches. Anyhow, here's the list: - arch/x86/kvm/vmx.c: handle_pcommit and EXIT_REASON_PCOMMIT was removed by the nvdimm tree. This tree adds handle_preemption_timer and EXIT_REASON_PREEMPTION_TIMER at the same place. In general all mentions of pcommit have to go. There is also a conflict between a stable fix and this patch, where the stable fix removed the vmx_create_pml_buffer function and its call. - virt/kvm/kvm_main.c: kvm_cpu_notifier was removed by the hotplug tree. This tree adds kvm_io_bus_get_dev at the same place. - virt/kvm/arm/vgic.c: a few final bugfixes went into 4.7 before the file was completely removed for 4.8. - include/linux/irqchip/arm-gic-v3.h: this one is entirely our fault; this is a change that should have gone in through the irqchip tree and pulled by kvm-arm. I think I would have rejected this kvm-arm pull request. The KVM version is the right one, except that it lacks GITS_BASER_PAGES_SHIFT. - arch/powerpc: what a mess. For the idle_book3s.S conflict, the KVM tree is the right one; everything else is trivial. In this case I am not quite sure what went wrong. The commit that is causing the mess (fd7bacbca4, "KVM: PPC: Book3S HV: Fix TB corruption in guest exit path on HMI interrupt", 2016-05-15) touches both arch/powerpc/kernel/ and arch/powerpc/kvm/. It's large, but at 396 insertions/5 deletions I guessed that it wasn't really possible to split it and that the 5 deletions wouldn't conflict. That wasn't the case. - arch/s390: also messy. First is hypfs_diag.c where the KVM tree moved some code and the s390 tree patched it. You have to reapply the relevant part of commits6c22c98637, plus all ofe030c1125e, to arch/s390/kernel/diag.c. Or pick the linux-next conflict resolution from http://marc.info/?l=kvm&m=146717549531603&w=2. Second, there is a conflict in gmap.c between a stable fix and 4.8. The KVM version here is the correct one. I have pushed my resolution at refs/heads/merge-20160802 (commit 3d1f53419842) at git://git.kernel.org/pub/scm/virt/kvm/kvm.git. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAABAgAGBQJXoGm7AAoJEL/70l94x66DugQIAIj703ePAFepB/fCrKHkZZia SGrsBdvAtNsOhr7FQ5qvvjLxiv/cv7CymeuJivX8H+4kuUHUllDzey+RPHYHD9X7 U6n1PdCH9F15a3IXc8tDjlDdOMNIKJixYuq1UyNZMU6NFwl00+TZf9JF8A2US65b x/41W98ilL6nNBAsoDVmCLtPNWAqQ3lajaZELGfcqRQ9ZGKcAYOaLFXHv2YHf2XC qIDMf+slBGSQ66UoATnYV2gAopNlWbZ7n0vO6tE2KyvhHZ1m399aBX1+k8la/0JI 69r+Tz7ZHUSFtmlmyByi5IAB87myy2WQHyAPwj+4vwJkDGPcl0TrupzbG7+T05Y= =42ti -----END PGP SIGNATURE----- Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm Pull KVM updates from Paolo Bonzini: - ARM: GICv3 ITS emulation and various fixes. Removal of the old VGIC implementation. - s390: support for trapping software breakpoints, nested virtualization (vSIE), the STHYI opcode, initial extensions for CPU model support. - MIPS: support for MIPS64 hosts (32-bit guests only) and lots of cleanups, preliminary to this and the upcoming support for hardware virtualization extensions. - x86: support for execute-only mappings in nested EPT; reduced vmexit latency for TSC deadline timer (by about 30%) on Intel hosts; support for more than 255 vCPUs. - PPC: bugfixes. * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (302 commits) KVM: PPC: Introduce KVM_CAP_PPC_HTM MIPS: Select HAVE_KVM for MIPS64_R{2,6} MIPS: KVM: Reset CP0_PageMask during host TLB flush MIPS: KVM: Fix ptr->int cast via KVM_GUEST_KSEGX() MIPS: KVM: Sign extend MFC0/RDHWR results MIPS: KVM: Fix 64-bit big endian dynamic translation MIPS: KVM: Fail if ebase doesn't fit in CP0_EBase MIPS: KVM: Use 64-bit CP0_EBase when appropriate MIPS: KVM: Set CP0_Status.KX on MIPS64 MIPS: KVM: Make entry code MIPS64 friendly MIPS: KVM: Use kmap instead of CKSEG0ADDR() MIPS: KVM: Use virt_to_phys() to get commpage PFN MIPS: Fix definition of KSEGX() for 64-bit KVM: VMX: Add VMCS to CPU's loaded VMCSs before VMPTRLD kvm: x86: nVMX: maintain internal copy of current VMCS KVM: PPC: Book3S HV: Save/restore TM state in H_CEDE KVM: PPC: Book3S HV: Pull out TM state save/restore into separate procedures KVM: arm64: vgic-its: Simplify MAPI error handling KVM: arm64: vgic-its: Make vgic_its_cmd_handle_mapi similar to other handlers KVM: arm64: vgic-its: Turn device_id validation into generic ID validation ...
This commit is contained in:
Linus Torvalds
commit
221bb8a46e
167 changed files with 11780 additions and 9287 deletions
|
|
@ -1482,6 +1482,11 @@ struct kvm_irq_routing_msi {
|
|||
__u32 pad;
|
||||
};
|
||||
|
||||
On x86, address_hi is ignored unless the KVM_X2APIC_API_USE_32BIT_IDS
|
||||
feature of KVM_CAP_X2APIC_API capability is enabled. If it is enabled,
|
||||
address_hi bits 31-8 provide bits 31-8 of the destination id. Bits 7-0 of
|
||||
address_hi must be zero.
|
||||
|
||||
struct kvm_irq_routing_s390_adapter {
|
||||
__u64 ind_addr;
|
||||
__u64 summary_addr;
|
||||
|
|
@ -1583,6 +1588,17 @@ struct kvm_lapic_state {
|
|||
Reads the Local APIC registers and copies them into the input argument. The
|
||||
data format and layout are the same as documented in the architecture manual.
|
||||
|
||||
If KVM_X2APIC_API_USE_32BIT_IDS feature of KVM_CAP_X2APIC_API is
|
||||
enabled, then the format of APIC_ID register depends on the APIC mode
|
||||
(reported by MSR_IA32_APICBASE) of its VCPU. x2APIC stores APIC ID in
|
||||
the APIC_ID register (bytes 32-35). xAPIC only allows an 8-bit APIC ID
|
||||
which is stored in bits 31-24 of the APIC register, or equivalently in
|
||||
byte 35 of struct kvm_lapic_state's regs field. KVM_GET_LAPIC must then
|
||||
be called after MSR_IA32_APICBASE has been set with KVM_SET_MSR.
|
||||
|
||||
If KVM_X2APIC_API_USE_32BIT_IDS feature is disabled, struct kvm_lapic_state
|
||||
always uses xAPIC format.
|
||||
|
||||
|
||||
4.58 KVM_SET_LAPIC
|
||||
|
||||
|
|
@ -1600,6 +1616,10 @@ struct kvm_lapic_state {
|
|||
Copies the input argument into the Local APIC registers. The data format
|
||||
and layout are the same as documented in the architecture manual.
|
||||
|
||||
The format of the APIC ID register (bytes 32-35 of struct kvm_lapic_state's
|
||||
regs field) depends on the state of the KVM_CAP_X2APIC_API capability.
|
||||
See the note in KVM_GET_LAPIC.
|
||||
|
||||
|
||||
4.59 KVM_IOEVENTFD
|
||||
|
||||
|
|
@ -2032,6 +2052,12 @@ registers, find a list below:
|
|||
MIPS | KVM_REG_MIPS_CP0_CONFIG5 | 32
|
||||
MIPS | KVM_REG_MIPS_CP0_CONFIG7 | 32
|
||||
MIPS | KVM_REG_MIPS_CP0_ERROREPC | 64
|
||||
MIPS | KVM_REG_MIPS_CP0_KSCRATCH1 | 64
|
||||
MIPS | KVM_REG_MIPS_CP0_KSCRATCH2 | 64
|
||||
MIPS | KVM_REG_MIPS_CP0_KSCRATCH3 | 64
|
||||
MIPS | KVM_REG_MIPS_CP0_KSCRATCH4 | 64
|
||||
MIPS | KVM_REG_MIPS_CP0_KSCRATCH5 | 64
|
||||
MIPS | KVM_REG_MIPS_CP0_KSCRATCH6 | 64
|
||||
MIPS | KVM_REG_MIPS_COUNT_CTL | 64
|
||||
MIPS | KVM_REG_MIPS_COUNT_RESUME | 64
|
||||
MIPS | KVM_REG_MIPS_COUNT_HZ | 64
|
||||
|
|
@ -2156,7 +2182,7 @@ after pausing the vcpu, but before it is resumed.
|
|||
4.71 KVM_SIGNAL_MSI
|
||||
|
||||
Capability: KVM_CAP_SIGNAL_MSI
|
||||
Architectures: x86
|
||||
Architectures: x86 arm64
|
||||
Type: vm ioctl
|
||||
Parameters: struct kvm_msi (in)
|
||||
Returns: >0 on delivery, 0 if guest blocked the MSI, and -1 on error
|
||||
|
|
@ -2169,10 +2195,22 @@ struct kvm_msi {
|
|||
__u32 address_hi;
|
||||
__u32 data;
|
||||
__u32 flags;
|
||||
__u8 pad[16];
|
||||
__u32 devid;
|
||||
__u8 pad[12];
|
||||
};
|
||||
|
||||
No flags are defined so far. The corresponding field must be 0.
|
||||
flags: KVM_MSI_VALID_DEVID: devid contains a valid value
|
||||
devid: If KVM_MSI_VALID_DEVID is set, contains a unique device identifier
|
||||
for the device that wrote the MSI message.
|
||||
For PCI, this is usually a BFD identifier in the lower 16 bits.
|
||||
|
||||
The per-VM KVM_CAP_MSI_DEVID capability advertises the need to provide
|
||||
the device ID. If this capability is not set, userland cannot rely on
|
||||
the kernel to allow the KVM_MSI_VALID_DEVID flag being set.
|
||||
|
||||
On x86, address_hi is ignored unless the KVM_CAP_X2APIC_API capability is
|
||||
enabled. If it is enabled, address_hi bits 31-8 provide bits 31-8 of the
|
||||
destination id. Bits 7-0 of address_hi must be zero.
|
||||
|
||||
|
||||
4.71 KVM_CREATE_PIT2
|
||||
|
|
@ -2520,6 +2558,7 @@ Parameters: struct kvm_device_attr
|
|||
Returns: 0 on success, -1 on error
|
||||
Errors:
|
||||
ENXIO: The group or attribute is unknown/unsupported for this device
|
||||
or hardware support is missing.
|
||||
EPERM: The attribute cannot (currently) be accessed this way
|
||||
(e.g. read-only attribute, or attribute that only makes
|
||||
sense when the device is in a different state)
|
||||
|
|
@ -2547,6 +2586,7 @@ Parameters: struct kvm_device_attr
|
|||
Returns: 0 on success, -1 on error
|
||||
Errors:
|
||||
ENXIO: The group or attribute is unknown/unsupported for this device
|
||||
or hardware support is missing.
|
||||
|
||||
Tests whether a device supports a particular attribute. A successful
|
||||
return indicates the attribute is implemented. It does not necessarily
|
||||
|
|
@ -3803,6 +3843,42 @@ Allows use of runtime-instrumentation introduced with zEC12 processor.
|
|||
Will return -EINVAL if the machine does not support runtime-instrumentation.
|
||||
Will return -EBUSY if a VCPU has already been created.
|
||||
|
||||
7.7 KVM_CAP_X2APIC_API
|
||||
|
||||
Architectures: x86
|
||||
Parameters: args[0] - features that should be enabled
|
||||
Returns: 0 on success, -EINVAL when args[0] contains invalid features
|
||||
|
||||
Valid feature flags in args[0] are
|
||||
|
||||
#define KVM_X2APIC_API_USE_32BIT_IDS (1ULL << 0)
|
||||
#define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK (1ULL << 1)
|
||||
|
||||
Enabling KVM_X2APIC_API_USE_32BIT_IDS changes the behavior of
|
||||
KVM_SET_GSI_ROUTING, KVM_SIGNAL_MSI, KVM_SET_LAPIC, and KVM_GET_LAPIC,
|
||||
allowing the use of 32-bit APIC IDs. See KVM_CAP_X2APIC_API in their
|
||||
respective sections.
|
||||
|
||||
KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK must be enabled for x2APIC to work
|
||||
in logical mode or with more than 255 VCPUs. Otherwise, KVM treats 0xff
|
||||
as a broadcast even in x2APIC mode in order to support physical x2APIC
|
||||
without interrupt remapping. This is undesirable in logical mode,
|
||||
where 0xff represents CPUs 0-7 in cluster 0.
|
||||
|
||||
7.8 KVM_CAP_S390_USER_INSTR0
|
||||
|
||||
Architectures: s390
|
||||
Parameters: none
|
||||
|
||||
With this capability enabled, all illegal instructions 0x0000 (2 bytes) will
|
||||
be intercepted and forwarded to user space. User space can use this
|
||||
mechanism e.g. to realize 2-byte software breakpoints. The kernel will
|
||||
not inject an operating exception for these instructions, user space has
|
||||
to take care of that.
|
||||
|
||||
This capability can be enabled dynamically even if VCPUs were already
|
||||
created and are running.
|
||||
|
||||
8. Other capabilities.
|
||||
----------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -4,16 +4,22 @@ ARM Virtual Generic Interrupt Controller (VGIC)
|
|||
Device types supported:
|
||||
KVM_DEV_TYPE_ARM_VGIC_V2 ARM Generic Interrupt Controller v2.0
|
||||
KVM_DEV_TYPE_ARM_VGIC_V3 ARM Generic Interrupt Controller v3.0
|
||||
KVM_DEV_TYPE_ARM_VGIC_ITS ARM Interrupt Translation Service Controller
|
||||
|
||||
Only one VGIC instance may be instantiated through either this API or the
|
||||
legacy KVM_CREATE_IRQCHIP api. The created VGIC will act as the VM interrupt
|
||||
controller, requiring emulated user-space devices to inject interrupts to the
|
||||
VGIC instead of directly to CPUs.
|
||||
Only one VGIC instance of the V2/V3 types above may be instantiated through
|
||||
either this API or the legacy KVM_CREATE_IRQCHIP api. The created VGIC will
|
||||
act as the VM interrupt controller, requiring emulated user-space devices to
|
||||
inject interrupts to the VGIC instead of directly to CPUs.
|
||||
|
||||
Creating a guest GICv3 device requires a host GICv3 as well.
|
||||
GICv3 implementations with hardware compatibility support allow a guest GICv2
|
||||
as well.
|
||||
|
||||
Creating a virtual ITS controller requires a host GICv3 (but does not depend
|
||||
on having physical ITS controllers).
|
||||
There can be multiple ITS controllers per guest, each of them has to have
|
||||
a separate, non-overlapping MMIO region.
|
||||
|
||||
Groups:
|
||||
KVM_DEV_ARM_VGIC_GRP_ADDR
|
||||
Attributes:
|
||||
|
|
@ -39,6 +45,13 @@ Groups:
|
|||
Only valid for KVM_DEV_TYPE_ARM_VGIC_V3.
|
||||
This address needs to be 64K aligned.
|
||||
|
||||
KVM_VGIC_V3_ADDR_TYPE_ITS (rw, 64-bit)
|
||||
Base address in the guest physical address space of the GICv3 ITS
|
||||
control register frame. The ITS allows MSI(-X) interrupts to be
|
||||
injected into guests. This extension is optional. If the kernel
|
||||
does not support the ITS, the call returns -ENODEV.
|
||||
Only valid for KVM_DEV_TYPE_ARM_VGIC_ITS.
|
||||
This address needs to be 64K aligned and the region covers 128K.
|
||||
|
||||
KVM_DEV_ARM_VGIC_GRP_DIST_REGS
|
||||
Attributes:
|
||||
|
|
@ -109,8 +122,8 @@ Groups:
|
|||
KVM_DEV_ARM_VGIC_GRP_CTRL
|
||||
Attributes:
|
||||
KVM_DEV_ARM_VGIC_CTRL_INIT
|
||||
request the initialization of the VGIC, no additional parameter in
|
||||
kvm_device_attr.addr.
|
||||
request the initialization of the VGIC or ITS, no additional parameter
|
||||
in kvm_device_attr.addr.
|
||||
Errors:
|
||||
-ENXIO: VGIC not properly configured as required prior to calling
|
||||
this attribute
|
||||
|
|
|
|||
|
|
@ -20,7 +20,8 @@ Enables Collaborative Memory Management Assist (CMMA) for the virtual machine.
|
|||
|
||||
1.2. ATTRIBUTE: KVM_S390_VM_MEM_CLR_CMMA
|
||||
Parameters: none
|
||||
Returns: 0
|
||||
Returns: -EINVAL if CMMA was not enabled
|
||||
0 otherwise
|
||||
|
||||
Clear the CMMA status for all guest pages, so any pages the guest marked
|
||||
as unused are again used any may not be reclaimed by the host.
|
||||
|
|
@ -85,6 +86,90 @@ Returns: -EBUSY in case 1 or more vcpus are already activated (only in write
|
|||
-ENOMEM if not enough memory is available to process the ioctl
|
||||
0 in case of success
|
||||
|
||||
2.3. ATTRIBUTE: KVM_S390_VM_CPU_MACHINE_FEAT (r/o)
|
||||
|
||||
Allows user space to retrieve available cpu features. A feature is available if
|
||||
provided by the hardware and supported by kvm. In theory, cpu features could
|
||||
even be completely emulated by kvm.
|
||||
|
||||
struct kvm_s390_vm_cpu_feat {
|
||||
__u64 feat[16]; # Bitmap (1 = feature available), MSB 0 bit numbering
|
||||
};
|
||||
|
||||
Parameters: address of a buffer to load the feature list from.
|
||||
Returns: -EFAULT if the given address is not accessible from kernel space.
|
||||
0 in case of success.
|
||||
|
||||
2.4. ATTRIBUTE: KVM_S390_VM_CPU_PROCESSOR_FEAT (r/w)
|
||||
|
||||
Allows user space to retrieve or change enabled cpu features for all VCPUs of a
|
||||
VM. Features that are not available cannot be enabled.
|
||||
|
||||
See 2.3. for a description of the parameter struct.
|
||||
|
||||
Parameters: address of a buffer to store/load the feature list from.
|
||||
Returns: -EFAULT if the given address is not accessible from kernel space.
|
||||
-EINVAL if a cpu feature that is not available is to be enabled.
|
||||
-EBUSY if at least one VCPU has already been defined.
|
||||
0 in case of success.
|
||||
|
||||
2.5. ATTRIBUTE: KVM_S390_VM_CPU_MACHINE_SUBFUNC (r/o)
|
||||
|
||||
Allows user space to retrieve available cpu subfunctions without any filtering
|
||||
done by a set IBC. These subfunctions are indicated to the guest VCPU via
|
||||
query or "test bit" subfunctions and used e.g. by cpacf functions, plo and ptff.
|
||||
|
||||
A subfunction block is only valid if KVM_S390_VM_CPU_MACHINE contains the
|
||||
STFL(E) bit introducing the affected instruction. If the affected instruction
|
||||
indicates subfunctions via a "query subfunction", the response block is
|
||||
contained in the returned struct. If the affected instruction
|
||||
indicates subfunctions via a "test bit" mechanism, the subfunction codes are
|
||||
contained in the returned struct in MSB 0 bit numbering.
|
||||
|
||||
struct kvm_s390_vm_cpu_subfunc {
|
||||
u8 plo[32]; # always valid (ESA/390 feature)
|
||||
u8 ptff[16]; # valid with TOD-clock steering
|
||||
u8 kmac[16]; # valid with Message-Security-Assist
|
||||
u8 kmc[16]; # valid with Message-Security-Assist
|
||||
u8 km[16]; # valid with Message-Security-Assist
|
||||
u8 kimd[16]; # valid with Message-Security-Assist
|
||||
u8 klmd[16]; # valid with Message-Security-Assist
|
||||
u8 pckmo[16]; # valid with Message-Security-Assist-Extension 3
|
||||
u8 kmctr[16]; # valid with Message-Security-Assist-Extension 4
|
||||
u8 kmf[16]; # valid with Message-Security-Assist-Extension 4
|
||||
u8 kmo[16]; # valid with Message-Security-Assist-Extension 4
|
||||
u8 pcc[16]; # valid with Message-Security-Assist-Extension 4
|
||||
u8 ppno[16]; # valid with Message-Security-Assist-Extension 5
|
||||
u8 reserved[1824]; # reserved for future instructions
|
||||
};
|
||||
|
||||
Parameters: address of a buffer to load the subfunction blocks from.
|
||||
Returns: -EFAULT if the given address is not accessible from kernel space.
|
||||
0 in case of success.
|
||||
|
||||
2.6. ATTRIBUTE: KVM_S390_VM_CPU_PROCESSOR_SUBFUNC (r/w)
|
||||
|
||||
Allows user space to retrieve or change cpu subfunctions to be indicated for
|
||||
all VCPUs of a VM. This attribute will only be available if kernel and
|
||||
hardware support are in place.
|
||||
|
||||
The kernel uses the configured subfunction blocks for indication to
|
||||
the guest. A subfunction block will only be used if the associated STFL(E) bit
|
||||
has not been disabled by user space (so the instruction to be queried is
|
||||
actually available for the guest).
|
||||
|
||||
As long as no data has been written, a read will fail. The IBC will be used
|
||||
to determine available subfunctions in this case, this will guarantee backward
|
||||
compatibility.
|
||||
|
||||
See 2.5. for a description of the parameter struct.
|
||||
|
||||
Parameters: address of a buffer to store/load the subfunction blocks from.
|
||||
Returns: -EFAULT if the given address is not accessible from kernel space.
|
||||
-EINVAL when reading, if there was no write yet.
|
||||
-EBUSY if at least one VCPU has already been defined.
|
||||
0 in case of success.
|
||||
|
||||
3. GROUP: KVM_S390_VM_TOD
|
||||
Architectures: s390
|
||||
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ In mmu_spte_clear_track_bits():
|
|||
old_spte = *spte;
|
||||
|
||||
/* 'if' condition is satisfied. */
|
||||
if (old_spte.Accssed == 1 &&
|
||||
if (old_spte.Accessed == 1 &&
|
||||
old_spte.W == 0)
|
||||
spte = 0ull;
|
||||
on fast page fault path:
|
||||
|
|
@ -102,7 +102,7 @@ In mmu_spte_clear_track_bits():
|
|||
old_spte = xchg(spte, 0ull)
|
||||
|
||||
|
||||
if (old_spte.Accssed == 1)
|
||||
if (old_spte.Accessed == 1)
|
||||
kvm_set_pfn_accessed(spte.pfn);
|
||||
if (old_spte.Dirty == 1)
|
||||
kvm_set_pfn_dirty(spte.pfn);
|
||||
|
|
|
|||
Loading…
Reference in a new issue