TPM 2.0 with SeaBIOS
by Piotr Kubaj
Hi,
I use SeaBIOS 1.11.2 as payload with 4.8-835-g113f670baa on ASUS KGPE-D16 board. I also have ASUS TPM-L R2.0 module with Infineon SLB9665 chip.
TPM is correctly detected by both Linux and FreeBSD. It's also detected by coreboot in debug console. But SeaBIOS doesn't cooperate with it - there's no TPM menu.
In serial console, I get:
TCGBIOS: Detected a TPM 1.2.
rsdp=0x000f1930
rsdt=0xbf4b9030
table(41504354)=0xbf4bf460
TCGBIOS: Starting with TPM_Startup(ST_CLEAR)
Return from tpm_simple_cmd(99, 1) = 1e
TCGBIOS: TPM malfunctioning (line 874).
Return from tpm_simple_cmd(73, 0) = 1e
Note that SeaBIOS detects it as TPM 1.2, even though it's TPM 2.0.
--
_________________________________________
/ I find this corpse guilty of carrying a \
| concealed weapon and I fine it $40. |
| |
| -- Judge Roy Bean, finding a pistol and |
| $40 on a man he'd |
| |
\ just shot. /
-----------------------------------------
\ ^__^
\ (oo)\_______
(__)\ )\/\
||----w |
|| ||
5 months, 2 weeks
Re: [SeaBIOS] Marvell 88SE9230 passthrough in KVM takes long time to boot
by Kevin O'Connor
On Sun, Jul 29, 2018 at 01:49:10PM +0200, Konrad Eisele wrote:
> I'm passing through a Marvell 88SE9230 card to a KVM guest under
> Ubuntu 18.04. The card is a Sata controller with 4 ports.
> The option rom of the Marvell 88SE9230 card shows on a normal boot a
> bios screen. When pressing CTRL-m quick enough, you can interrupt the
> bootprocess and enter a menue wherer you can define raid
> arrays.
>
> When booting seabios inside KVM the bootprocess is very slow.
> There is a 1 min holdtime where the cpu is about 30%. The screen is
> black with only the seabios version string shown. I suspect that
> the passed-through Marvell 88SE9230 cards option roms causes this
> behaviour.
> Maybe the scanning for option rom cause the slow bootprocess?
>
> In the seabios boot case no bios menue is shown, after
> around 1 min the boot continues.
>
> Is it possible to disable the options rom processing? Is there some
> documentation about this (How can I configure it for Ubuntu) ?
The list of runtime SeaBIOS settings is at:
https://www.seabios.org/Runtime_config
You could try playing with the etc/pci-optionrom-exec setting.
See QEMU's -fw_cfg command line option. You'll need to pass in a
binary integer zero or binary integer one to control that setting.
-Kevin
5 months, 3 weeks
Marvell 88SE9230 passthrough in KVM takes long time to boot
by Konrad Eisele
I'm passing through a Marvell 88SE9230 card to a KVM guest under
Ubuntu 18.04. The card is a Sata controller with 4 ports.
The option rom of the Marvell 88SE9230 card shows on a normal boot a
bios screen. When pressing CTRL-m quick enough, you can interrupt the
bootprocess and enter a menue wherer you can define raid
arrays.
When booting seabios inside KVM the bootprocess is very slow.
There is a 1 min holdtime where the cpu is about 30%. The screen is
black with only the seabios version string shown. I suspect that
the passed-through Marvell 88SE9230 cards option roms causes this
behaviour.
Maybe the scanning for option rom cause the slow bootprocess?
In the seabios boot case no bios menue is shown, after
around 1 min the boot continues.
Is it possible to disable the options rom processing? Is there some
documentation about this (How can I configure it for Ubuntu) ?
// Greetings Konrad
5 months, 3 weeks
Re: [SeaBIOS] Seabios issue
by Paul Menzel
Dear Lucien,
Am 23.07.2018 um 08:06 schrieb Lucien Jheng:
> If we have some issue about SeaBIOS, do we need to open a ticket or
> just use email?
Please use this mailing list. Use a descriptive subject and include all
necessary information like version, log files and the configuration.
Note, that there is no guarantee to get an answer or that your problem
will be solved.
For that to happen, you need to be support from your distribution and
use the distribution channels, like the Red Hat bug tracker [1] for Red
Hat, to get it fixed. (Not to mention, that your company and you should
somehow spend money on free software nevertheless, if you use it, so
that the developers can afford a living and work on the project.)
Kind regards,
Paul
[1]: https://bugzilla.redhat.com/
5 months, 4 weeks
Seabios issue
by Lucien Jheng
Hi SeaBIOS expert
If we have some issue about SeaBIOS, do we need to open a ticket or just use email?
Thanks you.
Best regards,
LITEON Corp.
SLA/NA
SW
鄭祥鈞Lucien Jheng
Office:+886-2-87982888#5233
Fax:+886-2-8793-6887
11492台北市內湖區瑞光路392號10樓
10F, No.392, Ruiguang Rd.
Neihu Dist., Taipei City 11492
Taiwan
Confidential Information:This message is sent to the intended recipient and may contain privileged or confidential information. If you received this transmission in error, please notify the sender with a replying e-mail and delete the message and any attachment.Transmission Caveat and Virus Alert: Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions.
5 months, 4 weeks
hotplug failure issue on pci-bridge
by Liu, Jing2
Hi,
Recently, we tried some hotplug issues. The case is: when hotplug a
device (e.g. iGPU) onto pci-bridge after guest booting up, guest reports
"BAR 2: no space for [mem size 0x40000000 64bit pref]" etc.
Seabios checks all the devices under the pci-bridge when qemu launching
the guest, and only allocates "size=ALIGN(sum, align)" of memory space
for pci-bridge mem and pref-mem windows. So if we hotplug a big pci
device like Intel GPU which needs 256M mem/pref-mem or bigger, it will
fail.
If my understanding is right, we may need some other logic of the memory
allocation in seabios?
Looking forward to the advice.
Thanks,
Jing
6 months
seabios fails to build with current IASL
by Vivia Nikolaidou
Hi,
Thanks for taking action on this bug that I reported.
This is a follow-up from
https://mail.coreboot.org/pipermail/seabios/2018-July/012353.html - I
just subscribed to the mailing list and I don't have an easy way to
reply to that email directly.
On Mon, Jul 02, 2018 at 09:10:34AM +0200, Gerd Hoffmann wrote:
>
> If you don't want use the prebuilt tables I think the sane options are
> (a) use a older iasl compiler, or (b) flip ACPI_DSDT to "n" and drop
> support for qemu 1.3 + older.
Since (a) isn't an option in Debian, I tried going for (b) (did it
directly in debian/rules when generating .config, without adding a patch
for it). It still failed to compile without the patch that truncates the
Table ID in the DefinitionBlock. Removing the prebuilt tables before
compilation also didn't work, as they are used quite extensively in
acpi.c. I'm not sure I haven't misunderstood something here, but when
you say that flipping ACPI_DSDT to "n" would make it not use the
prebuilt tables, what exactly do you mean?
That said, would the combination of the truncating patch + flipping
ACPI_DSDT to "n" be an acceptable solution to fix the build in Debian?
Best regards,
Vivia
6 months, 1 week
[PATCH] virtio-blk/scsi: enable multi-queues support when starting device
by Changpeng Liu
QEMU will not start all the queues since commit fb20fbb76
"vhost: avoid to start/stop virtqueue which is not read",
because seabios only use one queue when starting, this will
not work for some vhost slave targets which expect the exact
number of queues defined in virtio-pci configuration space,
while here, we also enable those queues in the BIOS phase.
Signed-off-by: Changpeng Liu <changpeng.liu(a)intel.com>
---
src/hw/virtio-blk.c | 26 +++++++++++++++++++-------
src/hw/virtio-ring.h | 1 +
src/hw/virtio-scsi.c | 28 +++++++++++++++++++---------
3 files changed, 39 insertions(+), 16 deletions(-)
diff --git a/src/hw/virtio-blk.c b/src/hw/virtio-blk.c
index 88d7e54..79638ec 100644
--- a/src/hw/virtio-blk.c
+++ b/src/hw/virtio-blk.c
@@ -25,7 +25,7 @@
struct virtiodrive_s {
struct drive_s drive;
- struct vring_virtqueue *vq;
+ struct vring_virtqueue *vq[MAX_NUM_QUEUES];
struct vp_device vp;
};
@@ -34,7 +34,7 @@ virtio_blk_op(struct disk_op_s *op, int write)
{
struct virtiodrive_s *vdrive =
container_of(op->drive_fl, struct virtiodrive_s, drive);
- struct vring_virtqueue *vq = vdrive->vq;
+ struct vring_virtqueue *vq = vdrive->vq[0];
struct virtio_blk_outhdr hdr = {
.type = write ? VIRTIO_BLK_T_OUT : VIRTIO_BLK_T_IN,
.ioprio = 0,
@@ -96,6 +96,7 @@ virtio_blk_process_op(struct disk_op_s *op)
static void
init_virtio_blk(void *data)
{
+ u32 i, num_queues = 1;
struct pci_device *pci = data;
u8 status = VIRTIO_CONFIG_S_ACKNOWLEDGE | VIRTIO_CONFIG_S_DRIVER;
dprintf(1, "found virtio-blk at %pP\n", pci);
@@ -109,10 +110,6 @@ init_virtio_blk(void *data)
vdrive->drive.cntl_id = pci->bdf;
vp_init_simple(&vdrive->vp, pci);
- if (vp_find_vq(&vdrive->vp, 0, &vdrive->vq) < 0 ) {
- dprintf(1, "fail to find vq for virtio-blk %pP\n", pci);
- goto fail;
- }
if (vdrive->vp.use_modern) {
struct vp_device *vp = &vdrive->vp;
@@ -156,6 +153,11 @@ init_virtio_blk(void *data)
vp_read(&vp->device, struct virtio_blk_config, heads);
vdrive->drive.pchs.sector =
vp_read(&vp->device, struct virtio_blk_config, sectors);
+
+ num_queues = vp_read(&vp->common, virtio_pci_common_cfg, num_queues);
+ if (num_queues < 1 || num_queues > MAX_NUM_QUEUES) {
+ num_queues = 1;
+ }
} else {
struct virtio_blk_config cfg;
vp_get_legacy(&vdrive->vp, 0, &cfg, sizeof(cfg));
@@ -178,6 +180,13 @@ init_virtio_blk(void *data)
vdrive->drive.pchs.sector = cfg.sectors;
}
+ for (i = 0; i < num_queues; i++) {
+ if (vp_find_vq(&vdrive->vp, i, &vdrive->vq[i]) < 0 ) {
+ dprintf(1, "fail to find vq %u for virtio-blk %pP\n", i, pci);
+ goto fail_vq;
+ }
+ }
+
char *desc = znprintf(MAXDESCSIZE, "Virtio disk PCI:%pP", pci);
boot_add_hd(&vdrive->drive, desc, bootprio_find_pci_device(pci));
@@ -185,9 +194,12 @@ init_virtio_blk(void *data)
vp_set_status(&vdrive->vp, status);
return;
+fail_vq:
+ for (i = 0; i < num_queues; i++) {
+ free(vdrive->vq[i]);
+ }
fail:
vp_reset(&vdrive->vp);
- free(vdrive->vq);
free(vdrive);
}
diff --git a/src/hw/virtio-ring.h b/src/hw/virtio-ring.h
index 8604a01..3c8a2d1 100644
--- a/src/hw/virtio-ring.h
+++ b/src/hw/virtio-ring.h
@@ -21,6 +21,7 @@
#define VIRTIO_F_IOMMU_PLATFORM 33
#define MAX_QUEUE_NUM (128)
+#define MAX_NUM_QUEUES (128)
#define VRING_DESC_F_NEXT 1
#define VRING_DESC_F_WRITE 2
diff --git a/src/hw/virtio-scsi.c b/src/hw/virtio-scsi.c
index a87cad8..d08643f 100644
--- a/src/hw/virtio-scsi.c
+++ b/src/hw/virtio-scsi.c
@@ -148,9 +148,10 @@ virtio_scsi_scan_target(struct pci_device *pci, struct vp_device *vp,
static void
init_virtio_scsi(void *data)
{
+ u32 i, num_queues = 3;
struct pci_device *pci = data;
dprintf(1, "found virtio-scsi at %pP\n", pci);
- struct vring_virtqueue *vq = NULL;
+ struct vring_virtqueue *vq[MAX_NUM_QUEUES];
struct vp_device *vp = malloc_high(sizeof(*vp));
if (!vp) {
warn_noalloc();
@@ -175,29 +176,38 @@ init_virtio_scsi(void *data)
dprintf(1, "device didn't accept features: %pP\n", pci);
goto fail;
}
+
+ num_queues = vp_read(&vp->common, virtio_pci_common_cfg, num_queues);
+ if (num_queues < 3 || num_queues > MAX_NUM_QUEUES) {
+ num_queues = 3;
+ }
}
- if (vp_find_vq(vp, 2, &vq) < 0 ) {
- dprintf(1, "fail to find vq for virtio-scsi %pP\n", pci);
- goto fail;
+ for (i = 0; i < num_queues; i++) {
+ if (vp_find_vq(vp, i, &vq[i]) < 0 ) {
+ dprintf(1, "fail to find vq %u for virtio-scsi %pP\n", i, pci);
+ goto fail;
+ }
}
status |= VIRTIO_CONFIG_S_DRIVER_OK;
vp_set_status(vp, status);
- int i, tot;
+ int tot;
for (tot = 0, i = 0; i < 256; i++)
- tot += virtio_scsi_scan_target(pci, vp, vq, i);
+ tot += virtio_scsi_scan_target(pci, vp, vq[2], i);
if (!tot)
- goto fail;
+ goto fail_vq;
return;
-
+fail_vq:
+ for (i = 0; i < num_queues; i++) {
+ free(vq[i]);
+ }
fail:
vp_reset(vp);
free(vp);
- free(vq);
}
void
--
1.9.3
6 months, 1 week
