On Thu, 7 Jan 2021 12:44:01 +0800
Keqian Zhu wrote:
> We always use the smallest supported page size of vfio_iommu as
> pgsize. Drop parameter "pgsize" of update_user_bitmap.
>
> Signed-off-by: Keqian Zhu
> ---
> drivers/vfio/vfio_iommu_type1.c | 9 -
> 1 file changed, 4
On Thu, 7 Jan 2021 12:44:00 +0800
Keqian Zhu wrote:
> We always use the smallest supported page size of vfio_iommu as
> pgsize. Remove parameter "pgsize" of vfio_iova_dirty_bitmap.
>
> Signed-off-by: Keqian Zhu
> ---
> drivers/vfio/vfio_iommu_type1.c | 8
> 1 file changed, 4
On Thu, 7 Jan 2021 12:43:59 +0800
Keqian Zhu wrote:
> We always use the smallest supported page size of vfio_iommu as
> pgsize. Remove parameter "pgsize" of vfio_dma_bitmap_alloc_all.
>
> Signed-off-by: Keqian Zhu
> ---
> drivers/vfio/vfio_iommu_type1.c | 8 +++-
> 1 file changed, 3
On Thu, 7 Jan 2021 12:43:58 +0800
Keqian Zhu wrote:
> For now there are 3 ways to promote the pinned_page_dirty_scope
> status of vfio_iommu:
>
> 1. Through vfio pin interface.
> 2. Detach a group without pinned_dirty_scope.
> 3. Attach a group with pinned_dirty_scope.
>
> For point 3, the
On Thu, 7 Jan 2021 12:43:57 +0800
Keqian Zhu wrote:
> The pinned_scope of external domain's groups are always true, that's
> to say we can safely ignore external domain when promote pinned_scope
> status of vfio_iommu.
>
> Signed-off-by: Keqian Zhu
> ---
> drivers/vfio/vfio_iommu_type1.c | 14
On Thu, 7 Jan 2021 12:43:56 +0800
Keqian Zhu wrote:
> When we want to promote the pinned_page_dirty_scope of vfio_iommu,
> we call the "update" function to visit all vfio_group, but when we
> want to downgrade this, we can set the flag as false directly.
I agree that the transition can only go
From: George-Aurelian Popescu
Test the UBsan functionality inside hyp/nVHE.
Because modules are not supported inside of hyp/nVHE code, the default
testing module for UBSan can not be used.
New functions have to be defined inside of hyp/nVHE.
They are called in kvm_get_mdcr_el2, to test UBSAN
From: George Popescu
Type mismatch undefiend behaviour handler provides two handlers with two
data structures type_mismatch_data and type_mismatch_data_v1. Both can be
stored inside a common data structure: type_mismatch_data_common, which
differs of type_mismatch_data only by keeping a pointer
From: George Popescu
Whenever an arithmetic overflow: addition, substraction, multiplication,
division or negating happens inside the hyp/nVHE code,
an __ubsan_handle_*_overflow is called.
All the overflow handlers are sharing the same structure called
overflow_data.
Signed-off-by: George
From: George Popescu
The handler for the load invalid value undefined behaviour is
implemented at EL2. The EL2 handler's parameters are stored inside the buffer.
They are used by the symetric handler from EL1.
Signed-off-by: George Popescu
Signed-off-by: Elena Petrova
---
From: George Popescu
The data from __ubsan_handle_builtin_unreachable is passed to the buffer
and printed inside the kernel by its simetric handler.
Signed-off-by: George Popescu
Signed-off-by: Elena Petrova
---
arch/arm64/include/asm/kvm_ubsan.h | 3 +++
arch/arm64/kvm/hyp/nvhe/ubsan.c
From: George Popescu
__ubsan_handle_shift_out_of_bounds data is passed to the buffer inside
hyp/nVHE. This data is passed to the original handler from kernel.
The 64bit values of the shift expression operands are stored as the lhs
and rhs pointers, so there is no need to dereference them.
From: George Popescu
If an out of bounds happens inside the hyp/nVHE code, the ubsan_out_of_bounds
handler stores the logging data inside the kvm_ubsan_buffer. The one responsible
for printing is the kernel ubsan_out_of_bounds handler. The process of
decapsulating the data from the buffer is
From: George-Aurelian Popescu
Implement UBSan handlers inside nVHe hyp code, as empty functions for the
moment, so the undefined behaviours, that are triggered there, will be
linked to them, not to the ones defined in kernel-proper lib/ubsan.c.
In this way, enabling UBSAN_MISC won't cause a
From: George Popescu
Share a buffer between the kernel and the hyp/nVHE code by using the
macros from kvm_debug_buffer.h.
The hyp/nVHE code requires a write index which counts how many elements
have been writtens inside the buffer and the kernel requires a read
index which counts how many
Respin of George's patch series enabling UBSAN for hyp/nVHE code.
Updates in v3:
* rebased onto v5.11-rc3
* added base commit info
Updates in v2:
* CONFIG_KVM_ARM_DEBUG_BUFFER removed; __kvm_check_ubsan_buffer is
called directly instead of via __kvm_arm_check_debug_buffer.
*
On Fri, 15 Jan 2021 17:26:43 +0800
Keqian Zhu wrote:
> vfio_sanity_check_pfn_list() is used to check whether pfn_list of
> vfio_dma is empty when remove the external domain, so it makes a
> wrong assumption that only external domain will add pfn to dma pfn_list.
>
> Now we apply this check when
On Fri, 15 Jan 2021 17:26:42 +0800
Keqian Zhu wrote:
> If a group with non-pinned-page dirty scope is detached with dirty
> logging enabled, we should fully populate the dirty bitmaps at the
> time it's removed since we don't know the extent of its previous DMA,
> nor will the group be present
Hi Marc,
On 1/15/21 5:42 PM, Marc Zyngier wrote:
> Hi Eric,
>
> On 2021-01-15 14:01, Auger Eric wrote:
>> Hi Marc,
>>
>> On 1/14/21 11:56 AM, Marc Zyngier wrote:
>>> Upgrading the PMU code from ARMv8.1 to ARMv8.4 turns out to be
>>> pretty easy. All that is required is support for PMMIR_EL1,
Hi Eric,
On 2021-01-15 14:01, Auger Eric wrote:
Hi Marc,
On 1/14/21 11:56 AM, Marc Zyngier wrote:
Upgrading the PMU code from ARMv8.1 to ARMv8.4 turns out to be
pretty easy. All that is required is support for PMMIR_EL1, which
is read-only, and for which returning 0 is a valid option.
Let's
On Tuesday 12 Jan 2021 at 16:50:12 (+), Quentin Perret wrote:
> On Tuesday 12 Jan 2021 at 10:45:56 (-0600), Rob Herring wrote:
> > Umm, yes you are right. But both are dealing with nomap. So someone
> > needs to sort out what the right thing to do here is. No one cared
> > enough to follow up
The VMM may not wish to have it's own mapping of guest memory mapped
with PROT_MTE because this causes problems if the VMM has tag checking
enabled (the guest controls the tags in physical RAM and it's unlikely
the tags are correct for the VMM).
Instead add a new ioctl which allows the VMM to
Add a new VM feature 'KVM_ARM_CAP_MTE' which enables memory tagging
for a VM. This exposes the feature to the guest and automatically tags
memory pages touched by the VM as PG_mte_tagged (and clears the tags
storage) to ensure that the guest cannot see stale tags, and so that the
tags are
Define the new system registers that MTE introduces and context switch
them. The MTE feature is still hidden from the ID register as it isn't
supported in a VM yet.
Signed-off-by: Steven Price
---
arch/arm64/include/asm/kvm_host.h | 4 ++
arch/arm64/include/asm/kvm_mte.h |
After chasing down a bug[1] with MTE assisted KASAN and KVM, I've now
been able to rebase on v5.11-rc1 and test the combination of
KVM-with-MTE and KASAN.
For anyone new to this series, or simply pretending 2020 didn't happen,
this series adds support for Arm's Memory Tagging Extension (MTE) to
Hi Elena,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on arm64/for-next/core]
[cannot apply to kvmarm/next soc/for-next arm/for-next xlnx/master v5.11-rc3
next-20210115]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On 2021-01-15 14:08, Ard Biesheuvel wrote:
On Fri, 15 Jan 2021 at 15:03, Marc Zyngier wrote:
[...]
diff --git a/arch/arm64/kvm/vgic/vgic-v3.c
b/arch/arm64/kvm/vgic/vgic-v3.c
index 8e7bf3151057..67b27b47312b 100644
--- a/arch/arm64/kvm/vgic/vgic-v3.c
+++ b/arch/arm64/kvm/vgic/vgic-v3.c
@@
On Fri, 15 Jan 2021 at 15:03, Marc Zyngier wrote:
>
> It looks like we have broken firmware out there that wrongly advertises
> a GICv2 compatibility interface, despite the CPUs not being able to deal
> with it.
>
> To work around this, check that the CPU initialising KVM is actually able
> to
It looks like we have broken firmware out there that wrongly advertises
a GICv2 compatibility interface, despite the CPUs not being able to deal
with it.
To work around this, check that the CPU initialising KVM is actually able
to switch to MMIO instead of system registers, and use that as a
It appears that there is firmware out there that advertises GICv2
compatibility on GICv3, despite the CPUs not being able to actually do
it. That's a bummer, and at best creates unexpected behaviours for the
users. At worse, it will crash the machine. Awesome!
In order to mitigate this issue, try
As we are about to report a bit more information to the rest of
the kernel, rename __vgic_v3_get_ich_vtr_el2() to the more
explicit __vgic_v3_get_gic_config().
No functional change.
Signed-off-by: Marc Zyngier
---
arch/arm64/include/asm/kvm_asm.h | 4 ++--
arch/arm64/kvm/hyp/nvhe/hyp-main.c
Hi Marc,
On 1/14/21 11:56 AM, Marc Zyngier wrote:
> Upgrading the PMU code from ARMv8.1 to ARMv8.4 turns out to be
> pretty easy. All that is required is support for PMMIR_EL1, which
> is read-only, and for which returning 0 is a valid option.
>
> Let's just do that and adjust what we return to
Hi Marc,
On 1/14/21 11:56 AM, Marc Zyngier wrote:
> Let's not pretend we support anything but ARMv8.0 as far as the
> debug architecture is concerned.
>
> Signed-off-by: Marc Zyngier
Reviewed-by: Eric Auger
Eric
> ---
> arch/arm64/kvm/sys_regs.c | 3 +++
> 1 file changed, 3 insertions(+)
>
Hi Elena,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on arm64/for-next/core]
[cannot apply to kvmarm/next soc/for-next arm/for-next xlnx/master v5.11-rc3
next-20210115]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
Hi Marc,
On 1/14/21 11:56 AM, Marc Zyngier wrote:
> Our current ID register filtering is starting to be a mess of if()
> statements, and isn't going to get any saner.
>
> Let's turn it into a switch(), which has a chance of being more
> readable, and introduce a FEATURE() macro that allows easy
Hi Marc,
On 1/14/21 11:56 AM, Marc Zyngier wrote:
> We shouldn't expose *any* PMU capability when no PMU has been
> configured for this VM.
>
> Signed-off-by: Marc Zyngier
> ---
> arch/arm64/kvm/sys_regs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
Hi Marc,
On 1/14/21 11:56 AM, 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.
>
> Reported-by: Peter Maydell
> Signed-off-by: Marc Zyngier
> ---
> arch/arm64/kvm/sys_regs.c | 2 +-
> 1 file changed,
Hi Marc,
On 1/14/21 11:56 AM, Marc Zyngier wrote:
> Despite advertising support for AArch32 PMUv3p1, we fail to handle
> the PMCEID{2,3} registers, which conveniently alias with with the top
s/with with/with
> bits of PMCEID{0,1}_EL1.
>
> Implement these registers with the usual AA32(HI/LO)
Hi Elena,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on arm64/for-next/core]
[cannot apply to kvmarm/next soc/for-next arm/for-next xlnx/master v5.11-rc3
next-20210115]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
On Wed, 6 Jan 2021 17:22:26 +, Marc Zyngier wrote:
> We're now able to hide PMU registers from the guest when no PMU is
> available, but I just realised that we don't do the same thing for
> userspace, which is pretty annoying (as it ends up with garbage).
>
> The first patch introduces a
On Wed, 6 Jan 2021 14:42:18 +, Alexandru Elisei wrote:
> The reg_to_encoding() macro is a wrapper over sys_reg() and conveniently
> takes a sys_reg_desc or a sys_reg_params argument and returns the 32 bit
> register encoding. Use it instead of calling sys_reg() directly.
Applied to next,
On Tue, 29 Dec 2020 16:00:59 +, David Brazdil wrote:
> The KVM/arm64 PSCI relay assumes that SYSTEM_OFF and SYSTEM_RESET should
> not return, as dictated by the PSCI spec. However, there is firmware out
> there which breaks this assumption, leading to a hyp panic. Make KVM
> more robust to
On 2021-01-15 09:30, Jianyong Wu wrote:
Currently, error report when cache maintenance at read-only memory
range,
like rom, is not clear enough and even not correct. As the specific
error
is definitely known by kvm, it is obliged to give it out.
Fox example, in a qemu/kvm VM, if the guest do
On Fri, Jan 15, 2021 at 05:53:07PM +0800, Keqian Zhu wrote:
> When align the end address, ought to use its original value.
>
> Fixes: b1e57de62cfb ("KVM: arm64: Add stand-alone page-table walker
> infrastructure")
> Signed-off-by: Keqian Zhu
> ---
> arch/arm64/kvm/hyp/pgtable.c | 2 +-
> 1
vfio_sanity_check_pfn_list() is used to check whether pfn_list of
vfio_dma is empty when remove the external domain, so it makes a
wrong assumption that only external domain will add pfn to dma pfn_list.
Now we apply this check when remove a specific vfio_dma and extract
the notifier check just
If a group with non-pinned-page dirty scope is detached with dirty
logging enabled, we should fully populate the dirty bitmaps at the
time it's removed since we don't know the extent of its previous DMA,
nor will the group be present to trigger the full bitmap when the user
retrieves the dirty
changelog:
v2:
- Address suggestions from Alex.
- Remove unnecessary patches.
Keqian Zhu (2):
vfio/iommu_type1: Populate full dirty when detach non-pinned group
vfio/iommu_type1: Sanity check pfn_list when remove vfio_dma
drivers/vfio/vfio_iommu_type1.c | 42
Hi Elena,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on arm64/for-next/core]
[cannot apply to kvmarm/next soc/for-next arm/for-next xlnx/master v5.11-rc3
next-20210115]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
When align the end address, ought to use its original value.
Fixes: b1e57de62cfb ("KVM: arm64: Add stand-alone page-table walker
infrastructure")
Signed-off-by: Keqian Zhu
---
arch/arm64/kvm/hyp/pgtable.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
On 2021/1/15 1:14, Alex Williamson wrote:
> On Thu, 14 Jan 2021 21:05:23 +0800
> Keqian Zhu wrote:
>
>> Hi Alex,
>>
>> On 2021/1/13 5:20, Alex Williamson wrote:
>>> On Thu, 7 Jan 2021 17:28:57 +0800
>>> Keqian Zhu wrote:
>>>
Defer checking whether vfio_dma is of fully-dirty in
Currently, error report when cache maintenance at read-only memory range,
like rom, is not clear enough and even not correct. As the specific error
is definitely known by kvm, it is obliged to give it out.
Fox example, in a qemu/kvm VM, if the guest do dc at the pflash range from
0 to 128M, error
vfio_sanity_check_pfn_list() is used to check whether pfn_list of
vfio_dma is empty when remove the external domain, so it makes a
wrong assumption that only external domain will add pfn to dma pfn_list.
Now we apply this check when remove a specific vfio_dma and extract
the notifier check just
If a group with non-pinned-page dirty scope is detached with dirty
logging enabled, we should fully populate the dirty bitmaps at the
time it's removed since we don't know the extent of its previous DMA,
nor will the group be present to trigger the full bitmap when the user
retrieves the dirty
changelog:
v2:
- Address suggestions from Alex.
- Remove unnecessary patches.
Keqian Zhu (2):
vfio/iommu_type1: Populate full dirty when detach non-pinned group
vfio/iommu_type1: Sanity check pfn_list when remove vfio_dma
drivers/vfio/vfio_iommu_type1.c | 42
Hi Elena,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on arm64/for-next/core]
[also build test WARNING on v5.11-rc3 next-20210115]
[cannot apply to kvmarm/next soc/for-next arm/for-next xlnx/master]
[If your patch is applied to the wrong git tree, kindly drop
55 matches
Mail list logo
