Re: kvmarm Digest, Vol 30, Issue 26

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi All,

I am a Masters student at Columbia University. I have taken for my current semester the performance analysis of applications on the guest kernel running with the help of KVM-ARM on the Cortex-A15 simulator, with Prof. Jason Nieh as my advisor.

As of now, I have managed to bring up the guest linux kernel. And I am trying to install Apache Server including the needed JRE environment on the guest kernel. As far as I understand, I need to install the JRE and Apache Server externally into the file system that we use to create the initrd image - initrd.cpio.gz that we use while booting the guest Linux kernel as under :

mkdir mnt1 mnt2
$ sudo mount -o loop fs-alip-armel.cramfs mnt1
$ sudo cp -a ./mnt1/* ./mnt2/
$ cd ./mnt2  ##### <------------------------------------------ Am installing the JRE and Apache under this folder
$ sudo ln -s sbin/init init
$ sudo sh -c "find . | cpio -o -H newc | gzip > ../initrd.cpio.gz"

Is the above approach fine or is there any other recommended approach? Also, I have put few printks in KVM code for ARM, in the world-switch area. Where can I see the output corresponding to those printks? I have tried looking into the logs that are dumped with dmesg command on both the host and guest Linux kernel. And they are plain printk() without any macro like KERN_DEBUG etc.

Appreciate any advice.

Thank you for your time.

Regards,
Raghavan


On Mon, Nov 19, 2012 at 2:07 AM, <kvmarm-request@xxxxxxxxxxxxxxxxxxxxx> wrote:
Send kvmarm mailing list submissions to
        kvmarm@xxxxxxxxxxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
or, via email, send a message with subject or body 'help' to
        kvmarm-request@xxxxxxxxxxxxxxxxxxxxx

You can reach the person managing the list at
        kvmarm-owner@xxxxxxxxxxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of kvmarm digest..."


Today's Topics:

   1. TrustZone support for VMs (James White)
   2. Re: TrustZone support for VMs (Peter Maydell)
   3. Re: [PATCH v2] ARM: KVM: Fix permission fault handling
      (Christoffer Dall)
   4. Real Time Patch (sanju james)
   5. [PATCH] KVM: ARM: Make VGIC_MAX_CPUS equal to KVM_MAX_VCPUS
      (Christoffer Dall)
   6. [PATCH] fixup! KVM: ARM: Make VGIC_MAX_CPUS equal to
      KVM_MAX_VCPUS (Christoffer Dall)
   7. Re: [PATCH] KVM: ARM: Make VGIC_MAX_CPUS equal to
      KVM_MAX_VCPUS (Marc Zyngier)


----------------------------------------------------------------------

Message: 1
Date: Wed, 14 Nov 2012 13:51:41 +0000
From: James White <james.white.2012@xxxxxxxxxxx>
Subject: TrustZone support for VMs
To: <kvmarm@xxxxxxxxxxxxxxxxxxxxx>
Message-ID: <SNT137-W339A2391EBCDD83D824374D9530@xxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"






I would like to understand the design of the KVM/ARM implementation with regard to making ARM's TrustZone capabilities available to a VM. I have read on several mailing lists that Qemu will have some limited support for TrustZone, so that at least you will be able to run secure firmware inside a VM. E.g. this will enable to use the smc instruction in a VM's boot loader, so that secure firmware implementations can be used and run on Qemu. So the first question is: is that already implemented and usable when running KVM on ARM?The second question is: in this design where TrustZone is "emulated" by Qemu, does KVM play a role in this as well? I assume that it cannot provide monitor mode in hardware (because it is running in hyp mode), so therefore it cannot provide any form of acceleration.
Thanks, James

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/kvmarm/attachments/20121114/4b0e95bb/attachment-0001.html

------------------------------

Message: 2
Date: Wed, 14 Nov 2012 14:02:15 +0000
From: Peter Maydell <peter.maydell@xxxxxxxxxx>
Subject: Re: TrustZone support for VMs
To: James White <james.white.2012@xxxxxxxxxxx>
Cc: kvmarm@xxxxxxxxxxxxxxxxxxxxx
Message-ID:
        <CAFEAcA_fFanQAnyzJdW3M0=LcnqBp99heMrB5PB90Fj7UD2SFg@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8

On 14 November 2012 13:51, James White <james.white.2012@xxxxxxxxxxx> wrote:
> I would like to understand the design of the KVM/ARM implementation with
> regard to making ARM's TrustZone capabilities available to a VM.
> I have read on several mailing lists that Qemu will have some limited
> support for TrustZone, so that at least you will be able to run secure
> firmware inside a VM. E.g. this will enable to use the smc instruction in a
> VM's boot loader, so that secure firmware implementations can be used and
> run on Qemu. So the first question is: is that already implemented and
> usable when running KVM on ARM?

No. At the moment trustzone support for QEMU (in purely emulated mode)
is unimplemented. I have some design ideas for a "minimal fake trustzone"
setup that would let you implement a qemu-specific fake bootrom for
booting guests that assume they run in the non-secure world and use SMC
calls for a few operations. We haven't actually started on that yet,
though (the current guest OS environment doesn't need it).

There's also been some work by Johannes Winter on doing proper emulation of
TrustZone, but this is experimental: https://github.com/jowinter/qemu-trustzone

The expected major use case for virtualization is that you'll just run
a straightforward guest that doesn't care about TrustZone at all.

> The second question is: in this design where TrustZone is "emulated" by
> Qemu, does KVM play a role in this as well? I assume that it cannot provide
> monitor mode in hardware (because it is running in hyp mode), so therefore
> it cannot provide any form of acceleration.

The virtualization extensions of the ARM architecture don't allow
virtualization of code running in monitor mode. You could probably
in theory implement a hybrid setup where non-secure world code ran
accelerated as usual and code in the secure world and/or monitor
mode code was emulated instruction at a time. However that would be
a lot of work and I don't think anybody is currently planning to do
it. (It might well also require some significant qemu rework to
cope with the two separate address spaces, device accesses which
differ for S vs NS accesses, etc.)

-- PMM


------------------------------

Message: 3
Date: Wed, 14 Nov 2012 11:21:56 -0500
From: Christoffer Dall <c.dall@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: [PATCH v2] ARM: KVM: Fix permission fault
        handling
To: Marc Zyngier <marc.zyngier@xxxxxxx>
Cc: kvmarm@xxxxxxxxxxxxxxxxxxxxx
Message-ID:
        <CANM98qJ+aZjuD_kT-XvouZk6HZM5cCYrMi1+CHEgmkEpEpcPeQ@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Nov 14, 2012 at 3:33 AM, Marc Zyngier <marc.zyngier@xxxxxxx> wrote:
> On Tue, 13 Nov 2012 20:39:21 -0500, Christoffer Dall
> <c.dall@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>> On Mon, Nov 12, 2012 at 12:02 PM, Marc Zyngier <marc.zyngier@xxxxxxx>
>> wrote:
>>> This patch fixes a very long standing bug in the KVM fault handling and
>>> is basically a backport of the equivalent arm64 code.
>>>
>>> The ARM ARM is quite explicit in saying the HPFAR cannot be trusted
>>> for a permission fault, unless it is a Stage-1 page table walk.
>>>
>>> The fact that it *seems* to work well enough on A15 is even more scary.
>>> We may well be silently corrupting memory without even noticing (hint,
>>> hint...). It is also quite possible that this bug would prevent KVM
>>> from running on a CPU which caches TLBs covering VA to PA with a single
>>> entry.
>>>
>>> The fix is to detect aborts that are permission faults, and not stage-1
>>> page table walk. We can then resolve the IPA, and store it just like
> the
>>> HPFAR register. If the IPA cannot be resolved, it means another CPU is
>>> playing with the page tables, and we simply restart the guest.
>>>
>>> This also paves the way for lighter Icache invalidation, using the NX
>>> bit.
>>>
>>> Signed-off-by: Marc Zyngier <marc.zyngier@xxxxxxx>
>>> ---
>>> >From v1:
>>> - Use ATS1CPR instead of ATS1CPW
>>>
>>>  arch/arm/kvm/interrupts.S | 37 ++++++++++++++++++++++++++++++++++++-
>>>  1 file changed, 36 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/kvm/interrupts.S b/arch/arm/kvm/interrupts.S
>>> index 5a09e89..b2d52a9 100644
>>> --- a/arch/arm/kvm/interrupts.S
>>> +++ b/arch/arm/kvm/interrupts.S
>>> @@ -401,12 +401,47 @@ guest_trap:
>>>         mrc     p15, 4, r2, c6, c0, 0   @ HDFAR
>>>
>>>  2:     str     r2, [r1, #VCPU_HxFAR]
>>> -       mrc     p15, 4, r2, c6, c0, 4   @ HPFAR
>>> +
>>> +       /*
>>> +        * B3.13.5 Reporting exceptions taken to the Non-secure PL2
> mode:
>>> +        *
>>> +        * Abort on the stage 2 translation for a memory access from a
>>> +        * Non-secure PL1 or PL0 mode:
>>> +        *
>>> +        * For any Access flag fault or Translation fault, and also for
>>> any
>>> +        * Permission fault on the stage 2 translation of a memory
> access
>>> +        * made as part of a translation table walk for a stage 1
>>> translation,
>>> +        * the HPFAR holds the IPA that caused the fault. Otherwise,
> the
>>> HPFAR
>>> +        * is UNKNOWN.
>>> +        */
>>> +
>>> +       /* Check for permission fault, and S1PTW */
>>> +       mrc     p15, 4, r1, c5, c2, 0   @ HSR
>>> +       and     r0, r1, #HSR_FSC_TYPE
>>> +       cmp     r0, #FSC_PERM
>>> +       tsteq   r1, #7                  @ S1PTW
>>
>>
>> shouldn't this be
>>
>>        tsteq   r1, #(1 << 7)              @ S1PTW
>>
>> ?
>
> Yup. arm64 contamination. Will fix and repost.
>
no need, I fixed an applied. thanks.


