[PATCH V2 2/2] KVM: arm64: Increase number of user memslots to 508

[linucherian]

From: Linu Cherian 

Having only 32 memslots is a real constraint for the maximum
number of PCI devices that can be assigned to a single guest.
Assuming each PCI device/virtual function having two memory BAR
regions, we could assign only 15 devices/virtual functions to a
guest.

Hence increase KVM_USER_MEM_SLOTS to 508, so that KVM_MEM_SLOTS_NUM is
512 as done in other archs like x86 and powerpc.

Signed-off-by: Linu Cherian 
---
 arch/arm64/include/asm/kvm_host.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/kvm_host.h 
b/arch/arm64/include/asm/kvm_host.h
index e505038..88f017d 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -30,7 +30,7 @@
 
 #define __KVM_HAVE_ARCH_INTC_INITIALIZED
 
-#define KVM_USER_MEM_SLOTS 32
+#define KVM_USER_MEM_SLOTS 508
 #define KVM_PRIVATE_MEM_SLOTS 4
 #define KVM_COALESCED_MMIO_PAGE_OFFSET 1
 #define KVM_HALT_POLL_NS_DEFAULT 50
-- 
1.9.1

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

[PATCH V2 1/2] KVM: arm/arm64: Enable KVM_CAP_NR_MEMSLOTS on arm/arm64

[linucherian]

From: Linu Cherian 

Return KVM_USER_MEM_SLOTS for userspace capability query on
NR_MEMSLOTS.

Signed-off-by: Linu Cherian 
---
 arch/arm/kvm/arm.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 9d74464..b64b47f 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -221,6 +221,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
case KVM_CAP_MAX_VCPUS:
r = KVM_MAX_VCPUS;
break;
+   case KVM_CAP_NR_MEMSLOTS:
+   r = KVM_USER_MEM_SLOTS;
+   break;
case KVM_CAP_MSI_DEVID:
if (!kvm)
r = -EINVAL;
-- 
1.9.1

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

[PATCH V2 0/2] KVM: arm64: Increase number of user memslots

[linucherian]

From: Linu Cherian 

v1 -> v2:
- Enabling KVM_CAP_NR_MEMSLOTS for arm/arm64 moved to separate patch.
- Updated commit message so that what is reported to userspace is explicit. 

Linu Cherian (2):
  KVM: arm/arm64: Enable KVM_CAP_NR_MEMSLOTS on arm/arm64
  KVM: arm64: Increase number of user memslots to 508

 arch/arm/kvm/arm.c| 3 +++
 arch/arm64/include/asm/kvm_host.h | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

-- 
1.9.1

___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH] KVM: arm64: Increase number of memslots to 512

[Linu Cherian]

On Tue, Feb 7, 2017 at 3:46 PM, Auger Eric  wrote:
> Hi Linu,
>
> On 11/01/2017 17:52, linucher...@gmail.com wrote:
>> From: Linu Cherian 
>>
>> Having only 32 memslots is a real constraint for the maximum number of
>> PCI devices that can be assigned to a single guest. Assuming each PCI
>> device/virtual function having two memory BAR regions, we could assign
>> only 15 devices/virtual functions to a guest.
>>
>> So increase KVM_MEM_SLOTS_NUM to 512 as done in other archs like x86 and
>> powerpc. For this, KVM_USER_MEM_SLOTS has been changed to 508.
>>
>> Signed-off-by: Linu Cherian 
>
>> ---
>>  arch/arm/kvm/arm.c| 3 +++
>>  arch/arm64/include/asm/kvm_host.h | 2 +-
>>  2 files changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> index 8f92efa..a19389b 100644
>> --- a/arch/arm/kvm/arm.c
>> +++ b/arch/arm/kvm/arm.c
>> @@ -221,6 +221,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long 
>> ext)
>>   case KVM_CAP_MAX_VCPUS:
>>   r = KVM_MAX_VCPUS;
>>   break;
>> + case KVM_CAP_NR_MEMSLOTS:
>> + r = KVM_USER_MEM_SLOTS;
>> + break;
> This change is not documented in the commit message and I think it
> should since we now allow KVM/ARM to report the number of available user
> mem slots. I would personally suggest to put it in a sepate patch as it
> was done on s390 for instance
> (http://marc.info/?l=linux-s390=136422861316920=2)
>

Thanks for reviewing. Will send out another version with this fixed.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003

[Christopher Covington]

On 02/01/2017 01:38 PM, Catalin Marinas wrote:
> On Wed, Feb 01, 2017 at 06:34:01PM +, Will Deacon wrote:
>> On Wed, Feb 01, 2017 at 06:22:44PM +, Catalin Marinas wrote:
>>> On Wed, Feb 01, 2017 at 05:59:48PM +, Will Deacon wrote:
 On Wed, Feb 01, 2017 at 05:49:34PM +, Catalin Marinas wrote:
> On Wed, Feb 01, 2017 at 05:41:05PM +, Will Deacon wrote:
>> Maybe
>> just select ARM64_PAN if the erratum workaround is selected, then
>> runtime warning if we find that the h/w doesn't have PAN but does have
>> the erratum (which should never fire)?
>
> You still need this workaround even if you don't want any PAN (both sw
> and hw PAN disabled). I wouldn't want to select ARM64_PAN since it's not
> a dependency. It's more like if you do need a PAN, make sure you only
> use the hw one.

 True, in the case that all PAN options are disabled we still want this
 to work. How about:

   select ARM64_PAN if ARM64_SW_TTBR0_PAN
