Re: [SeaBIOS] KVM call agenda for 2013-05-28
Hi, Raised that QOM interface should be sufficient. Agree on this one. Ideally the acpi table generation code should be able to gather all information it needs from the qom tree, so it can be a standalone C file instead of being scattered over all qemu. Ack. So my basic argument is why not expose the QOM interfaces to firmware and move the generation code there? Seems like it would be more or less a copy/paste once we had a proper implementation in QEMU. Well, no. Firmware is a quite simple environment without standard libc etc, so moving code from qemu to firmware certainly isn't as easy as copying over a file. There were discussions on potentially introducing a middle component to generate the tables. Coreboot was raised as a possibility, and David thought it would be okay to use coreboot for both OVMF and SeaBIOS. Certainly an option, but that is a long-term project. Out of curiousity, are there other benefits to using coreboot as a core firmware in QEMU? Short-term it's alot of work as we have to bring coreboot's qemu support to feature parity with seabios. I suspect most of this is acpi related though, so when qemu provides the tables and coreboot uses them we could be pretty close already. Long-term it should simplify firmware maintainance as we have only *one* place which handles the hardware bringup, and seabios/ovmf have less work to do. Is there a payload we would ever plausibly use besides OVMF and SeaBIOS? I wouldn't be surprised if people start using other coreboot payloads and/or features such as direct linux kernel boot once it works well on qemu. We might even run qemu test suites as coreboot payload. cheers, Gerd ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v3] config: allow DEBUG_IO for !QEMU
On 05/30/13 03:34, Kevin O'Connor wrote:
On Wed, May 29, 2013 at 04:25:59PM +0200, Gerd Hoffmann wrote:
Allow selecting DEBUG_IO for non-qemu configurations,
which is useful when running coreboot+seabios on qemu.
Unfortunately, if one does run seabios on real hardware and has
DEBUG_IO enabled, it will write to IO port 0x402 before confirming
that it is actually running on QEMU. This could cause mysterious
failures on real hardware if something is listening to that port.
It's why I left the option dependent on QEMU instead of QEMU_HARDWARE.
Ideally the code would verify it is on QEMU before using the IO port,
while still providing the very early debugging when it is known to be
safe.
The debgconsole port returns 0xe9 on reads, so we could use that for
probing and do something like the attached patch. Which doesn't build
for some reason. Is the F segment read-only in 16bit mode? Should I
use something else instead? Or #ifdef the SET_GLOBAL for 32bit mode,
which should work fine given that POST runs in 32bit mode?
cheers,
Gerd
From ea131715b0b8f959f8f34768ef46ac029a5f84b0 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann kra...@redhat.com
Date: Thu, 30 May 2013 09:25:40 +0200
Subject: [PATCH] [broken] probe for debug port
Signed-off-by: Gerd Hoffmann kra...@redhat.com
---
src/output.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/src/output.c b/src/output.c
index 79c3ada..102f177 100644
--- a/src/output.c
+++ b/src/output.c
@@ -24,6 +24,7 @@ struct putcinfo {
#define DEBUG_TIMEOUT 10
u16 DebugOutputPort VARFSEG = 0x402;
+u8 DebugOutputEnabled VARFSEG = 0xff;
void
debug_serial_preinit(void)
@@ -77,9 +78,17 @@ putc_debug(struct putcinfo *action, char c)
{
if (! CONFIG_DEBUG_LEVEL)
return;
-if (CONFIG_DEBUG_IO)
+if (CONFIG_DEBUG_IO) {
// Send character to debug port.
-outb(c, GET_GLOBAL(DebugOutputPort));
+u8 enabled = GET_GLOBAL(DebugOutputEnabled);
+if (enabled == 0xff) {
+enabled = (inb(GET_GLOBAL(DebugOutputPort)) == 0xe9);
+SET_GLOBAL(DebugOutputEnabled, enabled);
+}
+if (enabled ) {
+outb(c, GET_GLOBAL(DebugOutputPort));
+}
+}
if (c == '\n')
debug_serial('\r');
debug_serial(c);
--
1.7.9.7
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [QEMU PATCH v2] pci: set firmware name of q35 to pci
On Thu, May 30, 2013 at 03:25:17PM +0800, Amos Kong wrote: In QEMU, we set the firmware name of pc-i440fx to 'pci', and the typename 'q35-pcihost' is set to the firmware name of q35 by default. The seabios matches pci devices by /pci/@i0cf8, so q35 device could not be identified, seabios fails to adjust the boot priority of q35 devices. This patch sets firmware name of q35 to 'pci'. Signed-off-by: Michael S. Tsirkin m...@redhat.com Signed-off-by: Amos Kong ak...@redhat.com Does this imply Tested-by: Amos Kong ak...@redhat.com ? --- v2: just set the fw_name, no need to change seabios --- hw/pci-host/q35.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c index 8467f86..24df6b5 100644 --- a/hw/pci-host/q35.c +++ b/hw/pci-host/q35.c @@ -76,6 +76,7 @@ static void q35_host_class_init(ObjectClass *klass, void *data) k-init = q35_host_init; dc-props = mch_props; +dc-fw_name = pci; } static void q35_host_initfn(Object *obj) -- 1.8.1.4 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [QEMU PATCH v2] pci: set firmware name of q35 to pci
On Thu, May 30, 2013 at 03:25:17PM +0800, Amos Kong wrote: In QEMU, we set the firmware name of pc-i440fx to 'pci', and the typename 'q35-pcihost' is set to the firmware name of q35 by default. The seabios matches pci devices by /pci/@i0cf8, so q35 device could not be identified, seabios fails to adjust the boot priority of q35 devices. This patch sets firmware name of q35 to 'pci'. Signed-off-by: Michael S. Tsirkin m...@redhat.com Signed-off-by: Amos Kong ak...@redhat.com I've applied this already. --- v2: just set the fw_name, no need to change seabios --- hw/pci-host/q35.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/pci-host/q35.c b/hw/pci-host/q35.c index 8467f86..24df6b5 100644 --- a/hw/pci-host/q35.c +++ b/hw/pci-host/q35.c @@ -76,6 +76,7 @@ static void q35_host_class_init(ObjectClass *klass, void *data) k-init = q35_host_init; dc-props = mch_props; +dc-fw_name = pci; } static void q35_host_initfn(Object *obj) -- 1.8.1.4 ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-05-28
On Wed, 2013-05-29 at 11:18 -0500, Anthony Liguori wrote: Certainly an option, but that is a long-term project. Out of curiousity, are there other benefits to using coreboot as a core firmware in QEMU? Is there a payload we would ever plausibly use besides OVMF and SeaBIOS? I like the idea of using Coreboot on the UEFI side — if the most actively used TianoCore platform is CorebootPkg instead of OvmfPkg, that makes it a lot easier for people using *real* hardware with Coreboot to use TianoCore. And it helps to dispel the stupid misconception in some quarters that Coreboot *competes* with UEFI and thus cannot possibly be supported because helping something that competes with UEFI would be bad. Is there a payload we would ever plausibly use besides OVMF and SeaBIOS? For my part I want to get to the point where the default firmware shipped with qemu can be OVMF. We have SeaBIOS-as-CSM working, which was one of the biggest barriers. There are a few more things (like NV variable storage, in particular) that I need to fix before I can actually make that suggestion with a straight face though... -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v3] config: allow DEBUG_IO for !QEMU
Gerd Hoffmann wrote: Allow selecting DEBUG_IO for non-qemu configurations, which is useful when running coreboot+seabios on qemu. [ v2: QEMU_HARDWARE is even better as DEBUG_IO default value ] [ v3: make QEMU_HARDWARE usage consistent with other config options, fix spellings in commit message ] Signed-off-by: Gerd Hoffmann kra...@redhat.com Acked-by: Peter Stuge pe...@stuge.se ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28
On 05/30/13 11:23, David Woodhouse wrote: On Wed, 2013-05-29 at 11:18 -0500, Anthony Liguori wrote: Certainly an option, but that is a long-term project. Out of curiousity, are there other benefits to using coreboot as a core firmware in QEMU? Is there a payload we would ever plausibly use besides OVMF and SeaBIOS? I like the idea of using Coreboot on the UEFI side — if the most actively used TianoCore platform is CorebootPkg instead of OvmfPkg, that makes it a lot easier for people using *real* hardware with Coreboot to use TianoCore. Where is CorebootPkg available from? And it helps to dispel the stupid misconception in some quarters that Coreboot *competes* with UEFI and thus cannot possibly be supported because helping something that competes with UEFI would be bad. I'm not sure who do you mean by some quarters, but for some distributions Coreboot would be yet another component (package) to support, for no obvious benefit. (Gerd said it better than I possibly could: http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5685/focus=5705.) Is there a payload we would ever plausibly use besides OVMF and SeaBIOS? For my part I want to get to the point where the default firmware shipped with qemu can be OVMF. For some distributions this is a licensing question as well. See FatBinPkg/License.txt. (The same applies if you rebuild it from source (FatPkgDev), based on FatBinPkg/ReadMe.txt.) For example Fedora can't ship OVMF because of it. If you implement a UEFI FAT driver based on Microsoft's official specification, you're bound by the same restrictions on use and redistribution. If you implement a private UEFI FAT driver from scratch, or port a free software FAT implementation (eg. the r/o one in grub or the r/w one in mtools), you could still run into legal problems, I've been told. If you rip out the FAT driver, then OVMF won't be UEFI compliant and no installer media will boot on it. Interestingly, Ubuntu has OVMF in Universe http://packages.ubuntu.com/raring/ovmf. I think they missed the FatBinPkg license (I would have missed it too, after all you have to track down the licenses of every module included in the FDF file -- it was Paolo who told me about it) and I believe they should actually ship OVMF in Multiverse or Restricted https://help.ubuntu.com/community/Repositories/Ubuntu. We have SeaBIOS-as-CSM working, which was one of the biggest barriers. Agreed, and I could have never done that. Thanks for implementing it with Kevin. We need at least one out-of-tree edk2 patch for now (from you) but apparently that's no problem. There are a few more things (like NV variable storage, in particular) that I need to fix before I can actually make that suggestion with a straight face though... As far as I understand: - Jordan is nearing completion of flash support on KVM, - he also has WIP NvVar storage on top of qemu flash. http://thread.gmane.org/gmane.comp.emulators.qemu/213690 http://thread.gmane.org/gmane.comp.bios.tianocore.devel/2781/focus=2798 (Please coordinate I guess :)) Laszlo ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28
On Thu, May 30, 2013 at 01:19:18PM +0100, David Woodhouse wrote: Yeah, but if we're shoving a lot of hardware-specific ACPI table generation into the guest's firmware, instead of just doing it on the qemu side where a number of us seem to think it belongs, Hopefully this is not yet set in stone. then there *is* a benefit to using Coreboot. When stuff changes on the qemu side and we have to update the table generation to match, you end up having to update just the Coreboot package, and *not* having to patch both SeaBIOS and OVMF. We have all kind of logic in qemu. Some of it can thinkably be moved to a separate VM - it doesn't even need to run in the same VM as the guest - we could do it e.g. like kvm unit-test does, with less pain than running it in firmware. Not clear why would generating ACPI tables - which merely fills up an array of bytes from internal QEMU datastructures - should be the part where we start this modularization. -- MST ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28
On 05/30/13 14:19, David Woodhouse wrote: Yeah, but if we're shoving a lot of hardware-specific ACPI table generation into the guest's firmware, instead of just doing it on the qemu side where a number of us seem to think it belongs, then there *is* a benefit to using Coreboot. When stuff changes on the qemu side and we have to update the table generation to match, you end up having to update just the Coreboot package, and *not* having to patch both SeaBIOS and OVMF. The extra package in the distro really isn't painful to handle, and I suspect it would end up *reducing* the amount of work that we have to do to update. You update *just* Coreboot, not *both* of SeaBIOS and OVMF. I can't deny there's logic in that, but it still feels like tying ourselves up in some intricate bondage choreography. We'd like to move ACPI tables out of firmware, but we can't move them to qemu due to project direction disagreement, so let's adopt a middleman. (I'm not trying to denigrate coreboot -- I don't know it at all --, but introducing it in a (granted, distro-specific) stack just for this purpose seems quite arbitrary.) If you implement a private UEFI FAT driver from scratch, or port a free software FAT implementation (eg. the r/o one in grub or the r/w one in mtools), you could still run into legal problems, I've been told. That has been said, and it's been said for the FAT implementation in the kernel too. If a distribution is happy to ship the kernel without ripping out its FAT support, then I see no reason why that distribution wouldn't also be happy to ship a version of OVMF with a clean implementation of FAT support. It doesn't make sense to be happy with one but not the other. Under my *personal* impression, logic and Common Law don't really mix, especially not in the US. Still under my *personal* impression, someone might not feel convenient suing you for redistributing code that already exists in the upstream Linux kernel, but might happily drag you to court for an original clean implementation, and then you can explain it's illogical for them to do so. The best I can do with your suggestion is to take it to our legal dept. I would be happy to work on a new FAT driver. (I used to feel differently earlier but I've changed my mind.) We need at least one out-of-tree edk2 patch for now (from you) but apparently that's no problem. That'll get merged soon. We are working on the corresponding spec update... Great news! Thanks, Laszlo ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one
- Original Message -
From: Kevin O'Connor ke...@koconnor.net
To: Dave Frodin dave.fro...@se-eng.com
Cc: seabios seabios@seabios.org
Sent: Saturday, May 25, 2013 10:47:42 AM
Subject: Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option
ROMs to one
On Fri, May 24, 2013 at 09:06:54AM -0500, Dave Frodin wrote:
Kevin,
Thanks.
The new patch that I've attached no longer alters the pci device struct.
I also no longer repeatedly read the file in from CBFS, but keep the
pointer to it around for the next time the function is called.
As far as the use case is concerned. We (or a client) will often have
several of
the same mainboard (e.g. persimmon), but the graphics ID will vary
depending on
which version of the cpu is installed. Previously, we would have to figure
out
what the PCI ID of the graphics devices was, adjust the ID in coreboot's
config,
build/flash the new rom image. This seabios change along with a change to
coreboot to set the ID and stuff the correct vendev mapping file into CBFS
will allow a single coreboot/seabios image to be used on any particular
mainboard independent of what cpu was installed. This change won't be
useful
to someone who is using a single board who's graphics ID would never
change.
For that case they wouldn't need to do anything. If the vendev mapping file
doesn't get added they would see no difference.
Thanks.
Why not just place the rom in vgaroms/ directory where it will
always be run?
That is an option but I was hoping to reduce the number of configuration
differences between having coreboot vs seabios load/run the vga option rom.
Currently, coreboot has vendor/device ID mapping functions for the family14,
family15tn northbridges.
Also, I think we could avoid the binary structure in CBFS. Something
like the below (totally untested).
-Kevin
--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -178,10 +178,19 @@ deploy_romfile(struct romfile_s *file)
static struct rom_header *
lookup_hardcode(struct pci_device *pci)
{
-char fname[17];
-snprintf(fname, sizeof(fname), pci%04x,%04x.rom
+struct romfile_s *file;
+char fname[19];
+snprintf(fname, sizeof(fname), alias%04x,%04x.rom
, pci-vendor, pci-device);
-struct romfile_s *file = romfile_find(fname);
+char *alias = romfile_loadfile(fname, NULL);
+if (alias) {
+file = romfile_find(alias);
+free(alias);
+} else {
+snprintf(fname, sizeof(fname), pci%04x,%04x.rom
+ , pci-vendor, pci-device);
+file = romfile_find(fname);
+}
if (file)
return deploy_romfile(file);
return NULL;
In your sample code above, I don't see where any pci ID translation (mapping)
occurs.
As an example we could have a family14 mainboard with a coreboot .config that
generates
a vga option rom with the name pci1002,9802.rom. The actual mainboard could
have a
graphics chip with the id of 1002,9804 (which is 1 of 8 possible IDs). So there
needs
to be some sort of mapping function (in SeaBIOS) that maps the ID of 1002,9804
to 1002,9802.
Thanks again,
Dave
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28
On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote: Where is CorebootPkg available from? https://github.com/pgeorgi/edk2/tree/coreboot-pkg And it helps to dispel the stupid misconception in some quarters that Coreboot *competes* with UEFI and thus cannot possibly be supported because helping something that competes with UEFI would be bad. I'm not sure who do you mean by some quarters, but for some distributions Coreboot would be yet another component (package) to support, for no obvious benefit. (Gerd said it better than I possibly could: http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5685/focus=5705.) Yeah, but if we're shoving a lot of hardware-specific ACPI table generation into the guest's firmware, instead of just doing it on the qemu side where a number of us seem to think it belongs, then there *is* a benefit to using Coreboot. When stuff changes on the qemu side and we have to update the table generation to match, you end up having to update just the Coreboot package, and *not* having to patch both SeaBIOS and OVMF. The extra package in the distro really isn't painful to handle, and I suspect it would end up *reducing* the amount of work that we have to do to update. You update *just* Coreboot, not *both* of SeaBIOS and OVMF. If you implement a private UEFI FAT driver from scratch, or port a free software FAT implementation (eg. the r/o one in grub or the r/w one in mtools), you could still run into legal problems, I've been told. That has been said, and it's been said for the FAT implementation in the kernel too. If a distribution is happy to ship the kernel without ripping out its FAT support, then I see no reason why that distribution wouldn't also be happy to ship a version of OVMF with a clean implementation of FAT support. It doesn't make sense to be happy with one but not the other. We need at least one out-of-tree edk2 patch for now (from you) but apparently that's no problem. That'll get merged soon. We are working on the corresponding spec update... As far as I understand: - Jordan is nearing completion of flash support on KVM, - he also has WIP NvVar storage on top of qemu flash. http://thread.gmane.org/gmane.comp.emulators.qemu/213690 http://thread.gmane.org/gmane.comp.bios.tianocore.devel/2781/focus=2798 (Please coordinate I guess :)) Ooh, shiny. Yeah, when I get back to actually working on it rather than just heckling, I'll make sure I do :) -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-stable] [QEMU PATCH v3] qdev: fix get_fw_dev_path to support to add nothing to fw_dev_path
On Thu, May 30, 2013 at 02:09:25PM +0200, Stefan Priebe - Profihost AG wrote:
Am 29.05.2013 09:56, schrieb Amos Kong:
Recent virtio refactoring in QEMU made virtio-bus become the parent bus
of scsi-bus, and virtio-bus doesn't have get_fw_dev_path implementation,
typename will be added to fw_dev_path by default, the new fw_dev_path
could not be identified by seabios. It causes that bootindex parameter
of scsi device doesn't work.
This patch implements get_fw_dev_path() in BusClass, it will be called
if bus doesn't implement the method, tyename will be added to
fw_dev_path. If the implemented method returns NULL, nothing will be
added to fw_dev_path.
It also implements virtio_bus_get_fw_dev_path() to return NULL. Then
QEMU will still pass original style of fw_dev_path to seabios.
Signed-off-by: Amos Kong ak...@redhat.com
--
v2: only add nothing to fw_dev_path when get_fw_dev_path() is
implemented and returns NULL. then it will not effect other devices
don't have get_fw_dev_path() implementation.
v3: implement default get_fw_dev_path() in BusClass
---
hw/core/qdev.c | 10 +-
hw/virtio/virtio-bus.c | 6 ++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 6985ad8..9190a7e 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -515,7 +515,7 @@ static int qdev_get_fw_dev_path_helper(DeviceState
*dev, char *p, int size)
l += snprintf(p + l, size - l, %s, d);
g_free(d);
} else {
-l += snprintf(p + l, size - l, %s,
object_get_typename(OBJECT(dev)));
+return l;
}
}
l += snprintf(p + l , size - l, /);
@@ -867,9 +867,17 @@ static void qbus_initfn(Object *obj)
QTAILQ_INIT(bus-children);
}
+static char *default_bus_get_fw_dev_path(DeviceState *dev)
+{
+return g_strdup(object_get_typename(OBJECT(dev)));
+}
+
static void bus_class_init(ObjectClass *class, void *data)
{
+BusClass *bc = BUS_CLASS(class);
+
class-unparent = bus_unparent;
+bc-get_fw_dev_path = default_bus_get_fw_dev_path;
}
static void qbus_finalize(Object *obj)
diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c
index ea2e11a..6849a01 100644
--- a/hw/virtio/virtio-bus.c
+++ b/hw/virtio/virtio-bus.c
@@ -161,10 +161,16 @@ static char *virtio_bus_get_dev_path(DeviceState *dev)
return qdev_get_dev_path(proxy);
}
+static char *virtio_bus_get_fw_dev_path(DeviceState *dev)
+{
+return NULL;
+}
+
static void virtio_bus_class_init(ObjectClass *klass, void *data)
{
BusClass *bus_class = BUS_CLASS(klass);
bus_class-get_dev_path = virtio_bus_get_dev_path;
+bus_class-get_fw_dev_path = virtio_bus_get_fw_dev_path;
}
static const TypeInfo virtio_bus_info = {
To me booting VMs with more than one SCSI disk does still not work.
Hi Stefan,
Can you provide your full command-lines ?
net: bootindex=100
scsi0: bootindex=201
does not work
this one works fine:
net: bootindex=200
scsi0: bootindex=101
For me, they all work, (1. check the bootindex string, 2. check boot menu by
entering F12, 3. check by waiting ).
[root@t430s qemu]# qemu-upstream -drive
file=/images/RHEL-Server-6.4-64-virtio.qcow2,if=none,id=drive-system-disk \
-device virtio-scsi-pci,bus=pci.0,addr=0x4,id=scsi0 -device
scsi-hd,drive=drive-system-disk,bus=scsi0.0,bootindex=201 \
-device virtio-net-pci,netdev=h1,bootindex=100 \
-netdev tap,id=h1 -monitor stdio -boot menu=on \
-drive
file=/images/RHEL-Server-6.4-64-virtio.qcow2,if=none,id=drive-system-disk2 \
-device virtio-scsi-pci,bus=pci.0,addr=0x5,id=scsi02 \
-device scsi-hd,drive=drive-system-disk2,bus=scsi0.0,bootindex=202
/pci@i0cf8/ethernet@3/ethernet-phy@0
/pci@i0cf8/scsi@4/channel@0/disk@0,0
/pci@i0cf8/scsi@4/channel@0/disk@1,0
[root@t430s qemu]# qemu-upstream -drive
file=/images/RHEL-Server-6.4-64-virtio.qcow2,if=none,id=drive-system-disk \
-device virtio-scsi-pci,bus=pci.0,addr=0x4,id=scsi0 -device
scsi-hd,drive=drive-system-disk,bus=scsi0.0,bootindex=200 \
-device virtio-net-pci,netdev=h1,bootindex=101 \
-netdev tap,id=h1 -monitor stdio -boot menu=on \
-drive
file=/images/RHEL-Server-6.4-64-virtio.qcow2,if=none,id=drive-system-disk2 \
-device virtio-scsi-pci,bus=pci.0,addr=0x5,id=scsi02 \
-device scsi-hd,drive=drive-system-disk2,bus=scsi0.0,bootindex=202
/pci@i0cf8/ethernet@3/ethernet-phy@0
/pci@i0cf8/scsi@4/channel@0/disk@0,0
/pci@i0cf8/scsi@4/channel@0/disk@1,0
(I outputed the bootindex string)
diff --git a/hw/nvram/fw_cfg.c b/hw/nvram/fw_cfg.c
index 479113b..3f42660 100644
--- a/hw/nvram/fw_cfg.c
+++ b/hw/nvram/fw_cfg.c
@@ -476,6 +476,7 @@ static void fw_cfg_machine_ready(struct Notifier *n, void
*data)
FWCfgState *s = container_of(n, FWCfgState, machine_ready);
char *bootindex = get_boot_devices_list(len);
+
Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28
On Thu, May 30, 2013 at 5:19 AM, David Woodhouse dw...@infradead.org wrote: On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote: Where is CorebootPkg available from? https://github.com/pgeorgi/edk2/tree/coreboot-pkg Is the license on this actually BSD as the License.txt indicates? Is this planned to be upstreamed? Does this support UEFI variables? Does this support UEFI IA32 / X64? And it helps to dispel the stupid misconception in some quarters that Coreboot *competes* with UEFI and thus cannot possibly be supported because helping something that competes with UEFI would be bad. Coreboot and EDK II both provide a good infrastructure for initializing hardware. So, they compete on that point. Coreboot then focuses on booting coreboot payloads, while EDK II focuses on UEFI support. On that point they don't compete, but the focus is different. Of course, you can build a layer of EDK II = Coreboot payload support, or Coreboot = EDK II (CorebootPkg, I guess?), but the match will not be perfect. (That is not to say it can't work.) I'm not sure who do you mean by some quarters, but for some distributions Coreboot would be yet another component (package) to support, for no obvious benefit. (Gerd said it better than I possibly could: http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5685/focus=5705.) Yeah, but if we're shoving a lot of hardware-specific ACPI table generation into the guest's firmware, instead of just doing it on the qemu side where a number of us seem to think it belongs, then there *is* a benefit to using Coreboot. When stuff changes on the qemu side and we have to update the table generation to match, you end up having to update just the Coreboot package, and *not* having to patch both SeaBIOS and OVMF. I think ACPI table generation lives in firmware on real products, because on real products the firmware is the point that best understands the actual hardware layout for the machine. In qemu, I would say that qemu best knows the hardware layout, given that the firmware is generally a slightly separate project from qemu. I don't think adding a coreboot layer into the picture helps, if it brings along the coreboot payload boot interface as a requirement. Then again, I don't really understand how firmware could be swapped out in this case. What would -bios do? How would the coreboot ACPI shim layer be specified to qemu? -Jordan ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28
On 05/30/13 18:20, Jordan Justen wrote: I think ACPI table generation lives in firmware on real products, because on real products the firmware is the point that best understands the actual hardware layout for the machine. In qemu, I would say that qemu best knows the hardware layout, given that the firmware is generally a slightly separate project from qemu. I don't think adding a coreboot layer into the picture helps, if it brings along the coreboot payload boot interface as a requirement. Then again, I don't really understand how firmware could be swapped out in this case. What would -bios do? How would the coreboot ACPI shim layer be specified to qemu? I guess -bios would load coreboot. Coreboot would siphon the data necessary for ACPI table building through the current (same) fw_cfg bottleneck, build the tables, load the boot firmware (SeaBIOS or OVMF or something else -- not sure how to configure that), and pass down the tables to the firmware (through a now unspecified interface -- perhaps the tables could even be installed at this point). This could introduce another interface (fw_cfg+something rather than just fw_cfg), but ACPI table preparation would be concentrated in one project. I guess. Laszlo ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28
On Thu, May 30, 2013 at 9:41 AM, Laszlo Ersek ler...@redhat.com wrote: On 05/30/13 18:20, Jordan Justen wrote: I think ACPI table generation lives in firmware on real products, because on real products the firmware is the point that best understands the actual hardware layout for the machine. In qemu, I would say that qemu best knows the hardware layout, given that the firmware is generally a slightly separate project from qemu. I don't think adding a coreboot layer into the picture helps, if it brings along the coreboot payload boot interface as a requirement. Then again, I don't really understand how firmware could be swapped out in this case. What would -bios do? How would the coreboot ACPI shim layer be specified to qemu? I guess -bios would load coreboot. Coreboot would siphon the data necessary for ACPI table building through the current (same) fw_cfg bottleneck, build the tables, load the boot firmware (SeaBIOS or OVMF or something else -- not sure how to configure that), and pass down the tables to the firmware (through a now unspecified interface -- perhaps the tables could even be installed at this point). This could introduce another interface (fw_cfg+something rather than just fw_cfg), but ACPI table preparation would be concentrated in one project. I guess. For reference, I believe that both Xen and virtualbox build ACPI table in the VMM rather than firmware. They both dump the tables into the 0xe000 segment (yuck) where firmware finds and publishes it to the OS. I think fw-cfg would be a reasonable alternative to this for communicating the tables. -Jordan ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28
On 05/30/13 18:57, Jordan Justen wrote: On Thu, May 30, 2013 at 9:41 AM, Laszlo Ersek ler...@redhat.com wrote: On 05/30/13 18:20, Jordan Justen wrote: I think ACPI table generation lives in firmware on real products, because on real products the firmware is the point that best understands the actual hardware layout for the machine. In qemu, I would say that qemu best knows the hardware layout, given that the firmware is generally a slightly separate project from qemu. I don't think adding a coreboot layer into the picture helps, if it brings along the coreboot payload boot interface as a requirement. Then again, I don't really understand how firmware could be swapped out in this case. What would -bios do? How would the coreboot ACPI shim layer be specified to qemu? I guess -bios would load coreboot. Coreboot would siphon the data necessary for ACPI table building through the current (same) fw_cfg bottleneck, build the tables, load the boot firmware (SeaBIOS or OVMF or something else -- not sure how to configure that), and pass down the tables to the firmware (through a now unspecified interface -- perhaps the tables could even be installed at this point). This could introduce another interface (fw_cfg+something rather than just fw_cfg), but ACPI table preparation would be concentrated in one project. I guess. For reference, I believe that both Xen and virtualbox build ACPI table in the VMM rather than firmware. They both dump the tables into the 0xe000 segment (yuck) where firmware finds and publishes it to the OS. I think fw-cfg would be a reasonable alternative to this for communicating the tables. I think Xen uses a separate utility called hvmloader that runs in the domU. - http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5453/focus=5668 - http://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=tools/firmware/hvmloader - http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/6255/focus=110562 Laszlo ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28
On Thu, May 30, 2013 at 09:20:42AM -0700, Jordan Justen wrote: On Thu, May 30, 2013 at 5:19 AM, David Woodhouse dw...@infradead.org wrote: On Thu, 2013-05-30 at 13:13 +0200, Laszlo Ersek wrote: Where is CorebootPkg available from? https://github.com/pgeorgi/edk2/tree/coreboot-pkg Is the license on this actually BSD as the License.txt indicates? Is this planned to be upstreamed? Does this support UEFI variables? Does this support UEFI IA32 / X64? And it helps to dispel the stupid misconception in some quarters that Coreboot *competes* with UEFI and thus cannot possibly be supported because helping something that competes with UEFI would be bad. Coreboot and EDK II both provide a good infrastructure for initializing hardware. So, they compete on that point. Coreboot then focuses on booting coreboot payloads, while EDK II focuses on UEFI support. On that point they don't compete, but the focus is different. Of course, you can build a layer of EDK II = Coreboot payload support, or Coreboot = EDK II (CorebootPkg, I guess?), but the match will not be perfect. (That is not to say it can't work.) I'm not sure who do you mean by some quarters, but for some distributions Coreboot would be yet another component (package) to support, for no obvious benefit. (Gerd said it better than I possibly could: http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5685/focus=5705.) Yeah, but if we're shoving a lot of hardware-specific ACPI table generation into the guest's firmware, instead of just doing it on the qemu side where a number of us seem to think it belongs, then there *is* a benefit to using Coreboot. When stuff changes on the qemu side and we have to update the table generation to match, you end up having to update just the Coreboot package, and *not* having to patch both SeaBIOS and OVMF. I think ACPI table generation lives in firmware on real products, because on real products the firmware is the point that best understands the actual hardware layout for the machine. In qemu, I would say that qemu best knows the hardware layout, given that the firmware is generally a slightly separate project from qemu. Of course ACPI tables are firmware. Please note that what my patches do is simply supply templates for ACPI tables on a ROM device separate from where bios code resides. bios still tweaks them in minor ways. I am guessing this is what happens on real hardware too: most tables pre-generated in ROM, firmware shadows them and tweaks them in minor ways. I don't think adding a coreboot layer into the picture helps, if it brings along the coreboot payload boot interface as a requirement. Then again, I don't really understand how firmware could be swapped out in this case. What would -bios do? How would the coreboot ACPI shim layer be specified to qemu? -Jordan ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-devel] KVM call agenda for 2013-05-28
On Thu, May 30, 2013 at 09:57:10AM -0700, Jordan Justen wrote: On Thu, May 30, 2013 at 9:41 AM, Laszlo Ersek ler...@redhat.com wrote: On 05/30/13 18:20, Jordan Justen wrote: I think ACPI table generation lives in firmware on real products, because on real products the firmware is the point that best understands the actual hardware layout for the machine. In qemu, I would say that qemu best knows the hardware layout, given that the firmware is generally a slightly separate project from qemu. I don't think adding a coreboot layer into the picture helps, if it brings along the coreboot payload boot interface as a requirement. Then again, I don't really understand how firmware could be swapped out in this case. What would -bios do? How would the coreboot ACPI shim layer be specified to qemu? I guess -bios would load coreboot. Coreboot would siphon the data necessary for ACPI table building through the current (same) fw_cfg bottleneck, build the tables, load the boot firmware (SeaBIOS or OVMF or something else -- not sure how to configure that), and pass down the tables to the firmware (through a now unspecified interface -- perhaps the tables could even be installed at this point). This could introduce another interface (fw_cfg+something rather than just fw_cfg), but ACPI table preparation would be concentrated in one project. I guess. For reference, I believe that both Xen and virtualbox build ACPI table in the VMM rather than firmware. They both dump the tables into the 0xe000 segment (yuck) where firmware finds and publishes it to the OS. I think fw-cfg would be a reasonable alternative to this for communicating the tables. -Jordan Want to review/ack the patches I sent? That's exactly what they do. -- MST ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-stable] [QEMU PATCH v3] qdev: fix get_fw_dev_path to support to add nothing to fw_dev_path
On Thu, May 30, 2013 at 10:30:21PM +0200, Stefan Priebe wrote:
Am 30.05.2013 15:13, schrieb Amos Kong:
On Thu, May 30, 2013 at 02:09:25PM +0200, Stefan Priebe - Profihost AG wrote:
Am 29.05.2013 09:56, schrieb Amos Kong:
Recent virtio refactoring in QEMU made virtio-bus become the parent bus
of scsi-bus, and virtio-bus doesn't have get_fw_dev_path implementation,
typename will be added to fw_dev_path by default, the new fw_dev_path
could not be identified by seabios. It causes that bootindex parameter
of scsi device doesn't work.
This patch implements get_fw_dev_path() in BusClass, it will be called
if bus doesn't implement the method, tyename will be added to
fw_dev_path. If the implemented method returns NULL, nothing will be
added to fw_dev_path.
It also implements virtio_bus_get_fw_dev_path() to return NULL. Then
QEMU will still pass original style of fw_dev_path to seabios.
Signed-off-by: Amos Kong ak...@redhat.com
--
v2: only add nothing to fw_dev_path when get_fw_dev_path() is
implemented and returns NULL. then it will not effect other devices
don't have get_fw_dev_path() implementation.
v3: implement default get_fw_dev_path() in BusClass
---
hw/core/qdev.c | 10 +-
hw/virtio/virtio-bus.c | 6 ++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 6985ad8..9190a7e 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -515,7 +515,7 @@ static int qdev_get_fw_dev_path_helper(DeviceState
*dev, char *p, int size)
l += snprintf(p + l, size - l, %s, d);
g_free(d);
} else {
-l += snprintf(p + l, size - l, %s,
object_get_typename(OBJECT(dev)));
+return l;
}
}
l += snprintf(p + l , size - l, /);
@@ -867,9 +867,17 @@ static void qbus_initfn(Object *obj)
QTAILQ_INIT(bus-children);
}
+static char *default_bus_get_fw_dev_path(DeviceState *dev)
+{
+return g_strdup(object_get_typename(OBJECT(dev)));
+}
+
static void bus_class_init(ObjectClass *class, void *data)
{
+BusClass *bc = BUS_CLASS(class);
+
class-unparent = bus_unparent;
+bc-get_fw_dev_path = default_bus_get_fw_dev_path;
}
static void qbus_finalize(Object *obj)
diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c
index ea2e11a..6849a01 100644
--- a/hw/virtio/virtio-bus.c
+++ b/hw/virtio/virtio-bus.c
@@ -161,10 +161,16 @@ static char *virtio_bus_get_dev_path(DeviceState
*dev)
return qdev_get_dev_path(proxy);
}
+static char *virtio_bus_get_fw_dev_path(DeviceState *dev)
+{
+return NULL;
+}
+
static void virtio_bus_class_init(ObjectClass *klass, void *data)
{
BusClass *bus_class = BUS_CLASS(klass);
bus_class-get_dev_path = virtio_bus_get_dev_path;
+bus_class-get_fw_dev_path = virtio_bus_get_fw_dev_path;
}
static const TypeInfo virtio_bus_info = {
To me booting VMs with more than one SCSI disk does still not work.
Hi Stefan,
Can you provide your full command-lines ?
net: bootindex=100
scsi0: bootindex=201
does not work
this one works fine:
net: bootindex=200
scsi0: bootindex=101
For me, they all work, (1. check the bootindex string, 2. check boot menu by
entering F12, 3. check by waiting ).
Thanks for your reply.
Oh it does only NOT work if i have TWO network cards. It never seems
to try to boot from scsi0. It tries PXE net0 then net1 and then it
restarts.
Something is wrong here, '-boot menu=on ' - guest could not restart
if no available boot device, it will also try to boot from other
unselected devices (DVD, floppy)
'-boot menu=on,strict=on,reboot-timeout=1000' - boot from net0, net1, disk1,
then restart ...
It seems the problem of your bios.bin or rbd device.
You can try with a scsi disk (unavailable)
# qemu-img create /tmp/none.qcow2 -f qcow2 1M
I'm using seabios(pc-bios/bios.bin) in qemu repo latest seabios in seabios.org
Example:
Command line:
qemu -chardev
socket,id=qmp,path=/var/run/qemu-server/155.qmp,server,nowait -mon
chardev=qmp,mode=control -pidfile /var/run/qemu-server/155.pid
-daemonize -name TTT -smp sockets=1,cores=4 -nodefaults -boot
menu=on -vga cirrus -k de -m 4096 -device
piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 -device
usb-tablet,id=tablet,bus=uhci.0,port=1 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -device
virtio-scsi-pci,id=scsihw0,bus=pci.0,addr=0x5 -drive
file=rbd:stor/vmdisk-1:mon_host=10.255.0.100\:6789\;10.255.0.101\:6789\;10.255.0.102\:6789\;:auth_supported=none,if=none,id=drive-scsi0,iops_rd=215,iops_wr=155,bps_rd=136314880,bps_wr=94371840,aio=native,discard=on
-device
scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=200
-drive if=none,id=drive-ide2,media=cdrom,aio=native -device
ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2 -netdev
Re: [SeaBIOS] [Qemu-stable] [QEMU PATCH v3] qdev: fix get_fw_dev_path to support to add nothing to fw_dev_path
Am 29.05.2013 09:56, schrieb Amos Kong:
Recent virtio refactoring in QEMU made virtio-bus become the parent bus
of scsi-bus, and virtio-bus doesn't have get_fw_dev_path implementation,
typename will be added to fw_dev_path by default, the new fw_dev_path
could not be identified by seabios. It causes that bootindex parameter
of scsi device doesn't work.
This patch implements get_fw_dev_path() in BusClass, it will be called
if bus doesn't implement the method, tyename will be added to
fw_dev_path. If the implemented method returns NULL, nothing will be
added to fw_dev_path.
It also implements virtio_bus_get_fw_dev_path() to return NULL. Then
QEMU will still pass original style of fw_dev_path to seabios.
Signed-off-by: Amos Kong ak...@redhat.com
--
v2: only add nothing to fw_dev_path when get_fw_dev_path() is
implemented and returns NULL. then it will not effect other devices
don't have get_fw_dev_path() implementation.
v3: implement default get_fw_dev_path() in BusClass
---
hw/core/qdev.c | 10 +-
hw/virtio/virtio-bus.c | 6 ++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 6985ad8..9190a7e 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -515,7 +515,7 @@ static int qdev_get_fw_dev_path_helper(DeviceState *dev,
char *p, int size)
l += snprintf(p + l, size - l, %s, d);
g_free(d);
} else {
-l += snprintf(p + l, size - l, %s,
object_get_typename(OBJECT(dev)));
+return l;
}
}
l += snprintf(p + l , size - l, /);
@@ -867,9 +867,17 @@ static void qbus_initfn(Object *obj)
QTAILQ_INIT(bus-children);
}
+static char *default_bus_get_fw_dev_path(DeviceState *dev)
+{
+return g_strdup(object_get_typename(OBJECT(dev)));
+}
+
static void bus_class_init(ObjectClass *class, void *data)
{
+BusClass *bc = BUS_CLASS(class);
+
class-unparent = bus_unparent;
+bc-get_fw_dev_path = default_bus_get_fw_dev_path;
}
static void qbus_finalize(Object *obj)
diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c
index ea2e11a..6849a01 100644
--- a/hw/virtio/virtio-bus.c
+++ b/hw/virtio/virtio-bus.c
@@ -161,10 +161,16 @@ static char *virtio_bus_get_dev_path(DeviceState *dev)
return qdev_get_dev_path(proxy);
}
+static char *virtio_bus_get_fw_dev_path(DeviceState *dev)
+{
+return NULL;
+}
+
static void virtio_bus_class_init(ObjectClass *klass, void *data)
{
BusClass *bus_class = BUS_CLASS(klass);
bus_class-get_dev_path = virtio_bus_get_dev_path;
+bus_class-get_fw_dev_path = virtio_bus_get_fw_dev_path;
}
static const TypeInfo virtio_bus_info = {
To me booting VMs with more than one SCSI disk does still not work.
net: bootindex=100
scsi0: bootindex=201
does not work
this one works fine:
net: bootindex=200
scsi0: bootindex=101
Stefan
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [Qemu-stable] [QEMU PATCH v3] qdev: fix get_fw_dev_path to support to add nothing to fw_dev_path
Am 30.05.2013 15:13, schrieb Amos Kong:
On Thu, May 30, 2013 at 02:09:25PM +0200, Stefan Priebe - Profihost AG wrote:
Am 29.05.2013 09:56, schrieb Amos Kong:
Recent virtio refactoring in QEMU made virtio-bus become the parent bus
of scsi-bus, and virtio-bus doesn't have get_fw_dev_path implementation,
typename will be added to fw_dev_path by default, the new fw_dev_path
could not be identified by seabios. It causes that bootindex parameter
of scsi device doesn't work.
This patch implements get_fw_dev_path() in BusClass, it will be called
if bus doesn't implement the method, tyename will be added to
fw_dev_path. If the implemented method returns NULL, nothing will be
added to fw_dev_path.
It also implements virtio_bus_get_fw_dev_path() to return NULL. Then
QEMU will still pass original style of fw_dev_path to seabios.
Signed-off-by: Amos Kong ak...@redhat.com
--
v2: only add nothing to fw_dev_path when get_fw_dev_path() is
implemented and returns NULL. then it will not effect other devices
don't have get_fw_dev_path() implementation.
v3: implement default get_fw_dev_path() in BusClass
---
hw/core/qdev.c | 10 +-
hw/virtio/virtio-bus.c | 6 ++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 6985ad8..9190a7e 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -515,7 +515,7 @@ static int qdev_get_fw_dev_path_helper(DeviceState *dev,
char *p, int size)
l += snprintf(p + l, size - l, %s, d);
g_free(d);
} else {
-l += snprintf(p + l, size - l, %s,
object_get_typename(OBJECT(dev)));
+return l;
}
}
l += snprintf(p + l , size - l, /);
@@ -867,9 +867,17 @@ static void qbus_initfn(Object *obj)
QTAILQ_INIT(bus-children);
}
+static char *default_bus_get_fw_dev_path(DeviceState *dev)
+{
+return g_strdup(object_get_typename(OBJECT(dev)));
+}
+
static void bus_class_init(ObjectClass *class, void *data)
{
+BusClass *bc = BUS_CLASS(class);
+
class-unparent = bus_unparent;
+bc-get_fw_dev_path = default_bus_get_fw_dev_path;
}
static void qbus_finalize(Object *obj)
diff --git a/hw/virtio/virtio-bus.c b/hw/virtio/virtio-bus.c
index ea2e11a..6849a01 100644
--- a/hw/virtio/virtio-bus.c
+++ b/hw/virtio/virtio-bus.c
@@ -161,10 +161,16 @@ static char *virtio_bus_get_dev_path(DeviceState *dev)
return qdev_get_dev_path(proxy);
}
+static char *virtio_bus_get_fw_dev_path(DeviceState *dev)
+{
+return NULL;
+}
+
static void virtio_bus_class_init(ObjectClass *klass, void *data)
{
BusClass *bus_class = BUS_CLASS(klass);
bus_class-get_dev_path = virtio_bus_get_dev_path;
+bus_class-get_fw_dev_path = virtio_bus_get_fw_dev_path;
}
static const TypeInfo virtio_bus_info = {
To me booting VMs with more than one SCSI disk does still not work.
Hi Stefan,
Can you provide your full command-lines ?
net: bootindex=100
scsi0: bootindex=201
does not work
this one works fine:
net: bootindex=200
scsi0: bootindex=101
For me, they all work, (1. check the bootindex string, 2. check boot menu by
entering F12, 3. check by waiting ).
Oh it does only NOT work if i have TWO network cards. It never seems to
try to boot from scsi0. It tries PXE net0 then net1 and then it restarts.
Example:
Command line:
qemu -chardev
socket,id=qmp,path=/var/run/qemu-server/155.qmp,server,nowait -mon
chardev=qmp,mode=control -pidfile /var/run/qemu-server/155.pid
-daemonize -name TTT -smp sockets=1,cores=4 -nodefaults -boot menu=on
-vga cirrus -k de -m 4096 -device
piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2 -device
usb-tablet,id=tablet,bus=uhci.0,port=1 -device
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3 -device
virtio-scsi-pci,id=scsihw0,bus=pci.0,addr=0x5 -drive
file=rbd:stor/vmdisk-1:mon_host=10.255.0.100\:6789\;10.255.0.101\:6789\;10.255.0.102\:6789\;:auth_supported=none,if=none,id=drive-scsi0,iops_rd=215,iops_wr=155,bps_rd=136314880,bps_wr=94371840,aio=native,discard=on
-device
scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=200
-drive if=none,id=drive-ide2,media=cdrom,aio=native -device
ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2 -netdev
type=tap,id=net0,ifname=tap155i0,script=/var/lib/qemu-server/pve-bridge,vhost=on
-device
virtio-net-pci,mac=6A:32:5C:4B:38:F4,netdev=net0,bus=pci.0,addr=0x12,id=net0,bootindex=100
-netdev
type=tap,id=net1,ifname=tap155i1,script=/var/lib/qemu-server/pve-bridge,vhost=on
-device
virtio-net-pci,mac=D6:3A:F6:E2:91:0A,netdev=net1,bus=pci.0,addr=0x13,id=net1,bootindex=101
-rtc base=localtime
Stefan
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH v3] config: allow DEBUG_IO for !QEMU
On Thu, May 30, 2013 at 09:30:33AM +0200, Gerd Hoffmann wrote: On 05/30/13 03:34, Kevin O'Connor wrote: On Wed, May 29, 2013 at 04:25:59PM +0200, Gerd Hoffmann wrote: Allow selecting DEBUG_IO for non-qemu configurations, which is useful when running coreboot+seabios on qemu. Unfortunately, if one does run seabios on real hardware and has DEBUG_IO enabled, it will write to IO port 0x402 before confirming that it is actually running on QEMU. This could cause mysterious failures on real hardware if something is listening to that port. It's why I left the option dependent on QEMU instead of QEMU_HARDWARE. Ideally the code would verify it is on QEMU before using the IO port, while still providing the very early debugging when it is known to be safe. The debgconsole port returns 0xe9 on reads, so we could use that for probing and do something like the attached patch. Which doesn't build for some reason. Is the F segment read-only in 16bit mode? Should I use something else instead? Or #ifdef the SET_GLOBAL for 32bit mode, which should work fine given that POST runs in 32bit mode? Same problem - one can't reliably do an inb(0xe9) on real hardware without risking mysterious failures. -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] [PATCH] Seabios: allow mapping of multiple PCI option ROMs to one
On Thu, May 30, 2013 at 07:49:36AM -0500, Dave Frodin wrote:
From: Kevin O'Connor ke...@koconnor.net
--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -178,10 +178,19 @@ deploy_romfile(struct romfile_s *file)
static struct rom_header *
lookup_hardcode(struct pci_device *pci)
{
-char fname[17];
-snprintf(fname, sizeof(fname), pci%04x,%04x.rom
+struct romfile_s *file;
+char fname[19];
+snprintf(fname, sizeof(fname), alias%04x,%04x.rom
, pci-vendor, pci-device);
-struct romfile_s *file = romfile_find(fname);
+char *alias = romfile_loadfile(fname, NULL);
+if (alias) {
+file = romfile_find(alias);
+free(alias);
+} else {
+snprintf(fname, sizeof(fname), pci%04x,%04x.rom
+ , pci-vendor, pci-device);
+file = romfile_find(fname);
+}
if (file)
return deploy_romfile(file);
return NULL;
In your sample code above, I don't see where any pci ID translation
(mapping) occurs.
As an example we could have a family14 mainboard with a coreboot
.config that generates a vga option rom with the name
pci1002,9802.rom. The actual mainboard could have a graphics chip
with the id of 1002,9804 (which is 1 of 8 possible IDs). So there
needs to be some sort of mapping function (in SeaBIOS) that maps the
ID of 1002,9804 to 1002,9802.
With the above patch (assuming it works) one should be able to create
a CBFS file named alias1002,9804.rom that contains the text
pci1002,9802.rom.
-Kevin
___
SeaBIOS mailing list
SeaBIOS@seabios.org
http://www.seabios.org/mailman/listinfo/seabios
Re: [SeaBIOS] KVM call agenda for 2013-05-28
On Tue, May 28, 2013 at 07:53:09PM -0400, Kevin O'Connor wrote: There were discussions on potentially introducing a middle component to generate the tables. Coreboot was raised as a possibility, and David thought it would be okay to use coreboot for both OVMF and SeaBIOS. The possibility was also raised of a rom that lives in the qemu repo, is run in the guest, and generates the tables (which is similar to the hvmloader approach that Xen uses). Given the objections to implementing ACPI directly in QEMU, one possible way forward would be to split the current SeaBIOS rom into two roms: qvmloader and seabios. The qvmloader would do the qemu specific platform init (pci init, smm init, mtrr init, bios tables) and then load and run the regular seabios rom. With this split, qvmloader could be committed into the QEMU repo and maintained there. This would be analogous to Xen's hvmloader with the seabios code used as a starting point to implement it. With both the hardware implementation and acpi descriptions for that hardware in the same source code repository, it would be possible to implement changes to both in a single patch series. The fwcfg entries used to pass data between qemu and qvmloader could also be changed in a single patch and thus those fwcfg entries would not need to be considered a stable interface. The qvmloader code also wouldn't need the 16bit handlers that seabios requires and thus wouldn't need the full complexity of the seabios build. Finally, it's possible that both ovmf and seabios could use a single qvmloader implementation. On the down side, reboots can be a bit goofy today in kvm, and that would need to be settled before something like qvmloader could be implemented. Also, it may be problematic to support passing of bios tables from qvmloader to seabios for guests with only 1 meg of ram. Thoughts? -Kevin ___ SeaBIOS mailing list SeaBIOS@seabios.org http://www.seabios.org/mailman/listinfo/seabios
