On 13/10/2015 15:26, Laszlo Ersek wrote:
>>//
>> + // The write to the control register is synchronous and only affects the
>> + // current CPU, so bring in the APs first. The SMI handler expects that
>> + // all APs will rendez-vous within one PcdCpuSmmApSyncTimeout (though it
>> + //
On 10/14/15 13:37, Paolo Bonzini wrote:
> On 13/10/2015 15:26, Laszlo Ersek wrote:
>>>//
>>> + // The write to the control register is synchronous and only affects the
>>> + // current CPU, so bring in the APs first. The SMI handler expects that
>>> + // all APs will rendez-vous within one
On 09/10/2015 23:58, Laszlo Ersek wrote:
> diff --git a/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c
> b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c
> new file mode 100644
> index 000..e895fd6
> --- /dev/null
> +++ b/OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.c
> @@ -0,0 +1,365 @@
> +/** @file
> +
> + A
On 13/10/2015 15:26, Laszlo Ersek wrote:
> On the other hand, I don't know if Quark is a UP vs. MP system to begin
> with.
Quark is UP only. It's so UP that it triggers an erratum if you use
lock-prefixed instructions. :)
> Either the EFI_SMM_CONTROL2_PROTOCOL.Trigger()
> spec is incomplete
On 10/13/15 15:38, Paolo Bonzini wrote:
>
>
> On 13/10/2015 15:26, Laszlo Ersek wrote:
>> On the other hand, I don't know if Quark is a UP vs. MP system to begin
>> with.
>
> Quark is UP only. It's so UP that it triggers an erratum if you use
> lock-prefixed instructions. :)
>
>> Either the
On 13/10/2015 15:43, Laszlo Ersek wrote:
> I'll squash your fix into the next version, with many thanks. :) It's
> our platform after all, and we can do in OvmfPkg whatever needs to be
> done on it. :)
Indeed. Though, since the OVMF SmmCpuFeaturesLib will not require
configuring the MTRRs on
On 13/10/2015 18:35, Brian J. Johnson wrote:
>
> Traditionally, SMI handling has been global. If the h/w didn't
> broadcast the SMI to all CPUs, the SMI handler did so itself. The BSP
> would wait for all APs to "check in" to SMM, then it would do whatever
> work the SMI required, and signal
On 13/10/2015 18:49, Laszlo Ersek wrote:
>> >
>> > However, this (obviously) doesn't scale well, so Intel has been moving
>> > towards signaling SMI to only a single processor, and avoiding the
>> > machine-wide rendezvous when it isn't necessary. BIOS implementations
>> > may be lagging
On 10/13/15 18:53, Paolo Bonzini wrote:
>
>
> On 13/10/2015 18:49, Laszlo Ersek wrote:
However, this (obviously) doesn't scale well, so Intel has been moving
towards signaling SMI to only a single processor, and avoiding the
machine-wide rendezvous when it isn't necessary.
.org] On Behalf Of Laszlo
Ersek
Sent: Tuesday, October 13, 2015 10:03 AM
To: Paolo Bonzini <pbonz...@redhat.com>; Brian J. Johnson <bjohn...@sgi.com>;
edk2-de...@ml01.01.org
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Jiewen Yao
<jiewen@intel.com>
Subject: Re
On 10/13/15 18:35, Brian J. Johnson wrote:
> On 10/13/2015 08:26 AM, Laszlo Ersek wrote:
>>
>> First of all, if the edk2 reference code (in the SMM core and in
>> PiSmmCpuDxeSmm) depends on such behavior justifiedly, then I think we
>> have a bug in the PI specification. Namely, version 1.4
On 10/13/2015 08:26 AM, Laszlo Ersek wrote:
First of all, if the edk2 reference code (in the SMM core and in
PiSmmCpuDxeSmm) depends on such behavior justifiedly, then I think we
have a bug in the PI specification. Namely, version 1.4 thereof does not
seem to require that
> On Oct 13, 2015, at 9:35 AM, Brian J. Johnson wrote:
>
> On 10/13/2015 08:26 AM, Laszlo Ersek wrote:
>>
>> First of all, if the edk2 reference code (in the SMM core and in
>> PiSmmCpuDxeSmm) depends on such behavior justifiedly, then I think we
>> have a bug in the PI
On 10/13/2015 11:49 AM, Laszlo Ersek wrote:
On 10/13/15 18:35, Brian J. Johnson wrote:
On 10/13/2015 08:26 AM, Laszlo Ersek wrote:
First of all, if the edk2 reference code (in the SMM core and in
PiSmmCpuDxeSmm) depends on such behavior justifiedly, then I think we
have a bug in the PI
14 matches
Mail list logo