KVM Development List

Christoffer Dall | 15 Jun 2012 21:06

[PATCH v8 00/15] KVM/ARM Implementation

The following series implements KVM support for ARM processors,
specifically on the Cortex A-15 platform.  Work is done in
collaboration between Columbia University, Virtual Open Systems and
ARM/Linaro.

The patch series applies to kvm/next, specifically commit:
25e531a988ea5a64bd97a72dc9d3c65ad5850120

This is Version 8 of the patch series, but the first two versions
were reviewed outside of the KVM mailing list. Changes can also be
pulled from:
 git://github.com/virtualopensystems/linux-kvm-arm.git kvm-a15-v8

A non-flattened edition of the patch series can be found at:
 git://github.com/virtualopensystems/linux-kvm-arm.git kvm-a15-v8-stage

The implementation is broken up into a logical set of patches, the first
four are preparatory patches:
 1. Add mem_type prot_pte accessor (ARM community)
 2. Use KVM_CAP_IRQ_ROUTING to protect routing code  (KVM community)
 3. Introduce __KVM_HAVE_IRQ_LINE (KVM community)
 4. Guard code with CONFIG_MMU_NOTIFIER (KVM community)

KVM guys, please consider pulling the KVM generic patches as early as
possible. Thanks.

The main implementation is broken up into separate patches, the first
containing a skeleton of files, makefile changes, the basic user space
interface and KVM architecture specific stubs.  Subsequent patches
implement parts of the system as listed:

(Continue reading)

headers

Christoffer Dall | 15 Jun 2012 21:07

[PATCH v8 03/15] KVM: Introduce __KVM_HAVE_IRQ_LINE

This is a preparatory patch for the KVM/ARM implementation. KVM/ARM will use
the KVM_IRQ_LINE ioctl, which is currently conditional on
__KVM_HAVE_IOAPIC, but ARM obviously doesn't have any IOAPIC support and we
need a separate define.

Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
---
 arch/ia64/include/asm/kvm.h |    1 +
 arch/x86/include/asm/kvm.h  |    1 +
 include/trace/events/kvm.h  |    4 +++-
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/ia64/include/asm/kvm.h b/arch/ia64/include/asm/kvm.h
index b9f82c8..ec6c6b3 100644
--- a/arch/ia64/include/asm/kvm.h
+++ b/arch/ia64/include/asm/kvm.h
 <at>  <at>  -26,6 +26,7  <at>  <at> 

 /* Select x86 specific features in <linux/kvm.h> */
 #define __KVM_HAVE_IOAPIC
+#define __KVM_HAVE_IRQ_LINE
 #define __KVM_HAVE_DEVICE_ASSIGNMENT

 /* Architectural interrupt line count. */
diff --git a/arch/x86/include/asm/kvm.h b/arch/x86/include/asm/kvm.h
index e7d1c19..246617e 100644
--- a/arch/x86/include/asm/kvm.h
+++ b/arch/x86/include/asm/kvm.h
 <at>  <at>  -12,6 +12,7  <at>  <at> 
 /* Select x86 specific features in <linux/kvm.h> */

(Continue reading)

headers

Avi Kivity | 18 Jun 2012 15:07

Re: [PATCH v8 03/15] KVM: Introduce __KVM_HAVE_IRQ_LINE

On 06/15/2012 10:07 PM, Christoffer Dall wrote:
> This is a preparatory patch for the KVM/ARM implementation. KVM/ARM will use
> the KVM_IRQ_LINE ioctl, which is currently conditional on
> __KVM_HAVE_IOAPIC, but ARM obviously doesn't have any IOAPIC support and we
> need a separate define.
> 

Thanks, applied.

--

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Christoffer Dall | 15 Jun 2012 21:07

[PATCH v8 06/15] ARM: KVM: Hypervisor identity mapping

Adds support in the identity mapping feature that allows KVM to setup
identity mapping for the Hyp mode with the AP[1] bit set as required by
the specification and also supports freeing created sub pmd's after
finished use.

These two functions:
 - hyp_idmap_add(pgd, addr, end);
 - hyp_idmap_del(pgd, addr, end);
are essentially calls to the same function as the non-hyp versions but
with a different argument value. KVM calls these functions to setup
and teardown the identity mapping used to initialize the hypervisor.

Note, the hyp-version of the _del function actually frees the pmd's
pointed to by the pgd as opposed to the non-hyp version which just
clears them.

Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
---
 arch/arm/include/asm/pgtable-3level-hwdef.h |    1 +
 arch/arm/include/asm/pgtable.h              |    5 +++
 arch/arm/kvm/guest.c                        |    1 -
 arch/arm/mm/idmap.c                         |   47 +++++++++++++++++++++++++--
 4 files changed, 49 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/pgtable-3level-hwdef.h b/arch/arm/include/asm/pgtable-3level-hwdef.h
index d795282..a2d404e 100644
--- a/arch/arm/include/asm/pgtable-3level-hwdef.h
+++ b/arch/arm/include/asm/pgtable-3level-hwdef.h
 <at>  <at>  -44,6 +44,7  <at>  <at> 
 #define PMD_SECT_XN		(_AT(pmdval_t, 1) << 54)

(Continue reading)

headers

Avi Kivity | 18 Jun 2012 15:12

Re: [PATCH v8 06/15] ARM: KVM: Hypervisor identity mapping

On 06/15/2012 10:07 PM, Christoffer Dall wrote:
> Adds support in the identity mapping feature that allows KVM to setup
> identity mapping for the Hyp mode with the AP[1] bit set as required by
> the specification and also supports freeing created sub pmd's after
> finished use.
> 
> These two functions:
>  - hyp_idmap_add(pgd, addr, end);
>  - hyp_idmap_del(pgd, addr, end);
> are essentially calls to the same function as the non-hyp versions but
> with a different argument value. KVM calls these functions to setup
> and teardown the identity mapping used to initialize the hypervisor.
> 
> Note, the hyp-version of the _del function actually frees the pmd's
> pointed to by the pgd as opposed to the non-hyp version which just
> clears them.

I asked previously what happens if two data structures share a page, and
one of them is removed.  Is that handled now?  How?

Why not just identity map all memory?  You can use large pages so it's
fast and doesn't consume a lot of page table memory.--
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

headers

Christoffer Dall | 18 Jun 2012 19:55

Re: [PATCH v8 06/15] ARM: KVM: Hypervisor identity mapping

On Mon, Jun 18, 2012 at 9:12 AM, Avi Kivity <avi <at> redhat.com> wrote:
> On 06/15/2012 10:07 PM, Christoffer Dall wrote:
>> Adds support in the identity mapping feature that allows KVM to setup
>> identity mapping for the Hyp mode with the AP[1] bit set as required by
>> the specification and also supports freeing created sub pmd's after
>> finished use.
>>
>> These two functions:
>>  - hyp_idmap_add(pgd, addr, end);
>>  - hyp_idmap_del(pgd, addr, end);
>> are essentially calls to the same function as the non-hyp versions but
>> with a different argument value. KVM calls these functions to setup
>> and teardown the identity mapping used to initialize the hypervisor.
>>
>> Note, the hyp-version of the _del function actually frees the pmd's
>> pointed to by the pgd as opposed to the non-hyp version which just
>> clears them.
>
>
> I asked previously what happens if two data structures share a page, and
> one of them is removed.  Is that handled now?  How?
>

I think you asked previously for the general hyp-mode mappings, not
the identity mappings. For the general hyp-mode mappings we simply
don't unmap the data structures, potentially leaking a few pages for
the page tables themselves.

This is only for initialization, so there are not really any data
structures mapped, only one/two pages to initialize the hypervisor

(Continue reading)

headers

Avi Kivity | 19 Jun 2012 10:38

Re: [PATCH v8 06/15] ARM: KVM: Hypervisor identity mapping

On 06/18/2012 08:55 PM, Christoffer Dall wrote:
> On Mon, Jun 18, 2012 at 9:12 AM, Avi Kivity <avi <at> redhat.com> wrote:
>> On 06/15/2012 10:07 PM, Christoffer Dall wrote:
>>> Adds support in the identity mapping feature that allows KVM to setup
>>> identity mapping for the Hyp mode with the AP[1] bit set as required by
>>> the specification and also supports freeing created sub pmd's after
>>> finished use.
>>>
>>> These two functions:
>>>  - hyp_idmap_add(pgd, addr, end);
>>>  - hyp_idmap_del(pgd, addr, end);
>>> are essentially calls to the same function as the non-hyp versions but
>>> with a different argument value. KVM calls these functions to setup
>>> and teardown the identity mapping used to initialize the hypervisor.
>>>
>>> Note, the hyp-version of the _del function actually frees the pmd's
>>> pointed to by the pgd as opposed to the non-hyp version which just
>>> clears them.
>>
>>
>> I asked previously what happens if two data structures share a page, and
>> one of them is removed.  Is that handled now?  How?
>>
> 
> I think you asked previously for the general hyp-mode mappings, not
> the identity mappings. For the general hyp-mode mappings we simply
> don't unmap the data structures, potentially leaking a few pages for
> the page tables themselves.
> 
> This is only for initialization, so there are not really any data

(Continue reading)

headers

Christoffer Dall | 15 Jun 2012 21:07

[PATCH v8 04/15] KVM: Guard mmu_notifier specific code with CONFIG_MMU_NOTIFIER

From: Marc Zyngier <marc.zyngier <at> arm.com>

In order to avoid compilation failure when KVM is not compiled in,
guard the mmu_notifier specific sections with both CONFIG_MMU_NOTIFIER
and KVM_ARCH_WANT_MMU_NOTIFIER, like it is being done in the rest of
the KVM code.

