Merge tag 'kvmarm-for-v4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD
KVM/arm updates for 4.19 - Support for Group0 interrupts in guests - Cache management optimizations for ARMv8.4 systems - Userspace interface for RAS, allowing error retrival and injection - Fault path optimization - Emulated physical timer fixes - Random cleanups
This commit is contained in:
@@ -835,11 +835,13 @@ struct kvm_clock_data {
|
||||
|
||||
Capability: KVM_CAP_VCPU_EVENTS
|
||||
Extended by: KVM_CAP_INTR_SHADOW
|
||||
Architectures: x86
|
||||
Type: vm ioctl
|
||||
Architectures: x86, arm, arm64
|
||||
Type: vcpu ioctl
|
||||
Parameters: struct kvm_vcpu_event (out)
|
||||
Returns: 0 on success, -1 on error
|
||||
|
||||
X86:
|
||||
|
||||
Gets currently pending exceptions, interrupts, and NMIs as well as related
|
||||
states of the vcpu.
|
||||
|
||||
@@ -881,15 +883,64 @@ Only two fields are defined in the flags field:
|
||||
- KVM_VCPUEVENT_VALID_SMM may be set in the flags field to signal that
|
||||
smi contains a valid state.
|
||||
|
||||
ARM/ARM64:
|
||||
|
||||
If the guest accesses a device that is being emulated by the host kernel in
|
||||
such a way that a real device would generate a physical SError, KVM may make
|
||||
a virtual SError pending for that VCPU. This system error interrupt remains
|
||||
pending until the guest takes the exception by unmasking PSTATE.A.
|
||||
|
||||
Running the VCPU may cause it to take a pending SError, or make an access that
|
||||
causes an SError to become pending. The event's description is only valid while
|
||||
the VPCU is not running.
|
||||
|
||||
This API provides a way to read and write the pending 'event' state that is not
|
||||
visible to the guest. To save, restore or migrate a VCPU the struct representing
|
||||
the state can be read then written using this GET/SET API, along with the other
|
||||
guest-visible registers. It is not possible to 'cancel' an SError that has been
|
||||
made pending.
|
||||
|
||||
A device being emulated in user-space may also wish to generate an SError. To do
|
||||
this the events structure can be populated by user-space. The current state
|
||||
should be read first, to ensure no existing SError is pending. If an existing
|
||||
SError is pending, the architecture's 'Multiple SError interrupts' rules should
|
||||
be followed. (2.5.3 of DDI0587.a "ARM Reliability, Availability, and
|
||||
Serviceability (RAS) Specification").
|
||||
|
||||
SError exceptions always have an ESR value. Some CPUs have the ability to
|
||||
specify what the virtual SError's ESR value should be. These systems will
|
||||
advertise KVM_CAP_ARM_SET_SERROR_ESR. In this case exception.has_esr will
|
||||
always have a non-zero value when read, and the agent making an SError pending
|
||||
should specify the ISS field in the lower 24 bits of exception.serror_esr. If
|
||||
the system supports KVM_CAP_ARM_SET_SERROR_ESR, but user-space sets the events
|
||||
with exception.has_esr as zero, KVM will choose an ESR.
|
||||
|
||||
Specifying exception.has_esr on a system that does not support it will return
|
||||
-EINVAL. Setting anything other than the lower 24bits of exception.serror_esr
|
||||
will return -EINVAL.
|
||||
|
||||
struct kvm_vcpu_events {
|
||||
struct {
|
||||
__u8 serror_pending;
|
||||
__u8 serror_has_esr;
|
||||
/* Align it to 8 bytes */
|
||||
__u8 pad[6];
|
||||
__u64 serror_esr;
|
||||
} exception;
|
||||
__u32 reserved[12];
|
||||
};
|
||||
|
||||
4.32 KVM_SET_VCPU_EVENTS
|
||||
|
||||
Capability: KVM_CAP_VCPU_EVENTS
|
||||
Extended by: KVM_CAP_INTR_SHADOW
|
||||
Architectures: x86
|
||||
Type: vm ioctl
|
||||
Architectures: x86, arm, arm64
|
||||
Type: vcpu ioctl
|
||||
Parameters: struct kvm_vcpu_event (in)
|
||||
Returns: 0 on success, -1 on error
|
||||
|
||||
X86:
|
||||
|
||||
Set pending exceptions, interrupts, and NMIs as well as related states of the
|
||||
vcpu.
|
||||
|
||||
@@ -910,6 +961,13 @@ shall be written into the VCPU.
|
||||
|
||||
KVM_VCPUEVENT_VALID_SMM can only be set if KVM_CAP_X86_SMM is available.
|
||||
|
||||
ARM/ARM64:
|
||||
|
||||
Set the pending SError exception state for this VCPU. It is not possible to
|
||||
'cancel' an Serror that has been made pending.
|
||||
|
||||
See KVM_GET_VCPU_EVENTS for the data structure.
|
||||
|
||||
|
||||
4.33 KVM_GET_DEBUGREGS
|
||||
|
||||
@@ -4690,3 +4748,17 @@ This capability indicates that KVM supports paravirtualized Hyper-V TLB Flush
|
||||
hypercalls:
|
||||
HvFlushVirtualAddressSpace, HvFlushVirtualAddressSpaceEx,
|
||||
HvFlushVirtualAddressList, HvFlushVirtualAddressListEx.
|
||||
|
||||
8.19 KVM_CAP_ARM_SET_SERROR_ESR
|
||||
|
||||
Architectures: arm, arm64
|
||||
|
||||
This capability indicates that userspace can specify (via the
|
||||
KVM_SET_VCPU_EVENTS ioctl) the syndrome value reported to the guest when it
|
||||
takes a virtual SError interrupt exception.
|
||||
If KVM advertises this capability, userspace can only specify the ISS field for
|
||||
the ESR syndrome. Other parts of the ESR, such as the EC are generated by the
|
||||
CPU when the exception is taken. If this virtual SError is taken to EL1 using
|
||||
AArch64, this value will be reported in the ISS field of ESR_ELx.
|
||||
|
||||
See KVM_CAP_VCPU_EVENTS for more details.
|
||||
|
||||
@@ -100,6 +100,14 @@ Groups:
|
||||
Note that distributor fields are not banked, but return the same value
|
||||
regardless of the mpidr used to access the register.
|
||||
|
||||
GICD_IIDR.Revision is updated when the KVM implementation is changed in a
|
||||
way directly observable by the guest or userspace. Userspace should read
|
||||
GICD_IIDR from KVM and write back the read value to confirm its expected
|
||||
behavior is aligned with the KVM implementation. Userspace should set
|
||||
GICD_IIDR before setting any other registers to ensure the expected
|
||||
behavior.
|
||||
|
||||
|
||||
The GICD_STATUSR and GICR_STATUSR registers are architecturally defined such
|
||||
that a write of a clear bit has no effect, whereas a write with a set bit
|
||||
clears that value. To allow userspace to freely set the values of these two
|
||||
|
||||
@@ -49,9 +49,15 @@ Groups:
|
||||
index is specified with the vcpu_index field. Note that most distributor
|
||||
fields are not banked, but return the same value regardless of the
|
||||
vcpu_index used to access the register.
|
||||
Limitations:
|
||||
- Priorities are not implemented, and registers are RAZ/WI
|
||||
- Currently only implemented for KVM_DEV_TYPE_ARM_VGIC_V2.
|
||||
|
||||
GICD_IIDR.Revision is updated when the KVM implementation of an emulated
|
||||
GICv2 is changed in a way directly observable by the guest or userspace.
|
||||
Userspace should read GICD_IIDR from KVM and write back the read value to
|
||||
confirm its expected behavior is aligned with the KVM implementation.
|
||||
Userspace should set GICD_IIDR before setting any other registers (both
|
||||
KVM_DEV_ARM_VGIC_GRP_DIST_REGS and KVM_DEV_ARM_VGIC_GRP_CPU_REGS) to ensure
|
||||
the expected behavior. Unless GICD_IIDR has been set from userspace, writes
|
||||
to the interrupt group registers (GICD_IGROUPR) are ignored.
|
||||
Errors:
|
||||
-ENXIO: Getting or setting this register is not yet supported
|
||||
-EBUSY: One or more VCPUs are running
|
||||
@@ -94,9 +100,6 @@ Groups:
|
||||
use the lower 5 bits to communicate with the KVM device and must shift the
|
||||
value left by 3 places to obtain the actual priority mask level.
|
||||
|
||||
Limitations:
|
||||
- Priorities are not implemented, and registers are RAZ/WI
|
||||
- Currently only implemented for KVM_DEV_TYPE_ARM_VGIC_V2.
|
||||
Errors:
|
||||
-ENXIO: Getting or setting this register is not yet supported
|
||||
-EBUSY: One or more VCPUs are running
|
||||
|
||||
Reference in New Issue
Block a user