Chen, Zide
Hi Dubravko,
You are very welcome! Additional to Shuo's suggestion, here are some advices:
1) X2APIC. I added this log but didn't see it from your log. That's why I claimed that the guest didn't switch to x2apic.
pr_err("vm%d vcpu%d switched to X2APIC new %x", vlapic->vm->vm_id, vlapic->vcpu->vcpu_id, new);
BTW, Hypervisor passthru the CPUID X2APIC capability (CPUID.01.ECX[21]) to the guest and it's up to the guest to enable X2APIC.
2) Linux logs
Hypervisor provides a virtual UART port to Linux and expects Linux to detect it. You may double check the BASE/IRQ macro in your hypervisor code, and try to explicitly tell Linux with this info thru the bootargs?
scenarios/sdc/vm_configurations.c
struct acrn_vm_config vm_configs[CONFIG_MAX_VM_NUM] = {
{
.load_order = SOS_VM,
.name = "ACRN SOS VM",
.vuart[0] = {
.type = VUART_LEGACY_PIO,
.addr.port_base = SOS_COM1_BASE, // 0x3F8
.irq = SOS_COM1_IRQ, // 4
},
}
}
3) VCPU BLOCKED state.
This may be OK. HV could block the VCPU when it'handling guest's IO requests. Or it's never been woken up by SIPI. As I mentioned previously, I didn't see such SIPI sequences on other boards before and can't say it actually works or not. I'd suggest to use "MAXCPUS=1" to force the guest boot with one single CPU only.
4) HV console
So far so good. You may try other commands which may further indicate the guest's status.
ACRN:\>int
IRQ VECTOR CPU0 CPU1 CPU2 CPU3
0 0x20 28 0 0 0
1 0x21 0 0 0 0
2 0x22 0 0 0 0
3 0x23 0 0 0 0
4 0x24 0 0 0 0
5 0x25 0 0 0 0
6 0x26 0 0 0 0
7 0x27 0 0 0 0
8 0x28 0 0 0 1
9 0x29 0 5718 0 0
10 0x2A 0 0 0 0
11 0x2B 0 0 0 0
12 0x2C 0 0 0 0
13 0x2D 0 0 0 0
14 0x2E 0 0 0 0
15 0x2F 0 0 0 0
16 0x34 0 0 0 0
17 0x35 0 0 0 0
18 0x31 0 0 0 0
120 0x30 0 0 0 0
121 0x32 0 0 539127 0
122 0x33 0 0 0 46
123 0x36 0 0 21117 0
124 0x37 0 1061 0 0
125 0x38 0 0 34354 0
252 0xF4 0 0 0 0
253 0xF2 0 0 0 0
254 0xF0 99624 55478 75017 72695
255 0xEF 4761444 2072151 2408597 2532948
ACRN:\>pt
VM TYPE IRQ VEC DEST TM PIN VPIN BDF VBDF
0 IOAPIC 0 0x20 0x0 edge 2 2 0:0.0 0:0.0
0 IOAPIC 9 0x29 0x0 level 9 9 0:0.0 0:0.0
0 IOAPIC 18 0x31 0x0 level 18 18 0:0.0 0:0.0
0 IOAPIC 15 0x2F 0x0 edge 15 15 0:0.0 0:0.0
0 IOAPIC 14 0x2E 0x0 level 14 14 0:0.0 0:0.0
0 IOAPIC 13 0x2D 0x0 edge 13 13 0:0.0 0:0.0
0 IOAPIC 12 0x2C 0x0 edge 12 12 0:0.0 0:0.0
0 IOAPIC 11 0x2B 0x0 edge 11 11 0:0.0 0:0.0
0 IOAPIC 10 0x2A 0x0 edge 10 10 0:0.0 0:0.0
0 IOAPIC 8 0x28 0x0 edge 8 8 0:0.0 0:0.0
0 IOAPIC 7 0x27 0x0 edge 7 7 0:0.0 0:0.0
0 IOAPIC 6 0x26 0x0 edge 6 6 0:0.0 0:0.0
0 IOAPIC 5 0x25 0x0 edge 5 5 0:0.0 0:0.0
0 IOAPIC 1 0x21 0x0 edge 1 1 0:0.0 0:0.0
0 MSI 121 0x32 0x2 edge 255 255 0:2.0 0:2.0
0 MSI 122 0x33 0x0 edge 255 255 0:16.0 0:16.0
0 IOAPIC 16 0x34 0x0 level 16 16 0:0.0 0:0.0
0 IOAPIC 17 0x35 0x0 level 17 17 0:0.0 0:0.0
0 MSI 123 0x36 0x0 edge 255 255 0:17.0 0:17.0
0 MSI 124 0x37 0x0 edge 255 255 0:14.0 0:14.0
0 MSI 125 0x38 0x0 edge 255 255 0:1f.6 0:1f.6
Best Regards,
Zide
toggle quoted message
Show quoted text
On 2/14/20 7:41 AM, Dubravko Moravski | Exor Embedded S.r.l. wrote: Hi Zide,
1) X2APIC
I see that it's not mentioned anywhere in ACRN log (and I suppose it should be), but it seems to be enabled somehow in non-hypervised Linux:
clear@clr-bcdcb0fadf6546d7b0984fe80030eee8~ $ sudo dmesg | grep -i x2apic
[ 0.165205] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.
[ 0.167422] DMAR-IR: Enabled IRQ remapping in x2apic mode
[ 0.167426] x2apic enabled
[ 0.167448] Switched APIC routing to cluster x2apic.
clear@clr-bcdcb0fadf6546d7b0984fe80030eee8~ $
Our BIOS does not have a GUI setting to manually enable it, and we couldn't find where to explicitly enable it in source code. It's mentioned at many places; though not in DMAR table.
Can we conclude from the log above that it's ok, or we still need to find a way to enable it in ACRN or BIOS?
2) Linux logs
I'm working on this and will report later.
By the way, I think my last logs might be inconsistent with earlier ones (with endless SIPI messages) because earlier I might have in a hurry just pressed enter in the boot menu to choose whichever option was selected, instead of selecting ACRN. Now I'm more careful.
Removing 'quiet' parameter didn't help.
3) Naked HV
... is working. With your previous acrn.efi and bzImage from around Wednesday noon Central European Time, after serial boot log stops, I can indeed switch to ACRN console with ctrl+space. If I switch back to SOS, nothing happens. I can only return back to ACRN console. Here are some printouts:
[13133696us][cpu=0][vm0:vcpu0][sev=3][seq=322]:vlapic: pcpu0 Sending SIPI to vcpu1, mode 500 icr_low c4500 sipi cnt 0
vcpu state 2
[13146659us][cpu=0][vm0:vcpu0][sev=3][seq=323]:vcpu1 paused, new state: 4
[13154097us][cpu=0][vm0:vcpu0][sev=3][seq=324]:vcpu1 reset
[13160078us][cpu=0][vm0:vcpu0][sev=3][seq=325]:vlapic: vlapic_reset 1693 vm0 vcpu1 initial lapic_id: 2000000
[13170960us][cpu=0][vm0:vcpu0][sev=3][seq=326]:vlapic: pcpu0 Sending SIPI to vcpu2, mode 500 icr_low c4500 sipi cnt 0
vcpu state 2
[13183985us][cpu=0][vm0:vcpu0][sev=3][seq=327]:vcpu2 paused, new state: 4
[13191429us][cpu=0][vm0:vcpu0][sev=3][seq=328]:vcpu2 reset
[13197408us][cpu=0][vm0:vcpu0][sev=3][seq=329]:vlapic: vlapic_reset 1693 vm0 vcpu2 initial lapic_id: 4000000
[13208295us][cpu=0][vm0:vcpu0][sev=3][seq=330]:vlapic: pcpu0 Sending SIPI to vcpu3, mode 500 icr_low c4500 sipi cnt 0
vcpu state 2
[13221324us][cpu=0][vm0:vcpu0][sev=3][seq=331]:vcpu3 paused, new state: 4
[13228769us][cpu=0][vm0:vcpu0][sev=3][seq=332]:vcpu3 reset
[13234748us][cpu=0][vm0:vcpu0][sev=3][seq=333]:vlapic: vlapic_reset 1693 vm0 vcpu3 initial lapic_id: 6000000
[13255651us][cpu=0][vm0:vcpu0][sev=3][seq=334]:vlapic: pcpu0 Sending SIPI to vcpu1, mode 600 icr_low c469f sipi cnt 1
vcpu state 1
[13268597us][cpu=0][vm0:vcpu0][sev=3][seq=335]:vlapic: Start Secondary VCPU1 for VM[0]...
[13277605us][cpu=0][vm0:vcpu0][sev=3][seq=336]:vcpu1 scheduled on pcpu1 vcpu->state 1
[13286228us][cpu=0][vm0:vcpu0][sev=3][seq=337]:vlapic: pcpu0 Sending SIPI to vcpu2, mode 600 icr_low c469f sipi cnt 1
vcpu state 1
[13299256us][cpu=0][vm0:vcpu0][sev=3][seq=338]:vlapic: Start Secondary VCPU2 for VM[0]...
[13308274us][cpu=0][vm0:vcpu0][sev=3][seq=339]:vcpu2 scheduled on pcpu2 vcpu->state 1
[13316902us][cpu=0][vm0:vcpu0][sev=3][seq=340]:vlapic: pcpu0 Sending SIPI to vcpu3, mode 600 icr_low c469f sipi cnt 1
vcpu state 1
[13329919us][cpu=0][vm0:vcpu0][sev=3][seq=341]:vlapic: Start Secondary VCPU3 for VM[0]...
[13338926us][cpu=0][vm0:vcpu0][sev=3][seq=342]:vcpu3 scheduled on pcpu3 vcpu->state 1
[13347768us][cpu=0][vm0:vcpu0][sev=3][seq=343]:vlapic: pcpu0 Sending SIPI to vcpu1, mode 600 icr_low c469f sipi cnt 0
vcpu state 2
[13360707us][cpu=0][vm0:vcpu0][sev=3][seq=344]:vlapic: pcpu0 Sending SIPI to vcpu2, mode 600 icr_low c469f sipi cnt 0
vcpu state 2
[13373751us][cpu=0][vm0:vcpu0][sev=3][seq=345]:vlapic: pcpu0 Sending SIPI to vcpu3, mode 600 icr_low c469f sipi cnt 0
vcpu state 2
/* ctrl+space */
---Entering ACRN SHELL---
ACRN:\>
ACRN:\>version
HV version 1.6-unstable-2020-02-11 15:28:54-4990d8574159 DBG (daily tag: acrn-2020w03.4-140000p) build by zide
API version 1.0
ACRN:\>vm_list
VM_UUID VM_ID VM_NAME VM_STATE
================================ ===== ================================ ========
dbbbd4347a574216a12c2201f1ab0240 0 ACRN SOS VM Started
ACRN:\>vcpu_list
VM ID PCPU ID VCPU ID VCPU ROLE VCPU STATE THREAD STATE
===== ======= ======= ========= ========== ==========
0 0 0 PRIMARY Running RUNNING
0 1 1 SECONDARY Running BLOCKED
0 2 2 SECONDARY Running BLOCKED
0 3 3 SECONDARY Running BLOCKED
ACRN:\>vioapic
Error: Invalid parameters.
ACRN:\>vioapic 0
PIN VEC DM DEST TM DELM IRR MASK
0 0x0 phys 0x0 edge 0 0 1
1 0x0 phys 0x0 edge 0 0 1
2 0x0 phys 0x0 edge 0 0 1
3 0x0 phys 0x0 edge 0 0 1
4 0x0 phys 0x0 edge 0 0 1
5 0x0 phys 0x0 edge 0 0 1
6 0x0 phys 0x0 edge 0 0 1
7 0x0 phys 0x0 edge 0 0 1
8 0x0 phys 0x0 edge 0 0 1
9 0x0 phys 0x0 edge 0 0 1
10 0x0 phys 0x0 edge 0 0 1
11 0x0 phys 0x0 edge 0 0 1
12 0x0 phys 0x0 edge 0 0 1
13 0x0 phys 0x0 edge 0 0 1
14 0x0 phys 0x0 edge 0 0 1
15 0x0 phys 0x0 edge 0 0 1
16 0x0 phys 0x0 edge 0 0 1
17 0x0 phys 0x0 edge 0 0 1
18 0x0 phys 0x0 edge 0 0 1
19 0x0 phys 0x0 edge 0 0 1
20 0x0 phys 0x0 edge 0 0 1
21 0x0 phys 0x0 edge 0 0 1
22 0x0 phys 0x0 edge 0 0 1
23 0x0 phys 0x0 edge 0 0 1
24 0x0 phys 0x0 edge 0 0 1
25 0x0 phys 0x0 edge 0 0 1
26 0x0 phys 0x0 edge 0 0 1
27 0x0 phys 0x0 edge 0 0 1
28 0x0 phys 0x0 edge 0 0 1
29 0x0 phys 0x0 edge 0 0 1
30 0x0 phys 0x0 edge 0 0 1
31 0x0 phys 0x0 edge 0 0 1
32 0x0 phys 0x0 edge 0 0 1
33 0x0 phys 0x0 edge 0 0 1
34 0x0 phys 0x0 edge 0 0 1
35 0x0 phys 0x0 edge 0 0 1
36 0x0 phys 0x0 edge 0 0 1
37 0x0 phys 0x0 edge 0 0 1
38 0x0 phys 0x0 edge 0 0 1
39 0x0 phys 0x0 edge 0 0 1
40 0x0 phys 0x0 edge 0 0 1
41 0x0 phys 0x0 edge 0 0 1
42 0x0 phys 0x0 edge 0 0 1
43 0x0 phys 0x0 edge 0 0 1
44 0x0 phys 0x0 edge 0 0 1
45 0x0 phys 0x0 edge 0 0 1
46 0x0 phys 0x0 edge 0 0 1
47 0x0 phys 0x0 edge 0 0 1
48 0x0 phys 0x0 edge 0 0 1
49 0x0 phys 0x0 edge 0 0 1
50 0x0 phys 0x0 edge 0 0 1
51 0x0 phys 0x0 edge 0 0 1
52 0x0 phys 0x0 edge 0 0 1
53 0x0 phys 0x0 edge 0 0 1
54 0x0 phys 0x0 edge 0 0 1
55 0x0 phys 0x0 edge 0 0 1
56 0x0 phys 0x0 edge 0 0 1
57 0x0 phys 0x0 edge 0 0 1
58 0x0 phys 0x0 edge 0 0 1
59 0x0 phys 0x0 edge 0 0 1
60 0x0 phys 0x0 edge 0 0 1
61 0x0 phys 0x0 edge 0 0 1
62 0x0 phys 0x0 edge 0 0 1
63 0x0 phys 0x0 edge 0 0 1
64 0x0 phys 0x0 edge 0 0 1
65 0x0 phys 0x0 edge 0 0 1
66 0x0 phys 0x0 edge 0 0 1
67 0x0 phys 0x0 edge 0 0 1
68 0x0 phys 0x0 edge 0 0 1
69 0x0 phys 0x0 edge 0 0 1
70 0x0 phys 0x0 edge 0 0 1
71 0x0 phys 0x0 edge 0 0 1
72 0x0 phys 0x0 edge 0 0 1
73 0x0 phys 0x0 edge 0 0 1
74 0x0 phys 0x0 edge 0 0 1
75 0x0 phys 0x0 edge 0 0 1
76 0x0 phys 0x0 edge 0 0 1
77 0x0 phys 0x0 edge 0 0 1
78 0x0 phys 0x0 edge 0 0 1
79 0x0 phys 0x0 edge 0 0 1
80 0x0 phys 0x0 edge 0 0 1
81 0x0 phys 0x0 edge 0 0 1
82 0x0 phys 0x0 edge 0 0 1
83 0x0 phys 0x0 edge 0 0 1
84 0x0 phys 0x0 edge 0 0 1
85 0x0 phys 0x0 edge 0 0 1
86 0x0 phys 0x0 edge 0 0 1
87 0x0 phys 0x0 edge 0 0 1
88 0x0 phys 0x0 edge 0 0 1
89 0x0 phys 0x0 edge 0 0 1
90 0x0 phys 0x0 edge 0 0 1
91 0x0 phys 0x0 edge 0 0 1
92 0x0 phys 0x0 edge 0 0 1
93 0x0 phys 0x0 edge 0 0 1
94 0x0 phys 0x0 edge 0 0 1
95 0x0 phys 0x0 edge 0 0 1
96 0x0 phys 0x0 edge 0 0 1
97 0x0 phys 0x0 edge 0 0 1
98 0x0 phys 0x0 edge 0 0 1
99 0x0 phys 0x0 edge 0 0 1
100 0x0 phys 0x0 edge 0 0 1
101 0x0 phys 0x0 edge 0 0 1
102 0x0 phys 0x0 edge 0 0 1
103 0x0 phys 0x0 edge 0 0 1
104 0x0 phys 0x0 edge 0 0 1
105 0x0 phys 0x0 edge 0 0 1
106 0x0 phys 0x0 edge 0 0 1
107 0x0 phys 0x0 edge 0 0 1
108 0x0 phys 0x0 edge 0 0 1
109 0x0 phys 0x0 edge 0 0 1
110 0x0 phys 0x0 edge 0 0 1
111 0x0 phys 0x0 edge 0 0 1
112 0x0 phys 0x0 edge 0 0 1
113 0x0 phys 0x0 edge 0 0 1
114 0x0 phys 0x0 edge 0 0 1
115 0x0 phys 0x0 edge 0 0 1
116 0x0 phys 0x0 edge 0 0 1
117 0x0 phys 0x0 edge 0 0 1
118 0x0 phys 0x0 edge 0 0 1
119 0x0 phys 0x0 edge 0 0 1
ACRN:\>
ACRN:\>
ACRN:\>
ACRN:\>
ACRN:\>vm_console 0
----- Entering VM 0 Shell -----
/* no reaction to any regular keys */
/* ctrl+space */
---Entering ACRN SHELL---
ACRN:\>
Thank you again, I would never get this far without help.
Best regards,
Dubravko
*Dubravko Moravski*
/SW engineering/
*Exor Embedded S.r.l.*
p: +38 512455659 <tel:+38 512455659> m:+38 5915402413 <tel:+38 5915402413>
a: Slavonska avenija, 50, Zagreb, Croatia, 10000
w: exorint.com <https://exorint.com/>
Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.
Privacy <https://www.exorint.com/it/privacy>
--------------------------------------------------------------------------------------------------------------------------
*From:* acrn-users@... <acrn-users@...> on behalf of Chen, Zide via Lists.Projectacrn.Org <zide.chen=intel.com@...>
*Sent:* Wednesday, February 12, 2020 9:04 PM
*To:* acrn-users@... <acrn-users@...>
*Subject:* Re: [acrn-users] Getting ACRN to work
Hi Dubravko,
1) Enable X2APIC from guest Linux
Actually ACRN checks X2APIC capability and it goes panic w/o it. So the host CPUID must have X2APIC support.
We met one case where the BIOS DMAR setting has some thing like "do not use x2apic", which prevents Linux from enabling
X2APIC. Or you may check why the guest doesn't switch to X2APIC from native Linux dmesg?
2) Need Linux logs to help debugging.
Attached is the ACRN built with the following hack, which directs guest serial prints directly to HV console.
Seems Linux goes to the path of numachip_wakeup_secondary() to send SIPIs to secondary CPUs, which we didn't see before.
It's good to see Linux early pintk t help address the issue.
diff --git a/hypervisor/dm/vuart.c b/hypervisor/dm/vuart.c
index 8771a7d8a15f..be5f0da943b8 100644
--- a/hypervisor/dm/vuart.c
+++ b/hypervisor/dm/vuart.c
@@ -295,6 +295,7 @@ static void write_reg(struct acrn_vuart *vu, uint16_t reg, uint8_t value_u8)
vu->lsr |= LSR_OE;
} else {
fifo_putchar(&vu->txfifo, (char)value_u8);
+ printf("%c", value_u8);
}
vu->thre_int_pending = true;
break;
3) "naked" HV is working?
In the meantime, if you want, you can hack ACRN with the following and it won't launch any VMs and the HV console is
supposed to be working. It's just a way to check that ACRN is "generally" working on the HW and you may play with some HV
console commands.
diff --git a/hypervisor/arch/x86/guest/vm.c b/hypervisor/arch/x86/guest/vm.c
index 0471324be065..53ccb6b9acae 100644
--- a/hypervisor/arch/x86/guest/vm.c
+++ b/hypervisor/arch/x86/guest/vm.c
@@ -873,6 +873,8 @@ void launch_vms(uint16_t pcpu_id)
uint16_t vm_id, bsp_id;
struct acrn_vm_config *vm_config;
+ return;
+
for (vm_id = 0U; vm_id < CONFIG_MAX_VM_NUM; vm_id++) {
vm_config = get_vm_config(vm_id);
if ((vm_config->load_order == SOS_VM) || (vm_config->load_order == PRE_LAUNCHED_VM)) {
Best Regards,
Zide
On 2/12/20 11:05 AM, Zide Chen wrote:
Hi Dubravko,
With my acrn.efi, it switches to guest console by default. Does it switch back to ACRN console by pressing "Ctrl + Space"?
The logs show that X2APIC is not enabled by Linux. Is it possible to enable X2APIC from BIOS?
Without X2APIC, ACRN doesn't work. Though I'm expecting ACRN should go beyond what it is now.
BTW, can you remove "quiet" from the Linux bootargs? This may not really help, but I'm puzzled why it doesn't print any
Linux logs.
From the logs, one big difference with my images (acrn.efi + bzImage) is that now it doesn't repeat the SIPI sequence
(INIT -> Start up -> INIT -> Start up) endless, instead, after launching 3 VCPUs, the guest sends broadcasting SIPI INIT
and Start Up only. This is a good news, but not sure that's because of the new acrn.efi, or the bzImage?
Best Regards,
Zide
On 2/12/20 10:36 AM, Dubravko Moravski | Exor Embedded S.r.l. wrote:
Hi Zide,
I've checked all the menus and settings in our BIOS, unfortunately I couldn't find anything that looks like the
mentioned setting or similar or related to it.
We are using coreboot, built according to instructions from https://software.intel.com/en-us/firmware/sites/default/files/intelatome3900-0.71-buildinstructions.txt, plus we added
support for our board (the link apparently no longer works). In general it works very well.
Best regards,
Dubravko
*Dubravko Moravski*
/SW engineering/
*Exor Embedded S.r.l.*
p: +38 512455659 <tel:+38 512455659> m:+38 5915402413 <tel:+38 5915402413>
a: Slavonska avenija, 50, Zagreb, Croatia, 10000
w: exorint.com <https://exorint.com/>
Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.
Privacy <https://www.exorint.com/it/privacy>
--------------------------------------------------------------------------------------------------------------------------
*From:* acrn-users@... <acrn-users@...> on behalf of Chen, Zide via
Lists.Projectacrn.Org <zide.chen=intel.com@...>
*Sent:* Wednesday, February 12, 2020 6:47 PM
*To:* acrn-users@... <acrn-users@...>
*Subject:* Re: [acrn-users] Getting ACRN to work
Hi Dubravko,
In the meantime, is there something like "AP Thread Idle Manner" in your BIOS? And changing its setting makes any
difference?
Best Regards,
Zide
On 2/12/20 8:02 AM, Dubravko Moravski | Exor Embedded S.r.l. wrote:
Hello,
Please find attached the log file and my acrn.conf.
My old BIOS didn't have any settings related to Mwait, so I've installed newer BIOS which has "Monitor Mwait Enable" and
I've ensured it's set to "Disabled". Changing the BIOS seems to have also changed some data in logs, but the overall
behavior is the same.
New acrn.efi seems to work reasonably well. Our custom board is obviously specific, but in general it is similar to
reference Leaf Hill CRB.
After the last printout from the log, everything stops working (there is nothing on the screen attached to the board and
the keyboard doesn't do anything; also typing in the serial terminal doesn't do anything).
Best regards,
Dubravko
*Dubravko Moravski*
/SW engineering/
*Exor Embedded S.r.l.*
p: +38 512455659 <tel:+38 512455659> m:+38 5915402413 <tel:+38 5915402413>
a: Slavonska avenija, 50, Zagreb, Croatia, 10000
w: exorint.com <https://exorint.com/>
Prima di stampare pensa ai costi ambientali. Please consider the environment before printing this email.
Privacy <https://www.exorint.com/it/privacy>
--------------------------------------------------------------------------------------------------------------------------
*From:* acrn-users@... <acrn-users@...> on behalf of Chen, Zide via
Lists.Projectacrn.Org <zide.chen=intel.com@...>
*Sent:* Wednesday, February 12, 2020 1:04 AM
*To:* acrn-users@... <acrn-users@...>
*Subject:* Re: [acrn-users] Getting ACRN to work
Hi Dubravko,
"Spurious vector" could because of external interrupts not registered in hypervisor. This may not be an issue and can be
ignored for now.
For the repeating "Starting VCPU 3" issue, it seems some thing related to SIPI delivery. But nothing is obvious to me and
need to debug it.
I built a Clear Linux kernel with additional logs showing how it's bringing up APs. Could you please try the attached
bzImage?
Also please enable early printk by adding "ignore_loglevel earlyprintk=serial,ttyS0,115200n8,keep" to the options in
acrn.conf; And use the attached acrn.efi (I enabled some additional logs and print out Linux logs even before ACRN console
is operational). If acrn.efi doesn't boot, which is highly possibly since it's not built against your custom board, you
may need to apply the attached patch to ACRN hypervisor.
Hopefully the full logs can give us some clues.
Best Regards,
Zide
zide.chen@...
|
