Slides of kvm forum 2012?
Hello I was an attendee at the kvm forum 2012 in Barcelona. I think I heard that the slides will be gathered and posted on the web. But I cannot find them anywhere currently. Are the materials going to be available?(or already available?) Thanks, MinGyu Kim -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [kvmarm] [PATCH v2 06/14] KVM: ARM: Memory virtualization setup
> -Original Message-
> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
> Sent: Tuesday, October 09, 2012 9:56 PM
> To: Christoffer Dall
> Cc: Min-gyu Kim; 김창환; linux-arm-ker...@lists.infradead.org;
> kvm@vger.kernel.org; kvm...@lists.cs.columbia.edu
> Subject: Re: [kvmarm] [PATCH v2 06/14] KVM: ARM: Memory virtualization
> setup
>
> On Sat, 6 Oct 2012 17:33:43 -0400, Christoffer Dall
> wrote:
> > On Thu, Oct 4, 2012 at 10:23 PM, Min-gyu Kim
> >
> > wrote:
> >>
> >>
> >>> -Original Message-
> >>> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org]
> >>> On Behalf Of Christoffer Dall
> >>> Sent: Monday, October 01, 2012 6:11 PM
> >>> To: kvm@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> >>> kvm...@lists.cs.columbia.edu
> >>> Cc: Marc Zyngier
> >>> Subject: [PATCH v2 06/14] KVM: ARM: Memory virtualization setup
> >>>
> >>> +static void stage2_set_pte(struct kvm *kvm, struct
> kvm_mmu_memory_cache
> >>> *cache,
> >>> +phys_addr_t addr, const pte_t *new_pte) {
> >>> + pgd_t *pgd;
> >>> + pud_t *pud;
> >>> + pmd_t *pmd;
> >>> + pte_t *pte, old_pte;
> >>> +
> >>> + /* Create 2nd stage page table mapping - Level 1 */
> >>> + pgd = kvm->arch.pgd + pgd_index(addr);
> >>> + pud = pud_offset(pgd, addr);
> >>> + if (pud_none(*pud)) {
> >>> + if (!cache)
> >>> + return; /* ignore calls from kvm_set_spte_hva */
> >>> + pmd = mmu_memory_cache_alloc(cache);
> >>> + pud_populate(NULL, pud, pmd);
> >>> + pmd += pmd_index(addr);
> >>> + get_page(virt_to_page(pud));
> >>> + } else
> >>> + pmd = pmd_offset(pud, addr);
> >>> +
> >>> + /* Create 2nd stage page table mapping - Level 2 */
> >>> + if (pmd_none(*pmd)) {
> >>> + if (!cache)
> >>> + return; /* ignore calls from kvm_set_spte_hva */
> >>> + pte = mmu_memory_cache_alloc(cache);
> >>> + clean_pte_table(pte);
> >>> + pmd_populate_kernel(NULL, pmd, pte);
> >>> + pte += pte_index(addr);
> >>> + get_page(virt_to_page(pmd));
> >>> + } else
> >>> + pte = pte_offset_kernel(pmd, addr);
> >>> +
> >>> + /* Create 2nd stage page table mapping - Level 3 */
> >>> + old_pte = *pte;
> >>> + set_pte_ext(pte, *new_pte, 0);
> >>> + if (pte_present(old_pte))
> >>> + __kvm_tlb_flush_vmid(kvm);
> >>> + else
> >>> + get_page(virt_to_page(pte)); }
> >>
> >>
> >> I'm not sure about the 3-level page table, but isn't it necessary to
> >> clean the page table for 2nd level?
> >> There are two mmu_memory_cache_alloc calls. One has following
> >> clean_pte_table and the other doesn't have.
> >
> > hmm, it probably is - I couldn't really find the common case where
> > this is done in the kernel normally (except for some custom loop in
> > ioremap and idmap), but I added this fix:
> >
> > diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c index
> > 5394a52..f11ba27f 100644
> > --- a/arch/arm/kvm/mmu.c
> > +++ b/arch/arm/kvm/mmu.c
> > @@ -430,6 +430,7 @@ static void stage2_set_pte(struct kvm *kvm, struct
> > kvm_mmu_memory_cache *cache,
> > if (!cache)
> > return; /* ignore calls from kvm_set_spte_hva */
> > pmd = mmu_memory_cache_alloc(cache);
> > + clean_dcache_area(pmd, PTRS_PER_PMD * sizeof(pmd_t));
> > pud_populate(NULL, pud, pmd);
> > pmd += pmd_index(addr);
> > get_page(virt_to_page(pud));
>
> There ought to be a test of ID_MMFR3[23:20] to find out whether or not it
> is useful to clean the dcache. Not sure if that's a massive gain, but it
> is certainly an optimisation to consider for the kernel as a whole.
That's part of what I was wondering. clean_dcache_area is substituted by nop if
TLB_CAN_READ_FROM_L1_CACHE is defined(mm/proc-v7.S).
But I couldn't find any place where it is defined.
If it is part of bsp to enable TLB_CAN_RAD_FROM_L1_CACHE according to
ID_MMFR3[23:20],
it would not be necessary to concerned about cleaning or not cleaning.
However, am I right?
>
> M.
> --
> Fast, cheap, reliable. Pick two.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 06/14] KVM: ARM: Memory virtualization setup
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
> Behalf Of Christoffer Dall
> Sent: Monday, October 01, 2012 6:11 PM
> To: kvm@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> kvm...@lists.cs.columbia.edu
> Cc: Marc Zyngier
> Subject: [PATCH v2 06/14] KVM: ARM: Memory virtualization setup
>
> +static void stage2_set_pte(struct kvm *kvm, struct kvm_mmu_memory_cache
> *cache,
> +phys_addr_t addr, const pte_t *new_pte) {
> + pgd_t *pgd;
> + pud_t *pud;
> + pmd_t *pmd;
> + pte_t *pte, old_pte;
> +
> + /* Create 2nd stage page table mapping - Level 1 */
> + pgd = kvm->arch.pgd + pgd_index(addr);
> + pud = pud_offset(pgd, addr);
> + if (pud_none(*pud)) {
> + if (!cache)
> + return; /* ignore calls from kvm_set_spte_hva */
> + pmd = mmu_memory_cache_alloc(cache);
> + pud_populate(NULL, pud, pmd);
> + pmd += pmd_index(addr);
> + get_page(virt_to_page(pud));
> + } else
> + pmd = pmd_offset(pud, addr);
> +
> + /* Create 2nd stage page table mapping - Level 2 */
> + if (pmd_none(*pmd)) {
> + if (!cache)
> + return; /* ignore calls from kvm_set_spte_hva */
> + pte = mmu_memory_cache_alloc(cache);
> + clean_pte_table(pte);
> + pmd_populate_kernel(NULL, pmd, pte);
> + pte += pte_index(addr);
> + get_page(virt_to_page(pmd));
> + } else
> + pte = pte_offset_kernel(pmd, addr);
> +
> + /* Create 2nd stage page table mapping - Level 3 */
> + old_pte = *pte;
> + set_pte_ext(pte, *new_pte, 0);
> + if (pte_present(old_pte))
> + __kvm_tlb_flush_vmid(kvm);
> + else
> + get_page(virt_to_page(pte));
> +}
I'm not sure about the 3-level page table, but isn't it necessary to
clean the page table for 2nd level?
There are two mmu_memory_cache_alloc calls. One has following clean_pte_table
and the other doesn't have.
And why do you ignore calls from kvm_set_spte_hva? It is supposed to happen when
host moves the page, right? Then you ignore the case because it can be handled
later when fault actually happens? Is there any other reason that I miss?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 06/15] KVM: ARM: Initial skeleton to compile KVM support
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
> Behalf Of Christoffer Dall
> Sent: Monday, October 01, 2012 4:22 AM
> To: Will Deacon
> Cc: kvm@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> kvm...@lists.cs.columbia.edu; rusty.russ...@linaro.org; a...@redhat.com;
> marc.zyng...@arm.com
> Subject: Re: [PATCH 06/15] KVM: ARM: Initial skeleton to compile KVM
> support
>
> On Thu, Sep 27, 2012 at 10:13 AM, Will Deacon wrote:
> > On Wed, Sep 26, 2012 at 02:43:14AM +0100, Christoffer Dall wrote:
> >> On 09/25/2012 11:20 AM, Will Deacon wrote:
> >> >> +/* Multiprocessor Affinity Register */
> >> >> +#define MPIDR_CPUID(0x3 << 0)
> >> >
> >> > I'm fairly sure we already have code under arch/arm/ for dealing
> >> > with the mpidr. Let's re-use that rather than reinventing it here.
> >> >
> >>
> >> I see some defines in topology.c - do you want some of these factored
> >> out into a header file that we can then also use from kvm? If so,
where?
> >
> > I guess either in topology.h or a new header (topology-bits.h).
> >
> >> >> +#define EXCEPTION_NONE 0
> >> >> +#define EXCEPTION_RESET 0x80
> >> >> +#define EXCEPTION_UNDEFINED 0x40
> >> >> +#define EXCEPTION_SOFTWARE 0x20
> >> >> +#define EXCEPTION_PREFETCH 0x10
> >> >> +#define EXCEPTION_DATA 0x08
> >> >> +#define EXCEPTION_IMPRECISE 0x04
> >> >> +#define EXCEPTION_IRQ 0x02
> >> >> +#define EXCEPTION_FIQ 0x01
> >> >
> >> > Why the noise?
> >> >
> >>
> >> these are simply cruft from a previous life of KVM/ARM.
> >
> > Ok, then please get rid of them.
> >
> >> >> +static inline enum vcpu_mode vcpu_mode(struct kvm_vcpu *vcpu) {
> >> >> + u8 mode = __vcpu_mode(vcpu->arch.regs.cpsr);
> >> >> + BUG_ON(mode == 0xf);
> >> >> + return mode;
> >> >> +}
> >> >
> >> > I noticed that you have a fair few BUG_ONs throughout the series.
> >> > Fair enough, but for hyp code is that really the right thing to do?
> >> > Killing the guest could make more sense, perhaps?
> >>
> >> the idea is to have BUG_ONs that are indeed BUG_ONs that we want to
> >> catch explicitly on the host. We have had a pass over the code to
> >> change all the BUG_ONs that can be provoked by the guest and inject
> >> the proper exceptions into the guest in this case. If you find places
> >> where this is not the case, it should be changed, and do let me know.
> >
> > Ok, so are you saying that a BUG_ON due to some detected inconsistency
> > with one guest may not necessarily terminate the other guests? BUG_ONs
> > in the host seem like a bad idea if the host is able to continue with
> > a subset of guests.
> >
>
> No, I'm saying a BUG_ON is an actual BUG, it should not happen and there
> should be nowhere where a guest can cause a BUG_ON to occur in the host,
> because that would be a bug.
>
> We basically never kill a guest unless really extreme things happen (like
> we cannot allocate a pte, in which case we return -ENOMEM). If a guest
> does something really weird, that guest will receive the appropriate
> exception (undefined, prefetch abort, ...)
>
I agree with Will. It seems to be overreacting to kill the entire system.
>From the code above, BUG_ON case clearly points out that there happened a
serious bug case. However, killing the corresponding VM may not cause any
further problem.
Then leave some logs for debugging and killing the VM seems to be enough.
Let's assume KVM for ARM is distributed with a critical bug.
If the case is defended by BUG_ON, it will cause host to shutdown.
If the case is defended by killing VM, it will cause VM to shutdown.
In my opinion, latter case seems to be better.
I looked for a guide on BUG_ON and found this:
http://yarchive.net/comp/linux/BUG.html
> >> >
> >> >> +static inline u32 *vcpu_pc(struct kvm_vcpu *vcpu) {
> >> >> + return vcpu_reg(vcpu, 15); }
> >> >
> >> > If you stick a struct pt_regs into struct kvm_regs, you could reuse
> >> > ARM_pc here etc.
> >> >
> >>
> >> I prefer not to, because we'd have those registers presumably for usr
> >> mode and then we only define the others explicit. I think it's much
> >> clearer to look at kvm_regs today.
> >
> > I disagree and think that you should reuse as much of the arch/arm/
> > code as possible. Not only does it make it easier to read by people
> > who are familiar with that code (and in turn get you more reviewers)
> > but it also means that we limit the amount of duplication that we have.
>
> Reusing a struct just for the sake of reusing is not necessarily an
> improvement. Some times it complicates things, and some times it's
> misleading. To me, pt_regs carry the meaning that these are the registers
> for a user space process that traps into the kernel - in KVM we emulate a
> virtual CPU and that current definition is quite clear.
>
> The argument that more people will review the code if the struct contains
> a pt_regs field rather than a usr_regs field is completely invalid,
>
RE: [PATCH 13/15] KVM: ARM: Handle guest faults in KVM
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
> Behalf Of Christoffer Dall
> Sent: Tuesday, September 25, 2012 9:39 PM
> To: Min-gyu Kim
> Cc: kvm@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> kvm...@lists.cs.columbia.edu; 김창환
> Subject: Re: [PATCH 13/15] KVM: ARM: Handle guest faults in KVM
>
> >> +
> >> + /*
> >> + * If this is a write fault (think COW) we need to make sure the
> >> + * existing page, which other CPUs might still read, doesn't go
> >> away
> >> + * from under us, by calling gfn_to_pfn_prot(write_fault=true).
> >> + * Therefore, we call gfn_to_pfn_prot(write_fault=false), which
> >> will
> >> + * pin the existing page, then we get a new page for the user
> space
> >> + * pte and map this in the stage-2 table where we also make sure
> to
> >> + * flush the TLB for the VM, if there was an existing entry
> >> + (the
> >> entry
> >> + * was updated setting the write flag to the potentially new
page).
> >> + */
> >> + if (fault_status == FSC_PERM) {
> >> + pfn_existing = gfn_to_pfn_prot(vcpu->kvm, gfn, false,
NULL);
> >> + if (is_error_pfn(pfn_existing))
> >> + return -EFAULT;
> >> + }
> >> +
> >> + pfn = gfn_to_pfn_prot(vcpu->kvm, gfn, write_fault, &writable);
> >> + if (is_error_pfn(pfn)) {
> >> + ret = -EFAULT;
> >> + goto out_put_existing;
> >> + }
> >> +
> >> + /* We need minimum second+third level pages */
> >> + ret = mmu_topup_memory_cache(memcache, 2, KVM_NR_MEM_OBJS);
> >> + if (ret)
> >> + goto out;
> >> + new_pte = pfn_pte(pfn, PAGE_KVM_GUEST);
> >> + if (writable)
> >> + pte_val(new_pte) |= L_PTE2_WRITE;
> >> + coherent_icache_guest_page(vcpu->kvm, gfn);
> >
> > why don't you flush icache only when guest has mapped executable page
> > as __sync_icache_dcache function does currently?
> >
> >
>
> because we don't know if the guest will map the page executable. The guest
> may read the page through a normal load, which causes the fault, and
> subsequently execute it (even possible through different guest mappings).
> The only way to see this happening would be to mark all pages as non-
> executable and catch the fault when it occurs - unfortunately the HPFAR
> which gives us the IPA is not populated on execute never faults, so we
> would have to translate the PC's va to ipa using cp15 functionality when
> this happens, which is then also racy with other CPUs. So the question is
> really if this will even be an optimization, but it's definitely something
> that requires further investigation.
OK. I understand your point.
But if guest maps a page for execution, guest will flush Icache
from __sync_icache_dcache. Then coherent_icache_guest_page doesn't seem to
be
necessary again. One thing I'm not sure in this case is when guest maps
for kernel executable page(module loading) and it reuses the kernel
executable page
from host(module unloading). But in that case, I think it is possible to
reduce
the number of flush by limiting the address range for flush.
>
> -Christoffer
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in the body
> of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 13/15] KVM: ARM: Handle guest faults in KVM
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
> Behalf Of Christoffer Dall
> Sent: Sunday, September 16, 2012 12:36 AM
> To: kvm@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> kvm...@lists.cs.columbia.edu
> Subject: [PATCH 13/15] KVM: ARM: Handle guest faults in KVM
>
> From: Christoffer Dall
>
> Handles the guest faults in KVM by mapping in corresponding user pages in
> the 2nd stage page tables.
>
> We invalidate the instruction cache by MVA whenever we map a page to the
> guest (no, we cannot only do it when we have an iabt because the guest may
> happily read/write a page before hitting the icache) if the hardware uses
> VIPT or PIPT. In the latter case, we can invalidate only that physical
> page. In the first case, all bets are off and we simply must invalidate
> the whole affair. Not that VIVT icaches are tagged with vmids, and we are
> out of the woods on that one. Alexander Graf was nice enough to remind us
> of this massive pain.
>
> There may be a subtle bug hidden in, which we currently hide by marking
> all pages dirty even when the pages are only mapped read-only. The
> current hypothesis is that marking pages dirty may exercise the IO system
> and data cache more and therefore we don't see stale data in the guest,
> but it's purely guesswork. The bug is manifested by seemingly random
> kernel crashes in guests when the host is under extreme memory pressure
> and swapping is enabled.
>
> Signed-off-by: Marc Zyngier
> Signed-off-by: Christoffer Dall
> ---
> arch/arm/include/asm/kvm_arm.h |9 ++
> arch/arm/include/asm/kvm_asm.h |2 +
> arch/arm/kvm/mmu.c | 155
>
> arch/arm/kvm/trace.h | 28 +++
> 4 files changed, 193 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/kvm_arm.h
> b/arch/arm/include/asm/kvm_arm.h index ae586c1..4cff3b7 100644
> --- a/arch/arm/include/asm/kvm_arm.h
> +++ b/arch/arm/include/asm/kvm_arm.h
> @@ -158,11 +158,20 @@
> #define HSR_ISS (HSR_IL - 1)
> #define HSR_ISV_SHIFT(24)
> #define HSR_ISV (1U << HSR_ISV_SHIFT)
> +#define HSR_FSC (0x3f)
> +#define HSR_FSC_TYPE (0x3c)
> +#define HSR_WNR (1 << 6)
> #define HSR_CV_SHIFT (24)
> #define HSR_CV (1U << HSR_CV_SHIFT)
> #define HSR_COND_SHIFT (20)
> #define HSR_COND (0xfU << HSR_COND_SHIFT)
>
> +#define FSC_FAULT(0x04)
> +#define FSC_PERM (0x0c)
> +
> +/* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
> +#define HPFAR_MASK (~0xf)
> +
> #define HSR_EC_UNKNOWN (0x00)
> #define HSR_EC_WFI (0x01)
> #define HSR_EC_CP15_32 (0x03)
> diff --git a/arch/arm/include/asm/kvm_asm.h
> b/arch/arm/include/asm/kvm_asm.h index 201ec1f..40ee099 100644
> --- a/arch/arm/include/asm/kvm_asm.h
> +++ b/arch/arm/include/asm/kvm_asm.h
> @@ -43,6 +43,8 @@ extern char __kvm_hyp_vector[]; extern char
> __kvm_hyp_code_start[]; extern char __kvm_hyp_code_end[];
>
> +extern void __kvm_tlb_flush_vmid(struct kvm *kvm);
> +
> extern void __kvm_flush_vm_context(void); extern void
> __kvm_tlb_flush_vmid(struct kvm *kvm);
>
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c index
> ea17a97..52cc280 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -21,10 +21,16 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> +#include
> #include
> +#include
> +#include
> +
> +#include "trace.h"
>
> static DEFINE_MUTEX(kvm_hyp_pgd_mutex);
>
> @@ -490,9 +496,156 @@ out:
> return ret;
> }
>
> +static void coherent_icache_guest_page(struct kvm *kvm, gfn_t gfn) {
> + /*
> + * If we are going to insert an instruction page and the icache is
> + * either VIPT or PIPT, there is a potential problem where the host
> + * (or another VM) may have used this page at the same virtual
> address
> + * as this guest, and we read incorrect data from the icache. If
> + * we're using a PIPT cache, we can invalidate just that page, but
> if
> + * we are using a VIPT cache we need to invalidate the entire
> icache -
> + * damn shame - as written in the ARM ARM (DDI 0406C - Page B3-1384)
> + */
> + if (icache_is_pipt()) {
> + unsigned long hva = gfn_to_hva(kvm, gfn);
> + __cpuc_coherent_user_range(hva, hva + PAGE_SIZE);
> + } else if (!icache_is_vivt_asid_tagged()) {
> + /* any kind of VIPT cache */
> + __flush_icache_all();
> + }
> +}
> +
> +static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> + gfn_t gfn, struct kvm_memory_slot *memslot,
> + bool is_iabt, unsigned long fault_status) {
> + pte_t new_pte;
> + pfn_t pfn, pfn_existing = KVM_PFN_ERR_BAD;
> + int ret;
> + bool write_fault, writable;
> + struct kvm_mmu_memory_cache *memca
RE: [PATCH 01/10] ARM: KVM: Keep track of currently running vcpus
> -Original Message-
> From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On
> Behalf Of Christoffer Dall
> Sent: Sunday, September 16, 2012 12:37 AM
> To: kvm@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> kvm...@lists.cs.columbia.edu
> Subject: [PATCH 01/10] ARM: KVM: Keep track of currently running vcpus
>
> From: Marc Zyngier
>
> When an interrupt occurs for the guest, it is sometimes necessary to find
> out which vcpu was running at that point.
>
> Keep track of which vcpu is being tun in kvm_arch_vcpu_ioctl_run(), and
> allow the data to be retrived using either:
> - kvm_arm_get_running_vcpu(): returns the vcpu running at this point
> on the current CPU. Can only be used in a non-preemptable context.
What's the purpose of kvm_arm_get_running_vcpu?
It seems to be enough to pass vcpu struct through function argument,
and there is no caller by now.
> - kvm_arm_get_running_vcpus(): returns the per-CPU variable holding
> the the running vcpus, useable for per-CPU interrupts.
>
> Signed-off-by: Marc Zyngier
> Signed-off-by: Christoffer Dall
> ---
> arch/arm/include/asm/kvm_host.h |9 +
> arch/arm/kvm/arm.c | 30 ++
> 2 files changed, 39 insertions(+)
>
> diff --git a/arch/arm/include/asm/kvm_host.h
> b/arch/arm/include/asm/kvm_host.h index 3fec9ad..2e3ac1c 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -208,4 +208,13 @@ static inline int kvm_test_age_hva(struct kvm *kvm,
> unsigned long hva) {
> return 0;
> }
> +
> +struct kvm_vcpu *kvm_arm_get_running_vcpu(void); struct kvm_vcpu
> +__percpu **kvm_get_running_vcpus(void);
> +
> +int kvm_arm_copy_coproc_indices(struct kvm_vcpu *vcpu, u64 __user
> +*uindices); unsigned long kvm_arm_num_coproc_regs(struct kvm_vcpu
> +*vcpu); struct kvm_one_reg; int kvm_arm_coproc_get_reg(struct kvm_vcpu
> +*vcpu, const struct kvm_one_reg *); int kvm_arm_coproc_set_reg(struct
> +kvm_vcpu *vcpu, const struct kvm_one_reg *);
> #endif /* __ARM_KVM_HOST_H__ */
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c index
> 64fbec7..e6c3743 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -54,11 +54,38 @@ static DEFINE_PER_CPU(unsigned long,
> kvm_arm_hyp_stack_page); static struct vfp_hard_struct __percpu
> *kvm_host_vfp_state; static unsigned long hyp_default_vectors;
>
> +/* Per-CPU variable containing the currently running vcpu. */ static
> +DEFINE_PER_CPU(struct kvm_vcpu *, kvm_arm_running_vcpu);
> +
> /* The VMID used in the VTTBR */
> static atomic64_t kvm_vmid_gen = ATOMIC64_INIT(1); static u8
> kvm_next_vmid; static DEFINE_SPINLOCK(kvm_vmid_lock);
>
> +static void kvm_arm_set_running_vcpu(struct kvm_vcpu *vcpu) {
> + BUG_ON(preemptible());
> + __get_cpu_var(kvm_arm_running_vcpu) = vcpu; }
> +
> +/**
> + * kvm_arm_get_running_vcpu - get the vcpu running on the current CPU.
> + * Must be called from non-preemptible context */ struct kvm_vcpu
> +*kvm_arm_get_running_vcpu(void) {
> + BUG_ON(preemptible());
> + return __get_cpu_var(kvm_arm_running_vcpu);
> +}
> +
> +/**
> + * kvm_arm_get_running_vcpus - get the per-CPU array on currently running
> vcpus.
> + */
> +struct kvm_vcpu __percpu **kvm_get_running_vcpus(void) {
> + return &kvm_arm_running_vcpu;
> +}
> +
> int kvm_arch_hardware_enable(void *garbage) {
> return 0;
> @@ -293,10 +320,13 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int
> cpu)
> cpumask_clear_cpu(cpu, &vcpu->arch.require_dcache_flush);
> flush_cache_all(); /* We'd really want v7_flush_dcache_all()
> */
> }
> +
> + kvm_arm_set_running_vcpu(vcpu);
> }
>
> void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu) {
> + kvm_arm_set_running_vcpu(NULL);
> }
>
> int kvm_arch_vcpu_ioctl_set_guest_debug(struct kvm_vcpu *vcpu,
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in the body
> of a message to majord...@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v10 07/14] KVM: ARM: Memory virtualization setup
Dear Christoffer Dall,
In you code, kvm_alloc_stage2_pgd function allocates page table and memset.
isn't it necessary to clean the data cache after memset?
For reference, pgd_alloc cleans the area with clean_dcache_area.
There's some situation that cleaning is not necessary, and clean_dcache_area
function becomes empty in that case.
But I think explicit cleaning would be better for portability.
Best Regards
Min-gyu Kim
-Original Message-
From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of
Christoffer Dall
Sent: Friday, August 17, 2012 12:29 AM
To: kvm...@lists.cs.columbia.edu; kvm@vger.kernel.org
Subject: [PATCH v10 07/14] KVM: ARM: Memory virtualization setup
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);
Introduces new ARM-specific kernel memory types, PAGE_KVM_GUEST and
pgprot_guest variables used to map 2nd stage memory for KVM guests.
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.
We pre-allocate page table memory to be able to synchronize using a spinlock
and be called under rcu_read_lock from the MMU notifiers. We steal the
mmu_memory_cache implementation from x86 and adapt for our specific usage.
We support MMU notifiers (thanks to Marc Zyngier) through kvm_unmap_hva and
kvm_set_spte_hva.
Finally, define kvm_phys_addr_ioremap() to map a device at a guest IPA, which
is used by VGIC support to map the virtual CPU interface registers to the
guest. This support is added by Marc Zyngier.
Signed-off-by: Marc Zyngier
Signed-off-by: Christoffer Dall
---
arch/arm/include/asm/kvm_asm.h|2
arch/arm/include/asm/kvm_host.h | 18 ++
arch/arm/include/asm/kvm_mmu.h|9 +
arch/arm/include/asm/pgtable-3level.h |9 +
arch/arm/include/asm/pgtable.h|4
arch/arm/kvm/Kconfig |1
arch/arm/kvm/arm.c| 38 +++
arch/arm/kvm/exports.c|1
arch/arm/kvm/interrupts.S |8 +
arch/arm/kvm/mmu.c| 373 +
arch/arm/mm/mmu.c |3
11 files changed, 465 insertions(+), 1 deletion(-)
diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
index 58d51e3..55b6446 100644
--- a/arch/arm/include/asm/kvm_asm.h
+++ b/arch/arm/include/asm/kvm_asm.h
@@ -34,6 +34,7 @@
#define SMCHYP_HVBAR_W 0xfff0
#ifndef __ASSEMBLY__
+struct kvm;
struct kvm_vcpu;
extern char __kvm_hyp_init[];
@@ -48,6 +49,7 @@ extern char __kvm_hyp_code_start[]; extern char
__kvm_hyp_code_end[];
extern void __kvm_flush_vm_context(void);
+extern void __kvm_tlb_flush_vmid(struct kvm *kvm);
extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu); #endif diff --git
a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h index
d7e3398..d86ce39 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -157,4 +157,22 @@ struct kvm_vcpu_stat { struct kvm_vcpu_init; int
kvm_vcpu_set_target(struct kvm_vcpu *vcpu,
const struct kvm_vcpu_init *init);
+
+#define KVM_ARCH_WANT_MMU_NOTIFIER
+struct kvm;
+int kvm_unmap_hva(struct kvm *kvm, unsigned long hva); int
+kvm_unmap_hva_range(struct kvm *kvm,
+ unsigned long start, unsigned long end); void
+kvm_set_spte_hva(struct kvm *kvm, unsigned long hva, pte_t pte);
+
+/* We do not have shadow page tables, hence the empty hooks */ static
+inline int kvm_age_hva(struct kvm *kvm, unsigned long hva) {
+ return 0;
+}
+
+static inline int kvm_test_age_hva(struct kvm *kvm, unsigned long hva)
+{
+ return 0;
+}
#endif /* __ARM_KVM_HOST_H__ */
diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
index 8252921..11f4c3a 100644
--- a/arch/arm/include/asm/kvm_mmu.h
+++ b/arch/arm/include/asm/kvm_mmu.h
@@ -33,4 +33,13 @@ int create_hyp_mappings(void *from, void *to); int
create_hyp_io_mappings(void *from, void *to, phys_addr_t); void
free_hyp_pmds(void);
+int kvm_alloc_stage2_pgd(struct kvm *kvm); void
+kvm_free_stage2_pgd(struct kvm *kvm); int kvm_phys_addr_ioremap(struct
+kvm *kvm, p
RE: How does QEMU communicate with KVM?
Sorry for sending garbage mail There are several ways that qemu and kvm can communicate. One of them is the ioctl to /dev/kvm and it is documented in Documentation/virtual/kvm/api.txt. But there's other ways also: like the pages that are mmap-ed from kvm_vcpu_fault function, I’m not sure about the documentation of such channels. regards Min-gyu Kim --- Original Message --- Sender : Richard Yao Date : 2012-07-30 14:47 (GMT+09:00) Title : How does QEMU communicate with KVM? Is there any documentation on how QEMU communicates with KVM? From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of 김민규 Sent: Monday, July 30, 2012 5:23 PM To: Richard Yao; kvm@vger.kernel.org Subject: Re: How does QEMU communicate with KVM? -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v9 13/16] ARM: KVM: Emulation framework and CP15 emulation
Why does the cache operation need to happen on the same CPU while the L1 caches between cores are coherent? As you know, cache operations usually operate for a range and it iterates without disabling preemption. Therefore, though you enclose the vcpu_run and handle_exit with preemption disable, the operations on a range can run on several cores. If data of address X is written from CPU0 and CPU1 executes cache flush on address X while those 2 CPUs have same TTBR, does the cache operation fail? It seems to succeed from the document from ARM that I referred before. And that's why I think the preemption disable is unnecessary. Regards Kim, Min-gyu -Original Message- > And you said the reason of disabling preemption as CPU-specific data such as > caches. > But as far as I know, the l1 caches are coherent. > (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0438e/ > BABFHDFE.html) > > Can you please explain why preemption disable is necessary in detail? > if a VM tries to do a cache maintenance operation specific to that CPU that traps we want to make sure that the emulation of such operations happen on the same physical CPU to ensure correct semantics. -Christoffer -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