>>>
>>> As I replied to myself, the above would work for me as well, so let's go
>>> for this.
>>>
 In fact, what's the reason for supporting SW_PAN and ARM64_PAN as a
 config combination? Why not just have "PAN" that enables them both and
 uses the hardware feature if it's there?
>>>
>>> Because SW PAN has a non-trivial performance hit. You would enable SW
>>> PAN only if you are paranoid about security. HW PAN, OTOH, is very cheap
>>> and I wouldn't want to miss enabling it in a single Image supporting
>>> ARMv8.0 and ARMv8.1 just because SW PAN is slow on ARMv8.0.
>>>
>>> IOW, ARM64_PAN is default y while ARM64_SW_TTBR0_PAN is default n.
>>
>> Ok, in that case, then how about another permutation: we make
>> ARM64_SW_TTBR0_PAN depend on ARM64_PAN? Then when you select "PAN Support"
>> you get a new menu option underneath it for the emulation? I think that
>> solves the erratum case and the use-case above.
> 
> The problem is that ARM64_PAN is an ARMv8.1 feature and currently
> grouped accordingly in Kconfig. ARM64_SW_TTBR0_PAN is complementary (and
> even not recommended on ARMv8.1). We can do this if we break the ARMv8.x
> feature grouping but just for this erratum, I don't think it's worth.

Thanks all. I've used "select ARM64_PAN if ARM64_SW_TTBR0_PAN" in v6.

Thanks,
Cov

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH RFC 0/6] target-arm: KVM64: Cross type vCPU support

[Peter Maydell]

On 16 January 2017 at 09:26, Shannon Zhao  wrote:
> From: Shannon Zhao 
>
> This patch set support use cross type vCPU when using KVM on ARM and add
> two new CPU types: generic and cortex-a72.
>
> You can test this patch set with QEMU using
> -cpu cortex-a53/cortex-a57/generic/cortex-a72
>
> These patches can be fetched from:
> https://git.linaro.org/people/shannon.zhao/qemu.git cross_vcpu_rfc
>
> You corresponding KVM patches can be fetched from:
> https://git.linaro.org/people/shannon.zhao/linux-mainline.git cross_vcpu_rfc

We should really document the "generic" option for -cpu somewhere
and what it means. Unfortunately I'm not entirely sure where
that should be :-(  Suggestions welcomed but this isn't a blocker
for this series.

thanks
-- PMM
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH RFC 4/6] target: arm: Add a generic type cpu

[Peter Maydell]

