[PATCH] kvm: arm: LPAE: Incorrect device to IPA mapping

[marek.majtyka]

From: Marek Majtyka 

A critical bug has been found in device memory stage1 translation for machines
with more then 4GB of RAM. Once vm_pgoff size is smaller then pa (which is true
for LPAE case, u32 and u64 respectively) some more significant bits of pa may
be lost as a shift operation is performed on u32 and later cast onto u64.

Example: vm_pgoff(u32)=0x00210030, PAGE_SHIFT=12
expected pa(u64):   0x00201003
produced pa(u64):   0x1003

A suggested fix is changing the order of operations (casting first onto
phys_addr_t and then shifting), which works for both alternatives
(with and without LPAE).

A bug has been found, fixed and tested on kernel v3.19. However, it seems to be
valid for most, if not all, newer version starting from v3.18.

Signed-off-by: Marek Majtyka 
---
 arch/arm/kvm/mmu.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index 1366625..602bc63 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -1408,7 +1408,8 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
if (vma->vm_flags & VM_PFNMAP) {
gpa_t gpa = mem->guest_phys_addr +
(vm_start - mem->userspace_addr);
-   phys_addr_t pa = (vma->vm_pgoff << PAGE_SHIFT) +
+   phys_addr_t pa =
+   ((phys_addr_t) vma->vm_pgoff << PAGE_SHIFT) +
 vm_start - vma->vm_start;
 
ret = kvm_phys_addr_ioremap(kvm, gpa, pa,
-- 
1.9.1

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

Re: [PATCH] kvm: arm: LPAE: Incorrect device to IPA mapping

[Marc Zyngier]

Hi Marek,

On 16/09/15 11:04, marek.majtyka wrote:
> From: Marek Majtyka 
> 
> A critical bug has been found in device memory stage1 translation for machines
> with more then 4GB of RAM. Once vm_pgoff size is smaller then pa (which is 
> true
> for LPAE case, u32 and u64 respectively) some more significant bits of pa may
> be lost as a shift operation is performed on u32 and later cast onto u64.
> 
> Example: vm_pgoff(u32)=0x00210030, PAGE_SHIFT=12
> expected pa(u64):   0x00201003
> produced pa(u64):   0x1003
> 
> A suggested fix is changing the order of operations (casting first onto
> phys_addr_t and then shifting), which works for both alternatives
> (with and without LPAE).

Well, you can't use KVM without LPAE, so that's a moot point. Also, the
issue is when you place things above 4GB, not when you have more than
4GB of RAM (I cannot see how you allocate that amount of memory from
userspace on 32bit).

> 
> A bug has been found, fixed and tested on kernel v3.19. However, it seems to 
> be
> valid for most, if not all, newer version starting from v3.18.
> 
> Signed-off-by: Marek Majtyka 
> ---
>  arch/arm/kvm/mmu.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 1366625..602bc63 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -1408,7 +1408,8 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
>   if (vma->vm_flags & VM_PFNMAP) {
>   gpa_t gpa = mem->guest_phys_addr +
>   (vm_start - mem->userspace_addr);
> - phys_addr_t pa = (vma->vm_pgoff << PAGE_SHIFT) +
> + phys_addr_t pa =
> + ((phys_addr_t) vma->vm_pgoff << PAGE_SHIFT) +
>vm_start - vma->vm_start;
>  
>   ret = kvm_phys_addr_ioremap(kvm, gpa, pa,
> 

Looks perfectly valid to me (the formatting is horrible, but I can fix
that - I can only guess you've followed checkpatch's silly advise).

Reviewed-by: Marc Zyngier 

Christoffer: if you're OK with that one, I'll add it to the next batch
of fixes.

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

Re: [PATCH] arm64: KVM: Fix user access for debug registers

[Marc Zyngier]

On 16/09/15 14:41, Christoffer Dall wrote:
> On Wed, Sep 16, 2015 at 11:41:10AM +0100, Marc Zyngier wrote:
>> When setting the debug register from userspace, make sure that
>> copy_from_user() is called with its parameters in the expected
>> order. It otherwise doesn't do what you think.
>>
>> Reported-by: Peter Maydell 
>> Cc: Alex Bennée 
>> Fixes: 84e690bfbed1 ("KVM: arm64: introduce vcpu->arch.debug_ptr")
>> Signed-off-by: Marc Zyngier 
>
> yikes!
>
> Reviewed-by: Christoffer Dall 
>

Thanks. Merged and pushed out to -next, together with the physaddr_t patch.

M.
--
Jazz is not dead. It just smells funny...



-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

Re: [PATCH] kvm: arm: LPAE: Incorrect device to IPA mapping

[Christoffer Dall]

On Wed, Sep 16, 2015 at 11:33:37AM +0100, Marc Zyngier wrote:
> Hi Marek,
> 
> On 16/09/15 11:04, marek.majtyka wrote:
> > From: Marek Majtyka 
> > 
> > A critical bug has been found in device memory stage1 translation for 
> > machines
> > with more then 4GB of RAM. Once vm_pgoff size is smaller then pa (which is 
> > true
> > for LPAE case, u32 and u64 respectively) some more significant bits of pa 
> > may
> > be lost as a shift operation is performed on u32 and later cast onto u64.
> > 
> > Example: vm_pgoff(u32)=0x00210030, PAGE_SHIFT=12
> > expected pa(u64):   0x00201003
> > produced pa(u64):   0x1003
> > 
> > A suggested fix is changing the order of operations (casting first onto
> > phys_addr_t and then shifting), which works for both alternatives
> > (with and without LPAE).
> 
> Well, you can't use KVM without LPAE, so that's a moot point. Also, the
> issue is when you place things above 4GB, not when you have more than
> 4GB of RAM (I cannot see how you allocate that amount of memory from
> userspace on 32bit).
> 
> > 
> > A bug has been found, fixed and tested on kernel v3.19. However, it seems 
> > to be
> > valid for most, if not all, newer version starting from v3.18.
> > 
> > Signed-off-by: Marek Majtyka 
> > ---
> >  arch/arm/kvm/mmu.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> > index 1366625..602bc63 100644
> > --- a/arch/arm/kvm/mmu.c
> > +++ b/arch/arm/kvm/mmu.c
> > @@ -1408,7 +1408,8 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
> > if (vma->vm_flags & VM_PFNMAP) {
> > gpa_t gpa = mem->guest_phys_addr +
> > (vm_start - mem->userspace_addr);
> > -   phys_addr_t pa = (vma->vm_pgoff << PAGE_SHIFT) +
> > +   phys_addr_t pa =
> > +   ((phys_addr_t) vma->vm_pgoff << PAGE_SHIFT) +
> >  vm_start - vma->vm_start;
> >  
> > ret = kvm_phys_addr_ioremap(kvm, gpa, pa,
> > 
> 
> Looks perfectly valid to me (the formatting is horrible, but I can fix
> that - I can only guess you've followed checkpatch's silly advise).
> 
> Reviewed-by: Marc Zyngier 
> 
> Christoffer: if you're OK with that one, I'll add it to the next batch
> of fixes.
> 
Yup, looks good to me.

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

Re: [PATCH] arm64: KVM: Fix user access for debug registers

[Alex Bennée]

Christoffer Dall  writes:

> On Wed, Sep 16, 2015 at 11:41:10AM +0100, Marc Zyngier wrote:
>> When setting the debug register from userspace, make sure that
>> copy_from_user() is called with its parameters in the expected
>> order. It otherwise doesn't do what you think.
>> 
>> Reported-by: Peter Maydell 
>> Cc: Alex Bennée 
>> Fixes: 84e690bfbed1 ("KVM: arm64: introduce vcpu->arch.debug_ptr")
>> Signed-off-by: Marc Zyngier 
>
> yikes!

OK I'm now muchly confused as to how it could have worked...

>
> Reviewed-by: Christoffer Dall 

-- 
Alex Bennée
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [Qemu-devel] Could not boot a guest vm from kvm mode based on APM X-Gene Host and latest qemu

[Alex Bennée]

liang yan  writes:

> Hello, All,
>
> I am trying to enable kvm for a guest vm on an APM X-Gene Host with 
> latest qemu, but could not make it work.
>
> The host is APM X-Gene 8-core, Linux kernel is 4.1.0-rc7-1-arm64,
>
> Guest kernel is linux-3.16rc3
>
> QEMU is latest version
>
> Host has these dmesg info
> [2.708259] kvm [1]: GICH base=0x780c, GICV base=0x780e, IRQ=25
> [2.708327] kvm [1]: timer IRQ30
> [2.708335] kvm [1]: Hyp mode initialized successfully
>
> Host has dev/kvm.
>
> command-line is
> aarch64-softmmu/qemu-system-aarch64 -machine virt,kernel_irqchip=off 
> -cpu cortex-a57 -machine accel=kvm -nographic -smp 1 -m 2048 -kernel 
> aarch64-linux-3.16rc3-buildroot.img  --append "console=ttyAMA0"

I thought I recognised one of my images ;-)

Why are you running with kernel_irqchip=off?

Without it I can boot the image fine on my APM running 4.3.0-rc1-ajb but
with it I helpfully seg the kernel:

[16035.990518] Bad mode in Synchronous Abort handler detected, code 0x8606 
-- IABT (current EL)
[16035.997970] CPU: 1 PID: 21328 Comm: qemu-system-aar Not tainted 
4.3.0-rc1-ajb #446
[16036.004203] Hardware name: APM X-Gene Mustang board (DT)
[16036.008191] task: ffc3ecea8000 ti: ffc3d8078000 task.ti: 
ffc3d8078000
[16036.014338] PC is at 0x0
[16036.015564] LR is at kvm_vgic_map_resources+0x30/0x3c
[16036.019291] pc : [<>] lr : [] pstate: 
0145
[16036.025350] sp : ffc3d807bb20
[16036.027348] x29: ffc3d807bb20 x28: ffc3d8078000 
[16036.031355] x27: ffc000642000 x26: 001d 
[16036.035361] x25: 011b x24: ffc3d80c1000 
[16036.039368] x23:  x22:  
[16036.043374] x21: ffc0fa24 x20: ffc0fa807800 
[16036.047380] x19: ffc0fa807800 x18: 007f97af20e0 
[16036.051387] x17: 007f99c44810 x16: ffc0001fb030 
[16036.055394] x15: 007f99cc9588 x14: 00922000 
[16036.059401] x13: 0097eb80 x12: 004de0f0 
[16036.063406] x11: 0038 x10:  
[16036.067413] x9 : 007f97af2480 x8 : 0050 
[16036.071419] x7 : ffc3ec24c840 x6 :  
[16036.075424] x5 : 0003 x4 : ffc3ece72080 
[16036.079430] x3 : ffc3ece72080 x2 :  
[16036.083436] x1 : ffc000a26260 x0 : ffc0fa807800 

[16036.087628] Internal error: Oops - bad mode: 0 [#1] SMP
[16036.091528] Modules linked in:
[16036.093278] CPU: 1 PID: 21328 Comm: qemu-system-aar Not tainted 
4.3.0-rc1-ajb #446
[16036.099510] Hardware name: APM X-Gene Mustang board (DT)
[16036.103497] task: ffc3ecea8000 ti: ffc3d8078000 task.ti: 
ffc3d8078000
[16036.109642] PC is at 0x0
[16036.110864] LR is at kvm_vgic_map_resources+0x30/0x3c
[16036.114590] pc : [<>] lr : [] pstate: 
0145
[16036.120649] sp : ffc3d807bb20
[16036.122648] x29: ffc3d807bb20 x28: ffc3d8078000 
[16036.126654] x27: ffc000642000 x26: 001d 
[16036.130659] x25: 011b x24: ffc3d80c1000 
[16036.134666] x23:  x22:  
[16036.138671] x21: ffc0fa24 x20: ffc0fa807800 
[16036.142678] x19: ffc0fa807800 x18: 007f97af20e0 
[16036.146685] x17: 007f99c44810 x16: ffc0001fb030 
[16036.150690] x15: 007f99cc9588 x14: 00922000 
[16036.154696] x13: 0097eb80 x12: 004de0f0 
[16036.158701] x11: 0038 x10:  
[16036.162706] x9 : 007f97af2480 x8 : 0050 
[16036.166712] x7 : ffc3ec24c840 x6 :  
[16036.170719] x5 : 0003 x4 : ffc3ece72080 
[16036.174725] x3 : ffc3ece72080 x2 :  
[16036.178731] x1 : ffc000a26260 x0 : ffc0fa807800 

>
>
> when using cpu "cortex-a57", got the error "kvm_init_vcpu failed: 
> Invalid argument"
> when using cpu "host", got the error "Failed to retrieve host CPU features!"
>
> By the way, all the command line works well under "tcg" mode.
> Anyone has a quick idea? Thanks in advance.
>
> Best,
> Liang

-- 
Alex Bennée
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

[PATCH 3/3] arm: KVM: Disable virtual timer even if the guest is not using it

[Marc Zyngier]

When running a guest with the architected timer disabled (with QEMU and
the kernel_irqchip=off option, for example), it is important to make
sure the timer gets turned off. Otherwise, the guest may try to
enable it anyway, leading to a screaming HW interrupt.

The fix is to unconditionally turn off the virtual timer on guest
exit.

Cc: sta...@vger.kernel.org
Signed-off-by: Marc Zyngier 
---
 arch/arm/kvm/interrupts_head.S | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kvm/interrupts_head.S b/arch/arm/kvm/interrupts_head.S
index 702740d..51a5950 100644
--- a/arch/arm/kvm/interrupts_head.S
+++ b/arch/arm/kvm/interrupts_head.S
@@ -515,8 +515,7 @@ ARM_BE8(rev r6, r6  )
 
mrc p15, 0, r2, c14, c3, 1  @ CNTV_CTL
str r2, [vcpu, #VCPU_TIMER_CNTV_CTL]
-   bic r2, #1  @ Clear ENABLE
-   mcr p15, 0, r2, c14, c3, 1  @ CNTV_CTL
+
isb
 
mrrcp15, 3, rr_lo_hi(r2, r3), c14   @ CNTV_CVAL
@@ -529,6 +528,9 @@ ARM_BE8(rev r6, r6  )
mcrrp15, 4, r2, r2, c14 @ CNTVOFF
 
 1:
+   mov r2, #0  @ Clear ENABLE
+   mcr p15, 0, r2, c14, c3, 1  @ CNTV_CTL
+
@ Allow physical timer/counter access for the host
mrc p15, 4, r2, c14, c1, 0  @ CNTHCTL
orr r2, r2, #(CNTHCTL_PL1PCEN | CNTHCTL_PL1PCTEN)
-- 
2.1.4

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

[PATCH 1/3] arm/arm64: KVM: vgic: Check for !irqchip_in_kernel() when mapping resources

[Marc Zyngier]

From: Pavel Fedin 

Until b26e5fdac43c ("arm/arm64: KVM: introduce per-VM ops"),
kvm_vgic_map_resources() used to include a check on irqchip_in_kernel(),
and vgic_v2_map_resources() still has it.

But now vm_ops are not initialized until we call kvm_vgic_create().
Therefore kvm_vgic_map_resources() can being called without a VGIC,
and we die because vm_ops.map_resources is NULL.

Fixing this restores QEMU's kernel-irqchip=off option to a working state,
allowing to use GIC emulation in userspace.

Fixes: b26e5fdac43c ("arm/arm64: KVM: introduce per-VM ops")
Cc: sta...@vger.kernel.org
Signed-off-by: Pavel Fedin 
[maz: reworked commit message]
Signed-off-by: Marc Zyngier 
---
 arch/arm/kvm/arm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index ce404a5..dc017ad 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -446,7 +446,7 @@ static int kvm_vcpu_first_run_init(struct kvm_vcpu *vcpu)
 * Map the VGIC hardware resources before running a vcpu the first
 * time on this VM.
 */
-   if (unlikely(!vgic_ready(kvm))) {
+   if (unlikely(irqchip_in_kernel(kvm) && !vgic_ready(kvm))) {
ret = kvm_vgic_map_resources(kvm);
if (ret)
return ret;
-- 
2.1.4

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

[PATCH 0/3] arm/arm64: KVM: Fix !irqchip_in_kernel() handling

[Marc Zyngier]

It is quite obvious that the non kernel-irqchip has been bitrotting
for a while now. Pavel has been doing some work to address this, but
it turns out that there is more fun to be had...

This series picks up one of Pavel's series (which is an obvious fix),
and adds another fix for both arm and arm64.

With these two patches applied, I get a working system as long as I
don't need timers - which is expected.

Tested on X-Gene.

Marc Zyngier (2):
  arm64: KVM: Disable virtual timer even if the guest is not using it
  arm: KVM: Disable virtual timer even if the guest is not using it

Pavel Fedin (1):
  arm/arm64: KVM: vgic: Check for !irqchip_in_kernel() when mapping
resources

 arch/arm/kvm/arm.c | 2 +-
 arch/arm/kvm/interrupts_head.S | 6 --
 arch/arm64/kvm/hyp.S   | 4 ++--
 3 files changed, 7 insertions(+), 5 deletions(-)

-- 
2.1.4

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

Re: [PATCH v2 00/22] KVM: ARM64: Add guest PMU support

[Wei Huang]

On 09/11/2015 03:54 AM, Shannon Zhao wrote:
> From: Shannon Zhao 
> 
> This patchset adds guest PMU support for KVM on ARM64. It takes
> trap-and-emulate approach. When guest wants to monitor one event, it
> will be trapped by KVM and KVM will call perf_event API to create a perf
> event and call relevant perf_event APIs to get the count value of event.
> 
> Use perf to test this patchset in guest. When using "perf list", it
> shows the list of the hardware events and hardware cache events perf
> supports. Then use "perf stat -e EVENT" to monitor some event. For
> example, use "perf stat -e cycles" to count cpu cycles and
> "perf stat -e cache-misses" to count cache misses.
> 
> Below are the outputs of "perf stat -r 5 sleep 5" when running in host
> and guest.
> 
> Host:
>  Performance counter stats for 'sleep 5' (5 runs):
> 
>   0.551428  task-clock (msec) #0.000 CPUs utilized
> ( +-  0.91% )
>  1  context-switches  #0.002 M/sec
>  0  cpu-migrations#0.000 K/sec
> 48  page-faults   #0.088 M/sec
> ( +-  1.05% )
>1150265  cycles#2.086 GHz  
> ( +-  0.92% )
>  stalled-cycles-frontend
>  stalled-cycles-backend
> 526398  instructions  #0.46  insns per cycle  
> ( +-  0.89% )
>  branches
>   9485  branch-misses #   17.201 M/sec
> ( +-  2.35% )
> 
>5.000831616 seconds time elapsed   
>( +-  0.00% )
> 
> Guest:
>  Performance counter stats for 'sleep 5' (5 runs):
> 
>   0.730868  task-clock (msec) #0.000 CPUs utilized
> ( +-  1.13% )
>  1  context-switches  #0.001 M/sec
>  0  cpu-migrations#0.000 K/sec
> 48  page-faults   #0.065 M/sec
> ( +-  0.42% )
>1642982  cycles#2.248 GHz  
> ( +-  1.04% )
>  stalled-cycles-frontend
>  stalled-cycles-backend
> 637964  instructions  #0.39  insns per cycle  
> ( +-  0.65% )
>  branches
>  10377  branch-misses #   14.198 M/sec
> ( +-  1.09% )
> 
>5.001289068 seconds time elapsed   
>( +-  0.00% )
> 
> This patchset can be fetched from [1] and the relevant QEMU version for
> test can be fetched from [2].
> 
> Thanks,
> Shannon
> 
> [1] https://git.linaro.org/people/shannon.zhao/linux-mainline.git  
> KVM_ARM64_PMU_v2
> [2] https://git.linaro.org/people/shannon.zhao/qemu.git  PMU_v2

I am testing this series. The first question is: do you plan to add ACPI
support in QEMU? My in-house kernel uses ACPI for device probing. I had
to force "acpi=off" when I test this patch series.

> 
> Shannon Zhao (22):
>   ARM64: Move PMU register related defines to asm/pmu.h
>   KVM: ARM64: Define PMU data structure for each vcpu
>   KVM: ARM64: Add offset defines for PMU registers
>   KVM: ARM64: Add reset and access handlers for PMCR_EL0 register
>   KVM: ARM64: Add a helper for CP15 registers reset to UNKNOWN
>   KVM: ARM64: Add reset and access handlers for PMSELR register
>   KVM: ARM64: Add reset and access handlers for PMCEID0 and PMCEID1
> register
>   KVM: ARM64: PMU: Add perf event map and introduce perf event creating
> function
>   KVM: ARM64: Add reset and access handlers for PMXEVTYPER register
>   KVM: ARM64: Add reset and access handlers for PMXEVCNTR register
>   KVM: ARM64: Add reset and access handlers for PMCCNTR register
>   KVM: ARM64: Add reset and access handlers for PMCNTENSET and
> PMCNTENCLR register
>   KVM: ARM64: Add reset and access handlers for PMINTENSET and
> PMINTENCLR register
>   KVM: ARM64: Add reset and access handlers for PMOVSSET and PMOVSCLR
> register
>   KVM: ARM64: Add a helper for CP15 registers reset to specified value
>   KVM: ARM64: Add reset and access handlers for PMUSERENR register
>   KVM: ARM64: Add reset and access handlers for PMSWINC register
>   KVM: ARM64: Add access handlers for PMEVCNTRn and PMEVTYPERn register
>   KVM: ARM64: Add PMU overflow interrupt routing
>   KVM: ARM64: Reset PMU state when resetting vcpu
>   KVM: ARM64: Free perf event of PMU when destroying vcpu
>   KVM: ARM64: Add a new kvm ARM PMU device
> 
>  Documentation/virtual/kvm/devices/arm-pmu.txt |  15 +
>  arch/arm/kvm/arm.c|   4 +
>  arch/arm64/include/asm/kvm_asm.h  |  59 ++-
>  arch/arm64/include/asm/kvm_host.h |   2 +
>  arch/arm64/include/asm/pmu.h  |  49 +++
>  arch/arm64/include/uapi/asm/kvm.h 

Re: [PATCH v2 00/22] KVM: ARM64: Add guest PMU support

[Shannon Zhao]

Hi Wei,

On 2015/9/17 5:07, Wei Huang wrote:
> I am testing this series. 
Thanks for your time and help.

> The first question is: do you plan to add ACPI
> support in QEMU?
To the completeness, this should be added. Maybe this could be added at
v3. But I have a look at the kernel PMU driver, it doesn't support
probing through ACPI, although there are some patches[1] out-of-tree.

> My in-house kernel uses ACPI for device probing. I had
> to force "acpi=off" when I test this patch series.
Guest kernel only boots with ACPI when you add "acpi=force". No need to
add "acpi=off".

Thanks,

[1] http://marc.info/?l=linaro-acpi=137949337925645=2
-- 
Shannon
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [Qemu-devel] Could not boot a guest vm from kvm mode based on APM X-Gene Host and latest qemu

[Marc Zyngier]

On 16/09/15 15:34, Alex Bennée wrote:
> 
> liang yan  writes:
> 
>> Hello, All,
>>
>> I am trying to enable kvm for a guest vm on an APM X-Gene Host with 
>> latest qemu, but could not make it work.
>>
>> The host is APM X-Gene 8-core, Linux kernel is 4.1.0-rc7-1-arm64,
>>
>> Guest kernel is linux-3.16rc3
>>
>> QEMU is latest version
>>
>> Host has these dmesg info
>> [2.708259] kvm [1]: GICH base=0x780c, GICV base=0x780e, IRQ=25
>> [2.708327] kvm [1]: timer IRQ30
>> [2.708335] kvm [1]: Hyp mode initialized successfully
>>
>> Host has dev/kvm.
>>
>> command-line is
>> aarch64-softmmu/qemu-system-aarch64 -machine virt,kernel_irqchip=off 
>> -cpu cortex-a57 -machine accel=kvm -nographic -smp 1 -m 2048 -kernel 
>> aarch64-linux-3.16rc3-buildroot.img  --append "console=ttyAMA0"
> 
> I thought I recognised one of my images ;-)
> 
> Why are you running with kernel_irqchip=off?
> 
> Without it I can boot the image fine on my APM running 4.3.0-rc1-ajb but
> with it I helpfully seg the kernel:
> 
> [16035.990518] Bad mode in Synchronous Abort handler detected, code 
> 0x8606 -- IABT (current EL)
> [16035.997970] CPU: 1 PID: 21328 Comm: qemu-system-aar Not tainted 
> 4.3.0-rc1-ajb #446
> [16036.004203] Hardware name: APM X-Gene Mustang board (DT)
> [16036.008191] task: ffc3ecea8000 ti: ffc3d8078000 task.ti: 
> ffc3d8078000
> [16036.014338] PC is at 0x0
> [16036.015564] LR is at kvm_vgic_map_resources+0x30/0x3c
> [16036.019291] pc : [<>] lr : [] pstate: 
> 0145
> [16036.025350] sp : ffc3d807bb20
> [16036.027348] x29: ffc3d807bb20 x28: ffc3d8078000 
> [16036.031355] x27: ffc000642000 x26: 001d 
> [16036.035361] x25: 011b x24: ffc3d80c1000 
> [16036.039368] x23:  x22:  
> [16036.043374] x21: ffc0fa24 x20: ffc0fa807800 
> [16036.047380] x19: ffc0fa807800 x18: 007f97af20e0 
> [16036.051387] x17: 007f99c44810 x16: ffc0001fb030 
> [16036.055394] x15: 007f99cc9588 x14: 00922000 
> [16036.059401] x13: 0097eb80 x12: 004de0f0 
> [16036.063406] x11: 0038 x10:  
> [16036.067413] x9 : 007f97af2480 x8 : 0050 
> [16036.071419] x7 : ffc3ec24c840 x6 :  
> [16036.075424] x5 : 0003 x4 : ffc3ece72080 
> [16036.079430] x3 : ffc3ece72080 x2 :  
> [16036.083436] x1 : ffc000a26260 x0 : ffc0fa807800 
> 
> [16036.087628] Internal error: Oops - bad mode: 0 [#1] SMP
> [16036.091528] Modules linked in:
> [16036.093278] CPU: 1 PID: 21328 Comm: qemu-system-aar Not tainted 
> 4.3.0-rc1-ajb #446
> [16036.099510] Hardware name: APM X-Gene Mustang board (DT)
> [16036.103497] task: ffc3ecea8000 ti: ffc3d8078000 task.ti: 
> ffc3d8078000
> [16036.109642] PC is at 0x0
> [16036.110864] LR is at kvm_vgic_map_resources+0x30/0x3c
> [16036.114590] pc : [<>] lr : [] pstate: 
> 0145
> [16036.120649] sp : ffc3d807bb20
> [16036.122648] x29: ffc3d807bb20 x28: ffc3d8078000 
> [16036.126654] x27: ffc000642000 x26: 001d 
> [16036.130659] x25: 011b x24: ffc3d80c1000 
> [16036.134666] x23:  x22:  
> [16036.138671] x21: ffc0fa24 x20: ffc0fa807800 
> [16036.142678] x19: ffc0fa807800 x18: 007f97af20e0 
> [16036.146685] x17: 007f99c44810 x16: ffc0001fb030 
> [16036.150690] x15: 007f99cc9588 x14: 00922000 
> [16036.154696] x13: 0097eb80 x12: 004de0f0 
> [16036.158701] x11: 0038 x10:  
> [16036.162706] x9 : 007f97af2480 x8 : 0050 
> [16036.166712] x7 : ffc3ec24c840 x6 :  
> [16036.170719] x5 : 0003 x4 : ffc3ece72080 
> [16036.174725] x3 : ffc3ece72080 x2 :  
> [16036.178731] x1 : ffc000a26260 x0 : ffc0fa807800 

I've posted the relevant patches there:

https://lists.cs.columbia.edu/pipermail/kvmarm/2015-September/016487.html

I'd appreciate any form of testing.

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