Re: [PATCH v2 0/8] KVM: arm64: Support HW dirty log based on DBM

2020-07-27 Thread zhukeqian
Hi Marc, On 2020/7/13 22:53, Marc Zyngier wrote: > Hi Keqian, > > On Mon, 13 Jul 2020 03:47:25 +0100, > zhukeqian wrote: >> >> Hi Marc, >> >> Sorry for the delay reply. >> >> On 2020/7/6 15:54, Marc Zyngier wrote: >>> Hi Keqian, >>> >>> On 2020-07-06 02:28, zhukeqian wrote: Hi Catalin and M

RE: [PATCH v13 2/9] arm/arm64: KVM: Advertise KVM UID to guests via SMCCC

2020-07-27 Thread Jianyong Wu
> -Original Message- > From: Will Deacon > Sent: Monday, July 27, 2020 7:38 PM > To: Jianyong Wu > Cc: net...@vger.kernel.org; yangbo...@nxp.com; john.stu...@linaro.org; > t...@linutronix.de; pbonz...@redhat.com; sean.j.christopher...@intel.com; > m...@kernel.org; richardcoch...@gmail.

Re: [PATCH v3 3/3] arm64: Add workaround for Arm Cortex-A77 erratum 1508412

2020-07-27 Thread Andrew Scull
Hi Rob, a couple of suggestions for way this erratum is gated, but I haven't delved into the details of the errata itself. On Fri, Jul 17, 2020 at 02:52:33PM -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 rea

Re: [PATCH 0/5] KVM: arm64: pvtime: Fixes and a new cap

2020-07-27 Thread Marc Zyngier
On 2020-07-11 11:04, Andrew Jones wrote: The first three patches in the series are fixes that come from testing and reviewing pvtime code while writing the QEMU support (I'll reply to this mail with a link to the QEMU patches after posting - which I'll do shortly). The last patch is only a conven

Re: [PATCH 5/5] arm64/x86: KVM: Introduce steal-time cap

2020-07-27 Thread Marc Zyngier
On 2020-07-11 11:04, Andrew Jones wrote: arm64 requires a vcpu fd (KVM_HAS_DEVICE_ATTR vcpu ioctl) to probe support for steal-time. However this is unnecessary, as only a KVM fd is required, and it complicates userspace (userspace may prefer delaying vcpu creation until after feature probing). In

Re: [PATCH 4/5] KVM: Documentation minor fixups

2020-07-27 Thread Marc Zyngier
On 2020-07-11 11:04, Andrew Jones wrote: Reviewed-by: Steven Price Signed-off-by: Andrew Jones It'd be good to have an actual commit message. --- Documentation/virt/kvm/api.rst | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/Documentation/virt/kvm/api.rst b/Do

Re: [PATCH 3/5] KVM: arm64: pvtime: Fix stolen time accounting across migration

2020-07-27 Thread Marc Zyngier
On 2020-07-11 11:04, Andrew Jones wrote: When updating the stolen time we should always read the current stolen time from the user provided memory, not from a kernel cache. If we use a cache then we'll end up resetting stolen time to zero on the first update after migration. Signed-off-by: Andre

Re: [PATCH 2/5] KVM: arm64: pvtime: Fix potential loss of stolen time

2020-07-27 Thread Marc Zyngier
On 2020-07-11 11:04, Andrew Jones wrote: We should only check current->sched_info.run_delay once when updating stolen time. Otherwise there's a chance there could be a change between checks that we miss (preemption disabling comes after vcpu request checks). Signed-off-by: Andrew Jones --- arc

Re: [PATCH 1/5] KVM: arm64: pvtime: steal-time is only supported when configured

2020-07-27 Thread Marc Zyngier
Hi Andrew, On 2020-07-11 11:04, Andrew Jones wrote: Don't confuse the guest by saying steal-time is supported when it hasn't been configured by userspace and won't work. Signed-off-by: Andrew Jones --- arch/arm64/kvm/pvtime.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --g

Re: [kvm-unit-tests PATCH] arm64: Compile with -mno-outline-atomics for GCC >= 10

