Re: [PATCH] kvm: x86: svm: remove SVM_EXIT_READ_CR* intercepts

2015-03-16 Thread Joel Schopp
On 03/12/2015 04:20 PM, Radim Krčmář wrote: 2015-03-12 15:17-0500, Joel Schopp: There isn't really a valid reason for kvm to intercept cr* reads on svm hardware. The current kvm code just ends up returning the register There is no need to intercept CR* if the value that the guest should

[PATCH] kvm: x86: svm: remove SVM_EXIT_READ_CR* intercepts

2015-03-12 Thread Joel Schopp
There isn't really a valid reason for kvm to intercept cr* reads on svm hardware. The current kvm code just ends up returning the register Signed-off-by: Joel Schopp joel.sch...@amd.com --- arch/x86/kvm/svm.c | 41 - 1 file changed, 4 insertions(+), 37

[PATCH] x86: svm: use cr_interception for SVM_EXIT_CR0_SEL_WRITE

2015-03-06 Thread Joel Schopp
out just cr_interception part from larger removal of INTERCEPT_CR0_WRITE, forward ported, tested] Signed-off-by: Joel Schopp joel.sch...@amd.com --- arch/x86/kvm/svm.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index d319e0c

[PATCH v2] x86: svm: use cr_interception for SVM_EXIT_CR0_SEL_WRITE

2015-03-06 Thread Joel Schopp
, retested Signed-off-by: David Kaplan david.kap...@amd.com [separated out just cr_interception part from larger removal of INTERCEPT_CR0_WRITE, forward ported, tested] Signed-off-by: Joel Schopp joel.sch...@amd.com --- arch/x86/kvm/svm.c |7 +-- 1 file changed, 5 insertions(+), 2

Re: [PATCH v3] x86: svm: use kvm_fast_pio_in()

2015-03-03 Thread Joel Schopp
Thank you for your detailed review on several of my patches. +static int complete_fast_pio(struct kvm_vcpu *vcpu) (complete_fast_pio_in()?) If I do a v4 I'll adopt that name. +{ +unsigned long new_rax = kvm_register_read(vcpu, VCPU_REGS_RAX); Shouldn't we handle writes in EAX

Re: [PATCH v3] x86: svm: use kvm_fast_pio_in()

