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
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
---
arch/x86/kvm/svm.c | 41 -
1 file changed, 4 insertions(+), 37 deletions(-)
-off-by: David Kaplan
[separated out just cr_interception part from larger removal of
INTERCEPT_CR0_WRITE, forward ported, tested]
Signed-off-by: Joel Schopp
---
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
larger removal of
INTERCEPT_CR0_WRITE, forward ported, tested]
Signed-off-by: Joel Schopp
---
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..57f0240 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86
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(&am
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
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)
+
* removed redundant clearing of count
Changes from v1[Joel]
* Added kvm_fast_pio_in() implementation that was left out of v1
Signed-off-by: David Kaplan
[extracted from larger unlrelated patch, forward ported, addressed reviews,
tested]
Signed-off-by: Joel Schopp
---
arch/x86/include
From: David Kaplan
No need to re-decode WBINVD since we know what it is from the intercept.
Signed-off-by: David Kaplan
[extracted from larger unlrelated patch, forward ported, tested,style cleanup]
Signed-off-by: Joel Schopp
---
arch/x86/kvm/svm.c |8 +++-
1 file changed, 7
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
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/kvm/svm.c |
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
---
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) {
vcpu-
From: David Kaplan
No need to re-decode WBINVD since we know what it is from the intercept.
Signed-off-by: David Kaplan
[extracted from larger unlrelated patch, forward ported, tested]
Signed-off-by: Joel Schopp
---
arch/x86/kvm/svm.c |9 -
1 file changed, 8 insertions(+), 1
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
---
arch/x86/kvm/svm.c |2 --
arch/x86/kvm/vmx.c |9 +++--
arch/x86
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
On 03/02/2015 10:03 AM, Radim Krčmář wrote:
2015-03-02 10:25-0500, Bandan Das:
Radim Krčmář writes:
2015-03-01 21:29-0500, Bandan Das:
Joel Schopp writes:
+static int wbinvd_interception(struct vcpu_svm *svm)
+{
+ kvm_emulate_wbinvd(&svm->vcpu);
+ skip_emulated_inst
-off-by: Joel Schopp
---
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(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86
+ 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
From: David Kaplan
No need to re-decode WBINVD since we know what it is from the intercept.
Signed-off-by: David Kaplan
[extracted from larger unlrelated patch, forward ported, tested]
Signed-off-by: Joel Schopp
---
arch/x86/kvm/svm.c | 10 +-
1 file changed, 9 insertions(+), 1
From: David Kaplan
We can make the in instruction go faster the same way the out instruction is
already.
Signed-off-by: David Kaplan
[extracted from larger unlrelated patch, forward ported, tested]
Signed-off-by: Joel Schopp
---
arch/x86/kvm/svm.c |4 +++-
1 file changed, 3 insertions
From: David Kaplan
We can make the in instruction go faster the same way the out instruction is
already.
Signed-off-by: David Kaplan
[extracted from larger unlrelated patch, forward ported, tested]
Signed-off-by: Joel Schopp
---
arch/x86/kvm/svm.c |4 +++-
1 file changed, 3 insertions
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 n
>> -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
INTERCEPT_SELECTIVE_CR0 and not setting
INTERCEPT_CR0_WRITE.
Signed-off-by: David Kaplan
[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
---
arch/x86/kvm/svm.c | 13 +++--
1 file
From: David Kaplan
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
[forward port and testing]
Signed-off-by: Joel Schopp
---
arch/x86/kvm/svm.c | 19 +--
1 file changed, 9
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
&
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
Signed-off-by:Joel Schopp
---
arch/x86/kvm/svm.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/arch/x86/k
>>> -#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 whe
Add a one liner to identify the gic-400. It's gicv2 with optional MSI
extensions.
Cc: Christoffer Dall
Signed-off-by: Joel Schopp
---
virt/kvm/arm/vgic.c |1 +
1 file changed, 1 insertion(+)
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
index 73eba79..e81444e 100644
--- a
r
Cc: Christoffer Dall
Cc: Sungjinn Chung
Signed-off-by: Jungseok Lee
Signed-off-by: Joel Schopp
---
arch/arm/include/asm/kvm_mmu.h | 13 +++
arch/arm/kvm/arm.c | 23 +++-
arch/arm64/include/asm/kvm_arm.h | 17 ++---
arch/arm64/include/asm/kvm_mmu.h |
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
> To: kvm...@lists.cs.columbia.edu, linux-arm-ker...@lists.infradead.org,
> kvm@vger.kernel.or
Subject: [PATCH] From nobody Tue Sep 2 17:49:46 2014
From: Joel Schopp
To: kvm...@lists.cs.columbia.edu, linux-arm-ker...@lists.infradead.org,
kvm@vger.kernel.org
Cc: Marc Zyngier ,
Sungjinn Chung ,
Christoffer Dall ,
Jungseok Lee
Bcc: ssg.sos.patc...@amd.com
Date: Wed, 03 Sep 2014 13:22:18
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 m
>> 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
> 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
> 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
> allocati
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__ */
>> 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
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
>> thing
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
fail on unaligned vttbr.
Cc: Christoffer Dall
Cc: Sungjinn Chung
Signed-off-by: Jungseok Lee
Signed-off-by: Joel Schopp
---
arch/arm/include/asm/kvm_mmu.h | 12 ++
arch/arm/kvm/arm.c | 17 +++-
arch/arm64/include/asm/kvm_arm.h | 17 +---
arch/arm64/includ
#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 kv
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
https://lists.gnu.org/archive/ht
r as we do more
testing.
Cc: Eirc Auger
Signed-off-by: Joel Schopp
---
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/platform/Kconfig |
ff-by: Jungseok Lee
Signed-off-by: Joel Schopp
---
arch/arm/kvm/arm.c | 116 +-
arch/arm64/include/asm/kvm_arm.h | 17 +-
arch/arm64/kvm/hyp-init.S| 20 +--
3 files changed, 131 insertions(+), 22 deletions(-)
diff --git a/arch/ar
>>> 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),
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
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
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
? For example IDE disk or SATA disk or
maybe as a SCSI disk?
On Wed, Aug 6, 2014 at 9:48 AM, Joel Schopp 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 and moving on. -smp
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, Joe
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
>
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
fix on Jungseok Lee's patch https://lkml.org/lkml/2014/5/12/189 to
provide better long term fix. Updated that patch to log error instead of
silently fail on unaligned vttbr.
Cc: Christoffer Dall
Cc: Sungjinn Chung
Signed-off-by: Jungseok Lee
Signed-off-by: Joel Schopp
---
arch/arm/kvm/
to come out. The resulting one line patch has been tested to fix
the problem.
Cc: Grant Likely
Cc: Rob Herring
Cc: Will Deacon
Signed-off-by: Joel Schopp
---
include/linux/of.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/of.h b/include/linux/of.h
index
hardware that isolates memory from the hypervisor,
ie
https://www.google.com/patents/WO2013054528A1?cl=en&dq=Joel+Schopp&hl=en&sa=X&ei=YYPWU6aVJNProATe5IHACQ&ved=0CDMQ6AEwAw
Another approach might be to start with something like a TPM and a
trusted runtime UEFI. You could then ha
On 07/25/2014 11:02 AM, Peter Maydell wrote:
> On 25 July 2014 16:56, Joel Schopp 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 l
ailing the vgic probe if the physical
> base address or the size of GICV aren't page-aligned. Note that this
> generated a warning in dmesg about freeing enabled IRQs, so I had to
> move the IRQ enabling later in the probe.
>
> Cc: Christoffer Dall
> Cc: Marc Zyngier
> C
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 tr
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,
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-tr
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 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
On 07/24/2014 02:47 PM, Peter Maydell wrote:
> On 24 July 2014 20:27, Will Deacon 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 into the guest.
.o:/extra/sb/linux-kvm/tools/kvm/ui/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
Signed-off-by: Joel Schopp
-
https://lkml.org/lkml/2014/5/12/189 to
provide better long term fix. Updated that patch to log error instead of
silently fail on unaligned vttbr.
Cc: Christoffer Dall
Cc: Sungjinn Chung
Signed-off-by: Jungseok Lee
Signed-off-by: Joel Schopp
---
arch/arm/kvm/arm.c |
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 i
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
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
On 06/25/2014 03:45 PM, Peter Maydell wrote:
On 25 June 2014 20:34, Joel Schopp 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 u
On 06/25/2014 12:34 PM, Peter Maydell wrote:
On 25 June 2014 15:56, Joel Schopp wrote:
On 06/24/2014 05:28 PM, Peter Maydell wrote:
On 24 June 2014 20:28, Joel Schopp wrote:
Does this mean there is a corresponding patch for qemu?
Not as far as I know. It's a bit awkward on the QEM
On 06/24/2014 05:28 PM, Peter Maydell wrote:
On 24 June 2014 20:28, Joel Schopp 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 relative alignme
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 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
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 in
73 matches
Mail list logo