2020-07-27 Thread Paolo Bonzini
On 27/07/20 14:30, Andrew Jones wrote: >>> Looks much better than my version. Do you want me to spin a v2 or do you >>> want to >>> send it as a separate patch? If that's the case, I tested the same way I >>> did my >>> patch (gcc 10.1.0 and 5.4.0 for cross-compiling, 9.3.0 native): >>> >>> Teste

Re: [RESEND RFC PATCH v1] arm64: kvm: flush tlbs by range in unmap_stage2_range function

2020-07-27 Thread Marc Zyngier
Zhenyu, On 2020-07-27 15:51, Zhenyu Ye wrote: Hi Marc, On 2020/7/26 1:40, Marc Zyngier wrote: On 2020-07-24 14:43, Zhenyu Ye wrote: Now in unmap_stage2_range(), we flush tlbs one by one just after the corresponding pages cleared.  However, this may cause some performance problems when the u

Re: [RESEND RFC PATCH v1] arm64: kvm: flush tlbs by range in unmap_stage2_range function

2020-07-27 Thread Zhenyu Ye
Hi Marc, On 2020/7/26 1:40, Marc Zyngier wrote: > On 2020-07-24 14:43, Zhenyu Ye wrote: >> Now in unmap_stage2_range(), we flush tlbs one by one just after the >> corresponding pages cleared.  However, this may cause some performance >> problems when the unmap range is very large (such as when the

Re: [kvm-unit-tests PATCH] arm64: Compile with -mno-outline-atomics for GCC >= 10

2020-07-27 Thread Alexandru Elisei
Hi Drew, On 7/27/20 1:30 PM, Andrew Jones wrote: > On Mon, Jul 27, 2020 at 01:21:03PM +0100, Alexandru Elisei wrote: >> Hi Drew, >> >> On 7/18/20 2:50 PM, Alexandru Elisei wrote: >>> Hi, >>> >>> On 7/18/20 10:11 AM, Andrew Jones wrote: On Fri, Jul 17, 2020 at 05:47:27PM +0100, Alexandru Elise

Re: [kvm-unit-tests PATCH] arm64: Compile with -mno-outline-atomics for GCC >= 10

2020-07-27 Thread Andrew Jones
On Mon, Jul 27, 2020 at 01:21:03PM +0100, Alexandru Elisei wrote: > Hi Drew, > > On 7/18/20 2:50 PM, Alexandru Elisei wrote: > > Hi, > > > > On 7/18/20 10:11 AM, Andrew Jones wrote: > >> On Fri, Jul 17, 2020 at 05:47:27PM +0100, Alexandru Elisei wrote: > >>> GCC 10.1.0 introduced the -m{,no-}outli

Re: [kvm-unit-tests PATCH] arm64: Compile with -mno-outline-atomics for GCC >= 10

2020-07-27 Thread Alexandru Elisei
Hi Drew, On 7/18/20 2:50 PM, Alexandru Elisei wrote: > Hi, > > On 7/18/20 10:11 AM, Andrew Jones wrote: >> On Fri, Jul 17, 2020 at 05:47:27PM +0100, Alexandru Elisei wrote: >>> GCC 10.1.0 introduced the -m{,no-}outline-atomics flags which, according to >>> man 1 gcc: >>> >>> "Enable or disable cal

Re: [PATCH v13 2/9] arm/arm64: KVM: Advertise KVM UID to guests via SMCCC

2020-07-27 Thread Will Deacon
On Mon, Jul 27, 2020 at 03:45:37AM +, Jianyong Wu wrote: > > From: Will Deacon > > > > We can advertise ourselves to guests as KVM and provide a basic features > > bitmap for discoverability of future hypervisor services. > > > > Cc: Marc Zyngier > > Signed-off-by: Will Deacon > > Signed-o

Re: kvm-unit-tests: Question about the "no interrupt when timer is disabled" case

2020-07-27 Thread Alexandru Elisei
Hi Zenghui, On 7/25/20 5:50 AM, Zenghui Yu wrote: > Hi Alex, > > [+cc Nianyao] > > On 2020/7/24 19:08, Alexandru Elisei wrote: >> Hi Zenghui, >> >> I don't believe this issue can be triggered by a Linux guest. Details below. >> >> On 7/23/20 9:56 AM, Zenghui Yu wrote: >>> Hi Alexandru, >>> >>> I'v

Re: [PATCH 0/5] KVM: arm64: pvtime: Fixes and a new cap

2020-07-27 Thread Marc Zyngier
On 2020-07-27 12:02, Andrew Jones wrote: Hi Marc, Ping? On it! ;-) M. -- Jazz is not dead. It just smells funny... ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH 0/5] KVM: arm64: pvtime: Fixes and a new cap