On 16 January 2017 at 09:26, Shannon Zhao  wrote:
> From: Shannon Zhao 
>
> Add a generic type cpu, it's useful for migration when running on
> different hardwares.
>
> Signed-off-by: Shannon Zhao 
> ---
>  target/arm/cpu64.c | 54 
> ++
>  1 file changed, 54 insertions(+)
>
> diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c
> index 549cb1e..223f31e 100644
> --- a/target/arm/cpu64.c
> +++ b/target/arm/cpu64.c
> @@ -204,6 +204,59 @@ static void aarch64_a53_initfn(Object *obj)
>  define_arm_cp_regs(cpu, cortex_a57_a53_cp_reginfo);
>  }
>
> +static void aarch64_generic_initfn(Object *obj)
> +{
> +ARMCPU *cpu = ARM_CPU(obj);
> +
> +cpu->dtb_compatible = "arm,armv8";
> +set_feature(>env, ARM_FEATURE_V8);
> +set_feature(>env, ARM_FEATURE_VFP4);
> +set_feature(>env, ARM_FEATURE_NEON);
> +set_feature(>env, ARM_FEATURE_GENERIC_TIMER);
> +set_feature(>env, ARM_FEATURE_AARCH64);
> +set_feature(>env, ARM_FEATURE_CBAR_RO);
> +set_feature(>env, ARM_FEATURE_V8_AES);
> +set_feature(>env, ARM_FEATURE_V8_SHA1);
> +set_feature(>env, ARM_FEATURE_V8_SHA256);
> +set_feature(>env, ARM_FEATURE_V8_PMULL);
> +set_feature(>env, ARM_FEATURE_CRC);
> +set_feature(>env, ARM_FEATURE_EL3);
> +cpu->kvm_target = QEMU_KVM_ARM_TARGET_GENERIC_V8;
> +cpu->midr = 0x410fd000; /* FIXME: this needs to adjust */
> +cpu->revidr = 0x;
> +cpu->reset_fpsid = 0x41034070;
> +cpu->mvfr0 = 0x10110222;
> +cpu->mvfr1 = 0x1211;
> +cpu->mvfr2 = 0x0043;
> +cpu->ctr = 0x84448004; /* L1Ip = VIPT */
> +cpu->reset_sctlr = 0x00c50838;
> +cpu->id_pfr0 = 0x0131;
> +cpu->id_pfr1 = 0x00011011;
> +cpu->id_dfr0 = 0x03010066;
> +cpu->id_afr0 = 0x;
> +cpu->id_mmfr0 = 0x10101105;
> +cpu->id_mmfr1 = 0x4000;
> +cpu->id_mmfr2 = 0x0126;
> +cpu->id_mmfr3 = 0x02102211;
> +cpu->id_isar0 = 0x02101110;
> +cpu->id_isar1 = 0x13112111;
> +cpu->id_isar2 = 0x21232042;
> +cpu->id_isar3 = 0x01112131;
> +cpu->id_isar4 = 0x00011142;
> +cpu->id_isar5 = 0x00011121;
> +cpu->id_aa64pfr0 = 0x;
> +cpu->id_aa64dfr0 = 0x10305106;
> +cpu->id_aa64isar0 = 0x00011120;
> +cpu->id_aa64mmfr0 = 0x0f001101; /* only support 4k page, 36 bit physical 
> addr */

Not 64K as well? That seems rather limiting.

> +cpu->dbgdidr = 0x3516d000;
> +cpu->clidr = 0x0a200023;
> +cpu->ccsidr[0] = 0x7003e01a; /* 8KB L1 dcache */
> +cpu->ccsidr[1] = 0x2007e00a; /* 8KB L1 icache */
> +cpu->ccsidr[2] = 0x700fe07a; /* 128KB L2 cache */
> +cpu->dcz_blocksize = 4; /* 64 bytes */
> +define_arm_cp_regs(cpu, cortex_a57_a53_cp_reginfo);
> +}

What's the general principle behind the values we're using
here for the various ID and feature registers?

thanks
-- PMM
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH] KVM: arm64: Increase number of memslots to 512

[Auger Eric]

Hi Linu,

