On 2018/3/27 16:52, Jan Beulich wrote:
On 27.03.18 at 06:52, wrote:
After reset, IBRS is disabled by processor, but a coming intr/nmi leave IBRS
enabled after their exit. It's not necessory for bootup code to run in low
performance with IBRS enabled.
On ORACLE
>>> On 27.03.18 at 13:03, wrote:
> On 2018/3/27 16:52, Jan Beulich wrote:
> On 27.03.18 at 06:52, wrote:
>>> --- a/xen/include/asm-x86/spec_ctrl.h
>>> +++ b/xen/include/asm-x86/spec_ctrl.h
>>> @@ -32,8 +32,22 @@ extern uint8_t
On 2018/3/27 16:52, Jan Beulich wrote:
On 27.03.18 at 06:52, wrote:
After reset, IBRS is disabled by processor, but a coming intr/nmi leave IBRS
enabled after their exit. It's not necessory for bootup code to run in low
performance with IBRS enabled.
On ORACLE
>>> On 27.03.18 at 06:52, wrote:
> After reset, IBRS is disabled by processor, but a coming intr/nmi leave IBRS
> enabled after their exit. It's not necessory for bootup code to run in low
> performance with IBRS enabled.
>
> On ORACLE X6-2(500GB/88 cpus, dom0 11GB/20
After reset, IBRS is disabled by processor, but a coming intr/nmi leave IBRS
enabled after their exit. It's not necessory for bootup code to run in low
performance with IBRS enabled.
On ORACLE X6-2(500GB/88 cpus, dom0 11GB/20 vcpus), we observed an 200s+ delay
in construct_dom0.
By initializing