t;>> 2. qemu handles supported SDEI calls just as the spec says for what a
>>> hypervisor should do for a guest OS.
[pulled point 3 out to discuss separately]
>> Something like that.
>>
>> Interactions between SDEI and PSCI would need some thought: for example,
>>
Hi KarimAllah,
On 12/07/2019 09:22, KarimAllah Ahmed wrote:
> Valid RAM can live outside kernel control (e.g. using "mem=" command-line
> parameter). This memory can still be used as valid guest memory for KVM. So
> ensure that we validate that this memory is definitely not "RAM" before
> assuming
ned int esr,
> struct pt_regs *regs)
> [ESR_ELx_EC_CP14_LS]= "CP14 LDC/STC",
> [ESR_ELx_EC_FP_ASIMD] = "ASIMD",
> [ESR_ELx_EC_CP10_ID]= "CP10 MRC/VMRS",
> + [ESR_ELx_EC_PAC]= "PAC",
&
t;
> This patch removes the maintenance on rollover for VIPT and PIPT
> I-caches. At the same time, the unnecessary colons are removed from the
> asm statement to make it more legible.
Makes sense!
Reviewed-by: James Morse
Thanks,
James
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
KVM: Avoid marking pages as XN in Stage-2 if
CTR_EL0.DIC is set")
Signed-off-by: James Morse
---
arch/arm64/include/asm/pgtable-prot.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/pgtable-prot.h
b/arch/arm64/include/asm/pgtable-prot.h
index 92d
Hi Heyi,
On 24/09/2019 16:20, Heyi Guo wrote:
> Add new KVM capability "KVM_CAP_FORWARD_HYPERCALL" for user space to
> probe whether KVM supports forwarding hypercall.
>
> The capability should be enabled by user space explicitly, for we
> don't want user space application to deal with unexpected
Hi Heyi,
On 24/09/2019 16:20, Heyi Guo wrote:
> As more SMC/HVC usages emerge on arm64 platforms, like SDEI, it makes
> sense for kvm to have the capability of forwarding such calls to user
> space for further emulation.
(what do you mean by further? Doesn't user-space have to do all of it?)
>
Hi Christoffer,
On 09/09/2019 13:13, Christoffer Dall wrote:
> For a long time, if a guest accessed memory outside of a memslot using
> any of the load/store instructions in the architecture which doesn't
> supply decoding information in the ESR_EL2 (the ISV bit is not set), the
> kernel would pri
f guest state
needs to be
as you have it here, before the guest TTBRs are written.
Restore of the host state needs to only clear the EPDx bits after the TTBRs are
written,
and sync'd.
Assuming I'm making sense ... with that:
Reviewed-by: James Morse
for the series.
> + }
&
Hi Marc,
On 25/09/2019 12:19, Marc Zyngier wrote:
> Now that everything is in place, let's get the ball rolling
> by allowing the corresponding config option to be selected.
> Also add the required information to silicon_arrata.rst.
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 3
Hi Marc,
On 25/09/2019 12:19, Marc Zyngier wrote:
> When erratum 1319367 is being worked around, special care must
> be taken not to allow the page table walker to populate TLBs
> while we have the stage-2 translation enabled (which would otherwise
> result in a bizare mix of the host S1 and the g
de asm/kvm_mmu.h, you need to
include
linux/kvm_host.h first)
We end up calling it unconditionally, but I don't think that matters, both
callers do the
right thing.
With that:
Reviewed-by: James Morse
Thanks,
James
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Hi Heyi,
On 09/10/2019 13:33, Guoheyi wrote:
> On 2019/10/2 1:19, James Morse wrote:
>> On 24/09/2019 16:20, Heyi Guo wrote:
>>> As more SMC/HVC usages emerge on arm64 platforms, like SDEI, it makes
>>> sense for kvm to have the capability of forwarding such calls to
Hi Shannon,
On 24/10/2019 11:27, Shannon Zhao wrote:
> Curently KVM ARM64 doesn't support to compile as a kernel module. It's
> useful to compile KVM as a module.
> For example, it could reload kvm without rebooting host machine.
What problem does this solve?
KVM has some funny requirements tha
results in a minor reorganisation of the load sequence, without
> any functional change.
Reviewed-by: James Morse
Thanks,
James
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
t S1 and the guest S2).
>
> We enforce this by setting TCR_EL1.EPD{0,1} before restoring the S2
> configuration, and clear the same bits after having disabled S2.
Reviewed-by: James Morse
Thanks,
James
___
kvmarm mailing list
kvmarm@lists.
stage-2 is disabled
> - All host system registers are restored
Reviewed-by: James Morse
(whitespace nit below)
> diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
> index 69e10b29cbd0..5765b17c38c7 100644
> --- a/arch/arm64/kvm/hyp/switch.c
> +++ b/arch/arm64/kvm/hyp/
Hi Marc,
On 12/12/2019 11:33, Marc Zyngier wrote:
> On 2019-12-11 16:56, Marc Zyngier wrote:
>> When we check for a poisoned page, we use the VMA to tell userspace
>> about the looming disaster. But we pass a pointer to this VMA
>> after having released the mmap_sem, which isn't a good idea.
Soun
s to be careful when dealing with mapping size, cache
> management, and to handle potential execution of a device mapping.
Reviewed-by: James Morse
Thanks,
James
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Hi Christoffer,
On 13/12/2019 09:22, Christoffer Dall wrote:
> On Wed, Dec 11, 2019 at 04:56:49PM +, Marc Zyngier wrote:
>> When we check for a poisoned page, we use the VMA to tell userspace
>> about the looming disaster. But we pass a pointer to this VMA
>> after having released the mmap_sem
ed-by: Marc Zyngier
Signed-off-by: James Morse
---
Based on Marc's patch:
Link: lore.kernel.org/r/20191211165651.7889-3-...@kernel.org
virt/kvm/arm/mmu.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
index 38
Hi Marc,
On 13/12/2019 18:25, Marc Zyngier wrote:
> If userspace issues a munmap() on a set of pages, there is no
> expectation that the pages are cleaned to the PoC.
(Pedantry: Clean and invalidate. If the guest wrote through a device mapping,
we ditch any
clean+stale lines with this path, mean
Hi Marc,
On 18/12/2019 15:30, Marc Zyngier wrote:
> On 2019-12-18 15:07, James Morse wrote:
>> On 13/12/2019 18:25, Marc Zyngier wrote:
>>> If userspace issues a munmap() on a set of pages, there is no
>>> expectation that the pages are cleaned to the PoC.
>>>
he beholder. I don't know why an imp-def exception was picked...
Thanks,
James Morse (2):
KVM: arm: fix DFSR setting for non-LPAE aarch32 guests
KVM: arm: Make inject_abt32() inject an external abort instead
virt/kvm/arm/aarch32.c | 14 ++
1 file changed, 10 insertions(+), 4
p the static values. We
now get the expected:
| Unhandled fault: lock abort (0x404) at 0x9c800f00
Reported-by: Beata Michalska
Fixes: 74a64a981662a ("KVM: arm/arm64: Unify 32bit fault injection")
Signed-off-by: James Morse
---
virt/kvm/arm/aarch32.c | 8 +---
1 file changed, 5 inserti
we now get the documented:
| Unhandled fault: external abort on non-linefetch (0x008) at 0x9c800f00
and for LPAE:
| Unhandled fault: synchronous external abort (0x210) at 0x9c800f00
Reported-by: Beata Michalska
Signed-off-by: James Morse
---
virt/kvm/arm/aarch32.c | 10 +++---
1 file change
Hi Marc,
$subject typo: ~/DBGBIDR/DBGDIDR/
On 16/02/2020 18:53, Marc Zyngier wrote:
> The AArch32 CP14 DBGDIDR has bit 15 set to RES1, which our current
> emulation doesn't set. Just add the missing bit.
So it does.
Reviewed-by: James Morse
> diff --git a/arch/arm64/kvm/sys
readable via ID_DFR0_EL1.PerfMon, should that be
sanitised to be
the same?
(I don't think we've hidden an aarch64 feature that also existed in aarch32
before).
Regardless:
Reviewed-by: James Morse
Thanks,
James
> + val &= ~FEATURE(ID_AA64DFR0_PMUVER);
> +
Hi Marc,
On 16/02/2020 18:53, Marc Zyngier wrote:
> Let's not pretend we support anything but ARMv8.0 as far as the
> debug architecture is concerned.
(what happens for features that disappeared?)
For v8.0 the 'OS Double Lock' was mandatory. With v8.2 it became optional, and
not-implemented with
Hi Robin,
On 18/02/2020 18:01, Robin Murphy wrote:
> On 18/02/2020 5:43 pm, James Morse wrote:
>> On 16/02/2020 18:53, Marc Zyngier wrote:
>>> The AArch32 CP14 DBGDIDR has bit 15 set to RES1, which our current
>>> emulation doesn't set. Just add the missing bit.
Hi Marc,
On 2/19/20 9:46 AM, Marc Zyngier wrote:
> On 2020-02-18 17:43, James Morse wrote:
>> Hi Marc,
>>
>> On 16/02/2020 18:53, Marc Zyngier wrote:
>>> Our PMU code is only implementing the ARMv8.1 features, so let's
>>> stick to this when reporti
d the simon-says __always_inline annotation to all the static
inlines that KVM calls from HYP code.
This series based on v5.6-rc2.
[0]
https://lore.kernel.org/linux-arm-kernel/20200219000817.195049-1-samitolva...@google.com/
Thanks,
James Morse (3):
KVM: arm64: Ask the compiler to __always_i
from a hyp file.
Signed-off-by: James Morse
kvm_get_hyp_vector() pulls in all the regular per-cpu accessors
and this_cpu_has_cap(), fortunately its only called for VHE.
---
arch/arm64/include/asm/arch_gicv3.h | 2 +-
arch/arm64/include/asm/cpufeature.h | 2 +-
arch/arm64/include/asm/kvm
igned-off-by: James Morse
---
arch/arm64/include/asm/kvm_hyp.h | 7 +++
arch/arm64/kvm/hyp/vgic-v2-cpuif-proxy.c | 4 ++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_hyp.h b/arch/arm64/include/asm/kvm_hyp.h
index a3a6a2ba9a63..fe57f60
hint to these static-inlines that are used
by KVM.
Signed-off-by: James Morse
---
arch/arm64/include/asm/cache.h | 2 +-
arch/arm64/include/asm/cacheflush.h | 2 +-
arch/arm64/include/asm/cpufeature.h | 8
arch/arm64/include/asm/io.h | 4 ++--
4 files changed, 8 insertions
Hi Ard,
On 20/02/2020 17:04, Ard Biesheuvel wrote:
> On Thu, 20 Feb 2020 at 17:58, James Morse wrote:
>> It turns out KVM relies on the inline hint being honoured by the compiler
>> in quite a few more places than expected. Something about the Shadow Call
>> Stack support[0
Hi Marc,
On 21/02/2020 12:55, Marc Zyngier wrote:
> On 2020-02-20 16:58, James Morse wrote:
>> It turns out KVM relies on the inline hint being honoured by the compiler
>> in quite a few more places than expected. Something about the Shadow Call
>> Stack support[0] causes
Hi KarimAllah,
On 3/16/20 9:39 AM, KarimAllah Ahmed wrote:
> Use the physical timer object when reading the physical timer counter
> instead of using the virtual timer object. This is only visible when
> reading it from user-space as kvm_arm_timer_get_reg() is only executed on
> the get register p
tage2 translation, move
the registering of these notifiers into init_subsystems(), and add an
is_kernel_in_hyp_mode() path to each callback.
Fixes: 1e947bad0b6 ("arm64: KVM: Skip HYP setup when already running in HYP")
Signed-off-by: James Morse
---
arch/arm
On 30/03/16 17:30, Marc Zyngier wrote:
>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> index 6accd66d26f0..cf0184edf4f5 100644
>> --- a/arch/arm/kvm/arm.c
>> +++ b/arch/arm/kvm/arm.c
>> @@ -1084,9 +1092,13 @@ static int hyp_init_cpu_pm_notifier(struct
>> notifier_block *self,
>>
tage2 translation, move
the registering of these notifiers into init_subsystems(), and add a
is_kernel_in_hyp_mode() path to each callback.
Fixes: 1e947bad0b6 ("arm64: KVM: Skip HYP setup when already running in HYP")
Signed-off-by: James Morse
---
Change since v1:
* Moved common
SyS_clone+0x18/0x20
>[] el0_svc_naked+0x24/0x28
>[] 0x
On x86 kvm_vcpu_uninit() is called on the path from kvm_arch_destroy_vm(),
on arm no equivalent call is made. Add the call to kvm_arch_vcpu_free().
Signed-off-by: James Morse
Fixes: 749cf76c5a36 ("KVM: ARM: Initia
This isn't a problem in practice, as all devices appear to be
inserted in-order, so our rbtree is actually a monochrome linked list.
Signed-off-by: James Morse
---
devices.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/devices.c b/devices.c
index b560a59..a7c666a 100644
--- a/devic
801 - 843 of 843 matches
Mail list logo
