On Fri, 16 Sep 2022 15:45:38 -0400
"Jason Andryuk" wrote:
CCing Stefan as he is probably the best person to talk about qemu
impl. of TPM
> Hi,
>
> I've noticed an issue with the TPM2 EventLog. OVMF exposes the TPM
> Event Log via EFI and ACPI, but they have different addresses. The
> EFI one
On Mon, 12 Sep 2022 13:17:45 +0800
aryeh.c...@intel.com wrote:
> From: Aryeh Chen
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4057
>
> According to ASL Coding Guidelines - Device Identifiers
> "A Device should contain either an _ADR or a _HID object, never both."
> , so remove _ADR
On Tue, 8 Oct 2019 23:12:10 +0200
Laszlo Ersek wrote:
> On 10/08/19 17:06, Igor Mammedov wrote:
> > On Tue, 8 Oct 2019 13:27:14 +0200
> > Laszlo Ersek wrote:
> >
> >> MaxCpuCountInitialization() currently handles the following options:
> >>
> >
InMicroSeconds is
> irrelevant.
What for max cpu count is/will be used?
>
> This patch is a pre-requisite for enabling CPU hotplug with SMM_REQUIRE.
> As a side effect, it also enables S3 to work with CPU hotplug at once,
> *without* SMM_REQUIRE.
Does OVMF reread boot CPU count on r
On Tue, 1 Oct 2019 17:31:17 +0200
"Laszlo Ersek" wrote:
> On 09/27/19 13:35, Igor Mammedov wrote:
> > On Tue, 24 Sep 2019 13:34:55 +0200
> > "Laszlo Ersek" wrote:
>
> >> Going forward, if I understand correctly, the plan is to populate the
>
On Tue, 1 Oct 2019 20:03:20 +0200
"Laszlo Ersek" wrote:
> On 09/30/19 16:22, Yao, Jiewen wrote:
> >
> >> -Original Message-
> >> From: devel@edk2.groups.io On Behalf Of Igor
> >> Mammedov
> >> Sent: Monday, September 30, 2019 8
On Mon, 30 Sep 2019 13:51:46 +0200
"Laszlo Ersek" wrote:
> Hi Igor,
>
> On 09/24/19 13:19, Igor Mammedov wrote:
> > On Mon, 23 Sep 2019 20:35:02 +0200
> > "Laszlo Ersek" wrote:
>
> >> I've got good results. For this (1/2) QEMU patch:
the SMI handler in
> the locked SMRAM at the default SMBASE. At RSM, it may continue at the
> vector requested in the INIT-SIPI-SIPI.
Firmware can arbitrate/send INIT-SIPI-SIPI to hotplugged CPUs.
Enumerating hotplugged CPUs, can be done by reusing CPU hotplug
interface described at QEMU/docs/specs/ac
On Mon, 23 Sep 2019 20:35:02 +0200
"Laszlo Ersek" wrote:
> On 09/20/19 11:28, Laszlo Ersek wrote:
> > On 09/20/19 10:28, Igor Mammedov wrote:
> >> On Thu, 19 Sep 2019 19:02:07 +0200
> >> "Laszlo Ersek" wrote:
> >>
> >>>
On Thu, 19 Sep 2019 19:02:07 +0200
"Laszlo Ersek" wrote:
> Hi Igor,
>
> (+Brijesh)
>
> long-ish pondering ahead, with a question at the end.
[...]
> Finally: can you please remind me why we lock down 128KB (32 pages) at
> 0x3_, and not just half of that? What do we need the range at
> [0x4
On Wed, 11 Sep 2019 19:30:46 +0200
"Laszlo Ersek" wrote:
> On 09/10/19 17:58, Igor Mammedov wrote:
> > On Mon, 9 Sep 2019 21:15:44 +0200
> > Laszlo Ersek wrote:
>
> [...]
>
> > It looks like fwcfg smi feature negotiation isn't reusable in this c
test lockable SMRAM at default SMBASE feature introduced by
commit "q35: implement 128K SMRAM at default SMBASE address"
Signed-off-by: Igor Mammedov
---
tests/q35-test.c | 105 +++
1 file changed, 105 insertions(+)
diff --git a/tests/q3
: boris.ostrov...@oracle.com
CC: r...@edk2.groups.io
CC: joao.m.mart...@oracle.com
CC: ler...@redhat.com
Igor Mammedov (2):
q35: implement 128K SMRAM at default SMBASE address
tests: q35: MCH: add default SMBASE SMRAM lock test
include/hw/pci-host/q35.h | 10
hw/i386/pc.c
context. In non-SMM context, reads return
0xff and writes are ignored. Further writes into the register are
ignored until the system reset.
*) https://www.mail-archive.com/qemu-devel@nongnu.org/msg455991.html
Signed-off-by: Igor Mammedov
---
include/hw/pci-host/q35.h | 10 +
hw/i386
On Mon, 9 Sep 2019 21:15:44 +0200
Laszlo Ersek wrote:
> Hi Igor,
>
> On 09/05/19 17:49, Igor Mammedov wrote:
> > lpc already has SMI negotiation feature, extend it by adding
> > optin ICH9_LPC_SMI_F_LOCKED_SMBASE_BIT to supported features.
> >
> > Writing
quot; and set if supported set
it in "etc/smi/requested-features"
3. read "etc/smi/features-ok", if returned value is 1
negotiated at step 2 features are activated successfully.
Signed-off-by: Igor Mammedov
---
include/hw/i386/ich9.h | 11 ++--
hw/i386/pc.c
On Thu, 5 Sep 2019 15:08:31 +0200
Laszlo Ersek wrote:
> On 09/04/19 11:52, Igor Mammedov wrote:
>
> > it could be stolen RAM + black hole like TSEG, assuming fw can live
> > without RAM(0x3+128K) range
> > (in this case fwcfg interface would only work fo
On Tue, 3 Sep 2019 19:20:25 +0200
Laszlo Ersek wrote:
> On 09/03/19 16:53, Igor Mammedov wrote:
> > On Mon, 2 Sep 2019 21:09:58 +0200
> > Laszlo Ersek wrote:
> >
> >> On 09/02/19 10:45, Igor Mammedov wrote:
> >>> On Fri, 30 Aug 201
On Mon, 2 Sep 2019 21:09:58 +0200
Laszlo Ersek wrote:
> On 09/02/19 10:45, Igor Mammedov wrote:
> > On Fri, 30 Aug 2019 20:46:14 +0200
> > Laszlo Ersek wrote:
> >
> >> On 08/30/19 16:48, Igor Mammedov wrote:
> >>
> >>> (01) On boot f
On Fri, 30 Aug 2019 20:46:14 +0200
Laszlo Ersek wrote:
> On 08/30/19 16:48, Igor Mammedov wrote:
>
> > (01) On boot firmware maps and initializes SMI handler at default SMBASE
> > (3)
> > (using dedicated SMRAM at 3 would allow us to avoid save/restore
>
On Thu, 29 Aug 2019 18:25:17 +0200
Laszlo Ersek wrote:
> On 08/28/19 14:01, Igor Mammedov wrote:
> > On Tue, 27 Aug 2019 22:11:15 +0200
> > Laszlo Ersek wrote:
> >
> >> On 08/27/19 18:23, Igor Mammedov wrote:
> >>> On Mon, 26 Aug 2019 17:30:43 +0200
On Thu, 29 Aug 2019 19:01:35 +0200
Laszlo Ersek wrote:
> On 08/27/19 20:31, Igor Mammedov wrote:
> > On Sat, 24 Aug 2019 01:48:09 +
> > "Yao, Jiewen" wrote:
>
> >> (05) Host CPU: (OS) Port 0xB2 write, all CPUs enter SMM (NOTE: New CPU
> >>
On Tue, 27 Aug 2019 22:11:15 +0200
Laszlo Ersek wrote:
> On 08/27/19 18:23, Igor Mammedov wrote:
> > On Mon, 26 Aug 2019 17:30:43 +0200
> > Laszlo Ersek wrote:
> >
> >> On 08/23/19 17:25, Kinney, Michael D wrote:
> >>> Hi Jiewen,
> >>>
&
o: Yao, Jiewen ; Paolo Bonzini
> > ; Laszlo Ersek ;
> > r...@edk2.groups.io; Kinney, Michael D
> > Cc: Alex Williamson ; devel@edk2.groups.io;
> > qemu devel list ; Igor Mammedov
> > ; Chen, Yingwen ;
> > Nakajima, Jun ; Boris Ostrovsky
> > ; Joao Marcal Le
On Mon, 26 Aug 2019 17:30:43 +0200
Laszlo Ersek wrote:
> On 08/23/19 17:25, Kinney, Michael D wrote:
> > Hi Jiewen,
> >
> > If a hot add CPU needs to run any code before the
> > first SMI, I would recommend is only executes code
> > from a write protected FLASH range without a stack
> > and then
On Fri, 16 Aug 2019 18:43:11 -0400
Boris Ostrovsky wrote:
> On 8/16/19 7:24 AM, Igor Mammedov wrote:
> > for purpose of demo SMRAM (at 0x3) is aliased at a in system
> > address space
> > for easy initialization of SMI entry point.
> > Here is resulting debug
est to run:
qemu-system-x86_64 -M q35 -bios /path_to_seabios/out/bios.bin \
-nodefaults \
-chardev stdio,id=seabios -device isa-debugcon,iobase=0x402,chardev=seabios
Signed-off-by: Igor Mammedov
---
include/hw/pci-host/q35.h | 1 +
hw/pci-host/q35.c | 10 ++
2 files c
smm_relocate: SMRAM codeentry f000c831eac88c
smm_relocate: SMRAM cpu.i64.smm_base a
Patch depends on QEMU POC patch that adds SMRAM at 0x3 in SMM address space
PS:
configure bios with level 9 debugging and debug port
Signed-off-by: Igor Mammedov
---
src/fw/smm.c | 43
It's just a quick hack together with Seabios to show
that normal RAM at 0x3 is not affected by SMM relocation
and dedicated SMRAM could be used for relocation without need to
care about untrusted RAM content at 0x3.
CC: "Chen, Yingwen"
CC: edk2-devel-groups-io
CC: Phillip Goerl
CC:
On Thu, 15 Aug 2019 18:24:53 +0200
Paolo Bonzini wrote:
> On 15/08/19 18:07, Igor Mammedov wrote:
> > Looking at Q35 code and Seabios SMM relocation as example, if I see it
> > right QEMU has:
> > - SMRAM is aliased from DRAM at 0xa
> > - and TSEG steals f
On Thu, 15 Aug 2019 17:00:16 +0200
Laszlo Ersek wrote:
> On 08/14/19 16:04, Paolo Bonzini wrote:
> > On 14/08/19 15:20, Yao, Jiewen wrote:
> >>> - Does this part require a new branch somewhere in the OVMF SEC code?
> >>> How do we determine whether the CPU executing SEC is BSP or
> >>> hot-pl
On Wed, 14 Aug 2019 16:04:50 +0200
Paolo Bonzini wrote:
> On 14/08/19 15:20, Yao, Jiewen wrote:
> >> - Does this part require a new branch somewhere in the OVMF SEC code?
> >> How do we determine whether the CPU executing SEC is BSP or
> >> hot-plugged AP?
> > [Jiewen] I think this is blocked
32 matches
Mail list logo
