Meeting Archive: https://drive.google.com/drive/u/2/folders/1_XTGu6re3BOQAjtPx636Mz1T5lOy2UWC Location Online conference link: https://zoom.us/j/880368975 Zoom Meeting ID: 880-368-975 If Dial in: +1

Hi, Joe, Thanks for the update, we will also check from our end. Thanks & Best Regards, Jason Chen SSG -> OTC -> Intel Auto Hypervisor Team

Hi Jason, Eventually I found out the culprit: After removing CONFIG_SERIAL_8250_PNP=y from kernel_config_uefi_sos I have the expected behavior. Thanks, Joe

On Mon, Oct 29, 2018 at 08:26 PM, Chen, Jason CJ wrote: Your information make me a little confuse, if we enabled irq auto detection, either the port could detect the real irq as 6, or the port could

From: acrn-users@... [mailto:acrn-users@...]On Behalf Of joebovin@... Sent: Tuesday, October 30, 2018 10:58 AM To: acrn-users@... Subject: Re: [acrn-users] ACRN hypervisor message: VMX ctrl 0x48b not

On Mon, Oct 29, 2018 at 06:46 PM, Chen, Jason CJ wrote: After change vuart irq from 4 to 6, the SOS kernel config need enable CONFIG_SERIAL_8250_DETECT_IRQ,Hi Jason, Thanks for your reply. Of course I

Hi, Joe, After change vuart irq from 4 to 6, the SOS kernel config need enable CONFIG_SERIAL_8250_DETECT_IRQ, otherwise, the ttyS0 will work under polling mode and slowly… Thanks & Best

Thanks a lot for the feedback! We’ll check it and try your suggestion, then reply this email thread later. Best regards. Hongbo Tel: +86-21-6116 7445 MP: +86-1364 1793

Hi Geoffroy & list, Any news on this? On my side the issue is related to the uart being very slow. SystemD messages appears very slowly through the uart. After bisecting a bunch of commit I eventually

Hi Geoffroy & list, Same issue here but with an Intel NUC NUC7i5DNHE. After reading ACRN code, it looks like it means there's not support for VMX_PROCBASED_CTLS2_VAPIC_REGS. Is that true? What are the

Meeting Minutes Archive: https://drive.google.com/drive/u/2/folders/111m6iU3PjSZebOOKzLagYPUWMvseGLeU ACRN Project TCM - 24th October 2018 Location Online conference link:

@Geoffroy Just confirmed, it is a bug. The vmexit info buffer handling just check the buffer size at the beginning. It need check each time when add info into it. I'll fix

I'll check that, it could be a bug for the command :(

Thanks for the confirmation. I will see if I can find a different HW to test with. I have tried a few more times on the NUC7i7DNHE and it consistently get stuck... here is what I

Hi folks, When booting ACRN on my KBL NUC (NUC7i7DNHE), I see the following messages on the console: ACRN Hypervisor calibrate_tsc, tsc_khz=2100000 [12273476us][cpu=0][sev=2][seq=9]:HV version

Normally, you're in the HV console after you input command "vmexit", you can still input other commands. On MRB it work well, just checked.

I am talking about the 'vmexit' command you can use from the hypervisor console (it's listed here: https://projectacrn.github.io/latest/user-guides/acrn-shell.html). When I used it, it printed out a

I think you're talking different things. Vmexit command in "hypervisor console" is used to show the info/count which cause vmexit; it is used for debug. Not sure if it is included in our doc. After

That depends on how you trigger vm-exit. Basically, VMM needs to advance the GIP to mark the end of execution of the guest instruction. Thx Eddie