2020-07-27 Thread Andrew Jones
Hi Marc, Ping? Thanks, drew On Sat, Jul 11, 2020 at 12:04:29PM +0200, Andrew Jones wrote: > The first three patches in the series are fixes that come from testing > and reviewing pvtime code while writing the QEMU support (I'll reply > to this mail with a link to the QEMU patches after postin

Re: [PATCH 0/9] arm64: Stolen time support

2020-07-27 Thread Steven Price
On 21/07/2020 04:26, zhukeqian wrote: Hi Steven, Hi Keqian, On 2019/8/2 22:50, Steven Price wrote: This series add support for paravirtualized time for arm64 guests and KVM hosts following the specification in Arm's document DEN 0057A: https://developer.arm.com/docs/den0057/a It implements

Re: [PATCH 0/3] KVM: arm64: Clean up memcache usage for page-table pages

2020-07-27 Thread Will Deacon
On Mon, Jul 27, 2020 at 09:45:39AM +0100, Marc Zyngier wrote: > On 2020-07-23 12:02, Will Deacon wrote: > > Here are some small cleanups I made to the memcache logic while hacking > > on the > > page-table code. The ioremap() behaviour looks like a bug to me, > > although it's > > just a performanc

Re: [PATCH 5/7] KVM: arm64: Move 'invalid syndrome' logic out of io_mem_abort()

2020-07-27 Thread Will Deacon
On Sun, Jul 26, 2020 at 12:55:16PM +0100, Marc Zyngier wrote: > On Fri, 24 Jul 2020 15:35:04 +0100, > Will Deacon wrote: > > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c > > index 73e62d360a36..adb933ecd177 100644 > > --- a/arch/arm64/kvm/mmu.c > > +++ b/arch/arm64/kvm/mmu.c > > @@ -20

Re: [PATCH 1/7] KVM: arm64: Update comment when skipping guest MMIO access instruction

2020-07-27 Thread Will Deacon
On Sun, Jul 26, 2020 at 12:08:28PM +0100, Marc Zyngier wrote: > On Fri, 24 Jul 2020 15:35:00 +0100, > Will Deacon wrote: > > > > If a 32-bit guest accesses MMIO using a 16-bit Thumb-2 instruction that > > is reported to the hypervisor without a valid syndrom (for example, > > because of the addre

Re: [PATCH 2/7] KVM: arm64: Rename kvm_vcpu_dabt_isextabt()

2020-07-27 Thread Will Deacon
On Sun, Jul 26, 2020 at 12:15:44PM +0100, Marc Zyngier wrote: > On Fri, 24 Jul 2020 15:35:01 +0100, > Will Deacon wrote: > > > > kvm_vcpu_dabt_isextabt() is not specific to data aborts and has nothing > > to do with sign extension. > > Not sign extension, but external abort (it reads as "is exte

Re: [PATCH 6/7] KVM: arm64: Handle stage-2 faults on stage-1 page-table walks earlier

2020-07-27 Thread Will Deacon
On Sun, Jul 26, 2020 at 02:38:38PM +0100, Marc Zyngier wrote: > On Fri, 24 Jul 2020 15:35:05 +0100, > Will Deacon wrote: > > > > Stage-2 faults on stage-1 page-table walks can occur on both the I-side > > and the D-side. It is IMPLEMENTATATION DEFINED whether they are reported > > as reads or wri

Re: [PATCH 0/3] KVM: arm64: Clean up memcache usage for page-table pages

2020-07-27 Thread Marc Zyngier
Hi Will, On 2020-07-23 12:02, Will Deacon wrote: Hi all, Here are some small cleanups I made to the memcache logic while hacking on the page-table code. The ioremap() behaviour looks like a bug to me, although it's just a performance thing so nothing urgent. Cheers, Will --->8 Will Deaco