------------------------------

Message: 4
Date: Wed, 14 Nov 2012 19:34:53 +0100
From: sanju james <sanjukuttu@xxxxxxxxx>
Subject: Real Time Patch
To: kvmarm@xxxxxxxxxxxxxxxxxxxxx
Message-ID:
        <CADjSRHTrt3-+mk815=7XO+sSQw5iBMJkWoJPRO_7KjUeY-+Nmw@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"

Hi,

I am master student and doing a thesis to evaluate the kvm-linux for
attaining real time assurance for kvm operation. My plan is to give more
priorities for guest tasks so that we can get some real time assurances for
kvm. For doing this i need some real time patches that must be added into
the host linux-kvm kernel.

I would like get some information on real time patches which can be added
into this kernel. I have read in normal x86 linux-kvm they have PREMPT_RT
patches (also other similar patches) that can be added into the kernel . Is
there some similar real time patches that can be added into this kernel
also ? It would be very great if somebody help me with this. Hope to get a
reply soon.

Regards,

Sanjul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/kvmarm/attachments/20121114/d956cfd8/attachment-0001.html

------------------------------

Message: 5
Date: Mon, 19 Nov 2012 03:06:11 -0500
From: Christoffer Dall <c.dall@xxxxxxxxxxxxxxxxxxxxxx>
Subject: [PATCH] KVM: ARM: Make VGIC_MAX_CPUS equal to
        KVM_MAX_VCPUS
