These are remaining patches from V4 series which had some pending reviews
from Suzuki (https://patchwork.kernel.org/cover/11557333/). Also dropped
[PATCH 15/17] as that will need some more investigation and rework.
This series applies on 5.8-rc3.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Mark
Hi Eric,
On 7/2/2020 9:23 PM, Auger Eric wrote:
Hi Jingyi,
On 7/2/20 5:01 AM, Jingyi Wang wrote:
Besides using separate running times parameter, we add time limit
for loop_test to make sure each test should be done in a certain
time(5 sec here).
Signed-off-by: Jingyi Wang
---
On 7/2/2020 9:42 PM, Auger Eric wrote:
Hi Marc,
On 7/2/20 3:08 PM, Marc Zyngier wrote:
Hi Eric,
On 2020-07-02 13:57, Auger Eric wrote:
Hi Jingyi,
On 7/2/20 5:01 AM, Jingyi Wang wrote:
If gicv4.1(sgi hardware injection) supported, we test ipi injection
via hw/sw way separately.
Don't bother filling the gfn array cache when the caller is a fully
direct MMU, i.e. won't need a gfn array for shadow pages.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 18 ++
arch/x86/kvm/mmu/paging_tmpl.h | 4 ++--
2 files
Replace the @max param in mmu_topup_memory_cache() and instead use
ARRAY_SIZE() to terminate the loop to fill the cache. This removes a
BUG_ON() and sets the stage for moving MIPS to the common memory cache
implementation.
No functional change intended.
Signed-off-by: Sean Christopherson
---
Move to the common MMU memory cache implementation now that the common
code and arm64's existing code are semantically compatible.
No functional change intended.
Cc: Marc Zyngier
Suggested-by: Christoffer Dall
Signed-off-by: Sean Christopherson
---
arch/arm64/include/asm/Kbuild | 1 -
Track the kmem_cache used for non-page KVM MMU memory caches instead of
passing in the associated kmem_cache when filling the cache. This will
allow consolidating code and other cleanups.
No functional change intended.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
Avoid refilling the memory caches and potentially slow reclaim/swap when
handling a fast page fault, which does not need to allocate any new
objects.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 6 +++---
1 file changed, 3 insertions(+), 3
Return errors directly from mmu_topup_memory_caches() instead of
branching to a label that does the same.
No functional change intended.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff
Attempt to allocate a new object instead of crashing KVM (and likely the
kernel) if a memory cache is unexpectedly empty. Use GFP_ATOMIC for the
allocation as the caches are used while holding mmu_lock. The immediate
BUG_ON() makes the code unnecessarily explosive and led to confusing
minimums
Move x86's 'struct kvm_mmu_memory_cache' to common code in anticipation
of moving the entire x86 implementation code to common KVM and reusing
it for arm64 and MIPS. Add a new architecture specific asm/kvm_types.h
to control the existence and parameters of the struct. The new header
is needed to
Use GFP_KERNEL_ACCOUNT instead of GFP_KERNEL when allocating pages for
the the GPA page tables. The primary motivation for accounting the
allocations is to align with the common KVM memory cache helpers in
preparation for moving to the common implementation in a future patch.
The actual
Topup memory caches after walking the GVA->GPA translation during a
shadow page fault, there is no need to ensure the caches are full when
walking the GVA. As of commit f5a1e9f89504f ("KVM: MMU: remove call
to kvm_mmu_pte_write from walk_addr"), the FNAME(walk_addr) flow no
longer add rmaps via
Rename the memory helpers that will soon be moved to common code and be
made globaly available via linux/kvm_host.h. "mmu" alone is not a
sufficient namespace for globally available KVM symbols.
Opportunistically add "nr_" in mmu_memory_cache_free_objects() to make
it clear the function returns
Clean up the minimums in mmu_topup_memory_caches() to document the
driving mechanisms behind the minimums. Now that encountering an empty
cache is unlikely to trigger BUG_ON(), it is less dangerous to be more
precise when defining the minimums.
For rmaps, the logic is 1 parent PTE per level,
Set __GFP_ZERO for the shadow page memory cache and drop the explicit
clear_page() from kvm_mmu_get_page(). This moves the cost of zeroing a
page to the allocation time of the physical page, i.e. when topping up
the memory caches, and thus avoids having to zero out an entire page
while holding
Use "mc" for local variables to shorten line lengths and provide
consistent names, which will be especially helpful when some of the
helpers are moved to common KVM code in future patches.
No functional change intended.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
Move to the common MMU memory cache implementation now that the common
code and MIPS's existing code are semantically compatible.
No functional change intended.
Suggested-by: Christoffer Dall
Signed-off-by: Sean Christopherson
---
arch/mips/include/asm/Kbuild | 1 -
The only interesting delta from v2 is that patch 18 is updated to handle
a conflict with arm64's p4d rework. Resolution was straightforward
(famous last words).
This series resurrects Christoffer Dall's series[1] to provide a common
MMU memory cache implementation that can be shared by x86,
Add a "gfp_zero" member to arm64's 'struct kvm_mmu_memory_cache' to make
the struct and its usage compatible with the common 'struct
kvm_mmu_memory_cache' in linux/kvm_host.h. This will minimize code
churn when arm64 moves to the common implementation in a future patch, at
the cost of temporarily
Add a gfp_zero flag to 'struct kvm_mmu_memory_cache' and use it to
control __GFP_ZERO instead of hardcoding a call to kmem_cache_zalloc().
A future patch needs such a flag for the __get_free_page() path, as
gfn arrays do not need/want the allocator to zero the memory. Convert
the kmem_cache paths
Use separate caches for allocating shadow pages versus gfn arrays. This
sets the stage for specifying __GFP_ZERO when allocating shadow pages
without incurring extra cost for gfn arrays.
No functional change intended.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
Drop the "page" variants of the topup/free memory cache helpers, using
the existence of an associated kmem_cache to select the correct alloc
or free routine.
No functional change intended.
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 37
Move x86's memory cache helpers to common KVM code so that they can be
reused by arm64 and MIPS in future patches.
Suggested-by: Christoffer Dall
Reviewed-by: Ben Gardon
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/mmu/mmu.c | 53 --
Replace the @max param in mmu_topup_memory_cache() and instead use
ARRAY_SIZE() to terminate the loop to fill the cache. This removes a
BUG_ON() and sets the stage for moving arm64 to the common memory cache
implementation.
No functional change intended.
Tested-by: Marc Zyngier
Signed-off-by:
On Thu, Jul 02, 2020 at 02:57:56PM +0200, Auger Eric wrote:
> Hi Jingyi,
>
> On 7/2/20 5:01 AM, Jingyi Wang wrote:
> > If gicv4.1(sgi hardware injection) supported, we test ipi injection
> > via hw/sw way separately.
> >
> > Signed-off-by: Jingyi Wang
> > ---
> > arm/micro-bench.c| 45
On Wed, May 27, 2020 at 08:33:35AM +0530, Anshuman Khandual wrote:
> These are remaining patches from V4 series which had some pending reviews
> from Suzuki (https://patchwork.kernel.org/cover/11557333/). Also dropped
> [PATCH 15/17] as that will need some more investigation and rework.
>
> This
On 2020-07-02 16:37, Suzuki K Poulose wrote:
Hi Marc
On 07/01/2020 04:42 PM, Marc Zyngier wrote:
On 2020-07-01 15:20, Suzuki K Poulose wrote:
When the host doesn't support 32bit guests, the kvmtool fails
without a proper message on what is wrong. i.e,
$ lkvm run -c 1 Image --aarch32
#
Hi Marc
On 07/01/2020 04:42 PM, Marc Zyngier wrote:
On 2020-07-01 15:20, Suzuki K Poulose wrote:
When the host doesn't support 32bit guests, the kvmtool fails
without a proper message on what is wrong. i.e,
$ lkvm run -c 1 Image --aarch32
# lkvm run -k Image -m 256 -c 1 --name guest-105618
On Thu, Jul 02, 2020 at 08:56:05AM -0600, Rob Herring wrote:
> On Thu, Jul 2, 2020 at 5:42 AM Will Deacon wrote:
> >
> > On Wed, Jul 01, 2020 at 03:53:08PM -0600, Rob Herring wrote:
> > > On Cortex-A77 r0p0 and r1p0, a sequence of a non-cacheable or device load
> > > and a store exclusive or
On Thu, Jul 2, 2020 at 5:42 AM Will Deacon wrote:
>
> On Wed, Jul 01, 2020 at 03:53:08PM -0600, Rob Herring wrote:
> > On Cortex-A77 r0p0 and r1p0, a sequence of a non-cacheable or device load
> > and a store exclusive or PAR_EL1 read can cause a deadlock.
> >
> > The workaround requires a DMB SY
On Thu, Jul 02, 2020 at 08:04:43AM -0600, Rob Herring wrote:
> On Thu, Jul 2, 2020 at 5:45 AM Will Deacon wrote:
> >
> > On Wed, Jul 01, 2020 at 03:53:06PM -0600, Rob Herring wrote:
> > > If guests don't have certain CPU erratum work-arounds implemented, then
> > > there is a possibility a guest
On Thu, Jul 2, 2020 at 5:45 AM Will Deacon wrote:
>
> On Wed, Jul 01, 2020 at 03:53:06PM -0600, Rob Herring wrote:
> > If guests don't have certain CPU erratum work-arounds implemented, then
> > there is a possibility a guest can deadlock the system. IOW, only trusted
> > guests should be used on
DBM bit is used by MMU to differentiate a genuinely non-writable
page from a page that is only temporarily non-writable in order
to mark dirty.
Signed-off-by: Keqian Zhu
Signed-off-by: Peng Liang
---
arch/arm64/include/asm/kvm_mmu.h | 4
1 file changed, 4 insertions(+)
diff --git
kvm_set_pte is called to replace a target PTE with a desired one.
We always do this without changing the desired one, but if dirty
status set by hardware is covered, let caller know it.
There are two types of operations will change PTE and may cover
dirty status set by hardware.
1. Stage2 PTE
This patch series add support for dirty log based on HW DBM.
It works well under some migration test cases, including VM with 4K
pages or 2M THP. I checked the SHA256 hash digest of all memory and
they keep same for source VM and destination VM, which means no dirty
pages is missed under hardware
Marking PTs young (set AF bit) should be atomic to avoid cover
dirty status set by hardware.
Signed-off-by: Keqian Zhu
Signed-off-by: Peng Liang
---
arch/arm64/include/asm/kvm_mmu.h | 31 ++-
arch/arm64/kvm/mmu.c | 15 ---
2 files changed, 30
For hardware management of dirty state, dirty state is stored in
PTEs. We have to scan all PTEs to sync dirty log to memslot dirty
bitmap.
Signed-off-by: Keqian Zhu
Signed-off-by: Peng Liang
---
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/include/asm/kvm_mmu.h | 13 +++
For that using arm64 DBM to log dirty pages has the side effect
of long time dirty log sync, we should give userspace opportunity
to enable or disable this feature, to realize some policy.
This feature is disabled by default.
Signed-off-by: Keqian Zhu
Signed-off-by: Peng Liang
---
During dirty log clear, page table entries are write protected
according to a mask. In the past we write protect all entries
corresponding to the mask from ffs to fls. Though there may be
zero bits between this range, we are holding the kvm mmu lock
so we won't write protect entries that we don't
Synchronizing dirty log during log clear is useful only when the dirty
bitmap of userspace contains dirty bits that memslot dirty bitmap does
not contain, because we can sync new dirty bits to memslot dirty bitmap,
then we can clear them by the way and avoid reporting them to userspace
later.
Give userspace another selection to solve high-cost dirty log
sync, which called multi-core offload. Usersapce can enable
this policy through KVM_CAP_ARM_HW_DIRTY_LOG.
Signed-off-by: Keqian Zhu
Signed-off-by: Peng Liang
---
arch/arm64/include/asm/kvm_host.h | 3 ++
arch/arm64/kvm/arm.c
Hi Marc,
On 7/2/20 3:08 PM, Marc Zyngier wrote:
> Hi Eric,
>
> On 2020-07-02 13:57, Auger Eric wrote:
>> Hi Jingyi,
>>
>> On 7/2/20 5:01 AM, Jingyi Wang wrote:
>>> If gicv4.1(sgi hardware injection) supported, we test ipi injection
>>> via hw/sw way separately.
>>>
>>> Signed-off-by: Jingyi Wang
Hi Jingyi,
On 7/2/20 5:01 AM, Jingyi Wang wrote:
> Trigger PPIs by setting up a 10msec timer and test the latency.
so for each iteration the accumulated valued is 10 ms + latency, right?
and what is printed at the end does include the accumulated periods.
Wouldn't it make sense to have a
Hi Jingyi,
On 7/2/20 5:01 AM, Jingyi Wang wrote:
> Besides using separate running times parameter, we add time limit
> for loop_test to make sure each test should be done in a certain
> time(5 sec here).
>
> Signed-off-by: Jingyi Wang
> ---
> arm/micro-bench.c | 17 +++--
> 1 file
Hi Jingyi,
On 7/2/20 7:29 AM, Andrew Jones wrote:
> On Thu, Jul 02, 2020 at 11:01:30AM +0800, Jingyi Wang wrote:
>> For some test in micro-bench can be time consuming, we add a
>> micro-bench test parameter to allow each individual test to specify
>> its running times.
>>
>> Signed-off-by: Jingyi
Hi Jingyi,
On 7/2/20 5:01 AM, Jingyi Wang wrote:
> Triggers LPIs through the INT command and test the latency.
> Mostly inherited form commit 0ef02cd6cbaa(arm/arm64: ITS: INT
> functional tests).
>
> Signed-off-by: Jingyi Wang
> ---
> arm/micro-bench.c | 44
Hi Eric,
On 2020-07-02 13:57, Auger Eric wrote:
Hi Jingyi,
On 7/2/20 5:01 AM, Jingyi Wang wrote:
If gicv4.1(sgi hardware injection) supported, we test ipi injection
via hw/sw way separately.
Signed-off-by: Jingyi Wang
---
arm/micro-bench.c| 45
Hi Eric,
On 2020-07-02 13:36, Auger Eric wrote:
Hi Marc,
On 7/2/20 10:22 AM, Marc Zyngier wrote:
On 2020-07-02 04:01, Jingyi Wang wrote:
If gicv4.1(sgi hardware injection) supported, we test ipi injection
via hw/sw way separately.
nit: active-less SGIs are not strictly a feature of GICv4.1
Hi Jingyi,
On 7/2/20 5:01 AM, Jingyi Wang wrote:
> Because micro-bench may send a large number of ITS commands, we
> should handle ITS command queue wrapping as kernel instead of just
> failing the test.
>
> Signed-off-by: Jingyi Wang
Reviewed-by: Eric Auger
Thanks
Eric
> ---
>
Hi Jingyi,
On 7/2/20 5:01 AM, Jingyi Wang wrote:
> If gicv4.1(sgi hardware injection) supported, we test ipi injection
> via hw/sw way separately.
>
> Signed-off-by: Jingyi Wang
> ---
> arm/micro-bench.c| 45 +++-
> lib/arm/asm/gic-v3.h | 3 +++
>
Hi Marc,
On 7/2/20 10:22 AM, Marc Zyngier wrote:
> On 2020-07-02 04:01, Jingyi Wang wrote:
>> If gicv4.1(sgi hardware injection) supported, we test ipi injection
>> via hw/sw way separately.
>
> nit: active-less SGIs are not strictly a feature of GICv4.1 (you could
> imagine a GIC emulation
Hi Jingyi,
On 7/2/20 5:01 AM, Jingyi Wang wrote:
> If ipi_exec() fails because of timeout, we shouldn't increase
> the number of ipi received.
>
> Signed-off-by: Jingyi Wang
Reviewed-by: Eric Auger
Thanks
Eric
> ---
> arm/micro-bench.c | 4 +++-
> 1 file changed, 3 insertions(+), 1
Hi,
On 7/2/20 5:01 AM, Jingyi Wang wrote:
> The following patches will use that.
>
> Signed-off-by: Jingyi Wang
> ---
> arm/micro-bench.c | 39 ++-
> 1 file changed, 22 insertions(+), 17 deletions(-)
>
With commit message suggested by Drew,
Reviewed-by:
On Wed, Jul 01, 2020 at 03:53:06PM -0600, Rob Herring wrote:
> If guests don't have certain CPU erratum work-arounds implemented, then
> there is a possibility a guest can deadlock the system. IOW, only trusted
> guests should be used on systems with the erratum.
>
> This is the case for
On Wed, Jul 01, 2020 at 03:53:08PM -0600, Rob Herring wrote:
> On Cortex-A77 r0p0 and r1p0, a sequence of a non-cacheable or device load
> and a store exclusive or PAR_EL1 read can cause a deadlock.
>
> The workaround requires a DMB SY before and after a PAR_EL1 register read
> and the disabling
Hi Steven,
On 2020/7/1 19:28, Steven Price wrote:
> Hi,
>
> On 16/06/2020 10:35, Keqian Zhu wrote:
>> kvm_set_pte is called to replace a target PTE with a desired one.
>> We always do this without changing the desired one, but if dirty
>> status set by hardware is coverred, let caller know it.
On 7/2/2020 5:17 PM, Marc Zyngier wrote:
On 2020-07-02 10:02, Jingyi Wang wrote:
Hi Marc,
On 7/2/2020 4:22 PM, Marc Zyngier wrote:
On 2020-07-02 04:01, Jingyi Wang wrote:
If gicv4.1(sgi hardware injection) supported, we test ipi injection
via hw/sw way separately.
nit: active-less SGIs are
On 2020-07-02 10:02, Jingyi Wang wrote:
Hi Marc,
On 7/2/2020 4:22 PM, Marc Zyngier wrote:
On 2020-07-02 04:01, Jingyi Wang wrote:
If gicv4.1(sgi hardware injection) supported, we test ipi injection
via hw/sw way separately.
nit: active-less SGIs are not strictly a feature of GICv4.1 (you
Hi Drew,
On 7/2/20 10:12 AM, Andrew Jones wrote:
> The timer can be useful for other tests besides the timer test.
> Extract the DT parsing of the irqs out of the timer test into
> setup and provide them along with some defines in a new timer.h
> file.
>
> Signed-off-by: Andrew Jones
Hi Marc,
On 7/2/2020 4:22 PM, Marc Zyngier wrote:
On 2020-07-02 04:01, Jingyi Wang wrote:
If gicv4.1(sgi hardware injection) supported, we test ipi injection
via hw/sw way separately.
nit: active-less SGIs are not strictly a feature of GICv4.1 (you could
imagine a GIC emulation offering the
Hi Drew,
On 7/2/2020 1:44 PM, Andrew Jones wrote:
On Thu, Jul 02, 2020 at 11:01:32AM +0800, Jingyi Wang wrote:
Trigger PPIs by setting up a 10msec timer and test the latency.
Signed-off-by: Jingyi Wang
---
arm/micro-bench.c | 56 ++-
1 file
On 7/2/2020 1:48 PM, Andrew Jones wrote:
On Thu, Jul 02, 2020 at 11:01:31AM +0800, Jingyi Wang wrote:
Besides using separate running times parameter, we add time limit
for loop_test to make sure each test should be done in a certain
time(5 sec here).
Signed-off-by: Jingyi Wang
---
On 7/2/2020 1:29 PM, Andrew Jones wrote:
On Thu, Jul 02, 2020 at 11:01:30AM +0800, Jingyi Wang wrote:
For some test in micro-bench can be time consuming, we add a
micro-bench test parameter to allow each individual test to specify
its running times.
Signed-off-by: Jingyi Wang
---
On 2020-07-02 04:01, Jingyi Wang wrote:
If gicv4.1(sgi hardware injection) supported, we test ipi injection
via hw/sw way separately.
nit: active-less SGIs are not strictly a feature of GICv4.1 (you could
imagine a GIC emulation offering the same thing). Furthermore, GICv4.1
isn't as such
Hi Drew,
On 7/2/2020 1:25 PM, Andrew Jones wrote:
Hi Jingyi,
This patch has quite a long summary. How about instead of
arm64: microbench: Use the funcions for ipi test as the general functions for
gic(ipi/lpi/timer) test
we use
arm64: microbench: Generalize ipi test names
and then in
The timer can be useful for other tests besides the timer test.
Extract the DT parsing of the irqs out of the timer test into
setup and provide them along with some defines in a new timer.h
file.
Signed-off-by: Andrew Jones
---
arm/timer.c | 26 --
67 matches
Mail list logo
