On 02/14/2018 01:39 PM, Kevin O'Connor wrote:
On Tue, Feb 13, 2018 at 03:29:20PM -0500, Stefan Berger wrote:
[...]
In these 0x400 bytes we have 256 bytes that are used for configuration flags
describing the supported opcode as you previously described. This array
allows us to decouple the firmwa
On Tue, Feb 13, 2018 at 03:29:20PM -0500, Stefan Berger wrote:
[...]
> In these 0x400 bytes we have 256 bytes that are used for configuration flags
> describing the supported opcode as you previously described. This array
> allows us to decouple the firmware implementation from the ACPI code and we
On 02/13/2018 04:04 PM, Laszlo Ersek wrote:
On 02/13/18 21:29, Stefan Berger wrote:
On 02/13/2018 02:59 PM, Laszlo Ersek wrote:
On 02/13/18 20:37, Kevin O'Connor wrote:
On Tue, Feb 13, 2018 at 05:16:49PM +0100, Laszlo Ersek wrote:
On 02/12/18 21:49, Stefan Berger wrote:
On 02/12/2018 03:46 P
On 02/13/18 21:29, Stefan Berger wrote:
> On 02/13/2018 02:59 PM, Laszlo Ersek wrote:
>> On 02/13/18 20:37, Kevin O'Connor wrote:
>>> On Tue, Feb 13, 2018 at 05:16:49PM +0100, Laszlo Ersek wrote:
On 02/12/18 21:49, Stefan Berger wrote:
> On 02/12/2018 03:46 PM, Kevin O'Connor wrote:
>>
On 02/13/2018 02:59 PM, Laszlo Ersek wrote:
On 02/13/18 20:37, Kevin O'Connor wrote:
On Tue, Feb 13, 2018 at 05:16:49PM +0100, Laszlo Ersek wrote:
On 02/12/18 21:49, Stefan Berger wrote:
On 02/12/2018 03:46 PM, Kevin O'Connor wrote:
I'm not sure I fully understand the goals of the PPI interfa
On 02/13/18 20:37, Kevin O'Connor wrote:
> On Tue, Feb 13, 2018 at 05:16:49PM +0100, Laszlo Ersek wrote:
>> On 02/12/18 21:49, Stefan Berger wrote:
>>> On 02/12/2018 03:46 PM, Kevin O'Connor wrote:
I'm not sure I fully understand the goals of the PPI interface.
Here's what I understand so
On Tue, Feb 13, 2018 at 05:16:49PM +0100, Laszlo Ersek wrote:
> On 02/12/18 21:49, Stefan Berger wrote:
> > On 02/12/2018 03:46 PM, Kevin O'Connor wrote:
> >> I'm not sure I fully understand the goals of the PPI interface.
> >> Here's what I understand so far:
> >>
> >> The TPM specs define some ac
On 02/13/18 17:34, Igor Mammedov wrote:
> On Tue, 13 Feb 2018 17:16:49 +0100
> Laszlo Ersek wrote:
>
> [...]
>>
>> It's possible that I'll scream for additional hw enlightement under OVMF
>> later; so I suggest designing in some kind of feature negotiation up-front.
> We can add an extra fwcfg fi
On 02/13/18 17:19, Igor Mammedov wrote:
> On Tue, 13 Feb 2018 16:39:01 +0100
> Laszlo Ersek wrote:
>
>> On 02/13/18 15:17, Igor Mammedov wrote:
>>> On Tue, 13 Feb 2018 14:31:41 +0100
>>> Laszlo Ersek wrote:
>>>
On 02/13/18 13:57, Igor Mammedov wrote:
> On Mon, 12 Feb 2018 15:17:21
On Tue, 13 Feb 2018 17:16:49 +0100
Laszlo Ersek wrote:
[...]
>
> It's possible that I'll scream for additional hw enlightement under OVMF
> later; so I suggest designing in some kind of feature negotiation up-front.
We can add an extra fwcfg file for that later, when/if it's actually needed.
[.
On Tue, 13 Feb 2018 16:39:01 +0100
Laszlo Ersek wrote:
> On 02/13/18 15:17, Igor Mammedov wrote:
> > On Tue, 13 Feb 2018 14:31:41 +0100
> > Laszlo Ersek wrote:
> >
> >> On 02/13/18 13:57, Igor Mammedov wrote:
> >>> On Mon, 12 Feb 2018 15:17:21 -0500
> >>> Stefan Berger wrote:
> >>>
>
On 02/12/18 21:49, Stefan Berger wrote:
> On 02/12/2018 03:46 PM, Kevin O'Connor wrote:
>> On Fri, Feb 09, 2018 at 03:19:31PM -0500, Stefan Berger wrote:
>>> The PPI device in this patch series allocates 0x400 bytes. 0x200
>>> bytes are
>>> used by the OperationRegion() in this patch series. The re
On 02/13/18 15:17, Igor Mammedov wrote:
> On Tue, 13 Feb 2018 14:31:41 +0100
> Laszlo Ersek wrote:
>
>> On 02/13/18 13:57, Igor Mammedov wrote:
>>> On Mon, 12 Feb 2018 15:17:21 -0500
>>> Stefan Berger wrote:
>>>
On 02/12/2018 02:45 PM, Kevin O'Connor wrote:
> On Fri, Feb 09, 2018 a
On Tue, 13 Feb 2018 14:31:41 +0100
Laszlo Ersek wrote:
> On 02/13/18 13:57, Igor Mammedov wrote:
> > On Mon, 12 Feb 2018 15:17:21 -0500
> > Stefan Berger wrote:
> >
> >> On 02/12/2018 02:45 PM, Kevin O'Connor wrote:
> >>> On Fri, Feb 09, 2018 at 03:19:31PM -0500, Stefan Berger wrote:
>
On 02/13/18 13:57, Igor Mammedov wrote:
> On Mon, 12 Feb 2018 15:17:21 -0500
> Stefan Berger wrote:
>
>> On 02/12/2018 02:45 PM, Kevin O'Connor wrote:
>>> On Fri, Feb 09, 2018 at 03:19:31PM -0500, Stefan Berger wrote:
I have played around with this patch and some modifications to EDK2. Tho
On Mon, 12 Feb 2018 15:17:21 -0500
Stefan Berger wrote:
> On 02/12/2018 02:45 PM, Kevin O'Connor wrote:
> > On Fri, Feb 09, 2018 at 03:19:31PM -0500, Stefan Berger wrote:
> >> I have played around with this patch and some modifications to EDK2. Though
> >> for EDK2 the question is whether to tr
On Mon, 12 Feb 2018 13:45:17 -0500
Stefan Berger wrote:
> On 02/12/2018 12:52 PM, Igor Mammedov wrote:
> > On Mon, 12 Feb 2018 11:44:16 -0500
> > Stefan Berger wrote:
> >
> >> On 02/12/2018 09:27 AM, Igor Mammedov wrote:
> >>> On Fri, 9 Feb 2018 15:19:31 -0500
> >>> Stefan Berger wrote:
> >
On 02/12/2018 03:46 PM, Kevin O'Connor wrote:
On Fri, Feb 09, 2018 at 03:19:31PM -0500, Stefan Berger wrote:
The PPI device in this patch series allocates 0x400 bytes. 0x200 bytes are
used by the OperationRegion() in this patch series. The rest was thought of
for future extensions.
To allow bot
On Fri, Feb 09, 2018 at 03:19:31PM -0500, Stefan Berger wrote:
> The PPI device in this patch series allocates 0x400 bytes. 0x200 bytes are
> used by the OperationRegion() in this patch series. The rest was thought of
> for future extensions.
>
> To allow both firmwares to use PPI, we would need to
On 02/12/2018 02:45 PM, Kevin O'Connor wrote:
On Fri, Feb 09, 2018 at 03:19:31PM -0500, Stefan Berger wrote:
I have played around with this patch and some modifications to EDK2. Though
for EDK2 the question is whether to try to circumvent their current
implementation that uses SMM or use SMM. Wi
On Fri, Feb 09, 2018 at 03:19:31PM -0500, Stefan Berger wrote:
> I have played around with this patch and some modifications to EDK2. Though
> for EDK2 the question is whether to try to circumvent their current
> implementation that uses SMM or use SMM. With this patch so far I circumvent
> it, whi
On 02/12/2018 12:52 PM, Igor Mammedov wrote:
On Mon, 12 Feb 2018 11:44:16 -0500
Stefan Berger wrote:
On 02/12/2018 09:27 AM, Igor Mammedov wrote:
On Fri, 9 Feb 2018 15:19:31 -0500
Stefan Berger wrote:
On 01/16/2018 10:51 AM, Stefan Berger wrote:
The TPM Physical Presence interface consi
On Mon, 12 Feb 2018 11:44:16 -0500
Stefan Berger wrote:
> On 02/12/2018 09:27 AM, Igor Mammedov wrote:
> > On Fri, 9 Feb 2018 15:19:31 -0500
> > Stefan Berger wrote:
> >
> >> On 01/16/2018 10:51 AM, Stefan Berger wrote:
> >>> The TPM Physical Presence interface consists of an ACPI part, a sh
On 02/12/2018 09:27 AM, Igor Mammedov wrote:
On Fri, 9 Feb 2018 15:19:31 -0500
Stefan Berger wrote:
On 01/16/2018 10:51 AM, Stefan Berger wrote:
The TPM Physical Presence interface consists of an ACPI part, a shared
memory part, and code in the firmware. Users can send messages to the
firmwar
On Fri, 9 Feb 2018 15:19:31 -0500
Stefan Berger wrote:
> On 01/16/2018 10:51 AM, Stefan Berger wrote:
> > The TPM Physical Presence interface consists of an ACPI part, a shared
> > memory part, and code in the firmware. Users can send messages to the
> > firmware by writing a code into the shared
On 01/16/2018 10:51 AM, Stefan Berger wrote:
The TPM Physical Presence interface consists of an ACPI part, a shared
memory part, and code in the firmware. Users can send messages to the
firmware by writing a code into the shared memory through invoking the
ACPI code. When a reboot happens, the fi
The TPM Physical Presence interface consists of an ACPI part, a shared
memory part, and code in the firmware. Users can send messages to the
firmware by writing a code into the shared memory through invoking the
ACPI code. When a reboot happens, the firmware looks for the code and
acts on it by sen
27 matches
Mail list logo
