Add a test case for counter emulation on arm64. A side effect of how KVM
handles physical counter offsetting on non-ECV systems is that the
virtual counter will always hit hardware and the physical could be
emulated. Force emulation by writing a nonzero offset to the physical
counter and compare
KVM/arm64 now allows userspace to adjust the guest virtual counter-timer
via a vCPU device attribute. Test that changes to the virtual
counter-timer offset result in the correct view being presented to the
guest.
Reviewed-by: Andrew Jones
Signed-off-by: Oliver Upton
---
Introduce a KVM selftest to verify that userspace manipulation of the
TSC (via the new vCPU attribute) results in the correct behavior within
the guest.
Reviewed-by: Andrew Jones
Signed-off-by: Oliver Upton
---
tools/testing/selftests/kvm/.gitignore| 1 +
vCPU file descriptors are abstracted away from test code in KVM
selftests, meaning that tests cannot directly access a vCPU's device
attributes. Add helpers that tests can use to get at vCPU device
attributes.
Reviewed-by: Andrew Jones
Signed-off-by: Oliver Upton
---
Add a selftest for the new KVM clock UAPI that was introduced. Ensure
that the KVM clock is consistent between userspace and the guest, and
that the difference in realtime will only ever cause the KVM clock to
advance forward.
Cc: Andrew Jones
Signed-off-by: Oliver Upton
---
Add a new vCPU attribute that allows userspace to directly manipulate
the virtual counter-timer offset. Exposing such an interface allows for
the precise migration of guest virtual counter-timers, as it is an
indepotent interface.
Uphold the existing behavior of writes to CNTVOFF_EL2 for this new
Presently, KVM provides no facilities for correctly migrating a guest
that depends on the physical counter-timer. While most guests (barring
NV, of course) should not depend on the physical counter-timer, an
operator may still wish to provide a consistent view of the physical
counter-timer across
Copy over approximately clean versions of the pvclock headers into
tools. Reconcile headers/symbols missing in tools that are unneeded.
Signed-off-by: Oliver Upton
---
tools/arch/x86/include/asm/pvclock-abi.h | 48 +++
tools/arch/x86/include/asm/pvclock.h | 103
The KVM_CREATE_DEVICE and KVM_{GET,SET}_DEVICE_ATTR ioctls are defined
to return a value of zero on success. As such, tighten the assertions in
the helper functions to only pass if the return code is zero.
Suggested-by: Andrew Jones
Signed-off-by: Oliver Upton
---
KVM's current means of saving/restoring system counters is plagued with
temporal issues. At least on ARM64 and x86, we migrate the guest's
system counter by-value through the respective guest system register
values (cntvct_el0, ia32_tsc). Restoring system counters by-value is
brittle as the state
Handling the migration of TSCs correctly is difficult, in part because
Linux does not provide userspace with the ability to retrieve a (TSC,
realtime) clock pair for a single instant in time. In lieu of a more
convenient facility, KVM can report similar information in the kvm_clock
structure.
Test that userpace adjustment of the guest physical counter-timer
results in the correct view of within the guest.
Reviewed-by: Andrew Jones
Signed-off-by: Oliver Upton
---
.../selftests/kvm/include/aarch64/processor.h | 12
.../kvm/system_counter_offset_test.c | 29
Refactor kvm_synchronize_tsc to make a new function that allows callers
to specify TSC parameters (offset, value, nanoseconds, etc.) explicitly
for the sake of participating in TSC synchronization.
This changes the locking semantics around TSC writes. Writes to the TSC
will now take the pvclock
To date, VMM-directed TSC synchronization and migration has been a bit
messy. KVM has some baked-in heuristics around TSC writes to infer if
the VMM is attempting to synchronize. This is problematic, as it depends
on host userspace writing to the guest's TSC within 1 second of the last
write.
A
On Tue, Jul 27, 2021 at 3:33 AM Paolo Bonzini wrote:
>
> KVM/ARM has an architecture-specific implementation of
> kvm_flush_remote_tlbs; however, unlike the generic one,
> it does not count the flushes in kvm->stat.remote_tlb_flush,
> so that it inexorably remained stuck to zero.
>
>
Hyp checks whether an address range only covers RAM by checking the
start/endpoints against a list of memblock_region structs. However,
the endpoint here is exclusive but internally is treated as inclusive.
Fix the off-by-one error that caused valid address ranges to be
rejected.
Cc: Quentin
Currently range_is_memory finds the corresponding struct memblock_region
for both the lower and upper bounds of the given address range with two
rounds of binary search, and then checks that the two memblocks are the
same. Simplify this by only doing binary search on the lower bound and
then
Hi, here is an off-by-one bug fix and a very minor improvement for
the range_is_memory function in hyp.
David Brazdil (2):
KVM: arm64: Fix off-by-one in range_is_memory
KVM: arm64: Minor optimization of range_is_memory
arch/arm64/kvm/hyp/nvhe/mem_protect.c | 11 ---
1 file changed,
On Monday 26 Jul 2021 at 10:29:01 (+0100), Quentin Perret wrote:
> +static int finalize_mappings(void)
> +{
> + enum kvm_pgtable_prot prot;
> + int ret;
> +
> + /*
> + * The host's .bss and .rodata sections are now conceptually owned by
> + * the hypervisor, so mark them as
Remove the repeated word 'the' from two comments.
Signed-off-by: Jason Wang
---
arch/arm64/kvm/vgic/vgic-mmio-v2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/vgic/vgic-mmio-v2.c
b/arch/arm64/kvm/vgic/vgic-mmio-v2.c
index a016f07adc28..5f9014ae595b
On 28/07/2021 10:41, Marc Zyngier wrote:
> On Tue, 27 Jul 2021 19:10:27 +0100,
> Will Deacon wrote:
>>
>> On Thu, Jul 15, 2021 at 05:31:44PM +0100, Marc Zyngier wrote:
>>> We currently deal with a set of booleans for VM features,
>>> while they could be better represented as set of flags
>>>
Hi Alex,
On Tue, 27 Jul 2021 16:25:34 +0100,
Alexandru Elisei wrote:
>
> Hi Marc,
>
> On 7/26/21 4:35 PM, Marc Zyngier wrote:
> > It is becoming a common need to fetch the PTE for a given address
> > together with its level. Add such a helper.
> >
> > Signed-off-by: Marc Zyngier
> > ---
> >
On Tue, 27 Jul 2021 19:12:04 +0100,
Will Deacon wrote:
>
> On Thu, Jul 15, 2021 at 05:31:55PM +0100, Marc Zyngier wrote:
> > Add a pair of hooks (ioremap_page_range_hook/iounmap_page_range_hook)
> > that can be implemented by an architecture.
> >
> > Signed-off-by: Marc Zyngier
> > ---
> >
On Tue, 27 Jul 2021 19:11:46 +0100,
Will Deacon wrote:
>
> On Thu, Jul 15, 2021 at 05:31:50PM +0100, Marc Zyngier wrote:
> > Plumb in the hypercall interface to allow a guest to discover,
> > enroll, map and unmap MMIO regions.
> >
> > Signed-off-by: Marc Zyngier
> > ---
> >
On Tue, 27 Jul 2021 19:11:33 +0100,
Will Deacon wrote:
>
> On Thu, Jul 15, 2021 at 05:31:49PM +0100, Marc Zyngier wrote:
> > As we now keep information in the S2PT, we must be careful not
> > to keep it across a VM reboot, which could otherwise lead to
> > interesting problems.
> >
> > Make
On Tue, 27 Jul 2021 19:11:21 +0100,
Will Deacon wrote:
>
> On Thu, Jul 15, 2021 at 05:31:48PM +0100, Marc Zyngier wrote:
> > Plumb the MMIO checking code into the MMIO fault handling code.
> > Nothing allows a region to be registered yet, so there should be
> > no funtional change either.
>
>
On Tue, 27 Jul 2021 19:11:08 +0100,
Will Deacon wrote:
>
> On Thu, Jul 15, 2021 at 05:31:47PM +0100, Marc Zyngier wrote:
> > Introduce the infrastructure required to identify an IPA region
> > that is expected to be used as an MMIO window.
> >
> > This include mapping, unmapping and checking
On Tue, 27 Jul 2021 19:10:45 +0100,
Will Deacon wrote:
>
> On Thu, Jul 15, 2021 at 05:31:45PM +0100, Marc Zyngier wrote:
> > Make sure we don't issue CMOs when mapping something that
> > is not a memory address in the S2 page tables.
> >
> > Signed-off-by: Marc Zyngier
> > ---
> >
On Tue, 27 Jul 2021 19:10:27 +0100,
Will Deacon wrote:
>
> On Thu, Jul 15, 2021 at 05:31:44PM +0100, Marc Zyngier wrote:
> > We currently deal with a set of booleans for VM features,
> > while they could be better represented as set of flags
> > contained in an unsigned long, similarily to what
29 matches
Mail list logo
