Why does ACRN need to be told how much RAM the system has? Surely it
can probe PLATFORM_RAM_SIZE? Then maybe default SOS_RAM_SIZE to 0
(meaning 'all of the RAM') and so on.

Ross

Hi Ross:
This is a tradeoff between flexibility and functionality certification. In server virtualization, YES, we want one binary for all platforms with flexible configuration at run time -- this is a must to have features. But, in IOT, usually the image is released with particular platform with particular usage, and people usually build the image per the product. The more important thing is functional safety certification (FuSa) & real time requirement, which is the fundamental feature of ACRN. FuSa requires it to not use dynamic allocation policy to avoid the potential possible failure of allocation -- this is why ACRN is removing all of the "malloc" like code, and this is why we must pre-identify the size of buffer used in the VMM. For this purpose, we need to know the MAX RAM size at compile time to statically allocate memory for EPT for example.
There are other considerations in ACRN for Real time usage too. This is why we tradeoff between the flexibility and the FuSa/RT.

Thx Eddie

On Feb 14, 2019, at 5:44 PM, Eddie Dong <eddie.dong@...> wrote:

Hi Ross:
This is a tradeoff between flexibility and functionality certification. In server virtualization, YES, we want one binary for all platforms with flexible configuration at run time -- this is a must to have features. But, in IOT, usually the image is released with particular platform with particular usage, and people usually build the image per the product. The more important thing is functional safety certification (FuSa) & real time requirement, which is the fundamental feature of ACRN. FuSa requires it to not use dynamic allocation policy to avoid the potential possible failure of allocation -- this is why ACRN is removing all of the "malloc" like code, and this is why we must pre-identify the size of buffer used in the VMM. For this purpose, we need to know the MAX RAM size at compile time to statically allocate memory for EPT for example.

The fact that a KBL NUC 32GB system will simply hang at the EFI shell or the Intel NUC splash screen is really undesirable for our customers. We need to find a way to handle this gracefully. It is acceptable to have a strict configuration (for FuSA requirements). It is not acceptable to simply hang with no feedback to the user.

Regards,

—Tim

There are other considerations in ACRN for Real time usage too. This is why we tradeoff between the flexibility and the FuSa/RT.

Thx Eddie

-----Original Message-----
From: acrn-users@...
[mailto:acrn-users@...] On Behalf Of Ross Burton
Sent: Friday, February 15, 2019 9:07 AM
To: acrn-users@...
Subject: [acrn-users] RAM configuration

Why does ACRN need to be told how much RAM the system has? Surely it
can probe PLATFORM_RAM_SIZE? Then maybe default SOS_RAM_SIZE to 0
(meaning 'all of the RAM') and so on.

Ross

Hi Tim,
For "NUC splash screen" issue, can you submit a bug and attach log? We'll follow up to try to fix the bug.


Best regards.
Hongbo
Tel: +86-21-6116 7445
MP: +86-1364 1793 689
Mail: hongbo.wang@...

On Feb 19, 2019, at 12:55 AM, Wang, Hongbo <hongbo.wang@...> wrote:

Hi Tim,
For "NUC splash screen" issue, can you submit a bug and attach log? We'll follow up to try to fix the bug.

I have no logs to attach and no way that I know of to get one (this unit has no serial port). It never gets out of EFI. Not sure I could get logs out of EFI with a serial port anyway?

I am open to suggestions.

Best regards.
Hongbo
Tel: +86-21-6116 7445
MP: +86-1364 1793 689
Mail: hongbo.wang@...

-----Original Message-----
From: acrn-users@... [mailto:acrn-users@...]
On Behalf Of Tim Orling
Sent: Tuesday, February 19, 2019 2:12 PM
To: acrn-users@...
Cc: Dong, Eddie <eddie.dong@...>
Subject: Re: [acrn-users] RAM configuration

On Feb 14, 2019, at 5:44 PM, Eddie Dong <eddie.dong@...> wrote:

Hi Ross:
This is a tradeoff between flexibility and functionality certification. In server

virtualization, YES, we want one binary for all platforms with flexible
configuration at run time -- this is a must to have features. But, in IOT, usually the
image is released with particular platform with particular usage, and people
usually build the image per the product. The more important thing is functional
safety certification (FuSa) & real time requirement, which is the fundamental
feature of ACRN. FuSa requires it to not use dynamic allocation policy to avoid
the potential possible failure of allocation -- this is why ACRN is removing all of
the "malloc" like code, and this is why we must pre-identify the size of buffer
used in the VMM. For this purpose, we need to know the MAX RAM size at
compile time to statically allocate memory for EPT for example.

The fact that a KBL NUC 32GB system will simply hang at the EFI shell or the Intel
NUC splash screen is really undesirable for our customers. We need to find a way
to handle this gracefully. It is acceptable to have a strict configuration (for FuSA
requirements). It is not acceptable to simply hang with no feedback to the user.

Regards,

—Tim

There are other considerations in ACRN for Real time usage too. This is why

we tradeoff between the flexibility and the FuSa/RT.

Thx Eddie

-----Original Message-----
From: acrn-users@...
[mailto:acrn-users@...] On Behalf Of Ross Burton
Sent: Friday, February 15, 2019 9:07 AM
To: acrn-users@...
Subject: [acrn-users] RAM configuration

Why does ACRN need to be told how much RAM the system has? Surely it
can probe PLATFORM_RAM_SIZE? Then maybe default SOS_RAM_SIZE to 0
(meaning 'all of the RAM') and so on.

Ross