As an update, I successfully rolled back my BIOS to an earlier
version. With this change, tboot works again! GETSEC[SENTER] executes
with no errors and I get into the secure state. So it is definitely
some problem relating to the new BIOS.
Interestingly, I dumped the DMAR tables created by the wor
Hi
Sounds like some interesting tests. I wonder if the BIOS could have
locked the memory somehow after it is initialized - should be easy to
test :)
I agree that the "Register Base Address" in the DRHD is the register
base for the DMA hardware itself. Hence it wouldn't equal the BAR
reported by P
Hi Martin, thanks for those links. I've attached the output of lspci
-v when my system is booted with USB disabled. Here is an excerpt, the
only ones that have addresses listed:
00:02.0 VGA compatible controller: Intel Corporation 82Q35 Express
Integrated Graphics Controller (rev 02)
Subsy
Hello Hal
For a bit more on the PCI BAR, see this:
http://docs.sun.com/app/docs/doc/819-3196/6n5ed4hmv?a=view
Every PCI device has these registers that give the base address/range
of its registers. It seems these ranges don't match those in DMAR. It
makes sense SINIT would/could check this.
Bes
>From Googling, it seems BAR is a general PCI concept. The VT-d spec
mentions it in "8.3.6 Implications with Provisioning PCI BAR
Resources" (just next to the DRHD section) but doesn't give an obvious
clue to this error message (seems to be more of a recommendation).
Could it be that the register
I did another experiment, disabling USB and also audio in BIOS, and
trying tboot. It hung again in GETSEC[SENTER] as before. Upon
restarting it, it dumped the error code register, which was different
this time: Progress 0ah, error 6. That is:
"BARs in VT-d DMAR DRHD struct mismatch"
I am attachin
Well except DRHD #4 has the INCLUDE_ALL = yes which IIRC means it is the
catch-all for devices not explicitly reporting under another DRHD. So "Device:
0x1d Function: 0x07" would be under the scope of this DRHD.
Thanks
Ross
-Original Message-
From: Martin Thiim [mailto:mar...@thiim.net]
Hello Ross
Right, I had not noticed the utility operated at the ACPI-level; I
only jumped into the thread when I saw Hal's question on how to detect
if the BIOS actually had enabled VT-d. Based on the ACPI tables the
answer is a "yes" :-)
I think I may have found the error in the tables though! I
