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

Re: [Minios-devel] [UNIKRAFT PATCHv4 21/43] plat/kvm: Add Arm64 basic entry code





On 11/07/18 10:50, Wei Chen wrote:
Hi Julien,

Hi Wei,

-----Original Message-----
From: Julien Grall <julien.grall@xxxxxxx>
Sent: 2018年7月8日 6:24
To: Wei Chen <Wei.Chen@xxxxxxx>; minios-devel@xxxxxxxxxxxxxxxxxxxx;
simon.kuenzer@xxxxxxxxx
Cc: Kaly Xin <Kaly.Xin@xxxxxxx>; nd <nd@xxxxxxx>
Subject: Re: [Minios-devel] [UNIKRAFT PATCHv4 21/43] plat/kvm: Add Arm64 basic
entry code

Hi,

On 07/06/2018 10:03 AM, Wei Chen wrote:
QEMU/KVM can boot an Arm64 elf image without multiboot. In this case,
we can plage _libkvmplat_entry to entry64.S directly as the vCPU
reset entry. In this basic entry code, we just initialize the boot
stack and prepare jumping to _libkvmplat_start.
Can you clarify why you are using the ELF format and not Image? My main
concern is the former does not seem to have a clear description of the
state of the VM at boot.


It's little hard for me to answer your question. This is why I reply this
Comment at the last. Actually, when I was selecting the elf image I didn’t
think so much. And most Unikernel projects that I have involved (ukvm, mini-os)
are using the elf image, both for arm and x86.

Mini-OS ARM is using the zImage format, not ELF. For UKVM, IIRC, you wrote it yourself. So I guess you based your understanding of the state of the VM from somewhere?


So I don't know and understand your concern. Could please give me a
detail of "clear description of the state of the VM at boot" ?

My concern is you don't know what is the state of the memory, caches, CPU mode... For the Image protocol, this is clearly identified in [1].

If you tell me ELF has the same description somewhere, then fine. I will be happy to look at it and compare with what you did.


For instance, it is not clear what is the state of the cache, SCTLR...

If we use other format image can we get above information? How does it do this?

Yes, this is described in the format documentation [1].


You also assume the MMU is turned on. Do you have a pointer on what is
the expected state at boot? This would be quite useful to review the
boot code.


I don't have the pointer, I just refer to FreeBSD's steps.

AFAIK, FreeBSD has its own bootloader based on UEFI. This is different from booting without firmware.


Signed-off-by: Wei Chen <Wei.Chen@xxxxxxx>
---
   plat/kvm/arm/entry64.S | 36 ++++++++++++++++++++++++++++++
   plat/kvm/arm/setup.c   | 50 ++++++++++++++++++++++++++++++++++++++++++
   2 files changed, 86 insertions(+)
   create mode 100644 plat/kvm/arm/entry64.S
   create mode 100644 plat/kvm/arm/setup.c

diff --git a/plat/kvm/arm/entry64.S b/plat/kvm/arm/entry64.S
new file mode 100644
index 0000000..8a8a2e0
--- /dev/null
+++ b/plat/kvm/arm/entry64.S
@@ -0,0 +1,36 @@
+#include <uk/arch/limits.h>
+#include <arm/cpu_defs.h>
+
+.data
+.globl _dtb
+
+#define BOOT_STACK_SIZE PAGE_SIZE
+
+/*
+ * The registers used by _libkvmplat_start:
+ * x0 - FDT pointer
+ */
+
+.text
+ENTRY(_libkvmplat_entry)
+       /* Boot stack is placed after pagetable area temporarily */
+       ldr x26, =_end
+       add x26, x26, #PAGE_TABLE_SIZE
+       add x27, x26, #BOOT_STACK_SIZE
+
+       /* Clean the boot stack */
+1:
+       stp xzr, xzr, [x26], #16
+       stp xzr, xzr, [x26], #16
+       stp xzr, xzr, [x26], #16
+       stp xzr, xzr, [x26], #16

I guess you expect the stack to be 64-byte aligned? If so, It would be
nice to write it down in a comment.


Why did you have such feeling? I think my stack is 16-bytes alignment.

Do you agree that each stp instruction will clear 16-byte? So if you execute 4 stp consecutively without boundary check, you impose the stack to be 64-byte aligned.

Did I miss anything?

Cheers,

[1] https://www.kernel.org/doc/Documentation/arm64/booting.txt

--
Julien Grall

_______________________________________________
Minios-devel mailing list
Minios-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/minios-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.