Hi Dubravko,

If you see endless vmexit messages, it's possibly that you have successfully loaded the guest kernel.

You may remove the vmexit logs by configuring CONFIG_CONSOLE_LOGLEVEL_DEFAULT to any number < 6.

Build it with "RELEASE=1" disables the hypervisor serial console so you won't be able to see anything. So it's discouraged
to do that during bring-up.

I'm expecting you can see the console prompt: "ACRN:\>", and you can try some basic commands like "help", "vm_list",
"vcpu_list", etc. If you find any guest VM is running from "vm_list" command, you can switch to the guest console by
"vm_console 0", and switch back to HV console by pressing "Ctrl + Space".

https://projectacrn.github.io/latest/tutorials/debug.html?highlight=console

If you don't see any VM running, you may following this tutorial (of cause you can try other scenario):
https://projectacrn.github.io/latest/tutorials/kbl-nuc-sdc.html

The key point is at the end you need to install a clear Linux bzImage and acrn.efi (sample:
misc/efi-stub/clearlinux/acrn.conf) in the EFI partition, and the "Linux" line in acrn.efi points to the bzImage you
installed.


Best Regards,
Zide


On 2/10/20 10:39 AM, Dubravko Moravski | Exor Embedded S.r.l. wrote:
> Hi Zide,
>
> You were right again, I don't know how it happened but my MAX_PCPU_NUM was set to 3, while there are 4 CPUs.
>
> MADT and DMAR tables seem to be correct.
> I'm using acrn.efi, RELOC is enabled.
>
> Now the hypervisor seems to be almost working... The initialization seems to complete fine, then I'm getting a huge number
> of printouts like these:
>
>     [836682306us][cpu=0][vm0:vcpu0][sev=6][seq=31854]:Exit Reason: 0x0000000000000001
>     [836722306us][cpu=0][vm0:vcpu0][sev=6][seq=31855]:Exit Reason: 0x0000000000000001
>     [836762306us][cpu=0][vm0:vcpu0][sev=6][seq=31856]:Exit Reason: 0x0000000000000001
>     [836802306us][cpu=0][vm0:vcpu0][sev=6][seq=31857]:Exit Reason: 0x0000000000000001
>
> They continue indefinitely. As far as I can tell, there are no errors (unless these indicate some errors), but also
> nothing else happens, just these printouts.
>
> RELEASE=1 build doesn't display the above printouts, but also nothing seems to happen.
>
> I think I might not have configured loading of the next stage (Linux loader) correctly, so it's possible that ACRN just
> doesn't have anything to do. The tutorials aren't quite clear regarding doing that, for new custom boards. Though if
> that's the problem, I would expect at least some warning message to be displayed. I'll check that first anyway.
>
> Thank you and 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:* Monday, February 10, 2020 5:50 PM
> *To:* acrn-users@... <acrn-users@...>
> *Subject:* Re: [acrn-users] Getting ACRN to work
> Hi Dubravko,
>
> Did you boot ACRN from acrn.efi (UEFI) or acrn.bin (SBL), or acrn.32.out (Grub)? RELOC is enabled for acrn.efi, but not
> others.
>
> For the init_percpu_lapic_init() issue, it's highly possibly that the user defined MAX_PCPU_NUM is less than the physical
> CPU number from ACPI table.
>
> Other than that, probably you need to debug the parse_madt() and see if it can't find MADT table or corrupted MADT so that
> it finds 0 pcpus.
>
> BTW, you can pull this PR to your code which may help your bring-up since it enables early panic() and other pr_err()
> messages.
> https://github.com/projectacrn/acrn-hypervisor/pull/4381
>
> Best Regards,
> Zide
>
>
>