The following set of patches add TPM and Trusted Computing support to SeaBIOS.
In particular the patches add:
- a TPM driver for the Qemu's TPM TIS emulation (not yet in Qemu git)
- ACPI support for the TPM device (SSDT table)
- ACPI support for measurement logging (TCPA table)
- Support for initialzation of the TPM
- Support for the TCG BIOS extensions (1ah handler [ah = 0xbb])
(used by trusted grub; http://trousers.sourceforge.net/grub.html)
- Static Root of Trusted for Measurement (SRTM) …
[View More]support
- Support for S3 resume (sends command to TPM upon resume)
- TPM-specific menu for controlling aspects of the TPM
- [An optional test suite for the TIS interface]
All implementations necessarily follow specifications.
When all patches are applied the following services are available
- SSDT ACPI table for TPM support
- initialization of the TPM upon VM start and S3 resume
- Static root of trust for measurements (SRTM) that measures (some) data
of SeaBIOS in TCPA ACPI table
- 1ah interrupt handler offering APIs for measuring and sending commands to
the TPM (trusted grub uses them)
- User menu for controlling aspects of the state of the TPM
v6:
- adapted patches to checkout of 8e30147 (Aug 9)
- use timeouts/durations for commands as reported by TPM
- following Andreas Niederl's suggestion regarding the ACPI SSDT
v5:
- adapted patches to checkout of 76b5e71 (June 21)
- bugfixes (see individual patches)
- added patch to support the transfer of Qemu-provided measurements via
firmware interface
v4:
- if ! has_working_tpm() now returns error code everywhere
- tis_test.c now also under LGPLv3
- in inthandler, pulled set_cf() out of switch and then only call it in
the default case where we need to indicate that a function is not
implemented
v3:
- some nits here and there
- calling timer_setup now after S3 resume
v2:
- following Kevin's comment
- refactoring code so that every patch compiles
Regards,
Stefan
[View Less]
Hello,
I have encountered a problem with the bootindex parameter for a KVM
guest that has two virtio-blk disks. Although I set bootindex=1 for
the second disk, the VM chooses rather randomly the disk it boots
from.
host CPU: AMD Phenom II X4 955 Processor
host OS (first): x86_64 debian-squeeze (kernel 2.6.38 amd64)
host OS (later): x86_64 debian-squeeze (kernel 3.0 amd64)
guest OS (both disks): e.g. x86_64 debian-squeeze (2.6.32 amd64)
This is how I invoke qemu
(most of the times tested …
[View More]with Debian squeeze images):
# /usr/bin/qemu-system-x86_64 \
-m 256 \
-name test4221 \
-uuid f5dc124f-cbf4-6220-8b6b-15c0662be798 \
-nodefconfig \
-nodefaults \
-drive file=/opt/dev/4223,if=none,id=mydrive0,format=raw \
-device
virtio-blk-pci,bus=pci.0,addr=0x7,drive=mydrive0,id=mydisk0,bootindex=2 \
-drive file=/opt/dev/4256,if=none,id=mydrive1,format=raw \
-device
virtio-blk-pci,bus=pci.0,addr=0x4,drive=mydrive1,id=mydisk1,bootindex=1 \
-vga cirrus
(both tested, with and without bootindex=2 for the first disk)
When both disks contain different OS images (Debian vs. Windows),
everything is fine. But when I try two disks with the same OS on
them, (no matter whether both are Debian or both are Windows), then
when
first starting the VM (by a call to qemu-system-x86_64) or
simply rebooting the VM again and again,
the disk that is booted from seems to be chosen rather randomly.
I had qemu-kvm 0.14.0 and seabios 0.6.2 on the host when the problem
was first encountered. Then I replaced seabios with the current
version compiled from the git repository. Finally I removed
qemu-kvm and seabios completely and did a "make install" with
qemu-kvm 0.15 from the git repository.
# qemu-system-x86_64 -version
QEMU emulator version 0.15.50 (qemu-kvm-devel), Copyright (c) \
2003-2008 Fabrice Bellard
When I was using seabios post-0.6.2 from the git repo, I set its
debug level to 5 and compared the debug output for the good and bad
cases and found no difference.
Am I missing something or did I stumble over a bug?
Any hint would be welcome,
Elmar
[View Less]
On Aug 9, 2011, at 5:13 AM, Avi Kivity wrote:
> On 08/08/2011 10:18 PM, John Paul Walters wrote:
>> On Jul 21, 2011, at 2:10 AM, Avi Kivity wrote:
>>
>> > On 07/21/2011 02:20 AM, John Paul Walters wrote:
>> >> Hi,
>> >>
>> >> We have a 256 core SGI Ultraviolet machine running RHEL 6.1 with qemu-kvm 0.13, and we'd like to be able to start large guest VMs of up to 256 cores. I see that x86 guests are currently limited to 64 VCPUs. …
[View More]Is there any reason for this hard limitation? It appears that we can't get around this limitation by simply redefining the kernel's KVM_MAX_VCPUS to 256. Qemu-kvm and possibly SeaBIOS seem to require changes as well. Can anyone offer any suggestions as to how straightforward it would be to increase the number of CPUs that we can allocate to KVM guests?
>> >>
>> >
>> > And here I am on record saying no one wants this...
>> >
>> > kvm.git has patches increasing the limit to 254 (256 is not possible due to the APIC ID being 8 bits and two IDs being reserved).
>> >
>> > Latest seabios appears to have no cpu limits; qemu is limited to 255.
>> >
>>
>>
>> Hi again,
>>
>> I've applied the 254 core patches (below) from kvm.git on a RHEL 6.1 kernel. The new modules build and insert fine.
>>
>> https://git.kernel.org/?p=virt/kvm/kvm.git;a=commit;h=052fa7f4c5e79262cffcd…
>> https://git.kernel.org/?p=virt/kvm/kvm.git;a=commit;h=29a07f8e31980599c586e…
>>
>> However, whenever I try to boot a system with more than 83 CPUs, the system fails to boot with:
>>
>> Booting from Hard Disk...
>> Boot failed: could not read the boot disk
>>
>> I'm using qemu-kvm.git with the following command line:
>> /opt/qemu.git/bin/qemu-system-x86_64 -smp 84 -hda big_image_2.qcow2 -m 8388 -redir tcp:52109::22
>>
>> Does anyone have any suggestions?
>>
>>
>
> Most likely a seabios failure. Suggest you enable debugging in seabios and see what's going on; also copy the seabios mailing list.
>
Hi Avi,
I've enabled debugging in seabios (#define DEBUG_BIOS) and get the output below. Note that with the help of folks in the KVM irc channel I'm able to start a 254 core instance using the KVM tool, so the problem seems to be limited to qemu/seabios.
best,
JP
jwalters@uv /tmp/qemu_test_jp $ /opt/qemu.git/bin/qemu-system-x86_64 -smp 84 -drive file=big_image_2.qcow2,if=virtio -m 8388
warning: subregion collision fffe0000/20000 vs 0/12c400000
VNC server running on `::1:5901'
Start bios (version pre-0.6.3-20110315_112143-titi)
Ram Size=0xe0000000 (0x000000012c400000 high)
Relocating init from 0x000e49d0 to 0xdffe1880 (size 58968)
CPU Mhz=2002
PCI: pci_bios_init_bus_rec bus = 0x0
PIIX3/PIIX4 init: elcr=00 0c
PCI: bus=0 devfn=0x00: vendor_id=0x8086 device_id=0x1237
PCI: bus=0 devfn=0x08: vendor_id=0x8086 device_id=0x7000
PCI: bus=0 devfn=0x09: vendor_id=0x8086 device_id=0x7010
region 4: 0x0000c000
PCI: bus=0 devfn=0x0b: vendor_id=0x8086 device_id=0x7113
PCI: bus=0 devfn=0x10: vendor_id=0x1013 device_id=0x00b8
region 0: 0xf0000000
region 1: 0xf2000000
region 6: 0xf2010000
PCI: bus=0 devfn=0x18: vendor_id=0x10ec device_id=0x8139
region 0: 0x0000c100
region 1: 0xf2020000
region 6: 0xf2030000
PCI: bus=0 devfn=0x20: vendor_id=0x1af4 device_id=0x1001
region 0: 0x0000c200
region 1: 0xf2040000
Found 84 cpu(s) max supported 84 cpu(s)
MP table addr=0x000fd4b0 MPC table addr=0x000fd4c0 size=1892
SMBIOS ptr=0x000fd490 table=0xdffff030
ACPI tables: RSDP=0x000fd460 RSDT=0xdfffa5c0
Scan for VGA option rom
Running option rom at c000:0003
VGABios $Id$
Turning on vga text mode console
SeaBIOS (version pre-0.6.3-20110315_112143-titi)
Found 1 lpt ports
Found 1 serial ports
ATA controller 0 at 1f0/3f4/0 (irq 14 dev 9)
ATA controller 1 at 170/374/0 (irq 15 dev 9)
found virtio-blk at 0:4
ebda moved from 9fc00 to 9dc00
WARNING - Unable to allocate resource at init_virtio_blk:107!
WARNING - Unable to allocate resource at init_atadrive:740!
PS2 keyboard initialized
All threads complete.
Scan for option roms
Running option rom at c900:0003
pmm call arg1=1
pmm call arg1=0
pmm call arg1=1
pmm call arg1=0
Searching bootorder for: /pci@i0cf8/*@3
Searching bootorder for: /rom(a)genroms/vapic.bin
Running option rom at ca00:0003
Returned 40960 bytes of ZoneHigh
e820 map has 8 items:
0: 0000000000000000 - 000000000009dc00 = 1
1: 000000000009dc00 - 00000000000a0000 = 2
2: 00000000000f0000 - 0000000000100000 = 2
3: 0000000000100000 - 00000000dfffa000 = 1
4: 00000000dfffa000 - 00000000e0000000 = 2
5: 00000000feffc000 - 00000000ff000000 = 2
6: 00000000fffc0000 - 0000000100000000 = 2
7: 0000000100000000 - 000000022c400000 = 1
enter handle_19:
NULL
Booting from ROM...
Booting from c900:0372
enter handle_18:
NULL
Booting from Hard Disk...
Boot failed: could not read the boot disk
enter handle_18:
NULL
Booting from Floppy...
Boot failed: could not read the boot disk
enter handle_18:
NULL
No bootable device.
> --
> error compiling committee.c: too many arguments to function
>
[View Less]
On Tue, Aug 9, 2011 at 1:26 PM, Marc Jones <marcj303(a)gmail.com> wrote:
> On Tue, Aug 9, 2011 at 2:54 AM, Bjørn Mork <bjorn(a)mork.no> wrote:
>> Kevin O'Connor <kevin(a)koconnor.net> writes:
>>> On Mon, Jul 11, 2011 at 09:20:27AM +0200, Gerd Hoffmann wrote:
>>>> Hi,
>>>>
>>>> Next (and hopefully final) version of the two-pass pci initialization
>>>> patches. Addressed review comments, fixed some …
[View More]bugs, especially the
>>>> io range setup for bridges.
>>>
>>> Thanks - I committed this series.
>>
>> Sorry for being this late into the game, but this patch series seems to
>> break (some?) network interfaces on older FreeBSD systems. Exactly why
>> is unclear to me. The following error message is received (multiple
>> times):
>>
>> Aug 9 08:03:05 frebsd44 /kernel: fxp0: device timeout
>>
>> and pinging or any other attempt to transmit packets will fail:
>>
>> frebsd44# ping 10.0.2.2
>> PING 10.0.2.2 (10.0.2.2): 56 data bytes
>> ^C
>> --- 10.0.2.2 ping statistics ---
>> 3 packets transmitted, 0 packets received, 100% packet loss
>>
>>
>>
>> I tested this with a clean install of FreeBSD 4.4-REL and a single Intel
>> 82559 interface. A gzipped qemu/kvm raw disk image with serial console
>> setup is available from http://huey.mork.no/fbsd44.raw.gz (66MB)
>>
>> Run it as e.g.
>>
>> qemu -hda fbsd44.raw -net nic,model=i82559er -net user \
>> -serial mon:stdio -monitor null -nographic \
>> -bios bios-image-under-test.bin
>>
>> and login as root with no password. It has a single fxp0 configured
>> with 10.0.2.1/24 matching the qemu "user" network defaults, so pinging
>> 10.0.2.2 should work when running with above cmdline.
>>
>>
>> Bisecting shows that
>>
>> 01a5c8813b2e709809c07c5d7fab9d1c3ddb4989 is the first bad commit
>> commit 01a5c8813b2e709809c07c5d7fab9d1c3ddb4989
>> Author: Gerd Hoffmann <kraxel(a)redhat.com>
>> Date: Mon Jul 11 09:20:29 2011 +0200
>>
>> pci: activate two-pass pci initialization code
>>
>> This patch actually enables the two-pass pci initialization and
>> deactivates the old pci initialization bits.
>>
>> Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com>
>>
>> :040000 040000 07d0e9f2b470932f0682683fb3b979b321db866b cd181630a3892ebbd54b54a1ccd91eb38c24e88c M src
>>
>>
>> I've also verified that checking out commit 82b39b2 works OK, and that
>> reverting these 4 commits on top of current HEAD also results in a
>> working image:
>>
>> 77b8536 pci: set BUILD_PCIMEM_START to 0xe0000000
>> 60a348b pci: cleanup config.h
>> 3bbd11f pci: remove old pci initilaization code
>> 01a5c88 pci: activate two-pass pci initialization code
>>
>>
>> Please let me know if there is something else I should test.
>>
>>
>>
>> Bjørn
>
> Hi Bjørn,
>
> Can you see if there are differences in the PCI cfg registers between
> the versions? Use lspci -vxxx, or something similar.
>
> Marc
>
Ignore that... I see Gerd addressed it in another email.
Marc
--
http://se-eng.com
[View Less]
Hi,
Here comes a bumnch of fixes for the ahci code, see the individual
patches for details.
cheers,
Gerd
Gerd Hoffmann (5):
ahci/cdrom: shared bounce buffer
ahci: probe each port in its own thread
ahci: ignore atapi devices which are not cdroms
ahci: move device registration
ahci: use malloc_tmp memory for probing ports
src/ahci.c | 94 ++++++++++++++++++++++++++++++++---------------------------
src/ahci.h | 2 +
src/block.c | 14 +++++++++
src/cdrom.c | 10 ++----
…
[View More]src/disk.h | 2 +
5 files changed, 73 insertions(+), 49 deletions(-)
[View Less]
On Fri, Aug 05, 2011 at 04:59:44PM -0600, Marc Jones wrote:
> On Thu, Aug 4, 2011 at 7:19 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
> > On Thu, Aug 04, 2011 at 02:10:10PM -0500, Anthony Liguori wrote:
> >> On 08/04/2011 01:49 PM, Gerd Hoffmann wrote:
> >> >Hi,
> >> >
> >> >A bunch of new stuff has been added to master since the last version,
> >> >time to release a new one? Especially I'd like to see qemu get a …
[View More]seabios
> >> >update, and anthony prefers a release instead of a git snapshot for that.
> >>
> >> What's left in order to enable CONFIG_AHCI by default too? I'd
> >> really prefer not to carry a custom config for QEMU if it's
> >> possible.
> >
> > I'm okay with defaulting AHCI on. The 32bit trampolining could
> > theoretically be a problem, but there have been no trouble reports to
> > date.
> >
> >> Maybe this is a good time to coordinate a release around the next
> >> QEMU release too. I'm guessing that October would be a pretty good
> >> time to freeze on a new SeaBIOS so if there was an October release,
> >> that would work very well for us.
> >
> > I'm okay with that. We could probably arrange a release even sooner.
>
> I think that AHCI on would be good. What about ATA DMA and ATA 32bit PIO?
ATA DMA needs to be enhanced to use a white list. It's fine for SATA
controllers - where DMA is easy. However, on parallel ATA
controllers, correct DMA setup is more complicated and requires
controller specific code.
ATA 32bit PIO is not very useful. The performance gain is marginal,
and I have had reports of failures with it enabled. So, I wouldn't
recommend enabling it.
-Kevin
[View Less]
On Fri, Aug 05, 2011 at 04:59:44PM -0600, Marc Jones wrote:
> On Thu, Aug 4, 2011 at 7:19 PM, Kevin O'Connor <kevin(a)koconnor.net> wrote:
> > On Thu, Aug 04, 2011 at 02:10:10PM -0500, Anthony Liguori wrote:
> >> On 08/04/2011 01:49 PM, Gerd Hoffmann wrote:
> >> >Hi,
> >> >
> >> >A bunch of new stuff has been added to master since the last version,
> >> >time to release a new one? Especially I'd like to see qemu get a …
[View More]seabios
> >> >update, and anthony prefers a release instead of a git snapshot for that.
> >>
> >> What's left in order to enable CONFIG_AHCI by default too? I'd
> >> really prefer not to carry a custom config for QEMU if it's
> >> possible.
> >
> > I'm okay with defaulting AHCI on. The 32bit trampolining could
> > theoretically be a problem, but there have been no trouble reports to
> > date.
> >
> >> Maybe this is a good time to coordinate a release around the next
> >> QEMU release too. I'm guessing that October would be a pretty good
> >> time to freeze on a new SeaBIOS so if there was an October release,
> >> that would work very well for us.
> >
> > I'm okay with that. We could probably arrange a release even sooner.
>
> I think that AHCI on would be good. What about ATA DMA and ATA 32bit PIO?
ATA DMA caused me a bit of pain this morning, it didn't want to work.
32-bit PIO is probably mostly-safe these days.
Jonathan Kollasch
[View Less]