On 11/01/2017 17:52, linucher...@gmail.com wrote:
> From: Linu Cherian 
> 
> Having only 32 memslots is a real constraint for the maximum number of
> PCI devices that can be assigned to a single guest. Assuming each PCI
> device/virtual function having two memory BAR regions, we could assign
> only 15 devices/virtual functions to a guest.
> 
> So increase KVM_MEM_SLOTS_NUM to 512 as done in other archs like x86 and
> powerpc. For this, KVM_USER_MEM_SLOTS has been changed to 508.
> 
> Signed-off-by: Linu Cherian 

> ---
>  arch/arm/kvm/arm.c| 3 +++
>  arch/arm64/include/asm/kvm_host.h | 2 +-
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 8f92efa..a19389b 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -221,6 +221,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long 
> ext)
>   case KVM_CAP_MAX_VCPUS:
>   r = KVM_MAX_VCPUS;
>   break;
> + case KVM_CAP_NR_MEMSLOTS:
> + r = KVM_USER_MEM_SLOTS;
> + break;
This change is not documented in the commit message and I think it
should since we now allow KVM/ARM to report the number of available user
mem slots. I would personally suggest to put it in a sepate patch as it
was done on s390 for instance
(http://marc.info/?l=linux-s390=136422861316920=2)

Thanks

Eric

>   case KVM_CAP_MSI_DEVID:
>   if (!kvm)
>   r = -EINVAL;
> diff --git a/arch/arm64/include/asm/kvm_host.h 
> b/arch/arm64/include/asm/kvm_host.h
> index e505038..88f017d 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -30,7 +30,7 @@
>  
>  #define __KVM_HAVE_ARCH_INTC_INITIALIZED
>  
> -#define KVM_USER_MEM_SLOTS 32
> +#define KVM_USER_MEM_SLOTS 508
>  #define KVM_PRIVATE_MEM_SLOTS 4
>  #define KVM_COALESCED_MMIO_PAGE_OFFSET 1
>  #define KVM_HALT_POLL_NS_DEFAULT 50
> 
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH] KVM: arm64: Increase number of memslots to 512

[Marc Zyngier]

On 07/02/17 09:00, Linu Cherian wrote:
> On Tue, Jan 24, 2017 at 2:34 PM, Marc Zyngier  wrote:
>> On 24/01/17 05:06, Linu Cherian wrote:
>>> On Sat, Jan 14, 2017 at 9:53 PM, Geetha Akula
>>>  wrote:
 Hi Marc,

 We have been testing vfio patches regularly. We are in contact with Eric
 offline. In fact we are the first one to test V5 patches on Eric request as
 he had some issue with his test setup.  After our feedback it was posted in
 upstream.
 We also reported issues found with vfio patches. We been contact with Eric
 regularly.

 Thanks,
 Geetha.

 On 14-Jan-2017 4:17 PM, "Marc Zyngier"  wrote:
>
> On Sat, Jan 14 2017 at 09:53:52 AM, Linu Cherian 
> wrote:
>>> Let me be more precise. At the moment, KVM on arm64 doesn't support the
>>> delivery of MSIs generated by physical devices into a guest (patches
>>> are
>>> in progress, but not merged yet). So unless you used devices that have
>>> no need for interrupts, I don't see how this works.
>>>
>>> Can you shed some light on your test process?
>>>
>>
>> We did the testing on top of latest VFIO msi support patches submitted
>> by Eric Auger.
>
> Did you? That's reassuring. It would have been good if any of the Cavium
> folks did chime in on the list and help reviewing though - so far, all
> I've heard is a deafening silence. I guess there was no hurry for Cavium
> to see these patches being merged.
>
>>>
>>> May i know if this patch is queued for merge.
>>
>> Not at the moment, since none of the patches it implicitly depends on
>> are merged yet either. Once Eric's patches are in (or at least in
>> -next), this can be queued - assuming it gets some reviewing too.
>>
> 
> Marc,
> Hope this patch will be queued for merge, since Eric's patches has been 
> pulled.

Pulled, but not merged yet (as in, not in Linus' tree).

Look, I perfectly understand that you want this in, but there is no need
to send me an email every other week asking me whether I've queued it or
not. Once Eric's stuff is in, and provided that this very patch gets
reviewed (hint: nobody has), it will be queued as a fix post -rc1.

In the mean time, please relax.

Thanks,

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