To: kvmarm@xxxxxxxxxxxxxxxxxxxxx
Message-ID:
        <1353312371-39867-1-git-send-email-c.dall@xxxxxxxxxxxxxxxxxxxxxx>

Also check index of vcpus as they are initialized against VGIC_MAX_CPUS
so future changes of these defines doesn't cause inadvertent kernel
crashes.

Cc: Marc Zyngier <marc.zyngier@xxxxxxx>
Signed-off-by: Christoffer Dall <c.dall@xxxxxxxxxxxxxxxxxxxxxx>
---
 arch/arm/include/asm/kvm_vgic.h |    4 ++--
 arch/arm/kvm/arm.c              |    6 +++++-
 arch/arm/kvm/vgic.c             |    7 +++++--
 3 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/arm/include/asm/kvm_vgic.h b/arch/arm/include/asm/kvm_vgic.h
index 7d2662c..065aa0b 100644
--- a/arch/arm/include/asm/kvm_vgic.h
+++ b/arch/arm/include/asm/kvm_vgic.h
@@ -28,7 +28,7 @@

 #define VGIC_NR_IRQS           128
 #define VGIC_NR_SHARED_IRQS    (VGIC_NR_IRQS - 32)
-#define VGIC_MAX_CPUS          NR_CPUS
+#define VGIC_MAX_CPUS          KVM_MAX_VCPUS

 /* Sanity checks... */
 #if (VGIC_MAX_CPUS > 8)
