Hi Krishna,
On 3/15/21 7:04 PM, Krishna Reddy wrote:
> Tested-by: Krishna Reddy
>
>> 1) pass the guest stage 1 configuration
>
> Validated Nested SMMUv3 translations for NVMe PCIe device from Guest VM along
> with patch series "v11 SMMUv3 Nested Stage Setup (VFIO part)" and QEMU patch
>
Tested-by: Krishna Reddy
> 1) pass the guest stage 1 configuration
> 3) invalidate stage 1 related caches
Validated Nested SMMUv3 translations for NVMe PCIe device from Guest VM along
with patch series "v13 SMMUv3 Nested Stage Setup (IOMMU part)" and QEMU patch
series "vSMMUv3/pSMMUv3 2 stage
Tested-by: Krishna Reddy
> 1) pass the guest stage 1 configuration
Validated Nested SMMUv3 translations for NVMe PCIe device from Guest VM along
with patch series "v11 SMMUv3 Nested Stage Setup (VFIO part)" and QEMU patch
series "vSMMUv3/pSMMUv3 2 stage VFIO integration" from
In order to keep the code readable, move the host-save/guest-restore
sequences in their own functions, with the following changes:
- the hypervisor ZCR is now set from C code
- ZCR_EL2 is always used as the EL2 accessor
This results in some minor assembler macro rework.
No functional change
This series enables SVE support for KVM on nVHE hardware (or more
likely, software models), and is an alternative to Daniel's patch[1]
which has gone through 3 versions, but still has a number of issues.
Instead of waiting for things to happen, I decided to try and see what
I could come up with.
When running on nVHE, and that the vcpu supports SVE, map the
SVE state at EL2 so that KVM can access it.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/fpsimd.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index
The vcpu_sve_pffr() returns a pointer, which can be an interesting
thing to do on nVHE. Wrap the pointer with kern_hyp_va(), and
take this opportunity to remove the unnecessary casts (sve_state
being a void *).
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_host.h | 4 ++--
1 file
Make sure the guest's ZCR_EL1 is saved before we save/flush the
state. This will be useful in later patches.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/fpsimd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
index
ZCR_EL2 controls the upper bound for ZCR_EL1, and is set to
a potentially lower limit when the guest uses SVE.
In order to restore the SVE state on the EL1 host, we must first
reset ZCR_EL2 to its original value.
Provide a hypervall that perform this reset.
Signed-off-by: Marc Zyngier
---
Implement the SVE save/restore for nVHE, following a similar
logic to that of the VHE implementation:
- the SVE state is switched on trap from EL1 to EL2
- no further changes to ZCR_EL2 occur as long as the guest isn't
preempted or exit to userspace
- on vcpu_put(), ZCR_EL2 is reset to its
Switch to the unified EL1 accessors for ZCR_EL1, which will make
things easier for nVHE support.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/fpsimd.c | 3 ++-
arch/arm64/kvm/hyp/include/hyp/switch.h | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git
as we are about to change the way KVM deals with SVE, provide
KVM with its own save/restore SVE primitives.
No functional change intended.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/fpsimdmacros.h | 2 ++
arch/arm64/include/asm/kvm_hyp.h| 2 ++
The KVM code contains a number of "sve_vq_from_vl(vcpu->arch.sve_max_vl)"
instances, and we are about to add more.
Introduce vcpu_sve_vq() as a shorthand for this expression.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_host.h | 4 +++-
arch/arm64/kvm/guest.c
From: Daniel Kiss
Now that KVM is equipped to deal with SVE on nVHE, remove the code
preventing it from being used as well as the bits of documentation
that were mentioning the incompatibility.
Signed-off-by: Daniel Kiss
Signed-off-by: Marc Zyngier
---
arch/arm64/Kconfig| 7
The MMIO region of a device maybe huge (GB level), try to use
block mapping in stage2 to speedup both map and unmap.
Compared to normal memory mapping, we should consider two more
points when try block mapping for MMIO region:
1. For normal memory mapping, the PA(host physical address) and
HVA
Hi all,
We have two pathes to build stage2 mapping for MMIO regions.
Create time's path and stage2 fault path.
Patch#1 removes the creation time's mapping of MMIO regions
Patch#2 tries stage2 block mapping for host device MMIO at fault path
Thanks,
Keqian
Keqian Zhu (2):
kvm/arm64: Remove
The MMIO regions may be unmapped for many reasons and can be remapped
by stage2 fault path. Map MMIO regions at creation time becomes a
minor optimization and makes these two mapping path hard to sync.
Remove the mapping code while keep the useful sanity check.
Signed-off-by: Keqian Zhu
---
On Tuesday 16 Mar 2021 at 10:13:03 (+), Marc Zyngier wrote:
> diff --git a/arch/arm64/kvm/hyp/fpsimd.S b/arch/arm64/kvm/hyp/fpsimd.S
> index 01f114aa47b0..e4010d1acb79 100644
> --- a/arch/arm64/kvm/hyp/fpsimd.S
> +++ b/arch/arm64/kvm/hyp/fpsimd.S
> @@ -19,3 +19,13 @@
On Tue, 16 Mar 2021 10:45:55 +,
Quentin Perret wrote:
>
> On Tuesday 16 Mar 2021 at 10:13:10 (+), Marc Zyngier wrote:
> > diff --git a/arch/arm64/include/asm/kvm_host.h
> > b/arch/arm64/include/asm/kvm_host.h
> > index c4afe3d3397f..9108ccc80653 100644
> > ---
On Mon, 15 Mar 2021 15:46:09 +
Alexandru Elisei wrote:
Hi Alex,
> On 3/4/21 3:00 PM, Andre Przywara wrote:
> > On Sat, 27 Feb 2021 10:41:57 +
> > Alexandru Elisei wrote:
> >
> >> Compute the dcache line size when doing dcache maintenance instead of using
> >> a global variable
On Tue, 16 Mar 2021 14:24:38 +,
Andrew Scull wrote:
>
> On Tue, Mar 16, 2021 at 10:13:10AM +, Marc Zyngier wrote:
> > ZCR_EL2 controls the upper bound for ZCR_EL1, and is set to
> > a potentially lower limit when the guest uses SVE.
> >
> > In order to restore the SVE state on the EL1
On Tue, 16 Mar 2021 10:31:46 +,
Quentin Perret wrote:
>
> On Tuesday 16 Mar 2021 at 10:13:03 (+), Marc Zyngier wrote:
> > diff --git a/arch/arm64/kvm/hyp/fpsimd.S b/arch/arm64/kvm/hyp/fpsimd.S
> > index 01f114aa47b0..e4010d1acb79 100644
> > --- a/arch/arm64/kvm/hyp/fpsimd.S
> > +++
On Tuesday 16 Mar 2021 at 10:13:10 (+), Marc Zyngier wrote:
> diff --git a/arch/arm64/include/asm/kvm_host.h
> b/arch/arm64/include/asm/kvm_host.h
> index c4afe3d3397f..9108ccc80653 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -593,7 +593,9
On Tuesday 16 Mar 2021 at 13:28:42 (+0100), Mate Toth-Pal wrote:
> Testing the latest version of the patchset, we seem to have found another
> thing related to FEAT_S2FWB.
Argh! I wish I could put my hands on hardware with FWB. Thanks again for
the report.
> This function always sets Normal
Hi Andre,
On 3/15/21 3:33 PM, Andre Przywara wrote:
> With the planned retirement of the special ioport emulation code, we
> need to provide an emulation function compatible with the MMIO prototype.
>
> Adjust the trap handler to use that new function, and provide shims to
> implement the old
Instead of masking the guest timer at the source, take advantage of
the SYS_APL_VM_TMR_FIQ_ENA_EL1 register and properly mask the
timers at init time.
For a good measure, add the missing ISB that synchronises all
the previous sysreg accesses.
Signed-off-by: Marc Zyngier
---
The CPUs in the Apple M1 SoC partially implement a virtual GICv3
CPU interface, although one that is incapable of HW deactivation
of interrupts.
Advertise the support to KVM.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-apple-aic.c | 7 +++
1 file changed, 7 insertions(+)
diff
In order to deal with these systems that do not offer HW-based
deactivation of interrupts, let implement a SW-based approach:
- When the irq is queued into a LR, treat it as a pure virtual
interrupt and set the EOI flag in the LR.
- When the interrupt state is read back from the LR, force a
We already have the option to attach a callback to an interrupt
to retrieve its pending state. As we are planning to expand this
facility, move this callback into its own data structure.
This will limit the size of individual interrupts as the ops
structures can be shared across multiple
As we are about to add some more things to the timer IRQ
configuration, move this code out of the main timer init code
into its own set of functions.
No functional changes.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/arch_timer.c | 61 ++---
1 file changed,
As the enabling of the guest timer interrupts is done by
accessing a system register, make sure the access is correctly
synchronised.
Signed-off-by: Marc Zyngier
---
drivers/irqchip/irq-apple-aic.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/irqchip/irq-apple-aic.c
In order to deal with the lack of active state, we need to use
the mask/unmask primitives (after all, the active state is just an
additional mask on top of the normal one).
To avoid adding a bunch of ugly conditionals in the timer and vgic
code, let's use a timer-specific irqdomain to deal with
As it turns out, not all the interrupt controllers are able to
expose a vGIC maintenance interrupt as a distrete signal.
And to be fair, it doesn't really matter as all we require is
for *something* to kick us out of guest mode out way or another.
On systems that do not expose a maintenance
As we we now entertain the possibility of FIQ being used on the host,
treat the signalling of a FIQ while running a guest as an IRQ,
causing an exit instead of a HYP panic.
Signed-off-by: Marc Zyngier
---
arch/arm64/kvm/hyp/hyp-entry.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
I've spent the past few weekends trying to see how I could support the
M1 as a KVM host. It started by being pretty ugly, but the end result
is actually not too horrible.
Just a wee bit horrible.
The M1 has no GIC. And as everybody know, "KVM" stands for "The GIC
Emulator". Yes, Avi got the TLA
The vGIC, as architected by ARM, allows a virtual interrupt to
trigger the deactivation of a physical interrupt. This allows
the following interrupt to be delivered without requiring an exit.
However, some implementations have choosen not to implement this,
meaning that we will need some
The vGIC advertising code is unsurprisingly very much tied to
the GIC implementations. However, we are about to extend the
support to lesser implementations.
Let's dissociate the vgic registration from the GIC code and
move it into KVM, where it makes a bit more sense. This also
allows us to mark
On 15/03/21 23:31, Jing Zhang wrote:
We are considering about how to create the file descriptor. It might be risky
to create an extra fd for every vCPU. It will easily hit the fd limit for the
process or the system for machines running a ton of small VMs.
You already have a file descriptor for
On Tue, Mar 16, 2021 at 10:13:10AM +, Marc Zyngier wrote:
> ZCR_EL2 controls the upper bound for ZCR_EL1, and is set to
> a potentially lower limit when the guest uses SVE.
>
> In order to restore the SVE state on the EL1 host, we must first
> reset ZCR_EL2 to its original value.
>
> Provide
On Tuesday 16 Mar 2021 at 12:53:53 (+), Quentin Perret wrote:
> On Tuesday 16 Mar 2021 at 13:28:42 (+0100), Mate Toth-Pal wrote:
> > Changing the value of MT_S2_FWB_NORMAL to 7 would change this behavior, and
> > the resulting memory type would be device.
>
> Sounds like the correct fix here
On 2021-03-15 15:35, Quentin Perret wrote:
+static int host_stage2_idmap(u64 addr)
+{
+ enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_R | KVM_PGTABLE_PROT_W;
+ struct kvm_mem_range range;
+ bool is_memory = find_mem_range(addr, );
+ struct hyp_pool *pool = is_memory ?
On 2021-03-16 15:29, Quentin Perret wrote:
On Tuesday 16 Mar 2021 at 12:53:53 (+), Quentin Perret wrote:
On Tuesday 16 Mar 2021 at 13:28:42 (+0100), Mate Toth-Pal wrote:
Changing the value of MT_S2_FWB_NORMAL to 7 would change this behavior, and
the resulting memory type would be device.
> Hi Krishna,
> On 3/15/21 7:04 PM, Krishna Reddy wrote:
> > Tested-by: Krishna Reddy
> >
> >> 1) pass the guest stage 1 configuration
> >
> > Validated Nested SMMUv3 translations for NVMe PCIe device from Guest VM
> along with patch series "v11 SMMUv3 Nested Stage Setup (VFIO part)" and
> QEMU
On Tuesday 16 Mar 2021 at 16:16:18 (+0100), Mate Toth-Pal wrote:
> On 2021-03-16 15:29, Quentin Perret wrote:
> > On Tuesday 16 Mar 2021 at 12:53:53 (+), Quentin Perret wrote:
> > > On Tuesday 16 Mar 2021 at 13:28:42 (+0100), Mate Toth-Pal wrote:
> > > > Changing the value of MT_S2_FWB_NORMAL
44 matches
Mail list logo