2015-03-03 Thread Joel Schopp
On 03/03/2015 10:44 AM, Radim Krčmář wrote: 2015-03-02 15:02-0600, Joel Schopp: +int kvm_fast_pio_in(struct kvm_vcpu *vcpu, int size, unsigned short port) +{ +unsigned long val; +int ret = emulator_pio_in_emulated(vcpu-arch.emulate_ctxt, size

[PATCH v3] x86: svm: use kvm_fast_pio_in()

2015-03-02 Thread Joel Schopp
-off-by: Joel Schopp joel.sch...@amd.com --- arch/x86/include/asm/kvm_host.h |1 + arch/x86/kvm/svm.c |4 +++- arch/x86/kvm/x86.c | 30 ++ 3 files changed, 34 insertions(+), 1 deletion(-) diff --git a/arch/x86/include/asm/kvm_host.h b

Re: [PATCH v2] x86: svm: use kvm_fast_pio_in()

2015-03-02 Thread Joel Schopp
return emulate_instruction(vcpu, 0) == EMULATE_DONE; port = io_info 16; @@ -1907,6 +1907,8 @@ static int io_interception(struct vcpu_svm *svm) svm-next_rip = svm-vmcb-control.exit_info_2; skip_emulated_instruction(svm-vcpu); + if (in) +

Re: [PATCH] x86: svm: use kvm_fast_pio_in()

2015-03-02 Thread Joel Schopp
+ if (in) + return kvm_fast_pio_in(vcpu, size, port); Have I missed a patch that defined kvm_fast_pio_in()? Not sure how I managed to leave out the bulk of the patch. Resending v2 momentarily. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of

Re: [PATCH] x86: svm: make wbinvd faster

2015-03-02 Thread Joel Schopp
On 03/02/2015 10:03 AM, Radim Krčmář wrote: 2015-03-02 10:25-0500, Bandan Das: Radim Krčmář rkrc...@redhat.com writes: 2015-03-01 21:29-0500, Bandan Das: Joel Schopp joel.sch...@amd.com writes: +static int wbinvd_interception(struct vcpu_svm *svm) +{ + kvm_emulate_wbinvd(svm-vcpu

[PATCH v2] x86: svm: use kvm_fast_pio_in()

2015-03-02 Thread Joel Schopp
unlrelated patch, forward ported, tested] Signed-off-by: Joel Schopp joel.sch...@amd.com --- arch/x86/include/asm/kvm_host.h |1 + arch/x86/kvm/svm.c |4 +++- arch/x86/kvm/x86.c | 33 + 3 files changed, 37 insertions(+), 1 deletion

[PATCH v2 0/2] Series short description

2015-03-02 Thread Joel Schopp
Review comments from v1 that used kvm_emulate_wbinvd() pointed out that kvm_emulate_* was inconsistant in using skipping, while kvm_emulate() always skips. The first patch cleans up the existing use while the second patch adds use of the updated version of kvm_emulate_wbinvd() in svm --- Joel

[PATCH v2 1/2] kvm: x86: make kvm_emulate_* consistant

2015-03-02 Thread Joel Schopp
Currently kvm_emulate() skips the instruction but kvm_emulate_* sometimes don't. The end reult is the caller ends up doing the skip themselves. Let's make them consistant. Signed-off-by: Joel Schopp joel.sch...@amd.com --- arch/x86/kvm/svm.c |2 -- arch/x86/kvm/vmx.c |9 +++-- arch

[PATCH v2 2/2] x86: svm: make wbinvd faster

2015-03-02 Thread Joel Schopp
From: David Kaplan david.kap...@amd.com No need to re-decode WBINVD since we know what it is from the intercept. Signed-off-by: David Kaplan david.kap...@amd.com [extracted from larger unlrelated patch, forward ported, tested] Signed-off-by: Joel Schopp joel.sch...@amd.com --- arch/x86/kvm/svm.c

Re: [PATCH v2 1/2] kvm: x86: make kvm_emulate_* consistant

2015-03-02 Thread Joel Schopp
--- diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c @@ -4995,7 +4995,7 @@ static int handle_rmode_exception(struct kvm_vcpu *vcpu, if (emulate_instruction(vcpu, 0) == EMULATE_DONE) { if (vcpu-arch.halt_request) {

[PATCH v3 1/2] kvm: x86: make kvm_emulate_* consistant

2015-03-02 Thread Joel Schopp
Currently kvm_emulate() skips the instruction but kvm_emulate_* sometimes don't. The end reult is the caller ends up doing the skip themselves. Let's make them consistant. Signed-off-by: Joel Schopp joel.sch...@amd.com --- arch/x86/include/asm/kvm_host.h |1 + arch/x86/kvm/svm.c

[PATCH v3 2/2] x86: svm: make wbinvd faster

2015-03-02 Thread Joel Schopp
From: David Kaplan david.kap...@amd.com No need to re-decode WBINVD since we know what it is from the intercept. Signed-off-by: David Kaplan david.kap...@amd.com [extracted from larger unlrelated patch, forward ported, tested,style cleanup] Signed-off-by: Joel Schopp joel.sch...@amd.com

[PATCH v3 0/2] kvm: x86: kvm_emulate_*

2015-03-02 Thread Joel Schopp
since v2: * fixed email subject line on series short description * renamed kvm_emulate_halt_noskip() to kvm_vcpu_halt() * added header declaration for kvm_vcpu_halt() * squashed blank line --- David Kaplan (1): x86: svm: make wbinvd faster Joel Schopp (1

[PATCH] x86: svm: use kvm_fast_pio_in()

2015-02-27 Thread Joel Schopp
From: David Kaplan david.kap...@amd.com We can make the in instruction go faster the same way the out instruction is already. Signed-off-by: David Kaplan david.kap...@amd.com [extracted from larger unlrelated patch, forward ported, tested] Signed-off-by: Joel Schopp joel.sch...@amd.com --- arch

[PATCH] x86: svm: use kvm_fast_pio_in()

2015-02-27 Thread Joel Schopp
From: David Kaplan david.kap...@amd.com We can make the in instruction go faster the same way the out instruction is already. Signed-off-by: David Kaplan david.kap...@amd.com [extracted from larger unlrelated patch, forward ported, tested] Signed-off-by: Joel Schopp joel.sch...@amd.com --- arch

[PATCH] x86: svm: make wbinvd faster

2015-02-27 Thread Joel Schopp
From: David Kaplan david.kap...@amd.com No need to re-decode WBINVD since we know what it is from the intercept. Signed-off-by: David Kaplan david.kap...@amd.com [extracted from larger unlrelated patch, forward ported, tested] Signed-off-by: Joel Schopp joel.sch...@amd.com --- arch/x86/kvm/svm.c

Re: [PATCH] x86: svm: don't intercept CR0 TS or MP bit write

2015-02-25 Thread Joel Schopp
On 02/25/2015 02:26 PM, Radim Krčmář wrote: 2015-02-24 15:25-0600, Joel Schopp: - clr_cr_intercept(svm, INTERCEPT_CR0_WRITE); } else { set_cr_intercept(svm, INTERCEPT_CR0_READ); (There is no point in checking fpu_active if cr0s are equal.) - set_cr_intercept

Re: [PATCH] x86: svm: don't intercept CR0 TS or MP bit write

2015-02-24 Thread Joel Schopp
-clr_cr_intercept(svm, INTERCEPT_CR0_WRITE); } else { set_cr_intercept(svm, INTERCEPT_CR0_READ); (There is no point in checking fpu_active if cr0s are equal.) -set_cr_intercept(svm, INTERCEPT_CR0_WRITE); KVM uses lazy FPU and the state is undefined

[PATCH v2] x86: svm: use kvm_register_write()/read()

2015-02-20 Thread Joel Schopp
From: David Kaplan david.kap...@amd.com KVM has nice wrappers to access the register values, clean up a few places that should use them but currently do not. Signed-off-by: David Kaplan david.kap...@amd.com [forward port and testing] Signed-off-by: Joel Schopp joel.sch...@amd.com --- arch/x86

Re: [PATCH] x86: svm: use kvm_register_write()/read()

2015-02-20 Thread Joel Schopp
On 02/20/2015 02:54 PM, Borislav Petkov wrote: On Fri, Feb 20, 2015 at 12:39:40PM -0600, Joel Schopp wrote: KVM has nice wrappers to access the register values, clean up a few places that should use them but currently do not. Signed-off-by:David Kaplan david.kap...@amd.com Signed-off

[PATCH] x86: svm: don't intercept CR0 TS or MP bit write

2015-02-20 Thread Joel Schopp
is setting INTERCEPT_SELECTIVE_CR0 and not setting INTERCEPT_CR0_WRITE. Signed-off-by: David Kaplan david.kap...@amd.com [added remove of clr_cr_intercept in init_vmcb, fixed check in handle_exit, added emulation on interception back in, forward ported, tested] Signed-off-by: Joel Schopp joel.sch

[PATCH] x86: svm: use kvm_register_write()/read()

2015-02-20 Thread Joel Schopp
KVM has nice wrappers to access the register values, clean up a few places that should use them but currently do not. Signed-off-by:David Kaplan david.kap...@amd.com Signed-off-by:Joel Schopp joel.sch...@amd.com --- arch/x86/kvm/svm.c | 19 +-- 1 file changed, 9 insertions(+),

Re: [PATCH v6] arm64: fix VTTBR_BADDR_MASK

2014-09-22 Thread Joel Schopp
-#define VTTBR_BADDR_SHIFT (VTTBR_X - 1) -#define VTTBR_BADDR_MASK (((1LLU (40 - VTTBR_X)) - 1) VTTBR_BADDR_SHIFT) Actually, after some more thinking, why don't we just make the upper limit of this mask 48-bit always or even 64-bit. That's a physical mask for checking whether the pgd

[PATCH 6] From nobody Wed Sep 3 13:22:18 2014

2014-09-08 Thread Joel Schopp
Subject: [PATCH] From nobody Tue Sep 2 17:49:46 2014 From: Joel Schopp joel.sch...@amd.com To: kvm...@lists.cs.columbia.edu, linux-arm-ker...@lists.infradead.org, kvm@vger.kernel.org Cc: Marc Zyngier marc.zyng...@arm.com, Sungjinn Chung sungjinn.ch...@samsung.com, Christoffer Dall

Re: [PATCH 6] From nobody Wed Sep 3 13:22:18 2014

2014-09-08 Thread Joel Schopp
My apologies for the bad formatting. Will resend momentarily. On 09/08/2014 06:01 PM, Joel Schopp wrote: Subject: [PATCH] From nobody Tue Sep 2 17:49:46 2014 From: Joel Schopp joel.sch...@amd.com To: kvm...@lists.cs.columbia.edu, linux-arm-ker...@lists.infradead.org, kvm@vger.kernel.org

[PATCH v6] arm64: fix VTTBR_BADDR_MASK

2014-09-08 Thread Joel Schopp
marc.zyng...@arm.com Cc: Christoffer Dall christoffer.d...@linaro.org Cc: Sungjinn Chung sungjinn.ch...@samsung.com Signed-off-by: Jungseok Lee jays@samsung.com Signed-off-by: Joel Schopp joel.sch...@amd.com --- arch/arm/include/asm/kvm_mmu.h | 13 +++ arch/arm/kvm/arm.c | 23

[PATCH] KVM: arm64: add gic-400 compatible

2014-09-08 Thread Joel Schopp
Add a one liner to identify the gic-400. It's gicv2 with optional MSI extensions. Cc: Christoffer Dall christoffer.d...@linaro.org Signed-off-by: Joel Schopp joel.sch...@amd.com --- virt/kvm/arm/vgic.c |1 + 1 file changed, 1 insertion(+) diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm

Re: [PATCH v10 0/6] arm: dirty page logging support for ARMv7

2014-08-28 Thread Joel Schopp
On 08/26/2014 06:51 PM, Mario Smarduch wrote: This patch adds support for ARMv7 dirty page logging. Some functions of dirty page logging have been split to generic and arch specific implementations, details below. Dirty page logging is one of serveral features required for live migration, live

Re: [PATCH v5] arm64: fix VTTBR_BADDR_MASK

2014-08-26 Thread Joel Schopp
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h index 5c7aa3c..73f6ff6 100644 --- a/arch/arm/include/asm/kvm_mmu.h +++ b/arch/arm/include/asm/kvm_mmu.h @@ -166,6 +166,18 @@ static inline void coherent_cache_guest_page(struct kvm_vcpu *vcpu, hva_t hva, void

Re: [PATCH v4] arm64: fix VTTBR_BADDR_MASK

2014-08-19 Thread Joel Schopp
On 08/19/2014 07:22 AM, Christoffer Dall wrote: On Mon, Aug 18, 2014 at 03:30:58PM -0500, Joel Schopp wrote: #endif /* __ARM_KVM_MMU_H__ */ diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c index 16e7994..70f0f02 100644 --- a/arch/arm/kvm/mmu.c +++ b/arch/arm/kvm/mmu.c @@ -521,6 +521,7

Re: [PATCH v5] arm64: fix VTTBR_BADDR_MASK

2014-08-19 Thread Joel Schopp
On 08/19/2014 07:24 AM, Christoffer Dall wrote: On Mon, Aug 18, 2014 at 03:36:04PM -0500, Joel Schopp wrote: The current VTTBR_BADDR_MASK only masks 39 bits, which is broken on current systems. Rather than just add a bit it seems like a good time to also set things at run-time instead

Re: [PATCH v5] arm64: fix VTTBR_BADDR_MASK

2014-08-19 Thread Joel Schopp
The return is a value,not just an error code. Because of this returning an error overloads that value. 0 just seemed like a convenient invalid value to check since a vttbr_x of 0 is invalid, but returning a negative error code would be as equally invalid. If this is the only issue it

Re: [PATCH v4] arm64: fix VTTBR_BADDR_MASK

2014-08-19 Thread Joel Schopp
On 08/19/2014 09:37 AM, Christoffer Dall wrote: On Tue, Aug 19, 2014 at 09:05:09AM -0500, Joel Schopp wrote: On 08/19/2014 07:22 AM, Christoffer Dall wrote: On Mon, Aug 18, 2014 at 03:30:58PM -0500, Joel Schopp wrote: #endif /* __ARM_KVM_MMU_H__ */ diff --git a/arch/arm/kvm/mmu.c b/arch/arm

Re: [PATCH v5] arm64: fix VTTBR_BADDR_MASK

2014-08-19 Thread Joel Schopp
hmmm, the point is that we need to ensure that we have a properly aligned allocated PGD, that's what this patch currently addresses, and as you pointed out, the BUG_ON() just before trying to run a VM is not the nicest solution - we should really be dealing with this properly at allocation

Re: [RFC 0/4] VFIO: PLATFORM: Return device tree info for a platform device node

2014-08-19 Thread Joel Schopp
This RFC's intention is to show what an interface to access device node properties for VFIO_PLATFORM can look like. If a device tree node corresponding to a platform device bound by VFIO_PLATFORM is available, this patch series will allow the user to query the properties associated with

Re: [PATCH v4] arm64: fix VTTBR_BADDR_MASK

2014-08-18 Thread Joel Schopp
#endif /* __ARM_KVM_MMU_H__ */ diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c index 16e7994..70f0f02 100644 --- a/arch/arm/kvm/mmu.c +++ b/arch/arm/kvm/mmu.c @@ -521,6 +521,7 @@ int create_hyp_io_mappings(void *from, void *to, phys_addr_t phys_addr) */ int kvm_alloc_stage2_pgd(struct

[PATCH v5] arm64: fix VTTBR_BADDR_MASK

2014-08-18 Thread Joel Schopp
on unaligned vttbr. Cc: Christoffer Dall christoffer.d...@linaro.org Cc: Sungjinn Chung sungjinn.ch...@samsung.com Signed-off-by: Jungseok Lee jays@samsung.com Signed-off-by: Joel Schopp joel.sch...@amd.com --- arch/arm/include/asm/kvm_mmu.h | 12 ++ arch/arm/kvm/arm.c

Re: [Qemu-devel] The status about vhost-net on kvm-arm?

2014-08-14 Thread Joel Schopp
we at Virtual Open Systems did some work and tested vhost-net on ARM back in March. The setup was based on: - host kernel with our ioeventfd patches: http://www.spinics.net/lists/kvm-arm/msg08413.html - qemu with the aforementioned patches from Ying-Shiuan Pan

Re: [PATCH v3] arm64: fix VTTBR_BADDR_MASK

2014-08-11 Thread Joel Schopp
Thanks for the detailed review. the last case would be case 5 and the default case would be a BUG(). I agree with the case, but rather than do a BUG() I'm going to print an error and return -EINVAL. Not worth stopping the host kernel just because kvm is messed up when we can gracefully exit from

Re: KVM call for agenda for 2014-08-19

2014-08-11 Thread Joel Schopp
On 08/11/2014 08:09 AM, Juan Quintela wrote: Hi Please, send any topic that you are interested in covering. People have complained on the past that I don't cancel the call until the very last minute. So, what do you think that deadline for submitting topics is 23:00UTC on Monday? I like

Re: [PATCH v3] arm64: fix VTTBR_BADDR_MASK

2014-08-11 Thread Joel Schopp
That said, I don't think this is doing the right thing. I think you want to refuse running the VM and avoid any stage-2 entried being created if this is not the case (actually, we may want to check this after set_vttbr_baddr_mask() or right aftert allocating the stage-2 pgd), because

[PATCH v4] arm64: fix VTTBR_BADDR_MASK

2014-08-11 Thread Joel Schopp
Chung sungjinn.ch...@samsung.com Signed-off-by: Jungseok Lee jays@samsung.com Signed-off-by: Joel Schopp joel.sch...@amd.com --- arch/arm/kvm/arm.c | 116 +- arch/arm64/include/asm/kvm_arm.h | 17 +- arch/arm64/kvm/hyp-init.S| 20

[RFC PATCH] arm64: KVM: add irqfd support

2014-08-11 Thread Joel Schopp
testing. Cc: Eirc Auger eric.au...@linaro.org Signed-off-by: Joel Schopp joel.sch...@amd.com --- Documentation/virtual/kvm/api.txt |2 +- arch/arm64/include/uapi/asm/kvm.h |4 arch/arm64/kvm/Kconfig|4 +++- arch/arm64/kvm/Makefile |2 +- drivers/vfio

Re: KVM on ARM64

2014-08-07 Thread Joel Schopp
? For example IDE disk or SATA disk or maybe as a SCSI disk? On Wed, Aug 6, 2014 at 9:48 AM, Joel Schopp joel.sch...@amd.com wrote: It turns out that after a recent rebase of my kernel and qemu to the latest the problem is fixed. Rather than hunt down what fixed it I'm just accepting the win

Re: KVM on ARM64

2014-08-07 Thread Joel Schopp
On 08/07/2014 12:53 PM, Christoffer Dall wrote: Currently we only model a virtual machine board (the -machine type=virt parameter) which has a UART, a flash, an RTC, and a bunch of virtio-mmio channelse. Once we either emulate a real aarch64 board (with whatever peripherals it may have) or add

Re: KVM on ARM64

2014-08-06 Thread Joel Schopp
It turns out that after a recent rebase of my kernel and qemu to the latest the problem is fixed. Rather than hunt down what fixed it I'm just accepting the win and moving on. -smp 4 now works. -Joel On 08/06/2014 11:15 AM, Christoffer Dall wrote: On Tue, Aug 5, 2014 at 4:18 PM, Joel Schopp

Re: KVM on ARM64

2014-08-05 Thread Joel Schopp
On 08/04/2014 07:35 PM, Mathew Li wrote: Hi, I have a quick question. How do we add a hard disk to the qemu ARM VM? I tried: qemu-system-aarch64 -machine virt -hda disk.img -kernel image -initrd initrd.img qemu-system-aarch64 -machine virt -sd disk.img -kernel image -initrd

[PATCH v3] arm64: fix VTTBR_BADDR_MASK

2014-08-04 Thread Joel Schopp
jays@samsung.com Signed-off-by: Joel Schopp joel.sch...@amd.com --- arch/arm/kvm/arm.c | 91 +- arch/arm64/include/asm/kvm_arm.h | 17 +-- arch/arm64/kvm/hyp-init.S| 20 ++-- 3 files changed, 106 insertions(+), 22 deletions

Re: [PATCH v3] arm64: fix VTTBR_BADDR_MASK

2014-08-04 Thread Joel Schopp
Since this fixes a real problem and didn't make it into 3.16 it would be good if this made it into 3.17. -Joel On 08/04/2014 09:38 AM, Joel Schopp wrote: The current VTTBR_BADDR_MASK only masks 39 bits, which is broken on current systems. Rather than just add a bit it seems like a good time

[PATCH] arm64: bump MAX_MASTER_STREAMIDS from 16 to 32

2014-07-31 Thread Joel Schopp
to come out. The resulting one line patch has been tested to fix the problem. Cc: Grant Likely grant.lik...@linaro.org Cc: Rob Herring robh...@kernel.org Cc: Will Deacon will.dea...@arm.com Signed-off-by: Joel Schopp joel.sch...@amd.com --- include/linux/of.h |2 +- 1 file changed, 1 insertion

Re: Verifying Execution Integrity in Untrusted hypervisors

2014-07-28 Thread Joel Schopp
On 07/25/2014 03:11 PM, Shiva V wrote: Hello, I am exploring on finding a way to ensure runtime integrity of a executable in untrusted hypervisors. In particular, this is my requirements: 1. I have a 2 virtual machines. (A, B). 2. VM-A is running some service (exe) inside it. For

Re: [PATCH] kvm: arm64: vgic: fix hyp panic with 64k pages on juno platform

2014-07-25 Thread Joel Schopp
I can't think of any way of determining whether a particular system gets this right or wrong automatically, which suggests perhaps we need to allow the device tree to specify that the GICV is 64k-page-safe... When we support such systems, I also think we'll need a device-tree change. My

Re: [PATCH] kvm: arm64: vgic: fix hyp panic with 64k pages on juno platform

2014-07-25 Thread Joel Schopp
On 07/25/2014 09:08 AM, Will Deacon wrote: Hi Joel, On Fri, Jul 25, 2014 at 03:02:58PM +0100, Joel Schopp wrote: I can't think of any way of determining whether a particular system gets this right or wrong automatically, which suggests perhaps we need to allow the device tree to specify

Re: [PATCH] kvm: arm64: vgic: fix hyp panic with 64k pages on juno platform

2014-07-25 Thread Joel Schopp
On 07/25/2014 09:23 AM, Will Deacon wrote: On Fri, Jul 25, 2014 at 03:16:15PM +0100, Joel Schopp wrote: On 07/25/2014 09:08 AM, Will Deacon wrote: This would break with my SOC device tree which looks like this. Note this device tree works just fine without checks. gic: interrupt

Re: [PATCH v2] kvm: arm64: vgic: fix hyp panic with 64k pages on juno platform

2014-07-25 Thread Joel Schopp
...@redhat.com Cc: Joel Schopp joel.sch...@amd.com Cc: Don Dutile ddut...@redhat.com Acked-by: Peter Maydell peter.mayd...@linaro.org Signed-off-by: Will Deacon will.dea...@arm.com --- v1 -v2 : Added size alignment check and Peter's ack. Could this go in for 3.16 please? virt/kvm/arm

Re: [PATCH v2] kvm: arm64: vgic: fix hyp panic with 64k pages on juno platform

2014-07-25 Thread Joel Schopp
On 07/25/2014 11:02 AM, Peter Maydell wrote: On 25 July 2014 16:56, Joel Schopp joel.sch...@amd.com wrote: The problem with this patch is the gicv is really 8K. The reason you would map at a 60K offset (0xf000), and why we do on our SOC, is so that the 8K gicv would pick up the last 4K from

Re: [PATCH] kvm: arm64: vgic: fix hyp panic with 64k pages on juno platform

2014-07-24 Thread Joel Schopp
On 07/24/2014 02:47 PM, Peter Maydell wrote: On 24 July 2014 20:27, Will Deacon will.dea...@arm.com wrote: If the physical address of GICV isn't page-aligned, then we end up creating a stage-2 mapping of the page containing it, which causes us to map neighbouring memory locations directly

Re: [PATCH] kvm: arm64: vgic: fix hyp panic with 64k pages on juno platform

2014-07-24 Thread Joel Schopp
On 07/24/2014 02:55 PM, Will Deacon wrote: On Thu, Jul 24, 2014 at 08:47:23PM +0100, Peter Maydell wrote: On 24 July 2014 20:27, Will Deacon will.dea...@arm.com wrote: If the physical address of GICV isn't page-aligned, then we end up creating a stage-2 mapping of the page containing it,

[PATCH] kvmtool: arm64: fix compilation error

2014-07-22 Thread Joel Schopp
/gtk3.c:219: more undefined references to `kbd_queue' follow collect2: error: ld returned 1 exit status make: *** [lkvm] Error 1 The patch below makes the error go away and the resulting lkvm runs on arm64. Cc: Pekka Enberg penb...@kernel.org Signed-off-by: Joel Schopp joel.sch...@amd.com

[PATCH v2] arm64: fix VTTBR_BADDR_MASK

2014-07-11 Thread Joel Schopp
-by: Joel Schopp joel.sch...@amd.com --- arch/arm/kvm/arm.c | 91 +- arch/arm64/include/asm/kvm_arm.h | 17 +-- arch/arm64/kvm/hyp-init.S| 20 ++-- 3 files changed, 106 insertions(+), 22 deletions(-) diff --git a/arch/arm/kvm

Re: [PATCH] arm64: fix VTTBR_BADDR_MASK

2014-07-10 Thread Joel Schopp
On 07/10/2014 03:25 PM, Christoffer Dall wrote: On Wed, Jul 09, 2014 at 11:17:04AM -0500, Joel Schopp wrote: The current calculation for VTTBR_BADDR_MASK masks only 39 bits and not all 40 bits. That last bit is important as some systems allocate from near the top of the available address

Re: [PATCH] arm64: fix VTTBR_BADDR_MASK

2014-07-10 Thread Joel Schopp
On 07/10/2014 04:02 PM, Joel Schopp wrote: On 07/10/2014 03:25 PM, Christoffer Dall wrote: On Wed, Jul 09, 2014 at 11:17:04AM -0500, Joel Schopp wrote: The current calculation for VTTBR_BADDR_MASK masks only 39 bits and not all 40 bits. That last bit is important as some systems allocate

[PATCH] arm64: fix VTTBR_BADDR_MASK

2014-07-09 Thread Joel Schopp
The current calculation for VTTBR_BADDR_MASK masks only 39 bits and not all 40 bits. That last bit is important as some systems allocate from near the top of the available address space. This patch is necessary to run KVM on an aarch64 SOC I have been testing. Signed-off-by: Joel Schopp

Re: [PATCH v2 9/9] arm64: KVM: vgic: deal with GIC sub-page alignment

2014-06-25 Thread Joel Schopp
On 06/25/2014 10:00 AM, Marc Zyngier wrote: On 25/06/14 15:56, Joel Schopp wrote: On 06/24/2014 05:28 PM, Peter Maydell wrote: On 24 June 2014 20:28, Joel Schopp joel.sch...@amd.com wrote: On 06/19/2014 04:21 AM, Marc Zyngier wrote: The GIC CPU interface is always 4k aligned. If the host

Re: [PATCH v2 9/9] arm64: KVM: vgic: deal with GIC sub-page alignment

2014-06-25 Thread Joel Schopp
On 06/24/2014 05:28 PM, Peter Maydell wrote: On 24 June 2014 20:28, Joel Schopp joel.sch...@amd.com wrote: On 06/19/2014 04:21 AM, Marc Zyngier wrote: The GIC CPU interface is always 4k aligned. If the host is using 64k pages, it is critical to place the guest's GICC interface at the same

Re: [PATCH v2 9/9] arm64: KVM: vgic: deal with GIC sub-page alignment

2014-06-25 Thread Joel Schopp
On 06/25/2014 12:34 PM, Peter Maydell wrote: On 25 June 2014 15:56, Joel Schopp joel.sch...@amd.com wrote: On 06/24/2014 05:28 PM, Peter Maydell wrote: On 24 June 2014 20:28, Joel Schopp joel.sch...@amd.com wrote: Does this mean there is a corresponding patch for qemu? Not as far as I know

Re: [PATCH v2 9/9] arm64: KVM: vgic: deal with GIC sub-page alignment

2014-06-25 Thread Joel Schopp
On 06/25/2014 03:45 PM, Peter Maydell wrote: On 25 June 2014 20:34, Joel Schopp joel.sch...@amd.com wrote: It doesn't work for me. Maybe I'm doing something wrong, but I can't see what. I am unique in that I'm running a gic-400 (gicv2m) on aarch64 hardware with 64k pages. I'm also unique

Re: [PATCH v2 9/9] arm64: KVM: vgic: deal with GIC sub-page alignment

2014-06-24 Thread Joel Schopp
On 06/19/2014 04:21 AM, Marc Zyngier wrote: The GIC CPU interface is always 4k aligned. If the host is using 64k pages, it is critical to place the guest's GICC interface at the same relative alignment as the host's GICV. Failure to do so results in an impossibility for the guest to deal with