@@ -246,7 +246,7 @@ int kvm_vgic_set_addr(struct kvm *kvm, unsigned long type, u64 addr);
 int kvm_vgic_hyp_init(void);
 int kvm_vgic_init(struct kvm *kvm);
 int kvm_vgic_create(struct kvm *kvm);
-void kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu);
+int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu);
 void kvm_vgic_sync_to_cpu(struct kvm_vcpu *vcpu);
 void kvm_vgic_sync_from_cpu(struct kvm_vcpu *vcpu);
 int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid, unsigned int irq_num,
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index e62ba49..7a286d9 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -318,11 +318,15 @@ int __attribute_const__ kvm_target_cpu(void)

 int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
 {
+       int ret;
+
        /* Force users to call KVM_ARM_VCPU_INIT */
        vcpu->arch.target = -1;

        /* Set up VGIC */
-       kvm_vgic_vcpu_init(vcpu);
+       ret = kvm_vgic_vcpu_init(vcpu);
+       if (ret)
+               return ret;

        /* Set up the timer */
        kvm_timer_vcpu_init(vcpu);
diff --git a/arch/arm/kvm/vgic.c b/arch/arm/kvm/vgic.c
index 1f00b02..922a0aa 100644
--- a/arch/arm/kvm/vgic.c
+++ b/arch/arm/kvm/vgic.c
@@ -1045,7 +1045,7 @@ static irqreturn_t vgic_maintenance_handler(int irq, void *data)
        return IRQ_HANDLED;
 }

