arm64 will soon require its own callback to initialise services
that are only availably on this architecture. Introduce a hook
that can be overloaded by the architecture.
Signed-off-by: Marc Zyngier
---
arch/arm/include/asm/hypervisor.h | 1 +
arch/arm64/include/asm/hypervisor.h | 1 +
Should a guest desire to enroll into the MMIO guard, allow it to
do so with a command-line option.
Signed-off-by: Marc Zyngier
---
.../admin-guide/kernel-parameters.txt | 3 ++
arch/arm64/include/asm/hypervisor.h | 1 +
arch/arm64/kernel/setup.c | 6 +++
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
---
include/linux/io.h | 3 +++
mm/ioremap.c | 13 -
mm/vmalloc.c | 8
3 files changed, 23 insertions(+), 1
In order to transfer the early mapping state into KVM's MMIO
guard infrastucture, provide a small helper that will retrieve
the associated PTE.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/fixmap.h | 2 ++
arch/arm64/mm/mmu.c | 15 +++
2 files changed, 17
On initialising the MMIO guard infrastructure, register the
earlycon mapping if present.
Signed-off-by: Marc Zyngier
---
arch/arm64/mm/ioremap.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
index d82b63bcc554..a27b58e03c93
Implement the previously defined ioremap/iounmap hooks for arm64,
calling into KVM's MMIO guard if available.
Signed-off-by: Marc Zyngier
---
arch/arm64/mm/ioremap.c | 56 +
1 file changed, 56 insertions(+)
diff --git a/arch/arm64/mm/ioremap.c
Document the hypercalls user for the MMIO guard infrastructure.
Signed-off-by: Marc Zyngier
---
Documentation/virt/kvm/arm/index.rst | 1 +
Documentation/virt/kvm/arm/mmio-guard.rst | 73 +++
2 files changed, 74 insertions(+)
create mode 100644
In order to make debugging easier, expose a new trace point
that triggers when a MMIO check fails.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/mmu.c | 4 +++-
arch/arm64/kvm/trace_arm.h | 17 +
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git
In order for userspace to find out whether the MMIO guard is
exposed to a guest, expose a capability that says so.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/arm.c | 1 +
include/uapi/linux/kvm.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/arch/arm64/kvm/arm.c
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 sure that the S2 is completely discarded on reset of
a vcpu, and remove the flag that enforces the MMIO check.
Signed-off-by: Marc Zyngier
---
kvm_pgtable_stage2_set_owner() could be generalised into a way
to store up to 63 bits in the page tables, as long as we don't
set bit 0.
Let's just do that.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_pgtable.h | 12 +++-
arch/arm64/kvm/hyp/nvhe/mem_protect.c | 14
Plumb in the hypercall interface to allow a guest to discover,
enroll, map and unmap MMIO regions.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/hypercalls.c | 20
include/linux/arm-smccc.h | 28
2 files changed, 48 insertions(+)
diff --git
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.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/mmio.c | 10 ++
1 file changed, 10 insertions(+)
diff --git
KVM/arm64 currently considers that any memory access outside of a
memslot is a MMIO access. This so far has served us very well, but
obviously relies on the guest trusting the host, and especially
userspace to do the right thing.
As we keep on hacking away at pKVM, it becomes obvious that this
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 the regions. Nothing
calls into it yet, so no expected functional change.
Signed-off-by: Marc Zyngier
---
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 we are
doing on the CPU side.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_host.h | 12 +++-
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
---
arch/arm64/kvm/hyp/pgtable.c | 16 ++--
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kvm/hyp/pgtable.c
Hi,
Recently I'm playing around the Nvidia Xavier AGX board, which has VHE
extension support.
In theory, considering the CPU and memory, it should be pretty powerful
compared to boards like RPI CM4.
But to my surprise, KVM runs pretty poor on Xavier.
Just booting the edk2 firmware could
On 2021/7/15 下午5:28, Robin Murphy wrote:
On 2021-07-15 09:55, Qu Wenruo wrote:
Hi,
Recently I'm playing around the Nvidia Xavier AGX board, which has VHE
extension support.
In theory, considering the CPU and memory, it should be pretty
powerful compared to boards like RPI CM4.
But to
On 2021/7/15 下午4:55, Qu Wenruo wrote:
Hi,
Recently I'm playing around the Nvidia Xavier AGX board, which has VHE
extension support.
In theory, considering the CPU and memory, it should be pretty powerful
compared to boards like RPI CM4.
But to my surprise, KVM runs pretty poor on
On Thu, 15 Jul 2021 12:51:49 +0100,
Robin Murphy wrote:
>
> On 2021-07-15 12:11, Marc Zyngier wrote:
> > Hi Alex,
> >
> > On Wed, 14 Jul 2021 16:48:07 +0100,
> > Alexandru Elisei wrote:
> >>
> >> Hi Marc,
> >>
> >> On 7/13/21 2:58 PM, Marc Zyngier wrote:
> >>> A number of the PMU sysregs
On 2021-07-15 12:11, Marc Zyngier wrote:
Hi Alex,
On Wed, 14 Jul 2021 16:48:07 +0100,
Alexandru Elisei wrote:
Hi Marc,
On 7/13/21 2:58 PM, Marc Zyngier wrote:
A number of the PMU sysregs expose reset values that are not in
compliant with the architecture (set bits in the RES0 ranges,
for
Hi Alex,
On Wed, 14 Jul 2021 16:48:07 +0100,
Alexandru Elisei wrote:
>
> Hi Marc,
>
> On 7/13/21 2:58 PM, Marc Zyngier wrote:
> > A number of the PMU sysregs expose reset values that are not in
> > compliant with the architecture (set bits in the RES0 ranges,
> > for example).
> >
> > This in
On Thu, 15 Jul 2021 10:44:32 +0100,
Qu Wenruo wrote:
>
>
>
> On 2021/7/15 下午5:28, Robin Murphy wrote:
> > On 2021-07-15 09:55, Qu Wenruo wrote:
> >> Hi,
> >>
> >> Recently I'm playing around the Nvidia Xavier AGX board, which has
> >> VHE extension support.
> >>
> >> In theory, considering
On Thu, Jul 15, 2021 at 11:00:42AM +0100, Robin Murphy wrote:
> On 2021-07-15 10:44, Qu Wenruo wrote:
> >
> >
> > On 2021/7/15 下午5:28, Robin Murphy wrote:
> > > On 2021-07-15 09:55, Qu Wenruo wrote:
> > > > Hi,
> > > >
> > > > Recently I'm playing around the Nvidia Xavier AGX board, which
> > >
On 2021-07-15 10:44, Qu Wenruo wrote:
On 2021/7/15 下午5:28, Robin Murphy wrote:
On 2021-07-15 09:55, Qu Wenruo wrote:
Hi,
Recently I'm playing around the Nvidia Xavier AGX board, which has
VHE extension support.
In theory, considering the CPU and memory, it should be pretty
powerful
Hi Will,
On 7/14/21 7:20 PM, Will Deacon wrote:
> On Wed, Jul 14, 2021 at 10:56:01AM +0100, Alexandru Elisei wrote:
>> According to ARM DDI 0487G.a, page D9-2930, profiling is disabled when
>> the PE is executing at a higher exception level than the profiling
>> buffer owning exception level.
On 2021-07-15 09:55, Qu Wenruo wrote:
Hi,
Recently I'm playing around the Nvidia Xavier AGX board, which has VHE
extension support.
In theory, considering the CPU and memory, it should be pretty powerful
compared to boards like RPI CM4.
But to my surprise, KVM runs pretty poor on Xavier.
On 7/13/21 3:58 PM, Marc Zyngier wrote:
Hi all,
After some back and forth with Alexandre about patch #3 of this
series, it became apparent that some of the PMU code paths perform
some unnecessary masking, only to hide the fact that some of the PMU
register reset values are not
29 matches
Mail list logo