Signed-off-by: Marc Zyngier <marc.zyngier <at> arm.com>
Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
---
 include/linux/kvm_host.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index c7f7787..e3c86f8 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
 <at>  <at>  -306,7 +306,7  <at>  <at>  struct kvm {
 	struct hlist_head irq_ack_notifier_list;
 #endif

-#ifdef KVM_ARCH_WANT_MMU_NOTIFIER
+#if defined(CONFIG_MMU_NOTIFIER) && defined(KVM_ARCH_WANT_MMU_NOTIFIER)
 	struct mmu_notifier mmu_notifier;
 	unsigned long mmu_notifier_seq;
 	long mmu_notifier_count;
 <at>  <at>  -780,7 +780,7  <at>  <at>  struct kvm_stats_debugfs_item {
 extern struct kvm_stats_debugfs_item debugfs_entries[];
 extern struct dentry *kvm_debugfs_dir;

(Continue reading)

headers

Avi Kivity | 18 Jun 2012 15:08

Re: [PATCH v8 04/15] KVM: Guard mmu_notifier specific code with CONFIG_MMU_NOTIFIER

On 06/15/2012 10:07 PM, Christoffer Dall wrote:
> From: Marc Zyngier <marc.zyngier <at> arm.com>
> 
> In order to avoid compilation failure when KVM is not compiled in,
> guard the mmu_notifier specific sections with both CONFIG_MMU_NOTIFIER
> and KVM_ARCH_WANT_MMU_NOTIFIER, like it is being done in the rest of
> the KVM code.
> 
>  
> -#ifdef KVM_ARCH_WANT_MMU_NOTIFIER
> +#if defined(CONFIG_MMU_NOTIFIER) && defined(KVM_ARCH_WANT_MMU_NOTIFIER)
>  	struct mmu_notifier mmu_notifier;
>  	unsigned long mmu_notifier_seq;
>  	long mmu_notifier_count;
>  <at>  <at>  -780,7 +780,7  <at>  <at>  struct kvm_stats_debugfs_item {
>  extern struct kvm_stats_debugfs_item debugfs_entries[];
>  extern struct dentry *kvm_debugfs_dir;
>  
> -#ifdef KVM_ARCH_WANT_MMU_NOTIFIER
> +#if defined(CONFIG_MMU_NOTIFIER) && defined(KVM_ARCH_WANT_MMU_NOTIFIER)
>  static inline int mmu_notifier_retry(struct kvm_vcpu *vcpu, unsigned long mmu_seq)
>  {

Why not have Kconfig select CONFIG_MMU_NOTIFIER?

--

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in

(Continue reading)

headers

Christoffer Dall | 18 Jun 2012 19:47

Re: [PATCH v8 04/15] KVM: Guard mmu_notifier specific code with CONFIG_MMU_NOTIFIER

On Mon, Jun 18, 2012 at 9:08 AM, Avi Kivity <avi <at> redhat.com> wrote:
> On 06/15/2012 10:07 PM, Christoffer Dall wrote:
>> From: Marc Zyngier <marc.zyngier <at> arm.com>
>>
>> In order to avoid compilation failure when KVM is not compiled in,
>> guard the mmu_notifier specific sections with both CONFIG_MMU_NOTIFIER
>> and KVM_ARCH_WANT_MMU_NOTIFIER, like it is being done in the rest of
>> the KVM code.
>>
>>
>> -#ifdef KVM_ARCH_WANT_MMU_NOTIFIER
>> +#if defined(CONFIG_MMU_NOTIFIER) && defined(KVM_ARCH_WANT_MMU_NOTIFIER)
>>       struct mmu_notifier mmu_notifier;
>>       unsigned long mmu_notifier_seq;
>>       long mmu_notifier_count;
>>  <at>  <at>  -780,7 +780,7  <at>  <at>  struct kvm_stats_debugfs_item {
>>  extern struct kvm_stats_debugfs_item debugfs_entries[];
>>  extern struct dentry *kvm_debugfs_dir;
>>
>> -#ifdef KVM_ARCH_WANT_MMU_NOTIFIER
>> +#if defined(CONFIG_MMU_NOTIFIER) && defined(KVM_ARCH_WANT_MMU_NOTIFIER)
>>  static inline int mmu_notifier_retry(struct kvm_vcpu *vcpu, unsigned long mmu_seq)
>>  {
>
> Why not have Kconfig select CONFIG_MMU_NOTIFIER?
>
>
Not sure I understand. Where would you select this option?

We do select this option when choosing to compile KVM on, but when we

(Continue reading)

headers

Avi Kivity | 19 Jun 2012 10:37

Re: [PATCH v8 04/15] KVM: Guard mmu_notifier specific code with CONFIG_MMU_NOTIFIER

On 06/18/2012 08:47 PM, Christoffer Dall wrote:
> On Mon, Jun 18, 2012 at 9:08 AM, Avi Kivity <avi <at> redhat.com> wrote:
>> On 06/15/2012 10:07 PM, Christoffer Dall wrote:
>>> From: Marc Zyngier <marc.zyngier <at> arm.com>
>>>
>>> In order to avoid compilation failure when KVM is not compiled in,
>>> guard the mmu_notifier specific sections with both CONFIG_MMU_NOTIFIER
>>> and KVM_ARCH_WANT_MMU_NOTIFIER, like it is being done in the rest of
>>> the KVM code.
>>>
>>>
>>> -#ifdef KVM_ARCH_WANT_MMU_NOTIFIER
>>> +#if defined(CONFIG_MMU_NOTIFIER) && defined(KVM_ARCH_WANT_MMU_NOTIFIER)
>>>       struct mmu_notifier mmu_notifier;
>>>       unsigned long mmu_notifier_seq;
>>>       long mmu_notifier_count;
>>>  <at>  <at>  -780,7 +780,7  <at>  <at>  struct kvm_stats_debugfs_item {
>>>  extern struct kvm_stats_debugfs_item debugfs_entries[];
>>>  extern struct dentry *kvm_debugfs_dir;
>>>
>>> -#ifdef KVM_ARCH_WANT_MMU_NOTIFIER
>>> +#if defined(CONFIG_MMU_NOTIFIER) && defined(KVM_ARCH_WANT_MMU_NOTIFIER)
>>>  static inline int mmu_notifier_retry(struct kvm_vcpu *vcpu, unsigned long mmu_seq)
>>>  {
>>
>> Why not have Kconfig select CONFIG_MMU_NOTIFIER?
>>
>>
> Not sure I understand. Where would you select this option?
>

(Continue reading)

headers

Marcelo Tosatti | 28 Jun 2012 23:28

Re: [PATCH v8 04/15] KVM: Guard mmu_notifier specific code with CONFIG_MMU_NOTIFIER

On Fri, Jun 15, 2012 at 03:07:24PM -0400, Christoffer Dall wrote:
> From: Marc Zyngier <marc.zyngier <at> arm.com>
> 
> In order to avoid compilation failure when KVM is not compiled in,
> guard the mmu_notifier specific sections with both CONFIG_MMU_NOTIFIER
> and KVM_ARCH_WANT_MMU_NOTIFIER, like it is being done in the rest of
> the KVM code.
> 
> Signed-off-by: Marc Zyngier <marc.zyngier <at> arm.com>
> Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
> ---
>  include/linux/kvm_host.h |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Applied, thanks.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Christoffer Dall | 15 Jun 2012 21:07

[PATCH v8 05/15] ARM: KVM: Initial skeleton to compile KVM support

From: Christoffer Dall <cdall <at> cs.columbia.edu>

Targets KVM support for Cortex A-15 processors.

Contains no real functionality but all the framework components,
make files, header files and some tracing functionality.

“Nothing to see here. Move along, move along..."

Most functionality is in arch/arm/kvm/* or arch/arm/include/asm/kvm_*.h.

Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
---
 arch/arm/Kconfig                   |    2 
 arch/arm/Makefile                  |    1 
 arch/arm/include/asm/kvm.h         |   78 ++++++++++
 arch/arm/include/asm/kvm_asm.h     |   28 ++++
 arch/arm/include/asm/kvm_emulate.h |   97 +++++++++++++
 arch/arm/include/asm/kvm_host.h    |  116 +++++++++++++++
 arch/arm/include/asm/unified.h     |   12 ++
 arch/arm/kvm/Kconfig               |   44 ++++++
 arch/arm/kvm/Makefile              |   17 ++
 arch/arm/kvm/arm.c                 |  279 ++++++++++++++++++++++++++++++++++++
 arch/arm/kvm/emulate.c             |  125 ++++++++++++++++
 arch/arm/kvm/exports.c             |   16 ++
 arch/arm/kvm/guest.c               |  148 +++++++++++++++++++
 arch/arm/kvm/init.S                |   17 ++
 arch/arm/kvm/interrupts.S          |   17 ++
 arch/arm/kvm/mmu.c                 |   15 ++
 arch/arm/kvm/trace.h               |   52 +++++++

(Continue reading)

headers

Christoffer Dall | 15 Jun 2012 21:08

[PATCH v8 08/15] ARM: KVM: Module unloading support

Current initialization code relies on the MMU-bit and TE-bit of the
HSCTLR register to be cleared, so to support re-inserting the KVM module
we must clear these bits when unloading the module.

This is going to change in two ways:

First, the init id-map code is going to go away in favor of
section-based id-mapping.

Second, we are not going to use the SMC call in the future, but rather
an HVC instruction to take control of Hyp mode.  We need, however, a
method to setup the original init code again to support module
unloading.  It is useful to add this support at this point since we will (a)
remember to support unloading and (b) benefit from shorter debug cycles.

Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
---
 arch/arm/include/asm/kvm_asm.h |    3 ++
 arch/arm/kvm/arm.c             |   50 ++++++++++++++++++++++++++++++++++++++++
 arch/arm/kvm/exports.c         |    3 ++
 arch/arm/kvm/init.S            |   28 ++++++++++++++++++++++
 4 files changed, 84 insertions(+)

diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index 69afdf3..c2ec131 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
 <at>  <at>  -37,6 +37,9  <at>  <at>  struct kvm_vcpu;
 extern char __kvm_hyp_init[];
 extern char __kvm_hyp_init_end[];

(Continue reading)

headers

Christoffer Dall | 15 Jun 2012 21:08

[PATCH v8 10/15] ARM: KVM: Inject IRQs and FIQs from userspace

From: Christoffer Dall <cdall <at> cs.columbia.edu>

Userspace can inject IRQs and FIQs through the KVM_IRQ_LINE VM ioctl.
This ioctl is used since the sematics are in fact two lines that can be
either raised or lowered on the VCPU - the IRQ and FIQ lines.

KVM needs to know which VCPU it must operate on and whether the FIQ or
IRQ line is raised/lowered. Hence both pieces of information is packed
in the kvm_irq_level->irq field. The irq fild value will be:
  IRQ: vcpu_index << 1
  FIQ: (vcpu_index << 1) | 1

This is documented in Documentation/kvm/api.txt.

The effect of the ioctl is simply to simply raise/lower the
corresponding irq_line field on the VCPU struct, which will cause the
world-switch code to raise/lower virtual interrupts when running the
guest on next switch. The wait_for_interrupt flag is also cleared for
raised IRQs or FIQs causing an idle VCPU to become active again. CPUs
in guest mode are kicked to make sure they refresh their interrupt status.

Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
---
 Documentation/virtual/kvm/api.txt |   12 +++++--
 arch/arm/include/asm/kvm.h        |    9 +++++
 arch/arm/include/asm/kvm_arm.h    |    1 +
 arch/arm/kvm/arm.c                |   62 ++++++++++++++++++++++++++++++++++++-
 include/linux/kvm.h               |    1 +
 5 files changed, 80 insertions(+), 5 deletions(-)

(Continue reading)

headers

Avi Kivity | 18 Jun 2012 15:32

Re: [PATCH v8 10/15] ARM: KVM: Inject IRQs and FIQs from userspace

On 06/15/2012 10:08 PM, Christoffer Dall wrote:
> From: Christoffer Dall <cdall <at> cs.columbia.edu>
> 
> Userspace can inject IRQs and FIQs through the KVM_IRQ_LINE VM ioctl.
> This ioctl is used since the sematics are in fact two lines that can be
> either raised or lowered on the VCPU - the IRQ and FIQ lines.
> 
> KVM needs to know which VCPU it must operate on and whether the FIQ or
> IRQ line is raised/lowered. Hence both pieces of information is packed
> in the kvm_irq_level->irq field. The irq fild value will be:
>   IRQ: vcpu_index << 1
>   FIQ: (vcpu_index << 1) | 1
> 
> This is documented in Documentation/kvm/api.txt.
> 
> The effect of the ioctl is simply to simply raise/lower the
> corresponding irq_line field on the VCPU struct, which will cause the
> world-switch code to raise/lower virtual interrupts when running the
> guest on next switch. The wait_for_interrupt flag is also cleared for
> raised IRQs or FIQs causing an idle VCPU to become active again. CPUs
> in guest mode are kicked to make sure they refresh their interrupt status.

>  
> +static int kvm_arch_vm_ioctl_irq_line(struct kvm *kvm,
> +				      struct kvm_irq_level *irq_level)
> +{
> +	int mask;
> +	unsigned int vcpu_idx;
> +	struct kvm_vcpu *vcpu;
> +	unsigned long old, new, *ptr;

(Continue reading)

headers

Christoffer Dall | 18 Jun 2012 22:56

Re: [PATCH v8 10/15] ARM: KVM: Inject IRQs and FIQs from userspace

On Mon, Jun 18, 2012 at 9:32 AM, Avi Kivity <avi <at> redhat.com> wrote:
> On 06/15/2012 10:08 PM, Christoffer Dall wrote:
>> From: Christoffer Dall <cdall <at> cs.columbia.edu>
>>
>> Userspace can inject IRQs and FIQs through the KVM_IRQ_LINE VM ioctl.
>> This ioctl is used since the sematics are in fact two lines that can be
>> either raised or lowered on the VCPU - the IRQ and FIQ lines.
>>
>> KVM needs to know which VCPU it must operate on and whether the FIQ or
>> IRQ line is raised/lowered. Hence both pieces of information is packed
>> in the kvm_irq_level->irq field. The irq fild value will be:
>>   IRQ: vcpu_index << 1
>>   FIQ: (vcpu_index << 1) | 1
>>
>> This is documented in Documentation/kvm/api.txt.
>>
>> The effect of the ioctl is simply to simply raise/lower the
>> corresponding irq_line field on the VCPU struct, which will cause the
>> world-switch code to raise/lower virtual interrupts when running the
>> guest on next switch. The wait_for_interrupt flag is also cleared for
>> raised IRQs or FIQs causing an idle VCPU to become active again. CPUs
>> in guest mode are kicked to make sure they refresh their interrupt status.
>
>>
>> +static int kvm_arch_vm_ioctl_irq_line(struct kvm *kvm,
>> +                                   struct kvm_irq_level *irq_level)
>> +{
>> +     int mask;
>> +     unsigned int vcpu_idx;
>> +     struct kvm_vcpu *vcpu;

(Continue reading)

headers

Avi Kivity | 19 Jun 2012 10:49

Re: [PATCH v8 10/15] ARM: KVM: Inject IRQs and FIQs from userspace

On 06/18/2012 11:56 PM, Christoffer Dall wrote:
> On Mon, Jun 18, 2012 at 9:32 AM, Avi Kivity <avi <at> redhat.com> wrote:
>> On 06/15/2012 10:08 PM, Christoffer Dall wrote:
>>> From: Christoffer Dall <cdall <at> cs.columbia.edu>
>>>
>>> Userspace can inject IRQs and FIQs through the KVM_IRQ_LINE VM ioctl.
>>> This ioctl is used since the sematics are in fact two lines that can be
>>> either raised or lowered on the VCPU - the IRQ and FIQ lines.
>>>
>>> KVM needs to know which VCPU it must operate on and whether the FIQ or
>>> IRQ line is raised/lowered. Hence both pieces of information is packed
>>> in the kvm_irq_level->irq field. The irq fild value will be:
>>>   IRQ: vcpu_index << 1
>>>   FIQ: (vcpu_index << 1) | 1
>>>
>>> This is documented in Documentation/kvm/api.txt.
>>>
>>> The effect of the ioctl is simply to simply raise/lower the
>>> corresponding irq_line field on the VCPU struct, which will cause the
>>> world-switch code to raise/lower virtual interrupts when running the
>>> guest on next switch. The wait_for_interrupt flag is also cleared for
>>> raised IRQs or FIQs causing an idle VCPU to become active again. CPUs
>>> in guest mode are kicked to make sure they refresh their interrupt status.
>>
>>>
>>> +static int kvm_arch_vm_ioctl_irq_line(struct kvm *kvm,
>>> +                                   struct kvm_irq_level *irq_level)
>>> +{
>>> +     int mask;
>>> +     unsigned int vcpu_idx;

(Continue reading)

headers

Christoffer Dall | 20 Jun 2012 05:17

Re: [PATCH v8 10/15] ARM: KVM: Inject IRQs and FIQs from userspace

On Tue, Jun 19, 2012 at 4:49 AM, Avi Kivity <avi <at> redhat.com> wrote:
> On 06/18/2012 11:56 PM, Christoffer Dall wrote:
>> On Mon, Jun 18, 2012 at 9:32 AM, Avi Kivity <avi <at> redhat.com> wrote:
>>> On 06/15/2012 10:08 PM, Christoffer Dall wrote:
>>>> From: Christoffer Dall <cdall <at> cs.columbia.edu>
>>>>
>>>> Userspace can inject IRQs and FIQs through the KVM_IRQ_LINE VM ioctl.
>>>> This ioctl is used since the sematics are in fact two lines that can be
>>>> either raised or lowered on the VCPU - the IRQ and FIQ lines.
>>>>
>>>> KVM needs to know which VCPU it must operate on and whether the FIQ or
>>>> IRQ line is raised/lowered. Hence both pieces of information is packed
>>>> in the kvm_irq_level->irq field. The irq fild value will be:
>>>>   IRQ: vcpu_index << 1
>>>>   FIQ: (vcpu_index << 1) | 1
>>>>
>>>> This is documented in Documentation/kvm/api.txt.
>>>>
>>>> The effect of the ioctl is simply to simply raise/lower the
>>>> corresponding irq_line field on the VCPU struct, which will cause the
>>>> world-switch code to raise/lower virtual interrupts when running the
>>>> guest on next switch. The wait_for_interrupt flag is also cleared for
>>>> raised IRQs or FIQs causing an idle VCPU to become active again. CPUs
>>>> in guest mode are kicked to make sure they refresh their interrupt status.
>>>
>>>>
>>>> +static int kvm_arch_vm_ioctl_irq_line(struct kvm *kvm,
>>>> +                                   struct kvm_irq_level *irq_level)
>>>> +{
>>>> +     int mask;

(Continue reading)

headers

Christoffer Dall | 15 Jun 2012 21:07

[PATCH v8 07/15] ARM: KVM: Hypervisor inititalization

Sets up the required registers to run code in HYP-mode from the kernel.

By setting the HVBAR the kernel can execute code in Hyp-mode with
the MMU disabled. The HVBAR initially points to initialization code,
which initializes other Hyp-mode registers and enables the MMU
for Hyp-mode. Afterwards, the HVBAR is changed to point to KVM
Hyp vectors used to catch guest faults and to switch to Hyp mode
to perform a world-switch into a KVM guest.

Also provides memory mapping code to map required code pages and data
structures accessed in Hyp mode at the same virtual address as the
host kernel virtual addresses, but which conforms to the architectural
requirements for translations in Hyp mode. This interface is added in
arch/arm/kvm/arm_mmu.c and is comprised of:
 - create_hyp_mappings(hyp_pgd, start, end);
 - free_hyp_pmds(pgd_hyp);

Note: The initialization mechanism currently relies on an SMC #0 call
to the secure monitor, which was merely a fast way of getting to the
hypervisor. Dave Marting and Rusty Russel have patches out to make the
boot-wrapper and the kernel boot in Hyp-mode and setup a generic way for
hypervisors to get access to Hyp-mode if the boot-loader allows such
access.

Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
---
 arch/arm/include/asm/kvm_arm.h              |  117 +++++++++++++++++++
 arch/arm/include/asm/kvm_asm.h              |   22 +++
 arch/arm/include/asm/kvm_mmu.h              |   37 ++++++
 arch/arm/include/asm/pgtable-3level-hwdef.h |    4 +

(Continue reading)

headers

Marcelo Tosatti | 29 Jun 2012 00:35

Re: [PATCH v8 07/15] ARM: KVM: Hypervisor inititalization

On Fri, Jun 15, 2012 at 03:07:59PM -0400, Christoffer Dall wrote:
> Sets up the required registers to run code in HYP-mode from the kernel.
> 
> By setting the HVBAR the kernel can execute code in Hyp-mode with
> the MMU disabled. The HVBAR initially points to initialization code,
> which initializes other Hyp-mode registers and enables the MMU
> for Hyp-mode. Afterwards, the HVBAR is changed to point to KVM
> Hyp vectors used to catch guest faults and to switch to Hyp mode
> to perform a world-switch into a KVM guest.
> 
> Also provides memory mapping code to map required code pages and data
> structures accessed in Hyp mode at the same virtual address as the
> host kernel virtual addresses, but which conforms to the architectural
> requirements for translations in Hyp mode. This interface is added in
> arch/arm/kvm/arm_mmu.c and is comprised of:
>  - create_hyp_mappings(hyp_pgd, start, end);
>  - free_hyp_pmds(pgd_hyp);
> 
> Note: The initialization mechanism currently relies on an SMC #0 call
> to the secure monitor, which was merely a fast way of getting to the
> hypervisor. Dave Marting and Rusty Russel have patches out to make the
> boot-wrapper and the kernel boot in Hyp-mode and setup a generic way for
> hypervisors to get access to Hyp-mode if the boot-loader allows such
> access.
> 
> Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
> ---
>  arch/arm/include/asm/kvm_arm.h              |  117 +++++++++++++++++++
>  arch/arm/include/asm/kvm_asm.h              |   22 +++
>  arch/arm/include/asm/kvm_mmu.h              |   37 ++++++

(Continue reading)

headers

Christoffer Dall | 29 Jun 2012 00:53

Re: [PATCH v8 07/15] ARM: KVM: Hypervisor inititalization

On Thu, Jun 28, 2012 at 6:35 PM, Marcelo Tosatti <mtosatti <at> redhat.com> wrote:
> On Fri, Jun 15, 2012 at 03:07:59PM -0400, Christoffer Dall wrote:
>> Sets up the required registers to run code in HYP-mode from the kernel.
>>
>> By setting the HVBAR the kernel can execute code in Hyp-mode with
>> the MMU disabled. The HVBAR initially points to initialization code,
>> which initializes other Hyp-mode registers and enables the MMU
>> for Hyp-mode. Afterwards, the HVBAR is changed to point to KVM
>> Hyp vectors used to catch guest faults and to switch to Hyp mode
>> to perform a world-switch into a KVM guest.
>>
>> Also provides memory mapping code to map required code pages and data
>> structures accessed in Hyp mode at the same virtual address as the
>> host kernel virtual addresses, but which conforms to the architectural
>> requirements for translations in Hyp mode. This interface is added in
>> arch/arm/kvm/arm_mmu.c and is comprised of:
>>  - create_hyp_mappings(hyp_pgd, start, end);
>>  - free_hyp_pmds(pgd_hyp);
>>
>> Note: The initialization mechanism currently relies on an SMC #0 call
>> to the secure monitor, which was merely a fast way of getting to the
>> hypervisor. Dave Marting and Rusty Russel have patches out to make the
>> boot-wrapper and the kernel boot in Hyp-mode and setup a generic way for
>> hypervisors to get access to Hyp-mode if the boot-loader allows such
>> access.
>>
>> Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
>> ---
>>  arch/arm/include/asm/kvm_arm.h              |  117 +++++++++++++++++++
>>  arch/arm/include/asm/kvm_asm.h              |   22 +++

(Continue reading)

headers

Marcelo Tosatti | 29 Jun 2012 03:07

Re: [PATCH v8 07/15] ARM: KVM: Hypervisor inititalization

On Thu, Jun 28, 2012 at 06:53:43PM -0400, Christoffer Dall wrote:
> > should assign per_cpu(kvm_arm_hyp_stack_page, cpu) to NULL.
> >
> 
> why? this is run as part of the init code and thus the only way it
> could ever run again would be to have the module unloaded in which
> case the variable would be re-initialized to zero as per the static
> declaration, no?

Right.

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Christoffer Dall | 15 Jun 2012 21:08

[PATCH v8 09/15] ARM: KVM: Memory virtualization setup

From: Christoffer Dall <cdall <at> cs.columbia.edu>

This commit introduces the framework for guest memory management
through the use of 2nd stage translation. Each VM has a pointer
to a level-1 table (the pgd field in struct kvm_arch) which is
used for the 2nd stage translations. Entries are added when handling
guest faults (later patch) and the table itself can be allocated and
freed through the following functions implemented in
arch/arm/kvm/arm_mmu.c:
 - kvm_alloc_stage2_pgd(struct kvm *kvm);
 - kvm_free_stage2_pgd(struct kvm *kvm);

Further, each entry in TLBs and caches are tagged with a VMID
identifier in addition to ASIDs. The VMIDs are assigned consecutively
to VMs in the order that VMs are executed, and caches and tlbs are
invalidated when the VMID space has been used to allow for more than
255 simultaenously running guests.

The 2nd stage pgd is allocated in kvm_arch_init_vm(). The table is
freed in kvm_arch_destroy_vm(). Both functions are called from the main
KVM code.

Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
---
 arch/arm/include/asm/kvm_arm.h |    2 -
 arch/arm/include/asm/kvm_mmu.h |    5 ++
 arch/arm/kvm/arm.c             |   65 ++++++++++++++++++++++---
 arch/arm/kvm/mmu.c             |  103 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 166 insertions(+), 9 deletions(-)

(Continue reading)

headers

Gleb Natapov | 21 Jun 2012 14:29

Re: [PATCH v8 09/15] ARM: KVM: Memory virtualization setup

On Fri, Jun 15, 2012 at 03:08:22PM -0400, Christoffer Dall wrote:
> From: Christoffer Dall <cdall <at> cs.columbia.edu>
> 
> This commit introduces the framework for guest memory management
> through the use of 2nd stage translation. Each VM has a pointer
> to a level-1 table (the pgd field in struct kvm_arch) which is
> used for the 2nd stage translations. Entries are added when handling
> guest faults (later patch) and the table itself can be allocated and
> freed through the following functions implemented in
> arch/arm/kvm/arm_mmu.c:
>  - kvm_alloc_stage2_pgd(struct kvm *kvm);
>  - kvm_free_stage2_pgd(struct kvm *kvm);
> 
> Further, each entry in TLBs and caches are tagged with a VMID
> identifier in addition to ASIDs. The VMIDs are assigned consecutively
> to VMs in the order that VMs are executed, and caches and tlbs are
> invalidated when the VMID space has been used to allow for more than
> 255 simultaenously running guests.
> 
> The 2nd stage pgd is allocated in kvm_arch_init_vm(). The table is
> freed in kvm_arch_destroy_vm(). Both functions are called from the main
> KVM code.
> 
> Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
> ---
>  arch/arm/include/asm/kvm_arm.h |    2 -
>  arch/arm/include/asm/kvm_mmu.h |    5 ++
>  arch/arm/kvm/arm.c             |   65 ++++++++++++++++++++++---
>  arch/arm/kvm/mmu.c             |  103 ++++++++++++++++++++++++++++++++++++++++
>  4 files changed, 166 insertions(+), 9 deletions(-)

(Continue reading)

headers

Christoffer Dall | 21 Jun 2012 21:48

Re: [PATCH v8 09/15] ARM: KVM: Memory virtualization setup

On Thu, Jun 21, 2012 at 8:29 AM, Gleb Natapov <gleb <at> redhat.com> wrote:
> On Fri, Jun 15, 2012 at 03:08:22PM -0400, Christoffer Dall wrote:
>> From: Christoffer Dall <cdall <at> cs.columbia.edu>
>>
>> This commit introduces the framework for guest memory management
>> through the use of 2nd stage translation. Each VM has a pointer
>> to a level-1 table (the pgd field in struct kvm_arch) which is
>> used for the 2nd stage translations. Entries are added when handling
>> guest faults (later patch) and the table itself can be allocated and
>> freed through the following functions implemented in
>> arch/arm/kvm/arm_mmu.c:
>>  - kvm_alloc_stage2_pgd(struct kvm *kvm);
>>  - kvm_free_stage2_pgd(struct kvm *kvm);
>>
>> Further, each entry in TLBs and caches are tagged with a VMID
>> identifier in addition to ASIDs. The VMIDs are assigned consecutively
>> to VMs in the order that VMs are executed, and caches and tlbs are
>> invalidated when the VMID space has been used to allow for more than
>> 255 simultaenously running guests.
>>
>> The 2nd stage pgd is allocated in kvm_arch_init_vm(). The table is
>> freed in kvm_arch_destroy_vm(). Both functions are called from the main
>> KVM code.
>>
>> Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
>> ---
>>  arch/arm/include/asm/kvm_arm.h |    2 -
>>  arch/arm/include/asm/kvm_mmu.h |    5 ++
>>  arch/arm/kvm/arm.c             |   65 ++++++++++++++++++++++---
>>  arch/arm/kvm/mmu.c             |  103 ++++++++++++++++++++++++++++++++++++++++

(Continue reading)

headers

Marcelo Tosatti | 29 Jun 2012 00:34

Re: [PATCH v8 09/15] ARM: KVM: Memory virtualization setup

On Fri, Jun 15, 2012 at 03:08:22PM -0400, Christoffer Dall wrote:
> From: Christoffer Dall <cdall <at> cs.columbia.edu>
> 
> This commit introduces the framework for guest memory management
> through the use of 2nd stage translation. Each VM has a pointer
> to a level-1 table (the pgd field in struct kvm_arch) which is
> used for the 2nd stage translations. Entries are added when handling
> guest faults (later patch) and the table itself can be allocated and
> freed through the following functions implemented in
> arch/arm/kvm/arm_mmu.c:
>  - kvm_alloc_stage2_pgd(struct kvm *kvm);
>  - kvm_free_stage2_pgd(struct kvm *kvm);
> 
> Further, each entry in TLBs and caches are tagged with a VMID
> identifier in addition to ASIDs. The VMIDs are assigned consecutively
> to VMs in the order that VMs are executed, and caches and tlbs are
> invalidated when the VMID space has been used to allow for more than
> 255 simultaenously running guests.
> 
> The 2nd stage pgd is allocated in kvm_arch_init_vm(). The table is
> freed in kvm_arch_destroy_vm(). Both functions are called from the main
> KVM code.
> 
> Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>

Can you explain on a high level how the IPA -> PA mappings work? 

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org

(Continue reading)

headers

Christoffer Dall | 29 Jun 2012 00:51

Re: [PATCH v8 09/15] ARM: KVM: Memory virtualization setup

On Thu, Jun 28, 2012 at 6:34 PM, Marcelo Tosatti <mtosatti <at> redhat.com> wrote:
> On Fri, Jun 15, 2012 at 03:08:22PM -0400, Christoffer Dall wrote:
>> From: Christoffer Dall <cdall <at> cs.columbia.edu>
>>
>> This commit introduces the framework for guest memory management
>> through the use of 2nd stage translation. Each VM has a pointer
>> to a level-1 table (the pgd field in struct kvm_arch) which is
>> used for the 2nd stage translations. Entries are added when handling
>> guest faults (later patch) and the table itself can be allocated and
>> freed through the following functions implemented in
>> arch/arm/kvm/arm_mmu.c:
>>  - kvm_alloc_stage2_pgd(struct kvm *kvm);
>>  - kvm_free_stage2_pgd(struct kvm *kvm);
>>
>> Further, each entry in TLBs and caches are tagged with a VMID
>> identifier in addition to ASIDs. The VMIDs are assigned consecutively
>> to VMs in the order that VMs are executed, and caches and tlbs are
>> invalidated when the VMID space has been used to allow for more than
>> 255 simultaenously running guests.
>>
>> The 2nd stage pgd is allocated in kvm_arch_init_vm(). The table is
>> freed in kvm_arch_destroy_vm(). Both functions are called from the main
>> KVM code.
>>
>> Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
>
> Can you explain on a high level how the IPA -> PA mappings work?
>

the memory system on ARM with Virtualization Extensions is separated

(Continue reading)

headers

Christoffer Dall | 15 Jun 2012 21:07

[PATCH v8 02/15] KVM: use KVM_CAP_IRQ_ROUTING to protect the routing related code

From: Marc Zyngier <marc.zyngier <at> arm.com>

The KVM code sometimes uses CONFIG_HAVE_KVM_IRQCHIP to protect
code that is related to IRQ routing, which not all in-kernel
irqchips may support.

Use KVM_CAP_IRQ_ROUTING instead.

Signed-off-by: Marc Zyngier <marc.zyngier <at> arm.com>
Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
---
 include/linux/kvm_host.h |    2 +-
 virt/kvm/kvm_main.c      |    2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 27ac8a4..c7f7787 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
 <at>  <at>  -802,7 +802,7  <at>  <at>  static inline int mmu_notifier_retry(struct kvm_vcpu *vcpu, unsigned long mmu_se
 }
 #endif

-#ifdef CONFIG_HAVE_KVM_IRQCHIP
+#ifdef KVM_CAP_IRQ_ROUTING

 #define KVM_MAX_IRQ_ROUTES 1024

diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index 02cb440..636bd08 100644

(Continue reading)

headers

Avi Kivity | 18 Jun 2012 15:06

Re: [PATCH v8 02/15] KVM: use KVM_CAP_IRQ_ROUTING to protect the routing related code

On 06/15/2012 10:07 PM, Christoffer Dall wrote:
> From: Marc Zyngier <marc.zyngier <at> arm.com>
> 
> The KVM code sometimes uses CONFIG_HAVE_KVM_IRQCHIP to protect
> code that is related to IRQ routing, which not all in-kernel
> irqchips may support.
> 
> Use KVM_CAP_IRQ_ROUTING instead.

Thanks, applied.

--

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Christoffer Dall | 15 Jun 2012 21:06

[PATCH v8 01/15] ARM: add mem_type prot_pte accessor

From: Marc Zyngier <marc.zyngier <at> arm.com>

The KVM hypervisor mmu code requires requires access to the
mem_type prot_pte field when setting up page tables pointing
to a device. Unfortunately, the mem_type structure is opaque.

Add an accessor (get_mem_type_prot_pte()) to retrieve the
prot_pte value.

Signed-off-by: Marc Zyngier <marc.zyngier <at> arm.com>
Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
---
 arch/arm/include/asm/mach/map.h |    1 +
 arch/arm/mm/mmu.c               |    6 ++++++
 2 files changed, 7 insertions(+)

diff --git a/arch/arm/include/asm/mach/map.h b/arch/arm/include/asm/mach/map.h
index a6efcdd..3787c9f 100644
--- a/arch/arm/include/asm/mach/map.h
+++ b/arch/arm/include/asm/mach/map.h
 <at>  <at>  -37,6 +37,7  <at>  <at>  extern void iotable_init(struct map_desc *, int);

 struct mem_type;
 extern const struct mem_type *get_mem_type(unsigned int type);
+extern pteval_t get_mem_type_prot_pte(unsigned int type);
 /*
  * external interface to remap single page with appropriate type
  */
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index e5dad60..f7439e7 100644

(Continue reading)

headers

Christoffer Dall | 15 Jun 2012 21:08

[PATCH v8 12/15] ARM: KVM: Emulation framework and CP15 emulation

From: Christoffer Dall <cdall <at> cs.columbia.edu>

Adds a new important function in the main KVM/ARM code called
handle_exit() which is called from kvm_arch_vcpu_ioctl_run() on returns
from guest execution. This function examines the Hyp-Syndrome-Register
(HSR), which contains information telling KVM what caused the exit from
the guest.

Some of the reasons for an exit are CP15 accesses, which are
not allowed from the guest and this commit handles these exits by
emulating the intended operation in software and skip the guest
instruction.

Signed-off-by: Rusty Russell <rusty <at> rustcorp.com.au>
Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
---
 arch/arm/include/asm/kvm_emulate.h |    9 +
 arch/arm/kvm/arm.c                 |   87 +++++++++
 arch/arm/kvm/emulate.c             |  330 ++++++++++++++++++++++++++++++++++++
 arch/arm/kvm/trace.h               |   28 +++
 4 files changed, 454 insertions(+)

diff --git a/arch/arm/include/asm/kvm_emulate.h b/arch/arm/include/asm/kvm_emulate.h
index 7ab696d..4b49168 100644
--- a/arch/arm/include/asm/kvm_emulate.h
+++ b/arch/arm/include/asm/kvm_emulate.h
 <at>  <at>  -40,6 +40,15  <at>  <at>  static inline enum vcpu_mode vcpu_mode(struct kvm_vcpu *vcpu)
 	return modes_table[vcpu->arch.regs.cpsr & 0xf];
 }

(Continue reading)

headers

Christoffer Dall | 15 Jun 2012 21:09

[PATCH v8 13/15] ARM: KVM: Handle guest faults in KVM

From: Christoffer Dall <cdall <at> cs.columbia.edu>

Handles the guest faults in KVM by mapping in corresponding user pages
in the 2nd stage page tables.

Introduces new ARM-specific kernel memory types, PAGE_KVM_GUEST and
pgprot_guest variables used to map 2nd stage memory for KVM guests.

Leverages MMU notifiers on KVM/ARM by supporting the kvm_unmap_hva() operation,
where we remove the HVA from the 2nd stage translation. All other KVM MMU
notifierhooks are NOPs.

Signed-off-by: Marc Zyngier <marc.zyngier <at> arm.com>
Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
---
 arch/arm/include/asm/kvm_asm.h        |    3 +
 arch/arm/include/asm/kvm_host.h       |   20 ++++
 arch/arm/include/asm/pgtable-3level.h |    8 ++
 arch/arm/include/asm/pgtable.h        |    4 +
 arch/arm/kvm/Kconfig                  |    1 
 arch/arm/kvm/exports.c                |    1 
 arch/arm/kvm/interrupts.S             |   37 +++++++
 arch/arm/kvm/mmu.c                    |  164 +++++++++++++++++++++++++++++++++
 arch/arm/mm/mmu.c                     |    3 +
 9 files changed, 240 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index c2ec131..c4f40f3 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h

(Continue reading)

headers

Avi Kivity | 18 Jun 2012 15:45

Re: [PATCH v8 13/15] ARM: KVM: Handle guest faults in KVM

On 06/15/2012 10:09 PM, Christoffer Dall wrote:
> From: Christoffer Dall <cdall <at> cs.columbia.edu>
> 
> Handles the guest faults in KVM by mapping in corresponding user pages
> in the 2nd stage page tables.
> 
> Introduces new ARM-specific kernel memory types, PAGE_KVM_GUEST and
> pgprot_guest variables used to map 2nd stage memory for KVM guests.
> 
> Leverages MMU notifiers on KVM/ARM by supporting the kvm_unmap_hva() operation,
> where we remove the HVA from the 2nd stage translation. All other KVM MMU
> notifierhooks are NOPs.

I think you must at least support change_pte (possibly by unmapping).
Andrea?

--

-- 
error compiling committee.c: too many arguments to function

--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Christoffer Dall | 19 Jun 2012 00:20

Re: [PATCH v8 13/15] ARM: KVM: Handle guest faults in KVM

On Mon, Jun 18, 2012 at 9:45 AM, Avi Kivity <avi <at> redhat.com> wrote:
> On 06/15/2012 10:09 PM, Christoffer Dall wrote:
>> From: Christoffer Dall <cdall <at> cs.columbia.edu>
>>
>> Handles the guest faults in KVM by mapping in corresponding user pages
>> in the 2nd stage page tables.
>>
>> Introduces new ARM-specific kernel memory types, PAGE_KVM_GUEST and
>> pgprot_guest variables used to map 2nd stage memory for KVM guests.
>>
>> Leverages MMU notifiers on KVM/ARM by supporting the kvm_unmap_hva() operation,
>> where we remove the HVA from the 2nd stage translation. All other KVM MMU
>> notifierhooks are NOPs.
>
> I think you must at least support change_pte (possibly by unmapping).
> Andrea?
>
hmmm, at least for KSM support we need to support change_pte (are
there other callers for this type of memory?)

It's not trivial I guess, since we would need to support COW and
thereby stage-2 permission faults... Marc, right?

-Christoffer
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

headers

Avi Kivity | 19 Jun 2012 11:32

Re: [PATCH v8 13/15] ARM: KVM: Handle guest faults in KVM

On 06/19/2012 01:20 AM, Christoffer Dall wrote:
> On Mon, Jun 18, 2012 at 9:45 AM, Avi Kivity <avi <at> redhat.com> wrote:
>> On 06/15/2012 10:09 PM, Christoffer Dall wrote:
>>> From: Christoffer Dall <cdall <at> cs.columbia.edu>
>>>
>>> Handles the guest faults in KVM by mapping in corresponding user pages
>>> in the 2nd stage page tables.
>>>
>>> Introduces new ARM-specific kernel memory types, PAGE_KVM_GUEST and
>>> pgprot_guest variables used to map 2nd stage memory for KVM guests.
>>>
>>> Leverages MMU notifiers on KVM/ARM by supporting the kvm_unmap_hva() operation,
>>> where we remove the HVA from the 2nd stage translation. All other KVM MMU
>>> notifierhooks are NOPs.
>>
>> I think you must at least support change_pte (possibly by unmapping).
>> Andrea?
>>
> hmmm, at least for KSM support we need to support change_pte (are
> there other callers for this type of memory?)
> 
> It's not trivial I guess, since we would need to support COW and
> thereby stage-2 permission faults... Marc, right?

As I mentioned, you can support change_pte by unmapping.  This will
cause ksm to be ineffective (pages will only be shared if the guest
doesn't touch them at all), but it's enough to get started.

--

-- 
error compiling committee.c: too many arguments to function

(Continue reading)

headers

Andrea Arcangeli | 19 Jun 2012 12:41

Re: [PATCH v8 13/15] ARM: KVM: Handle guest faults in KVM

On Tue, Jun 19, 2012 at 12:32:06PM +0300, Avi Kivity wrote:
> On 06/19/2012 01:20 AM, Christoffer Dall wrote:
> > On Mon, Jun 18, 2012 at 9:45 AM, Avi Kivity <avi <at> redhat.com> wrote:
> >> On 06/15/2012 10:09 PM, Christoffer Dall wrote:
> >>> From: Christoffer Dall <cdall <at> cs.columbia.edu>
> >>>
> >>> Handles the guest faults in KVM by mapping in corresponding user pages
> >>> in the 2nd stage page tables.
> >>>
> >>> Introduces new ARM-specific kernel memory types, PAGE_KVM_GUEST and
> >>> pgprot_guest variables used to map 2nd stage memory for KVM guests.
> >>>
> >>> Leverages MMU notifiers on KVM/ARM by supporting the kvm_unmap_hva() operation,
> >>> where we remove the HVA from the 2nd stage translation. All other KVM MMU
> >>> notifierhooks are NOPs.
> >>
> >> I think you must at least support change_pte (possibly by unmapping).
> >> Andrea?
> >>
> > hmmm, at least for KSM support we need to support change_pte (are
> > there other callers for this type of memory?)
> > 
> > It's not trivial I guess, since we would need to support COW and
> > thereby stage-2 permission faults... Marc, right?
> 
> As I mentioned, you can support change_pte by unmapping.  This will
> cause ksm to be ineffective (pages will only be shared if the guest
> doesn't touch them at all), but it's enough to get started.

The main reason change_pte initially was required for KSM to be

(Continue reading)

headers

Christoffer Dall | 20 Jun 2012 17:13

Re: [PATCH v8 13/15] ARM: KVM: Handle guest faults in KVM

On Tue, Jun 19, 2012 at 6:41 AM, Andrea Arcangeli <aarcange <at> redhat.com> wrote:
> On Tue, Jun 19, 2012 at 12:32:06PM +0300, Avi Kivity wrote:
>> On 06/19/2012 01:20 AM, Christoffer Dall wrote:
>> > On Mon, Jun 18, 2012 at 9:45 AM, Avi Kivity <avi <at> redhat.com> wrote:
>> >> On 06/15/2012 10:09 PM, Christoffer Dall wrote:
>> >>> From: Christoffer Dall <cdall <at> cs.columbia.edu>
>> >>>
>> >>> Handles the guest faults in KVM by mapping in corresponding user pages
>> >>> in the 2nd stage page tables.
>> >>>
>> >>> Introduces new ARM-specific kernel memory types, PAGE_KVM_GUEST and
>> >>> pgprot_guest variables used to map 2nd stage memory for KVM guests.
>> >>>
>> >>> Leverages MMU notifiers on KVM/ARM by supporting the kvm_unmap_hva() operation,
>> >>> where we remove the HVA from the 2nd stage translation. All other KVM MMU
>> >>> notifierhooks are NOPs.
>> >>
>> >> I think you must at least support change_pte (possibly by unmapping).
>> >> Andrea?
>> >>
>> > hmmm, at least for KSM support we need to support change_pte (are
>> > there other callers for this type of memory?)
>> >
>> > It's not trivial I guess, since we would need to support COW and
>> > thereby stage-2 permission faults... Marc, right?
>>
>> As I mentioned, you can support change_pte by unmapping.  This will
>> cause ksm to be ineffective (pages will only be shared if the guest
>> doesn't touch them at all), but it's enough to get started.
>

(Continue reading)

headers

Andrea Arcangeli | 20 Jun 2012 19:49

Re: [PATCH v8 13/15] ARM: KVM: Handle guest faults in KVM

On Wed, Jun 20, 2012 at 11:13:36AM -0400, Christoffer Dall wrote:
> ah, we don't do things right, we use gfn_to_pfn() flat out and will
> always break the COW :)
> 
> I guess now, when change_pte is a nop, it's outright incorrect if
> anyone runs KSM.
> 
> This has just been added to my todo-list.

Great.

Either implement change_pte, or use gfn_to_pfn_async(write_fault=0)
for read faults.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

headers

Christoffer Dall | 15 Jun 2012 21:08

[PATCH v8 11/15] ARM: KVM: World-switch implementation

Provides complete world-switch implementation to switch to other guests
running in non-secure modes. Includes Hyp exception handlers that
capture necessary exception information and stores the information on
the VCPU and KVM structures.

Switching to Hyp mode is done through a simple HVC instructions. The
exception vector code will check that the HVC comes from VMID==0 and if
so will store the necessary state on the Hyp stack, which will look like
this (growing downwards, see the hyp_hvc handler):
  ...
  Hyp_Sp + 4: spsr (Host-SVC cpsr)
  Hyp_Sp    : lr_usr

When returning from Hyp mode to SVC mode, another HVC instruction is
executed from Hyp mode, which is taken in the Hyp_Svc handler. The Hyp
stack pointer should be where it was left from the above initial call,
since the values on the stack will be used to restore state (see
hyp_svc).

Otherwise, the world-switch is pretty straight-forward. All state that
can be modified by the guest is first backed up on the Hyp stack and the
VCPU values is loaded onto the hardware. State, which is not loaded, but
theoretically modifiable by the guest is protected through the
virtualiation features to generate a trap and cause software emulation.
Upon guest returns, all state is restored from hardware onto the VCPU
struct and the original state is restored from the Hyp-stack onto the
hardware.

One controversy may be the back-door call to __irq_svc (the host
kernel's own physical IRQ handler) which is called when a physical IRQ

(Continue reading)

headers

Avi Kivity | 18 Jun 2012 15:41

Re: [PATCH v8 11/15] ARM: KVM: World-switch implementation

On 06/15/2012 10:08 PM, Christoffer Dall wrote:
> Provides complete world-switch implementation to switch to other guests
> running in non-secure modes. Includes Hyp exception handlers that
> capture necessary exception information and stores the information on
> the VCPU and KVM structures.
> 
> Switching to Hyp mode is done through a simple HVC instructions. The
> exception vector code will check that the HVC comes from VMID==0 and if
> so will store the necessary state on the Hyp stack, which will look like
> this (growing downwards, see the hyp_hvc handler):
>   ...
>   Hyp_Sp + 4: spsr (Host-SVC cpsr)
>   Hyp_Sp    : lr_usr
> 
> When returning from Hyp mode to SVC mode, another HVC instruction is
> executed from Hyp mode, which is taken in the Hyp_Svc handler. The Hyp
> stack pointer should be where it was left from the above initial call,
> since the values on the stack will be used to restore state (see
> hyp_svc).
> 
> Otherwise, the world-switch is pretty straight-forward. All state that
> can be modified by the guest is first backed up on the Hyp stack and the
> VCPU values is loaded onto the hardware. State, which is not loaded, but
> theoretically modifiable by the guest is protected through the
> virtualiation features to generate a trap and cause software emulation.
> Upon guest returns, all state is restored from hardware onto the VCPU
> struct and the original state is restored from the Hyp-stack onto the
> hardware.
> 
> One controversy may be the back-door call to __irq_svc (the host

(Continue reading)

headers

Christoffer Dall | 19 Jun 2012 00:05

Re: [PATCH v8 11/15] ARM: KVM: World-switch implementation

On Mon, Jun 18, 2012 at 9:41 AM, Avi Kivity <avi <at> redhat.com> wrote:
> On 06/15/2012 10:08 PM, Christoffer Dall wrote:
>> Provides complete world-switch implementation to switch to other guests
>> running in non-secure modes. Includes Hyp exception handlers that
>> capture necessary exception information and stores the information on
>> the VCPU and KVM structures.
>>
>> Switching to Hyp mode is done through a simple HVC instructions. The
>> exception vector code will check that the HVC comes from VMID==0 and if
>> so will store the necessary state on the Hyp stack, which will look like
>> this (growing downwards, see the hyp_hvc handler):
>>   ...
>>   Hyp_Sp + 4: spsr (Host-SVC cpsr)
>>   Hyp_Sp    : lr_usr
>>
>> When returning from Hyp mode to SVC mode, another HVC instruction is
>> executed from Hyp mode, which is taken in the Hyp_Svc handler. The Hyp
>> stack pointer should be where it was left from the above initial call,
>> since the values on the stack will be used to restore state (see
>> hyp_svc).
>>
>> Otherwise, the world-switch is pretty straight-forward. All state that
>> can be modified by the guest is first backed up on the Hyp stack and the
>> VCPU values is loaded onto the hardware. State, which is not loaded, but
>> theoretically modifiable by the guest is protected through the
>> virtualiation features to generate a trap and cause software emulation.
>> Upon guest returns, all state is restored from hardware onto the VCPU
>> struct and the original state is restored from the Hyp-stack onto the
>> hardware.
>>

(Continue reading)

headers

Avi Kivity | 19 Jun 2012 11:16

Re: [PATCH v8 11/15] ARM: KVM: World-switch implementation

On 06/19/2012 01:05 AM, Christoffer Dall wrote:
>> Premature, but this is sad.  I suggest you split vmid generation from
>> next available vmid.  This allows you to make the generation counter
>> atomic so it may be read outside the lock.
>>
>> You can do
>>
>>    if (likely(kvm->arch.vmd_gen) == atomic_read(&kvm_vmid_gen)))
>>           return;
>>
>>    spin_lock(...
>>
> 
> I knew you were going to say something here :), please take a look at
> this and see if you agree:

It looks reasonable wrt locking.

> +
> +	/* First user of a new VMID generation? */
> +	if (unlikely(kvm_next_vmid == 0)) {
> +		atomic64_inc(&kvm_vmid_gen);
> +		kvm_next_vmid = 1;
> +
> +		/* This does nothing on UP */
> +		smp_call_function(reset_vm_context, NULL, 1);

Does this imply a memory barrier?  If not, smp_mb__after_atomic_inc().

> +

(Continue reading)

headers

Christoffer Dall | 20 Jun 2012 05:27

Re: [PATCH v8 11/15] ARM: KVM: World-switch implementation

On Tue, Jun 19, 2012 at 5:16 AM, Avi Kivity <avi <at> redhat.com> wrote:
> On 06/19/2012 01:05 AM, Christoffer Dall wrote:
>>> Premature, but this is sad.  I suggest you split vmid generation from
>>> next available vmid.  This allows you to make the generation counter
>>> atomic so it may be read outside the lock.
>>>
>>> You can do
>>>
>>>    if (likely(kvm->arch.vmd_gen) == atomic_read(&kvm_vmid_gen)))
>>>           return;
>>>
>>>    spin_lock(...
>>>
>>
>> I knew you were going to say something here :), please take a look at
>> this and see if you agree:
>
> It looks reasonable wrt locking.
>
>> +
>> +     /* First user of a new VMID generation? */
>> +     if (unlikely(kvm_next_vmid == 0)) {
>> +             atomic64_inc(&kvm_vmid_gen);
>> +             kvm_next_vmid = 1;
>> +
>> +             /* This does nothing on UP */
>> +             smp_call_function(reset_vm_context, NULL, 1);
>
> Does this imply a memory barrier?  If not, smp_mb__after_atomic_inc().
>

(Continue reading)

headers

Christoffer Dall | 20 Jun 2012 06:40

Re: [PATCH v8 11/15] ARM: KVM: World-switch implementation

On Tue, Jun 19, 2012 at 11:27 PM, Christoffer Dall
<c.dall <at> virtualopensystems.com> wrote:
> On Tue, Jun 19, 2012 at 5:16 AM, Avi Kivity <avi <at> redhat.com> wrote:
>> On 06/19/2012 01:05 AM, Christoffer Dall wrote:
>>>> Premature, but this is sad.  I suggest you split vmid generation from
>>>> next available vmid.  This allows you to make the generation counter
>>>> atomic so it may be read outside the lock.
>>>>
>>>> You can do
>>>>
>>>>    if (likely(kvm->arch.vmd_gen) == atomic_read(&kvm_vmid_gen)))
>>>>           return;
>>>>
>>>>    spin_lock(...
>>>>
>>>
>>> I knew you were going to say something here :), please take a look at
>>> this and see if you agree:
>>
>> It looks reasonable wrt locking.
>>
>>> +
>>> +     /* First user of a new VMID generation? */
>>> +     if (unlikely(kvm_next_vmid == 0)) {
>>> +             atomic64_inc(&kvm_vmid_gen);
>>> +             kvm_next_vmid = 1;
>>> +
>>> +             /* This does nothing on UP */
>>> +             smp_call_function(reset_vm_context, NULL, 1);
>>

(Continue reading)

headers

Avi Kivity | 21 Jun 2012 10:13

Re: [PATCH v8 11/15] ARM: KVM: World-switch implementation

On 06/20/2012 07:40 AM, Christoffer Dall wrote:
> 
>>>
>>> cpu0                       cpu1
>>> (vmid=0, gen=1)            (gen=0)
>>> -------------------------- ----------------------
>>> gen == global_gen, return
>>>
>>>                           gen != global_gen
>>>                           increment global_gen
>>>                           smp_call_function
>>> reset_vm_context
>>>                           vmid=0
>>>
>>> enter with vmid=0          enter with vmid=0
>>
>> I can't see how the scenario above can happen. First, no-one can run
>> with vmid 0 - it is reserved for the host. If we bump global_gen on
>> cpuN, then since we do smp_call_function(x, x, wait=1) we are now sure
>> that after this call, all cpus(N-1) potentially being inside a VM will
>> have exited, called reset_vm_context, but before they can re-enter
>> into the guest, they will call update_vttbr, and if their generation
>> counter differs from global_gen, they will try to grab that spinlock
>> and everything should happen in order.
>>
> 
> the whole vmid=0 confused me a bit. The point is since we moved the
> generation check outside the spin_lock we have to re-check, I see:

In fact I think the problem occured with the original code as well.  The

(Continue reading)

headers

Christoffer Dall | 21 Jun 2012 19:54

Re: [PATCH v8 11/15] ARM: KVM: World-switch implementation

On Thu, Jun 21, 2012 at 4:13 AM, Avi Kivity <avi <at> redhat.com> wrote:
> On 06/20/2012 07:40 AM, Christoffer Dall wrote:
>>
>>>>
>>>> cpu0                       cpu1
>>>> (vmid=0, gen=1)            (gen=0)
>>>> -------------------------- ----------------------
>>>> gen == global_gen, return
>>>>
>>>>                           gen != global_gen
>>>>                           increment global_gen
>>>>                           smp_call_function
>>>> reset_vm_context
>>>>                           vmid=0
>>>>
>>>> enter with vmid=0          enter with vmid=0
>>>
>>> I can't see how the scenario above can happen. First, no-one can run
>>> with vmid 0 - it is reserved for the host. If we bump global_gen on
>>> cpuN, then since we do smp_call_function(x, x, wait=1) we are now sure
>>> that after this call, all cpus(N-1) potentially being inside a VM will
>>> have exited, called reset_vm_context, but before they can re-enter
>>> into the guest, they will call update_vttbr, and if their generation
>>> counter differs from global_gen, they will try to grab that spinlock
>>> and everything should happen in order.
>>>
>>
>> the whole vmid=0 confused me a bit. The point is since we moved the
>> generation check outside the spin_lock we have to re-check, I see:
>

(Continue reading)

headers

Avi Kivity | 2 Jul 2012 15:07

Re: [PATCH v8 11/15] ARM: KVM: World-switch implementation

On 06/21/2012 08:54 PM, Christoffer Dall wrote:
>>>  <at>  <at>  -504,6 +514,13  <at>  <at>  int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu
>>> *vcpu, struct kvm_run *run)
>>>                */
>>>               preempt_disable();
>>>               local_irq_disable();
>>> +
>>> +             if (check_new_vmid_gen(kvm)) {
>>> +                     local_irq_enable();
>>> +                     preempt_enable();
>>> +                     continue;
>>> +             }
>>> +
>>
>> I see the same race with signals.  Your signal_pending() check needs to
>> be after the local_irq_disable(), otherwise we can enter a guest with a
>> pending signal.
>>
> 
> that's not functionally incorrect though is it? It may simply increase
> the latency for the signal delivery as far as I can see, but I
> definitely don't mind changing this path in any case.

Nothing guarantees that there will be a next exit.  I think we still run
the timer tick on guest entry, so we'll exit after a few milliseconds,
but there are patches to disable the timer tick if only one task is queued.

--

-- 
error compiling committee.c: too many arguments to function

(Continue reading)

headers

Christoffer Dall | 15 Jun 2012 21:09

[PATCH v8 15/15] ARM: KVM: Guest wait-for-interrupts (WFI) support

From: Christoffer Dall <cdall <at> cs.columbia.edu>

When the guest executes a WFI instruction the operation is trapped to
KVM, which emulates the instruction in software. There is no correlation
between a guest executing a WFI instruction and actually putting the
hardware into a low-power mode, since a KVM guest is essentially a
process and the WFI instruction can be seen as 'sleep' call from this
process. Therefore, we flag the VCPU to be in wait_for_interrupts mode
and call the main KVM function kvm_vcpu_block() function. This function
will put the thread on a wait-queue and call schedule.

When an interrupt comes in through KVM_IRQ_LINE (see previous patch) we
signal the VCPU thread and unflag the VCPU to no longer wait for
interrupts. All calls to kvm_arch_vcpu_ioctl_run() result in a call to
kvm_vcpu_block() as long as the VCPU is in wfi-mode.

Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
---
 arch/arm/kvm/arm.c     |   15 ++++++++++++++-
 arch/arm/kvm/emulate.c |   12 ++++++++++++
 arch/arm/kvm/trace.h   |   16 ++++++++++++++++
 3 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index eedf171..e4b659b 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
 <at>  <at>  -291,9 +291,17  <at>  <at>  int kvm_arch_vcpu_ioctl_set_mpstate(struct kvm_vcpu *vcpu,
 	return -EINVAL;
 }

(Continue reading)

headers

Christoffer Dall | 15 Jun 2012 21:09

[PATCH v8 14/15] ARM: KVM: Handle I/O aborts

When the guest accesses I/O memory this will create data abort
exceptions and they are handled by decoding the HSR information
(physical address, read/write, length, register) and forwarding reads
and writes to QEMU which performs the device emulation.

Certain classes of load/store operations do not support the syndrome
information provided in the HSR and we therefore must be able to fetch
the offending instruction from guest memory and decode it manually.

This requires changing the general flow somewhat since new calls to run
the VCPU must check if there's a pending MMIO load and perform the write
after userspace has made the data available.

Signed-off-by: Christoffer Dall <c.dall <at> virtualopensystems.com>
---
 arch/arm/include/asm/kvm_emulate.h |    2 
 arch/arm/include/asm/kvm_host.h    |    1 
 arch/arm/include/asm/kvm_mmu.h     |    1 
 arch/arm/kvm/arm.c                 |    6 +
 arch/arm/kvm/emulate.c             |  282 ++++++++++++++++++++++++++++++++++++
 arch/arm/kvm/mmu.c                 |  162 ++++++++++++++++++++-
 arch/arm/kvm/trace.h               |   21 +++
 7 files changed, 472 insertions(+), 3 deletions(-)

diff --git a/arch/arm/include/asm/kvm_emulate.h b/arch/arm/include/asm/kvm_emulate.h
index 4b49168..1f93e71 100644
--- a/arch/arm/include/asm/kvm_emulate.h
+++ b/arch/arm/include/asm/kvm_emulate.h
 <at>  <at>  -47,6 +47,8  <at>  <at>  int kvm_handle_cp14_access(struct kvm_vcpu *vcpu, struct kvm_run *run);
 int kvm_handle_cp15_32(struct kvm_vcpu *vcpu, struct kvm_run *run);

(Continue reading)

headers

Avi Kivity | 18 Jun 2012 15:48

Re: [PATCH v8 14/15] ARM: KVM: Handle I/O aborts

On 06/15/2012 10:09 PM, Christoffer Dall wrote:
> When the guest accesses I/O memory this will create data abort
> exceptions and they are handled by decoding the HSR information
> (physical address, read/write, length, register) and forwarding reads
> and writes to QEMU which performs the device emulation.
> 
> Certain classes of load/store operations do not support the syndrome
> information provided in the HSR and we therefore must be able to fetch
> the offending instruction from guest memory and decode it manually.
> 
> This requires changing the general flow somewhat since new calls to run
> the VCPU must check if there's a pending MMIO load and perform the write
> after userspace has made the data available.
> 
>  
>  	memslot = gfn_to_memslot(vcpu->kvm, gfn);
> diff --git a/arch/arm/kvm/trace.h b/arch/arm/kvm/trace.h
> index e474a0a..bd3a6cc 100644
> --- a/arch/arm/kvm/trace.h
> +++ b/arch/arm/kvm/trace.h
>  <at>  <at>  -39,6 +39,27  <at>  <at>  TRACE_EVENT(kvm_exit,
>  	TP_printk("PC: 0x%08lx", __entry->vcpu_pc)
>  );
>  
> +TRACE_EVENT(kvm_mmio_emulate,
> +	TP_PROTO(unsigned long vcpu_pc, unsigned long instr,
> +		 unsigned long cpsr),
> +	TP_ARGS(vcpu_pc, instr, cpsr),
> +
> +	TP_STRUCT__entry(

(Continue reading)

headers

Christoffer Dall | 19 Jun 2012 00:28

Re: [PATCH v8 14/15] ARM: KVM: Handle I/O aborts

On Mon, Jun 18, 2012 at 9:48 AM, Avi Kivity <avi <at> redhat.com> wrote:
> On 06/15/2012 10:09 PM, Christoffer Dall wrote:
>> When the guest accesses I/O memory this will create data abort
>> exceptions and they are handled by decoding the HSR information
>> (physical address, read/write, length, register) and forwarding reads
>> and writes to QEMU which performs the device emulation.
>>
>> Certain classes of load/store operations do not support the syndrome
>> information provided in the HSR and we therefore must be able to fetch
>> the offending instruction from guest memory and decode it manually.
>>
>> This requires changing the general flow somewhat since new calls to run
>> the VCPU must check if there's a pending MMIO load and perform the write
>> after userspace has made the data available.
>>
>>
>>       memslot = gfn_to_memslot(vcpu->kvm, gfn);
>> diff --git a/arch/arm/kvm/trace.h b/arch/arm/kvm/trace.h
>> index e474a0a..bd3a6cc 100644
>> --- a/arch/arm/kvm/trace.h
>> +++ b/arch/arm/kvm/trace.h
>>  <at>  <at>  -39,6 +39,27  <at>  <at>  TRACE_EVENT(kvm_exit,
>>       TP_printk("PC: 0x%08lx", __entry->vcpu_pc)
>>  );
>>
>> +TRACE_EVENT(kvm_mmio_emulate,
>> +     TP_PROTO(unsigned long vcpu_pc, unsigned long instr,
>> +              unsigned long cpsr),
>> +     TP_ARGS(vcpu_pc, instr, cpsr),
>> +

(Continue reading)

headers

Marcelo Tosatti | 28 Jun 2012 23:49

Re: [PATCH v8 00/15] KVM/ARM Implementation

On Fri, Jun 15, 2012 at 03:06:39PM -0400, Christoffer Dall wrote:
> The following series implements KVM support for ARM processors,
> specifically on the Cortex A-15 platform.  Work is done in
> collaboration between Columbia University, Virtual Open Systems and
> ARM/Linaro.
> 
> The patch series applies to kvm/next, specifically commit:
> 25e531a988ea5a64bd97a72dc9d3c65ad5850120
> 
> This is Version 8 of the patch series, but the first two versions
> were reviewed outside of the KVM mailing list. Changes can also be
> pulled from:
>  git://github.com/virtualopensystems/linux-kvm-arm.git kvm-a15-v8
> 
> A non-flattened edition of the patch series can be found at:
>  git://github.com/virtualopensystems/linux-kvm-arm.git kvm-a15-v8-stage
> 
> The implementation is broken up into a logical set of patches, the first
> four are preparatory patches:
>  1. Add mem_type prot_pte accessor (ARM community)
>  2. Use KVM_CAP_IRQ_ROUTING to protect routing code  (KVM community)
>  3. Introduce __KVM_HAVE_IRQ_LINE (KVM community)
>  4. Guard code with CONFIG_MMU_NOTIFIER (KVM community)
> 
> KVM guys, please consider pulling the KVM generic patches as early as
> possible. Thanks.
> 
> The main implementation is broken up into separate patches, the first
> containing a skeleton of files, makefile changes, the basic user space
> interface and KVM architecture specific stubs.  Subsequent patches

(Continue reading)

headers

Christoffer Dall | 29 Jun 2012 00:44

Re: [PATCH v8 00/15] KVM/ARM Implementation

>
> Is there public documentation for "hyp-mode" available?
>
yes, you have to register on the ARM website
(http://infocenter.arm.com) but there you can download the ARM v7
architecture reference manual.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html