-void kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
+int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
 {
        struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
        struct vgic_dist *dist = &vcpu->kvm->arch.vgic;
@@ -1053,7 +1053,10 @@ void kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
        int i;

        if (!irqchip_in_kernel(vcpu->kvm))
-               return;
+               return 0;
+
+       if (vcpu->vcpu_id >= VGIC_MAX_CPUS)
+               return -EBUSY;

        for (i = 0; i < VGIC_NR_IRQS; i++) {
                if (i < 16)
--
1.7.9.5



------------------------------

Message: 6
Date: Mon, 19 Nov 2012 03:35:56 -0500
From: Christoffer Dall <c.dall@xxxxxxxxxxxxxxxxxxxxxx>
Subject: [PATCH] fixup! KVM: ARM: Make VGIC_MAX_CPUS equal to
        KVM_MAX_VCPUS
To: kvmarm@xxxxxxxxxxxxxxxxxxxxx
Message-ID:
        <1353314156-59400-1-git-send-email-c.dall@xxxxxxxxxxxxxxxxxxxxxx>

Signed-off-by: Christoffer Dall <c.dall@xxxxxxxxxxxxxxxxxxxxxx>
---
 arch/arm/include/asm/kvm_host.h |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index 41012ef..0a1a52b 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -23,7 +23,6 @@
 #include <asm/kvm_asm.h>
 #include <asm/fpstate.h>
 #include <asm/kvm_decode.h>
-#include <asm/kvm_vgic.h>
 #include <asm/kvm_arch_timer.h>

 #define KVM_MAX_VCPUS CONFIG_KVM_ARM_MAX_VCPUS
@@ -39,6 +38,8 @@
 #define KVM_NR_PAGE_SIZES      1
 #define KVM_PAGES_PER_HPAGE(x) (1UL<<31)

+#include <asm/kvm_vgic.h>
+
 struct kvm_vcpu;
 u32 *kvm_vcpu_reg(struct kvm_vcpu *vcpu, u8 reg_num, u32 mode);
 int kvm_target_cpu(void);
--
1.7.9.5



------------------------------

Message: 7
Date: Mon, 19 Nov 2012 10:07:03 +0000
From: Marc Zyngier <marc.zyngier@xxxxxxx>
Subject: Re: [PATCH] KVM: ARM: Make VGIC_MAX_CPUS equal to
        KVM_MAX_VCPUS
To: Christoffer Dall <c.dall@xxxxxxxxxxxxxxxxxxxxxx>
Cc: "kvmarm@xxxxxxxxxxxxxxxxxxxxx" <kvmarm@xxxxxxxxxxxxxxxxxxxxx>
Message-ID: <50AA04C7.3010804@xxxxxxx>
Content-Type: text/plain; charset=WINDOWS-1252

On 19/11/12 08:06, Christoffer Dall wrote:
> Also check index of vcpus as they are initialized against VGIC_MAX_CPUS
> so future changes of these defines doesn't cause inadvertent kernel
> crashes.

Yes, this is what the code used to be.

> Cc: Marc Zyngier <marc.zyngier@xxxxxxx>
> Signed-off-by: Christoffer Dall <c.dall@xxxxxxxxxxxxxxxxxxxxxx>

Acked-by: Marc Zyngier <marc.zyngier@xxxxxxx>

> ---
>  arch/arm/include/asm/kvm_vgic.h |    4 ++--
>  arch/arm/kvm/arm.c              |    6 +++++-
>  arch/arm/kvm/vgic.c             |    7 +++++--
>  3 files changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_vgic.h b/arch/arm/include/asm/kvm_vgic.h
> index 7d2662c..065aa0b 100644
> --- a/arch/arm/include/asm/kvm_vgic.h
> +++ b/arch/arm/include/asm/kvm_vgic.h
> @@ -28,7 +28,7 @@
>
>  #define VGIC_NR_IRQS         128
>  #define VGIC_NR_SHARED_IRQS  (VGIC_NR_IRQS - 32)
> -#define VGIC_MAX_CPUS                NR_CPUS
> +#define VGIC_MAX_CPUS                KVM_MAX_VCPUS
>
>  /* Sanity checks... */
>  #if (VGIC_MAX_CPUS > 8)
> @@ -246,7 +246,7 @@ int kvm_vgic_set_addr(struct kvm *kvm, unsigned long type, u64 addr);
>  int kvm_vgic_hyp_init(void);
>  int kvm_vgic_init(struct kvm *kvm);
>  int kvm_vgic_create(struct kvm *kvm);
> -void kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu);
> +int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu);
>  void kvm_vgic_sync_to_cpu(struct kvm_vcpu *vcpu);
>  void kvm_vgic_sync_from_cpu(struct kvm_vcpu *vcpu);
>  int kvm_vgic_inject_irq(struct kvm *kvm, int cpuid, unsigned int irq_num,
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index e62ba49..7a286d9 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -318,11 +318,15 @@ int __attribute_const__ kvm_target_cpu(void)
>
>  int kvm_arch_vcpu_init(struct kvm_vcpu *vcpu)
>  {
> +     int ret;
> +
>       /* Force users to call KVM_ARM_VCPU_INIT */
>       vcpu->arch.target = -1;
>
>       /* Set up VGIC */
> -     kvm_vgic_vcpu_init(vcpu);
> +     ret = kvm_vgic_vcpu_init(vcpu);
> +     if (ret)
> +             return ret;
>
>       /* Set up the timer */
>       kvm_timer_vcpu_init(vcpu);
> diff --git a/arch/arm/kvm/vgic.c b/arch/arm/kvm/vgic.c
> index 1f00b02..922a0aa 100644
> --- a/arch/arm/kvm/vgic.c
> +++ b/arch/arm/kvm/vgic.c
> @@ -1045,7 +1045,7 @@ static irqreturn_t vgic_maintenance_handler(int irq, void *data)
>       return IRQ_HANDLED;
>  }
>
> -void kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
> +int kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
>  {
>       struct vgic_cpu *vgic_cpu = &vcpu->arch.vgic_cpu;
>       struct vgic_dist *dist = &vcpu->kvm->arch.vgic;
> @@ -1053,7 +1053,10 @@ void kvm_vgic_vcpu_init(struct kvm_vcpu *vcpu)
>       int i;
>
>       if (!irqchip_in_kernel(vcpu->kvm))
> -             return;
> +             return 0;
> +
> +     if (vcpu->vcpu_id >= VGIC_MAX_CPUS)
> +             return -EBUSY;
>
>       for (i = 0; i < VGIC_NR_IRQS; i++) {
>               if (i < 16)
>


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




------------------------------

_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

End of kvmarm Digest, Vol 30, Issue 26
**************************************

_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm

[Index of Archives]     [Linux KVM]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux