* [Qemu-devel] [PATCHv6 00/16] boot order specification
@ 2010-11-17 16:43 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, mst, armbru, blauwirbel, alex.williamson, kevin
I am using open firmware naming scheme to specify device path names.
In this version: added SCSI bus support. Pass boot order list as file
to firmware.
Names look like this on pci machine:
/pci@i0cf8/ide@1,1/drive@1/disk@0
/pci@i0cf8/isa@1/fdc@03f1/floppy@1
/pci@i0cf8/isa@1/fdc@03f1/floppy@0
/pci@i0cf8/ide@1,1/drive@1/disk@1
/pci@i0cf8/ide@1,1/drive@0/disk@0
/pci@i0cf8/scsi@3/disk@0,0
/pci@i0cf8/ethernet@4/ethernet-phy@0
/pci@i0cf8/ethernet@5/ethernet-phy@0
/pci@i0cf8/ide@1,1/drive@0/disk@1
/pci@i0cf8/isa@1/ide@01e8/drive@0/disk@0
/pci@i0cf8/usb@1,2/network@0/ethernet@0
/pci@i0cf8/usb@1,2/hub@1/network@0/ethernet@0
/rom@genroms/linuxboot.bin
and on isa machine:
/isa/ide@0170/drive@0/disk@0
/isa/fdc@03f1/floppy@1
/isa/fdc@03f1/floppy@0
/isa/ide@0170/drive@0/disk@1
Instead of using get_dev_path() callback I introduces another one
get_fw_dev_path. Unfortunately the way get_dev_path() callback is used
in migration code makes it hard to reuse it for other purposes. First
of all it is not called recursively so caller expects it to provide
unique name by itself. Device path though is inherently recursive. Each
individual element may not be unique, but the whole path will be. On
the other hand to call get_dev_path() recursively in migration code we
should implement it for all possible buses first. Other problem is
compatibility. If we change get_dev_path() output format now we will not
be able to migrate from old qemu to new one without some additional
compatibility layer.
Gleb Natapov (16):
Introduce fw_name field to DeviceInfo structure.
Introduce new BusInfo callback get_fw_dev_path.
Keep track of ISA ports ISA device is using in qdev.
Add get_fw_dev_path callback to ISA bus in qdev.
Store IDE bus id in IDEBus structure for easy access.
Add get_fw_dev_path callback to IDE bus.
Add get_dev_path callback for system bus.
Add get_fw_dev_path callback for pci bus.
Record which USBDevice USBPort belongs too.
Add get_dev_path callback for usb bus.
Add get_dev_path callback to scsi bus.
Add bootindex parameter to net/block/fd device
Change fw_cfg_add_file() to get full file path as a parameter.
Add bootindex for option roms.
Add notifier that will be called when machine is fully created.
Pass boot device list to firmware.
block_int.h | 4 +-
hw/cs4231a.c | 1 +
hw/e1000.c | 4 ++
hw/eepro100.c | 3 +
hw/fdc.c | 12 ++++++
hw/fw_cfg.c | 30 ++++++++------
hw/fw_cfg.h | 4 +-
hw/gus.c | 4 ++
hw/ide/cmd646.c | 4 +-
hw/ide/internal.h | 3 +-
hw/ide/isa.c | 5 ++-
hw/ide/piix.c | 4 +-
hw/ide/qdev.c | 22 ++++++++++-
hw/ide/via.c | 4 +-
hw/isa-bus.c | 42 +++++++++++++++++++
hw/isa.h | 4 ++
hw/lance.c | 1 +
hw/loader.c | 32 ++++++++++++---
hw/loader.h | 8 ++--
hw/m48t59.c | 1 +
hw/mc146818rtc.c | 1 +
hw/multiboot.c | 3 +-
hw/ne2000-isa.c | 3 +
hw/ne2000.c | 5 ++-
hw/nseries.c | 4 +-
hw/palm.c | 6 +-
hw/parallel.c | 5 ++
hw/pc.c | 7 ++-
hw/pci.c | 110 ++++++++++++++++++++++++++++++++++++++++-----------
hw/pci_host.c | 2 +
hw/pckbd.c | 3 +
hw/pcnet.c | 6 ++-
hw/piix_pci.c | 1 +
hw/qdev.c | 32 +++++++++++++++
hw/qdev.h | 9 ++++
hw/rtl8139.c | 4 ++
hw/sb16.c | 4 ++
hw/scsi-bus.c | 23 +++++++++++
hw/scsi-disk.c | 2 +
hw/serial.c | 1 +
hw/sysbus.c | 30 ++++++++++++++
hw/sysbus.h | 4 ++
hw/usb-bus.c | 45 ++++++++++++++++++++-
hw/usb-hub.c | 3 +-
hw/usb-musb.c | 2 +-
hw/usb-net.c | 3 +
hw/usb-ohci.c | 2 +-
hw/usb-uhci.c | 2 +-
hw/usb.h | 3 +-
hw/virtio-blk.c | 2 +
hw/virtio-net.c | 2 +
hw/virtio-pci.c | 1 +
net.h | 4 +-
qemu-config.c | 17 ++++++++
sysemu.h | 11 +++++-
vl.c | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
56 files changed, 588 insertions(+), 80 deletions(-)
--
1.7.2.3
^ permalink raw reply [flat|nested] 136+ messages in thread
* [PATCHv6 01/16] Introduce fw_name field to DeviceInfo structure.
2010-11-17 16:43 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-17 16:43 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, blauwirbel, armbru, alex.williamson, mst, kevin
Add "fw_name" to DeviceInfo to use in device path building. In
contrast to "name" "fw_name" should refer to functionality device
provides instead of particular device model like "name" does.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/fdc.c | 1 +
hw/ide/isa.c | 1 +
hw/ide/qdev.c | 1 +
hw/isa-bus.c | 1 +
hw/lance.c | 1 +
hw/piix_pci.c | 1 +
hw/qdev.h | 6 ++++++
hw/scsi-disk.c | 1 +
hw/usb-hub.c | 1 +
hw/usb-net.c | 1 +
hw/virtio-pci.c | 1 +
11 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/hw/fdc.c b/hw/fdc.c
index c159dcb..a467c4b 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -2040,6 +2040,7 @@ static const VMStateDescription vmstate_isa_fdc ={
static ISADeviceInfo isa_fdc_info = {
.init = isabus_fdc_init1,
.qdev.name = "isa-fdc",
+ .qdev.fw_name = "fdc",
.qdev.size = sizeof(FDCtrlISABus),
.qdev.no_user = 1,
.qdev.vmsd = &vmstate_isa_fdc,
diff --git a/hw/ide/isa.c b/hw/ide/isa.c
index 6b57e0d..9856435 100644
--- a/hw/ide/isa.c
+++ b/hw/ide/isa.c
@@ -98,6 +98,7 @@ ISADevice *isa_ide_init(int iobase, int iobase2, int isairq,
static ISADeviceInfo isa_ide_info = {
.qdev.name = "isa-ide",
+ .qdev.fw_name = "ide",
.qdev.size = sizeof(ISAIDEState),
.init = isa_ide_initfn,
.qdev.reset = isa_ide_reset,
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 0808760..6d27b60 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -134,6 +134,7 @@ static int ide_drive_initfn(IDEDevice *dev)
static IDEDeviceInfo ide_drive_info = {
.qdev.name = "ide-drive",
+ .qdev.fw_name = "drive",
.qdev.size = sizeof(IDEDrive),
.init = ide_drive_initfn,
.qdev.props = (Property[]) {
diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index 4e306de..26036e0 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -153,6 +153,7 @@ static int isabus_bridge_init(SysBusDevice *dev)
static SysBusDeviceInfo isabus_bridge_info = {
.init = isabus_bridge_init,
.qdev.name = "isabus-bridge",
+ .qdev.fw_name = "isa",
.qdev.size = sizeof(SysBusDevice),
.qdev.no_user = 1,
};
diff --git a/hw/lance.c b/hw/lance.c
index dc12144..1a3bb1a 100644
--- a/hw/lance.c
+++ b/hw/lance.c
@@ -141,6 +141,7 @@ static void lance_reset(DeviceState *dev)
static SysBusDeviceInfo lance_info = {
.init = lance_init,
.qdev.name = "lance",
+ .qdev.fw_name = "ethernet",
.qdev.size = sizeof(SysBusPCNetState),
.qdev.reset = lance_reset,
.qdev.vmsd = &vmstate_lance,
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index b5589b9..38f9d9e 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -365,6 +365,7 @@ static PCIDeviceInfo i440fx_info[] = {
static SysBusDeviceInfo i440fx_pcihost_info = {
.init = i440fx_pcihost_initfn,
.qdev.name = "i440FX-pcihost",
+ .qdev.fw_name = "pci",
.qdev.size = sizeof(I440FXState),
.qdev.no_user = 1,
};
diff --git a/hw/qdev.h b/hw/qdev.h
index 579328a..9f90efe 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -139,6 +139,7 @@ typedef void (*qdev_resetfn)(DeviceState *dev);
struct DeviceInfo {
const char *name;
+ const char *fw_name;
const char *alias;
const char *desc;
size_t size;
@@ -288,6 +289,11 @@ void qdev_prop_set_defaults(DeviceState *dev, Property *props);
void qdev_prop_register_global_list(GlobalProperty *props);
void qdev_prop_set_globals(DeviceState *dev);
+static inline const char *qdev_fw_name(DeviceState *dev)
+{
+ return dev->info->fw_name ? : dev->info->alias ? : dev->info->name;
+}
+
/* This is a nasty hack to allow passing a NULL bus to qdev_create. */
extern struct BusInfo system_bus_info;
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index dc71957..2b22777 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -1235,6 +1235,7 @@ static int scsi_disk_initfn(SCSIDevice *dev)
static SCSIDeviceInfo scsi_disk_info = {
.qdev.name = "scsi-disk",
+ .qdev.fw_name = "disk",
.qdev.desc = "virtual scsi disk or cdrom",
.qdev.size = sizeof(SCSIDiskState),
.qdev.reset = scsi_disk_reset,
diff --git a/hw/usb-hub.c b/hw/usb-hub.c
index 2a1edfc..8e3a96b 100644
--- a/hw/usb-hub.c
+++ b/hw/usb-hub.c
@@ -545,6 +545,7 @@ static int usb_hub_initfn(USBDevice *dev)
static struct USBDeviceInfo hub_info = {
.product_desc = "QEMU USB Hub",
.qdev.name = "usb-hub",
+ .qdev.fw_name = "hub",
.qdev.size = sizeof(USBHubState),
.init = usb_hub_initfn,
.handle_packet = usb_hub_handle_packet,
diff --git a/hw/usb-net.c b/hw/usb-net.c
index 58c672f..f6bed21 100644
--- a/hw/usb-net.c
+++ b/hw/usb-net.c
@@ -1496,6 +1496,7 @@ static USBDevice *usb_net_init(const char *cmdline)
static struct USBDeviceInfo net_info = {
.product_desc = "QEMU USB Network Interface",
.qdev.name = "usb-net",
+ .qdev.fw_name = "network",
.qdev.size = sizeof(USBNetState),
.init = usb_net_initfn,
.handle_packet = usb_generic_handle_packet,
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 729917d..be2c92f 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -697,6 +697,7 @@ static int virtio_9p_init_pci(PCIDevice *pci_dev)
static PCIDeviceInfo virtio_info[] = {
{
.qdev.name = "virtio-blk-pci",
+ .qdev.alias = "virtio-blk",
.qdev.size = sizeof(VirtIOPCIProxy),
.init = virtio_blk_init_pci,
.exit = virtio_blk_exit_pci,
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread* [Qemu-devel] [PATCHv6 01/16] Introduce fw_name field to DeviceInfo structure.
@ 2010-11-17 16:43 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, mst, armbru, blauwirbel, alex.williamson, kevin
Add "fw_name" to DeviceInfo to use in device path building. In
contrast to "name" "fw_name" should refer to functionality device
provides instead of particular device model like "name" does.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/fdc.c | 1 +
hw/ide/isa.c | 1 +
hw/ide/qdev.c | 1 +
hw/isa-bus.c | 1 +
hw/lance.c | 1 +
hw/piix_pci.c | 1 +
hw/qdev.h | 6 ++++++
hw/scsi-disk.c | 1 +
hw/usb-hub.c | 1 +
hw/usb-net.c | 1 +
hw/virtio-pci.c | 1 +
11 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/hw/fdc.c b/hw/fdc.c
index c159dcb..a467c4b 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -2040,6 +2040,7 @@ static const VMStateDescription vmstate_isa_fdc ={
static ISADeviceInfo isa_fdc_info = {
.init = isabus_fdc_init1,
.qdev.name = "isa-fdc",
+ .qdev.fw_name = "fdc",
.qdev.size = sizeof(FDCtrlISABus),
.qdev.no_user = 1,
.qdev.vmsd = &vmstate_isa_fdc,
diff --git a/hw/ide/isa.c b/hw/ide/isa.c
index 6b57e0d..9856435 100644
--- a/hw/ide/isa.c
+++ b/hw/ide/isa.c
@@ -98,6 +98,7 @@ ISADevice *isa_ide_init(int iobase, int iobase2, int isairq,
static ISADeviceInfo isa_ide_info = {
.qdev.name = "isa-ide",
+ .qdev.fw_name = "ide",
.qdev.size = sizeof(ISAIDEState),
.init = isa_ide_initfn,
.qdev.reset = isa_ide_reset,
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 0808760..6d27b60 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -134,6 +134,7 @@ static int ide_drive_initfn(IDEDevice *dev)
static IDEDeviceInfo ide_drive_info = {
.qdev.name = "ide-drive",
+ .qdev.fw_name = "drive",
.qdev.size = sizeof(IDEDrive),
.init = ide_drive_initfn,
.qdev.props = (Property[]) {
diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index 4e306de..26036e0 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -153,6 +153,7 @@ static int isabus_bridge_init(SysBusDevice *dev)
static SysBusDeviceInfo isabus_bridge_info = {
.init = isabus_bridge_init,
.qdev.name = "isabus-bridge",
+ .qdev.fw_name = "isa",
.qdev.size = sizeof(SysBusDevice),
.qdev.no_user = 1,
};
diff --git a/hw/lance.c b/hw/lance.c
index dc12144..1a3bb1a 100644
--- a/hw/lance.c
+++ b/hw/lance.c
@@ -141,6 +141,7 @@ static void lance_reset(DeviceState *dev)
static SysBusDeviceInfo lance_info = {
.init = lance_init,
.qdev.name = "lance",
+ .qdev.fw_name = "ethernet",
.qdev.size = sizeof(SysBusPCNetState),
.qdev.reset = lance_reset,
.qdev.vmsd = &vmstate_lance,
diff --git a/hw/piix_pci.c b/hw/piix_pci.c
index b5589b9..38f9d9e 100644
--- a/hw/piix_pci.c
+++ b/hw/piix_pci.c
@@ -365,6 +365,7 @@ static PCIDeviceInfo i440fx_info[] = {
static SysBusDeviceInfo i440fx_pcihost_info = {
.init = i440fx_pcihost_initfn,
.qdev.name = "i440FX-pcihost",
+ .qdev.fw_name = "pci",
.qdev.size = sizeof(I440FXState),
.qdev.no_user = 1,
};
diff --git a/hw/qdev.h b/hw/qdev.h
index 579328a..9f90efe 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -139,6 +139,7 @@ typedef void (*qdev_resetfn)(DeviceState *dev);
struct DeviceInfo {
const char *name;
+ const char *fw_name;
const char *alias;
const char *desc;
size_t size;
@@ -288,6 +289,11 @@ void qdev_prop_set_defaults(DeviceState *dev, Property *props);
void qdev_prop_register_global_list(GlobalProperty *props);
void qdev_prop_set_globals(DeviceState *dev);
+static inline const char *qdev_fw_name(DeviceState *dev)
+{
+ return dev->info->fw_name ? : dev->info->alias ? : dev->info->name;
+}
+
/* This is a nasty hack to allow passing a NULL bus to qdev_create. */
extern struct BusInfo system_bus_info;
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index dc71957..2b22777 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -1235,6 +1235,7 @@ static int scsi_disk_initfn(SCSIDevice *dev)
static SCSIDeviceInfo scsi_disk_info = {
.qdev.name = "scsi-disk",
+ .qdev.fw_name = "disk",
.qdev.desc = "virtual scsi disk or cdrom",
.qdev.size = sizeof(SCSIDiskState),
.qdev.reset = scsi_disk_reset,
diff --git a/hw/usb-hub.c b/hw/usb-hub.c
index 2a1edfc..8e3a96b 100644
--- a/hw/usb-hub.c
+++ b/hw/usb-hub.c
@@ -545,6 +545,7 @@ static int usb_hub_initfn(USBDevice *dev)
static struct USBDeviceInfo hub_info = {
.product_desc = "QEMU USB Hub",
.qdev.name = "usb-hub",
+ .qdev.fw_name = "hub",
.qdev.size = sizeof(USBHubState),
.init = usb_hub_initfn,
.handle_packet = usb_hub_handle_packet,
diff --git a/hw/usb-net.c b/hw/usb-net.c
index 58c672f..f6bed21 100644
--- a/hw/usb-net.c
+++ b/hw/usb-net.c
@@ -1496,6 +1496,7 @@ static USBDevice *usb_net_init(const char *cmdline)
static struct USBDeviceInfo net_info = {
.product_desc = "QEMU USB Network Interface",
.qdev.name = "usb-net",
+ .qdev.fw_name = "network",
.qdev.size = sizeof(USBNetState),
.init = usb_net_initfn,
.handle_packet = usb_generic_handle_packet,
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index 729917d..be2c92f 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -697,6 +697,7 @@ static int virtio_9p_init_pci(PCIDevice *pci_dev)
static PCIDeviceInfo virtio_info[] = {
{
.qdev.name = "virtio-blk-pci",
+ .qdev.alias = "virtio-blk",
.qdev.size = sizeof(VirtIOPCIProxy),
.init = virtio_blk_init_pci,
.exit = virtio_blk_exit_pci,
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCHv6 02/16] Introduce new BusInfo callback get_fw_dev_path.
2010-11-17 16:43 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-17 16:43 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, blauwirbel, armbru, alex.williamson, mst, kevin
New get_fw_dev_path callback will be used for build device path usable
by firmware in contrast to qdev qemu internal device path.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/qdev.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/hw/qdev.h b/hw/qdev.h
index 9f90efe..dc669b3 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -49,12 +49,14 @@ struct DeviceState {
typedef void (*bus_dev_printfn)(Monitor *mon, DeviceState *dev, int indent);
typedef char *(*bus_get_dev_path)(DeviceState *dev);
+typedef char *(*bus_get_fw_dev_path)(DeviceState *dev);
struct BusInfo {
const char *name;
size_t size;
bus_dev_printfn print_dev;
bus_get_dev_path get_dev_path;
+ bus_get_fw_dev_path get_fw_dev_path;
Property *props;
};
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread* [Qemu-devel] [PATCHv6 02/16] Introduce new BusInfo callback get_fw_dev_path.
@ 2010-11-17 16:43 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, mst, armbru, blauwirbel, alex.williamson, kevin
New get_fw_dev_path callback will be used for build device path usable
by firmware in contrast to qdev qemu internal device path.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/qdev.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/hw/qdev.h b/hw/qdev.h
index 9f90efe..dc669b3 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -49,12 +49,14 @@ struct DeviceState {
typedef void (*bus_dev_printfn)(Monitor *mon, DeviceState *dev, int indent);
typedef char *(*bus_get_dev_path)(DeviceState *dev);
+typedef char *(*bus_get_fw_dev_path)(DeviceState *dev);
struct BusInfo {
const char *name;
size_t size;
bus_dev_printfn print_dev;
bus_get_dev_path get_dev_path;
+ bus_get_fw_dev_path get_fw_dev_path;
Property *props;
};
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCHv6 03/16] Keep track of ISA ports ISA device is using in qdev.
2010-11-17 16:43 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-17 16:43 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, blauwirbel, armbru, alex.williamson, mst, kevin
Store all io ports used by device in ISADevice structure.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/cs4231a.c | 1 +
hw/fdc.c | 3 +++
hw/gus.c | 4 ++++
hw/ide/isa.c | 2 ++
hw/isa-bus.c | 25 +++++++++++++++++++++++++
hw/isa.h | 4 ++++
hw/m48t59.c | 1 +
hw/mc146818rtc.c | 1 +
hw/ne2000-isa.c | 3 +++
hw/parallel.c | 5 +++++
hw/pckbd.c | 3 +++
hw/sb16.c | 4 ++++
hw/serial.c | 1 +
13 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/hw/cs4231a.c b/hw/cs4231a.c
index 4d5ce5c..598f032 100644
--- a/hw/cs4231a.c
+++ b/hw/cs4231a.c
@@ -645,6 +645,7 @@ static int cs4231a_initfn (ISADevice *dev)
isa_init_irq (dev, &s->pic, s->irq);
for (i = 0; i < 4; i++) {
+ isa_init_ioport(dev, i);
register_ioport_write (s->port + i, 1, 1, cs_write, s);
register_ioport_read (s->port + i, 1, 1, cs_read, s);
}
diff --git a/hw/fdc.c b/hw/fdc.c
index a467c4b..5ab754b 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -1983,6 +1983,9 @@ static int isabus_fdc_init1(ISADevice *dev)
&fdctrl_write_port, fdctrl);
register_ioport_write(iobase + 0x07, 1, 1,
&fdctrl_write_port, fdctrl);
+ isa_init_ioport_range(dev, iobase + 1, 5);
+ isa_init_ioport(dev, iobase + 7);
+
isa_init_irq(&isa->busdev, &fdctrl->irq, isairq);
fdctrl->dma_chann = dma_chann;
diff --git a/hw/gus.c b/hw/gus.c
index e9016d8..ff9e7c7 100644
--- a/hw/gus.c
+++ b/hw/gus.c
@@ -264,20 +264,24 @@ static int gus_initfn (ISADevice *dev)
register_ioport_write (s->port, 1, 1, gus_writeb, s);
register_ioport_write (s->port, 1, 2, gus_writew, s);
+ isa_init_ioport_range(dev, s->port, 2);
register_ioport_read ((s->port + 0x100) & 0xf00, 1, 1, gus_readb, s);
register_ioport_read ((s->port + 0x100) & 0xf00, 1, 2, gus_readw, s);
+ isa_init_ioport_range(dev, (s->port + 0x100) & 0xf00, 2);
register_ioport_write (s->port + 6, 10, 1, gus_writeb, s);
register_ioport_write (s->port + 6, 10, 2, gus_writew, s);
register_ioport_read (s->port + 6, 10, 1, gus_readb, s);
register_ioport_read (s->port + 6, 10, 2, gus_readw, s);
+ isa_init_ioport_range(dev, s->port + 6, 10);
register_ioport_write (s->port + 0x100, 8, 1, gus_writeb, s);
register_ioport_write (s->port + 0x100, 8, 2, gus_writew, s);
register_ioport_read (s->port + 0x100, 8, 1, gus_readb, s);
register_ioport_read (s->port + 0x100, 8, 2, gus_readw, s);
+ isa_init_ioport_range(dev, s->port + 0x100, 8);
DMA_register_channel (s->emu.gusdma, GUS_read_DMA, s);
s->emu.himemaddr = s->himem;
diff --git a/hw/ide/isa.c b/hw/ide/isa.c
index 9856435..4206afd 100644
--- a/hw/ide/isa.c
+++ b/hw/ide/isa.c
@@ -70,6 +70,8 @@ static int isa_ide_initfn(ISADevice *dev)
ide_bus_new(&s->bus, &s->dev.qdev);
ide_init_ioport(&s->bus, s->iobase, s->iobase2);
isa_init_irq(dev, &s->irq, s->isairq);
+ isa_init_ioport_range(dev, s->iobase, 8);
+ isa_init_ioport(dev, s->iobase2);
ide_init2(&s->bus, s->irq);
vmstate_register(&dev->qdev, 0, &vmstate_ide_isa, s);
return 0;
diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index 26036e0..c0ac7e9 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -92,6 +92,31 @@ void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq)
dev->nirqs++;
}
+static void isa_init_ioport_one(ISADevice *dev, uint16_t ioport)
+{
+ assert(dev->nioports < ARRAY_SIZE(dev->ioports));
+ dev->ioports[dev->nioports++] = ioport;
+}
+
+static int isa_cmp_ports(const void *p1, const void *p2)
+{
+ return *(uint16_t*)p1 - *(uint16_t*)p2;
+}
+
+void isa_init_ioport_range(ISADevice *dev, uint16_t start, uint16_t length)
+{
+ int i;
+ for (i = start; i < start + length; i++) {
+ isa_init_ioport_one(dev, i);
+ }
+ qsort(dev->ioports, dev->nioports, sizeof(dev->ioports[0]), isa_cmp_ports);
+}
+
+void isa_init_ioport(ISADevice *dev, uint16_t ioport)
+{
+ isa_init_ioport_range(dev, ioport, 1);
+}
+
static int isa_qdev_init(DeviceState *qdev, DeviceInfo *base)
{
ISADevice *dev = DO_UPCAST(ISADevice, qdev, qdev);
diff --git a/hw/isa.h b/hw/isa.h
index aaf0272..4794b76 100644
--- a/hw/isa.h
+++ b/hw/isa.h
@@ -14,6 +14,8 @@ struct ISADevice {
DeviceState qdev;
uint32_t isairq[2];
int nirqs;
+ uint16_t ioports[32];
+ int nioports;
};
typedef int (*isa_qdev_initfn)(ISADevice *dev);
@@ -26,6 +28,8 @@ ISABus *isa_bus_new(DeviceState *dev);
void isa_bus_irqs(qemu_irq *irqs);
qemu_irq isa_reserve_irq(int isairq);
void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq);
+void isa_init_ioport(ISADevice *dev, uint16_t ioport);
+void isa_init_ioport_range(ISADevice *dev, uint16_t start, uint16_t length);
void isa_qdev_register(ISADeviceInfo *info);
ISADevice *isa_create(const char *name);
ISADevice *isa_create_simple(const char *name);
diff --git a/hw/m48t59.c b/hw/m48t59.c
index c7492a6..75a94e1 100644
--- a/hw/m48t59.c
+++ b/hw/m48t59.c
@@ -680,6 +680,7 @@ M48t59State *m48t59_init_isa(uint32_t io_base, uint16_t size, int type)
if (io_base != 0) {
register_ioport_read(io_base, 0x04, 1, NVRAM_readb, s);
register_ioport_write(io_base, 0x04, 1, NVRAM_writeb, s);
+ isa_init_ioport_range(dev, io_base, 4);
}
return s;
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 2b91fa8..6466aff 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -605,6 +605,7 @@ static int rtc_initfn(ISADevice *dev)
register_ioport_write(base, 2, 1, cmos_ioport_write, s);
register_ioport_read(base, 2, 1, cmos_ioport_read, s);
+ isa_init_ioport_range(dev, base, 2);
qdev_set_legacy_instance_id(&dev->qdev, base, 2);
qemu_register_reset(rtc_reset, s);
diff --git a/hw/ne2000-isa.c b/hw/ne2000-isa.c
index 03a5a1f..3ff0d89 100644
--- a/hw/ne2000-isa.c
+++ b/hw/ne2000-isa.c
@@ -68,14 +68,17 @@ static int isa_ne2000_initfn(ISADevice *dev)
register_ioport_write(isa->iobase, 16, 1, ne2000_ioport_write, s);
register_ioport_read(isa->iobase, 16, 1, ne2000_ioport_read, s);
+ isa_init_ioport_range(dev, isa->iobase, 16);
register_ioport_write(isa->iobase + 0x10, 1, 1, ne2000_asic_ioport_write, s);
register_ioport_read(isa->iobase + 0x10, 1, 1, ne2000_asic_ioport_read, s);
register_ioport_write(isa->iobase + 0x10, 2, 2, ne2000_asic_ioport_write, s);
register_ioport_read(isa->iobase + 0x10, 2, 2, ne2000_asic_ioport_read, s);
+ isa_init_ioport_range(dev, isa->iobase + 0x10, 2);
register_ioport_write(isa->iobase + 0x1f, 1, 1, ne2000_reset_ioport_write, s);
register_ioport_read(isa->iobase + 0x1f, 1, 1, ne2000_reset_ioport_read, s);
+ isa_init_ioport(dev, isa->iobase + 0x1f);
isa_init_irq(dev, &s->irq, isa->isairq);
diff --git a/hw/parallel.c b/hw/parallel.c
index 6b11672..6270b53 100644
--- a/hw/parallel.c
+++ b/hw/parallel.c
@@ -481,16 +481,21 @@ static int parallel_isa_initfn(ISADevice *dev)
if (s->hw_driver) {
register_ioport_write(base, 8, 1, parallel_ioport_write_hw, s);
register_ioport_read(base, 8, 1, parallel_ioport_read_hw, s);
+ isa_init_ioport_range(dev, base, 8);
+
register_ioport_write(base+4, 1, 2, parallel_ioport_eppdata_write_hw2, s);
register_ioport_read(base+4, 1, 2, parallel_ioport_eppdata_read_hw2, s);
register_ioport_write(base+4, 1, 4, parallel_ioport_eppdata_write_hw4, s);
register_ioport_read(base+4, 1, 4, parallel_ioport_eppdata_read_hw4, s);
+ isa_init_ioport(dev, base+4);
register_ioport_write(base+0x400, 8, 1, parallel_ioport_ecp_write, s);
register_ioport_read(base+0x400, 8, 1, parallel_ioport_ecp_read, s);
+ isa_init_ioport_range(dev, base+0x400, 8);
}
else {
register_ioport_write(base, 8, 1, parallel_ioport_write_sw, s);
register_ioport_read(base, 8, 1, parallel_ioport_read_sw, s);
+ isa_init_ioport_range(dev, base, 8);
}
return 0;
}
diff --git a/hw/pckbd.c b/hw/pckbd.c
index 6e4e406..e736505 100644
--- a/hw/pckbd.c
+++ b/hw/pckbd.c
@@ -484,10 +484,13 @@ static int i8042_initfn(ISADevice *dev)
register_ioport_read(0x60, 1, 1, kbd_read_data, s);
register_ioport_write(0x60, 1, 1, kbd_write_data, s);
+ isa_init_ioport(dev, 0x60);
register_ioport_read(0x64, 1, 1, kbd_read_status, s);
register_ioport_write(0x64, 1, 1, kbd_write_command, s);
+ isa_init_ioport(dev, 0x64);
register_ioport_read(0x92, 1, 1, ioport92_read, s);
register_ioport_write(0x92, 1, 1, ioport92_write, s);
+ isa_init_ioport(dev, 0x92);
s->kbd = ps2_kbd_init(kbd_update_kbd_irq, s);
s->mouse = ps2_mouse_init(kbd_update_aux_irq, s);
diff --git a/hw/sb16.c b/hw/sb16.c
index 78590a7..c9d37ad 100644
--- a/hw/sb16.c
+++ b/hw/sb16.c
@@ -1368,16 +1368,20 @@ static int sb16_initfn (ISADevice *dev)
for (i = 0; i < ARRAY_SIZE (dsp_write_ports); i++) {
register_ioport_write (s->port + dsp_write_ports[i], 1, 1, dsp_write, s);
+ isa_init_ioport(dev, s->port + dsp_write_ports[i]);
}
for (i = 0; i < ARRAY_SIZE (dsp_read_ports); i++) {
register_ioport_read (s->port + dsp_read_ports[i], 1, 1, dsp_read, s);
+ isa_init_ioport(dev, s->port + dsp_read_ports[i]);
}
register_ioport_write (s->port + 0x4, 1, 1, mixer_write_indexb, s);
register_ioport_write (s->port + 0x4, 1, 2, mixer_write_indexw, s);
+ isa_init_ioport(dev, s->port + 0x4);
register_ioport_read (s->port + 0x5, 1, 1, mixer_read, s);
register_ioport_write (s->port + 0x5, 1, 1, mixer_write_datab, s);
+ isa_init_ioport(dev, s->port + 0x5);
DMA_register_channel (s->hdma, SB_read_DMA, s);
DMA_register_channel (s->dma, SB_read_DMA, s);
diff --git a/hw/serial.c b/hw/serial.c
index 9ebc452..20902ae 100644
--- a/hw/serial.c
+++ b/hw/serial.c
@@ -778,6 +778,7 @@ static int serial_isa_initfn(ISADevice *dev)
register_ioport_write(isa->iobase, 8, 1, serial_ioport_write, s);
register_ioport_read(isa->iobase, 8, 1, serial_ioport_read, s);
+ isa_init_ioport_range(dev, isa->iobase, 8);
return 0;
}
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread* [Qemu-devel] [PATCHv6 03/16] Keep track of ISA ports ISA device is using in qdev.
@ 2010-11-17 16:43 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, mst, armbru, blauwirbel, alex.williamson, kevin
Store all io ports used by device in ISADevice structure.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/cs4231a.c | 1 +
hw/fdc.c | 3 +++
hw/gus.c | 4 ++++
hw/ide/isa.c | 2 ++
hw/isa-bus.c | 25 +++++++++++++++++++++++++
hw/isa.h | 4 ++++
hw/m48t59.c | 1 +
hw/mc146818rtc.c | 1 +
hw/ne2000-isa.c | 3 +++
hw/parallel.c | 5 +++++
hw/pckbd.c | 3 +++
hw/sb16.c | 4 ++++
hw/serial.c | 1 +
13 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/hw/cs4231a.c b/hw/cs4231a.c
index 4d5ce5c..598f032 100644
--- a/hw/cs4231a.c
+++ b/hw/cs4231a.c
@@ -645,6 +645,7 @@ static int cs4231a_initfn (ISADevice *dev)
isa_init_irq (dev, &s->pic, s->irq);
for (i = 0; i < 4; i++) {
+ isa_init_ioport(dev, i);
register_ioport_write (s->port + i, 1, 1, cs_write, s);
register_ioport_read (s->port + i, 1, 1, cs_read, s);
}
diff --git a/hw/fdc.c b/hw/fdc.c
index a467c4b..5ab754b 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -1983,6 +1983,9 @@ static int isabus_fdc_init1(ISADevice *dev)
&fdctrl_write_port, fdctrl);
register_ioport_write(iobase + 0x07, 1, 1,
&fdctrl_write_port, fdctrl);
+ isa_init_ioport_range(dev, iobase + 1, 5);
+ isa_init_ioport(dev, iobase + 7);
+
isa_init_irq(&isa->busdev, &fdctrl->irq, isairq);
fdctrl->dma_chann = dma_chann;
diff --git a/hw/gus.c b/hw/gus.c
index e9016d8..ff9e7c7 100644
--- a/hw/gus.c
+++ b/hw/gus.c
@@ -264,20 +264,24 @@ static int gus_initfn (ISADevice *dev)
register_ioport_write (s->port, 1, 1, gus_writeb, s);
register_ioport_write (s->port, 1, 2, gus_writew, s);
+ isa_init_ioport_range(dev, s->port, 2);
register_ioport_read ((s->port + 0x100) & 0xf00, 1, 1, gus_readb, s);
register_ioport_read ((s->port + 0x100) & 0xf00, 1, 2, gus_readw, s);
+ isa_init_ioport_range(dev, (s->port + 0x100) & 0xf00, 2);
register_ioport_write (s->port + 6, 10, 1, gus_writeb, s);
register_ioport_write (s->port + 6, 10, 2, gus_writew, s);
register_ioport_read (s->port + 6, 10, 1, gus_readb, s);
register_ioport_read (s->port + 6, 10, 2, gus_readw, s);
+ isa_init_ioport_range(dev, s->port + 6, 10);
register_ioport_write (s->port + 0x100, 8, 1, gus_writeb, s);
register_ioport_write (s->port + 0x100, 8, 2, gus_writew, s);
register_ioport_read (s->port + 0x100, 8, 1, gus_readb, s);
register_ioport_read (s->port + 0x100, 8, 2, gus_readw, s);
+ isa_init_ioport_range(dev, s->port + 0x100, 8);
DMA_register_channel (s->emu.gusdma, GUS_read_DMA, s);
s->emu.himemaddr = s->himem;
diff --git a/hw/ide/isa.c b/hw/ide/isa.c
index 9856435..4206afd 100644
--- a/hw/ide/isa.c
+++ b/hw/ide/isa.c
@@ -70,6 +70,8 @@ static int isa_ide_initfn(ISADevice *dev)
ide_bus_new(&s->bus, &s->dev.qdev);
ide_init_ioport(&s->bus, s->iobase, s->iobase2);
isa_init_irq(dev, &s->irq, s->isairq);
+ isa_init_ioport_range(dev, s->iobase, 8);
+ isa_init_ioport(dev, s->iobase2);
ide_init2(&s->bus, s->irq);
vmstate_register(&dev->qdev, 0, &vmstate_ide_isa, s);
return 0;
diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index 26036e0..c0ac7e9 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -92,6 +92,31 @@ void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq)
dev->nirqs++;
}
+static void isa_init_ioport_one(ISADevice *dev, uint16_t ioport)
+{
+ assert(dev->nioports < ARRAY_SIZE(dev->ioports));
+ dev->ioports[dev->nioports++] = ioport;
+}
+
+static int isa_cmp_ports(const void *p1, const void *p2)
+{
+ return *(uint16_t*)p1 - *(uint16_t*)p2;
+}
+
+void isa_init_ioport_range(ISADevice *dev, uint16_t start, uint16_t length)
+{
+ int i;
+ for (i = start; i < start + length; i++) {
+ isa_init_ioport_one(dev, i);
+ }
+ qsort(dev->ioports, dev->nioports, sizeof(dev->ioports[0]), isa_cmp_ports);
+}
+
+void isa_init_ioport(ISADevice *dev, uint16_t ioport)
+{
+ isa_init_ioport_range(dev, ioport, 1);
+}
+
static int isa_qdev_init(DeviceState *qdev, DeviceInfo *base)
{
ISADevice *dev = DO_UPCAST(ISADevice, qdev, qdev);
diff --git a/hw/isa.h b/hw/isa.h
index aaf0272..4794b76 100644
--- a/hw/isa.h
+++ b/hw/isa.h
@@ -14,6 +14,8 @@ struct ISADevice {
DeviceState qdev;
uint32_t isairq[2];
int nirqs;
+ uint16_t ioports[32];
+ int nioports;
};
typedef int (*isa_qdev_initfn)(ISADevice *dev);
@@ -26,6 +28,8 @@ ISABus *isa_bus_new(DeviceState *dev);
void isa_bus_irqs(qemu_irq *irqs);
qemu_irq isa_reserve_irq(int isairq);
void isa_init_irq(ISADevice *dev, qemu_irq *p, int isairq);
+void isa_init_ioport(ISADevice *dev, uint16_t ioport);
+void isa_init_ioport_range(ISADevice *dev, uint16_t start, uint16_t length);
void isa_qdev_register(ISADeviceInfo *info);
ISADevice *isa_create(const char *name);
ISADevice *isa_create_simple(const char *name);
diff --git a/hw/m48t59.c b/hw/m48t59.c
index c7492a6..75a94e1 100644
--- a/hw/m48t59.c
+++ b/hw/m48t59.c
@@ -680,6 +680,7 @@ M48t59State *m48t59_init_isa(uint32_t io_base, uint16_t size, int type)
if (io_base != 0) {
register_ioport_read(io_base, 0x04, 1, NVRAM_readb, s);
register_ioport_write(io_base, 0x04, 1, NVRAM_writeb, s);
+ isa_init_ioport_range(dev, io_base, 4);
}
return s;
diff --git a/hw/mc146818rtc.c b/hw/mc146818rtc.c
index 2b91fa8..6466aff 100644
--- a/hw/mc146818rtc.c
+++ b/hw/mc146818rtc.c
@@ -605,6 +605,7 @@ static int rtc_initfn(ISADevice *dev)
register_ioport_write(base, 2, 1, cmos_ioport_write, s);
register_ioport_read(base, 2, 1, cmos_ioport_read, s);
+ isa_init_ioport_range(dev, base, 2);
qdev_set_legacy_instance_id(&dev->qdev, base, 2);
qemu_register_reset(rtc_reset, s);
diff --git a/hw/ne2000-isa.c b/hw/ne2000-isa.c
index 03a5a1f..3ff0d89 100644
--- a/hw/ne2000-isa.c
+++ b/hw/ne2000-isa.c
@@ -68,14 +68,17 @@ static int isa_ne2000_initfn(ISADevice *dev)
register_ioport_write(isa->iobase, 16, 1, ne2000_ioport_write, s);
register_ioport_read(isa->iobase, 16, 1, ne2000_ioport_read, s);
+ isa_init_ioport_range(dev, isa->iobase, 16);
register_ioport_write(isa->iobase + 0x10, 1, 1, ne2000_asic_ioport_write, s);
register_ioport_read(isa->iobase + 0x10, 1, 1, ne2000_asic_ioport_read, s);
register_ioport_write(isa->iobase + 0x10, 2, 2, ne2000_asic_ioport_write, s);
register_ioport_read(isa->iobase + 0x10, 2, 2, ne2000_asic_ioport_read, s);
+ isa_init_ioport_range(dev, isa->iobase + 0x10, 2);
register_ioport_write(isa->iobase + 0x1f, 1, 1, ne2000_reset_ioport_write, s);
register_ioport_read(isa->iobase + 0x1f, 1, 1, ne2000_reset_ioport_read, s);
+ isa_init_ioport(dev, isa->iobase + 0x1f);
isa_init_irq(dev, &s->irq, isa->isairq);
diff --git a/hw/parallel.c b/hw/parallel.c
index 6b11672..6270b53 100644
--- a/hw/parallel.c
+++ b/hw/parallel.c
@@ -481,16 +481,21 @@ static int parallel_isa_initfn(ISADevice *dev)
if (s->hw_driver) {
register_ioport_write(base, 8, 1, parallel_ioport_write_hw, s);
register_ioport_read(base, 8, 1, parallel_ioport_read_hw, s);
+ isa_init_ioport_range(dev, base, 8);
+
register_ioport_write(base+4, 1, 2, parallel_ioport_eppdata_write_hw2, s);
register_ioport_read(base+4, 1, 2, parallel_ioport_eppdata_read_hw2, s);
register_ioport_write(base+4, 1, 4, parallel_ioport_eppdata_write_hw4, s);
register_ioport_read(base+4, 1, 4, parallel_ioport_eppdata_read_hw4, s);
+ isa_init_ioport(dev, base+4);
register_ioport_write(base+0x400, 8, 1, parallel_ioport_ecp_write, s);
register_ioport_read(base+0x400, 8, 1, parallel_ioport_ecp_read, s);
+ isa_init_ioport_range(dev, base+0x400, 8);
}
else {
register_ioport_write(base, 8, 1, parallel_ioport_write_sw, s);
register_ioport_read(base, 8, 1, parallel_ioport_read_sw, s);
+ isa_init_ioport_range(dev, base, 8);
}
return 0;
}
diff --git a/hw/pckbd.c b/hw/pckbd.c
index 6e4e406..e736505 100644
--- a/hw/pckbd.c
+++ b/hw/pckbd.c
@@ -484,10 +484,13 @@ static int i8042_initfn(ISADevice *dev)
register_ioport_read(0x60, 1, 1, kbd_read_data, s);
register_ioport_write(0x60, 1, 1, kbd_write_data, s);
+ isa_init_ioport(dev, 0x60);
register_ioport_read(0x64, 1, 1, kbd_read_status, s);
register_ioport_write(0x64, 1, 1, kbd_write_command, s);
+ isa_init_ioport(dev, 0x64);
register_ioport_read(0x92, 1, 1, ioport92_read, s);
register_ioport_write(0x92, 1, 1, ioport92_write, s);
+ isa_init_ioport(dev, 0x92);
s->kbd = ps2_kbd_init(kbd_update_kbd_irq, s);
s->mouse = ps2_mouse_init(kbd_update_aux_irq, s);
diff --git a/hw/sb16.c b/hw/sb16.c
index 78590a7..c9d37ad 100644
--- a/hw/sb16.c
+++ b/hw/sb16.c
@@ -1368,16 +1368,20 @@ static int sb16_initfn (ISADevice *dev)
for (i = 0; i < ARRAY_SIZE (dsp_write_ports); i++) {
register_ioport_write (s->port + dsp_write_ports[i], 1, 1, dsp_write, s);
+ isa_init_ioport(dev, s->port + dsp_write_ports[i]);
}
for (i = 0; i < ARRAY_SIZE (dsp_read_ports); i++) {
register_ioport_read (s->port + dsp_read_ports[i], 1, 1, dsp_read, s);
+ isa_init_ioport(dev, s->port + dsp_read_ports[i]);
}
register_ioport_write (s->port + 0x4, 1, 1, mixer_write_indexb, s);
register_ioport_write (s->port + 0x4, 1, 2, mixer_write_indexw, s);
+ isa_init_ioport(dev, s->port + 0x4);
register_ioport_read (s->port + 0x5, 1, 1, mixer_read, s);
register_ioport_write (s->port + 0x5, 1, 1, mixer_write_datab, s);
+ isa_init_ioport(dev, s->port + 0x5);
DMA_register_channel (s->hdma, SB_read_DMA, s);
DMA_register_channel (s->dma, SB_read_DMA, s);
diff --git a/hw/serial.c b/hw/serial.c
index 9ebc452..20902ae 100644
--- a/hw/serial.c
+++ b/hw/serial.c
@@ -778,6 +778,7 @@ static int serial_isa_initfn(ISADevice *dev)
register_ioport_write(isa->iobase, 8, 1, serial_ioport_write, s);
register_ioport_read(isa->iobase, 8, 1, serial_ioport_read, s);
+ isa_init_ioport_range(dev, isa->iobase, 8);
return 0;
}
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCHv6 04/16] Add get_fw_dev_path callback to ISA bus in qdev.
2010-11-17 16:43 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-17 16:43 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, blauwirbel, armbru, alex.williamson, mst, kevin
Use device ioports to create unique device path.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/isa-bus.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index c0ac7e9..c423c1b 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -31,11 +31,13 @@ static ISABus *isabus;
target_phys_addr_t isa_mem_base = 0;
static void isabus_dev_print(Monitor *mon, DeviceState *dev, int indent);
+static char *isabus_get_fw_dev_path(DeviceState *dev);
static struct BusInfo isa_bus_info = {
.name = "ISA",
.size = sizeof(ISABus),
.print_dev = isabus_dev_print,
+ .get_fw_dev_path = isabus_get_fw_dev_path,
};
ISABus *isa_bus_new(DeviceState *dev)
@@ -188,4 +190,18 @@ static void isabus_register_devices(void)
sysbus_register_withprop(&isabus_bridge_info);
}
+static char *isabus_get_fw_dev_path(DeviceState *dev)
+{
+ ISADevice *d = (ISADevice*)dev;
+ char path[40];
+ int off;
+
+ off = snprintf(path, sizeof(path), "%s", qdev_fw_name(dev));
+ if (d->nioports) {
+ snprintf(path + off, sizeof(path) - off, "@%04x", d->ioports[0]);
+ }
+
+ return strdup(path);
+}
+
device_init(isabus_register_devices)
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread* [Qemu-devel] [PATCHv6 04/16] Add get_fw_dev_path callback to ISA bus in qdev.
@ 2010-11-17 16:43 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, mst, armbru, blauwirbel, alex.williamson, kevin
Use device ioports to create unique device path.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/isa-bus.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/hw/isa-bus.c b/hw/isa-bus.c
index c0ac7e9..c423c1b 100644
--- a/hw/isa-bus.c
+++ b/hw/isa-bus.c
@@ -31,11 +31,13 @@ static ISABus *isabus;
target_phys_addr_t isa_mem_base = 0;
static void isabus_dev_print(Monitor *mon, DeviceState *dev, int indent);
+static char *isabus_get_fw_dev_path(DeviceState *dev);
static struct BusInfo isa_bus_info = {
.name = "ISA",
.size = sizeof(ISABus),
.print_dev = isabus_dev_print,
+ .get_fw_dev_path = isabus_get_fw_dev_path,
};
ISABus *isa_bus_new(DeviceState *dev)
@@ -188,4 +190,18 @@ static void isabus_register_devices(void)
sysbus_register_withprop(&isabus_bridge_info);
}
+static char *isabus_get_fw_dev_path(DeviceState *dev)
+{
+ ISADevice *d = (ISADevice*)dev;
+ char path[40];
+ int off;
+
+ off = snprintf(path, sizeof(path), "%s", qdev_fw_name(dev));
+ if (d->nioports) {
+ snprintf(path + off, sizeof(path) - off, "@%04x", d->ioports[0]);
+ }
+
+ return strdup(path);
+}
+
device_init(isabus_register_devices)
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCHv6 05/16] Store IDE bus id in IDEBus structure for easy access.
2010-11-17 16:43 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-17 16:43 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, blauwirbel, armbru, alex.williamson, mst, kevin
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/ide/cmd646.c | 4 ++--
hw/ide/internal.h | 3 ++-
hw/ide/isa.c | 2 +-
hw/ide/piix.c | 4 ++--
hw/ide/qdev.c | 3 ++-
hw/ide/via.c | 4 ++--
6 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
index ff80dd5..b2cbdbc 100644
--- a/hw/ide/cmd646.c
+++ b/hw/ide/cmd646.c
@@ -257,8 +257,8 @@ static int pci_cmd646_ide_initfn(PCIDevice *dev)
pci_conf[PCI_INTERRUPT_PIN] = 0x01; // interrupt on pin 1
irq = qemu_allocate_irqs(cmd646_set_irq, d, 2);
- ide_bus_new(&d->bus[0], &d->dev.qdev);
- ide_bus_new(&d->bus[1], &d->dev.qdev);
+ ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
+ ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
ide_init2(&d->bus[0], irq[0]);
ide_init2(&d->bus[1], irq[1]);
diff --git a/hw/ide/internal.h b/hw/ide/internal.h
index d652e06..c0a1abc 100644
--- a/hw/ide/internal.h
+++ b/hw/ide/internal.h
@@ -448,6 +448,7 @@ struct IDEBus {
IDEDevice *slave;
BMDMAState *bmdma;
IDEState ifs[2];
+ int bus_id;
uint8_t unit;
uint8_t cmd;
qemu_irq irq;
@@ -565,7 +566,7 @@ void ide_init2_with_non_qdev_drives(IDEBus *bus, DriveInfo *hd0,
void ide_init_ioport(IDEBus *bus, int iobase, int iobase2);
/* hw/ide/qdev.c */
-void ide_bus_new(IDEBus *idebus, DeviceState *dev);
+void ide_bus_new(IDEBus *idebus, DeviceState *dev, int bus_id);
IDEDevice *ide_create_drive(IDEBus *bus, int unit, DriveInfo *drive);
#endif /* HW_IDE_INTERNAL_H */
diff --git a/hw/ide/isa.c b/hw/ide/isa.c
index 4206afd..8c59c5a 100644
--- a/hw/ide/isa.c
+++ b/hw/ide/isa.c
@@ -67,7 +67,7 @@ static int isa_ide_initfn(ISADevice *dev)
{
ISAIDEState *s = DO_UPCAST(ISAIDEState, dev, dev);
- ide_bus_new(&s->bus, &s->dev.qdev);
+ ide_bus_new(&s->bus, &s->dev.qdev, 0);
ide_init_ioport(&s->bus, s->iobase, s->iobase2);
isa_init_irq(dev, &s->irq, s->isairq);
isa_init_ioport_range(dev, s->iobase, 8);
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 07483e8..d0b04a3 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -129,8 +129,8 @@ static int pci_piix_ide_initfn(PCIIDEState *d)
vmstate_register(&d->dev.qdev, 0, &vmstate_ide_pci, d);
- ide_bus_new(&d->bus[0], &d->dev.qdev);
- ide_bus_new(&d->bus[1], &d->dev.qdev);
+ ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
+ ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
ide_init_ioport(&d->bus[1], 0x170, 0x376);
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 6d27b60..88ff657 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -29,9 +29,10 @@ static struct BusInfo ide_bus_info = {
.size = sizeof(IDEBus),
};
-void ide_bus_new(IDEBus *idebus, DeviceState *dev)
+void ide_bus_new(IDEBus *idebus, DeviceState *dev, int bus_id)
{
qbus_create_inplace(&idebus->qbus, &ide_bus_info, dev, NULL);
+ idebus->bus_id = bus_id;
}
static int ide_qdev_init(DeviceState *qdev, DeviceInfo *base)
diff --git a/hw/ide/via.c b/hw/ide/via.c
index b2c7cad..cc48b2b 100644
--- a/hw/ide/via.c
+++ b/hw/ide/via.c
@@ -158,8 +158,8 @@ static int vt82c686b_ide_initfn(PCIDevice *dev)
vmstate_register(&dev->qdev, 0, &vmstate_ide_pci, d);
- ide_bus_new(&d->bus[0], &d->dev.qdev);
- ide_bus_new(&d->bus[1], &d->dev.qdev);
+ ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
+ ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
ide_init2(&d->bus[0], isa_reserve_irq(14));
ide_init2(&d->bus[1], isa_reserve_irq(15));
ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread* [Qemu-devel] [PATCHv6 05/16] Store IDE bus id in IDEBus structure for easy access.
@ 2010-11-17 16:43 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, mst, armbru, blauwirbel, alex.williamson, kevin
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/ide/cmd646.c | 4 ++--
hw/ide/internal.h | 3 ++-
hw/ide/isa.c | 2 +-
hw/ide/piix.c | 4 ++--
hw/ide/qdev.c | 3 ++-
hw/ide/via.c | 4 ++--
6 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c
index ff80dd5..b2cbdbc 100644
--- a/hw/ide/cmd646.c
+++ b/hw/ide/cmd646.c
@@ -257,8 +257,8 @@ static int pci_cmd646_ide_initfn(PCIDevice *dev)
pci_conf[PCI_INTERRUPT_PIN] = 0x01; // interrupt on pin 1
irq = qemu_allocate_irqs(cmd646_set_irq, d, 2);
- ide_bus_new(&d->bus[0], &d->dev.qdev);
- ide_bus_new(&d->bus[1], &d->dev.qdev);
+ ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
+ ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
ide_init2(&d->bus[0], irq[0]);
ide_init2(&d->bus[1], irq[1]);
diff --git a/hw/ide/internal.h b/hw/ide/internal.h
index d652e06..c0a1abc 100644
--- a/hw/ide/internal.h
+++ b/hw/ide/internal.h
@@ -448,6 +448,7 @@ struct IDEBus {
IDEDevice *slave;
BMDMAState *bmdma;
IDEState ifs[2];
+ int bus_id;
uint8_t unit;
uint8_t cmd;
qemu_irq irq;
@@ -565,7 +566,7 @@ void ide_init2_with_non_qdev_drives(IDEBus *bus, DriveInfo *hd0,
void ide_init_ioport(IDEBus *bus, int iobase, int iobase2);
/* hw/ide/qdev.c */
-void ide_bus_new(IDEBus *idebus, DeviceState *dev);
+void ide_bus_new(IDEBus *idebus, DeviceState *dev, int bus_id);
IDEDevice *ide_create_drive(IDEBus *bus, int unit, DriveInfo *drive);
#endif /* HW_IDE_INTERNAL_H */
diff --git a/hw/ide/isa.c b/hw/ide/isa.c
index 4206afd..8c59c5a 100644
--- a/hw/ide/isa.c
+++ b/hw/ide/isa.c
@@ -67,7 +67,7 @@ static int isa_ide_initfn(ISADevice *dev)
{
ISAIDEState *s = DO_UPCAST(ISAIDEState, dev, dev);
- ide_bus_new(&s->bus, &s->dev.qdev);
+ ide_bus_new(&s->bus, &s->dev.qdev, 0);
ide_init_ioport(&s->bus, s->iobase, s->iobase2);
isa_init_irq(dev, &s->irq, s->isairq);
isa_init_ioport_range(dev, s->iobase, 8);
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 07483e8..d0b04a3 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -129,8 +129,8 @@ static int pci_piix_ide_initfn(PCIIDEState *d)
vmstate_register(&d->dev.qdev, 0, &vmstate_ide_pci, d);
- ide_bus_new(&d->bus[0], &d->dev.qdev);
- ide_bus_new(&d->bus[1], &d->dev.qdev);
+ ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
+ ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
ide_init_ioport(&d->bus[1], 0x170, 0x376);
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 6d27b60..88ff657 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -29,9 +29,10 @@ static struct BusInfo ide_bus_info = {
.size = sizeof(IDEBus),
};
-void ide_bus_new(IDEBus *idebus, DeviceState *dev)
+void ide_bus_new(IDEBus *idebus, DeviceState *dev, int bus_id)
{
qbus_create_inplace(&idebus->qbus, &ide_bus_info, dev, NULL);
+ idebus->bus_id = bus_id;
}
static int ide_qdev_init(DeviceState *qdev, DeviceInfo *base)
diff --git a/hw/ide/via.c b/hw/ide/via.c
index b2c7cad..cc48b2b 100644
--- a/hw/ide/via.c
+++ b/hw/ide/via.c
@@ -158,8 +158,8 @@ static int vt82c686b_ide_initfn(PCIDevice *dev)
vmstate_register(&dev->qdev, 0, &vmstate_ide_pci, d);
- ide_bus_new(&d->bus[0], &d->dev.qdev);
- ide_bus_new(&d->bus[1], &d->dev.qdev);
+ ide_bus_new(&d->bus[0], &d->dev.qdev, 0);
+ ide_bus_new(&d->bus[1], &d->dev.qdev, 1);
ide_init2(&d->bus[0], isa_reserve_irq(14));
ide_init2(&d->bus[1], isa_reserve_irq(15));
ide_init_ioport(&d->bus[0], 0x1f0, 0x3f6);
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCHv6 06/16] Add get_fw_dev_path callback to IDE bus.
2010-11-17 16:43 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-17 16:43 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, blauwirbel, armbru, alex.williamson, mst, kevin
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/ide/qdev.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 88ff657..01a181b 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -24,9 +24,12 @@
/* --------------------------------- */
+static char *idebus_get_fw_dev_path(DeviceState *dev);
+
static struct BusInfo ide_bus_info = {
.name = "IDE",
.size = sizeof(IDEBus),
+ .get_fw_dev_path = idebus_get_fw_dev_path,
};
void ide_bus_new(IDEBus *idebus, DeviceState *dev, int bus_id)
@@ -35,6 +38,16 @@ void ide_bus_new(IDEBus *idebus, DeviceState *dev, int bus_id)
idebus->bus_id = bus_id;
}
+static char *idebus_get_fw_dev_path(DeviceState *dev)
+{
+ char path[30];
+
+ snprintf(path, sizeof(path), "%s@%d", qdev_fw_name(dev),
+ ((IDEBus*)dev->parent_bus)->bus_id);
+
+ return strdup(path);
+}
+
static int ide_qdev_init(DeviceState *qdev, DeviceInfo *base)
{
IDEDevice *dev = DO_UPCAST(IDEDevice, qdev, qdev);
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread* [Qemu-devel] [PATCHv6 06/16] Add get_fw_dev_path callback to IDE bus.
@ 2010-11-17 16:43 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, mst, armbru, blauwirbel, alex.williamson, kevin
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/ide/qdev.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 88ff657..01a181b 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -24,9 +24,12 @@
/* --------------------------------- */
+static char *idebus_get_fw_dev_path(DeviceState *dev);
+
static struct BusInfo ide_bus_info = {
.name = "IDE",
.size = sizeof(IDEBus),
+ .get_fw_dev_path = idebus_get_fw_dev_path,
};
void ide_bus_new(IDEBus *idebus, DeviceState *dev, int bus_id)
@@ -35,6 +38,16 @@ void ide_bus_new(IDEBus *idebus, DeviceState *dev, int bus_id)
idebus->bus_id = bus_id;
}
+static char *idebus_get_fw_dev_path(DeviceState *dev)
+{
+ char path[30];
+
+ snprintf(path, sizeof(path), "%s@%d", qdev_fw_name(dev),
+ ((IDEBus*)dev->parent_bus)->bus_id);
+
+ return strdup(path);
+}
+
static int ide_qdev_init(DeviceState *qdev, DeviceInfo *base)
{
IDEDevice *dev = DO_UPCAST(IDEDevice, qdev, qdev);
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCHv6 07/16] Add get_dev_path callback for system bus.
2010-11-17 16:43 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-17 16:43 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, blauwirbel, armbru, alex.williamson, mst, kevin
Prints out mmio or pio used to access child device.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/pci_host.c | 2 ++
hw/sysbus.c | 30 ++++++++++++++++++++++++++++++
hw/sysbus.h | 4 ++++
3 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/hw/pci_host.c b/hw/pci_host.c
index bc5b771..28d45bf 100644
--- a/hw/pci_host.c
+++ b/hw/pci_host.c
@@ -197,6 +197,7 @@ void pci_host_conf_register_ioport(pio_addr_t ioport, PCIHostState *s)
{
pci_host_init(s);
register_ioport_simple(&s->conf_noswap_handler, ioport, 4, 4);
+ sysbus_init_ioports(&s->busdev, ioport, 4);
}
int pci_host_data_register_mmio(PCIHostState *s, int swap)
@@ -215,4 +216,5 @@ void pci_host_data_register_ioport(pio_addr_t ioport, PCIHostState *s)
register_ioport_simple(&s->data_noswap_handler, ioport, 4, 1);
register_ioport_simple(&s->data_noswap_handler, ioport, 4, 2);
register_ioport_simple(&s->data_noswap_handler, ioport, 4, 4);
+ sysbus_init_ioports(&s->busdev, ioport, 4);
}
diff --git a/hw/sysbus.c b/hw/sysbus.c
index d817721..1583bd8 100644
--- a/hw/sysbus.c
+++ b/hw/sysbus.c
@@ -22,11 +22,13 @@
#include "monitor.h"
static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent);
+static char *sysbus_get_fw_dev_path(DeviceState *dev);
struct BusInfo system_bus_info = {
.name = "System",
.size = sizeof(BusState),
.print_dev = sysbus_dev_print,
+ .get_fw_dev_path = sysbus_get_fw_dev_path,
};
void sysbus_connect_irq(SysBusDevice *dev, int n, qemu_irq irq)
@@ -106,6 +108,16 @@ void sysbus_init_mmio_cb(SysBusDevice *dev, target_phys_addr_t size,
dev->mmio[n].cb = cb;
}
+void sysbus_init_ioports(SysBusDevice *dev, pio_addr_t ioport, pio_addr_t size)
+{
+ pio_addr_t i;
+
+ for (i = 0; i < size; i++) {
+ assert(dev->num_pio < QDEV_MAX_PIO);
+ dev->pio[dev->num_pio++] = ioport++;
+ }
+}
+
static int sysbus_device_init(DeviceState *dev, DeviceInfo *base)
{
SysBusDeviceInfo *info = container_of(base, SysBusDeviceInfo, qdev);
@@ -171,3 +183,21 @@ static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent)
indent, "", s->mmio[i].addr, s->mmio[i].size);
}
}
+
+static char *sysbus_get_fw_dev_path(DeviceState *dev)
+{
+ SysBusDevice *s = sysbus_from_qdev(dev);
+ char path[40];
+ int off;
+
+ off = snprintf(path, sizeof(path), "%s", qdev_fw_name(dev));
+
+ if (s->num_mmio) {
+ snprintf(path + off, sizeof(path) - off, "@"TARGET_FMT_plx,
+ s->mmio[0].addr);
+ } else if (s->num_pio) {
+ snprintf(path + off, sizeof(path) - off, "@i%04x", s->pio[0]);
+ }
+
+ return strdup(path);
+}
diff --git a/hw/sysbus.h b/hw/sysbus.h
index 5980901..e9eb618 100644
--- a/hw/sysbus.h
+++ b/hw/sysbus.h
@@ -6,6 +6,7 @@
#include "qdev.h"
#define QDEV_MAX_MMIO 32
+#define QDEV_MAX_PIO 32
#define QDEV_MAX_IRQ 256
typedef struct SysBusDevice SysBusDevice;
@@ -23,6 +24,8 @@ struct SysBusDevice {
mmio_mapfunc cb;
ram_addr_t iofunc;
} mmio[QDEV_MAX_MMIO];
+ int num_pio;
+ pio_addr_t pio[QDEV_MAX_PIO];
};
typedef int (*sysbus_initfn)(SysBusDevice *dev);
@@ -45,6 +48,7 @@ void sysbus_init_mmio_cb(SysBusDevice *dev, target_phys_addr_t size,
mmio_mapfunc cb);
void sysbus_init_irq(SysBusDevice *dev, qemu_irq *p);
void sysbus_pass_irq(SysBusDevice *dev, SysBusDevice *target);
+void sysbus_init_ioports(SysBusDevice *dev, pio_addr_t ioport, pio_addr_t size);
void sysbus_connect_irq(SysBusDevice *dev, int n, qemu_irq irq);
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread* [Qemu-devel] [PATCHv6 07/16] Add get_dev_path callback for system bus.
@ 2010-11-17 16:43 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, mst, armbru, blauwirbel, alex.williamson, kevin
Prints out mmio or pio used to access child device.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/pci_host.c | 2 ++
hw/sysbus.c | 30 ++++++++++++++++++++++++++++++
hw/sysbus.h | 4 ++++
3 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/hw/pci_host.c b/hw/pci_host.c
index bc5b771..28d45bf 100644
--- a/hw/pci_host.c
+++ b/hw/pci_host.c
@@ -197,6 +197,7 @@ void pci_host_conf_register_ioport(pio_addr_t ioport, PCIHostState *s)
{
pci_host_init(s);
register_ioport_simple(&s->conf_noswap_handler, ioport, 4, 4);
+ sysbus_init_ioports(&s->busdev, ioport, 4);
}
int pci_host_data_register_mmio(PCIHostState *s, int swap)
@@ -215,4 +216,5 @@ void pci_host_data_register_ioport(pio_addr_t ioport, PCIHostState *s)
register_ioport_simple(&s->data_noswap_handler, ioport, 4, 1);
register_ioport_simple(&s->data_noswap_handler, ioport, 4, 2);
register_ioport_simple(&s->data_noswap_handler, ioport, 4, 4);
+ sysbus_init_ioports(&s->busdev, ioport, 4);
}
diff --git a/hw/sysbus.c b/hw/sysbus.c
index d817721..1583bd8 100644
--- a/hw/sysbus.c
+++ b/hw/sysbus.c
@@ -22,11 +22,13 @@
#include "monitor.h"
static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent);
+static char *sysbus_get_fw_dev_path(DeviceState *dev);
struct BusInfo system_bus_info = {
.name = "System",
.size = sizeof(BusState),
.print_dev = sysbus_dev_print,
+ .get_fw_dev_path = sysbus_get_fw_dev_path,
};
void sysbus_connect_irq(SysBusDevice *dev, int n, qemu_irq irq)
@@ -106,6 +108,16 @@ void sysbus_init_mmio_cb(SysBusDevice *dev, target_phys_addr_t size,
dev->mmio[n].cb = cb;
}
+void sysbus_init_ioports(SysBusDevice *dev, pio_addr_t ioport, pio_addr_t size)
+{
+ pio_addr_t i;
+
+ for (i = 0; i < size; i++) {
+ assert(dev->num_pio < QDEV_MAX_PIO);
+ dev->pio[dev->num_pio++] = ioport++;
+ }
+}
+
static int sysbus_device_init(DeviceState *dev, DeviceInfo *base)
{
SysBusDeviceInfo *info = container_of(base, SysBusDeviceInfo, qdev);
@@ -171,3 +183,21 @@ static void sysbus_dev_print(Monitor *mon, DeviceState *dev, int indent)
indent, "", s->mmio[i].addr, s->mmio[i].size);
}
}
+
+static char *sysbus_get_fw_dev_path(DeviceState *dev)
+{
+ SysBusDevice *s = sysbus_from_qdev(dev);
+ char path[40];
+ int off;
+
+ off = snprintf(path, sizeof(path), "%s", qdev_fw_name(dev));
+
+ if (s->num_mmio) {
+ snprintf(path + off, sizeof(path) - off, "@"TARGET_FMT_plx,
+ s->mmio[0].addr);
+ } else if (s->num_pio) {
+ snprintf(path + off, sizeof(path) - off, "@i%04x", s->pio[0]);
+ }
+
+ return strdup(path);
+}
diff --git a/hw/sysbus.h b/hw/sysbus.h
index 5980901..e9eb618 100644
--- a/hw/sysbus.h
+++ b/hw/sysbus.h
@@ -6,6 +6,7 @@
#include "qdev.h"
#define QDEV_MAX_MMIO 32
+#define QDEV_MAX_PIO 32
#define QDEV_MAX_IRQ 256
typedef struct SysBusDevice SysBusDevice;
@@ -23,6 +24,8 @@ struct SysBusDevice {
mmio_mapfunc cb;
ram_addr_t iofunc;
} mmio[QDEV_MAX_MMIO];
+ int num_pio;
+ pio_addr_t pio[QDEV_MAX_PIO];
};
typedef int (*sysbus_initfn)(SysBusDevice *dev);
@@ -45,6 +48,7 @@ void sysbus_init_mmio_cb(SysBusDevice *dev, target_phys_addr_t size,
mmio_mapfunc cb);
void sysbus_init_irq(SysBusDevice *dev, qemu_irq *p);
void sysbus_pass_irq(SysBusDevice *dev, SysBusDevice *target);
+void sysbus_init_ioports(SysBusDevice *dev, pio_addr_t ioport, pio_addr_t size);
void sysbus_connect_irq(SysBusDevice *dev, int n, qemu_irq irq);
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCHv6 08/16] Add get_fw_dev_path callback for pci bus.
2010-11-17 16:43 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-17 16:43 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, blauwirbel, armbru, alex.williamson, mst, kevin
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/pci.c | 108 ++++++++++++++++++++++++++++++++++++++++++++++++-------------
1 files changed, 85 insertions(+), 23 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 438c0d1..8514e15 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -43,12 +43,14 @@
static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent);
static char *pcibus_get_dev_path(DeviceState *dev);
+static char *pcibus_get_fw_dev_path(DeviceState *dev);
struct BusInfo pci_bus_info = {
.name = "PCI",
.size = sizeof(PCIBus),
.print_dev = pcibus_dev_print,
.get_dev_path = pcibus_get_dev_path,
+ .get_fw_dev_path = pcibus_get_fw_dev_path,
.props = (Property[]) {
DEFINE_PROP_PCI_DEVFN("addr", PCIDevice, devfn, -1),
DEFINE_PROP_STRING("romfile", PCIDevice, romfile),
@@ -1061,45 +1063,63 @@ void pci_msi_notify(PCIDevice *dev, unsigned int vector)
typedef struct {
uint16_t class;
const char *desc;
+ const char *fw_name;
+ uint16_t fw_ign_bits;
} pci_class_desc;
static const pci_class_desc pci_class_descriptions[] =
{
- { 0x0100, "SCSI controller"},
- { 0x0101, "IDE controller"},
- { 0x0102, "Floppy controller"},
- { 0x0103, "IPI controller"},
- { 0x0104, "RAID controller"},
+ { 0x0001, "VGA controller", "display"},
+ { 0x0100, "SCSI controller", "scsi"},
+ { 0x0101, "IDE controller", "ide"},
+ { 0x0102, "Floppy controller", "fdc"},
+ { 0x0103, "IPI controller", "ipi"},
+ { 0x0104, "RAID controller", "raid"},
{ 0x0106, "SATA controller"},
{ 0x0107, "SAS controller"},
{ 0x0180, "Storage controller"},
- { 0x0200, "Ethernet controller"},
- { 0x0201, "Token Ring controller"},
- { 0x0202, "FDDI controller"},
- { 0x0203, "ATM controller"},
+ { 0x0200, "Ethernet controller", "ethernet"},
+ { 0x0201, "Token Ring controller", "token-ring"},
+ { 0x0202, "FDDI controller", "fddi"},
+ { 0x0203, "ATM controller", "atm"},
{ 0x0280, "Network controller"},
- { 0x0300, "VGA controller"},
+ { 0x0300, "VGA controller", "display", 0x00ff},
{ 0x0301, "XGA controller"},
{ 0x0302, "3D controller"},
{ 0x0380, "Display controller"},
- { 0x0400, "Video controller"},
- { 0x0401, "Audio controller"},
+ { 0x0400, "Video controller", "video"},
+ { 0x0401, "Audio controller", "sound"},
{ 0x0402, "Phone"},
{ 0x0480, "Multimedia controller"},
- { 0x0500, "RAM controller"},
- { 0x0501, "Flash controller"},
+ { 0x0500, "RAM controller", "memory"},
+ { 0x0501, "Flash controller", "flash"},
{ 0x0580, "Memory controller"},
- { 0x0600, "Host bridge"},
- { 0x0601, "ISA bridge"},
- { 0x0602, "EISA bridge"},
- { 0x0603, "MC bridge"},
- { 0x0604, "PCI bridge"},
- { 0x0605, "PCMCIA bridge"},
- { 0x0606, "NUBUS bridge"},
- { 0x0607, "CARDBUS bridge"},
+ { 0x0600, "Host bridge", "host"},
+ { 0x0601, "ISA bridge", "isa"},
+ { 0x0602, "EISA bridge", "eisa"},
+ { 0x0603, "MC bridge", "mca"},
+ { 0x0604, "PCI bridge", "pci"},
+ { 0x0605, "PCMCIA bridge", "pcmcia"},
+ { 0x0606, "NUBUS bridge", "nubus"},
+ { 0x0607, "CARDBUS bridge", "cardbus"},
{ 0x0608, "RACEWAY bridge"},
{ 0x0680, "Bridge"},
- { 0x0c03, "USB controller"},
+ { 0x0700, "Serial port", "serial"},
+ { 0x0701, "Parallel port", "parallel"},
+ { 0x0800, "Interrupt controller", "interrupt-controller"},
+ { 0x0801, "DMA controller", "dma-controller"},
+ { 0x0802, "Timer", "timer"},
+ { 0x0803, "RTC", "rtc"},
+ { 0x0900, "Keyboard", "keyboard"},
+ { 0x0901, "Pen", "pen"},
+ { 0x0902, "Mouse", "mouse"},
+ { 0x0A00, "Dock station", "dock", 0x00ff},
+ { 0x0B00, "i386 cpu", "cpu", 0x00ff},
+ { 0x0c00, "Fireware contorller", "fireware"},
+ { 0x0c01, "Access bus controller", "access-bus"},
+ { 0x0c02, "SSA controller", "ssa"},
+ { 0x0c03, "USB controller", "usb"},
+ { 0x0c04, "Fibre channel controller", "fibre-channel"},
{ 0, NULL}
};
@@ -1828,6 +1848,48 @@ static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
}
}
+static char *pci_dev_fw_name(DeviceState *dev, char *buf, int len)
+{
+ PCIDevice *d = (PCIDevice *)dev;
+ const char *name = NULL;
+ const pci_class_desc *desc = pci_class_descriptions;
+ int class = pci_get_word(d->config + PCI_CLASS_DEVICE);
+
+ while (desc->desc &&
+ (class & ~desc->fw_ign_bits) !=
+ (desc->class & ~desc->fw_ign_bits)) {
+ desc++;
+ }
+
+ if (desc->desc) {
+ name = desc->fw_name;
+ }
+
+ if (name) {
+ pstrcpy(buf, len, name);
+ } else {
+ snprintf(buf, len, "pci%04x,%04x",
+ pci_get_word(d->config + PCI_VENDOR_ID),
+ pci_get_word(d->config + PCI_DEVICE_ID));
+ }
+
+ return buf;
+}
+
+static char *pcibus_get_fw_dev_path(DeviceState *dev)
+{
+ PCIDevice *d = (PCIDevice *)dev;
+ char path[50], name[33];
+ int off;
+
+ off = snprintf(path, sizeof(path), "%s@%x",
+ pci_dev_fw_name(dev, name, sizeof name),
+ PCI_SLOT(d->devfn));
+ if (PCI_FUNC(d->devfn))
+ snprintf(path + off, sizeof(path) + off, ",%x", PCI_FUNC(d->devfn));
+ return strdup(path);
+}
+
static char *pcibus_get_dev_path(DeviceState *dev)
{
PCIDevice *d = (PCIDevice *)dev;
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread* [Qemu-devel] [PATCHv6 08/16] Add get_fw_dev_path callback for pci bus.
@ 2010-11-17 16:43 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, mst, armbru, blauwirbel, alex.williamson, kevin
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/pci.c | 108 ++++++++++++++++++++++++++++++++++++++++++++++++-------------
1 files changed, 85 insertions(+), 23 deletions(-)
diff --git a/hw/pci.c b/hw/pci.c
index 438c0d1..8514e15 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -43,12 +43,14 @@
static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent);
static char *pcibus_get_dev_path(DeviceState *dev);
+static char *pcibus_get_fw_dev_path(DeviceState *dev);
struct BusInfo pci_bus_info = {
.name = "PCI",
.size = sizeof(PCIBus),
.print_dev = pcibus_dev_print,
.get_dev_path = pcibus_get_dev_path,
+ .get_fw_dev_path = pcibus_get_fw_dev_path,
.props = (Property[]) {
DEFINE_PROP_PCI_DEVFN("addr", PCIDevice, devfn, -1),
DEFINE_PROP_STRING("romfile", PCIDevice, romfile),
@@ -1061,45 +1063,63 @@ void pci_msi_notify(PCIDevice *dev, unsigned int vector)
typedef struct {
uint16_t class;
const char *desc;
+ const char *fw_name;
+ uint16_t fw_ign_bits;
} pci_class_desc;
static const pci_class_desc pci_class_descriptions[] =
{
- { 0x0100, "SCSI controller"},
- { 0x0101, "IDE controller"},
- { 0x0102, "Floppy controller"},
- { 0x0103, "IPI controller"},
- { 0x0104, "RAID controller"},
+ { 0x0001, "VGA controller", "display"},
+ { 0x0100, "SCSI controller", "scsi"},
+ { 0x0101, "IDE controller", "ide"},
+ { 0x0102, "Floppy controller", "fdc"},
+ { 0x0103, "IPI controller", "ipi"},
+ { 0x0104, "RAID controller", "raid"},
{ 0x0106, "SATA controller"},
{ 0x0107, "SAS controller"},
{ 0x0180, "Storage controller"},
- { 0x0200, "Ethernet controller"},
- { 0x0201, "Token Ring controller"},
- { 0x0202, "FDDI controller"},
- { 0x0203, "ATM controller"},
+ { 0x0200, "Ethernet controller", "ethernet"},
+ { 0x0201, "Token Ring controller", "token-ring"},
+ { 0x0202, "FDDI controller", "fddi"},
+ { 0x0203, "ATM controller", "atm"},
{ 0x0280, "Network controller"},
- { 0x0300, "VGA controller"},
+ { 0x0300, "VGA controller", "display", 0x00ff},
{ 0x0301, "XGA controller"},
{ 0x0302, "3D controller"},
{ 0x0380, "Display controller"},
- { 0x0400, "Video controller"},
- { 0x0401, "Audio controller"},
+ { 0x0400, "Video controller", "video"},
+ { 0x0401, "Audio controller", "sound"},
{ 0x0402, "Phone"},
{ 0x0480, "Multimedia controller"},
- { 0x0500, "RAM controller"},
- { 0x0501, "Flash controller"},
+ { 0x0500, "RAM controller", "memory"},
+ { 0x0501, "Flash controller", "flash"},
{ 0x0580, "Memory controller"},
- { 0x0600, "Host bridge"},
- { 0x0601, "ISA bridge"},
- { 0x0602, "EISA bridge"},
- { 0x0603, "MC bridge"},
- { 0x0604, "PCI bridge"},
- { 0x0605, "PCMCIA bridge"},
- { 0x0606, "NUBUS bridge"},
- { 0x0607, "CARDBUS bridge"},
+ { 0x0600, "Host bridge", "host"},
+ { 0x0601, "ISA bridge", "isa"},
+ { 0x0602, "EISA bridge", "eisa"},
+ { 0x0603, "MC bridge", "mca"},
+ { 0x0604, "PCI bridge", "pci"},
+ { 0x0605, "PCMCIA bridge", "pcmcia"},
+ { 0x0606, "NUBUS bridge", "nubus"},
+ { 0x0607, "CARDBUS bridge", "cardbus"},
{ 0x0608, "RACEWAY bridge"},
{ 0x0680, "Bridge"},
- { 0x0c03, "USB controller"},
+ { 0x0700, "Serial port", "serial"},
+ { 0x0701, "Parallel port", "parallel"},
+ { 0x0800, "Interrupt controller", "interrupt-controller"},
+ { 0x0801, "DMA controller", "dma-controller"},
+ { 0x0802, "Timer", "timer"},
+ { 0x0803, "RTC", "rtc"},
+ { 0x0900, "Keyboard", "keyboard"},
+ { 0x0901, "Pen", "pen"},
+ { 0x0902, "Mouse", "mouse"},
+ { 0x0A00, "Dock station", "dock", 0x00ff},
+ { 0x0B00, "i386 cpu", "cpu", 0x00ff},
+ { 0x0c00, "Fireware contorller", "fireware"},
+ { 0x0c01, "Access bus controller", "access-bus"},
+ { 0x0c02, "SSA controller", "ssa"},
+ { 0x0c03, "USB controller", "usb"},
+ { 0x0c04, "Fibre channel controller", "fibre-channel"},
{ 0, NULL}
};
@@ -1828,6 +1848,48 @@ static void pcibus_dev_print(Monitor *mon, DeviceState *dev, int indent)
}
}
+static char *pci_dev_fw_name(DeviceState *dev, char *buf, int len)
+{
+ PCIDevice *d = (PCIDevice *)dev;
+ const char *name = NULL;
+ const pci_class_desc *desc = pci_class_descriptions;
+ int class = pci_get_word(d->config + PCI_CLASS_DEVICE);
+
+ while (desc->desc &&
+ (class & ~desc->fw_ign_bits) !=
+ (desc->class & ~desc->fw_ign_bits)) {
+ desc++;
+ }
+
+ if (desc->desc) {
+ name = desc->fw_name;
+ }
+
+ if (name) {
+ pstrcpy(buf, len, name);
+ } else {
+ snprintf(buf, len, "pci%04x,%04x",
+ pci_get_word(d->config + PCI_VENDOR_ID),
+ pci_get_word(d->config + PCI_DEVICE_ID));
+ }
+
+ return buf;
+}
+
+static char *pcibus_get_fw_dev_path(DeviceState *dev)
+{
+ PCIDevice *d = (PCIDevice *)dev;
+ char path[50], name[33];
+ int off;
+
+ off = snprintf(path, sizeof(path), "%s@%x",
+ pci_dev_fw_name(dev, name, sizeof name),
+ PCI_SLOT(d->devfn));
+ if (PCI_FUNC(d->devfn))
+ snprintf(path + off, sizeof(path) + off, ",%x", PCI_FUNC(d->devfn));
+ return strdup(path);
+}
+
static char *pcibus_get_dev_path(DeviceState *dev)
{
PCIDevice *d = (PCIDevice *)dev;
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCHv6 09/16] Record which USBDevice USBPort belongs too.
2010-11-17 16:43 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-17 16:43 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, blauwirbel, armbru, alex.williamson, mst, kevin
Ports on root hub will have NULL here. This is needed to reconstruct
path from device to its root hub to build device path.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/usb-bus.c | 3 ++-
hw/usb-hub.c | 2 +-
hw/usb-musb.c | 2 +-
hw/usb-ohci.c | 2 +-
hw/usb-uhci.c | 2 +-
hw/usb.h | 3 ++-
6 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index b692503..256b881 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -110,11 +110,12 @@ USBDevice *usb_create_simple(USBBus *bus, const char *name)
}
void usb_register_port(USBBus *bus, USBPort *port, void *opaque, int index,
- usb_attachfn attach)
+ USBDevice *pdev, usb_attachfn attach)
{
port->opaque = opaque;
port->index = index;
port->attach = attach;
+ port->pdev = pdev;
QTAILQ_INSERT_TAIL(&bus->free, port, next);
bus->nfree++;
}
diff --git a/hw/usb-hub.c b/hw/usb-hub.c
index 8e3a96b..8a3f829 100644
--- a/hw/usb-hub.c
+++ b/hw/usb-hub.c
@@ -535,7 +535,7 @@ static int usb_hub_initfn(USBDevice *dev)
for (i = 0; i < s->nb_ports; i++) {
port = &s->ports[i];
usb_register_port(usb_bus_from_device(dev),
- &port->port, s, i, usb_hub_attach);
+ &port->port, s, i, &s->dev, usb_hub_attach);
port->wPortStatus = PORT_STAT_POWER;
port->wPortChange = 0;
}
diff --git a/hw/usb-musb.c b/hw/usb-musb.c
index 7f15842..9efe7a6 100644
--- a/hw/usb-musb.c
+++ b/hw/usb-musb.c
@@ -343,7 +343,7 @@ struct MUSBState {
}
usb_bus_new(&s->bus, NULL /* FIXME */);
- usb_register_port(&s->bus, &s->port, s, 0, musb_attach);
+ usb_register_port(&s->bus, &s->port, s, 0, NULL, musb_attach);
return s;
}
diff --git a/hw/usb-ohci.c b/hw/usb-ohci.c
index c60fd8d..59604cf 100644
--- a/hw/usb-ohci.c
+++ b/hw/usb-ohci.c
@@ -1705,7 +1705,7 @@ static void usb_ohci_init(OHCIState *ohci, DeviceState *dev,
usb_bus_new(&ohci->bus, dev);
ohci->num_ports = num_ports;
for (i = 0; i < num_ports; i++) {
- usb_register_port(&ohci->bus, &ohci->rhport[i].port, ohci, i, ohci_attach);
+ usb_register_port(&ohci->bus, &ohci->rhport[i].port, ohci, i, NULL, ohci_attach);
}
ohci->async_td = 0;
diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 1d83400..b9b822f 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -1115,7 +1115,7 @@ static int usb_uhci_common_initfn(UHCIState *s)
usb_bus_new(&s->bus, &s->dev.qdev);
for(i = 0; i < NB_PORTS; i++) {
- usb_register_port(&s->bus, &s->ports[i].port, s, i, uhci_attach);
+ usb_register_port(&s->bus, &s->ports[i].port, s, i, NULL, uhci_attach);
}
s->frame_timer = qemu_new_timer(vm_clock, uhci_frame_timer, s);
s->expire_time = qemu_get_clock(vm_clock) +
diff --git a/hw/usb.h b/hw/usb.h
index 00d2802..0b32d77 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -203,6 +203,7 @@ struct USBPort {
USBDevice *dev;
usb_attachfn attach;
void *opaque;
+ USBDevice *pdev;
int index; /* internal port index, may be used with the opaque */
QTAILQ_ENTRY(USBPort) next;
};
@@ -312,7 +313,7 @@ USBDevice *usb_create(USBBus *bus, const char *name);
USBDevice *usb_create_simple(USBBus *bus, const char *name);
USBDevice *usbdevice_create(const char *cmdline);
void usb_register_port(USBBus *bus, USBPort *port, void *opaque, int index,
- usb_attachfn attach);
+ USBDevice *pdev, usb_attachfn attach);
void usb_unregister_port(USBBus *bus, USBPort *port);
int usb_device_attach(USBDevice *dev);
int usb_device_detach(USBDevice *dev);
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread* [Qemu-devel] [PATCHv6 09/16] Record which USBDevice USBPort belongs too.
@ 2010-11-17 16:43 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, mst, armbru, blauwirbel, alex.williamson, kevin
Ports on root hub will have NULL here. This is needed to reconstruct
path from device to its root hub to build device path.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/usb-bus.c | 3 ++-
hw/usb-hub.c | 2 +-
hw/usb-musb.c | 2 +-
hw/usb-ohci.c | 2 +-
hw/usb-uhci.c | 2 +-
hw/usb.h | 3 ++-
6 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index b692503..256b881 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -110,11 +110,12 @@ USBDevice *usb_create_simple(USBBus *bus, const char *name)
}
void usb_register_port(USBBus *bus, USBPort *port, void *opaque, int index,
- usb_attachfn attach)
+ USBDevice *pdev, usb_attachfn attach)
{
port->opaque = opaque;
port->index = index;
port->attach = attach;
+ port->pdev = pdev;
QTAILQ_INSERT_TAIL(&bus->free, port, next);
bus->nfree++;
}
diff --git a/hw/usb-hub.c b/hw/usb-hub.c
index 8e3a96b..8a3f829 100644
--- a/hw/usb-hub.c
+++ b/hw/usb-hub.c
@@ -535,7 +535,7 @@ static int usb_hub_initfn(USBDevice *dev)
for (i = 0; i < s->nb_ports; i++) {
port = &s->ports[i];
usb_register_port(usb_bus_from_device(dev),
- &port->port, s, i, usb_hub_attach);
+ &port->port, s, i, &s->dev, usb_hub_attach);
port->wPortStatus = PORT_STAT_POWER;
port->wPortChange = 0;
}
diff --git a/hw/usb-musb.c b/hw/usb-musb.c
index 7f15842..9efe7a6 100644
--- a/hw/usb-musb.c
+++ b/hw/usb-musb.c
@@ -343,7 +343,7 @@ struct MUSBState {
}
usb_bus_new(&s->bus, NULL /* FIXME */);
- usb_register_port(&s->bus, &s->port, s, 0, musb_attach);
+ usb_register_port(&s->bus, &s->port, s, 0, NULL, musb_attach);
return s;
}
diff --git a/hw/usb-ohci.c b/hw/usb-ohci.c
index c60fd8d..59604cf 100644
--- a/hw/usb-ohci.c
+++ b/hw/usb-ohci.c
@@ -1705,7 +1705,7 @@ static void usb_ohci_init(OHCIState *ohci, DeviceState *dev,
usb_bus_new(&ohci->bus, dev);
ohci->num_ports = num_ports;
for (i = 0; i < num_ports; i++) {
- usb_register_port(&ohci->bus, &ohci->rhport[i].port, ohci, i, ohci_attach);
+ usb_register_port(&ohci->bus, &ohci->rhport[i].port, ohci, i, NULL, ohci_attach);
}
ohci->async_td = 0;
diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c
index 1d83400..b9b822f 100644
--- a/hw/usb-uhci.c
+++ b/hw/usb-uhci.c
@@ -1115,7 +1115,7 @@ static int usb_uhci_common_initfn(UHCIState *s)
usb_bus_new(&s->bus, &s->dev.qdev);
for(i = 0; i < NB_PORTS; i++) {
- usb_register_port(&s->bus, &s->ports[i].port, s, i, uhci_attach);
+ usb_register_port(&s->bus, &s->ports[i].port, s, i, NULL, uhci_attach);
}
s->frame_timer = qemu_new_timer(vm_clock, uhci_frame_timer, s);
s->expire_time = qemu_get_clock(vm_clock) +
diff --git a/hw/usb.h b/hw/usb.h
index 00d2802..0b32d77 100644
--- a/hw/usb.h
+++ b/hw/usb.h
@@ -203,6 +203,7 @@ struct USBPort {
USBDevice *dev;
usb_attachfn attach;
void *opaque;
+ USBDevice *pdev;
int index; /* internal port index, may be used with the opaque */
QTAILQ_ENTRY(USBPort) next;
};
@@ -312,7 +313,7 @@ USBDevice *usb_create(USBBus *bus, const char *name);
USBDevice *usb_create_simple(USBBus *bus, const char *name);
USBDevice *usbdevice_create(const char *cmdline);
void usb_register_port(USBBus *bus, USBPort *port, void *opaque, int index,
- usb_attachfn attach);
+ USBDevice *pdev, usb_attachfn attach);
void usb_unregister_port(USBBus *bus, USBPort *port);
int usb_device_attach(USBDevice *dev);
int usb_device_detach(USBDevice *dev);
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCHv6 10/16] Add get_dev_path callback for usb bus.
2010-11-17 16:43 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-17 16:43 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, blauwirbel, armbru, alex.williamson, mst, kevin
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/usb-bus.c | 42 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index 256b881..8b4583c 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -5,11 +5,13 @@
#include "monitor.h"
static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent);
+static char *usbbus_get_fw_dev_path(DeviceState *dev);
static struct BusInfo usb_bus_info = {
.name = "USB",
.size = sizeof(USBBus),
.print_dev = usb_bus_dev_print,
+ .get_fw_dev_path = usbbus_get_fw_dev_path,
};
static int next_usb_bus = 0;
static QTAILQ_HEAD(, USBBus) busses = QTAILQ_HEAD_INITIALIZER(busses);
@@ -307,3 +309,43 @@ USBDevice *usbdevice_create(const char *cmdline)
}
return usb->usbdevice_init(params);
}
+
+static int usbbus_get_fw_dev_path_helper(USBDevice *d, USBBus *bus, char *p,
+ int len)
+{
+ int l = 0;
+ USBPort *port;
+
+ QTAILQ_FOREACH(port, &bus->used, next) {
+ if (port->dev == d) {
+ if (port->pdev) {
+ l = usbbus_get_fw_dev_path_helper(port->pdev, bus, p, len);
+ }
+ l += snprintf(p + l, len - l, "%s@%x/", qdev_fw_name(&d->qdev),
+ port->index);
+ break;
+ }
+ }
+
+ return l;
+}
+
+static char *usbbus_get_fw_dev_path(DeviceState *dev)
+{
+ USBDevice *d = (USBDevice*)dev;
+ USBBus *bus = usb_bus_from_device(d);
+ char path[100];
+ int l;
+
+ assert(d->attached != 0);
+
+ l = usbbus_get_fw_dev_path_helper(d, bus, path, sizeof(path));
+
+ if (l == 0) {
+ abort();
+ }
+
+ path[l-1] = '\0';
+
+ return strdup(path);
+}
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread* [Qemu-devel] [PATCHv6 10/16] Add get_dev_path callback for usb bus.
@ 2010-11-17 16:43 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, mst, armbru, blauwirbel, alex.williamson, kevin
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/usb-bus.c | 42 ++++++++++++++++++++++++++++++++++++++++++
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/hw/usb-bus.c b/hw/usb-bus.c
index 256b881..8b4583c 100644
--- a/hw/usb-bus.c
+++ b/hw/usb-bus.c
@@ -5,11 +5,13 @@
#include "monitor.h"
static void usb_bus_dev_print(Monitor *mon, DeviceState *qdev, int indent);
+static char *usbbus_get_fw_dev_path(DeviceState *dev);
static struct BusInfo usb_bus_info = {
.name = "USB",
.size = sizeof(USBBus),
.print_dev = usb_bus_dev_print,
+ .get_fw_dev_path = usbbus_get_fw_dev_path,
};
static int next_usb_bus = 0;
static QTAILQ_HEAD(, USBBus) busses = QTAILQ_HEAD_INITIALIZER(busses);
@@ -307,3 +309,43 @@ USBDevice *usbdevice_create(const char *cmdline)
}
return usb->usbdevice_init(params);
}
+
+static int usbbus_get_fw_dev_path_helper(USBDevice *d, USBBus *bus, char *p,
+ int len)
+{
+ int l = 0;
+ USBPort *port;
+
+ QTAILQ_FOREACH(port, &bus->used, next) {
+ if (port->dev == d) {
+ if (port->pdev) {
+ l = usbbus_get_fw_dev_path_helper(port->pdev, bus, p, len);
+ }
+ l += snprintf(p + l, len - l, "%s@%x/", qdev_fw_name(&d->qdev),
+ port->index);
+ break;
+ }
+ }
+
+ return l;
+}
+
+static char *usbbus_get_fw_dev_path(DeviceState *dev)
+{
+ USBDevice *d = (USBDevice*)dev;
+ USBBus *bus = usb_bus_from_device(d);
+ char path[100];
+ int l;
+
+ assert(d->attached != 0);
+
+ l = usbbus_get_fw_dev_path_helper(d, bus, path, sizeof(path));
+
+ if (l == 0) {
+ abort();
+ }
+
+ path[l-1] = '\0';
+
+ return strdup(path);
+}
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCHv6 11/16] Add get_dev_path callback to scsi bus.
2010-11-17 16:43 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-17 16:43 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, blauwirbel, armbru, alex.williamson, mst, kevin
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/scsi-bus.c | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index 5a3fd4b..db7482a 100644
--- a/hw/scsi-bus.c
+++ b/hw/scsi-bus.c
@@ -5,9 +5,12 @@
#include "qdev.h"
#include "blockdev.h"
+static char *scsibus_get_fw_dev_path(DeviceState *dev);
+
static struct BusInfo scsi_bus_info = {
.name = "SCSI",
.size = sizeof(SCSIBus),
+ .get_fw_dev_path = scsibus_get_fw_dev_path,
.props = (Property[]) {
DEFINE_PROP_UINT32("scsi-id", SCSIDevice, id, -1),
DEFINE_PROP_END_OF_LIST(),
@@ -528,3 +531,23 @@ void scsi_req_complete(SCSIRequest *req)
req->tag,
req->status);
}
+
+static char *scsibus_get_fw_dev_path(DeviceState *dev)
+{
+ SCSIDevice *d = (SCSIDevice*)dev;
+ SCSIBus *bus = scsi_bus_from_device(d);
+ char path[100];
+ int i;
+
+ for (i = 0; i < bus->ndev; i++) {
+ if (bus->devs[i] == d) {
+ break;
+ }
+ }
+
+ assert(i != bus->ndev);
+
+ snprintf(path, sizeof(path), "%s@%x", qdev_fw_name(dev), i);
+
+ return strdup(path);
+}
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread* [Qemu-devel] [PATCHv6 11/16] Add get_dev_path callback to scsi bus.
@ 2010-11-17 16:43 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, mst, armbru, blauwirbel, alex.williamson, kevin
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/scsi-bus.c | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index 5a3fd4b..db7482a 100644
--- a/hw/scsi-bus.c
+++ b/hw/scsi-bus.c
@@ -5,9 +5,12 @@
#include "qdev.h"
#include "blockdev.h"
+static char *scsibus_get_fw_dev_path(DeviceState *dev);
+
static struct BusInfo scsi_bus_info = {
.name = "SCSI",
.size = sizeof(SCSIBus),
+ .get_fw_dev_path = scsibus_get_fw_dev_path,
.props = (Property[]) {
DEFINE_PROP_UINT32("scsi-id", SCSIDevice, id, -1),
DEFINE_PROP_END_OF_LIST(),
@@ -528,3 +531,23 @@ void scsi_req_complete(SCSIRequest *req)
req->tag,
req->status);
}
+
+static char *scsibus_get_fw_dev_path(DeviceState *dev)
+{
+ SCSIDevice *d = (SCSIDevice*)dev;
+ SCSIBus *bus = scsi_bus_from_device(d);
+ char path[100];
+ int i;
+
+ for (i = 0; i < bus->ndev; i++) {
+ if (bus->devs[i] == d) {
+ break;
+ }
+ }
+
+ assert(i != bus->ndev);
+
+ snprintf(path, sizeof(path), "%s@%x", qdev_fw_name(dev), i);
+
+ return strdup(path);
+}
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCHv6 12/16] Add bootindex parameter to net/block/fd device
2010-11-17 16:43 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-17 16:43 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, blauwirbel, armbru, alex.williamson, mst, kevin
If bootindex is specified on command line a string that describes device
in firmware readable way is added into sorted list. Later this list will
be passed into firmware to control boot order.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
block_int.h | 4 +++-
hw/e1000.c | 4 ++++
hw/eepro100.c | 3 +++
hw/fdc.c | 8 ++++++++
hw/ide/qdev.c | 5 +++++
hw/ne2000.c | 3 +++
hw/pcnet.c | 4 ++++
hw/qdev.c | 32 ++++++++++++++++++++++++++++++++
hw/qdev.h | 1 +
hw/rtl8139.c | 4 ++++
hw/scsi-disk.c | 1 +
hw/usb-net.c | 2 ++
hw/virtio-blk.c | 2 ++
hw/virtio-net.c | 2 ++
net.h | 4 +++-
sysemu.h | 2 ++
vl.c | 40 ++++++++++++++++++++++++++++++++++++++++
17 files changed, 119 insertions(+), 2 deletions(-)
diff --git a/block_int.h b/block_int.h
index 3c3adb5..0a0e47d 100644
--- a/block_int.h
+++ b/block_int.h
@@ -227,6 +227,7 @@ typedef struct BlockConf {
uint16_t logical_block_size;
uint16_t min_io_size;
uint32_t opt_io_size;
+ int32_t bootindex;
} BlockConf;
static inline unsigned int get_physical_block_exp(BlockConf *conf)
@@ -249,6 +250,7 @@ static inline unsigned int get_physical_block_exp(BlockConf *conf)
DEFINE_PROP_UINT16("physical_block_size", _state, \
_conf.physical_block_size, 512), \
DEFINE_PROP_UINT16("min_io_size", _state, _conf.min_io_size, 0), \
- DEFINE_PROP_UINT32("opt_io_size", _state, _conf.opt_io_size, 0)
+ DEFINE_PROP_UINT32("opt_io_size", _state, _conf.opt_io_size, 0), \
+ DEFINE_PROP_INT32("bootindex", _state, _conf.bootindex, -1) \
#endif /* BLOCK_INT_H */
diff --git a/hw/e1000.c b/hw/e1000.c
index 7811699..34ad136 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -30,6 +30,7 @@
#include "net.h"
#include "net/checksum.h"
#include "loader.h"
+#include "sysemu.h"
#include "e1000_hw.h"
@@ -1154,6 +1155,9 @@ static int pci_e1000_init(PCIDevice *pci_dev)
d->dev.qdev.info->name, d->dev.qdev.id, d);
qemu_format_nic_info_str(&d->nic->nc, macaddr);
+
+ add_boot_device_path(d->conf.bootindex, &pci_dev->qdev, "/ethernet-phy@0");
+
return 0;
}
diff --git a/hw/eepro100.c b/hw/eepro100.c
index 41d792a..ae96204 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -46,6 +46,7 @@
#include "pci.h"
#include "net.h"
#include "eeprom93xx.h"
+#include "sysemu.h"
#define KiB 1024
@@ -1907,6 +1908,8 @@ static int e100_nic_init(PCIDevice *pci_dev)
s->vmstate->name = s->nic->nc.model;
vmstate_register(&pci_dev->qdev, -1, s->vmstate, s);
+ add_boot_device_path(s->conf.bootindex, &pci_dev->qdev, "/ethernet-phy@0");
+
return 0;
}
diff --git a/hw/fdc.c b/hw/fdc.c
index 5ab754b..543aa68 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -35,6 +35,7 @@
#include "sysbus.h"
#include "qdev-addr.h"
#include "blockdev.h"
+#include "sysemu.h"
/********************************************************/
/* debug Floppy devices */
@@ -523,6 +524,8 @@ typedef struct FDCtrlSysBus {
typedef struct FDCtrlISABus {
ISADevice busdev;
struct FDCtrl state;
+ int32_t bootindexA;
+ int32_t bootindexB;
} FDCtrlISABus;
static uint32_t fdctrl_read (void *opaque, uint32_t reg)
@@ -1992,6 +1995,9 @@ static int isabus_fdc_init1(ISADevice *dev)
qdev_set_legacy_instance_id(&dev->qdev, iobase, 2);
ret = fdctrl_init_common(fdctrl);
+ add_boot_device_path(isa->bootindexA, &dev->qdev, "/floppy@0");
+ add_boot_device_path(isa->bootindexB, &dev->qdev, "/floppy@1");
+
return ret;
}
@@ -2051,6 +2057,8 @@ static ISADeviceInfo isa_fdc_info = {
.qdev.props = (Property[]) {
DEFINE_PROP_DRIVE("driveA", FDCtrlISABus, state.drives[0].bs),
DEFINE_PROP_DRIVE("driveB", FDCtrlISABus, state.drives[1].bs),
+ DEFINE_PROP_INT32("bootindexA", FDCtrlISABus, bootindexA, -1),
+ DEFINE_PROP_INT32("bootindexB", FDCtrlISABus, bootindexB, -1),
DEFINE_PROP_END_OF_LIST(),
},
};
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 01a181b..69a00e2 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -21,6 +21,7 @@
#include "qemu-error.h"
#include <hw/ide/internal.h>
#include "blockdev.h"
+#include "sysemu.h"
/* --------------------------------- */
@@ -143,6 +144,10 @@ static int ide_drive_initfn(IDEDevice *dev)
if (!dev->serial) {
dev->serial = qemu_strdup(s->drive_serial_str);
}
+
+ add_boot_device_path(dev->conf.bootindex, &dev->qdev,
+ dev->unit ? "disk@1" : "disk@0");
+
return 0;
}
diff --git a/hw/ne2000.c b/hw/ne2000.c
index 126e7cf..a030106 100644
--- a/hw/ne2000.c
+++ b/hw/ne2000.c
@@ -26,6 +26,7 @@
#include "net.h"
#include "ne2000.h"
#include "loader.h"
+#include "sysemu.h"
/* debug NE2000 card */
//#define DEBUG_NE2000
@@ -746,6 +747,8 @@ static int pci_ne2000_init(PCIDevice *pci_dev)
}
}
+ add_boot_device_path(s->c.bootindex, &pci_dev->qdev, "/ethernet-phy@0");
+
return 0;
}
diff --git a/hw/pcnet.c b/hw/pcnet.c
index b52935a..f100945 100644
--- a/hw/pcnet.c
+++ b/hw/pcnet.c
@@ -40,6 +40,7 @@
#include "loader.h"
#include "qemu-timer.h"
#include "qemu_socket.h"
+#include "sysemu.h"
#include "pcnet.h"
@@ -1898,6 +1899,9 @@ int pcnet_common_init(DeviceState *dev, PCNetState *s, NetClientInfo *info)
qemu_macaddr_default_if_unset(&s->conf.macaddr);
s->nic = qemu_new_nic(info, &s->conf, dev->info->name, dev->id, s);
qemu_format_nic_info_str(&s->nic->nc, s->conf.macaddr.a);
+
+ add_boot_device_path(s->conf.bootindex, dev, "/ethernet-phy@0");
+
return 0;
}
diff --git a/hw/qdev.c b/hw/qdev.c
index 35858cb..cc9bf43 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -820,3 +820,35 @@ int do_device_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
}
return qdev_unplug(dev);
}
+
+static int qdev_get_fw_dev_path_helper(DeviceState *dev, char *p, int size)
+{
+ int l = 0;
+
+ if (dev && dev->parent_bus) {
+ char *d;
+ l = qdev_get_fw_dev_path_helper(dev->parent_bus->parent, p, size);
+ if (dev->parent_bus->info->get_fw_dev_path) {
+ d = dev->parent_bus->info->get_fw_dev_path(dev);
+ l += snprintf(p + l, size - l, "%s", d);
+ qemu_free(d);
+ } else {
+ l += snprintf(p + l, size - l, "%s", dev->info->name);
+ }
+ }
+ l += snprintf(p + l , size - l, "/");
+
+ return l;
+}
+
+char* qdev_get_fw_dev_path(DeviceState *dev)
+{
+ char path[128];
+ int l;
+
+ l = qdev_get_fw_dev_path_helper(dev, path, 128);
+
+ path[l-1] = '\0';
+
+ return strdup(path);
+}
diff --git a/hw/qdev.h b/hw/qdev.h
index dc669b3..13f3597 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -296,6 +296,7 @@ static inline const char *qdev_fw_name(DeviceState *dev)
return dev->info->fw_name ? : dev->info->alias ? : dev->info->name;
}
+char *qdev_get_fw_dev_path(DeviceState *dev);
/* This is a nasty hack to allow passing a NULL bus to qdev_create. */
extern struct BusInfo system_bus_info;
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index d92981d..80a2813 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -52,6 +52,7 @@
#include "qemu-timer.h"
#include "net.h"
#include "loader.h"
+#include "sysemu.h"
/* debug RTL8139 card */
//#define DEBUG_RTL8139 1
@@ -3387,6 +3388,9 @@ static int pci_rtl8139_init(PCIDevice *dev)
s->TimerExpire = 0;
s->timer = qemu_new_timer(vm_clock, rtl8139_timer, s);
rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
+
+ add_boot_device_path(s->conf.bootindex, &dev->qdev, "/ethernet-phy@0");
+
return 0;
}
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 2b22777..705ebf8 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -1230,6 +1230,7 @@ static int scsi_disk_initfn(SCSIDevice *dev)
s->qdev.type = TYPE_DISK;
qemu_add_vm_change_state_handler(scsi_dma_restart_cb, s);
bdrv_set_removable(s->bs, is_cd);
+ add_boot_device_path(s->qdev.conf.bootindex, &dev->qdev, ",0");
return 0;
}
diff --git a/hw/usb-net.c b/hw/usb-net.c
index f6bed21..8492455 100644
--- a/hw/usb-net.c
+++ b/hw/usb-net.c
@@ -27,6 +27,7 @@
#include "usb.h"
#include "net.h"
#include "qemu-queue.h"
+#include "sysemu.h"
/*#define TRAFFIC_DEBUG*/
/* Thanks to NetChip Technologies for donating this product ID.
@@ -1463,6 +1464,7 @@ static int usb_net_initfn(USBDevice *dev)
s->conf.macaddr.a[4],
s->conf.macaddr.a[5]);
+ add_boot_device_path(s->conf.bootindex, &dev->qdev, "/ethernet@0");
return 0;
}
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 49528a9..c48dda5 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -548,6 +548,8 @@ VirtIODevice *virtio_blk_init(DeviceState *dev, BlockConf *conf)
bdrv_set_removable(s->bs, 0);
s->bs->buffer_alignment = conf->logical_block_size;
+ add_boot_device_path(conf->bootindex, dev, "/disk@0,0");
+
return &s->vdev;
}
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 7e1688c..b67c9ee 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -1018,6 +1018,8 @@ VirtIODevice *virtio_net_init(DeviceState *dev, NICConf *conf,
virtio_net_save, virtio_net_load, n);
n->vmstate = qemu_add_vm_change_state_handler(virtio_net_vmstate_change, n);
+ add_boot_device_path(conf->bootindex, dev, "/ethernet-phy@0");
+
return &n->vdev;
}
diff --git a/net.h b/net.h
index 44c31a9..6ceca50 100644
--- a/net.h
+++ b/net.h
@@ -17,12 +17,14 @@ typedef struct NICConf {
MACAddr macaddr;
VLANState *vlan;
VLANClientState *peer;
+ int32_t bootindex;
} NICConf;
#define DEFINE_NIC_PROPERTIES(_state, _conf) \
DEFINE_PROP_MACADDR("mac", _state, _conf.macaddr), \
DEFINE_PROP_VLAN("vlan", _state, _conf.vlan), \
- DEFINE_PROP_NETDEV("netdev", _state, _conf.peer)
+ DEFINE_PROP_NETDEV("netdev", _state, _conf.peer), \
+ DEFINE_PROP_INT32("bootindex", _state, _conf.bootindex, -1)
/* VLANs support */
diff --git a/sysemu.h b/sysemu.h
index b81a70e..fe9a582 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -188,4 +188,6 @@ void rtc_change_mon_event(struct tm *tm);
void register_devices(void);
+void add_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix);
#endif
diff --git a/vl.c b/vl.c
index 9ee6479..4e5d146 100644
--- a/vl.c
+++ b/vl.c
@@ -228,6 +228,17 @@ unsigned int nb_prom_envs = 0;
const char *prom_envs[MAX_PROM_ENVS];
int boot_menu;
+typedef struct FWBootEntry FWBootEntry;
+
+struct FWBootEntry {
+ QTAILQ_ENTRY(FWBootEntry) link;
+ int32_t bootindex;
+ DeviceState *dev;
+ char *suffix;
+};
+
+QTAILQ_HEAD(, FWBootEntry) fw_boot_order = QTAILQ_HEAD_INITIALIZER(fw_boot_order);
+
int nb_numa_nodes;
uint64_t node_mem[MAX_NODES];
uint64_t node_cpumask[MAX_NODES];
@@ -692,6 +703,35 @@ static void restore_boot_devices(void *opaque)
qemu_free(standard_boot_devices);
}
+void add_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix)
+{
+ FWBootEntry *node, *i;
+
+ if (bootindex < 0) {
+ return;
+ }
+
+ assert(dev != NULL || suffix != NULL);
+
+ node = qemu_mallocz(sizeof(FWBootEntry));
+ node->bootindex = bootindex;
+ node->suffix = strdup(suffix);
+ node->dev = dev;
+
+ QTAILQ_FOREACH(i, &fw_boot_order, link) {
+ if (i->bootindex == bootindex) {
+ fprintf(stderr, "Two devices with same boot index %d\n", bootindex);
+ exit(1);
+ } else if (i->bootindex < bootindex) {
+ continue;
+ }
+ QTAILQ_INSERT_BEFORE(i, node, link);
+ return;
+ }
+ QTAILQ_INSERT_TAIL(&fw_boot_order, node, link);
+}
+
static void numa_add(const char *optarg)
{
char option[128];
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread* [Qemu-devel] [PATCHv6 12/16] Add bootindex parameter to net/block/fd device
@ 2010-11-17 16:43 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:43 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, mst, armbru, blauwirbel, alex.williamson, kevin
If bootindex is specified on command line a string that describes device
in firmware readable way is added into sorted list. Later this list will
be passed into firmware to control boot order.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
block_int.h | 4 +++-
hw/e1000.c | 4 ++++
hw/eepro100.c | 3 +++
hw/fdc.c | 8 ++++++++
hw/ide/qdev.c | 5 +++++
hw/ne2000.c | 3 +++
hw/pcnet.c | 4 ++++
hw/qdev.c | 32 ++++++++++++++++++++++++++++++++
hw/qdev.h | 1 +
hw/rtl8139.c | 4 ++++
hw/scsi-disk.c | 1 +
hw/usb-net.c | 2 ++
hw/virtio-blk.c | 2 ++
hw/virtio-net.c | 2 ++
net.h | 4 +++-
sysemu.h | 2 ++
vl.c | 40 ++++++++++++++++++++++++++++++++++++++++
17 files changed, 119 insertions(+), 2 deletions(-)
diff --git a/block_int.h b/block_int.h
index 3c3adb5..0a0e47d 100644
--- a/block_int.h
+++ b/block_int.h
@@ -227,6 +227,7 @@ typedef struct BlockConf {
uint16_t logical_block_size;
uint16_t min_io_size;
uint32_t opt_io_size;
+ int32_t bootindex;
} BlockConf;
static inline unsigned int get_physical_block_exp(BlockConf *conf)
@@ -249,6 +250,7 @@ static inline unsigned int get_physical_block_exp(BlockConf *conf)
DEFINE_PROP_UINT16("physical_block_size", _state, \
_conf.physical_block_size, 512), \
DEFINE_PROP_UINT16("min_io_size", _state, _conf.min_io_size, 0), \
- DEFINE_PROP_UINT32("opt_io_size", _state, _conf.opt_io_size, 0)
+ DEFINE_PROP_UINT32("opt_io_size", _state, _conf.opt_io_size, 0), \
+ DEFINE_PROP_INT32("bootindex", _state, _conf.bootindex, -1) \
#endif /* BLOCK_INT_H */
diff --git a/hw/e1000.c b/hw/e1000.c
index 7811699..34ad136 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -30,6 +30,7 @@
#include "net.h"
#include "net/checksum.h"
#include "loader.h"
+#include "sysemu.h"
#include "e1000_hw.h"
@@ -1154,6 +1155,9 @@ static int pci_e1000_init(PCIDevice *pci_dev)
d->dev.qdev.info->name, d->dev.qdev.id, d);
qemu_format_nic_info_str(&d->nic->nc, macaddr);
+
+ add_boot_device_path(d->conf.bootindex, &pci_dev->qdev, "/ethernet-phy@0");
+
return 0;
}
diff --git a/hw/eepro100.c b/hw/eepro100.c
index 41d792a..ae96204 100644
--- a/hw/eepro100.c
+++ b/hw/eepro100.c
@@ -46,6 +46,7 @@
#include "pci.h"
#include "net.h"
#include "eeprom93xx.h"
+#include "sysemu.h"
#define KiB 1024
@@ -1907,6 +1908,8 @@ static int e100_nic_init(PCIDevice *pci_dev)
s->vmstate->name = s->nic->nc.model;
vmstate_register(&pci_dev->qdev, -1, s->vmstate, s);
+ add_boot_device_path(s->conf.bootindex, &pci_dev->qdev, "/ethernet-phy@0");
+
return 0;
}
diff --git a/hw/fdc.c b/hw/fdc.c
index 5ab754b..543aa68 100644
--- a/hw/fdc.c
+++ b/hw/fdc.c
@@ -35,6 +35,7 @@
#include "sysbus.h"
#include "qdev-addr.h"
#include "blockdev.h"
+#include "sysemu.h"
/********************************************************/
/* debug Floppy devices */
@@ -523,6 +524,8 @@ typedef struct FDCtrlSysBus {
typedef struct FDCtrlISABus {
ISADevice busdev;
struct FDCtrl state;
+ int32_t bootindexA;
+ int32_t bootindexB;
} FDCtrlISABus;
static uint32_t fdctrl_read (void *opaque, uint32_t reg)
@@ -1992,6 +1995,9 @@ static int isabus_fdc_init1(ISADevice *dev)
qdev_set_legacy_instance_id(&dev->qdev, iobase, 2);
ret = fdctrl_init_common(fdctrl);
+ add_boot_device_path(isa->bootindexA, &dev->qdev, "/floppy@0");
+ add_boot_device_path(isa->bootindexB, &dev->qdev, "/floppy@1");
+
return ret;
}
@@ -2051,6 +2057,8 @@ static ISADeviceInfo isa_fdc_info = {
.qdev.props = (Property[]) {
DEFINE_PROP_DRIVE("driveA", FDCtrlISABus, state.drives[0].bs),
DEFINE_PROP_DRIVE("driveB", FDCtrlISABus, state.drives[1].bs),
+ DEFINE_PROP_INT32("bootindexA", FDCtrlISABus, bootindexA, -1),
+ DEFINE_PROP_INT32("bootindexB", FDCtrlISABus, bootindexB, -1),
DEFINE_PROP_END_OF_LIST(),
},
};
diff --git a/hw/ide/qdev.c b/hw/ide/qdev.c
index 01a181b..69a00e2 100644
--- a/hw/ide/qdev.c
+++ b/hw/ide/qdev.c
@@ -21,6 +21,7 @@
#include "qemu-error.h"
#include <hw/ide/internal.h>
#include "blockdev.h"
+#include "sysemu.h"
/* --------------------------------- */
@@ -143,6 +144,10 @@ static int ide_drive_initfn(IDEDevice *dev)
if (!dev->serial) {
dev->serial = qemu_strdup(s->drive_serial_str);
}
+
+ add_boot_device_path(dev->conf.bootindex, &dev->qdev,
+ dev->unit ? "disk@1" : "disk@0");
+
return 0;
}
diff --git a/hw/ne2000.c b/hw/ne2000.c
index 126e7cf..a030106 100644
--- a/hw/ne2000.c
+++ b/hw/ne2000.c
@@ -26,6 +26,7 @@
#include "net.h"
#include "ne2000.h"
#include "loader.h"
+#include "sysemu.h"
/* debug NE2000 card */
//#define DEBUG_NE2000
@@ -746,6 +747,8 @@ static int pci_ne2000_init(PCIDevice *pci_dev)
}
}
+ add_boot_device_path(s->c.bootindex, &pci_dev->qdev, "/ethernet-phy@0");
+
return 0;
}
diff --git a/hw/pcnet.c b/hw/pcnet.c
index b52935a..f100945 100644
--- a/hw/pcnet.c
+++ b/hw/pcnet.c
@@ -40,6 +40,7 @@
#include "loader.h"
#include "qemu-timer.h"
#include "qemu_socket.h"
+#include "sysemu.h"
#include "pcnet.h"
@@ -1898,6 +1899,9 @@ int pcnet_common_init(DeviceState *dev, PCNetState *s, NetClientInfo *info)
qemu_macaddr_default_if_unset(&s->conf.macaddr);
s->nic = qemu_new_nic(info, &s->conf, dev->info->name, dev->id, s);
qemu_format_nic_info_str(&s->nic->nc, s->conf.macaddr.a);
+
+ add_boot_device_path(s->conf.bootindex, dev, "/ethernet-phy@0");
+
return 0;
}
diff --git a/hw/qdev.c b/hw/qdev.c
index 35858cb..cc9bf43 100644
--- a/hw/qdev.c
+++ b/hw/qdev.c
@@ -820,3 +820,35 @@ int do_device_del(Monitor *mon, const QDict *qdict, QObject **ret_data)
}
return qdev_unplug(dev);
}
+
+static int qdev_get_fw_dev_path_helper(DeviceState *dev, char *p, int size)
+{
+ int l = 0;
+
+ if (dev && dev->parent_bus) {
+ char *d;
+ l = qdev_get_fw_dev_path_helper(dev->parent_bus->parent, p, size);
+ if (dev->parent_bus->info->get_fw_dev_path) {
+ d = dev->parent_bus->info->get_fw_dev_path(dev);
+ l += snprintf(p + l, size - l, "%s", d);
+ qemu_free(d);
+ } else {
+ l += snprintf(p + l, size - l, "%s", dev->info->name);
+ }
+ }
+ l += snprintf(p + l , size - l, "/");
+
+ return l;
+}
+
+char* qdev_get_fw_dev_path(DeviceState *dev)
+{
+ char path[128];
+ int l;
+
+ l = qdev_get_fw_dev_path_helper(dev, path, 128);
+
+ path[l-1] = '\0';
+
+ return strdup(path);
+}
diff --git a/hw/qdev.h b/hw/qdev.h
index dc669b3..13f3597 100644
--- a/hw/qdev.h
+++ b/hw/qdev.h
@@ -296,6 +296,7 @@ static inline const char *qdev_fw_name(DeviceState *dev)
return dev->info->fw_name ? : dev->info->alias ? : dev->info->name;
}
+char *qdev_get_fw_dev_path(DeviceState *dev);
/* This is a nasty hack to allow passing a NULL bus to qdev_create. */
extern struct BusInfo system_bus_info;
diff --git a/hw/rtl8139.c b/hw/rtl8139.c
index d92981d..80a2813 100644
--- a/hw/rtl8139.c
+++ b/hw/rtl8139.c
@@ -52,6 +52,7 @@
#include "qemu-timer.h"
#include "net.h"
#include "loader.h"
+#include "sysemu.h"
/* debug RTL8139 card */
//#define DEBUG_RTL8139 1
@@ -3387,6 +3388,9 @@ static int pci_rtl8139_init(PCIDevice *dev)
s->TimerExpire = 0;
s->timer = qemu_new_timer(vm_clock, rtl8139_timer, s);
rtl8139_set_next_tctr_time(s, qemu_get_clock(vm_clock));
+
+ add_boot_device_path(s->conf.bootindex, &dev->qdev, "/ethernet-phy@0");
+
return 0;
}
diff --git a/hw/scsi-disk.c b/hw/scsi-disk.c
index 2b22777..705ebf8 100644
--- a/hw/scsi-disk.c
+++ b/hw/scsi-disk.c
@@ -1230,6 +1230,7 @@ static int scsi_disk_initfn(SCSIDevice *dev)
s->qdev.type = TYPE_DISK;
qemu_add_vm_change_state_handler(scsi_dma_restart_cb, s);
bdrv_set_removable(s->bs, is_cd);
+ add_boot_device_path(s->qdev.conf.bootindex, &dev->qdev, ",0");
return 0;
}
diff --git a/hw/usb-net.c b/hw/usb-net.c
index f6bed21..8492455 100644
--- a/hw/usb-net.c
+++ b/hw/usb-net.c
@@ -27,6 +27,7 @@
#include "usb.h"
#include "net.h"
#include "qemu-queue.h"
+#include "sysemu.h"
/*#define TRAFFIC_DEBUG*/
/* Thanks to NetChip Technologies for donating this product ID.
@@ -1463,6 +1464,7 @@ static int usb_net_initfn(USBDevice *dev)
s->conf.macaddr.a[4],
s->conf.macaddr.a[5]);
+ add_boot_device_path(s->conf.bootindex, &dev->qdev, "/ethernet@0");
return 0;
}
diff --git a/hw/virtio-blk.c b/hw/virtio-blk.c
index 49528a9..c48dda5 100644
--- a/hw/virtio-blk.c
+++ b/hw/virtio-blk.c
@@ -548,6 +548,8 @@ VirtIODevice *virtio_blk_init(DeviceState *dev, BlockConf *conf)
bdrv_set_removable(s->bs, 0);
s->bs->buffer_alignment = conf->logical_block_size;
+ add_boot_device_path(conf->bootindex, dev, "/disk@0,0");
+
return &s->vdev;
}
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index 7e1688c..b67c9ee 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -1018,6 +1018,8 @@ VirtIODevice *virtio_net_init(DeviceState *dev, NICConf *conf,
virtio_net_save, virtio_net_load, n);
n->vmstate = qemu_add_vm_change_state_handler(virtio_net_vmstate_change, n);
+ add_boot_device_path(conf->bootindex, dev, "/ethernet-phy@0");
+
return &n->vdev;
}
diff --git a/net.h b/net.h
index 44c31a9..6ceca50 100644
--- a/net.h
+++ b/net.h
@@ -17,12 +17,14 @@ typedef struct NICConf {
MACAddr macaddr;
VLANState *vlan;
VLANClientState *peer;
+ int32_t bootindex;
} NICConf;
#define DEFINE_NIC_PROPERTIES(_state, _conf) \
DEFINE_PROP_MACADDR("mac", _state, _conf.macaddr), \
DEFINE_PROP_VLAN("vlan", _state, _conf.vlan), \
- DEFINE_PROP_NETDEV("netdev", _state, _conf.peer)
+ DEFINE_PROP_NETDEV("netdev", _state, _conf.peer), \
+ DEFINE_PROP_INT32("bootindex", _state, _conf.bootindex, -1)
/* VLANs support */
diff --git a/sysemu.h b/sysemu.h
index b81a70e..fe9a582 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -188,4 +188,6 @@ void rtc_change_mon_event(struct tm *tm);
void register_devices(void);
+void add_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix);
#endif
diff --git a/vl.c b/vl.c
index 9ee6479..4e5d146 100644
--- a/vl.c
+++ b/vl.c
@@ -228,6 +228,17 @@ unsigned int nb_prom_envs = 0;
const char *prom_envs[MAX_PROM_ENVS];
int boot_menu;
+typedef struct FWBootEntry FWBootEntry;
+
+struct FWBootEntry {
+ QTAILQ_ENTRY(FWBootEntry) link;
+ int32_t bootindex;
+ DeviceState *dev;
+ char *suffix;
+};
+
+QTAILQ_HEAD(, FWBootEntry) fw_boot_order = QTAILQ_HEAD_INITIALIZER(fw_boot_order);
+
int nb_numa_nodes;
uint64_t node_mem[MAX_NODES];
uint64_t node_cpumask[MAX_NODES];
@@ -692,6 +703,35 @@ static void restore_boot_devices(void *opaque)
qemu_free(standard_boot_devices);
}
+void add_boot_device_path(int32_t bootindex, DeviceState *dev,
+ const char *suffix)
+{
+ FWBootEntry *node, *i;
+
+ if (bootindex < 0) {
+ return;
+ }
+
+ assert(dev != NULL || suffix != NULL);
+
+ node = qemu_mallocz(sizeof(FWBootEntry));
+ node->bootindex = bootindex;
+ node->suffix = strdup(suffix);
+ node->dev = dev;
+
+ QTAILQ_FOREACH(i, &fw_boot_order, link) {
+ if (i->bootindex == bootindex) {
+ fprintf(stderr, "Two devices with same boot index %d\n", bootindex);
+ exit(1);
+ } else if (i->bootindex < bootindex) {
+ continue;
+ }
+ QTAILQ_INSERT_BEFORE(i, node, link);
+ return;
+ }
+ QTAILQ_INSERT_TAIL(&fw_boot_order, node, link);
+}
+
static void numa_add(const char *optarg)
{
char option[128];
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCHv6 13/16] Change fw_cfg_add_file() to get full file path as a parameter.
2010-11-17 16:43 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-17 16:44 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:44 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, blauwirbel, armbru, alex.williamson, mst, kevin
Change fw_cfg_add_file() to get full file path as a parameter instead
of building one internally. Two reasons for that. First caller may need
to know how file is named. Second this moves policy of file naming out
from fw_cfg. Platform may want to use more then two levels of
directories for instance.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/fw_cfg.c | 16 ++++------------
hw/fw_cfg.h | 4 ++--
hw/loader.c | 16 ++++++++++++++--
3 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index 72866ae..7b9434f 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -277,10 +277,9 @@ int fw_cfg_add_callback(FWCfgState *s, uint16_t key, FWCfgCallback callback,
return 1;
}
-int fw_cfg_add_file(FWCfgState *s, const char *dir, const char *filename,
- uint8_t *data, uint32_t len)
+int fw_cfg_add_file(FWCfgState *s, const char *filename, uint8_t *data,
+ uint32_t len)
{
- const char *basename;
int i, index;
if (!s->files) {
@@ -297,15 +296,8 @@ int fw_cfg_add_file(FWCfgState *s, const char *dir, const char *filename,
fw_cfg_add_bytes(s, FW_CFG_FILE_FIRST + index, data, len);
- basename = strrchr(filename, '/');
- if (basename) {
- basename++;
- } else {
- basename = filename;
- }
-
- snprintf(s->files->f[index].name, sizeof(s->files->f[index].name),
- "%s/%s", dir, basename);
+ pstrcpy(s->files->f[index].name, sizeof(s->files->f[index].name),
+ filename);
for (i = 0; i < index; i++) {
if (strcmp(s->files->f[index].name, s->files->f[i].name) == 0) {
FW_CFG_DPRINTF("%s: skip duplicate: %s\n", __FUNCTION__,
diff --git a/hw/fw_cfg.h b/hw/fw_cfg.h
index 4d13a4f..856bf91 100644
--- a/hw/fw_cfg.h
+++ b/hw/fw_cfg.h
@@ -60,8 +60,8 @@ int fw_cfg_add_i32(FWCfgState *s, uint16_t key, uint32_t value);
int fw_cfg_add_i64(FWCfgState *s, uint16_t key, uint64_t value);
int fw_cfg_add_callback(FWCfgState *s, uint16_t key, FWCfgCallback callback,
void *callback_opaque, uint8_t *data, size_t len);
-int fw_cfg_add_file(FWCfgState *s, const char *dir, const char *filename,
- uint8_t *data, uint32_t len);
+int fw_cfg_add_file(FWCfgState *s, const char *filename, uint8_t *data,
+ uint32_t len);
FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
target_phys_addr_t crl_addr, target_phys_addr_t data_addr);
diff --git a/hw/loader.c b/hw/loader.c
index 49ac1fa..1e98326 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -592,8 +592,20 @@ int rom_add_file(const char *file, const char *fw_dir,
}
close(fd);
rom_insert(rom);
- if (rom->fw_file && fw_cfg)
- fw_cfg_add_file(fw_cfg, rom->fw_dir, rom->fw_file, rom->data, rom->romsize);
+ if (rom->fw_file && fw_cfg) {
+ const char *basename;
+ char fw_file_name[56];
+
+ basename = strrchr(rom->fw_file, '/');
+ if (basename) {
+ basename++;
+ } else {
+ basename = rom->fw_file;
+ }
+ snprintf(fw_file_name, sizeof(fw_file_name), "%s/%s", rom->fw_dir,
+ basename);
+ fw_cfg_add_file(fw_cfg, fw_file_name, rom->data, rom->romsize);
+ }
return 0;
err:
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread* [Qemu-devel] [PATCHv6 13/16] Change fw_cfg_add_file() to get full file path as a parameter.
@ 2010-11-17 16:44 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:44 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, mst, armbru, blauwirbel, alex.williamson, kevin
Change fw_cfg_add_file() to get full file path as a parameter instead
of building one internally. Two reasons for that. First caller may need
to know how file is named. Second this moves policy of file naming out
from fw_cfg. Platform may want to use more then two levels of
directories for instance.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/fw_cfg.c | 16 ++++------------
hw/fw_cfg.h | 4 ++--
hw/loader.c | 16 ++++++++++++++--
3 files changed, 20 insertions(+), 16 deletions(-)
diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index 72866ae..7b9434f 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -277,10 +277,9 @@ int fw_cfg_add_callback(FWCfgState *s, uint16_t key, FWCfgCallback callback,
return 1;
}
-int fw_cfg_add_file(FWCfgState *s, const char *dir, const char *filename,
- uint8_t *data, uint32_t len)
+int fw_cfg_add_file(FWCfgState *s, const char *filename, uint8_t *data,
+ uint32_t len)
{
- const char *basename;
int i, index;
if (!s->files) {
@@ -297,15 +296,8 @@ int fw_cfg_add_file(FWCfgState *s, const char *dir, const char *filename,
fw_cfg_add_bytes(s, FW_CFG_FILE_FIRST + index, data, len);
- basename = strrchr(filename, '/');
- if (basename) {
- basename++;
- } else {
- basename = filename;
- }
-
- snprintf(s->files->f[index].name, sizeof(s->files->f[index].name),
- "%s/%s", dir, basename);
+ pstrcpy(s->files->f[index].name, sizeof(s->files->f[index].name),
+ filename);
for (i = 0; i < index; i++) {
if (strcmp(s->files->f[index].name, s->files->f[i].name) == 0) {
FW_CFG_DPRINTF("%s: skip duplicate: %s\n", __FUNCTION__,
diff --git a/hw/fw_cfg.h b/hw/fw_cfg.h
index 4d13a4f..856bf91 100644
--- a/hw/fw_cfg.h
+++ b/hw/fw_cfg.h
@@ -60,8 +60,8 @@ int fw_cfg_add_i32(FWCfgState *s, uint16_t key, uint32_t value);
int fw_cfg_add_i64(FWCfgState *s, uint16_t key, uint64_t value);
int fw_cfg_add_callback(FWCfgState *s, uint16_t key, FWCfgCallback callback,
void *callback_opaque, uint8_t *data, size_t len);
-int fw_cfg_add_file(FWCfgState *s, const char *dir, const char *filename,
- uint8_t *data, uint32_t len);
+int fw_cfg_add_file(FWCfgState *s, const char *filename, uint8_t *data,
+ uint32_t len);
FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
target_phys_addr_t crl_addr, target_phys_addr_t data_addr);
diff --git a/hw/loader.c b/hw/loader.c
index 49ac1fa..1e98326 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -592,8 +592,20 @@ int rom_add_file(const char *file, const char *fw_dir,
}
close(fd);
rom_insert(rom);
- if (rom->fw_file && fw_cfg)
- fw_cfg_add_file(fw_cfg, rom->fw_dir, rom->fw_file, rom->data, rom->romsize);
+ if (rom->fw_file && fw_cfg) {
+ const char *basename;
+ char fw_file_name[56];
+
+ basename = strrchr(rom->fw_file, '/');
+ if (basename) {
+ basename++;
+ } else {
+ basename = rom->fw_file;
+ }
+ snprintf(fw_file_name, sizeof(fw_file_name), "%s/%s", rom->fw_dir,
+ basename);
+ fw_cfg_add_file(fw_cfg, fw_file_name, rom->data, rom->romsize);
+ }
return 0;
err:
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCHv6 14/16] Add bootindex for option roms.
2010-11-17 16:43 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-17 16:44 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:44 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, blauwirbel, armbru, alex.williamson, mst, kevin
Extend -option-rom command to have additional parameter ,bootindex=.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/loader.c | 16 +++++++++++-----
hw/loader.h | 8 ++++----
hw/multiboot.c | 3 ++-
hw/ne2000.c | 2 +-
hw/nseries.c | 4 ++--
hw/palm.c | 6 +++---
hw/pc.c | 7 ++++---
hw/pci.c | 2 +-
hw/pcnet.c | 2 +-
qemu-config.c | 17 +++++++++++++++++
sysemu.h | 6 +++++-
vl.c | 11 +++++++++--
12 files changed, 60 insertions(+), 24 deletions(-)
diff --git a/hw/loader.c b/hw/loader.c
index 1e98326..eb198f6 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -107,7 +107,7 @@ int load_image_targphys(const char *filename,
size = get_image_size(filename);
if (size > 0)
- rom_add_file_fixed(filename, addr);
+ rom_add_file_fixed(filename, addr, -1);
return size;
}
@@ -557,10 +557,11 @@ static void rom_insert(Rom *rom)
}
int rom_add_file(const char *file, const char *fw_dir,
- target_phys_addr_t addr)
+ target_phys_addr_t addr, int32_t bootindex)
{
Rom *rom;
int rc, fd = -1;
+ char devpath[100];
rom = qemu_mallocz(sizeof(*rom));
rom->name = qemu_strdup(file);
@@ -605,7 +606,12 @@ int rom_add_file(const char *file, const char *fw_dir,
snprintf(fw_file_name, sizeof(fw_file_name), "%s/%s", rom->fw_dir,
basename);
fw_cfg_add_file(fw_cfg, fw_file_name, rom->data, rom->romsize);
+ snprintf(devpath, sizeof(devpath), "/rom@%s", fw_file_name);
+ } else {
+ snprintf(devpath, sizeof(devpath), "/rom@" TARGET_FMT_plx, addr);
}
+
+ add_boot_device_path(bootindex, NULL, devpath);
return 0;
err:
@@ -635,12 +641,12 @@ int rom_add_blob(const char *name, const void *blob, size_t len,
int rom_add_vga(const char *file)
{
- return rom_add_file(file, "vgaroms", 0);
+ return rom_add_file(file, "vgaroms", 0, -1);
}
-int rom_add_option(const char *file)
+int rom_add_option(const char *file, int32_t bootindex)
{
- return rom_add_file(file, "genroms", 0);
+ return rom_add_file(file, "genroms", 0, bootindex);
}
static void rom_reset(void *unused)
diff --git a/hw/loader.h b/hw/loader.h
index 1f82fc5..fc6bdff 100644
--- a/hw/loader.h
+++ b/hw/loader.h
@@ -22,7 +22,7 @@ void pstrcpy_targphys(const char *name,
int rom_add_file(const char *file, const char *fw_dir,
- target_phys_addr_t addr);
+ target_phys_addr_t addr, int32_t bootindex);
int rom_add_blob(const char *name, const void *blob, size_t len,
target_phys_addr_t addr);
int rom_load_all(void);
@@ -31,8 +31,8 @@ int rom_copy(uint8_t *dest, target_phys_addr_t addr, size_t size);
void *rom_ptr(target_phys_addr_t addr);
void do_info_roms(Monitor *mon);
-#define rom_add_file_fixed(_f, _a) \
- rom_add_file(_f, NULL, _a)
+#define rom_add_file_fixed(_f, _a, _i) \
+ rom_add_file(_f, NULL, _a, _i)
#define rom_add_blob_fixed(_f, _b, _l, _a) \
rom_add_blob(_f, _b, _l, _a)
@@ -43,6 +43,6 @@ void do_info_roms(Monitor *mon);
#define PC_ROM_SIZE (PC_ROM_MAX - PC_ROM_MIN_VGA)
int rom_add_vga(const char *file);
-int rom_add_option(const char *file);
+int rom_add_option(const char *file, int32_t bootindex);
#endif
diff --git a/hw/multiboot.c b/hw/multiboot.c
index e710bbb..7cc3055 100644
--- a/hw/multiboot.c
+++ b/hw/multiboot.c
@@ -331,7 +331,8 @@ int load_multiboot(void *fw_cfg,
fw_cfg_add_bytes(fw_cfg, FW_CFG_INITRD_DATA, mb_bootinfo_data,
sizeof(bootinfo));
- option_rom[nb_option_roms] = "multiboot.bin";
+ option_rom[nb_option_roms].name = "multiboot.bin";
+ option_rom[nb_option_roms].bootindex = 0;
nb_option_roms++;
return 1; /* yes, we are multiboot */
diff --git a/hw/ne2000.c b/hw/ne2000.c
index a030106..5966359 100644
--- a/hw/ne2000.c
+++ b/hw/ne2000.c
@@ -742,7 +742,7 @@ static int pci_ne2000_init(PCIDevice *pci_dev)
if (!pci_dev->qdev.hotplugged) {
static int loaded = 0;
if (!loaded) {
- rom_add_option("pxe-ne2k_pci.bin");
+ rom_add_option("pxe-ne2k_pci.bin", -1);
loaded = 1;
}
}
diff --git a/hw/nseries.c b/hw/nseries.c
index 04a028d..2f6f473 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -1326,7 +1326,7 @@ static void n8x0_init(ram_addr_t ram_size, const char *boot_device,
qemu_register_reset(n8x0_boot_init, s);
}
- if (option_rom[0] && (boot_device[0] == 'n' || !kernel_filename)) {
+ if (option_rom[0].name && (boot_device[0] == 'n' || !kernel_filename)) {
int rom_size;
uint8_t nolo_tags[0x10000];
/* No, wait, better start at the ROM. */
@@ -1341,7 +1341,7 @@ static void n8x0_init(ram_addr_t ram_size, const char *boot_device,
*
* The code above is for loading the `zImage' file from Nokia
* images. */
- rom_size = load_image_targphys(option_rom[0],
+ rom_size = load_image_targphys(option_rom[0].name,
OMAP2_Q2_BASE + 0x400000,
sdram_size - 0x400000);
printf("%i bytes of image loaded\n", rom_size);
diff --git a/hw/palm.c b/hw/palm.c
index 193aa11..dafc487 100644
--- a/hw/palm.c
+++ b/hw/palm.c
@@ -234,20 +234,20 @@ static void palmte_init(ram_addr_t ram_size,
/* Setup initial (reset) machine state */
if (nb_option_roms) {
- rom_size = get_image_size(option_rom[0]);
+ rom_size = get_image_size(option_rom[0].name);
if (rom_size > flash_size) {
fprintf(stderr, "%s: ROM image too big (%x > %x)\n",
__FUNCTION__, rom_size, flash_size);
rom_size = 0;
}
if (rom_size > 0) {
- rom_size = load_image_targphys(option_rom[0], OMAP_CS0_BASE,
+ rom_size = load_image_targphys(option_rom[0].name, OMAP_CS0_BASE,
flash_size);
rom_loaded = 1;
}
if (rom_size < 0) {
fprintf(stderr, "%s: error loading '%s'\n",
- __FUNCTION__, option_rom[0]);
+ __FUNCTION__, option_rom[0].name);
}
}
diff --git a/hw/pc.c b/hw/pc.c
index c34d194..a10c67a 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -733,7 +733,8 @@ static void load_linux(void *fw_cfg,
fw_cfg_add_i32(fw_cfg, FW_CFG_SETUP_SIZE, setup_size);
fw_cfg_add_bytes(fw_cfg, FW_CFG_SETUP_DATA, setup, setup_size);
- option_rom[nb_option_roms] = "linuxboot.bin";
+ option_rom[nb_option_roms].name = "linuxboot.bin";
+ option_rom[nb_option_roms].bootindex = 0;
nb_option_roms++;
}
@@ -937,7 +938,7 @@ void pc_memory_init(ram_addr_t ram_size,
goto bios_error;
}
bios_offset = qemu_ram_alloc(NULL, "pc.bios", bios_size);
- ret = rom_add_file_fixed(bios_name, (uint32_t)(-bios_size));
+ ret = rom_add_file_fixed(bios_name, (uint32_t)(-bios_size), -1);
if (ret != 0) {
bios_error:
fprintf(stderr, "qemu: could not load PC BIOS '%s'\n", bios_name);
@@ -969,7 +970,7 @@ void pc_memory_init(ram_addr_t ram_size,
}
for (i = 0; i < nb_option_roms; i++) {
- rom_add_option(option_rom[i]);
+ rom_add_option(option_rom[i].name, option_rom[i].bootindex);
}
}
diff --git a/hw/pci.c b/hw/pci.c
index 8514e15..fc09384 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1705,7 +1705,7 @@ static int pci_add_option_rom(PCIDevice *pdev)
if (class == 0x0300) {
rom_add_vga(pdev->romfile);
} else {
- rom_add_option(pdev->romfile);
+ rom_add_option(pdev->romfile, -1);
}
return 0;
}
diff --git a/hw/pcnet.c b/hw/pcnet.c
index f100945..dc9281c 100644
--- a/hw/pcnet.c
+++ b/hw/pcnet.c
@@ -2014,7 +2014,7 @@ static int pci_pcnet_init(PCIDevice *pci_dev)
if (!pci_dev->qdev.hotplugged) {
static int loaded = 0;
if (!loaded) {
- rom_add_option("pxe-pcnet.bin");
+ rom_add_option("pxe-pcnet.bin", -1);
loaded = 1;
}
}
diff --git a/qemu-config.c b/qemu-config.c
index 52f18be..965fa46 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -429,6 +429,22 @@ QemuOptsList qemu_spice_opts = {
},
};
+QemuOptsList qemu_option_rom_opts = {
+ .name = "option-rom",
+ .implied_opt_name = "romfile",
+ .head = QTAILQ_HEAD_INITIALIZER(qemu_option_rom_opts.head),
+ .desc = {
+ {
+ .name = "bootindex",
+ .type = QEMU_OPT_NUMBER,
+ }, {
+ .name = "romfile",
+ .type = QEMU_OPT_STRING,
+ },
+ { /* end if list */ }
+ },
+};
+
static QemuOptsList *vm_config_groups[32] = {
&qemu_drive_opts,
&qemu_chardev_opts,
@@ -442,6 +458,7 @@ static QemuOptsList *vm_config_groups[32] = {
#ifdef CONFIG_SIMPLE_TRACE
&qemu_trace_opts,
#endif
+ &qemu_option_rom_opts,
NULL,
};
diff --git a/sysemu.h b/sysemu.h
index fe9a582..48f8eee 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -139,7 +139,11 @@ extern uint64_t node_mem[MAX_NODES];
extern uint64_t node_cpumask[MAX_NODES];
#define MAX_OPTION_ROMS 16
-extern const char *option_rom[MAX_OPTION_ROMS];
+typedef struct QEMUOptionRom {
+ const char *name;
+ int32_t bootindex;
+} QEMUOptionRom;
+extern QEMUOptionRom option_rom[MAX_OPTION_ROMS];
extern int nb_option_roms;
#define MAX_PROM_ENVS 128
diff --git a/vl.c b/vl.c
index 4e5d146..f02aaec 100644
--- a/vl.c
+++ b/vl.c
@@ -217,7 +217,7 @@ int cursor_hide = 1;
int graphic_rotate = 0;
uint8_t irq0override = 1;
const char *watchdog;
-const char *option_rom[MAX_OPTION_ROMS];
+QEMUOptionRom option_rom[MAX_OPTION_ROMS];
int nb_option_roms;
int semihosting_enabled = 0;
int old_param = 0;
@@ -2517,7 +2517,14 @@ int main(int argc, char **argv, char **envp)
fprintf(stderr, "Too many option ROMs\n");
exit(1);
}
- option_rom[nb_option_roms] = optarg;
+ opts = qemu_opts_parse(qemu_find_opts("option-rom"), optarg, 1);
+ option_rom[nb_option_roms].name = qemu_opt_get(opts, "romfile");
+ option_rom[nb_option_roms].bootindex =
+ qemu_opt_get_number(opts, "bootindex", -1);
+ if (!option_rom[nb_option_roms].name) {
+ fprintf(stderr, "Option ROM file is not specified\n");
+ exit(1);
+ }
nb_option_roms++;
break;
case QEMU_OPTION_semihosting:
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread* [Qemu-devel] [PATCHv6 14/16] Add bootindex for option roms.
@ 2010-11-17 16:44 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:44 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, mst, armbru, blauwirbel, alex.williamson, kevin
Extend -option-rom command to have additional parameter ,bootindex=.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/loader.c | 16 +++++++++++-----
hw/loader.h | 8 ++++----
hw/multiboot.c | 3 ++-
hw/ne2000.c | 2 +-
hw/nseries.c | 4 ++--
hw/palm.c | 6 +++---
hw/pc.c | 7 ++++---
hw/pci.c | 2 +-
hw/pcnet.c | 2 +-
qemu-config.c | 17 +++++++++++++++++
sysemu.h | 6 +++++-
vl.c | 11 +++++++++--
12 files changed, 60 insertions(+), 24 deletions(-)
diff --git a/hw/loader.c b/hw/loader.c
index 1e98326..eb198f6 100644
--- a/hw/loader.c
+++ b/hw/loader.c
@@ -107,7 +107,7 @@ int load_image_targphys(const char *filename,
size = get_image_size(filename);
if (size > 0)
- rom_add_file_fixed(filename, addr);
+ rom_add_file_fixed(filename, addr, -1);
return size;
}
@@ -557,10 +557,11 @@ static void rom_insert(Rom *rom)
}
int rom_add_file(const char *file, const char *fw_dir,
- target_phys_addr_t addr)
+ target_phys_addr_t addr, int32_t bootindex)
{
Rom *rom;
int rc, fd = -1;
+ char devpath[100];
rom = qemu_mallocz(sizeof(*rom));
rom->name = qemu_strdup(file);
@@ -605,7 +606,12 @@ int rom_add_file(const char *file, const char *fw_dir,
snprintf(fw_file_name, sizeof(fw_file_name), "%s/%s", rom->fw_dir,
basename);
fw_cfg_add_file(fw_cfg, fw_file_name, rom->data, rom->romsize);
+ snprintf(devpath, sizeof(devpath), "/rom@%s", fw_file_name);
+ } else {
+ snprintf(devpath, sizeof(devpath), "/rom@" TARGET_FMT_plx, addr);
}
+
+ add_boot_device_path(bootindex, NULL, devpath);
return 0;
err:
@@ -635,12 +641,12 @@ int rom_add_blob(const char *name, const void *blob, size_t len,
int rom_add_vga(const char *file)
{
- return rom_add_file(file, "vgaroms", 0);
+ return rom_add_file(file, "vgaroms", 0, -1);
}
-int rom_add_option(const char *file)
+int rom_add_option(const char *file, int32_t bootindex)
{
- return rom_add_file(file, "genroms", 0);
+ return rom_add_file(file, "genroms", 0, bootindex);
}
static void rom_reset(void *unused)
diff --git a/hw/loader.h b/hw/loader.h
index 1f82fc5..fc6bdff 100644
--- a/hw/loader.h
+++ b/hw/loader.h
@@ -22,7 +22,7 @@ void pstrcpy_targphys(const char *name,
int rom_add_file(const char *file, const char *fw_dir,
- target_phys_addr_t addr);
+ target_phys_addr_t addr, int32_t bootindex);
int rom_add_blob(const char *name, const void *blob, size_t len,
target_phys_addr_t addr);
int rom_load_all(void);
@@ -31,8 +31,8 @@ int rom_copy(uint8_t *dest, target_phys_addr_t addr, size_t size);
void *rom_ptr(target_phys_addr_t addr);
void do_info_roms(Monitor *mon);
-#define rom_add_file_fixed(_f, _a) \
- rom_add_file(_f, NULL, _a)
+#define rom_add_file_fixed(_f, _a, _i) \
+ rom_add_file(_f, NULL, _a, _i)
#define rom_add_blob_fixed(_f, _b, _l, _a) \
rom_add_blob(_f, _b, _l, _a)
@@ -43,6 +43,6 @@ void do_info_roms(Monitor *mon);
#define PC_ROM_SIZE (PC_ROM_MAX - PC_ROM_MIN_VGA)
int rom_add_vga(const char *file);
-int rom_add_option(const char *file);
+int rom_add_option(const char *file, int32_t bootindex);
#endif
diff --git a/hw/multiboot.c b/hw/multiboot.c
index e710bbb..7cc3055 100644
--- a/hw/multiboot.c
+++ b/hw/multiboot.c
@@ -331,7 +331,8 @@ int load_multiboot(void *fw_cfg,
fw_cfg_add_bytes(fw_cfg, FW_CFG_INITRD_DATA, mb_bootinfo_data,
sizeof(bootinfo));
- option_rom[nb_option_roms] = "multiboot.bin";
+ option_rom[nb_option_roms].name = "multiboot.bin";
+ option_rom[nb_option_roms].bootindex = 0;
nb_option_roms++;
return 1; /* yes, we are multiboot */
diff --git a/hw/ne2000.c b/hw/ne2000.c
index a030106..5966359 100644
--- a/hw/ne2000.c
+++ b/hw/ne2000.c
@@ -742,7 +742,7 @@ static int pci_ne2000_init(PCIDevice *pci_dev)
if (!pci_dev->qdev.hotplugged) {
static int loaded = 0;
if (!loaded) {
- rom_add_option("pxe-ne2k_pci.bin");
+ rom_add_option("pxe-ne2k_pci.bin", -1);
loaded = 1;
}
}
diff --git a/hw/nseries.c b/hw/nseries.c
index 04a028d..2f6f473 100644
--- a/hw/nseries.c
+++ b/hw/nseries.c
@@ -1326,7 +1326,7 @@ static void n8x0_init(ram_addr_t ram_size, const char *boot_device,
qemu_register_reset(n8x0_boot_init, s);
}
- if (option_rom[0] && (boot_device[0] == 'n' || !kernel_filename)) {
+ if (option_rom[0].name && (boot_device[0] == 'n' || !kernel_filename)) {
int rom_size;
uint8_t nolo_tags[0x10000];
/* No, wait, better start at the ROM. */
@@ -1341,7 +1341,7 @@ static void n8x0_init(ram_addr_t ram_size, const char *boot_device,
*
* The code above is for loading the `zImage' file from Nokia
* images. */
- rom_size = load_image_targphys(option_rom[0],
+ rom_size = load_image_targphys(option_rom[0].name,
OMAP2_Q2_BASE + 0x400000,
sdram_size - 0x400000);
printf("%i bytes of image loaded\n", rom_size);
diff --git a/hw/palm.c b/hw/palm.c
index 193aa11..dafc487 100644
--- a/hw/palm.c
+++ b/hw/palm.c
@@ -234,20 +234,20 @@ static void palmte_init(ram_addr_t ram_size,
/* Setup initial (reset) machine state */
if (nb_option_roms) {
- rom_size = get_image_size(option_rom[0]);
+ rom_size = get_image_size(option_rom[0].name);
if (rom_size > flash_size) {
fprintf(stderr, "%s: ROM image too big (%x > %x)\n",
__FUNCTION__, rom_size, flash_size);
rom_size = 0;
}
if (rom_size > 0) {
- rom_size = load_image_targphys(option_rom[0], OMAP_CS0_BASE,
+ rom_size = load_image_targphys(option_rom[0].name, OMAP_CS0_BASE,
flash_size);
rom_loaded = 1;
}
if (rom_size < 0) {
fprintf(stderr, "%s: error loading '%s'\n",
- __FUNCTION__, option_rom[0]);
+ __FUNCTION__, option_rom[0].name);
}
}
diff --git a/hw/pc.c b/hw/pc.c
index c34d194..a10c67a 100644
--- a/hw/pc.c
+++ b/hw/pc.c
@@ -733,7 +733,8 @@ static void load_linux(void *fw_cfg,
fw_cfg_add_i32(fw_cfg, FW_CFG_SETUP_SIZE, setup_size);
fw_cfg_add_bytes(fw_cfg, FW_CFG_SETUP_DATA, setup, setup_size);
- option_rom[nb_option_roms] = "linuxboot.bin";
+ option_rom[nb_option_roms].name = "linuxboot.bin";
+ option_rom[nb_option_roms].bootindex = 0;
nb_option_roms++;
}
@@ -937,7 +938,7 @@ void pc_memory_init(ram_addr_t ram_size,
goto bios_error;
}
bios_offset = qemu_ram_alloc(NULL, "pc.bios", bios_size);
- ret = rom_add_file_fixed(bios_name, (uint32_t)(-bios_size));
+ ret = rom_add_file_fixed(bios_name, (uint32_t)(-bios_size), -1);
if (ret != 0) {
bios_error:
fprintf(stderr, "qemu: could not load PC BIOS '%s'\n", bios_name);
@@ -969,7 +970,7 @@ void pc_memory_init(ram_addr_t ram_size,
}
for (i = 0; i < nb_option_roms; i++) {
- rom_add_option(option_rom[i]);
+ rom_add_option(option_rom[i].name, option_rom[i].bootindex);
}
}
diff --git a/hw/pci.c b/hw/pci.c
index 8514e15..fc09384 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1705,7 +1705,7 @@ static int pci_add_option_rom(PCIDevice *pdev)
if (class == 0x0300) {
rom_add_vga(pdev->romfile);
} else {
- rom_add_option(pdev->romfile);
+ rom_add_option(pdev->romfile, -1);
}
return 0;
}
diff --git a/hw/pcnet.c b/hw/pcnet.c
index f100945..dc9281c 100644
--- a/hw/pcnet.c
+++ b/hw/pcnet.c
@@ -2014,7 +2014,7 @@ static int pci_pcnet_init(PCIDevice *pci_dev)
if (!pci_dev->qdev.hotplugged) {
static int loaded = 0;
if (!loaded) {
- rom_add_option("pxe-pcnet.bin");
+ rom_add_option("pxe-pcnet.bin", -1);
loaded = 1;
}
}
diff --git a/qemu-config.c b/qemu-config.c
index 52f18be..965fa46 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -429,6 +429,22 @@ QemuOptsList qemu_spice_opts = {
},
};
+QemuOptsList qemu_option_rom_opts = {
+ .name = "option-rom",
+ .implied_opt_name = "romfile",
+ .head = QTAILQ_HEAD_INITIALIZER(qemu_option_rom_opts.head),
+ .desc = {
+ {
+ .name = "bootindex",
+ .type = QEMU_OPT_NUMBER,
+ }, {
+ .name = "romfile",
+ .type = QEMU_OPT_STRING,
+ },
+ { /* end if list */ }
+ },
+};
+
static QemuOptsList *vm_config_groups[32] = {
&qemu_drive_opts,
&qemu_chardev_opts,
@@ -442,6 +458,7 @@ static QemuOptsList *vm_config_groups[32] = {
#ifdef CONFIG_SIMPLE_TRACE
&qemu_trace_opts,
#endif
+ &qemu_option_rom_opts,
NULL,
};
diff --git a/sysemu.h b/sysemu.h
index fe9a582..48f8eee 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -139,7 +139,11 @@ extern uint64_t node_mem[MAX_NODES];
extern uint64_t node_cpumask[MAX_NODES];
#define MAX_OPTION_ROMS 16
-extern const char *option_rom[MAX_OPTION_ROMS];
+typedef struct QEMUOptionRom {
+ const char *name;
+ int32_t bootindex;
+} QEMUOptionRom;
+extern QEMUOptionRom option_rom[MAX_OPTION_ROMS];
extern int nb_option_roms;
#define MAX_PROM_ENVS 128
diff --git a/vl.c b/vl.c
index 4e5d146..f02aaec 100644
--- a/vl.c
+++ b/vl.c
@@ -217,7 +217,7 @@ int cursor_hide = 1;
int graphic_rotate = 0;
uint8_t irq0override = 1;
const char *watchdog;
-const char *option_rom[MAX_OPTION_ROMS];
+QEMUOptionRom option_rom[MAX_OPTION_ROMS];
int nb_option_roms;
int semihosting_enabled = 0;
int old_param = 0;
@@ -2517,7 +2517,14 @@ int main(int argc, char **argv, char **envp)
fprintf(stderr, "Too many option ROMs\n");
exit(1);
}
- option_rom[nb_option_roms] = optarg;
+ opts = qemu_opts_parse(qemu_find_opts("option-rom"), optarg, 1);
+ option_rom[nb_option_roms].name = qemu_opt_get(opts, "romfile");
+ option_rom[nb_option_roms].bootindex =
+ qemu_opt_get_number(opts, "bootindex", -1);
+ if (!option_rom[nb_option_roms].name) {
+ fprintf(stderr, "Option ROM file is not specified\n");
+ exit(1);
+ }
nb_option_roms++;
break;
case QEMU_OPTION_semihosting:
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCHv6 15/16] Add notifier that will be called when machine is fully created.
2010-11-17 16:43 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-17 16:44 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:44 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, blauwirbel, armbru, alex.williamson, mst, kevin
Action that depends on fully initialized device model should register
with this notifier chain.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
sysemu.h | 2 ++
vl.c | 15 +++++++++++++++
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/sysemu.h b/sysemu.h
index 48f8eee..c42f33a 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -60,6 +60,8 @@ void qemu_system_reset(void);
void qemu_add_exit_notifier(Notifier *notify);
void qemu_remove_exit_notifier(Notifier *notify);
+void qemu_add_machine_init_done_notifier(Notifier *notify);
+
void do_savevm(Monitor *mon, const QDict *qdict);
int load_vmstate(const char *name);
void do_delvm(Monitor *mon, const QDict *qdict);
diff --git a/vl.c b/vl.c
index f02aaec..d6564d4 100644
--- a/vl.c
+++ b/vl.c
@@ -253,6 +253,9 @@ static void *boot_set_opaque;
static NotifierList exit_notifiers =
NOTIFIER_LIST_INITIALIZER(exit_notifiers);
+static NotifierList machine_init_done_notifiers =
+ NOTIFIER_LIST_INITIALIZER(machine_init_done_notifiers);
+
int kvm_allowed = 0;
uint32_t xen_domid;
enum xen_mode xen_mode = XEN_EMULATE;
@@ -1779,6 +1782,16 @@ static void qemu_run_exit_notifiers(void)
notifier_list_notify(&exit_notifiers);
}
+void qemu_add_machine_init_done_notifier(Notifier *notify)
+{
+ notifier_list_add(&machine_init_done_notifiers, notify);
+}
+
+static void qemu_run_machine_init_done_notifiers(void)
+{
+ notifier_list_notify(&machine_init_done_notifiers);
+}
+
static const QEMUOption *lookup_opt(int argc, char **argv,
const char **poptarg, int *poptind)
{
@@ -3024,6 +3037,8 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
+ qemu_run_machine_init_done_notifiers();
+
qemu_system_reset();
if (loadvm) {
if (load_vmstate(loadvm) < 0) {
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread* [Qemu-devel] [PATCHv6 15/16] Add notifier that will be called when machine is fully created.
@ 2010-11-17 16:44 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:44 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, mst, armbru, blauwirbel, alex.williamson, kevin
Action that depends on fully initialized device model should register
with this notifier chain.
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
sysemu.h | 2 ++
vl.c | 15 +++++++++++++++
2 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/sysemu.h b/sysemu.h
index 48f8eee..c42f33a 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -60,6 +60,8 @@ void qemu_system_reset(void);
void qemu_add_exit_notifier(Notifier *notify);
void qemu_remove_exit_notifier(Notifier *notify);
+void qemu_add_machine_init_done_notifier(Notifier *notify);
+
void do_savevm(Monitor *mon, const QDict *qdict);
int load_vmstate(const char *name);
void do_delvm(Monitor *mon, const QDict *qdict);
diff --git a/vl.c b/vl.c
index f02aaec..d6564d4 100644
--- a/vl.c
+++ b/vl.c
@@ -253,6 +253,9 @@ static void *boot_set_opaque;
static NotifierList exit_notifiers =
NOTIFIER_LIST_INITIALIZER(exit_notifiers);
+static NotifierList machine_init_done_notifiers =
+ NOTIFIER_LIST_INITIALIZER(machine_init_done_notifiers);
+
int kvm_allowed = 0;
uint32_t xen_domid;
enum xen_mode xen_mode = XEN_EMULATE;
@@ -1779,6 +1782,16 @@ static void qemu_run_exit_notifiers(void)
notifier_list_notify(&exit_notifiers);
}
+void qemu_add_machine_init_done_notifier(Notifier *notify)
+{
+ notifier_list_add(&machine_init_done_notifiers, notify);
+}
+
+static void qemu_run_machine_init_done_notifiers(void)
+{
+ notifier_list_notify(&machine_init_done_notifiers);
+}
+
static const QEMUOption *lookup_opt(int argc, char **argv,
const char **poptarg, int *poptind)
{
@@ -3024,6 +3037,8 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
+ qemu_run_machine_init_done_notifiers();
+
qemu_system_reset();
if (loadvm) {
if (load_vmstate(loadvm) < 0) {
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread
* [PATCHv6 16/16] Pass boot device list to firmware.
2010-11-17 16:43 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-17 16:44 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:44 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, blauwirbel, armbru, alex.williamson, mst, kevin
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/fw_cfg.c | 14 ++++++++++++++
sysemu.h | 1 +
vl.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index 7b9434f..20a816f 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -53,6 +53,7 @@ struct FWCfgState {
FWCfgFiles *files;
uint16_t cur_entry;
uint32_t cur_offset;
+ Notifier machine_ready;
};
static void fw_cfg_write(FWCfgState *s, uint8_t value)
@@ -315,6 +316,15 @@ int fw_cfg_add_file(FWCfgState *s, const char *filename, uint8_t *data,
return 1;
}
+static void fw_cfg_machine_ready(struct Notifier* n)
+{
+ uint32_t len;
+ FWCfgState *s = container_of(n, FWCfgState, machine_ready);
+ char *bootindex = get_boot_devices_list(&len);
+
+ fw_cfg_add_file(s, "bootorder", (uint8_t*)bootindex, len);
+}
+
FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
target_phys_addr_t ctl_addr, target_phys_addr_t data_addr)
{
@@ -343,6 +353,10 @@ FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
fw_cfg_add_i16(s, FW_CFG_MAX_CPUS, (uint16_t)max_cpus);
fw_cfg_add_i16(s, FW_CFG_BOOT_MENU, (uint16_t)boot_menu);
+
+ s->machine_ready.notify = fw_cfg_machine_ready;
+ qemu_add_machine_init_done_notifier(&s->machine_ready);
+
return s;
}
diff --git a/sysemu.h b/sysemu.h
index c42f33a..38a20a3 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -196,4 +196,5 @@ void register_devices(void);
void add_boot_device_path(int32_t bootindex, DeviceState *dev,
const char *suffix);
+char *get_boot_devices_list(uint32_t *size);
#endif
diff --git a/vl.c b/vl.c
index d6564d4..da025c1 100644
--- a/vl.c
+++ b/vl.c
@@ -735,6 +735,54 @@ void add_boot_device_path(int32_t bootindex, DeviceState *dev,
QTAILQ_INSERT_TAIL(&fw_boot_order, node, link);
}
+/*
+ * This function returns null terminated string that consist of new line
+ * separated device pathes.
+ *
+ * memory pointed by "size" is assigned total length of the array in bytes
+ *
+ */
+char *get_boot_devices_list(uint32_t *size)
+{
+ FWBootEntry *i;
+ uint32_t total = 0;
+ char *list = NULL;
+
+ QTAILQ_FOREACH(i, &fw_boot_order, link) {
+ char *devpath = NULL, *bootpath;
+ int len;
+
+ if (i->dev) {
+ devpath = qdev_get_fw_dev_path(i->dev);
+ assert(devpath);
+ }
+
+ if (i->suffix && devpath) {
+ bootpath = qemu_malloc(strlen(devpath) + strlen(i->suffix) + 1);
+ sprintf(bootpath, "%s%s", devpath, i->suffix);
+ qemu_free(devpath);
+ } else if (devpath) {
+ bootpath = devpath;
+ } else {
+ bootpath = strdup(i->suffix);
+ assert(bootpath);
+ }
+
+ if (total) {
+ list[total-1] = '\n';
+ }
+ len = strlen(bootpath) + 1;
+ list = qemu_realloc(list, total + len);
+ memcpy(&list[total], bootpath, len);
+ total += len;
+ qemu_free(bootpath);
+ }
+
+ *size = total;
+
+ return list;
+}
+
static void numa_add(const char *optarg)
{
char option[128];
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread* [Qemu-devel] [PATCHv6 16/16] Pass boot device list to firmware.
@ 2010-11-17 16:44 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-17 16:44 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm, mst, armbru, blauwirbel, alex.williamson, kevin
Signed-off-by: Gleb Natapov <gleb@redhat.com>
---
hw/fw_cfg.c | 14 ++++++++++++++
sysemu.h | 1 +
vl.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/hw/fw_cfg.c b/hw/fw_cfg.c
index 7b9434f..20a816f 100644
--- a/hw/fw_cfg.c
+++ b/hw/fw_cfg.c
@@ -53,6 +53,7 @@ struct FWCfgState {
FWCfgFiles *files;
uint16_t cur_entry;
uint32_t cur_offset;
+ Notifier machine_ready;
};
static void fw_cfg_write(FWCfgState *s, uint8_t value)
@@ -315,6 +316,15 @@ int fw_cfg_add_file(FWCfgState *s, const char *filename, uint8_t *data,
return 1;
}
+static void fw_cfg_machine_ready(struct Notifier* n)
+{
+ uint32_t len;
+ FWCfgState *s = container_of(n, FWCfgState, machine_ready);
+ char *bootindex = get_boot_devices_list(&len);
+
+ fw_cfg_add_file(s, "bootorder", (uint8_t*)bootindex, len);
+}
+
FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
target_phys_addr_t ctl_addr, target_phys_addr_t data_addr)
{
@@ -343,6 +353,10 @@ FWCfgState *fw_cfg_init(uint32_t ctl_port, uint32_t data_port,
fw_cfg_add_i16(s, FW_CFG_MAX_CPUS, (uint16_t)max_cpus);
fw_cfg_add_i16(s, FW_CFG_BOOT_MENU, (uint16_t)boot_menu);
+
+ s->machine_ready.notify = fw_cfg_machine_ready;
+ qemu_add_machine_init_done_notifier(&s->machine_ready);
+
return s;
}
diff --git a/sysemu.h b/sysemu.h
index c42f33a..38a20a3 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -196,4 +196,5 @@ void register_devices(void);
void add_boot_device_path(int32_t bootindex, DeviceState *dev,
const char *suffix);
+char *get_boot_devices_list(uint32_t *size);
#endif
diff --git a/vl.c b/vl.c
index d6564d4..da025c1 100644
--- a/vl.c
+++ b/vl.c
@@ -735,6 +735,54 @@ void add_boot_device_path(int32_t bootindex, DeviceState *dev,
QTAILQ_INSERT_TAIL(&fw_boot_order, node, link);
}
+/*
+ * This function returns null terminated string that consist of new line
+ * separated device pathes.
+ *
+ * memory pointed by "size" is assigned total length of the array in bytes
+ *
+ */
+char *get_boot_devices_list(uint32_t *size)
+{
+ FWBootEntry *i;
+ uint32_t total = 0;
+ char *list = NULL;
+
+ QTAILQ_FOREACH(i, &fw_boot_order, link) {
+ char *devpath = NULL, *bootpath;
+ int len;
+
+ if (i->dev) {
+ devpath = qdev_get_fw_dev_path(i->dev);
+ assert(devpath);
+ }
+
+ if (i->suffix && devpath) {
+ bootpath = qemu_malloc(strlen(devpath) + strlen(i->suffix) + 1);
+ sprintf(bootpath, "%s%s", devpath, i->suffix);
+ qemu_free(devpath);
+ } else if (devpath) {
+ bootpath = devpath;
+ } else {
+ bootpath = strdup(i->suffix);
+ assert(bootpath);
+ }
+
+ if (total) {
+ list[total-1] = '\n';
+ }
+ len = strlen(bootpath) + 1;
+ list = qemu_realloc(list, total + len);
+ memcpy(&list[total], bootpath, len);
+ total += len;
+ qemu_free(bootpath);
+ }
+
+ *size = total;
+
+ return list;
+}
+
static void numa_add(const char *optarg)
{
char option[128];
--
1.7.2.3
^ permalink raw reply related [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-17 16:43 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-23 15:31 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-23 15:31 UTC (permalink / raw)
To: qemu-devel
Cc: kvm, blauwirbel, armbru, alex.williamson, mst, kevin, Anthony Liguori
Anthony, Blue
No comments on this patch series for almost a week. Can it be applied?
On Wed, Nov 17, 2010 at 06:43:47PM +0200, Gleb Natapov wrote:
> I am using open firmware naming scheme to specify device path names.
> In this version: added SCSI bus support. Pass boot order list as file
> to firmware.
>
> Names look like this on pci machine:
> /pci@i0cf8/ide@1,1/drive@1/disk@0
> /pci@i0cf8/isa@1/fdc@03f1/floppy@1
> /pci@i0cf8/isa@1/fdc@03f1/floppy@0
> /pci@i0cf8/ide@1,1/drive@1/disk@1
> /pci@i0cf8/ide@1,1/drive@0/disk@0
> /pci@i0cf8/scsi@3/disk@0,0
> /pci@i0cf8/ethernet@4/ethernet-phy@0
> /pci@i0cf8/ethernet@5/ethernet-phy@0
> /pci@i0cf8/ide@1,1/drive@0/disk@1
> /pci@i0cf8/isa@1/ide@01e8/drive@0/disk@0
> /pci@i0cf8/usb@1,2/network@0/ethernet@0
> /pci@i0cf8/usb@1,2/hub@1/network@0/ethernet@0
> /rom@genroms/linuxboot.bin
>
> and on isa machine:
> /isa/ide@0170/drive@0/disk@0
> /isa/fdc@03f1/floppy@1
> /isa/fdc@03f1/floppy@0
> /isa/ide@0170/drive@0/disk@1
>
> Instead of using get_dev_path() callback I introduces another one
> get_fw_dev_path. Unfortunately the way get_dev_path() callback is used
> in migration code makes it hard to reuse it for other purposes. First
> of all it is not called recursively so caller expects it to provide
> unique name by itself. Device path though is inherently recursive. Each
> individual element may not be unique, but the whole path will be. On
> the other hand to call get_dev_path() recursively in migration code we
> should implement it for all possible buses first. Other problem is
> compatibility. If we change get_dev_path() output format now we will not
> be able to migrate from old qemu to new one without some additional
> compatibility layer.
>
> Gleb Natapov (16):
> Introduce fw_name field to DeviceInfo structure.
> Introduce new BusInfo callback get_fw_dev_path.
> Keep track of ISA ports ISA device is using in qdev.
> Add get_fw_dev_path callback to ISA bus in qdev.
> Store IDE bus id in IDEBus structure for easy access.
> Add get_fw_dev_path callback to IDE bus.
> Add get_dev_path callback for system bus.
> Add get_fw_dev_path callback for pci bus.
> Record which USBDevice USBPort belongs too.
> Add get_dev_path callback for usb bus.
> Add get_dev_path callback to scsi bus.
> Add bootindex parameter to net/block/fd device
> Change fw_cfg_add_file() to get full file path as a parameter.
> Add bootindex for option roms.
> Add notifier that will be called when machine is fully created.
> Pass boot device list to firmware.
>
> block_int.h | 4 +-
> hw/cs4231a.c | 1 +
> hw/e1000.c | 4 ++
> hw/eepro100.c | 3 +
> hw/fdc.c | 12 ++++++
> hw/fw_cfg.c | 30 ++++++++------
> hw/fw_cfg.h | 4 +-
> hw/gus.c | 4 ++
> hw/ide/cmd646.c | 4 +-
> hw/ide/internal.h | 3 +-
> hw/ide/isa.c | 5 ++-
> hw/ide/piix.c | 4 +-
> hw/ide/qdev.c | 22 ++++++++++-
> hw/ide/via.c | 4 +-
> hw/isa-bus.c | 42 +++++++++++++++++++
> hw/isa.h | 4 ++
> hw/lance.c | 1 +
> hw/loader.c | 32 ++++++++++++---
> hw/loader.h | 8 ++--
> hw/m48t59.c | 1 +
> hw/mc146818rtc.c | 1 +
> hw/multiboot.c | 3 +-
> hw/ne2000-isa.c | 3 +
> hw/ne2000.c | 5 ++-
> hw/nseries.c | 4 +-
> hw/palm.c | 6 +-
> hw/parallel.c | 5 ++
> hw/pc.c | 7 ++-
> hw/pci.c | 110 ++++++++++++++++++++++++++++++++++++++++-----------
> hw/pci_host.c | 2 +
> hw/pckbd.c | 3 +
> hw/pcnet.c | 6 ++-
> hw/piix_pci.c | 1 +
> hw/qdev.c | 32 +++++++++++++++
> hw/qdev.h | 9 ++++
> hw/rtl8139.c | 4 ++
> hw/sb16.c | 4 ++
> hw/scsi-bus.c | 23 +++++++++++
> hw/scsi-disk.c | 2 +
> hw/serial.c | 1 +
> hw/sysbus.c | 30 ++++++++++++++
> hw/sysbus.h | 4 ++
> hw/usb-bus.c | 45 ++++++++++++++++++++-
> hw/usb-hub.c | 3 +-
> hw/usb-musb.c | 2 +-
> hw/usb-net.c | 3 +
> hw/usb-ohci.c | 2 +-
> hw/usb-uhci.c | 2 +-
> hw/usb.h | 3 +-
> hw/virtio-blk.c | 2 +
> hw/virtio-net.c | 2 +
> hw/virtio-pci.c | 1 +
> net.h | 4 +-
> qemu-config.c | 17 ++++++++
> sysemu.h | 11 +++++-
> vl.c | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 56 files changed, 588 insertions(+), 80 deletions(-)
>
> --
> 1.7.2.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-23 15:31 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-23 15:31 UTC (permalink / raw)
To: qemu-devel
Cc: Anthony Liguori, kvm, mst, armbru, blauwirbel, alex.williamson, kevin
Anthony, Blue
No comments on this patch series for almost a week. Can it be applied?
On Wed, Nov 17, 2010 at 06:43:47PM +0200, Gleb Natapov wrote:
> I am using open firmware naming scheme to specify device path names.
> In this version: added SCSI bus support. Pass boot order list as file
> to firmware.
>
> Names look like this on pci machine:
> /pci@i0cf8/ide@1,1/drive@1/disk@0
> /pci@i0cf8/isa@1/fdc@03f1/floppy@1
> /pci@i0cf8/isa@1/fdc@03f1/floppy@0
> /pci@i0cf8/ide@1,1/drive@1/disk@1
> /pci@i0cf8/ide@1,1/drive@0/disk@0
> /pci@i0cf8/scsi@3/disk@0,0
> /pci@i0cf8/ethernet@4/ethernet-phy@0
> /pci@i0cf8/ethernet@5/ethernet-phy@0
> /pci@i0cf8/ide@1,1/drive@0/disk@1
> /pci@i0cf8/isa@1/ide@01e8/drive@0/disk@0
> /pci@i0cf8/usb@1,2/network@0/ethernet@0
> /pci@i0cf8/usb@1,2/hub@1/network@0/ethernet@0
> /rom@genroms/linuxboot.bin
>
> and on isa machine:
> /isa/ide@0170/drive@0/disk@0
> /isa/fdc@03f1/floppy@1
> /isa/fdc@03f1/floppy@0
> /isa/ide@0170/drive@0/disk@1
>
> Instead of using get_dev_path() callback I introduces another one
> get_fw_dev_path. Unfortunately the way get_dev_path() callback is used
> in migration code makes it hard to reuse it for other purposes. First
> of all it is not called recursively so caller expects it to provide
> unique name by itself. Device path though is inherently recursive. Each
> individual element may not be unique, but the whole path will be. On
> the other hand to call get_dev_path() recursively in migration code we
> should implement it for all possible buses first. Other problem is
> compatibility. If we change get_dev_path() output format now we will not
> be able to migrate from old qemu to new one without some additional
> compatibility layer.
>
> Gleb Natapov (16):
> Introduce fw_name field to DeviceInfo structure.
> Introduce new BusInfo callback get_fw_dev_path.
> Keep track of ISA ports ISA device is using in qdev.
> Add get_fw_dev_path callback to ISA bus in qdev.
> Store IDE bus id in IDEBus structure for easy access.
> Add get_fw_dev_path callback to IDE bus.
> Add get_dev_path callback for system bus.
> Add get_fw_dev_path callback for pci bus.
> Record which USBDevice USBPort belongs too.
> Add get_dev_path callback for usb bus.
> Add get_dev_path callback to scsi bus.
> Add bootindex parameter to net/block/fd device
> Change fw_cfg_add_file() to get full file path as a parameter.
> Add bootindex for option roms.
> Add notifier that will be called when machine is fully created.
> Pass boot device list to firmware.
>
> block_int.h | 4 +-
> hw/cs4231a.c | 1 +
> hw/e1000.c | 4 ++
> hw/eepro100.c | 3 +
> hw/fdc.c | 12 ++++++
> hw/fw_cfg.c | 30 ++++++++------
> hw/fw_cfg.h | 4 +-
> hw/gus.c | 4 ++
> hw/ide/cmd646.c | 4 +-
> hw/ide/internal.h | 3 +-
> hw/ide/isa.c | 5 ++-
> hw/ide/piix.c | 4 +-
> hw/ide/qdev.c | 22 ++++++++++-
> hw/ide/via.c | 4 +-
> hw/isa-bus.c | 42 +++++++++++++++++++
> hw/isa.h | 4 ++
> hw/lance.c | 1 +
> hw/loader.c | 32 ++++++++++++---
> hw/loader.h | 8 ++--
> hw/m48t59.c | 1 +
> hw/mc146818rtc.c | 1 +
> hw/multiboot.c | 3 +-
> hw/ne2000-isa.c | 3 +
> hw/ne2000.c | 5 ++-
> hw/nseries.c | 4 +-
> hw/palm.c | 6 +-
> hw/parallel.c | 5 ++
> hw/pc.c | 7 ++-
> hw/pci.c | 110 ++++++++++++++++++++++++++++++++++++++++-----------
> hw/pci_host.c | 2 +
> hw/pckbd.c | 3 +
> hw/pcnet.c | 6 ++-
> hw/piix_pci.c | 1 +
> hw/qdev.c | 32 +++++++++++++++
> hw/qdev.h | 9 ++++
> hw/rtl8139.c | 4 ++
> hw/sb16.c | 4 ++
> hw/scsi-bus.c | 23 +++++++++++
> hw/scsi-disk.c | 2 +
> hw/serial.c | 1 +
> hw/sysbus.c | 30 ++++++++++++++
> hw/sysbus.h | 4 ++
> hw/usb-bus.c | 45 ++++++++++++++++++++-
> hw/usb-hub.c | 3 +-
> hw/usb-musb.c | 2 +-
> hw/usb-net.c | 3 +
> hw/usb-ohci.c | 2 +-
> hw/usb-uhci.c | 2 +-
> hw/usb.h | 3 +-
> hw/virtio-blk.c | 2 +
> hw/virtio-net.c | 2 +
> hw/virtio-pci.c | 1 +
> net.h | 4 +-
> qemu-config.c | 17 ++++++++
> sysemu.h | 11 +++++-
> vl.c | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
> 56 files changed, 588 insertions(+), 80 deletions(-)
>
> --
> 1.7.2.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-23 15:31 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-23 16:12 ` Anthony Liguori
-1 siblings, 0 replies; 136+ messages in thread
From: Anthony Liguori @ 2010-11-23 16:12 UTC (permalink / raw)
To: Gleb Natapov
Cc: qemu-devel, kvm, blauwirbel, armbru, alex.williamson, mst, kevin,
Anthony Liguori
On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> Anthony, Blue
>
> No comments on this patch series for almost a week. Can it be applied?
>
Does that mean everyone's happy or have folks not gotten around to
review it?
IOW, last call if you have objections :-)
Regards,
Anthony Liguori
> On Wed, Nov 17, 2010 at 06:43:47PM +0200, Gleb Natapov wrote:
>
>> I am using open firmware naming scheme to specify device path names.
>> In this version: added SCSI bus support. Pass boot order list as file
>> to firmware.
>>
>> Names look like this on pci machine:
>> /pci@i0cf8/ide@1,1/drive@1/disk@0
>> /pci@i0cf8/isa@1/fdc@03f1/floppy@1
>> /pci@i0cf8/isa@1/fdc@03f1/floppy@0
>> /pci@i0cf8/ide@1,1/drive@1/disk@1
>> /pci@i0cf8/ide@1,1/drive@0/disk@0
>> /pci@i0cf8/scsi@3/disk@0,0
>> /pci@i0cf8/ethernet@4/ethernet-phy@0
>> /pci@i0cf8/ethernet@5/ethernet-phy@0
>> /pci@i0cf8/ide@1,1/drive@0/disk@1
>> /pci@i0cf8/isa@1/ide@01e8/drive@0/disk@0
>> /pci@i0cf8/usb@1,2/network@0/ethernet@0
>> /pci@i0cf8/usb@1,2/hub@1/network@0/ethernet@0
>> /rom@genroms/linuxboot.bin
>>
>> and on isa machine:
>> /isa/ide@0170/drive@0/disk@0
>> /isa/fdc@03f1/floppy@1
>> /isa/fdc@03f1/floppy@0
>> /isa/ide@0170/drive@0/disk@1
>>
>> Instead of using get_dev_path() callback I introduces another one
>> get_fw_dev_path. Unfortunately the way get_dev_path() callback is used
>> in migration code makes it hard to reuse it for other purposes. First
>> of all it is not called recursively so caller expects it to provide
>> unique name by itself. Device path though is inherently recursive. Each
>> individual element may not be unique, but the whole path will be. On
>> the other hand to call get_dev_path() recursively in migration code we
>> should implement it for all possible buses first. Other problem is
>> compatibility. If we change get_dev_path() output format now we will not
>> be able to migrate from old qemu to new one without some additional
>> compatibility layer.
>>
>> Gleb Natapov (16):
>> Introduce fw_name field to DeviceInfo structure.
>> Introduce new BusInfo callback get_fw_dev_path.
>> Keep track of ISA ports ISA device is using in qdev.
>> Add get_fw_dev_path callback to ISA bus in qdev.
>> Store IDE bus id in IDEBus structure for easy access.
>> Add get_fw_dev_path callback to IDE bus.
>> Add get_dev_path callback for system bus.
>> Add get_fw_dev_path callback for pci bus.
>> Record which USBDevice USBPort belongs too.
>> Add get_dev_path callback for usb bus.
>> Add get_dev_path callback to scsi bus.
>> Add bootindex parameter to net/block/fd device
>> Change fw_cfg_add_file() to get full file path as a parameter.
>> Add bootindex for option roms.
>> Add notifier that will be called when machine is fully created.
>> Pass boot device list to firmware.
>>
>> block_int.h | 4 +-
>> hw/cs4231a.c | 1 +
>> hw/e1000.c | 4 ++
>> hw/eepro100.c | 3 +
>> hw/fdc.c | 12 ++++++
>> hw/fw_cfg.c | 30 ++++++++------
>> hw/fw_cfg.h | 4 +-
>> hw/gus.c | 4 ++
>> hw/ide/cmd646.c | 4 +-
>> hw/ide/internal.h | 3 +-
>> hw/ide/isa.c | 5 ++-
>> hw/ide/piix.c | 4 +-
>> hw/ide/qdev.c | 22 ++++++++++-
>> hw/ide/via.c | 4 +-
>> hw/isa-bus.c | 42 +++++++++++++++++++
>> hw/isa.h | 4 ++
>> hw/lance.c | 1 +
>> hw/loader.c | 32 ++++++++++++---
>> hw/loader.h | 8 ++--
>> hw/m48t59.c | 1 +
>> hw/mc146818rtc.c | 1 +
>> hw/multiboot.c | 3 +-
>> hw/ne2000-isa.c | 3 +
>> hw/ne2000.c | 5 ++-
>> hw/nseries.c | 4 +-
>> hw/palm.c | 6 +-
>> hw/parallel.c | 5 ++
>> hw/pc.c | 7 ++-
>> hw/pci.c | 110 ++++++++++++++++++++++++++++++++++++++++-----------
>> hw/pci_host.c | 2 +
>> hw/pckbd.c | 3 +
>> hw/pcnet.c | 6 ++-
>> hw/piix_pci.c | 1 +
>> hw/qdev.c | 32 +++++++++++++++
>> hw/qdev.h | 9 ++++
>> hw/rtl8139.c | 4 ++
>> hw/sb16.c | 4 ++
>> hw/scsi-bus.c | 23 +++++++++++
>> hw/scsi-disk.c | 2 +
>> hw/serial.c | 1 +
>> hw/sysbus.c | 30 ++++++++++++++
>> hw/sysbus.h | 4 ++
>> hw/usb-bus.c | 45 ++++++++++++++++++++-
>> hw/usb-hub.c | 3 +-
>> hw/usb-musb.c | 2 +-
>> hw/usb-net.c | 3 +
>> hw/usb-ohci.c | 2 +-
>> hw/usb-uhci.c | 2 +-
>> hw/usb.h | 3 +-
>> hw/virtio-blk.c | 2 +
>> hw/virtio-net.c | 2 +
>> hw/virtio-pci.c | 1 +
>> net.h | 4 +-
>> qemu-config.c | 17 ++++++++
>> sysemu.h | 11 +++++-
>> vl.c | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
>> 56 files changed, 588 insertions(+), 80 deletions(-)
>>
>> --
>> 1.7.2.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
> --
> Gleb.
>
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-23 16:12 ` Anthony Liguori
0 siblings, 0 replies; 136+ messages in thread
From: Anthony Liguori @ 2010-11-23 16:12 UTC (permalink / raw)
To: Gleb Natapov
Cc: Anthony Liguori, kvm, mst, qemu-devel, armbru, blauwirbel,
alex.williamson, kevin
On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> Anthony, Blue
>
> No comments on this patch series for almost a week. Can it be applied?
>
Does that mean everyone's happy or have folks not gotten around to
review it?
IOW, last call if you have objections :-)
Regards,
Anthony Liguori
> On Wed, Nov 17, 2010 at 06:43:47PM +0200, Gleb Natapov wrote:
>
>> I am using open firmware naming scheme to specify device path names.
>> In this version: added SCSI bus support. Pass boot order list as file
>> to firmware.
>>
>> Names look like this on pci machine:
>> /pci@i0cf8/ide@1,1/drive@1/disk@0
>> /pci@i0cf8/isa@1/fdc@03f1/floppy@1
>> /pci@i0cf8/isa@1/fdc@03f1/floppy@0
>> /pci@i0cf8/ide@1,1/drive@1/disk@1
>> /pci@i0cf8/ide@1,1/drive@0/disk@0
>> /pci@i0cf8/scsi@3/disk@0,0
>> /pci@i0cf8/ethernet@4/ethernet-phy@0
>> /pci@i0cf8/ethernet@5/ethernet-phy@0
>> /pci@i0cf8/ide@1,1/drive@0/disk@1
>> /pci@i0cf8/isa@1/ide@01e8/drive@0/disk@0
>> /pci@i0cf8/usb@1,2/network@0/ethernet@0
>> /pci@i0cf8/usb@1,2/hub@1/network@0/ethernet@0
>> /rom@genroms/linuxboot.bin
>>
>> and on isa machine:
>> /isa/ide@0170/drive@0/disk@0
>> /isa/fdc@03f1/floppy@1
>> /isa/fdc@03f1/floppy@0
>> /isa/ide@0170/drive@0/disk@1
>>
>> Instead of using get_dev_path() callback I introduces another one
>> get_fw_dev_path. Unfortunately the way get_dev_path() callback is used
>> in migration code makes it hard to reuse it for other purposes. First
>> of all it is not called recursively so caller expects it to provide
>> unique name by itself. Device path though is inherently recursive. Each
>> individual element may not be unique, but the whole path will be. On
>> the other hand to call get_dev_path() recursively in migration code we
>> should implement it for all possible buses first. Other problem is
>> compatibility. If we change get_dev_path() output format now we will not
>> be able to migrate from old qemu to new one without some additional
>> compatibility layer.
>>
>> Gleb Natapov (16):
>> Introduce fw_name field to DeviceInfo structure.
>> Introduce new BusInfo callback get_fw_dev_path.
>> Keep track of ISA ports ISA device is using in qdev.
>> Add get_fw_dev_path callback to ISA bus in qdev.
>> Store IDE bus id in IDEBus structure for easy access.
>> Add get_fw_dev_path callback to IDE bus.
>> Add get_dev_path callback for system bus.
>> Add get_fw_dev_path callback for pci bus.
>> Record which USBDevice USBPort belongs too.
>> Add get_dev_path callback for usb bus.
>> Add get_dev_path callback to scsi bus.
>> Add bootindex parameter to net/block/fd device
>> Change fw_cfg_add_file() to get full file path as a parameter.
>> Add bootindex for option roms.
>> Add notifier that will be called when machine is fully created.
>> Pass boot device list to firmware.
>>
>> block_int.h | 4 +-
>> hw/cs4231a.c | 1 +
>> hw/e1000.c | 4 ++
>> hw/eepro100.c | 3 +
>> hw/fdc.c | 12 ++++++
>> hw/fw_cfg.c | 30 ++++++++------
>> hw/fw_cfg.h | 4 +-
>> hw/gus.c | 4 ++
>> hw/ide/cmd646.c | 4 +-
>> hw/ide/internal.h | 3 +-
>> hw/ide/isa.c | 5 ++-
>> hw/ide/piix.c | 4 +-
>> hw/ide/qdev.c | 22 ++++++++++-
>> hw/ide/via.c | 4 +-
>> hw/isa-bus.c | 42 +++++++++++++++++++
>> hw/isa.h | 4 ++
>> hw/lance.c | 1 +
>> hw/loader.c | 32 ++++++++++++---
>> hw/loader.h | 8 ++--
>> hw/m48t59.c | 1 +
>> hw/mc146818rtc.c | 1 +
>> hw/multiboot.c | 3 +-
>> hw/ne2000-isa.c | 3 +
>> hw/ne2000.c | 5 ++-
>> hw/nseries.c | 4 +-
>> hw/palm.c | 6 +-
>> hw/parallel.c | 5 ++
>> hw/pc.c | 7 ++-
>> hw/pci.c | 110 ++++++++++++++++++++++++++++++++++++++++-----------
>> hw/pci_host.c | 2 +
>> hw/pckbd.c | 3 +
>> hw/pcnet.c | 6 ++-
>> hw/piix_pci.c | 1 +
>> hw/qdev.c | 32 +++++++++++++++
>> hw/qdev.h | 9 ++++
>> hw/rtl8139.c | 4 ++
>> hw/sb16.c | 4 ++
>> hw/scsi-bus.c | 23 +++++++++++
>> hw/scsi-disk.c | 2 +
>> hw/serial.c | 1 +
>> hw/sysbus.c | 30 ++++++++++++++
>> hw/sysbus.h | 4 ++
>> hw/usb-bus.c | 45 ++++++++++++++++++++-
>> hw/usb-hub.c | 3 +-
>> hw/usb-musb.c | 2 +-
>> hw/usb-net.c | 3 +
>> hw/usb-ohci.c | 2 +-
>> hw/usb-uhci.c | 2 +-
>> hw/usb.h | 3 +-
>> hw/virtio-blk.c | 2 +
>> hw/virtio-net.c | 2 +
>> hw/virtio-pci.c | 1 +
>> net.h | 4 +-
>> qemu-config.c | 17 ++++++++
>> sysemu.h | 11 +++++-
>> vl.c | 114 ++++++++++++++++++++++++++++++++++++++++++++++++++++-
>> 56 files changed, 588 insertions(+), 80 deletions(-)
>>
>> --
>> 1.7.2.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
> --
> Gleb.
>
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-23 16:12 ` [Qemu-devel] " Anthony Liguori
@ 2010-11-23 19:30 ` Blue Swirl
-1 siblings, 0 replies; 136+ messages in thread
From: Blue Swirl @ 2010-11-23 19:30 UTC (permalink / raw)
To: Anthony Liguori
Cc: Gleb Natapov, qemu-devel, kvm, armbru, alex.williamson, mst,
kevin, Anthony Liguori
On Tue, Nov 23, 2010 at 4:12 PM, Anthony Liguori
<aliguori@linux.vnet.ibm.com> wrote:
> On 11/23/2010 09:31 AM, Gleb Natapov wrote:
>>
>> Anthony, Blue
>>
>> No comments on this patch series for almost a week. Can it be applied?
>>
>
> Does that mean everyone's happy or have folks not gotten around to review
> it?
>
> IOW, last call if you have objections :-)
I'm happy with the patch set in general, I've just been very busy IRL.
More experiments with Sparc32 device paths would not hurt, but bugs
(if any) can be fixed later.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-23 19:30 ` Blue Swirl
0 siblings, 0 replies; 136+ messages in thread
From: Blue Swirl @ 2010-11-23 19:30 UTC (permalink / raw)
To: Anthony Liguori
Cc: Anthony Liguori, kvm, Gleb Natapov, mst, armbru, qemu-devel,
alex.williamson, kevin
On Tue, Nov 23, 2010 at 4:12 PM, Anthony Liguori
<aliguori@linux.vnet.ibm.com> wrote:
> On 11/23/2010 09:31 AM, Gleb Natapov wrote:
>>
>> Anthony, Blue
>>
>> No comments on this patch series for almost a week. Can it be applied?
>>
>
> Does that mean everyone's happy or have folks not gotten around to review
> it?
>
> IOW, last call if you have objections :-)
I'm happy with the patch set in general, I've just been very busy IRL.
More experiments with Sparc32 device paths would not hurt, but bugs
(if any) can be fixed later.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-23 16:12 ` [Qemu-devel] " Anthony Liguori
@ 2010-11-27 20:56 ` Avi Kivity
-1 siblings, 0 replies; 136+ messages in thread
From: Avi Kivity @ 2010-11-27 20:56 UTC (permalink / raw)
To: Anthony Liguori
Cc: Gleb Natapov, qemu-devel, kvm, blauwirbel, armbru,
alex.williamson, mst, kevin, Anthony Liguori
On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> On 11/23/2010 09:31 AM, Gleb Natapov wrote:
>> Anthony, Blue
>>
>> No comments on this patch series for almost a week. Can it be applied?
>
> Does that mean everyone's happy or have folks not gotten around to
> review it?
>
> IOW, last call if you have objections :-)
>
I haven't reviewed this - I trust the author and maintainers to get it
right.
But I notice the there is no documentation - surely some is needed?
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-27 20:56 ` Avi Kivity
0 siblings, 0 replies; 136+ messages in thread
From: Avi Kivity @ 2010-11-27 20:56 UTC (permalink / raw)
To: Anthony Liguori
Cc: Anthony Liguori, kvm, Gleb Natapov, mst, armbru, qemu-devel,
blauwirbel, alex.williamson, kevin
On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> On 11/23/2010 09:31 AM, Gleb Natapov wrote:
>> Anthony, Blue
>>
>> No comments on this patch series for almost a week. Can it be applied?
>
> Does that mean everyone's happy or have folks not gotten around to
> review it?
>
> IOW, last call if you have objections :-)
>
I haven't reviewed this - I trust the author and maintainers to get it
right.
But I notice the there is no documentation - surely some is needed?
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-27 20:56 ` [Qemu-devel] " Avi Kivity
@ 2010-11-28 7:54 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 7:54 UTC (permalink / raw)
To: Avi Kivity
Cc: Anthony Liguori, qemu-devel, kvm, blauwirbel, armbru,
alex.williamson, mst, kevin, Anthony Liguori
On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> >>Anthony, Blue
> >>
> >>No comments on this patch series for almost a week. Can it be applied?
> >
> >Does that mean everyone's happy or have folks not gotten around to
> >review it?
> >
> >IOW, last call if you have objections :-)
> >
>
> I haven't reviewed this - I trust the author and maintainers to get
> it right.
>
> But I notice the there is no documentation - surely some is needed?
>
The patch creates Openfirmware device path from qdev
hierarchy. Each element of a device path depends on type of a bus
the device resides on. You can find various bus bindings here:
http://playground.sun.com/1275/bindings/ and main spec is here
http://forthworks.com/standards/of1275.pdf. Format in which list of
device paths is passed to firmware is documented by comment (it is very
simple). The only thing missing is command line option documentation. I
will add it and resend if no more changes are needed for patch to be
excepted.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-28 7:54 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 7:54 UTC (permalink / raw)
To: Avi Kivity
Cc: Anthony Liguori, kvm, mst, qemu-devel, armbru, blauwirbel,
Anthony Liguori, alex.williamson, kevin
On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> >>Anthony, Blue
> >>
> >>No comments on this patch series for almost a week. Can it be applied?
> >
> >Does that mean everyone's happy or have folks not gotten around to
> >review it?
> >
> >IOW, last call if you have objections :-)
> >
>
> I haven't reviewed this - I trust the author and maintainers to get
> it right.
>
> But I notice the there is no documentation - surely some is needed?
>
The patch creates Openfirmware device path from qdev
hierarchy. Each element of a device path depends on type of a bus
the device resides on. You can find various bus bindings here:
http://playground.sun.com/1275/bindings/ and main spec is here
http://forthworks.com/standards/of1275.pdf. Format in which list of
device paths is passed to firmware is documented by comment (it is very
simple). The only thing missing is command line option documentation. I
will add it and resend if no more changes are needed for patch to be
excepted.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-28 7:54 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-28 9:38 ` Avi Kivity
-1 siblings, 0 replies; 136+ messages in thread
From: Avi Kivity @ 2010-11-28 9:38 UTC (permalink / raw)
To: Gleb Natapov
Cc: Anthony Liguori, qemu-devel, kvm, blauwirbel, armbru,
alex.williamson, mst, kevin, Anthony Liguori
On 11/28/2010 09:54 AM, Gleb Natapov wrote:
> On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> > >>Anthony, Blue
> > >>
> > >>No comments on this patch series for almost a week. Can it be applied?
> > >
> > >Does that mean everyone's happy or have folks not gotten around to
> > >review it?
> > >
> > >IOW, last call if you have objections :-)
> > >
> >
> > I haven't reviewed this - I trust the author and maintainers to get
> > it right.
> >
> > But I notice the there is no documentation - surely some is needed?
> >
>
> The patch creates Openfirmware device path from qdev
> hierarchy. Each element of a device path depends on type of a bus
> the device resides on. You can find various bus bindings here:
> http://playground.sun.com/1275/bindings/ and main spec is here
> http://forthworks.com/standards/of1275.pdf. Format in which list of
> device paths is passed to firmware is documented by comment (it is very
> simple). The only thing missing is command line option documentation. I
> will add it and resend if no more changes are needed for patch to be
> excepted.
What about the format of the fwcfg interface? It should be described,
and point to the references above.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-28 9:38 ` Avi Kivity
0 siblings, 0 replies; 136+ messages in thread
From: Avi Kivity @ 2010-11-28 9:38 UTC (permalink / raw)
To: Gleb Natapov
Cc: Anthony Liguori, kvm, mst, qemu-devel, armbru, blauwirbel,
Anthony Liguori, alex.williamson, kevin
On 11/28/2010 09:54 AM, Gleb Natapov wrote:
> On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> > >>Anthony, Blue
> > >>
> > >>No comments on this patch series for almost a week. Can it be applied?
> > >
> > >Does that mean everyone's happy or have folks not gotten around to
> > >review it?
> > >
> > >IOW, last call if you have objections :-)
> > >
> >
> > I haven't reviewed this - I trust the author and maintainers to get
> > it right.
> >
> > But I notice the there is no documentation - surely some is needed?
> >
>
> The patch creates Openfirmware device path from qdev
> hierarchy. Each element of a device path depends on type of a bus
> the device resides on. You can find various bus bindings here:
> http://playground.sun.com/1275/bindings/ and main spec is here
> http://forthworks.com/standards/of1275.pdf. Format in which list of
> device paths is passed to firmware is documented by comment (it is very
> simple). The only thing missing is command line option documentation. I
> will add it and resend if no more changes are needed for patch to be
> excepted.
What about the format of the fwcfg interface? It should be described,
and point to the references above.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-28 9:38 ` [Qemu-devel] " Avi Kivity
@ 2010-11-28 9:47 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 9:47 UTC (permalink / raw)
To: Avi Kivity
Cc: Anthony Liguori, qemu-devel, kvm, blauwirbel, armbru,
alex.williamson, mst, kevin, Anthony Liguori
On Sun, Nov 28, 2010 at 11:38:36AM +0200, Avi Kivity wrote:
> On 11/28/2010 09:54 AM, Gleb Natapov wrote:
> >On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> >> On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> >> >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> >> >>Anthony, Blue
> >> >>
> >> >>No comments on this patch series for almost a week. Can it be applied?
> >> >
> >> >Does that mean everyone's happy or have folks not gotten around to
> >> >review it?
> >> >
> >> >IOW, last call if you have objections :-)
> >> >
> >>
> >> I haven't reviewed this - I trust the author and maintainers to get
> >> it right.
> >>
> >> But I notice the there is no documentation - surely some is needed?
> >>
> >
> >The patch creates Openfirmware device path from qdev
> >hierarchy. Each element of a device path depends on type of a bus
> >the device resides on. You can find various bus bindings here:
> >http://playground.sun.com/1275/bindings/ and main spec is here
> >http://forthworks.com/standards/of1275.pdf. Format in which list of
> >device paths is passed to firmware is documented by comment (it is very
> >simple). The only thing missing is command line option documentation. I
> >will add it and resend if no more changes are needed for patch to be
> >excepted.
>
> What about the format of the fwcfg interface? It should be
> described, and point to the references above.
>
As I said above it is described in a comment above get_boot_devices_list().
No pointers to Openfirmware there, will put them above get_fw_dev_path()
definition in qdev.h where they belong.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-28 9:47 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 9:47 UTC (permalink / raw)
To: Avi Kivity
Cc: Anthony Liguori, kvm, mst, qemu-devel, armbru, blauwirbel,
Anthony Liguori, alex.williamson, kevin
On Sun, Nov 28, 2010 at 11:38:36AM +0200, Avi Kivity wrote:
> On 11/28/2010 09:54 AM, Gleb Natapov wrote:
> >On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> >> On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> >> >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> >> >>Anthony, Blue
> >> >>
> >> >>No comments on this patch series for almost a week. Can it be applied?
> >> >
> >> >Does that mean everyone's happy or have folks not gotten around to
> >> >review it?
> >> >
> >> >IOW, last call if you have objections :-)
> >> >
> >>
> >> I haven't reviewed this - I trust the author and maintainers to get
> >> it right.
> >>
> >> But I notice the there is no documentation - surely some is needed?
> >>
> >
> >The patch creates Openfirmware device path from qdev
> >hierarchy. Each element of a device path depends on type of a bus
> >the device resides on. You can find various bus bindings here:
> >http://playground.sun.com/1275/bindings/ and main spec is here
> >http://forthworks.com/standards/of1275.pdf. Format in which list of
> >device paths is passed to firmware is documented by comment (it is very
> >simple). The only thing missing is command line option documentation. I
> >will add it and resend if no more changes are needed for patch to be
> >excepted.
>
> What about the format of the fwcfg interface? It should be
> described, and point to the references above.
>
As I said above it is described in a comment above get_boot_devices_list().
No pointers to Openfirmware there, will put them above get_fw_dev_path()
definition in qdev.h where they belong.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-28 7:54 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-28 12:39 ` Blue Swirl
-1 siblings, 0 replies; 136+ messages in thread
From: Blue Swirl @ 2010-11-28 12:39 UTC (permalink / raw)
To: Gleb Natapov
Cc: Avi Kivity, Anthony Liguori, qemu-devel, kvm, armbru,
alex.williamson, mst, kevin, Anthony Liguori
On Sun, Nov 28, 2010 at 7:54 AM, Gleb Natapov <gleb@redhat.com> wrote:
> On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
>> On 11/23/2010 06:12 PM, Anthony Liguori wrote:
>> >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
>> >>Anthony, Blue
>> >>
>> >>No comments on this patch series for almost a week. Can it be applied?
>> >
>> >Does that mean everyone's happy or have folks not gotten around to
>> >review it?
>> >
>> >IOW, last call if you have objections :-)
>> >
>>
>> I haven't reviewed this - I trust the author and maintainers to get
>> it right.
>>
>> But I notice the there is no documentation - surely some is needed?
>>
>
> The patch creates Openfirmware device path from qdev
> hierarchy. Each element of a device path depends on type of a bus
> the device resides on. You can find various bus bindings here:
> http://playground.sun.com/1275/bindings/ and main spec is here
> http://forthworks.com/standards/of1275.pdf. Format in which list of
> device paths is passed to firmware is documented by comment (it is very
> simple). The only thing missing is command line option documentation. I
> will add it and resend if no more changes are needed for patch to be
> excepted.
The patches don't apply anymore due to recent changes to pcnet.c.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-28 12:39 ` Blue Swirl
0 siblings, 0 replies; 136+ messages in thread
From: Blue Swirl @ 2010-11-28 12:39 UTC (permalink / raw)
To: Gleb Natapov
Cc: Anthony Liguori, kvm, mst, armbru, qemu-devel, Anthony Liguori,
alex.williamson, kevin, Avi Kivity
On Sun, Nov 28, 2010 at 7:54 AM, Gleb Natapov <gleb@redhat.com> wrote:
> On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
>> On 11/23/2010 06:12 PM, Anthony Liguori wrote:
>> >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
>> >>Anthony, Blue
>> >>
>> >>No comments on this patch series for almost a week. Can it be applied?
>> >
>> >Does that mean everyone's happy or have folks not gotten around to
>> >review it?
>> >
>> >IOW, last call if you have objections :-)
>> >
>>
>> I haven't reviewed this - I trust the author and maintainers to get
>> it right.
>>
>> But I notice the there is no documentation - surely some is needed?
>>
>
> The patch creates Openfirmware device path from qdev
> hierarchy. Each element of a device path depends on type of a bus
> the device resides on. You can find various bus bindings here:
> http://playground.sun.com/1275/bindings/ and main spec is here
> http://forthworks.com/standards/of1275.pdf. Format in which list of
> device paths is passed to firmware is documented by comment (it is very
> simple). The only thing missing is command line option documentation. I
> will add it and resend if no more changes are needed for patch to be
> excepted.
The patches don't apply anymore due to recent changes to pcnet.c.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-28 12:39 ` [Qemu-devel] " Blue Swirl
@ 2010-11-28 13:03 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 13:03 UTC (permalink / raw)
To: Blue Swirl
Cc: Avi Kivity, Anthony Liguori, qemu-devel, kvm, armbru,
alex.williamson, mst, kevin, Anthony Liguori
On Sun, Nov 28, 2010 at 12:39:13PM +0000, Blue Swirl wrote:
> On Sun, Nov 28, 2010 at 7:54 AM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> >> On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> >> >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> >> >>Anthony, Blue
> >> >>
> >> >>No comments on this patch series for almost a week. Can it be applied?
> >> >
> >> >Does that mean everyone's happy or have folks not gotten around to
> >> >review it?
> >> >
> >> >IOW, last call if you have objections :-)
> >> >
> >>
> >> I haven't reviewed this - I trust the author and maintainers to get
> >> it right.
> >>
> >> But I notice the there is no documentation - surely some is needed?
> >>
> >
> > The patch creates Openfirmware device path from qdev
> > hierarchy. Each element of a device path depends on type of a bus
> > the device resides on. You can find various bus bindings here:
> > http://playground.sun.com/1275/bindings/ and main spec is here
> > http://forthworks.com/standards/of1275.pdf. Format in which list of
> > device paths is passed to firmware is documented by comment (it is very
> > simple). The only thing missing is command line option documentation. I
> > will add it and resend if no more changes are needed for patch to be
> > excepted.
>
> The patches don't apply anymore due to recent changes to pcnet.c.
Will resend rebased with documentation fixes after concluding discussion
with Kevin.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-28 13:03 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 13:03 UTC (permalink / raw)
To: Blue Swirl
Cc: Anthony Liguori, kvm, mst, armbru, qemu-devel, Anthony Liguori,
alex.williamson, kevin, Avi Kivity
On Sun, Nov 28, 2010 at 12:39:13PM +0000, Blue Swirl wrote:
> On Sun, Nov 28, 2010 at 7:54 AM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> >> On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> >> >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> >> >>Anthony, Blue
> >> >>
> >> >>No comments on this patch series for almost a week. Can it be applied?
> >> >
> >> >Does that mean everyone's happy or have folks not gotten around to
> >> >review it?
> >> >
> >> >IOW, last call if you have objections :-)
> >> >
> >>
> >> I haven't reviewed this - I trust the author and maintainers to get
> >> it right.
> >>
> >> But I notice the there is no documentation - surely some is needed?
> >>
> >
> > The patch creates Openfirmware device path from qdev
> > hierarchy. Each element of a device path depends on type of a bus
> > the device resides on. You can find various bus bindings here:
> > http://playground.sun.com/1275/bindings/ and main spec is here
> > http://forthworks.com/standards/of1275.pdf. Format in which list of
> > device paths is passed to firmware is documented by comment (it is very
> > simple). The only thing missing is command line option documentation. I
> > will add it and resend if no more changes are needed for patch to be
> > excepted.
>
> The patches don't apply anymore due to recent changes to pcnet.c.
Will resend rebased with documentation fixes after concluding discussion
with Kevin.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-28 7:54 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-28 13:13 ` Michael S. Tsirkin
-1 siblings, 0 replies; 136+ messages in thread
From: Michael S. Tsirkin @ 2010-11-28 13:13 UTC (permalink / raw)
To: Gleb Natapov
Cc: Avi Kivity, Anthony Liguori, qemu-devel, kvm, blauwirbel, armbru,
alex.williamson, kevin, Anthony Liguori
On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote:
> On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> > >>Anthony, Blue
> > >>
> > >>No comments on this patch series for almost a week. Can it be applied?
> > >
> > >Does that mean everyone's happy or have folks not gotten around to
> > >review it?
> > >
> > >IOW, last call if you have objections :-)
> > >
> >
> > I haven't reviewed this - I trust the author and maintainers to get
> > it right.
> >
> > But I notice the there is no documentation - surely some is needed?
> >
>
> The patch creates Openfirmware device path from qdev
> hierarchy. Each element of a device path depends on type of a bus
> the device resides on. You can find various bus bindings here:
> http://playground.sun.com/1275/bindings/ and main spec is here
sun.com links have a tendency to disappear nowdays :)
Is this the official location? Aren't bindings part of some standard?
It also worries me that PCI Express bindings are in a 'proposal' form
from August 2004. The PCI bindings are from 1994. They are likely to miss
some recent technology advancements :)
Further, while this last document which is only 28 page in length, is
not readable by itself: one must first digest the openfirmware spec.
However ...
> http://forthworks.com/standards/of1275.pdf.
That's 266 pages of a specification. I am guessing that most of it is
irrelevant for the task in question? Can we have a small text document
including just the path format, please?
> Format in which list of
> device paths is passed to firmware is documented by comment (it is very
> simple). The only thing missing is command line option documentation. I
> will add it and resend if no more changes are needed for patch to be
> excepted.
>
> --
> Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-28 13:13 ` Michael S. Tsirkin
0 siblings, 0 replies; 136+ messages in thread
From: Michael S. Tsirkin @ 2010-11-28 13:13 UTC (permalink / raw)
To: Gleb Natapov
Cc: Anthony Liguori, kvm, armbru, qemu-devel, blauwirbel,
Anthony Liguori, alex.williamson, kevin, Avi Kivity
On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote:
> On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> > >>Anthony, Blue
> > >>
> > >>No comments on this patch series for almost a week. Can it be applied?
> > >
> > >Does that mean everyone's happy or have folks not gotten around to
> > >review it?
> > >
> > >IOW, last call if you have objections :-)
> > >
> >
> > I haven't reviewed this - I trust the author and maintainers to get
> > it right.
> >
> > But I notice the there is no documentation - surely some is needed?
> >
>
> The patch creates Openfirmware device path from qdev
> hierarchy. Each element of a device path depends on type of a bus
> the device resides on. You can find various bus bindings here:
> http://playground.sun.com/1275/bindings/ and main spec is here
sun.com links have a tendency to disappear nowdays :)
Is this the official location? Aren't bindings part of some standard?
It also worries me that PCI Express bindings are in a 'proposal' form
from August 2004. The PCI bindings are from 1994. They are likely to miss
some recent technology advancements :)
Further, while this last document which is only 28 page in length, is
not readable by itself: one must first digest the openfirmware spec.
However ...
> http://forthworks.com/standards/of1275.pdf.
That's 266 pages of a specification. I am guessing that most of it is
irrelevant for the task in question? Can we have a small text document
including just the path format, please?
> Format in which list of
> device paths is passed to firmware is documented by comment (it is very
> simple). The only thing missing is command line option documentation. I
> will add it and resend if no more changes are needed for patch to be
> excepted.
>
> --
> Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-28 13:13 ` [Qemu-devel] " Michael S. Tsirkin
@ 2010-11-28 13:19 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 13:19 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Avi Kivity, Anthony Liguori, qemu-devel, kvm, blauwirbel, armbru,
alex.williamson, kevin, Anthony Liguori
On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote:
> On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote:
> > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> > > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> > > >>Anthony, Blue
> > > >>
> > > >>No comments on this patch series for almost a week. Can it be applied?
> > > >
> > > >Does that mean everyone's happy or have folks not gotten around to
> > > >review it?
> > > >
> > > >IOW, last call if you have objections :-)
> > > >
> > >
> > > I haven't reviewed this - I trust the author and maintainers to get
> > > it right.
> > >
> > > But I notice the there is no documentation - surely some is needed?
> > >
> >
> > The patch creates Openfirmware device path from qdev
> > hierarchy. Each element of a device path depends on type of a bus
> > the device resides on. You can find various bus bindings here:
> > http://playground.sun.com/1275/bindings/ and main spec is here
>
> sun.com links have a tendency to disappear nowdays :)
> Is this the official location? Aren't bindings part of some standard?
I think this is official location.
>
> It also worries me that PCI Express bindings are in a 'proposal' form
> from August 2004. The PCI bindings are from 1994. They are likely to miss
> some recent technology advancements :)
>
>
> Further, while this last document which is only 28 page in length, is
> not readable by itself: one must first digest the openfirmware spec.
> However ...
>
> > http://forthworks.com/standards/of1275.pdf.
>
> That's 266 pages of a specification. I am guessing that most of it is
> irrelevant for the task in question? Can we have a small text document
> including just the path format, please?
>
So basically you are complaining that reading specs is difficult. It is. That's
life.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-28 13:19 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 13:19 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Anthony Liguori, kvm, armbru, qemu-devel, blauwirbel,
Anthony Liguori, alex.williamson, kevin, Avi Kivity
On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote:
> On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote:
> > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> > > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> > > >>Anthony, Blue
> > > >>
> > > >>No comments on this patch series for almost a week. Can it be applied?
> > > >
> > > >Does that mean everyone's happy or have folks not gotten around to
> > > >review it?
> > > >
> > > >IOW, last call if you have objections :-)
> > > >
> > >
> > > I haven't reviewed this - I trust the author and maintainers to get
> > > it right.
> > >
> > > But I notice the there is no documentation - surely some is needed?
> > >
> >
> > The patch creates Openfirmware device path from qdev
> > hierarchy. Each element of a device path depends on type of a bus
> > the device resides on. You can find various bus bindings here:
> > http://playground.sun.com/1275/bindings/ and main spec is here
>
> sun.com links have a tendency to disappear nowdays :)
> Is this the official location? Aren't bindings part of some standard?
I think this is official location.
>
> It also worries me that PCI Express bindings are in a 'proposal' form
> from August 2004. The PCI bindings are from 1994. They are likely to miss
> some recent technology advancements :)
>
>
> Further, while this last document which is only 28 page in length, is
> not readable by itself: one must first digest the openfirmware spec.
> However ...
>
> > http://forthworks.com/standards/of1275.pdf.
>
> That's 266 pages of a specification. I am guessing that most of it is
> irrelevant for the task in question? Can we have a small text document
> including just the path format, please?
>
So basically you are complaining that reading specs is difficult. It is. That's
life.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-28 13:19 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-28 13:22 ` Blue Swirl
-1 siblings, 0 replies; 136+ messages in thread
From: Blue Swirl @ 2010-11-28 13:22 UTC (permalink / raw)
To: Gleb Natapov
Cc: Michael S. Tsirkin, Avi Kivity, Anthony Liguori, qemu-devel, kvm,
armbru, alex.williamson, kevin, Anthony Liguori
On Sun, Nov 28, 2010 at 1:19 PM, Gleb Natapov <gleb@redhat.com> wrote:
> On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote:
>> On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote:
>> > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
>> > > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
>> > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
>> > > >>Anthony, Blue
>> > > >>
>> > > >>No comments on this patch series for almost a week. Can it be applied?
>> > > >
>> > > >Does that mean everyone's happy or have folks not gotten around to
>> > > >review it?
>> > > >
>> > > >IOW, last call if you have objections :-)
>> > > >
>> > >
>> > > I haven't reviewed this - I trust the author and maintainers to get
>> > > it right.
>> > >
>> > > But I notice the there is no documentation - surely some is needed?
>> > >
>> >
>> > The patch creates Openfirmware device path from qdev
>> > hierarchy. Each element of a device path depends on type of a bus
>> > the device resides on. You can find various bus bindings here:
>> > http://playground.sun.com/1275/bindings/ and main spec is here
>>
>> sun.com links have a tendency to disappear nowdays :)
>> Is this the official location? Aren't bindings part of some standard?
> I think this is official location.
I'd suppose some of them are IEEE standards, available for a fee.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-28 13:22 ` Blue Swirl
0 siblings, 0 replies; 136+ messages in thread
From: Blue Swirl @ 2010-11-28 13:22 UTC (permalink / raw)
To: Gleb Natapov
Cc: Anthony Liguori, kvm, Michael S. Tsirkin, qemu-devel, armbru,
Anthony Liguori, alex.williamson, kevin, Avi Kivity
On Sun, Nov 28, 2010 at 1:19 PM, Gleb Natapov <gleb@redhat.com> wrote:
> On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote:
>> On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote:
>> > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
>> > > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
>> > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
>> > > >>Anthony, Blue
>> > > >>
>> > > >>No comments on this patch series for almost a week. Can it be applied?
>> > > >
>> > > >Does that mean everyone's happy or have folks not gotten around to
>> > > >review it?
>> > > >
>> > > >IOW, last call if you have objections :-)
>> > > >
>> > >
>> > > I haven't reviewed this - I trust the author and maintainers to get
>> > > it right.
>> > >
>> > > But I notice the there is no documentation - surely some is needed?
>> > >
>> >
>> > The patch creates Openfirmware device path from qdev
>> > hierarchy. Each element of a device path depends on type of a bus
>> > the device resides on. You can find various bus bindings here:
>> > http://playground.sun.com/1275/bindings/ and main spec is here
>>
>> sun.com links have a tendency to disappear nowdays :)
>> Is this the official location? Aren't bindings part of some standard?
> I think this is official location.
I'd suppose some of them are IEEE standards, available for a fee.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-28 13:22 ` [Qemu-devel] " Blue Swirl
@ 2010-11-28 17:02 ` Michael S. Tsirkin
-1 siblings, 0 replies; 136+ messages in thread
From: Michael S. Tsirkin @ 2010-11-28 17:02 UTC (permalink / raw)
To: Blue Swirl
Cc: Gleb Natapov, Avi Kivity, Anthony Liguori, qemu-devel, kvm,
armbru, alex.williamson, kevin, Anthony Liguori
On Sun, Nov 28, 2010 at 01:22:42PM +0000, Blue Swirl wrote:
> On Sun, Nov 28, 2010 at 1:19 PM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote:
> >> On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote:
> >> > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> >> > > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> >> > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> >> > > >>Anthony, Blue
> >> > > >>
> >> > > >>No comments on this patch series for almost a week. Can it be applied?
> >> > > >
> >> > > >Does that mean everyone's happy or have folks not gotten around to
> >> > > >review it?
> >> > > >
> >> > > >IOW, last call if you have objections :-)
> >> > > >
> >> > >
> >> > > I haven't reviewed this - I trust the author and maintainers to get
> >> > > it right.
> >> > >
> >> > > But I notice the there is no documentation - surely some is needed?
> >> > >
> >> >
> >> > The patch creates Openfirmware device path from qdev
> >> > hierarchy. Each element of a device path depends on type of a bus
> >> > the device resides on. You can find various bus bindings here:
> >> > http://playground.sun.com/1275/bindings/ and main spec is here
> >>
> >> sun.com links have a tendency to disappear nowdays :)
> >> Is this the official location? Aren't bindings part of some standard?
> > I think this is official location.
>
> I'd suppose some of them are IEEE standards, available for a fee.
I don't think so:
The IEEE-1275 Open Firmware standard was not reaffirmed by the OFWG and
has been officially withdrawn by IEEE. Unfortunately, this means it is
unavailable from the IEEE.
--
MST
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-28 17:02 ` Michael S. Tsirkin
0 siblings, 0 replies; 136+ messages in thread
From: Michael S. Tsirkin @ 2010-11-28 17:02 UTC (permalink / raw)
To: Blue Swirl
Cc: Anthony Liguori, Gleb Natapov, kvm, armbru, qemu-devel,
Anthony Liguori, alex.williamson, kevin, Avi Kivity
On Sun, Nov 28, 2010 at 01:22:42PM +0000, Blue Swirl wrote:
> On Sun, Nov 28, 2010 at 1:19 PM, Gleb Natapov <gleb@redhat.com> wrote:
> > On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote:
> >> On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote:
> >> > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> >> > > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> >> > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> >> > > >>Anthony, Blue
> >> > > >>
> >> > > >>No comments on this patch series for almost a week. Can it be applied?
> >> > > >
> >> > > >Does that mean everyone's happy or have folks not gotten around to
> >> > > >review it?
> >> > > >
> >> > > >IOW, last call if you have objections :-)
> >> > > >
> >> > >
> >> > > I haven't reviewed this - I trust the author and maintainers to get
> >> > > it right.
> >> > >
> >> > > But I notice the there is no documentation - surely some is needed?
> >> > >
> >> >
> >> > The patch creates Openfirmware device path from qdev
> >> > hierarchy. Each element of a device path depends on type of a bus
> >> > the device resides on. You can find various bus bindings here:
> >> > http://playground.sun.com/1275/bindings/ and main spec is here
> >>
> >> sun.com links have a tendency to disappear nowdays :)
> >> Is this the official location? Aren't bindings part of some standard?
> > I think this is official location.
>
> I'd suppose some of them are IEEE standards, available for a fee.
I don't think so:
The IEEE-1275 Open Firmware standard was not reaffirmed by the OFWG and
has been officially withdrawn by IEEE. Unfortunately, this means it is
unavailable from the IEEE.
--
MST
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-28 13:19 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-28 17:23 ` Michael S. Tsirkin
-1 siblings, 0 replies; 136+ messages in thread
From: Michael S. Tsirkin @ 2010-11-28 17:23 UTC (permalink / raw)
To: Gleb Natapov
Cc: Avi Kivity, Anthony Liguori, qemu-devel, kvm, blauwirbel, armbru,
alex.williamson, kevin, Anthony Liguori
On Sun, Nov 28, 2010 at 03:19:00PM +0200, Gleb Natapov wrote:
> On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote:
> > On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote:
> > > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> > > > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> > > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> > > > >>Anthony, Blue
> > > > >>
> > > > >>No comments on this patch series for almost a week. Can it be applied?
> > > > >
> > > > >Does that mean everyone's happy or have folks not gotten around to
> > > > >review it?
> > > > >
> > > > >IOW, last call if you have objections :-)
> > > > >
> > > >
> > > > I haven't reviewed this - I trust the author and maintainers to get
> > > > it right.
> > > >
> > > > But I notice the there is no documentation - surely some is needed?
> > > >
> > >
> > > The patch creates Openfirmware device path from qdev
> > > hierarchy. Each element of a device path depends on type of a bus
> > > the device resides on. You can find various bus bindings here:
> > > http://playground.sun.com/1275/bindings/ and main spec is here
> >
> > sun.com links have a tendency to disappear nowdays :)
> > Is this the official location? Aren't bindings part of some standard?
> I think this is official location.
> >
> > It also worries me that PCI Express bindings are in a 'proposal' form
> > from August 2004. The PCI bindings are from 1994. They are likely to miss
> > some recent technology advancements :)
> >
> >
> > Further, while this last document which is only 28 page in length, is
> > not readable by itself: one must first digest the openfirmware spec.
> > However ...
> >
> > > http://forthworks.com/standards/of1275.pdf.
> >
> > That's 266 pages of a specification. I am guessing that most of it is
> > irrelevant for the task in question? Can we have a small text document
> > including just the path format, please?
> >
> So basically you are complaining that reading specs is difficult. It is. That's
> life.
Well, the specific format used is undocumented. Patch borrowed bits from
various specs, but it's undocumented which bits, and from which specs.
I do realize you had to go over all of these specs and do the difficult work
to come up with the format, but please write documentation
for the rest of us.
> --
> Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-28 17:23 ` Michael S. Tsirkin
0 siblings, 0 replies; 136+ messages in thread
From: Michael S. Tsirkin @ 2010-11-28 17:23 UTC (permalink / raw)
To: Gleb Natapov
Cc: Anthony Liguori, kvm, armbru, qemu-devel, blauwirbel,
Anthony Liguori, alex.williamson, kevin, Avi Kivity
On Sun, Nov 28, 2010 at 03:19:00PM +0200, Gleb Natapov wrote:
> On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote:
> > On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote:
> > > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> > > > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> > > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> > > > >>Anthony, Blue
> > > > >>
> > > > >>No comments on this patch series for almost a week. Can it be applied?
> > > > >
> > > > >Does that mean everyone's happy or have folks not gotten around to
> > > > >review it?
> > > > >
> > > > >IOW, last call if you have objections :-)
> > > > >
> > > >
> > > > I haven't reviewed this - I trust the author and maintainers to get
> > > > it right.
> > > >
> > > > But I notice the there is no documentation - surely some is needed?
> > > >
> > >
> > > The patch creates Openfirmware device path from qdev
> > > hierarchy. Each element of a device path depends on type of a bus
> > > the device resides on. You can find various bus bindings here:
> > > http://playground.sun.com/1275/bindings/ and main spec is here
> >
> > sun.com links have a tendency to disappear nowdays :)
> > Is this the official location? Aren't bindings part of some standard?
> I think this is official location.
> >
> > It also worries me that PCI Express bindings are in a 'proposal' form
> > from August 2004. The PCI bindings are from 1994. They are likely to miss
> > some recent technology advancements :)
> >
> >
> > Further, while this last document which is only 28 page in length, is
> > not readable by itself: one must first digest the openfirmware spec.
> > However ...
> >
> > > http://forthworks.com/standards/of1275.pdf.
> >
> > That's 266 pages of a specification. I am guessing that most of it is
> > irrelevant for the task in question? Can we have a small text document
> > including just the path format, please?
> >
> So basically you are complaining that reading specs is difficult. It is. That's
> life.
Well, the specific format used is undocumented. Patch borrowed bits from
various specs, but it's undocumented which bits, and from which specs.
I do realize you had to go over all of these specs and do the difficult work
to come up with the format, but please write documentation
for the rest of us.
> --
> Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-28 17:23 ` [Qemu-devel] " Michael S. Tsirkin
@ 2010-11-28 18:54 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 18:54 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Avi Kivity, Anthony Liguori, qemu-devel, kvm, blauwirbel, armbru,
alex.williamson, kevin, Anthony Liguori
On Sun, Nov 28, 2010 at 07:23:20PM +0200, Michael S. Tsirkin wrote:
> On Sun, Nov 28, 2010 at 03:19:00PM +0200, Gleb Natapov wrote:
> > On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote:
> > > On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote:
> > > > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> > > > > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> > > > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> > > > > >>Anthony, Blue
> > > > > >>
> > > > > >>No comments on this patch series for almost a week. Can it be applied?
> > > > > >
> > > > > >Does that mean everyone's happy or have folks not gotten around to
> > > > > >review it?
> > > > > >
> > > > > >IOW, last call if you have objections :-)
> > > > > >
> > > > >
> > > > > I haven't reviewed this - I trust the author and maintainers to get
> > > > > it right.
> > > > >
> > > > > But I notice the there is no documentation - surely some is needed?
> > > > >
> > > >
> > > > The patch creates Openfirmware device path from qdev
> > > > hierarchy. Each element of a device path depends on type of a bus
> > > > the device resides on. You can find various bus bindings here:
> > > > http://playground.sun.com/1275/bindings/ and main spec is here
> > >
> > > sun.com links have a tendency to disappear nowdays :)
> > > Is this the official location? Aren't bindings part of some standard?
> > I think this is official location.
> > >
> > > It also worries me that PCI Express bindings are in a 'proposal' form
> > > from August 2004. The PCI bindings are from 1994. They are likely to miss
> > > some recent technology advancements :)
> > >
> > >
> > > Further, while this last document which is only 28 page in length, is
> > > not readable by itself: one must first digest the openfirmware spec.
> > > However ...
> > >
> > > > http://forthworks.com/standards/of1275.pdf.
> > >
> > > That's 266 pages of a specification. I am guessing that most of it is
> > > irrelevant for the task in question? Can we have a small text document
> > > including just the path format, please?
> > >
> > So basically you are complaining that reading specs is difficult. It is. That's
> > life.
>
> Well, the specific format used is undocumented. Patch borrowed bits from
> various specs, but it's undocumented which bits, and from which specs.
>
See above for documentation. Download everything. Read.
> I do realize you had to go over all of these specs and do the difficult work
> to come up with the format, but please write documentation
> for the rest of us.
>
Pleas read spec. You can even find that I interpreted spec incorrectly
and point where the bug is. That is the reason spec exists. I do not
ask you to provide me with documentation for each and every thing you do
in pci layer although it will be much simpler to read your executive
summery then go and read complicated spec. The same hold true for any
other piece of code that implement spec.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-28 18:54 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 18:54 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Anthony Liguori, kvm, armbru, qemu-devel, blauwirbel,
Anthony Liguori, alex.williamson, kevin, Avi Kivity
On Sun, Nov 28, 2010 at 07:23:20PM +0200, Michael S. Tsirkin wrote:
> On Sun, Nov 28, 2010 at 03:19:00PM +0200, Gleb Natapov wrote:
> > On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote:
> > > On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote:
> > > > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> > > > > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> > > > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> > > > > >>Anthony, Blue
> > > > > >>
> > > > > >>No comments on this patch series for almost a week. Can it be applied?
> > > > > >
> > > > > >Does that mean everyone's happy or have folks not gotten around to
> > > > > >review it?
> > > > > >
> > > > > >IOW, last call if you have objections :-)
> > > > > >
> > > > >
> > > > > I haven't reviewed this - I trust the author and maintainers to get
> > > > > it right.
> > > > >
> > > > > But I notice the there is no documentation - surely some is needed?
> > > > >
> > > >
> > > > The patch creates Openfirmware device path from qdev
> > > > hierarchy. Each element of a device path depends on type of a bus
> > > > the device resides on. You can find various bus bindings here:
> > > > http://playground.sun.com/1275/bindings/ and main spec is here
> > >
> > > sun.com links have a tendency to disappear nowdays :)
> > > Is this the official location? Aren't bindings part of some standard?
> > I think this is official location.
> > >
> > > It also worries me that PCI Express bindings are in a 'proposal' form
> > > from August 2004. The PCI bindings are from 1994. They are likely to miss
> > > some recent technology advancements :)
> > >
> > >
> > > Further, while this last document which is only 28 page in length, is
> > > not readable by itself: one must first digest the openfirmware spec.
> > > However ...
> > >
> > > > http://forthworks.com/standards/of1275.pdf.
> > >
> > > That's 266 pages of a specification. I am guessing that most of it is
> > > irrelevant for the task in question? Can we have a small text document
> > > including just the path format, please?
> > >
> > So basically you are complaining that reading specs is difficult. It is. That's
> > life.
>
> Well, the specific format used is undocumented. Patch borrowed bits from
> various specs, but it's undocumented which bits, and from which specs.
>
See above for documentation. Download everything. Read.
> I do realize you had to go over all of these specs and do the difficult work
> to come up with the format, but please write documentation
> for the rest of us.
>
Pleas read spec. You can even find that I interpreted spec incorrectly
and point where the bug is. That is the reason spec exists. I do not
ask you to provide me with documentation for each and every thing you do
in pci layer although it will be much simpler to read your executive
summery then go and read complicated spec. The same hold true for any
other piece of code that implement spec.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-28 18:54 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-28 19:09 ` Michael S. Tsirkin
-1 siblings, 0 replies; 136+ messages in thread
From: Michael S. Tsirkin @ 2010-11-28 19:09 UTC (permalink / raw)
To: Gleb Natapov
Cc: Avi Kivity, Anthony Liguori, qemu-devel, kvm, blauwirbel, armbru,
alex.williamson, kevin, Anthony Liguori
On Sun, Nov 28, 2010 at 08:54:38PM +0200, Gleb Natapov wrote:
> On Sun, Nov 28, 2010 at 07:23:20PM +0200, Michael S. Tsirkin wrote:
> > On Sun, Nov 28, 2010 at 03:19:00PM +0200, Gleb Natapov wrote:
> > > On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote:
> > > > On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote:
> > > > > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> > > > > > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> > > > > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> > > > > > >>Anthony, Blue
> > > > > > >>
> > > > > > >>No comments on this patch series for almost a week. Can it be applied?
> > > > > > >
> > > > > > >Does that mean everyone's happy or have folks not gotten around to
> > > > > > >review it?
> > > > > > >
> > > > > > >IOW, last call if you have objections :-)
> > > > > > >
> > > > > >
> > > > > > I haven't reviewed this - I trust the author and maintainers to get
> > > > > > it right.
> > > > > >
> > > > > > But I notice the there is no documentation - surely some is needed?
> > > > > >
> > > > >
> > > > > The patch creates Openfirmware device path from qdev
> > > > > hierarchy. Each element of a device path depends on type of a bus
> > > > > the device resides on. You can find various bus bindings here:
> > > > > http://playground.sun.com/1275/bindings/ and main spec is here
> > > >
> > > > sun.com links have a tendency to disappear nowdays :)
> > > > Is this the official location? Aren't bindings part of some standard?
> > > I think this is official location.
> > > >
> > > > It also worries me that PCI Express bindings are in a 'proposal' form
> > > > from August 2004. The PCI bindings are from 1994. They are likely to miss
> > > > some recent technology advancements :)
> > > >
> > > >
> > > > Further, while this last document which is only 28 page in length, is
> > > > not readable by itself: one must first digest the openfirmware spec.
> > > > However ...
> > > >
> > > > > http://forthworks.com/standards/of1275.pdf.
> > > >
> > > > That's 266 pages of a specification. I am guessing that most of it is
> > > > irrelevant for the task in question? Can we have a small text document
> > > > including just the path format, please?
> > > >
> > > So basically you are complaining that reading specs is difficult. It is. That's
> > > life.
> >
> > Well, the specific format used is undocumented. Patch borrowed bits from
> > various specs, but it's undocumented which bits, and from which specs.
> >
> See above for documentation. Download everything. Read.
>
> > I do realize you had to go over all of these specs and do the difficult work
> > to come up with the format, but please write documentation
> > for the rest of us.
> >
> Pleas read spec. You can even find that I interpreted spec incorrectly
> and point where the bug is.
Seems a waste of time. As long as qemu and BIOS agree, it does
not matter what does the spec say.
> That is the reason spec exists. I do not
> ask you to provide me with documentation for each and every thing you do
> in pci layer although it will be much simpler to read your executive
> summery then go and read complicated spec. The same hold true for any
> other piece of code that implement spec.
>
> --
> Gleb.
PCI is a hardware spec that guest drivers rely on for functionality. If
we implement it incorrectly, guests break. We also implement a large
part of the spec, quite unlike this case. The spec is also
organazed in the way that maps to our code. So if you
have msix.c, you look up msix in table of content and
you got it. And, we are adding pointers to spec chapters as we go on.
--
MST
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-28 19:09 ` Michael S. Tsirkin
0 siblings, 0 replies; 136+ messages in thread
From: Michael S. Tsirkin @ 2010-11-28 19:09 UTC (permalink / raw)
To: Gleb Natapov
Cc: Anthony Liguori, kvm, armbru, qemu-devel, blauwirbel,
Anthony Liguori, alex.williamson, kevin, Avi Kivity
On Sun, Nov 28, 2010 at 08:54:38PM +0200, Gleb Natapov wrote:
> On Sun, Nov 28, 2010 at 07:23:20PM +0200, Michael S. Tsirkin wrote:
> > On Sun, Nov 28, 2010 at 03:19:00PM +0200, Gleb Natapov wrote:
> > > On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote:
> > > > On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote:
> > > > > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> > > > > > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> > > > > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> > > > > > >>Anthony, Blue
> > > > > > >>
> > > > > > >>No comments on this patch series for almost a week. Can it be applied?
> > > > > > >
> > > > > > >Does that mean everyone's happy or have folks not gotten around to
> > > > > > >review it?
> > > > > > >
> > > > > > >IOW, last call if you have objections :-)
> > > > > > >
> > > > > >
> > > > > > I haven't reviewed this - I trust the author and maintainers to get
> > > > > > it right.
> > > > > >
> > > > > > But I notice the there is no documentation - surely some is needed?
> > > > > >
> > > > >
> > > > > The patch creates Openfirmware device path from qdev
> > > > > hierarchy. Each element of a device path depends on type of a bus
> > > > > the device resides on. You can find various bus bindings here:
> > > > > http://playground.sun.com/1275/bindings/ and main spec is here
> > > >
> > > > sun.com links have a tendency to disappear nowdays :)
> > > > Is this the official location? Aren't bindings part of some standard?
> > > I think this is official location.
> > > >
> > > > It also worries me that PCI Express bindings are in a 'proposal' form
> > > > from August 2004. The PCI bindings are from 1994. They are likely to miss
> > > > some recent technology advancements :)
> > > >
> > > >
> > > > Further, while this last document which is only 28 page in length, is
> > > > not readable by itself: one must first digest the openfirmware spec.
> > > > However ...
> > > >
> > > > > http://forthworks.com/standards/of1275.pdf.
> > > >
> > > > That's 266 pages of a specification. I am guessing that most of it is
> > > > irrelevant for the task in question? Can we have a small text document
> > > > including just the path format, please?
> > > >
> > > So basically you are complaining that reading specs is difficult. It is. That's
> > > life.
> >
> > Well, the specific format used is undocumented. Patch borrowed bits from
> > various specs, but it's undocumented which bits, and from which specs.
> >
> See above for documentation. Download everything. Read.
>
> > I do realize you had to go over all of these specs and do the difficult work
> > to come up with the format, but please write documentation
> > for the rest of us.
> >
> Pleas read spec. You can even find that I interpreted spec incorrectly
> and point where the bug is.
Seems a waste of time. As long as qemu and BIOS agree, it does
not matter what does the spec say.
> That is the reason spec exists. I do not
> ask you to provide me with documentation for each and every thing you do
> in pci layer although it will be much simpler to read your executive
> summery then go and read complicated spec. The same hold true for any
> other piece of code that implement spec.
>
> --
> Gleb.
PCI is a hardware spec that guest drivers rely on for functionality. If
we implement it incorrectly, guests break. We also implement a large
part of the spec, quite unlike this case. The spec is also
organazed in the way that maps to our code. So if you
have msix.c, you look up msix in table of content and
you got it. And, we are adding pointers to spec chapters as we go on.
--
MST
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-28 19:09 ` [Qemu-devel] " Michael S. Tsirkin
@ 2010-11-28 19:20 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 19:20 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Avi Kivity, Anthony Liguori, qemu-devel, kvm, blauwirbel, armbru,
alex.williamson, kevin, Anthony Liguori
On Sun, Nov 28, 2010 at 09:09:48PM +0200, Michael S. Tsirkin wrote:
> On Sun, Nov 28, 2010 at 08:54:38PM +0200, Gleb Natapov wrote:
> > On Sun, Nov 28, 2010 at 07:23:20PM +0200, Michael S. Tsirkin wrote:
> > > On Sun, Nov 28, 2010 at 03:19:00PM +0200, Gleb Natapov wrote:
> > > > On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote:
> > > > > On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote:
> > > > > > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> > > > > > > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> > > > > > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> > > > > > > >>Anthony, Blue
> > > > > > > >>
> > > > > > > >>No comments on this patch series for almost a week. Can it be applied?
> > > > > > > >
> > > > > > > >Does that mean everyone's happy or have folks not gotten around to
> > > > > > > >review it?
> > > > > > > >
> > > > > > > >IOW, last call if you have objections :-)
> > > > > > > >
> > > > > > >
> > > > > > > I haven't reviewed this - I trust the author and maintainers to get
> > > > > > > it right.
> > > > > > >
> > > > > > > But I notice the there is no documentation - surely some is needed?
> > > > > > >
> > > > > >
> > > > > > The patch creates Openfirmware device path from qdev
> > > > > > hierarchy. Each element of a device path depends on type of a bus
> > > > > > the device resides on. You can find various bus bindings here:
> > > > > > http://playground.sun.com/1275/bindings/ and main spec is here
> > > > >
> > > > > sun.com links have a tendency to disappear nowdays :)
> > > > > Is this the official location? Aren't bindings part of some standard?
> > > > I think this is official location.
> > > > >
> > > > > It also worries me that PCI Express bindings are in a 'proposal' form
> > > > > from August 2004. The PCI bindings are from 1994. They are likely to miss
> > > > > some recent technology advancements :)
> > > > >
> > > > >
> > > > > Further, while this last document which is only 28 page in length, is
> > > > > not readable by itself: one must first digest the openfirmware spec.
> > > > > However ...
> > > > >
> > > > > > http://forthworks.com/standards/of1275.pdf.
> > > > >
> > > > > That's 266 pages of a specification. I am guessing that most of it is
> > > > > irrelevant for the task in question? Can we have a small text document
> > > > > including just the path format, please?
> > > > >
> > > > So basically you are complaining that reading specs is difficult. It is. That's
> > > > life.
> > >
> > > Well, the specific format used is undocumented. Patch borrowed bits from
> > > various specs, but it's undocumented which bits, and from which specs.
> > >
> > See above for documentation. Download everything. Read.
> >
> > > I do realize you had to go over all of these specs and do the difficult work
> > > to come up with the format, but please write documentation
> > > for the rest of us.
> > >
> > Pleas read spec. You can even find that I interpreted spec incorrectly
> > and point where the bug is.
>
> Seems a waste of time. As long as qemu and BIOS agree, it does
> not matter what does the spec say.
>
So what. I don't get this "summarize spec for me here" request.
> > That is the reason spec exists. I do not
> > ask you to provide me with documentation for each and every thing you do
> > in pci layer although it will be much simpler to read your executive
> > summery then go and read complicated spec. The same hold true for any
> > other piece of code that implement spec.
> >
> > --
> > Gleb.
>
> PCI is a hardware spec that guest drivers rely on for functionality. If
> we implement it incorrectly, guests break. We also implement a large
> part of the spec, quite unlike this case. The spec is also
> organazed in the way that maps to our code. So if you
> have msix.c, you look up msix in table of content and
> you got it. And, we are adding pointers to spec chapters as we go on.
>
>
With next patch to pci summarize pci spec for me please. It is to big
and complex for me to understand in 3 minutes I have to look at it.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-28 19:20 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 19:20 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Anthony Liguori, kvm, armbru, qemu-devel, blauwirbel,
Anthony Liguori, alex.williamson, kevin, Avi Kivity
On Sun, Nov 28, 2010 at 09:09:48PM +0200, Michael S. Tsirkin wrote:
> On Sun, Nov 28, 2010 at 08:54:38PM +0200, Gleb Natapov wrote:
> > On Sun, Nov 28, 2010 at 07:23:20PM +0200, Michael S. Tsirkin wrote:
> > > On Sun, Nov 28, 2010 at 03:19:00PM +0200, Gleb Natapov wrote:
> > > > On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote:
> > > > > On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote:
> > > > > > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> > > > > > > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> > > > > > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> > > > > > > >>Anthony, Blue
> > > > > > > >>
> > > > > > > >>No comments on this patch series for almost a week. Can it be applied?
> > > > > > > >
> > > > > > > >Does that mean everyone's happy or have folks not gotten around to
> > > > > > > >review it?
> > > > > > > >
> > > > > > > >IOW, last call if you have objections :-)
> > > > > > > >
> > > > > > >
> > > > > > > I haven't reviewed this - I trust the author and maintainers to get
> > > > > > > it right.
> > > > > > >
> > > > > > > But I notice the there is no documentation - surely some is needed?
> > > > > > >
> > > > > >
> > > > > > The patch creates Openfirmware device path from qdev
> > > > > > hierarchy. Each element of a device path depends on type of a bus
> > > > > > the device resides on. You can find various bus bindings here:
> > > > > > http://playground.sun.com/1275/bindings/ and main spec is here
> > > > >
> > > > > sun.com links have a tendency to disappear nowdays :)
> > > > > Is this the official location? Aren't bindings part of some standard?
> > > > I think this is official location.
> > > > >
> > > > > It also worries me that PCI Express bindings are in a 'proposal' form
> > > > > from August 2004. The PCI bindings are from 1994. They are likely to miss
> > > > > some recent technology advancements :)
> > > > >
> > > > >
> > > > > Further, while this last document which is only 28 page in length, is
> > > > > not readable by itself: one must first digest the openfirmware spec.
> > > > > However ...
> > > > >
> > > > > > http://forthworks.com/standards/of1275.pdf.
> > > > >
> > > > > That's 266 pages of a specification. I am guessing that most of it is
> > > > > irrelevant for the task in question? Can we have a small text document
> > > > > including just the path format, please?
> > > > >
> > > > So basically you are complaining that reading specs is difficult. It is. That's
> > > > life.
> > >
> > > Well, the specific format used is undocumented. Patch borrowed bits from
> > > various specs, but it's undocumented which bits, and from which specs.
> > >
> > See above for documentation. Download everything. Read.
> >
> > > I do realize you had to go over all of these specs and do the difficult work
> > > to come up with the format, but please write documentation
> > > for the rest of us.
> > >
> > Pleas read spec. You can even find that I interpreted spec incorrectly
> > and point where the bug is.
>
> Seems a waste of time. As long as qemu and BIOS agree, it does
> not matter what does the spec say.
>
So what. I don't get this "summarize spec for me here" request.
> > That is the reason spec exists. I do not
> > ask you to provide me with documentation for each and every thing you do
> > in pci layer although it will be much simpler to read your executive
> > summery then go and read complicated spec. The same hold true for any
> > other piece of code that implement spec.
> >
> > --
> > Gleb.
>
> PCI is a hardware spec that guest drivers rely on for functionality. If
> we implement it incorrectly, guests break. We also implement a large
> part of the spec, quite unlike this case. The spec is also
> organazed in the way that maps to our code. So if you
> have msix.c, you look up msix in table of content and
> you got it. And, we are adding pointers to spec chapters as we go on.
>
>
With next patch to pci summarize pci spec for me please. It is to big
and complex for me to understand in 3 minutes I have to look at it.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-28 13:13 ` [Qemu-devel] " Michael S. Tsirkin
@ 2010-11-28 13:25 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 13:25 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Avi Kivity, Anthony Liguori, qemu-devel, kvm, blauwirbel, armbru,
alex.williamson, kevin, Anthony Liguori
On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote:
> On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote:
> > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> > > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> > > >>Anthony, Blue
> > > >>
> > > >>No comments on this patch series for almost a week. Can it be applied?
> > > >
> > > >Does that mean everyone's happy or have folks not gotten around to
> > > >review it?
> > > >
> > > >IOW, last call if you have objections :-)
> > > >
> > >
> > > I haven't reviewed this - I trust the author and maintainers to get
> > > it right.
> > >
> > > But I notice the there is no documentation - surely some is needed?
> > >
> >
> > The patch creates Openfirmware device path from qdev
> > hierarchy. Each element of a device path depends on type of a bus
> > the device resides on. You can find various bus bindings here:
> > http://playground.sun.com/1275/bindings/ and main spec is here
>
> sun.com links have a tendency to disappear nowdays :)
> Is this the official location? Aren't bindings part of some standard?
>
BTW on this link they are better organized:
http://playground.sun.com/pub/p1275/home.html
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-28 13:25 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 13:25 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Anthony Liguori, kvm, armbru, qemu-devel, blauwirbel,
Anthony Liguori, alex.williamson, kevin, Avi Kivity
On Sun, Nov 28, 2010 at 03:13:52PM +0200, Michael S. Tsirkin wrote:
> On Sun, Nov 28, 2010 at 09:54:04AM +0200, Gleb Natapov wrote:
> > On Sat, Nov 27, 2010 at 10:56:10PM +0200, Avi Kivity wrote:
> > > On 11/23/2010 06:12 PM, Anthony Liguori wrote:
> > > >On 11/23/2010 09:31 AM, Gleb Natapov wrote:
> > > >>Anthony, Blue
> > > >>
> > > >>No comments on this patch series for almost a week. Can it be applied?
> > > >
> > > >Does that mean everyone's happy or have folks not gotten around to
> > > >review it?
> > > >
> > > >IOW, last call if you have objections :-)
> > > >
> > >
> > > I haven't reviewed this - I trust the author and maintainers to get
> > > it right.
> > >
> > > But I notice the there is no documentation - surely some is needed?
> > >
> >
> > The patch creates Openfirmware device path from qdev
> > hierarchy. Each element of a device path depends on type of a bus
> > the device resides on. You can find various bus bindings here:
> > http://playground.sun.com/1275/bindings/ and main spec is here
>
> sun.com links have a tendency to disappear nowdays :)
> Is this the official location? Aren't bindings part of some standard?
>
BTW on this link they are better organized:
http://playground.sun.com/pub/p1275/home.html
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-23 15:31 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-24 1:19 ` Kevin O'Connor
-1 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-11-24 1:19 UTC (permalink / raw)
To: Gleb Natapov
Cc: qemu-devel, kvm, blauwirbel, armbru, alex.williamson, mst,
Anthony Liguori
Hi Gleb,
On Tue, Nov 23, 2010 at 05:31:41PM +0200, Gleb Natapov wrote:
> Anthony, Blue
>
> No comments on this patch series for almost a week. Can it be applied?
My apologies - I haven't had time to review.
> On Wed, Nov 17, 2010 at 06:43:47PM +0200, Gleb Natapov wrote:
> > I am using open firmware naming scheme to specify device path names.
> > In this version: added SCSI bus support. Pass boot order list as file
> > to firmware.
> >
> > Names look like this on pci machine:
[...]
> > /pci@i0cf8/usb@1,2/hub@1/network@0/ethernet@0
> > /rom@genroms/linuxboot.bin
What's the plan for handling optionroms (ie, BCVs and BEVs)? This is
an area which is a bit tricky - mainly due to legacy BIOS crud.
An option rom can register either a BEV (eg, gpxe on a network card),
or it can register one or more BCVs (eg, a scsi card registering two
drives). How do we say boot from the optionrom on the second nic
card? If you have a scsi card, how do we communicate that its second
drive should be the c: drive?
The ugly thing about BCVs is that they are not necessarily registered
in the rom for the device that controls it. So, if you have two of
the same type of scsi card, each with two drives, it's possible for
the optionrom to put all four drives in the rom of the first scsi
card.
> > Gleb Natapov (16):
[...]
> > Pass boot device list to firmware.
It looks like you went with a newline separated list. Thanks.
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-24 1:19 ` Kevin O'Connor
0 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-11-24 1:19 UTC (permalink / raw)
To: Gleb Natapov
Cc: Anthony Liguori, kvm, mst, qemu-devel, armbru, blauwirbel,
alex.williamson
Hi Gleb,
On Tue, Nov 23, 2010 at 05:31:41PM +0200, Gleb Natapov wrote:
> Anthony, Blue
>
> No comments on this patch series for almost a week. Can it be applied?
My apologies - I haven't had time to review.
> On Wed, Nov 17, 2010 at 06:43:47PM +0200, Gleb Natapov wrote:
> > I am using open firmware naming scheme to specify device path names.
> > In this version: added SCSI bus support. Pass boot order list as file
> > to firmware.
> >
> > Names look like this on pci machine:
[...]
> > /pci@i0cf8/usb@1,2/hub@1/network@0/ethernet@0
> > /rom@genroms/linuxboot.bin
What's the plan for handling optionroms (ie, BCVs and BEVs)? This is
an area which is a bit tricky - mainly due to legacy BIOS crud.
An option rom can register either a BEV (eg, gpxe on a network card),
or it can register one or more BCVs (eg, a scsi card registering two
drives). How do we say boot from the optionrom on the second nic
card? If you have a scsi card, how do we communicate that its second
drive should be the c: drive?
The ugly thing about BCVs is that they are not necessarily registered
in the rom for the device that controls it. So, if you have two of
the same type of scsi card, each with two drives, it's possible for
the optionrom to put all four drives in the rom of the first scsi
card.
> > Gleb Natapov (16):
[...]
> > Pass boot device list to firmware.
It looks like you went with a newline separated list. Thanks.
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-24 1:19 ` [Qemu-devel] " Kevin O'Connor
@ 2010-11-24 10:03 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-24 10:03 UTC (permalink / raw)
To: Kevin O'Connor
Cc: qemu-devel, kvm, blauwirbel, armbru, alex.williamson, mst,
Anthony Liguori
On Tue, Nov 23, 2010 at 08:19:07PM -0500, Kevin O'Connor wrote:
> Hi Gleb,
>
> On Tue, Nov 23, 2010 at 05:31:41PM +0200, Gleb Natapov wrote:
> > Anthony, Blue
> >
> > No comments on this patch series for almost a week. Can it be applied?
>
> My apologies - I haven't had time to review.
>
> > On Wed, Nov 17, 2010 at 06:43:47PM +0200, Gleb Natapov wrote:
> > > I am using open firmware naming scheme to specify device path names.
> > > In this version: added SCSI bus support. Pass boot order list as file
> > > to firmware.
> > >
> > > Names look like this on pci machine:
> [...]
> > > /pci@i0cf8/usb@1,2/hub@1/network@0/ethernet@0
> > > /rom@genroms/linuxboot.bin
>
> What's the plan for handling optionroms (ie, BCVs and BEVs)? This is
> an area which is a bit tricky - mainly due to legacy BIOS crud.
>
> An option rom can register either a BEV (eg, gpxe on a network card),
> or it can register one or more BCVs (eg, a scsi card registering two
> drives). How do we say boot from the optionrom on the second nic
> card? If you have a scsi card, how do we communicate that its second
> drive should be the c: drive?
>
BEV should be easy. When you register BEV found on pci card you search
for device path to that pci card to determine BEV's boot order. BCV
should be the same, but since one PCI card may register several
BCVs the problem is more complex. Device path has not only path to
SCSI PCI card but to specific target,lun too. For instance this path
/pci@i0cf8/scsi@3,2/disk@0,0 points to SCSI card in pci slot 3 function 2
target 1 lun 1. The question is if BCV provides us with enough information
to know what target/lun it is going to boot. Another problem is with
device passthroug where if we pass entire SCSI PCI card to a guest we
cannot specify particular target to boot from. This can be solved by
allowing adding boot device paths from command line.
For SCSI the optimal solution would be to have SCSI support for device
QEMU emulates built in in Seabios itself. It is just that current device
QEMU emulates is so old and so buggy that it is not worth to support it.
> The ugly thing about BCVs is that they are not necessarily registered
> in the rom for the device that controls it. So, if you have two of
> the same type of scsi card, each with two drives, it's possible for
> the optionrom to put all four drives in the rom of the first scsi
> card.
>
That just broken optionrom. I can't see how we can solve this without
communicating with such optionrom and letting it know what device we
want to boot from. There can be also legacy optionrom that just hooks
into int19 during init and hijack booting process entirely. I think
those problems exist on real HW too.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-24 10:03 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-24 10:03 UTC (permalink / raw)
To: Kevin O'Connor
Cc: Anthony Liguori, kvm, mst, qemu-devel, armbru, blauwirbel,
alex.williamson
On Tue, Nov 23, 2010 at 08:19:07PM -0500, Kevin O'Connor wrote:
> Hi Gleb,
>
> On Tue, Nov 23, 2010 at 05:31:41PM +0200, Gleb Natapov wrote:
> > Anthony, Blue
> >
> > No comments on this patch series for almost a week. Can it be applied?
>
> My apologies - I haven't had time to review.
>
> > On Wed, Nov 17, 2010 at 06:43:47PM +0200, Gleb Natapov wrote:
> > > I am using open firmware naming scheme to specify device path names.
> > > In this version: added SCSI bus support. Pass boot order list as file
> > > to firmware.
> > >
> > > Names look like this on pci machine:
> [...]
> > > /pci@i0cf8/usb@1,2/hub@1/network@0/ethernet@0
> > > /rom@genroms/linuxboot.bin
>
> What's the plan for handling optionroms (ie, BCVs and BEVs)? This is
> an area which is a bit tricky - mainly due to legacy BIOS crud.
>
> An option rom can register either a BEV (eg, gpxe on a network card),
> or it can register one or more BCVs (eg, a scsi card registering two
> drives). How do we say boot from the optionrom on the second nic
> card? If you have a scsi card, how do we communicate that its second
> drive should be the c: drive?
>
BEV should be easy. When you register BEV found on pci card you search
for device path to that pci card to determine BEV's boot order. BCV
should be the same, but since one PCI card may register several
BCVs the problem is more complex. Device path has not only path to
SCSI PCI card but to specific target,lun too. For instance this path
/pci@i0cf8/scsi@3,2/disk@0,0 points to SCSI card in pci slot 3 function 2
target 1 lun 1. The question is if BCV provides us with enough information
to know what target/lun it is going to boot. Another problem is with
device passthroug where if we pass entire SCSI PCI card to a guest we
cannot specify particular target to boot from. This can be solved by
allowing adding boot device paths from command line.
For SCSI the optimal solution would be to have SCSI support for device
QEMU emulates built in in Seabios itself. It is just that current device
QEMU emulates is so old and so buggy that it is not worth to support it.
> The ugly thing about BCVs is that they are not necessarily registered
> in the rom for the device that controls it. So, if you have two of
> the same type of scsi card, each with two drives, it's possible for
> the optionrom to put all four drives in the rom of the first scsi
> card.
>
That just broken optionrom. I can't see how we can solve this without
communicating with such optionrom and letting it know what device we
want to boot from. There can be also legacy optionrom that just hooks
into int19 during init and hijack booting process entirely. I think
those problems exist on real HW too.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-24 10:03 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-27 15:41 ` Kevin O'Connor
-1 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-11-27 15:41 UTC (permalink / raw)
To: Gleb Natapov
Cc: qemu-devel, kvm, blauwirbel, armbru, alex.williamson, mst,
Anthony Liguori
On Wed, Nov 24, 2010 at 12:03:11PM +0200, Gleb Natapov wrote:
> On Tue, Nov 23, 2010 at 08:19:07PM -0500, Kevin O'Connor wrote:
> > On Tue, Nov 23, 2010 at 05:31:41PM +0200, Gleb Natapov wrote:
> > > On Wed, Nov 17, 2010 at 06:43:47PM +0200, Gleb Natapov wrote:
> > > > I am using open firmware naming scheme to specify device path names.
> > > > In this version: added SCSI bus support. Pass boot order list as file
> > > > to firmware.
> > > >
> > > > Names look like this on pci machine:
> > [...]
> > > > /pci@i0cf8/usb@1,2/hub@1/network@0/ethernet@0
> > > > /rom@genroms/linuxboot.bin
> >
> > What's the plan for handling optionroms (ie, BCVs and BEVs)? This is
> > an area which is a bit tricky - mainly due to legacy BIOS crud.
> >
> > An option rom can register either a BEV (eg, gpxe on a network card),
> > or it can register one or more BCVs (eg, a scsi card registering two
> > drives). How do we say boot from the optionrom on the second nic
> > card? If you have a scsi card, how do we communicate that its second
> > drive should be the c: drive?
> >
> BEV should be easy. When you register BEV found on pci card you search
> for device path to that pci card to determine BEV's boot order.
SeaBIOS has two separate optionrom passes - one to extract the roms
from the cards and one to find BEVs and BCVs. In order to correlate a
rom to a pci device SeaBIOS would have to keep track of each rom it
deploys and then correlate it during the BEV/BCV scan.
>BCV
> should be the same, but since one PCI card may register several
> BCVs the problem is more complex. Device path has not only path to
> SCSI PCI card but to specific target,lun too. For instance this path
> /pci@i0cf8/scsi@3,2/disk@0,0 points to SCSI card in pci slot 3 function 2
> target 1 lun 1. The question is if BCV provides us with enough information
> to know what target/lun it is going to boot.
How will seabios even know it's a SCSI card? All seabios sees is a
PCI device with a valid option rom bar. Further, I don't see how
seabios will know which BCV is which lun.
BTW, I assume you're suggesting that if a disk is found first in the
list then seabios should make that drive the c: and make hard drive
booting be the first thing attempted? (This is what the seabios boot
menu does.)
> > The ugly thing about BCVs is that they are not necessarily registered
> > in the rom for the device that controls it. So, if you have two of
> > the same type of scsi card, each with two drives, it's possible for
> > the optionrom to put all four drives in the rom of the first scsi
> > card.
> >
> That just broken optionrom. I can't see how we can solve this without
> communicating with such optionrom and letting it know what device we
> want to boot from.
I wouldn't call it broken as the BIOS Boot Spec (BBS) specifically
states that optionroms can do this. I don't know how many roms
actually do it.
The BCV and BEVs have a "product name string" that could be used to
identify which one to boot. Unfortunately, there isn't a good way for
qemu to find these strings (though maybe it could just hard code them
for roms it ships with). SeaBIOS does show them in the boot menu, so
a user could manually copy them to a command line.
>There can be also legacy optionrom that just hooks
> into int19 during init and hijack booting process entirely. I think
> those problems exist on real HW too.
That's a separate problem which I wouldn't worry too much about. The
only roms that I've seen do this today are roms we have the source for
and can change.
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-27 15:41 ` Kevin O'Connor
0 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-11-27 15:41 UTC (permalink / raw)
To: Gleb Natapov
Cc: Anthony Liguori, kvm, mst, qemu-devel, armbru, blauwirbel,
alex.williamson
On Wed, Nov 24, 2010 at 12:03:11PM +0200, Gleb Natapov wrote:
> On Tue, Nov 23, 2010 at 08:19:07PM -0500, Kevin O'Connor wrote:
> > On Tue, Nov 23, 2010 at 05:31:41PM +0200, Gleb Natapov wrote:
> > > On Wed, Nov 17, 2010 at 06:43:47PM +0200, Gleb Natapov wrote:
> > > > I am using open firmware naming scheme to specify device path names.
> > > > In this version: added SCSI bus support. Pass boot order list as file
> > > > to firmware.
> > > >
> > > > Names look like this on pci machine:
> > [...]
> > > > /pci@i0cf8/usb@1,2/hub@1/network@0/ethernet@0
> > > > /rom@genroms/linuxboot.bin
> >
> > What's the plan for handling optionroms (ie, BCVs and BEVs)? This is
> > an area which is a bit tricky - mainly due to legacy BIOS crud.
> >
> > An option rom can register either a BEV (eg, gpxe on a network card),
> > or it can register one or more BCVs (eg, a scsi card registering two
> > drives). How do we say boot from the optionrom on the second nic
> > card? If you have a scsi card, how do we communicate that its second
> > drive should be the c: drive?
> >
> BEV should be easy. When you register BEV found on pci card you search
> for device path to that pci card to determine BEV's boot order.
SeaBIOS has two separate optionrom passes - one to extract the roms
from the cards and one to find BEVs and BCVs. In order to correlate a
rom to a pci device SeaBIOS would have to keep track of each rom it
deploys and then correlate it during the BEV/BCV scan.
>BCV
> should be the same, but since one PCI card may register several
> BCVs the problem is more complex. Device path has not only path to
> SCSI PCI card but to specific target,lun too. For instance this path
> /pci@i0cf8/scsi@3,2/disk@0,0 points to SCSI card in pci slot 3 function 2
> target 1 lun 1. The question is if BCV provides us with enough information
> to know what target/lun it is going to boot.
How will seabios even know it's a SCSI card? All seabios sees is a
PCI device with a valid option rom bar. Further, I don't see how
seabios will know which BCV is which lun.
BTW, I assume you're suggesting that if a disk is found first in the
list then seabios should make that drive the c: and make hard drive
booting be the first thing attempted? (This is what the seabios boot
menu does.)
> > The ugly thing about BCVs is that they are not necessarily registered
> > in the rom for the device that controls it. So, if you have two of
> > the same type of scsi card, each with two drives, it's possible for
> > the optionrom to put all four drives in the rom of the first scsi
> > card.
> >
> That just broken optionrom. I can't see how we can solve this without
> communicating with such optionrom and letting it know what device we
> want to boot from.
I wouldn't call it broken as the BIOS Boot Spec (BBS) specifically
states that optionroms can do this. I don't know how many roms
actually do it.
The BCV and BEVs have a "product name string" that could be used to
identify which one to boot. Unfortunately, there isn't a good way for
qemu to find these strings (though maybe it could just hard code them
for roms it ships with). SeaBIOS does show them in the boot menu, so
a user could manually copy them to a command line.
>There can be also legacy optionrom that just hooks
> into int19 during init and hijack booting process entirely. I think
> those problems exist on real HW too.
That's a separate problem which I wouldn't worry too much about. The
only roms that I've seen do this today are roms we have the source for
and can change.
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-27 15:41 ` [Qemu-devel] " Kevin O'Connor
@ 2010-11-27 16:22 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-27 16:22 UTC (permalink / raw)
To: Kevin O'Connor
Cc: qemu-devel, kvm, blauwirbel, armbru, alex.williamson, mst,
Anthony Liguori
On Sat, Nov 27, 2010 at 10:41:10AM -0500, Kevin O'Connor wrote:
> On Wed, Nov 24, 2010 at 12:03:11PM +0200, Gleb Natapov wrote:
> > On Tue, Nov 23, 2010 at 08:19:07PM -0500, Kevin O'Connor wrote:
> > > On Tue, Nov 23, 2010 at 05:31:41PM +0200, Gleb Natapov wrote:
> > > > On Wed, Nov 17, 2010 at 06:43:47PM +0200, Gleb Natapov wrote:
> > > > > I am using open firmware naming scheme to specify device path names.
> > > > > In this version: added SCSI bus support. Pass boot order list as file
> > > > > to firmware.
> > > > >
> > > > > Names look like this on pci machine:
> > > [...]
> > > > > /pci@i0cf8/usb@1,2/hub@1/network@0/ethernet@0
> > > > > /rom@genroms/linuxboot.bin
> > >
> > > What's the plan for handling optionroms (ie, BCVs and BEVs)? This is
> > > an area which is a bit tricky - mainly due to legacy BIOS crud.
> > >
> > > An option rom can register either a BEV (eg, gpxe on a network card),
> > > or it can register one or more BCVs (eg, a scsi card registering two
> > > drives). How do we say boot from the optionrom on the second nic
> > > card? If you have a scsi card, how do we communicate that its second
> > > drive should be the c: drive?
> > >
> > BEV should be easy. When you register BEV found on pci card you search
> > for device path to that pci card to determine BEV's boot order.
>
> SeaBIOS has two separate optionrom passes - one to extract the roms
> from the cards and one to find BEVs and BCVs. In order to correlate a
> rom to a pci device SeaBIOS would have to keep track of each rom it
> deploys and then correlate it during the BEV/BCV scan.
>
Yeah. I looked at the Seabios code. The simplest would be to change
device path to point to rom instead of pci device. So if there is device
path /pci@i0cf8/ethernet@3 when rom is copied into the memory the path
is changed to be /rom@addr where addr is memory address where rom was
copied. The same with roms that are copied from qemu. When rom memory
is later scanned for bevs/bcvs it will be easy to find boot priority of
each one of them.
> >BCV
> > should be the same, but since one PCI card may register several
> > BCVs the problem is more complex. Device path has not only path to
> > SCSI PCI card but to specific target,lun too. For instance this path
> > /pci@i0cf8/scsi@3,2/disk@0,0 points to SCSI card in pci slot 3 function 2
> > target 1 lun 1. The question is if BCV provides us with enough information
> > to know what target/lun it is going to boot.
>
> How will seabios even know it's a SCSI card? All seabios sees is a
> PCI device with a valid option rom bar. Further, I don't see how
> seabios will know which BCV is which lun.
>
Seabios knows that this is SCSI card from its device class.
Unfortunately it looks like bcv does not provide enough info to know what
target it corresponds too. I can't think of enything smart we can do
here, so lets just treat all bcvs as same priority.
> BTW, I assume you're suggesting that if a disk is found first in the
> list then seabios should make that drive the c: and make hard drive
> booting be the first thing attempted? (This is what the seabios boot
> menu does.)
Yes.
>
> > > The ugly thing about BCVs is that they are not necessarily registered
> > > in the rom for the device that controls it. So, if you have two of
> > > the same type of scsi card, each with two drives, it's possible for
> > > the optionrom to put all four drives in the rom of the first scsi
> > > card.
> > >
> > That just broken optionrom. I can't see how we can solve this without
> > communicating with such optionrom and letting it know what device we
> > want to boot from.
>
> I wouldn't call it broken as the BIOS Boot Spec (BBS) specifically
> states that optionroms can do this. I don't know how many roms
> actually do it.
>
BSS tries to documents things post factum. I hope it doesn't encourage
this type of option roms. But how it works if we have two scsi cards
both have same option rom and each one of them tries to register bcv for
all scsi card it found. Won't we have two bcvs registered for each scsi
car then?
> The BCV and BEVs have a "product name string" that could be used to
> identify which one to boot. Unfortunately, there isn't a good way for
> qemu to find these strings (though maybe it could just hard code them
> for roms it ships with). SeaBIOS does show them in the boot menu, so
> a user could manually copy them to a command line.
>
Two disks can have same product name no? And qemu can't even know
product names for pass through devices. Also I wouldn't worry about
optioroms qemu ships. We can fix those.
> >There can be also legacy optionrom that just hooks
> > into int19 during init and hijack booting process entirely. I think
> > those problems exist on real HW too.
>
> That's a separate problem which I wouldn't worry too much about. The
> only roms that I've seen do this today are roms we have the source for
> and can change.
>
Agree.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-27 16:22 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-27 16:22 UTC (permalink / raw)
To: Kevin O'Connor
Cc: Anthony Liguori, kvm, mst, qemu-devel, armbru, blauwirbel,
alex.williamson
On Sat, Nov 27, 2010 at 10:41:10AM -0500, Kevin O'Connor wrote:
> On Wed, Nov 24, 2010 at 12:03:11PM +0200, Gleb Natapov wrote:
> > On Tue, Nov 23, 2010 at 08:19:07PM -0500, Kevin O'Connor wrote:
> > > On Tue, Nov 23, 2010 at 05:31:41PM +0200, Gleb Natapov wrote:
> > > > On Wed, Nov 17, 2010 at 06:43:47PM +0200, Gleb Natapov wrote:
> > > > > I am using open firmware naming scheme to specify device path names.
> > > > > In this version: added SCSI bus support. Pass boot order list as file
> > > > > to firmware.
> > > > >
> > > > > Names look like this on pci machine:
> > > [...]
> > > > > /pci@i0cf8/usb@1,2/hub@1/network@0/ethernet@0
> > > > > /rom@genroms/linuxboot.bin
> > >
> > > What's the plan for handling optionroms (ie, BCVs and BEVs)? This is
> > > an area which is a bit tricky - mainly due to legacy BIOS crud.
> > >
> > > An option rom can register either a BEV (eg, gpxe on a network card),
> > > or it can register one or more BCVs (eg, a scsi card registering two
> > > drives). How do we say boot from the optionrom on the second nic
> > > card? If you have a scsi card, how do we communicate that its second
> > > drive should be the c: drive?
> > >
> > BEV should be easy. When you register BEV found on pci card you search
> > for device path to that pci card to determine BEV's boot order.
>
> SeaBIOS has two separate optionrom passes - one to extract the roms
> from the cards and one to find BEVs and BCVs. In order to correlate a
> rom to a pci device SeaBIOS would have to keep track of each rom it
> deploys and then correlate it during the BEV/BCV scan.
>
Yeah. I looked at the Seabios code. The simplest would be to change
device path to point to rom instead of pci device. So if there is device
path /pci@i0cf8/ethernet@3 when rom is copied into the memory the path
is changed to be /rom@addr where addr is memory address where rom was
copied. The same with roms that are copied from qemu. When rom memory
is later scanned for bevs/bcvs it will be easy to find boot priority of
each one of them.
> >BCV
> > should be the same, but since one PCI card may register several
> > BCVs the problem is more complex. Device path has not only path to
> > SCSI PCI card but to specific target,lun too. For instance this path
> > /pci@i0cf8/scsi@3,2/disk@0,0 points to SCSI card in pci slot 3 function 2
> > target 1 lun 1. The question is if BCV provides us with enough information
> > to know what target/lun it is going to boot.
>
> How will seabios even know it's a SCSI card? All seabios sees is a
> PCI device with a valid option rom bar. Further, I don't see how
> seabios will know which BCV is which lun.
>
Seabios knows that this is SCSI card from its device class.
Unfortunately it looks like bcv does not provide enough info to know what
target it corresponds too. I can't think of enything smart we can do
here, so lets just treat all bcvs as same priority.
> BTW, I assume you're suggesting that if a disk is found first in the
> list then seabios should make that drive the c: and make hard drive
> booting be the first thing attempted? (This is what the seabios boot
> menu does.)
Yes.
>
> > > The ugly thing about BCVs is that they are not necessarily registered
> > > in the rom for the device that controls it. So, if you have two of
> > > the same type of scsi card, each with two drives, it's possible for
> > > the optionrom to put all four drives in the rom of the first scsi
> > > card.
> > >
> > That just broken optionrom. I can't see how we can solve this without
> > communicating with such optionrom and letting it know what device we
> > want to boot from.
>
> I wouldn't call it broken as the BIOS Boot Spec (BBS) specifically
> states that optionroms can do this. I don't know how many roms
> actually do it.
>
BSS tries to documents things post factum. I hope it doesn't encourage
this type of option roms. But how it works if we have two scsi cards
both have same option rom and each one of them tries to register bcv for
all scsi card it found. Won't we have two bcvs registered for each scsi
car then?
> The BCV and BEVs have a "product name string" that could be used to
> identify which one to boot. Unfortunately, there isn't a good way for
> qemu to find these strings (though maybe it could just hard code them
> for roms it ships with). SeaBIOS does show them in the boot menu, so
> a user could manually copy them to a command line.
>
Two disks can have same product name no? And qemu can't even know
product names for pass through devices. Also I wouldn't worry about
optioroms qemu ships. We can fix those.
> >There can be also legacy optionrom that just hooks
> > into int19 during init and hijack booting process entirely. I think
> > those problems exist on real HW too.
>
> That's a separate problem which I wouldn't worry too much about. The
> only roms that I've seen do this today are roms we have the source for
> and can change.
>
Agree.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-27 16:22 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-27 16:49 ` Kevin O'Connor
-1 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-11-27 16:49 UTC (permalink / raw)
To: Gleb Natapov
Cc: qemu-devel, kvm, blauwirbel, armbru, alex.williamson, mst,
Anthony Liguori
On Sat, Nov 27, 2010 at 06:22:16PM +0200, Gleb Natapov wrote:
> On Sat, Nov 27, 2010 at 10:41:10AM -0500, Kevin O'Connor wrote:
> > On Wed, Nov 24, 2010 at 12:03:11PM +0200, Gleb Natapov wrote:
> > > BEV should be easy. When you register BEV found on pci card you search
> > > for device path to that pci card to determine BEV's boot order.
> >
> > SeaBIOS has two separate optionrom passes - one to extract the roms
> > from the cards and one to find BEVs and BCVs. In order to correlate a
> > rom to a pci device SeaBIOS would have to keep track of each rom it
> > deploys and then correlate it during the BEV/BCV scan.
> >
> Yeah. I looked at the Seabios code. The simplest would be to change
> device path to point to rom instead of pci device. So if there is device
> path /pci@i0cf8/ethernet@3 when rom is copied into the memory the path
> is changed to be /rom@addr where addr is memory address where rom was
> copied.
Seabios would change its local copy of the path?
[...]
> > How will seabios even know it's a SCSI card? All seabios sees is a
> > PCI device with a valid option rom bar. Further, I don't see how
> > seabios will know which BCV is which lun.
> >
> Seabios knows that this is SCSI card from its device class.
I assume "ethernet" would be from device class as well?
This seems fragile - it would require seabios to keep a list of device
classes to name mappings, and a user may not be able to boot from a
device if seabios isn't programmed for it (eg, a passthrough device).
> Unfortunately it looks like bcv does not provide enough info to know what
> target it corresponds too. I can't think of enything smart we can do
> here, so lets just treat all bcvs as same priority.
There's the product name and there's the order it was registered in
(ie, the third bcv on the rom).
[...]
> > > That just broken optionrom. I can't see how we can solve this without
> > > communicating with such optionrom and letting it know what device we
> > > want to boot from.
> >
> > I wouldn't call it broken as the BIOS Boot Spec (BBS) specifically
> > states that optionroms can do this. I don't know how many roms
> > actually do it.
> >
> BSS tries to documents things post factum. I hope it doesn't encourage
> this type of option roms. But how it works if we have two scsi cards
> both have same option rom and each one of them tries to register bcv for
> all scsi card it found. Won't we have two bcvs registered for each scsi
> car then?
First optionrom finds all devices for that type of scsi card. Second
optionrom detects that its drives have already been probed and resizes
itself to zero.
> > The BCV and BEVs have a "product name string" that could be used to
> > identify which one to boot. Unfortunately, there isn't a good way for
> > qemu to find these strings (though maybe it could just hard code them
> > for roms it ships with). SeaBIOS does show them in the boot menu, so
> > a user could manually copy them to a command line.
> >
> Two disks can have same product name no? And qemu can't even know
> product names for pass through devices. Also I wouldn't worry about
> optioroms qemu ships. We can fix those.
The product name is supposed to be unique. From the spec:
The data within each header must be valid. Especially the `BCV' and
`Pointer to Product Name String' fields. The BCV should point to a
procedure that installs only that device into INT 13h services. It
is strongly recommended that the Product Name String for each header
uniquely identify the device to which that header belongs, so that
when these strings are displayed to the user in a menu, the user can
intelligently recognize and choose devices connected to that
controller without having to open up the computer.
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-27 16:49 ` Kevin O'Connor
0 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-11-27 16:49 UTC (permalink / raw)
To: Gleb Natapov
Cc: Anthony Liguori, kvm, mst, qemu-devel, armbru, blauwirbel,
alex.williamson
On Sat, Nov 27, 2010 at 06:22:16PM +0200, Gleb Natapov wrote:
> On Sat, Nov 27, 2010 at 10:41:10AM -0500, Kevin O'Connor wrote:
> > On Wed, Nov 24, 2010 at 12:03:11PM +0200, Gleb Natapov wrote:
> > > BEV should be easy. When you register BEV found on pci card you search
> > > for device path to that pci card to determine BEV's boot order.
> >
> > SeaBIOS has two separate optionrom passes - one to extract the roms
> > from the cards and one to find BEVs and BCVs. In order to correlate a
> > rom to a pci device SeaBIOS would have to keep track of each rom it
> > deploys and then correlate it during the BEV/BCV scan.
> >
> Yeah. I looked at the Seabios code. The simplest would be to change
> device path to point to rom instead of pci device. So if there is device
> path /pci@i0cf8/ethernet@3 when rom is copied into the memory the path
> is changed to be /rom@addr where addr is memory address where rom was
> copied.
Seabios would change its local copy of the path?
[...]
> > How will seabios even know it's a SCSI card? All seabios sees is a
> > PCI device with a valid option rom bar. Further, I don't see how
> > seabios will know which BCV is which lun.
> >
> Seabios knows that this is SCSI card from its device class.
I assume "ethernet" would be from device class as well?
This seems fragile - it would require seabios to keep a list of device
classes to name mappings, and a user may not be able to boot from a
device if seabios isn't programmed for it (eg, a passthrough device).
> Unfortunately it looks like bcv does not provide enough info to know what
> target it corresponds too. I can't think of enything smart we can do
> here, so lets just treat all bcvs as same priority.
There's the product name and there's the order it was registered in
(ie, the third bcv on the rom).
[...]
> > > That just broken optionrom. I can't see how we can solve this without
> > > communicating with such optionrom and letting it know what device we
> > > want to boot from.
> >
> > I wouldn't call it broken as the BIOS Boot Spec (BBS) specifically
> > states that optionroms can do this. I don't know how many roms
> > actually do it.
> >
> BSS tries to documents things post factum. I hope it doesn't encourage
> this type of option roms. But how it works if we have two scsi cards
> both have same option rom and each one of them tries to register bcv for
> all scsi card it found. Won't we have two bcvs registered for each scsi
> car then?
First optionrom finds all devices for that type of scsi card. Second
optionrom detects that its drives have already been probed and resizes
itself to zero.
> > The BCV and BEVs have a "product name string" that could be used to
> > identify which one to boot. Unfortunately, there isn't a good way for
> > qemu to find these strings (though maybe it could just hard code them
> > for roms it ships with). SeaBIOS does show them in the boot menu, so
> > a user could manually copy them to a command line.
> >
> Two disks can have same product name no? And qemu can't even know
> product names for pass through devices. Also I wouldn't worry about
> optioroms qemu ships. We can fix those.
The product name is supposed to be unique. From the spec:
The data within each header must be valid. Especially the `BCV' and
`Pointer to Product Name String' fields. The BCV should point to a
procedure that installs only that device into INT 13h services. It
is strongly recommended that the Product Name String for each header
uniquely identify the device to which that header belongs, so that
when these strings are displayed to the user in a menu, the user can
intelligently recognize and choose devices connected to that
controller without having to open up the computer.
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-27 16:49 ` [Qemu-devel] " Kevin O'Connor
@ 2010-11-27 17:06 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-27 17:06 UTC (permalink / raw)
To: Kevin O'Connor
Cc: qemu-devel, kvm, blauwirbel, armbru, alex.williamson, mst,
Anthony Liguori
On Sat, Nov 27, 2010 at 11:49:39AM -0500, Kevin O'Connor wrote:
> On Sat, Nov 27, 2010 at 06:22:16PM +0200, Gleb Natapov wrote:
> > On Sat, Nov 27, 2010 at 10:41:10AM -0500, Kevin O'Connor wrote:
> > > On Wed, Nov 24, 2010 at 12:03:11PM +0200, Gleb Natapov wrote:
> > > > BEV should be easy. When you register BEV found on pci card you search
> > > > for device path to that pci card to determine BEV's boot order.
> > >
> > > SeaBIOS has two separate optionrom passes - one to extract the roms
> > > from the cards and one to find BEVs and BCVs. In order to correlate a
> > > rom to a pci device SeaBIOS would have to keep track of each rom it
> > > deploys and then correlate it during the BEV/BCV scan.
> > >
> > Yeah. I looked at the Seabios code. The simplest would be to change
> > device path to point to rom instead of pci device. So if there is device
> > path /pci@i0cf8/ethernet@3 when rom is copied into the memory the path
> > is changed to be /rom@addr where addr is memory address where rom was
> > copied.
>
> Seabios would change its local copy of the path?
>
Yes.
> [...]
> > > How will seabios even know it's a SCSI card? All seabios sees is a
> > > PCI device with a valid option rom bar. Further, I don't see how
> > > seabios will know which BCV is which lun.
> > >
> > Seabios knows that this is SCSI card from its device class.
>
> I assume "ethernet" would be from device class as well?
>
Yes.
> This seems fragile - it would require seabios to keep a list of device
> classes to name mappings, and a user may not be able to boot from a
> device if seabios isn't programmed for it (eg, a passthrough device).
>
Seabios can ignore device name from device path since the same
information is present in pci config space of the device. So the device path
can be /pci@i0cf8/scis@4 or /pci@i0cf8/@4 Seabios can detect that device
is scsi just by looking at config space of pci device in slot 4 function 0.
For, scsi I think, proper solution would be to have Seabios support for
scsi controller emulated by qemu. This will make all devices bootable from
BCV known to Seabios and will not require option rom. The only problem
then will be with pass through devices, but since now only the whole
scsi controller can be passed through not individual targets qemu can
point device path only to the controller and not individual targets too.
> > Unfortunately it looks like bcv does not provide enough info to know what
> > target it corresponds too. I can't think of enything smart we can do
> > here, so lets just treat all bcvs as same priority.
>
> There's the product name and there's the order it was registered in
> (ie, the third bcv on the rom).
Doesn't help much if we can't correlate bcv to device path.
>
> [...]
> > > > That just broken optionrom. I can't see how we can solve this without
> > > > communicating with such optionrom and letting it know what device we
> > > > want to boot from.
> > >
> > > I wouldn't call it broken as the BIOS Boot Spec (BBS) specifically
> > > states that optionroms can do this. I don't know how many roms
> > > actually do it.
> > >
> > BSS tries to documents things post factum. I hope it doesn't encourage
> > this type of option roms. But how it works if we have two scsi cards
> > both have same option rom and each one of them tries to register bcv for
> > all scsi card it found. Won't we have two bcvs registered for each scsi
> > car then?
>
> First optionrom finds all devices for that type of scsi card. Second
> optionrom detects that its drives have already been probed and resizes
> itself to zero.
>
> > > The BCV and BEVs have a "product name string" that could be used to
> > > identify which one to boot. Unfortunately, there isn't a good way for
> > > qemu to find these strings (though maybe it could just hard code them
> > > for roms it ships with). SeaBIOS does show them in the boot menu, so
> > > a user could manually copy them to a command line.
> > >
> > Two disks can have same product name no? And qemu can't even know
> > product names for pass through devices. Also I wouldn't worry about
> > optioroms qemu ships. We can fix those.
>
> The product name is supposed to be unique. From the spec:
>
> The data within each header must be valid. Especially the `BCV' and
> `Pointer to Product Name String' fields. The BCV should point to a
> procedure that installs only that device into INT 13h services. It
> is strongly recommended that the Product Name String for each header
> uniquely identify the device to which that header belongs, so that
> when these strings are displayed to the user in a menu, the user can
> intelligently recognize and choose devices connected to that
> controller without having to open up the computer.
>
The spec is "strongly recommended", not requires, but I guess if product
violates this recommendation it will have the same problem on real HW
too.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-27 17:06 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-27 17:06 UTC (permalink / raw)
To: Kevin O'Connor
Cc: Anthony Liguori, kvm, mst, qemu-devel, armbru, blauwirbel,
alex.williamson
On Sat, Nov 27, 2010 at 11:49:39AM -0500, Kevin O'Connor wrote:
> On Sat, Nov 27, 2010 at 06:22:16PM +0200, Gleb Natapov wrote:
> > On Sat, Nov 27, 2010 at 10:41:10AM -0500, Kevin O'Connor wrote:
> > > On Wed, Nov 24, 2010 at 12:03:11PM +0200, Gleb Natapov wrote:
> > > > BEV should be easy. When you register BEV found on pci card you search
> > > > for device path to that pci card to determine BEV's boot order.
> > >
> > > SeaBIOS has two separate optionrom passes - one to extract the roms
> > > from the cards and one to find BEVs and BCVs. In order to correlate a
> > > rom to a pci device SeaBIOS would have to keep track of each rom it
> > > deploys and then correlate it during the BEV/BCV scan.
> > >
> > Yeah. I looked at the Seabios code. The simplest would be to change
> > device path to point to rom instead of pci device. So if there is device
> > path /pci@i0cf8/ethernet@3 when rom is copied into the memory the path
> > is changed to be /rom@addr where addr is memory address where rom was
> > copied.
>
> Seabios would change its local copy of the path?
>
Yes.
> [...]
> > > How will seabios even know it's a SCSI card? All seabios sees is a
> > > PCI device with a valid option rom bar. Further, I don't see how
> > > seabios will know which BCV is which lun.
> > >
> > Seabios knows that this is SCSI card from its device class.
>
> I assume "ethernet" would be from device class as well?
>
Yes.
> This seems fragile - it would require seabios to keep a list of device
> classes to name mappings, and a user may not be able to boot from a
> device if seabios isn't programmed for it (eg, a passthrough device).
>
Seabios can ignore device name from device path since the same
information is present in pci config space of the device. So the device path
can be /pci@i0cf8/scis@4 or /pci@i0cf8/@4 Seabios can detect that device
is scsi just by looking at config space of pci device in slot 4 function 0.
For, scsi I think, proper solution would be to have Seabios support for
scsi controller emulated by qemu. This will make all devices bootable from
BCV known to Seabios and will not require option rom. The only problem
then will be with pass through devices, but since now only the whole
scsi controller can be passed through not individual targets qemu can
point device path only to the controller and not individual targets too.
> > Unfortunately it looks like bcv does not provide enough info to know what
> > target it corresponds too. I can't think of enything smart we can do
> > here, so lets just treat all bcvs as same priority.
>
> There's the product name and there's the order it was registered in
> (ie, the third bcv on the rom).
Doesn't help much if we can't correlate bcv to device path.
>
> [...]
> > > > That just broken optionrom. I can't see how we can solve this without
> > > > communicating with such optionrom and letting it know what device we
> > > > want to boot from.
> > >
> > > I wouldn't call it broken as the BIOS Boot Spec (BBS) specifically
> > > states that optionroms can do this. I don't know how many roms
> > > actually do it.
> > >
> > BSS tries to documents things post factum. I hope it doesn't encourage
> > this type of option roms. But how it works if we have two scsi cards
> > both have same option rom and each one of them tries to register bcv for
> > all scsi card it found. Won't we have two bcvs registered for each scsi
> > car then?
>
> First optionrom finds all devices for that type of scsi card. Second
> optionrom detects that its drives have already been probed and resizes
> itself to zero.
>
> > > The BCV and BEVs have a "product name string" that could be used to
> > > identify which one to boot. Unfortunately, there isn't a good way for
> > > qemu to find these strings (though maybe it could just hard code them
> > > for roms it ships with). SeaBIOS does show them in the boot menu, so
> > > a user could manually copy them to a command line.
> > >
> > Two disks can have same product name no? And qemu can't even know
> > product names for pass through devices. Also I wouldn't worry about
> > optioroms qemu ships. We can fix those.
>
> The product name is supposed to be unique. From the spec:
>
> The data within each header must be valid. Especially the `BCV' and
> `Pointer to Product Name String' fields. The BCV should point to a
> procedure that installs only that device into INT 13h services. It
> is strongly recommended that the Product Name String for each header
> uniquely identify the device to which that header belongs, so that
> when these strings are displayed to the user in a menu, the user can
> intelligently recognize and choose devices connected to that
> controller without having to open up the computer.
>
The spec is "strongly recommended", not requires, but I guess if product
violates this recommendation it will have the same problem on real HW
too.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-27 17:06 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-27 17:47 ` Kevin O'Connor
-1 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-11-27 17:47 UTC (permalink / raw)
To: Gleb Natapov
Cc: qemu-devel, kvm, blauwirbel, armbru, alex.williamson, mst,
Anthony Liguori
On Sat, Nov 27, 2010 at 07:06:19PM +0200, Gleb Natapov wrote:
> On Sat, Nov 27, 2010 at 11:49:39AM -0500, Kevin O'Connor wrote:
> > On Sat, Nov 27, 2010 at 06:22:16PM +0200, Gleb Natapov wrote:
> > > Yeah. I looked at the Seabios code. The simplest would be to change
> > > device path to point to rom instead of pci device. So if there is device
> > > path /pci@i0cf8/ethernet@3 when rom is copied into the memory the path
> > > is changed to be /rom@addr where addr is memory address where rom was
> > > copied.
> > Seabios would change its local copy of the path?
> Yes.
Thinking about this further - since the optionrom must be 2k aligned
there are only 96 spots a rom can be in. So, it should be simple to
just have optionrom_setup() declare a "u16 romaddr_to_bdf[96]".
> > > > How will seabios even know it's a SCSI card? All seabios sees is a
> > > > PCI device with a valid option rom bar. Further, I don't see how
> > > > seabios will know which BCV is which lun.
> > > >
> > > Seabios knows that this is SCSI card from its device class.
> >
> > This seems fragile - it would require seabios to keep a list of device
> > classes to name mappings, and a user may not be able to boot from a
> > device if seabios isn't programmed for it (eg, a passthrough device).
> >
> Seabios can ignore device name from device path since the same
> information is present in pci config space of the device. So the device path
> can be /pci@i0cf8/scis@4 or /pci@i0cf8/@4 Seabios can detect that device
> is scsi just by looking at config space of pci device in slot 4 function 0.
I don't think seabios should try to parse the path. Instead, I think
seabios should build a name for each device it finds using the same
algorithm that qemu uses and then just do a string compare to see if
there is a match.
Also, if qemu wants seabios to boot from a rom, I think it should tell
seabios that - something like "/pci@i0cf8/rom@4.0/bcv@0" to mean make
the drive declared by the rom on pci device 4 function 0 in the first
found bcv the c: drive.
> For, scsi I think, proper solution would be to have Seabios support for
> scsi controller emulated by qemu. This will make all devices bootable from
> BCV known to Seabios and will not require option rom. The only problem
> then will be with pass through devices, but since now only the whole
> scsi controller can be passed through not individual targets qemu can
> point device path only to the controller and not individual targets too.
I'm okay with adding scsi support to seabios. However, the problem
doesn't go away as network booting still requires a rom.
> > > Unfortunately it looks like bcv does not provide enough info to know what
> > > target it corresponds too. I can't think of enything smart we can do
> > > here, so lets just treat all bcvs as same priority.
> >
> > There's the product name and there's the order it was registered in
> > (ie, the third bcv on the rom).
> Doesn't help much if we can't correlate bcv to device path.
I'm confused by this. SeaBIOS can't boot the device in this situation
- it can only run a rom. I think qemu should try to send info on
which rom to run, not which device to boot. Each rom is uniquely
identifiable by the pci device it came from (or fw_cfg slot), and each
BCV can be identified by either its instance or its product name.
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-27 17:47 ` Kevin O'Connor
0 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-11-27 17:47 UTC (permalink / raw)
To: Gleb Natapov
Cc: Anthony Liguori, kvm, mst, qemu-devel, armbru, blauwirbel,
alex.williamson
On Sat, Nov 27, 2010 at 07:06:19PM +0200, Gleb Natapov wrote:
> On Sat, Nov 27, 2010 at 11:49:39AM -0500, Kevin O'Connor wrote:
> > On Sat, Nov 27, 2010 at 06:22:16PM +0200, Gleb Natapov wrote:
> > > Yeah. I looked at the Seabios code. The simplest would be to change
> > > device path to point to rom instead of pci device. So if there is device
> > > path /pci@i0cf8/ethernet@3 when rom is copied into the memory the path
> > > is changed to be /rom@addr where addr is memory address where rom was
> > > copied.
> > Seabios would change its local copy of the path?
> Yes.
Thinking about this further - since the optionrom must be 2k aligned
there are only 96 spots a rom can be in. So, it should be simple to
just have optionrom_setup() declare a "u16 romaddr_to_bdf[96]".
> > > > How will seabios even know it's a SCSI card? All seabios sees is a
> > > > PCI device with a valid option rom bar. Further, I don't see how
> > > > seabios will know which BCV is which lun.
> > > >
> > > Seabios knows that this is SCSI card from its device class.
> >
> > This seems fragile - it would require seabios to keep a list of device
> > classes to name mappings, and a user may not be able to boot from a
> > device if seabios isn't programmed for it (eg, a passthrough device).
> >
> Seabios can ignore device name from device path since the same
> information is present in pci config space of the device. So the device path
> can be /pci@i0cf8/scis@4 or /pci@i0cf8/@4 Seabios can detect that device
> is scsi just by looking at config space of pci device in slot 4 function 0.
I don't think seabios should try to parse the path. Instead, I think
seabios should build a name for each device it finds using the same
algorithm that qemu uses and then just do a string compare to see if
there is a match.
Also, if qemu wants seabios to boot from a rom, I think it should tell
seabios that - something like "/pci@i0cf8/rom@4.0/bcv@0" to mean make
the drive declared by the rom on pci device 4 function 0 in the first
found bcv the c: drive.
> For, scsi I think, proper solution would be to have Seabios support for
> scsi controller emulated by qemu. This will make all devices bootable from
> BCV known to Seabios and will not require option rom. The only problem
> then will be with pass through devices, but since now only the whole
> scsi controller can be passed through not individual targets qemu can
> point device path only to the controller and not individual targets too.
I'm okay with adding scsi support to seabios. However, the problem
doesn't go away as network booting still requires a rom.
> > > Unfortunately it looks like bcv does not provide enough info to know what
> > > target it corresponds too. I can't think of enything smart we can do
> > > here, so lets just treat all bcvs as same priority.
> >
> > There's the product name and there's the order it was registered in
> > (ie, the third bcv on the rom).
> Doesn't help much if we can't correlate bcv to device path.
I'm confused by this. SeaBIOS can't boot the device in this situation
- it can only run a rom. I think qemu should try to send info on
which rom to run, not which device to boot. Each rom is uniquely
identifiable by the pci device it came from (or fw_cfg slot), and each
BCV can be identified by either its instance or its product name.
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-27 17:47 ` [Qemu-devel] " Kevin O'Connor
@ 2010-11-27 18:15 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-27 18:15 UTC (permalink / raw)
To: Kevin O'Connor
Cc: qemu-devel, kvm, blauwirbel, armbru, alex.williamson, mst,
Anthony Liguori
On Sat, Nov 27, 2010 at 12:47:26PM -0500, Kevin O'Connor wrote:
> On Sat, Nov 27, 2010 at 07:06:19PM +0200, Gleb Natapov wrote:
> > On Sat, Nov 27, 2010 at 11:49:39AM -0500, Kevin O'Connor wrote:
> > > On Sat, Nov 27, 2010 at 06:22:16PM +0200, Gleb Natapov wrote:
> > > > Yeah. I looked at the Seabios code. The simplest would be to change
> > > > device path to point to rom instead of pci device. So if there is device
> > > > path /pci@i0cf8/ethernet@3 when rom is copied into the memory the path
> > > > is changed to be /rom@addr where addr is memory address where rom was
> > > > copied.
> > > Seabios would change its local copy of the path?
> > Yes.
>
> Thinking about this further - since the optionrom must be 2k aligned
> there are only 96 spots a rom can be in. So, it should be simple to
> just have optionrom_setup() declare a "u16 romaddr_to_bdf[96]".
>
That will work too.
> > > > > How will seabios even know it's a SCSI card? All seabios sees is a
> > > > > PCI device with a valid option rom bar. Further, I don't see how
> > > > > seabios will know which BCV is which lun.
> > > > >
> > > > Seabios knows that this is SCSI card from its device class.
> > >
> > > This seems fragile - it would require seabios to keep a list of device
> > > classes to name mappings, and a user may not be able to boot from a
> > > device if seabios isn't programmed for it (eg, a passthrough device).
> > >
> > Seabios can ignore device name from device path since the same
> > information is present in pci config space of the device. So the device path
> > can be /pci@i0cf8/scis@4 or /pci@i0cf8/@4 Seabios can detect that device
> > is scsi just by looking at config space of pci device in slot 4 function 0.
>
> I don't think seabios should try to parse the path. Instead, I think
> seabios should build a name for each device it finds using the same
> algorithm that qemu uses and then just do a string compare to see if
> there is a match.
>
> Also, if qemu wants seabios to boot from a rom, I think it should tell
> seabios that - something like "/pci@i0cf8/rom@4.0/bcv@0" to mean make
> the drive declared by the rom on pci device 4 function 0 in the first
> found bcv the c: drive.
>
Qemu does not know that Seabios needs optionrom to boot from a device.
It knows even less about bcvs in option rom. Qemu knows about device
itself, not how firmware boots from it.
> > For, scsi I think, proper solution would be to have Seabios support for
> > scsi controller emulated by qemu. This will make all devices bootable from
> > BCV known to Seabios and will not require option rom. The only problem
> > then will be with pass through devices, but since now only the whole
> > scsi controller can be passed through not individual targets qemu can
> > point device path only to the controller and not individual targets too.
>
> I'm okay with adding scsi support to seabios. However, the problem
> doesn't go away as network booting still requires a rom.
But bev can be only one, so we do not have this problem with bev. Boot
priority of a bev is boot priority of pci device it was loaded from.
>
> > > > Unfortunately it looks like bcv does not provide enough info to know what
> > > > target it corresponds too. I can't think of enything smart we can do
> > > > here, so lets just treat all bcvs as same priority.
> > >
> > > There's the product name and there's the order it was registered in
> > > (ie, the third bcv on the rom).
> > Doesn't help much if we can't correlate bcv to device path.
>
> I'm confused by this. SeaBIOS can't boot the device in this situation
> - it can only run a rom. I think qemu should try to send info on
> which rom to run, not which device to boot. Each rom is uniquely
> identifiable by the pci device it came from (or fw_cfg slot), and each
> BCV can be identified by either its instance or its product name.
>
For Qemu those optionroms are just binary blobs. It doesn't know why they
are needed at all (there is no difference for qemu between vga rom and
e1000 rom).
BTW are you actually aware of any option rom with multiple BCVs and, if
yes, how those BCVs differ?
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-27 18:15 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-27 18:15 UTC (permalink / raw)
To: Kevin O'Connor
Cc: Anthony Liguori, kvm, mst, qemu-devel, armbru, blauwirbel,
alex.williamson
On Sat, Nov 27, 2010 at 12:47:26PM -0500, Kevin O'Connor wrote:
> On Sat, Nov 27, 2010 at 07:06:19PM +0200, Gleb Natapov wrote:
> > On Sat, Nov 27, 2010 at 11:49:39AM -0500, Kevin O'Connor wrote:
> > > On Sat, Nov 27, 2010 at 06:22:16PM +0200, Gleb Natapov wrote:
> > > > Yeah. I looked at the Seabios code. The simplest would be to change
> > > > device path to point to rom instead of pci device. So if there is device
> > > > path /pci@i0cf8/ethernet@3 when rom is copied into the memory the path
> > > > is changed to be /rom@addr where addr is memory address where rom was
> > > > copied.
> > > Seabios would change its local copy of the path?
> > Yes.
>
> Thinking about this further - since the optionrom must be 2k aligned
> there are only 96 spots a rom can be in. So, it should be simple to
> just have optionrom_setup() declare a "u16 romaddr_to_bdf[96]".
>
That will work too.
> > > > > How will seabios even know it's a SCSI card? All seabios sees is a
> > > > > PCI device with a valid option rom bar. Further, I don't see how
> > > > > seabios will know which BCV is which lun.
> > > > >
> > > > Seabios knows that this is SCSI card from its device class.
> > >
> > > This seems fragile - it would require seabios to keep a list of device
> > > classes to name mappings, and a user may not be able to boot from a
> > > device if seabios isn't programmed for it (eg, a passthrough device).
> > >
> > Seabios can ignore device name from device path since the same
> > information is present in pci config space of the device. So the device path
> > can be /pci@i0cf8/scis@4 or /pci@i0cf8/@4 Seabios can detect that device
> > is scsi just by looking at config space of pci device in slot 4 function 0.
>
> I don't think seabios should try to parse the path. Instead, I think
> seabios should build a name for each device it finds using the same
> algorithm that qemu uses and then just do a string compare to see if
> there is a match.
>
> Also, if qemu wants seabios to boot from a rom, I think it should tell
> seabios that - something like "/pci@i0cf8/rom@4.0/bcv@0" to mean make
> the drive declared by the rom on pci device 4 function 0 in the first
> found bcv the c: drive.
>
Qemu does not know that Seabios needs optionrom to boot from a device.
It knows even less about bcvs in option rom. Qemu knows about device
itself, not how firmware boots from it.
> > For, scsi I think, proper solution would be to have Seabios support for
> > scsi controller emulated by qemu. This will make all devices bootable from
> > BCV known to Seabios and will not require option rom. The only problem
> > then will be with pass through devices, but since now only the whole
> > scsi controller can be passed through not individual targets qemu can
> > point device path only to the controller and not individual targets too.
>
> I'm okay with adding scsi support to seabios. However, the problem
> doesn't go away as network booting still requires a rom.
But bev can be only one, so we do not have this problem with bev. Boot
priority of a bev is boot priority of pci device it was loaded from.
>
> > > > Unfortunately it looks like bcv does not provide enough info to know what
> > > > target it corresponds too. I can't think of enything smart we can do
> > > > here, so lets just treat all bcvs as same priority.
> > >
> > > There's the product name and there's the order it was registered in
> > > (ie, the third bcv on the rom).
> > Doesn't help much if we can't correlate bcv to device path.
>
> I'm confused by this. SeaBIOS can't boot the device in this situation
> - it can only run a rom. I think qemu should try to send info on
> which rom to run, not which device to boot. Each rom is uniquely
> identifiable by the pci device it came from (or fw_cfg slot), and each
> BCV can be identified by either its instance or its product name.
>
For Qemu those optionroms are just binary blobs. It doesn't know why they
are needed at all (there is no difference for qemu between vga rom and
e1000 rom).
BTW are you actually aware of any option rom with multiple BCVs and, if
yes, how those BCVs differ?
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-27 18:15 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-27 18:40 ` Kevin O'Connor
-1 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-11-27 18:40 UTC (permalink / raw)
To: Gleb Natapov
Cc: qemu-devel, kvm, blauwirbel, armbru, alex.williamson, mst,
Anthony Liguori
On Sat, Nov 27, 2010 at 08:15:42PM +0200, Gleb Natapov wrote:
> On Sat, Nov 27, 2010 at 12:47:26PM -0500, Kevin O'Connor wrote:
> > I don't think seabios should try to parse the path. Instead, I think
> > seabios should build a name for each device it finds using the same
> > algorithm that qemu uses and then just do a string compare to see if
> > there is a match.
> >
> > Also, if qemu wants seabios to boot from a rom, I think it should tell
> > seabios that - something like "/pci@i0cf8/rom@4.0/bcv@0" to mean make
> > the drive declared by the rom on pci device 4 function 0 in the first
> > found bcv the c: drive.
> >
> Qemu does not know that Seabios needs optionrom to boot from a device.
> It knows even less about bcvs in option rom. Qemu knows about device
> itself, not how firmware boots from it.
If the user wants to boot from a device and that device has an
optionrom, then it's a safe bet that the optionrom is needed to boot
from it.
In any case, I'd rather have qemu know which devices seabios can boot
then have seabios try to figure out what rom to run from a device
path.
> > > > There's the product name and there's the order it was registered in
> > > > (ie, the third bcv on the rom).
> > > Doesn't help much if we can't correlate bcv to device path.
> >
> > I'm confused by this. SeaBIOS can't boot the device in this situation
> > - it can only run a rom. I think qemu should try to send info on
> > which rom to run, not which device to boot. Each rom is uniquely
> > identifiable by the pci device it came from (or fw_cfg slot), and each
> > BCV can be identified by either its instance or its product name.
> >
> For Qemu those optionroms are just binary blobs. It doesn't know why they
> are needed at all (there is no difference for qemu between vga rom and
> e1000 rom).
>
> BTW are you actually aware of any option rom with multiple BCVs and, if
> yes, how those BCVs differ?
Multiple BCVs - yes. A SCSI card will define a BCV for each attached
drive. I don't have a scsi card myself, but the support was added by
a user who ran into the problem first hand.
I don't know if there are SCSI card roms that will register all the
drives on multiple cards in the first rom. I wouldn't be surprised if
there are because of the scarcity of space in the 0xc0000-0xf0000
space. (Having secondary optionroms resize themselves to zero would
be a big savings.)
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-27 18:40 ` Kevin O'Connor
0 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-11-27 18:40 UTC (permalink / raw)
To: Gleb Natapov
Cc: Anthony Liguori, kvm, mst, qemu-devel, armbru, blauwirbel,
alex.williamson
On Sat, Nov 27, 2010 at 08:15:42PM +0200, Gleb Natapov wrote:
> On Sat, Nov 27, 2010 at 12:47:26PM -0500, Kevin O'Connor wrote:
> > I don't think seabios should try to parse the path. Instead, I think
> > seabios should build a name for each device it finds using the same
> > algorithm that qemu uses and then just do a string compare to see if
> > there is a match.
> >
> > Also, if qemu wants seabios to boot from a rom, I think it should tell
> > seabios that - something like "/pci@i0cf8/rom@4.0/bcv@0" to mean make
> > the drive declared by the rom on pci device 4 function 0 in the first
> > found bcv the c: drive.
> >
> Qemu does not know that Seabios needs optionrom to boot from a device.
> It knows even less about bcvs in option rom. Qemu knows about device
> itself, not how firmware boots from it.
If the user wants to boot from a device and that device has an
optionrom, then it's a safe bet that the optionrom is needed to boot
from it.
In any case, I'd rather have qemu know which devices seabios can boot
then have seabios try to figure out what rom to run from a device
path.
> > > > There's the product name and there's the order it was registered in
> > > > (ie, the third bcv on the rom).
> > > Doesn't help much if we can't correlate bcv to device path.
> >
> > I'm confused by this. SeaBIOS can't boot the device in this situation
> > - it can only run a rom. I think qemu should try to send info on
> > which rom to run, not which device to boot. Each rom is uniquely
> > identifiable by the pci device it came from (or fw_cfg slot), and each
> > BCV can be identified by either its instance or its product name.
> >
> For Qemu those optionroms are just binary blobs. It doesn't know why they
> are needed at all (there is no difference for qemu between vga rom and
> e1000 rom).
>
> BTW are you actually aware of any option rom with multiple BCVs and, if
> yes, how those BCVs differ?
Multiple BCVs - yes. A SCSI card will define a BCV for each attached
drive. I don't have a scsi card myself, but the support was added by
a user who ran into the problem first hand.
I don't know if there are SCSI card roms that will register all the
drives on multiple cards in the first rom. I wouldn't be surprised if
there are because of the scarcity of space in the 0xc0000-0xf0000
space. (Having secondary optionroms resize themselves to zero would
be a big savings.)
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-27 18:40 ` [Qemu-devel] " Kevin O'Connor
@ 2010-11-27 19:04 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-27 19:04 UTC (permalink / raw)
To: Kevin O'Connor
Cc: qemu-devel, kvm, blauwirbel, armbru, alex.williamson, mst,
Anthony Liguori
On Sat, Nov 27, 2010 at 01:40:12PM -0500, Kevin O'Connor wrote:
> On Sat, Nov 27, 2010 at 08:15:42PM +0200, Gleb Natapov wrote:
> > On Sat, Nov 27, 2010 at 12:47:26PM -0500, Kevin O'Connor wrote:
> > > I don't think seabios should try to parse the path. Instead, I think
> > > seabios should build a name for each device it finds using the same
> > > algorithm that qemu uses and then just do a string compare to see if
> > > there is a match.
> > >
> > > Also, if qemu wants seabios to boot from a rom, I think it should tell
> > > seabios that - something like "/pci@i0cf8/rom@4.0/bcv@0" to mean make
> > > the drive declared by the rom on pci device 4 function 0 in the first
> > > found bcv the c: drive.
> > >
> > Qemu does not know that Seabios needs optionrom to boot from a device.
> > It knows even less about bcvs in option rom. Qemu knows about device
> > itself, not how firmware boots from it.
>
> If the user wants to boot from a device and that device has an
> optionrom, then it's a safe bet that the optionrom is needed to boot
> from it.
>
Suppose we add SCSI support to Seabios and suppose SCSI card Seabios can
natively boot from has optionrom. What Seabios will do in such situation
and how qemu can know it? Besides qemu support tries to be firmware
agnostic.
> In any case, I'd rather have qemu know which devices seabios can boot
> then have seabios try to figure out what rom to run from a device
> path.
You run all of them just like you do now. Information you get from qemu is
only used for sorting BCV/BEV entries. BCV/BEV that does not have
corespondent boot path in boot order list is put at the end.
>
> > > > > There's the product name and there's the order it was registered in
> > > > > (ie, the third bcv on the rom).
> > > > Doesn't help much if we can't correlate bcv to device path.
> > >
> > > I'm confused by this. SeaBIOS can't boot the device in this situation
> > > - it can only run a rom. I think qemu should try to send info on
> > > which rom to run, not which device to boot. Each rom is uniquely
> > > identifiable by the pci device it came from (or fw_cfg slot), and each
> > > BCV can be identified by either its instance or its product name.
> > >
> > For Qemu those optionroms are just binary blobs. It doesn't know why they
> > are needed at all (there is no difference for qemu between vga rom and
> > e1000 rom).
> >
> > BTW are you actually aware of any option rom with multiple BCVs and, if
> > yes, how those BCVs differ?
>
> Multiple BCVs - yes. A SCSI card will define a BCV for each attached
> drive. I don't have a scsi card myself, but the support was added by
> a user who ran into the problem first hand.
Optionrom is static. How number of BCVs can depend on number of attached
drives?
>
> I don't know if there are SCSI card roms that will register all the
> drives on multiple cards in the first rom. I wouldn't be surprised if
> there are because of the scarcity of space in the 0xc0000-0xf0000
> space. (Having secondary optionroms resize themselves to zero would
> be a big savings.)
>
> -Kevin
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-27 19:04 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-27 19:04 UTC (permalink / raw)
To: Kevin O'Connor
Cc: Anthony Liguori, kvm, mst, qemu-devel, armbru, blauwirbel,
alex.williamson
On Sat, Nov 27, 2010 at 01:40:12PM -0500, Kevin O'Connor wrote:
> On Sat, Nov 27, 2010 at 08:15:42PM +0200, Gleb Natapov wrote:
> > On Sat, Nov 27, 2010 at 12:47:26PM -0500, Kevin O'Connor wrote:
> > > I don't think seabios should try to parse the path. Instead, I think
> > > seabios should build a name for each device it finds using the same
> > > algorithm that qemu uses and then just do a string compare to see if
> > > there is a match.
> > >
> > > Also, if qemu wants seabios to boot from a rom, I think it should tell
> > > seabios that - something like "/pci@i0cf8/rom@4.0/bcv@0" to mean make
> > > the drive declared by the rom on pci device 4 function 0 in the first
> > > found bcv the c: drive.
> > >
> > Qemu does not know that Seabios needs optionrom to boot from a device.
> > It knows even less about bcvs in option rom. Qemu knows about device
> > itself, not how firmware boots from it.
>
> If the user wants to boot from a device and that device has an
> optionrom, then it's a safe bet that the optionrom is needed to boot
> from it.
>
Suppose we add SCSI support to Seabios and suppose SCSI card Seabios can
natively boot from has optionrom. What Seabios will do in such situation
and how qemu can know it? Besides qemu support tries to be firmware
agnostic.
> In any case, I'd rather have qemu know which devices seabios can boot
> then have seabios try to figure out what rom to run from a device
> path.
You run all of them just like you do now. Information you get from qemu is
only used for sorting BCV/BEV entries. BCV/BEV that does not have
corespondent boot path in boot order list is put at the end.
>
> > > > > There's the product name and there's the order it was registered in
> > > > > (ie, the third bcv on the rom).
> > > > Doesn't help much if we can't correlate bcv to device path.
> > >
> > > I'm confused by this. SeaBIOS can't boot the device in this situation
> > > - it can only run a rom. I think qemu should try to send info on
> > > which rom to run, not which device to boot. Each rom is uniquely
> > > identifiable by the pci device it came from (or fw_cfg slot), and each
> > > BCV can be identified by either its instance or its product name.
> > >
> > For Qemu those optionroms are just binary blobs. It doesn't know why they
> > are needed at all (there is no difference for qemu between vga rom and
> > e1000 rom).
> >
> > BTW are you actually aware of any option rom with multiple BCVs and, if
> > yes, how those BCVs differ?
>
> Multiple BCVs - yes. A SCSI card will define a BCV for each attached
> drive. I don't have a scsi card myself, but the support was added by
> a user who ran into the problem first hand.
Optionrom is static. How number of BCVs can depend on number of attached
drives?
>
> I don't know if there are SCSI card roms that will register all the
> drives on multiple cards in the first rom. I wouldn't be surprised if
> there are because of the scarcity of space in the 0xc0000-0xf0000
> space. (Having secondary optionroms resize themselves to zero would
> be a big savings.)
>
> -Kevin
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-27 19:04 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-27 21:07 ` Kevin O'Connor
-1 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-11-27 21:07 UTC (permalink / raw)
To: Gleb Natapov; +Cc: qemu-devel, kvm, seabios
Trimming CC list, adding seabios list.
On Sat, Nov 27, 2010 at 09:04:24PM +0200, Gleb Natapov wrote:
> On Sat, Nov 27, 2010 at 01:40:12PM -0500, Kevin O'Connor wrote:
> > On Sat, Nov 27, 2010 at 08:15:42PM +0200, Gleb Natapov wrote:
> > > Qemu does not know that Seabios needs optionrom to boot from a device.
> > > It knows even less about bcvs in option rom. Qemu knows about device
> > > itself, not how firmware boots from it.
> >
> > If the user wants to boot from a device and that device has an
> > optionrom, then it's a safe bet that the optionrom is needed to boot
> > from it.
> >
> Suppose we add SCSI support to Seabios and suppose SCSI card Seabios can
> natively boot from has optionrom. What Seabios will do in such situation
> and how qemu can know it? Besides qemu support tries to be firmware
> agnostic.
In such a situation, under my proposal, users wouldn't be able to
specify a default boot from their scsi drive until after qemu was also
upgraded to know seabios could boot native scsi. (Or, they'd only be
able to do it by adding in a command-line option.)
> > In any case, I'd rather have qemu know which devices seabios can boot
> > then have seabios try to figure out what rom to run from a device
> > path.
> You run all of them just like you do now. Information you get from qemu is
> only used for sorting BCV/BEV entries. BCV/BEV that does not have
> corespondent boot path in boot order list is put at the end.
If qemu sends in "/pci@i0cf8/scsi@3/disk@0,0" or
"/pci@i0cf8/ethernet@4/ethernet-phy@0" it will expect seabios to boot
from the appropriate device. In both cases, seabios would need to run
a rom in order to fulfill that request. Trying to figure out which
rom is quite painful. That's why I'd prefer to see qemu instead pass
in something like "/pci@i0cf8/rom@3/bcv@0" or "/pci@i0cf8/rom@4/bev".
That is, if the machine needs to boot via a rom I'd prefer qemu state
that explicitly.
BTW, in the situation where seabios has native device support (eg,
ATA), I don't have any concerns. (The names are a bit verbose, but
that's not really an issue.)
> > > BTW are you actually aware of any option rom with multiple BCVs and, if
> > > yes, how those BCVs differ?
> >
> > Multiple BCVs - yes. A SCSI card will define a BCV for each attached
> > drive. I don't have a scsi card myself, but the support was added by
> > a user who ran into the problem first hand.
> Optionrom is static. How number of BCVs can depend on number of attached
> drives?
Not sure what you mean by "Optionrom is static". SeaBIOS unlocks the
memory, and the optionrom can and will modify itself with additional
PNP headers so that it can list multiple BCVs - one for each drive.
In particular, gPXE uses self modification to relocate parts of itself
into high ram.
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-27 21:07 ` Kevin O'Connor
0 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-11-27 21:07 UTC (permalink / raw)
To: Gleb Natapov; +Cc: seabios, qemu-devel, kvm
Trimming CC list, adding seabios list.
On Sat, Nov 27, 2010 at 09:04:24PM +0200, Gleb Natapov wrote:
> On Sat, Nov 27, 2010 at 01:40:12PM -0500, Kevin O'Connor wrote:
> > On Sat, Nov 27, 2010 at 08:15:42PM +0200, Gleb Natapov wrote:
> > > Qemu does not know that Seabios needs optionrom to boot from a device.
> > > It knows even less about bcvs in option rom. Qemu knows about device
> > > itself, not how firmware boots from it.
> >
> > If the user wants to boot from a device and that device has an
> > optionrom, then it's a safe bet that the optionrom is needed to boot
> > from it.
> >
> Suppose we add SCSI support to Seabios and suppose SCSI card Seabios can
> natively boot from has optionrom. What Seabios will do in such situation
> and how qemu can know it? Besides qemu support tries to be firmware
> agnostic.
In such a situation, under my proposal, users wouldn't be able to
specify a default boot from their scsi drive until after qemu was also
upgraded to know seabios could boot native scsi. (Or, they'd only be
able to do it by adding in a command-line option.)
> > In any case, I'd rather have qemu know which devices seabios can boot
> > then have seabios try to figure out what rom to run from a device
> > path.
> You run all of them just like you do now. Information you get from qemu is
> only used for sorting BCV/BEV entries. BCV/BEV that does not have
> corespondent boot path in boot order list is put at the end.
If qemu sends in "/pci@i0cf8/scsi@3/disk@0,0" or
"/pci@i0cf8/ethernet@4/ethernet-phy@0" it will expect seabios to boot
from the appropriate device. In both cases, seabios would need to run
a rom in order to fulfill that request. Trying to figure out which
rom is quite painful. That's why I'd prefer to see qemu instead pass
in something like "/pci@i0cf8/rom@3/bcv@0" or "/pci@i0cf8/rom@4/bev".
That is, if the machine needs to boot via a rom I'd prefer qemu state
that explicitly.
BTW, in the situation where seabios has native device support (eg,
ATA), I don't have any concerns. (The names are a bit verbose, but
that's not really an issue.)
> > > BTW are you actually aware of any option rom with multiple BCVs and, if
> > > yes, how those BCVs differ?
> >
> > Multiple BCVs - yes. A SCSI card will define a BCV for each attached
> > drive. I don't have a scsi card myself, but the support was added by
> > a user who ran into the problem first hand.
> Optionrom is static. How number of BCVs can depend on number of attached
> drives?
Not sure what you mean by "Optionrom is static". SeaBIOS unlocks the
memory, and the optionrom can and will modify itself with additional
PNP headers so that it can list multiple BCVs - one for each drive.
In particular, gPXE uses self modification to relocate parts of itself
into high ram.
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-27 21:07 ` [Qemu-devel] " Kevin O'Connor
@ 2010-11-28 7:45 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 7:45 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: qemu-devel, kvm, seabios
On Sat, Nov 27, 2010 at 04:07:45PM -0500, Kevin O'Connor wrote:
> Trimming CC list, adding seabios list.
>
> On Sat, Nov 27, 2010 at 09:04:24PM +0200, Gleb Natapov wrote:
> > On Sat, Nov 27, 2010 at 01:40:12PM -0500, Kevin O'Connor wrote:
> > > On Sat, Nov 27, 2010 at 08:15:42PM +0200, Gleb Natapov wrote:
> > > > Qemu does not know that Seabios needs optionrom to boot from a device.
> > > > It knows even less about bcvs in option rom. Qemu knows about device
> > > > itself, not how firmware boots from it.
> > >
> > > If the user wants to boot from a device and that device has an
> > > optionrom, then it's a safe bet that the optionrom is needed to boot
> > > from it.
> > >
> > Suppose we add SCSI support to Seabios and suppose SCSI card Seabios can
> > natively boot from has optionrom. What Seabios will do in such situation
> > and how qemu can know it? Besides qemu support tries to be firmware
> > agnostic.
>
> In such a situation, under my proposal, users wouldn't be able to
> specify a default boot from their scsi drive until after qemu was also
> upgraded to know seabios could boot native scsi. (Or, they'd only be
> able to do it by adding in a command-line option.)
>
If scsi card has optionrom with only one bcv then Seabios can determine
its boot order from device path, so why not provide user with this
option today? Besides qemu may be used to emulates sparc with openbios and
this combination may be able to boot from scsi device. Qemu is not just
x86 emulator running Seabios. If there is problem with scsi boot we let
management know, so it will not create unbootable configuration. Today it
is impossible to boot guest from scsi in qemu btw.
> > > In any case, I'd rather have qemu know which devices seabios can boot
> > > then have seabios try to figure out what rom to run from a device
> > > path.
> > You run all of them just like you do now. Information you get from qemu is
> > only used for sorting BCV/BEV entries. BCV/BEV that does not have
> > corespondent boot path in boot order list is put at the end.
>
> If qemu sends in "/pci@i0cf8/scsi@3/disk@0,0" or
> "/pci@i0cf8/ethernet@4/ethernet-phy@0" it will expect seabios to boot
> from the appropriate device. In both cases, seabios would need to run
> a rom in order to fulfill that request. Trying to figure out which
> rom is quite painful. That's why I'd prefer to see qemu instead pass
> in something like "/pci@i0cf8/rom@3/bcv@0" or "/pci@i0cf8/rom@4/bev".
> That is, if the machine needs to boot via a rom I'd prefer qemu state
> that explicitly.
It is painful in Seabios it is impossible in qemu at all. There is no
way for qemu to know about BCVs or BEVs in optionroms especially
considering that they are created at runtime like you say bellow.
The best qemu can do is to ask user what device user wants to boot from
and pass this information to Seabios in form of device path. Seabios (or
other firmware) has to figure out how to boot from the device or ignore
request if it can't. We can't provide the same functionality as Seabios'
f12 menu on qemu command line since content of the menu depend on run time.
>
> BTW, in the situation where seabios has native device support (eg,
> ATA), I don't have any concerns. (The names are a bit verbose, but
> that's not really an issue.)
This + network booting are the may use case really. And I do not see
what problem we have with BEV devices. "/pci@i0cf8/rom@4/bev" is not
much different from "/pci@i0cf8/ethernet@4/ethernet-phy@0" since there
can be only one bev per pci device. It is easy for Seabios to see that
to boot from pci device in slot 4 func 0 it has to execute BEV.
>
> > > > BTW are you actually aware of any option rom with multiple BCVs and, if
> > > > yes, how those BCVs differ?
> > >
> > > Multiple BCVs - yes. A SCSI card will define a BCV for each attached
> > > drive. I don't have a scsi card myself, but the support was added by
> > > a user who ran into the problem first hand.
> > Optionrom is static. How number of BCVs can depend on number of attached
> > drives?
>
> Not sure what you mean by "Optionrom is static". SeaBIOS unlocks the
> memory, and the optionrom can and will modify itself with additional
> PNP headers so that it can list multiple BCVs - one for each drive.
> In particular, gPXE uses self modification to relocate parts of itself
> into high ram.
>
"Optionrom is static" was my misunderstanding. As you say here optionrom
can create BEVs/BCVs at runtime which make it impossible for qemu to
know about them even if qemu examine optionroms of devices.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-28 7:45 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 7:45 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: seabios, qemu-devel, kvm
On Sat, Nov 27, 2010 at 04:07:45PM -0500, Kevin O'Connor wrote:
> Trimming CC list, adding seabios list.
>
> On Sat, Nov 27, 2010 at 09:04:24PM +0200, Gleb Natapov wrote:
> > On Sat, Nov 27, 2010 at 01:40:12PM -0500, Kevin O'Connor wrote:
> > > On Sat, Nov 27, 2010 at 08:15:42PM +0200, Gleb Natapov wrote:
> > > > Qemu does not know that Seabios needs optionrom to boot from a device.
> > > > It knows even less about bcvs in option rom. Qemu knows about device
> > > > itself, not how firmware boots from it.
> > >
> > > If the user wants to boot from a device and that device has an
> > > optionrom, then it's a safe bet that the optionrom is needed to boot
> > > from it.
> > >
> > Suppose we add SCSI support to Seabios and suppose SCSI card Seabios can
> > natively boot from has optionrom. What Seabios will do in such situation
> > and how qemu can know it? Besides qemu support tries to be firmware
> > agnostic.
>
> In such a situation, under my proposal, users wouldn't be able to
> specify a default boot from their scsi drive until after qemu was also
> upgraded to know seabios could boot native scsi. (Or, they'd only be
> able to do it by adding in a command-line option.)
>
If scsi card has optionrom with only one bcv then Seabios can determine
its boot order from device path, so why not provide user with this
option today? Besides qemu may be used to emulates sparc with openbios and
this combination may be able to boot from scsi device. Qemu is not just
x86 emulator running Seabios. If there is problem with scsi boot we let
management know, so it will not create unbootable configuration. Today it
is impossible to boot guest from scsi in qemu btw.
> > > In any case, I'd rather have qemu know which devices seabios can boot
> > > then have seabios try to figure out what rom to run from a device
> > > path.
> > You run all of them just like you do now. Information you get from qemu is
> > only used for sorting BCV/BEV entries. BCV/BEV that does not have
> > corespondent boot path in boot order list is put at the end.
>
> If qemu sends in "/pci@i0cf8/scsi@3/disk@0,0" or
> "/pci@i0cf8/ethernet@4/ethernet-phy@0" it will expect seabios to boot
> from the appropriate device. In both cases, seabios would need to run
> a rom in order to fulfill that request. Trying to figure out which
> rom is quite painful. That's why I'd prefer to see qemu instead pass
> in something like "/pci@i0cf8/rom@3/bcv@0" or "/pci@i0cf8/rom@4/bev".
> That is, if the machine needs to boot via a rom I'd prefer qemu state
> that explicitly.
It is painful in Seabios it is impossible in qemu at all. There is no
way for qemu to know about BCVs or BEVs in optionroms especially
considering that they are created at runtime like you say bellow.
The best qemu can do is to ask user what device user wants to boot from
and pass this information to Seabios in form of device path. Seabios (or
other firmware) has to figure out how to boot from the device or ignore
request if it can't. We can't provide the same functionality as Seabios'
f12 menu on qemu command line since content of the menu depend on run time.
>
> BTW, in the situation where seabios has native device support (eg,
> ATA), I don't have any concerns. (The names are a bit verbose, but
> that's not really an issue.)
This + network booting are the may use case really. And I do not see
what problem we have with BEV devices. "/pci@i0cf8/rom@4/bev" is not
much different from "/pci@i0cf8/ethernet@4/ethernet-phy@0" since there
can be only one bev per pci device. It is easy for Seabios to see that
to boot from pci device in slot 4 func 0 it has to execute BEV.
>
> > > > BTW are you actually aware of any option rom with multiple BCVs and, if
> > > > yes, how those BCVs differ?
> > >
> > > Multiple BCVs - yes. A SCSI card will define a BCV for each attached
> > > drive. I don't have a scsi card myself, but the support was added by
> > > a user who ran into the problem first hand.
> > Optionrom is static. How number of BCVs can depend on number of attached
> > drives?
>
> Not sure what you mean by "Optionrom is static". SeaBIOS unlocks the
> memory, and the optionrom can and will modify itself with additional
> PNP headers so that it can list multiple BCVs - one for each drive.
> In particular, gPXE uses self modification to relocate parts of itself
> into high ram.
>
"Optionrom is static" was my misunderstanding. As you say here optionrom
can create BEVs/BCVs at runtime which make it impossible for qemu to
know about them even if qemu examine optionroms of devices.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-28 7:45 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-28 17:15 ` Kevin O'Connor
-1 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-11-28 17:15 UTC (permalink / raw)
To: Gleb Natapov; +Cc: qemu-devel, kvm, seabios
On Sun, Nov 28, 2010 at 09:45:34AM +0200, Gleb Natapov wrote:
> On Sat, Nov 27, 2010 at 04:07:45PM -0500, Kevin O'Connor wrote:
> > On Sat, Nov 27, 2010 at 09:04:24PM +0200, Gleb Natapov wrote:
> > > Suppose we add SCSI support to Seabios and suppose SCSI card Seabios can
> > > natively boot from has optionrom. What Seabios will do in such situation
> > > and how qemu can know it? Besides qemu support tries to be firmware
> > > agnostic.
> >
> > In such a situation, under my proposal, users wouldn't be able to
> > specify a default boot from their scsi drive until after qemu was also
> > upgraded to know seabios could boot native scsi. (Or, they'd only be
> > able to do it by adding in a command-line option.)
> >
> If scsi card has optionrom with only one bcv then Seabios can determine
> its boot order from device path, so why not provide user with this
> option today?
It's unclear to me how SeaBIOS is supposed to do that.
>Besides qemu may be used to emulates sparc with openbios and
> this combination may be able to boot from scsi device. Qemu is not just
> x86 emulator running Seabios. If there is problem with scsi boot we let
> management know, so it will not create unbootable configuration. Today it
> is impossible to boot guest from scsi in qemu btw.
Qemu can send in "/pci@i0cf8/scsi@3/disk@0,0" - it's just unclear what
seabios is supposed to do with it. (If "ignore it" is the answer,
that's fine with me.)
> > If qemu sends in "/pci@i0cf8/scsi@3/disk@0,0" or
> > "/pci@i0cf8/ethernet@4/ethernet-phy@0" it will expect seabios to boot
> > from the appropriate device. In both cases, seabios would need to run
> > a rom in order to fulfill that request. Trying to figure out which
> > rom is quite painful. That's why I'd prefer to see qemu instead pass
> > in something like "/pci@i0cf8/rom@3/bcv@0" or "/pci@i0cf8/rom@4/bev".
> > That is, if the machine needs to boot via a rom I'd prefer qemu state
> > that explicitly.
> It is painful in Seabios it is impossible in qemu at all. There is no
> way for qemu to know about BCVs or BEVs in optionroms especially
> considering that they are created at runtime like you say bellow.
It's not impossible - qemu could code up rules for when to request a
rom boot and when to request a native boot. That may seem ugly, but
(as near as I can tell) it's basically what you've asked seabios to
do. If nothing else, qemu has the option to let the user pass in an
explicit request via the command-line.
> > BTW, in the situation where seabios has native device support (eg,
> > ATA), I don't have any concerns. (The names are a bit verbose, but
> > that's not really an issue.)
> This + network booting are the may use case really. And I do not see
> what problem we have with BEV devices. "/pci@i0cf8/rom@4/bev" is not
> much different from "/pci@i0cf8/ethernet@4/ethernet-phy@0" since there
> can be only one bev per pci device. It is easy for Seabios to see that
> to boot from pci device in slot 4 func 0 it has to execute BEV.
I'm still stuck on how seabios is supposed to know it's an ethernet
card. Sure, seabios could hardcode translations from classid to
strings, but that seems fragile. What happens when the user wants to
boot from myranet, or fiberchannel, or whatnot?
Maybe we can compromise here - if the user selects booting from a
device, and qemu sees there is a rom for that device, then qemu can
specify two boot options:
/pci@i0cf8/ethernet@4/ethernet-phy@0
/pci@i0cf8/rom@4
SeaBIOS will ignore the first entry, and act on the second entry. If
at some later point seabios knows how to natively boot from the device
(eg, scsi), then it will use the first entry and ignore the second.
BTW, how are PCI locations specified in these paths? They should have
a (bus, dev, fn) - your examples only seem to show dev. How are the
other parts specified?
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-28 17:15 ` Kevin O'Connor
0 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-11-28 17:15 UTC (permalink / raw)
To: Gleb Natapov; +Cc: seabios, qemu-devel, kvm
On Sun, Nov 28, 2010 at 09:45:34AM +0200, Gleb Natapov wrote:
> On Sat, Nov 27, 2010 at 04:07:45PM -0500, Kevin O'Connor wrote:
> > On Sat, Nov 27, 2010 at 09:04:24PM +0200, Gleb Natapov wrote:
> > > Suppose we add SCSI support to Seabios and suppose SCSI card Seabios can
> > > natively boot from has optionrom. What Seabios will do in such situation
> > > and how qemu can know it? Besides qemu support tries to be firmware
> > > agnostic.
> >
> > In such a situation, under my proposal, users wouldn't be able to
> > specify a default boot from their scsi drive until after qemu was also
> > upgraded to know seabios could boot native scsi. (Or, they'd only be
> > able to do it by adding in a command-line option.)
> >
> If scsi card has optionrom with only one bcv then Seabios can determine
> its boot order from device path, so why not provide user with this
> option today?
It's unclear to me how SeaBIOS is supposed to do that.
>Besides qemu may be used to emulates sparc with openbios and
> this combination may be able to boot from scsi device. Qemu is not just
> x86 emulator running Seabios. If there is problem with scsi boot we let
> management know, so it will not create unbootable configuration. Today it
> is impossible to boot guest from scsi in qemu btw.
Qemu can send in "/pci@i0cf8/scsi@3/disk@0,0" - it's just unclear what
seabios is supposed to do with it. (If "ignore it" is the answer,
that's fine with me.)
> > If qemu sends in "/pci@i0cf8/scsi@3/disk@0,0" or
> > "/pci@i0cf8/ethernet@4/ethernet-phy@0" it will expect seabios to boot
> > from the appropriate device. In both cases, seabios would need to run
> > a rom in order to fulfill that request. Trying to figure out which
> > rom is quite painful. That's why I'd prefer to see qemu instead pass
> > in something like "/pci@i0cf8/rom@3/bcv@0" or "/pci@i0cf8/rom@4/bev".
> > That is, if the machine needs to boot via a rom I'd prefer qemu state
> > that explicitly.
> It is painful in Seabios it is impossible in qemu at all. There is no
> way for qemu to know about BCVs or BEVs in optionroms especially
> considering that they are created at runtime like you say bellow.
It's not impossible - qemu could code up rules for when to request a
rom boot and when to request a native boot. That may seem ugly, but
(as near as I can tell) it's basically what you've asked seabios to
do. If nothing else, qemu has the option to let the user pass in an
explicit request via the command-line.
> > BTW, in the situation where seabios has native device support (eg,
> > ATA), I don't have any concerns. (The names are a bit verbose, but
> > that's not really an issue.)
> This + network booting are the may use case really. And I do not see
> what problem we have with BEV devices. "/pci@i0cf8/rom@4/bev" is not
> much different from "/pci@i0cf8/ethernet@4/ethernet-phy@0" since there
> can be only one bev per pci device. It is easy for Seabios to see that
> to boot from pci device in slot 4 func 0 it has to execute BEV.
I'm still stuck on how seabios is supposed to know it's an ethernet
card. Sure, seabios could hardcode translations from classid to
strings, but that seems fragile. What happens when the user wants to
boot from myranet, or fiberchannel, or whatnot?
Maybe we can compromise here - if the user selects booting from a
device, and qemu sees there is a rom for that device, then qemu can
specify two boot options:
/pci@i0cf8/ethernet@4/ethernet-phy@0
/pci@i0cf8/rom@4
SeaBIOS will ignore the first entry, and act on the second entry. If
at some later point seabios knows how to natively boot from the device
(eg, scsi), then it will use the first entry and ignore the second.
BTW, how are PCI locations specified in these paths? They should have
a (bus, dev, fn) - your examples only seem to show dev. How are the
other parts specified?
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-28 17:15 ` [Qemu-devel] " Kevin O'Connor
@ 2010-11-28 18:47 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 18:47 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: qemu-devel, kvm, seabios
On Sun, Nov 28, 2010 at 12:15:44PM -0500, Kevin O'Connor wrote:
> On Sun, Nov 28, 2010 at 09:45:34AM +0200, Gleb Natapov wrote:
> > On Sat, Nov 27, 2010 at 04:07:45PM -0500, Kevin O'Connor wrote:
> > > On Sat, Nov 27, 2010 at 09:04:24PM +0200, Gleb Natapov wrote:
> > > > Suppose we add SCSI support to Seabios and suppose SCSI card Seabios can
> > > > natively boot from has optionrom. What Seabios will do in such situation
> > > > and how qemu can know it? Besides qemu support tries to be firmware
> > > > agnostic.
> > >
> > > In such a situation, under my proposal, users wouldn't be able to
> > > specify a default boot from their scsi drive until after qemu was also
> > > upgraded to know seabios could boot native scsi. (Or, they'd only be
> > > able to do it by adding in a command-line option.)
> > >
> > If scsi card has optionrom with only one bcv then Seabios can determine
> > its boot order from device path, so why not provide user with this
> > option today?
>
> It's unclear to me how SeaBIOS is supposed to do that.
>
Suppose we have "/pci@i0cf8/scsi@3/disk@0,0" with boot index 5 in
boot devices list and suppose pci device in slot 3 function 0 has
optionrom. When Seabios load the option rom from device to memory it looks
for string that matches "/pci@i0cf8/.*@3.*" if the string is found option
rom gets boot index from it. In our case "/pci@i0cf8/scsi@3/disk@0,0"
will match and optionrom will get boot index 5. In practice Seabios will
know that device is SCSI by reading device class so it will be able
to construct string "/pci@i0cf8/scsi@3" and use simple strstr to find
matching device path.
> >Besides qemu may be used to emulates sparc with openbios and
> > this combination may be able to boot from scsi device. Qemu is not just
> > x86 emulator running Seabios. If there is problem with scsi boot we let
> > management know, so it will not create unbootable configuration. Today it
> > is impossible to boot guest from scsi in qemu btw.
>
> Qemu can send in "/pci@i0cf8/scsi@3/disk@0,0" - it's just unclear what
> seabios is supposed to do with it. (If "ignore it" is the answer,
> that's fine with me.)
>
See above. But for some device paths "ignore it" is acceptable answer (is
Seabios can't boot from it and device doesn't have optionrom).
> > > If qemu sends in "/pci@i0cf8/scsi@3/disk@0,0" or
> > > "/pci@i0cf8/ethernet@4/ethernet-phy@0" it will expect seabios to boot
> > > from the appropriate device. In both cases, seabios would need to run
> > > a rom in order to fulfill that request. Trying to figure out which
> > > rom is quite painful. That's why I'd prefer to see qemu instead pass
> > > in something like "/pci@i0cf8/rom@3/bcv@0" or "/pci@i0cf8/rom@4/bev".
> > > That is, if the machine needs to boot via a rom I'd prefer qemu state
> > > that explicitly.
> > It is painful in Seabios it is impossible in qemu at all. There is no
> > way for qemu to know about BCVs or BEVs in optionroms especially
> > considering that they are created at runtime like you say bellow.
>
> It's not impossible - qemu could code up rules for when to request a
> rom boot and when to request a native boot. That may seem ugly, but
> (as near as I can tell) it's basically what you've asked seabios to
> do. If nothing else, qemu has the option to let the user pass in an
> explicit request via the command-line.
I still do not see why such rule is needed. Why information this patch
set provides is not enough?
>
> > > BTW, in the situation where seabios has native device support (eg,
> > > ATA), I don't have any concerns. (The names are a bit verbose, but
> > > that's not really an issue.)
> > This + network booting are the may use case really. And I do not see
> > what problem we have with BEV devices. "/pci@i0cf8/rom@4/bev" is not
> > much different from "/pci@i0cf8/ethernet@4/ethernet-phy@0" since there
> > can be only one bev per pci device. It is easy for Seabios to see that
> > to boot from pci device in slot 4 func 0 it has to execute BEV.
>
> I'm still stuck on how seabios is supposed to know it's an ethernet
> card. Sure, seabios could hardcode translations from classid to
> strings, but that seems fragile. What happens when the user wants to
> boot from myranet, or fiberchannel, or whatnot?
This is not fragile since class to name translation is defined
by the spec. But even that is not required if Seabios will be a
little bit smarter and will implement fuzzy matching. i.e do not
match "/pci@i0cf8/ethernet@4/ethernet-phy@0" exactly but match
"/pci@i0cf8/.*@4.*" instead.
>
> Maybe we can compromise here - if the user selects booting from a
> device, and qemu sees there is a rom for that device, then qemu can
> specify two boot options:
>
> /pci@i0cf8/ethernet@4/ethernet-phy@0
> /pci@i0cf8/rom@4
>
This patch series implement device paths as defined by Openfirmware
spec. /pci@i0cf8/rom@4 sould be out of spec. But I do not see why Seabios
can't build later from the former. Also I do not see why it would be
needed at all.
> SeaBIOS will ignore the first entry, and act on the second entry. If
> at some later point seabios knows how to natively boot from the device
> (eg, scsi), then it will use the first entry and ignore the second.
>
If you let go to the idea of exact matching of string built by qemu in
Seabios it will be easy to see that /pci@i0cf8/ethernet@4/ethernet-phy@0
provides everything that Seabios needs to know and even more. If
you ignore all the noise it just says "boot from pci device slot 4 fn
0". Seabios may have native support for the card in the slot or it can
use option rom on the card. Qemu does not care.
> BTW, how are PCI locations specified in these paths? They should have
> a (bus, dev, fn) - your examples only seem to show dev. How are the
> other parts specified?
>
Bus numbers are assigned by a guest. Qemu knows nothing about them, so
it specify device path by topology. If pci bridge is present device
path will look like this:
/pci@i0cf8/pci@2/ethernet@4,1/ethernet-phy@0.
This path point to device in slot 4 fn 1 sitting on pci-to-pci bridge
in slot 2 fn 0 of host pci controller. Same is true for usb bus.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-28 18:47 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 18:47 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: seabios, qemu-devel, kvm
On Sun, Nov 28, 2010 at 12:15:44PM -0500, Kevin O'Connor wrote:
> On Sun, Nov 28, 2010 at 09:45:34AM +0200, Gleb Natapov wrote:
> > On Sat, Nov 27, 2010 at 04:07:45PM -0500, Kevin O'Connor wrote:
> > > On Sat, Nov 27, 2010 at 09:04:24PM +0200, Gleb Natapov wrote:
> > > > Suppose we add SCSI support to Seabios and suppose SCSI card Seabios can
> > > > natively boot from has optionrom. What Seabios will do in such situation
> > > > and how qemu can know it? Besides qemu support tries to be firmware
> > > > agnostic.
> > >
> > > In such a situation, under my proposal, users wouldn't be able to
> > > specify a default boot from their scsi drive until after qemu was also
> > > upgraded to know seabios could boot native scsi. (Or, they'd only be
> > > able to do it by adding in a command-line option.)
> > >
> > If scsi card has optionrom with only one bcv then Seabios can determine
> > its boot order from device path, so why not provide user with this
> > option today?
>
> It's unclear to me how SeaBIOS is supposed to do that.
>
Suppose we have "/pci@i0cf8/scsi@3/disk@0,0" with boot index 5 in
boot devices list and suppose pci device in slot 3 function 0 has
optionrom. When Seabios load the option rom from device to memory it looks
for string that matches "/pci@i0cf8/.*@3.*" if the string is found option
rom gets boot index from it. In our case "/pci@i0cf8/scsi@3/disk@0,0"
will match and optionrom will get boot index 5. In practice Seabios will
know that device is SCSI by reading device class so it will be able
to construct string "/pci@i0cf8/scsi@3" and use simple strstr to find
matching device path.
> >Besides qemu may be used to emulates sparc with openbios and
> > this combination may be able to boot from scsi device. Qemu is not just
> > x86 emulator running Seabios. If there is problem with scsi boot we let
> > management know, so it will not create unbootable configuration. Today it
> > is impossible to boot guest from scsi in qemu btw.
>
> Qemu can send in "/pci@i0cf8/scsi@3/disk@0,0" - it's just unclear what
> seabios is supposed to do with it. (If "ignore it" is the answer,
> that's fine with me.)
>
See above. But for some device paths "ignore it" is acceptable answer (is
Seabios can't boot from it and device doesn't have optionrom).
> > > If qemu sends in "/pci@i0cf8/scsi@3/disk@0,0" or
> > > "/pci@i0cf8/ethernet@4/ethernet-phy@0" it will expect seabios to boot
> > > from the appropriate device. In both cases, seabios would need to run
> > > a rom in order to fulfill that request. Trying to figure out which
> > > rom is quite painful. That's why I'd prefer to see qemu instead pass
> > > in something like "/pci@i0cf8/rom@3/bcv@0" or "/pci@i0cf8/rom@4/bev".
> > > That is, if the machine needs to boot via a rom I'd prefer qemu state
> > > that explicitly.
> > It is painful in Seabios it is impossible in qemu at all. There is no
> > way for qemu to know about BCVs or BEVs in optionroms especially
> > considering that they are created at runtime like you say bellow.
>
> It's not impossible - qemu could code up rules for when to request a
> rom boot and when to request a native boot. That may seem ugly, but
> (as near as I can tell) it's basically what you've asked seabios to
> do. If nothing else, qemu has the option to let the user pass in an
> explicit request via the command-line.
I still do not see why such rule is needed. Why information this patch
set provides is not enough?
>
> > > BTW, in the situation where seabios has native device support (eg,
> > > ATA), I don't have any concerns. (The names are a bit verbose, but
> > > that's not really an issue.)
> > This + network booting are the may use case really. And I do not see
> > what problem we have with BEV devices. "/pci@i0cf8/rom@4/bev" is not
> > much different from "/pci@i0cf8/ethernet@4/ethernet-phy@0" since there
> > can be only one bev per pci device. It is easy for Seabios to see that
> > to boot from pci device in slot 4 func 0 it has to execute BEV.
>
> I'm still stuck on how seabios is supposed to know it's an ethernet
> card. Sure, seabios could hardcode translations from classid to
> strings, but that seems fragile. What happens when the user wants to
> boot from myranet, or fiberchannel, or whatnot?
This is not fragile since class to name translation is defined
by the spec. But even that is not required if Seabios will be a
little bit smarter and will implement fuzzy matching. i.e do not
match "/pci@i0cf8/ethernet@4/ethernet-phy@0" exactly but match
"/pci@i0cf8/.*@4.*" instead.
>
> Maybe we can compromise here - if the user selects booting from a
> device, and qemu sees there is a rom for that device, then qemu can
> specify two boot options:
>
> /pci@i0cf8/ethernet@4/ethernet-phy@0
> /pci@i0cf8/rom@4
>
This patch series implement device paths as defined by Openfirmware
spec. /pci@i0cf8/rom@4 sould be out of spec. But I do not see why Seabios
can't build later from the former. Also I do not see why it would be
needed at all.
> SeaBIOS will ignore the first entry, and act on the second entry. If
> at some later point seabios knows how to natively boot from the device
> (eg, scsi), then it will use the first entry and ignore the second.
>
If you let go to the idea of exact matching of string built by qemu in
Seabios it will be easy to see that /pci@i0cf8/ethernet@4/ethernet-phy@0
provides everything that Seabios needs to know and even more. If
you ignore all the noise it just says "boot from pci device slot 4 fn
0". Seabios may have native support for the card in the slot or it can
use option rom on the card. Qemu does not care.
> BTW, how are PCI locations specified in these paths? They should have
> a (bus, dev, fn) - your examples only seem to show dev. How are the
> other parts specified?
>
Bus numbers are assigned by a guest. Qemu knows nothing about them, so
it specify device path by topology. If pci bridge is present device
path will look like this:
/pci@i0cf8/pci@2/ethernet@4,1/ethernet-phy@0.
This path point to device in slot 4 fn 1 sitting on pci-to-pci bridge
in slot 2 fn 0 of host pci controller. Same is true for usb bus.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-28 18:47 ` [Qemu-devel] " Gleb Natapov
(?)
@ 2010-11-30 1:34 ` Kevin O'Connor
2010-11-30 14:01 ` [Qemu-devel] " Gleb Natapov
-1 siblings, 1 reply; 136+ messages in thread
From: Kevin O'Connor @ 2010-11-30 1:34 UTC (permalink / raw)
To: Gleb Natapov; +Cc: qemu-devel, kvm, seabios
On Sun, Nov 28, 2010 at 08:47:34PM +0200, Gleb Natapov wrote:
> On Sun, Nov 28, 2010 at 12:15:44PM -0500, Kevin O'Connor wrote:
> > It's unclear to me how SeaBIOS is supposed to do that.
> >
> Suppose we have "/pci@i0cf8/scsi@3/disk@0,0" with boot index 5 in
> boot devices list and suppose pci device in slot 3 function 0 has
> optionrom. When Seabios load the option rom from device to memory it looks
> for string that matches "/pci@i0cf8/.*@3.*" if the string is found option
> rom gets boot index from it. In our case "/pci@i0cf8/scsi@3/disk@0,0"
> will match and optionrom will get boot index 5. In practice Seabios will
> know that device is SCSI by reading device class so it will be able
> to construct string "/pci@i0cf8/scsi@3" and use simple strstr to find
> matching device path.
I recognize that if we had a regex engine in seabios this would work,
but I'm reluctant to add one. strstr doesn't work becuase "@3" could
match some unrelated part of the path (eg, don't want to match
"/pci@i0cf8/scsi@1/disk@3,0") - so, what you seem to want is
"/pci@i0cf8/[^/]*@3(/|$)".
[...]
> > I'm still stuck on how seabios is supposed to know it's an ethernet
> > card. Sure, seabios could hardcode translations from classid to
> > strings, but that seems fragile. What happens when the user wants to
> > boot from myranet, or fiberchannel, or whatnot?
> This is not fragile since class to name translation is defined
> by the spec. But even that is not required if Seabios will be a
> little bit smarter and will implement fuzzy matching. i.e do not
> match "/pci@i0cf8/ethernet@4/ethernet-phy@0" exactly but match
> "/pci@i0cf8/.*@4.*" instead.
I think we're agreeing here that we don't want to put class to name
translation in seabios. :-)
> > Maybe we can compromise here - if the user selects booting from a
> > device, and qemu sees there is a rom for that device, then qemu can
> > specify two boot options:
> >
> > /pci@i0cf8/ethernet@4/ethernet-phy@0
> > /pci@i0cf8/rom@4
> >
> This patch series implement device paths as defined by Openfirmware
> spec. /pci@i0cf8/rom@4 sould be out of spec. But I do not see why Seabios
> can't build later from the former. Also I do not see why it would be
> needed at all.
The name isn't important to me - call it something else if you want.
It's value is that SeaBIOS doesn't then need to do fuzzy matching or
parsing of the device names. That is, we turn the list from boot
devices to boot methods which makes life easier for the firmware.
> > SeaBIOS will ignore the first entry, and act on the second entry. If
> > at some later point seabios knows how to natively boot from the device
> > (eg, scsi), then it will use the first entry and ignore the second.
> >
> If you let go to the idea of exact matching of string built by qemu in
> Seabios it will be easy to see that /pci@i0cf8/ethernet@4/ethernet-phy@0
> provides everything that Seabios needs to know and even more. If
> you ignore all the noise it just says "boot from pci device slot 4 fn
> 0". Seabios may have native support for the card in the slot or it can
> use option rom on the card. Qemu does not care.
I'm having a hard time letting go of string matching. I understand
all the info is there if SeaBIOS parses the string. However, I think
parsing out openbios device strings is overkill in an x86 bios that
just wants to order the boot objects it knows about.
Is there an issue with qemu generating two strings for devices with
roms?
> > BTW, how are PCI locations specified in these paths? They should have
> > a (bus, dev, fn) - your examples only seem to show dev. How are the
> > other parts specified?
> >
> Bus numbers are assigned by a guest. Qemu knows nothing about them, so
> it specify device path by topology. If pci bridge is present device
> path will look like this:
> /pci@i0cf8/pci@2/ethernet@4,1/ethernet-phy@0.
> This path point to device in slot 4 fn 1 sitting on pci-to-pci bridge
> in slot 2 fn 0 of host pci controller. Same is true for usb bus.
I understand - it makes sense. This does mean that seabios will need
to track where each pci bus comes from.
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-30 1:34 ` Kevin O'Connor
@ 2010-11-30 14:01 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-30 14:01 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: qemu-devel, kvm, seabios
On Mon, Nov 29, 2010 at 08:34:03PM -0500, Kevin O'Connor wrote:
> On Sun, Nov 28, 2010 at 08:47:34PM +0200, Gleb Natapov wrote:
> > On Sun, Nov 28, 2010 at 12:15:44PM -0500, Kevin O'Connor wrote:
> > > It's unclear to me how SeaBIOS is supposed to do that.
> > >
> > Suppose we have "/pci@i0cf8/scsi@3/disk@0,0" with boot index 5 in
> > boot devices list and suppose pci device in slot 3 function 0 has
> > optionrom. When Seabios load the option rom from device to memory it looks
> > for string that matches "/pci@i0cf8/.*@3.*" if the string is found option
> > rom gets boot index from it. In our case "/pci@i0cf8/scsi@3/disk@0,0"
> > will match and optionrom will get boot index 5. In practice Seabios will
> > know that device is SCSI by reading device class so it will be able
> > to construct string "/pci@i0cf8/scsi@3" and use simple strstr to find
> > matching device path.
>
> I recognize that if we had a regex engine in seabios this would work,
> but I'm reluctant to add one. strstr doesn't work becuase "@3" could
> match some unrelated part of the path (eg, don't want to match
> "/pci@i0cf8/scsi@1/disk@3,0") - so, what you seem to want is
> "/pci@i0cf8/[^/]*@3(/|$)".
>
We do not need regex engine to part this very special and regular
string. The patch below reads boot order list from qemu and creates
rom2prio table for pci roms.
> [...]
> > > I'm still stuck on how seabios is supposed to know it's an ethernet
> > > card. Sure, seabios could hardcode translations from classid to
> > > strings, but that seems fragile. What happens when the user wants to
> > > boot from myranet, or fiberchannel, or whatnot?
> > This is not fragile since class to name translation is defined
> > by the spec. But even that is not required if Seabios will be a
> > little bit smarter and will implement fuzzy matching. i.e do not
> > match "/pci@i0cf8/ethernet@4/ethernet-phy@0" exactly but match
> > "/pci@i0cf8/.*@4.*" instead.
>
> I think we're agreeing here that we don't want to put class to name
> translation in seabios. :-)
We did? I think it is not needed but I don't not see why it would be
a problem.
>
> > > Maybe we can compromise here - if the user selects booting from a
> > > device, and qemu sees there is a rom for that device, then qemu can
> > > specify two boot options:
> > >
> > > /pci@i0cf8/ethernet@4/ethernet-phy@0
> > > /pci@i0cf8/rom@4
> > >
> > This patch series implement device paths as defined by Openfirmware
> > spec. /pci@i0cf8/rom@4 sould be out of spec. But I do not see why Seabios
> > can't build later from the former. Also I do not see why it would be
> > needed at all.
>
> The name isn't important to me - call it something else if you want.
> It's value is that SeaBIOS doesn't then need to do fuzzy matching or
> parsing of the device names. That is, we turn the list from boot
> devices to boot methods which makes life easier for the firmware.
>
> > > SeaBIOS will ignore the first entry, and act on the second entry. If
> > > at some later point seabios knows how to natively boot from the device
> > > (eg, scsi), then it will use the first entry and ignore the second.
> > >
> > If you let go to the idea of exact matching of string built by qemu in
> > Seabios it will be easy to see that /pci@i0cf8/ethernet@4/ethernet-phy@0
> > provides everything that Seabios needs to know and even more. If
> > you ignore all the noise it just says "boot from pci device slot 4 fn
> > 0". Seabios may have native support for the card in the slot or it can
> > use option rom on the card. Qemu does not care.
>
> I'm having a hard time letting go of string matching. I understand
> all the info is there if SeaBIOS parses the string. However, I think
> parsing out openbios device strings is overkill in an x86 bios that
> just wants to order the boot objects it knows about.
>
> Is there an issue with qemu generating two strings for devices with
> roms?
>
I just do not see how I can justify this addition to qemu maintainers
given that the parsing code below is very simple.
diff --git a/src/boot.c b/src/boot.c
index 021b8ac..c1ac9af 100644
--- a/src/boot.c
+++ b/src/boot.c
@@ -67,6 +67,47 @@ boot_setup(void)
if (!(inb_cmos(CMOS_BIOS_BOOTFLAG1) & 1))
IPL.checkfloppysig = 1;
}
+
+ u32 file = romfile_find("bootorder");
+ if (!file)
+ return;
+
+ int filesize = romfile_size(file);
+ char *f = malloc_tmphigh(filesize);
+ dprintf(3, "bootorder file found (len %d)\n", filesize);
+
+ if (!f) {
+ dprintf(1, "can't allocate memory for bootorder file\n");
+ return;
+ }
+
+ romfile_copy(file, f, filesize);
+ int i;
+ IPL.fw_bootorder_count = 1;
+ while(f[i]) {
+ if (f[i] == '\n')
+ IPL.fw_bootorder_count++;
+ i++;
+ }
+ IPL.fw_bootorder = malloc_tmphigh(IPL.fw_bootorder_count*sizeof(char*));
+ if (!IPL.fw_bootorder) {
+ dprintf(1, "can't allocate memory for bootorder\n");
+ free(f);
+ return;
+ }
+
+ dprintf(3, "boot order:\n");
+ i = 0;
+ do {
+ IPL.fw_bootorder[i] = f;
+ f = strchr(f, '\n');
+ if (*f) {
+ *f = '\0';
+ f++;
+ dprintf(3, "%d: %s\n", i, IPL.fw_bootorder[i]);
+ i++;
+ }
+ } while(f);
}
// Add a BEV vector for a given pnp compatible option rom.
@@ -506,3 +547,78 @@ handle_19(void)
SET_EBDA(boot_sequence, 0);
do_boot(0);
}
+
+/*
+ * function returns string representing firts device path element in 'dp'
+ * and puts pointer to the reset of the device path into 'end'
+ */
+static char *dev_path_get_node(const char *dp, const char **end)
+{
+ int len;
+ char *node;
+
+ dp += 1; /* skip '/' */
+
+ *end = strchr(dp, '/');
+
+ if (*end == NULL) {
+ len = strlen(dp); /* last path element */
+ *end = dp + len;
+ }
+ else
+ len = *end - dp;
+
+ if (len == 0)
+ return NULL;
+
+ node = malloc_tmphigh(len + 1);
+ memcpy(node, dp, len);
+ node[len] = '\0';
+
+ return node;
+}
+
+static int match_unit_address(const char *pe, const char *unit_address)
+{
+ char *s = strchr(pe, '@');
+
+ if (s == NULL)
+ return 0;
+
+ return !strcmp(s, unit_address);
+}
+
+#define FW_PCI_DOMAIN "/pci@i0cf8"
+
+int bootprio_match_pci_device(int dev, int fn)
+{
+ int i, l;
+ char pci[7];
+
+ if (!fn)
+ l = snprintf(pci, sizeof(pci), "@%x", dev);
+ else
+ l = snprintf(pci, sizeof(pci), "@%x,%x", dev, fn);
+
+ for (i = 0; i < IPL.fw_bootorder_count; i++) {
+ char *node;
+ const char *next, *path = IPL.fw_bootorder[i];
+ int r;
+
+ /* is pci domain? */
+ if (memcmp(path, FW_PCI_DOMAIN, strlen(FW_PCI_DOMAIN)))
+ continue;
+
+ node = dev_path_get_node(path + strlen(FW_PCI_DOMAIN), &next);
+ if (node == NULL)
+ continue;
+
+ r = match_unit_address(node, pci);
+
+ free(node);
+ if (r)
+ return i;
+ }
+
+ return -1;
+}
diff --git a/src/boot.h b/src/boot.h
index db046e3..07467e6 100644
--- a/src/boot.h
+++ b/src/boot.h
@@ -20,6 +20,8 @@ struct ipl_s {
int bevcount, bcvcount;
u32 bootorder;
int checkfloppysig;
+ char **fw_bootorder;
+ int fw_bootorder_count;
};
#define IPL_TYPE_FLOPPY 0x01
@@ -44,5 +46,6 @@ void add_bcv(u16 seg, u16 ip, u16 desc);
struct drive_s;
void add_bcv_internal(struct drive_s *drive_g);
void boot_prep(void);
+int bootprio_match_pci_device(int dev, int fn);
#endif // __BOOT_H
diff --git a/src/optionroms.c b/src/optionroms.c
index 854c33f..5500c56 100644
--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -74,6 +74,13 @@ struct pnp_data {
// The end of the last deployed rom.
u32 RomEnd = BUILD_ROM_START;
+static struct rom_boot_prio {
+ u32 addr;
+ int prio;
+} rom2prio[92];
+
+static int rom2prio_index;
+
/****************************************************************
* Helper functions
@@ -342,7 +349,20 @@ init_pcirom(u16 bdf, int isvga)
if (! rom)
// No ROM present.
return -1;
- return init_optionrom(rom, bdf, isvga);
+
+ int r = init_optionrom(rom, bdf, isvga);
+
+ if (r || !is_valid_rom(rom))
+ return r;
+
+ rom2prio[rom2prio_index].addr = (u32)rom;
+ rom2prio[rom2prio_index].prio =
+ bootprio_match_pci_device(pci_bdf_to_dev(bdf), pci_bdf_to_fn(bdf));
+ dprintf(3, "pci rom at memory address %x has boot prio %d\n",
+ rom2prio[rom2prio_index].addr, rom2prio[rom2prio_index].prio);
+ rom2prio_index++;
+
+ return r;
}
diff --git a/src/util.c b/src/util.c
index 8e02d1e..cfb4add 100644
--- a/src/util.c
+++ b/src/util.c
@@ -253,6 +253,17 @@ strtcpy(char *dest, const char *src, size_t len)
return dest;
}
+// locate first occurance of character c in the string s
+char *
+strchr(const char *s, int c)
+{
+ int i = 0;
+
+ while(s[i] && s[i] != c)
+ i++;
+
+ return s[i] ? (char*)&s[i] : NULL;
+}
/****************************************************************
* Keyboard calls
diff --git a/src/util.h b/src/util.h
index 18ab814..cd46d9c 100644
--- a/src/util.h
+++ b/src/util.h
@@ -208,6 +208,7 @@ void *memcpy(void *d1, const void *s1, size_t len);
void iomemcpy(void *d, const void *s, u32 len);
void *memmove(void *d, const void *s, size_t len);
char *strtcpy(char *dest, const char *src, size_t len);
+char *strchr(const char *s, int c);
int get_keystroke(int msec);
// stacks.c
--
Gleb.
^ permalink raw reply related [flat|nested] 136+ messages in thread* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-30 14:01 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-30 14:01 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: seabios, qemu-devel, kvm
On Mon, Nov 29, 2010 at 08:34:03PM -0500, Kevin O'Connor wrote:
> On Sun, Nov 28, 2010 at 08:47:34PM +0200, Gleb Natapov wrote:
> > On Sun, Nov 28, 2010 at 12:15:44PM -0500, Kevin O'Connor wrote:
> > > It's unclear to me how SeaBIOS is supposed to do that.
> > >
> > Suppose we have "/pci@i0cf8/scsi@3/disk@0,0" with boot index 5 in
> > boot devices list and suppose pci device in slot 3 function 0 has
> > optionrom. When Seabios load the option rom from device to memory it looks
> > for string that matches "/pci@i0cf8/.*@3.*" if the string is found option
> > rom gets boot index from it. In our case "/pci@i0cf8/scsi@3/disk@0,0"
> > will match and optionrom will get boot index 5. In practice Seabios will
> > know that device is SCSI by reading device class so it will be able
> > to construct string "/pci@i0cf8/scsi@3" and use simple strstr to find
> > matching device path.
>
> I recognize that if we had a regex engine in seabios this would work,
> but I'm reluctant to add one. strstr doesn't work becuase "@3" could
> match some unrelated part of the path (eg, don't want to match
> "/pci@i0cf8/scsi@1/disk@3,0") - so, what you seem to want is
> "/pci@i0cf8/[^/]*@3(/|$)".
>
We do not need regex engine to part this very special and regular
string. The patch below reads boot order list from qemu and creates
rom2prio table for pci roms.
> [...]
> > > I'm still stuck on how seabios is supposed to know it's an ethernet
> > > card. Sure, seabios could hardcode translations from classid to
> > > strings, but that seems fragile. What happens when the user wants to
> > > boot from myranet, or fiberchannel, or whatnot?
> > This is not fragile since class to name translation is defined
> > by the spec. But even that is not required if Seabios will be a
> > little bit smarter and will implement fuzzy matching. i.e do not
> > match "/pci@i0cf8/ethernet@4/ethernet-phy@0" exactly but match
> > "/pci@i0cf8/.*@4.*" instead.
>
> I think we're agreeing here that we don't want to put class to name
> translation in seabios. :-)
We did? I think it is not needed but I don't not see why it would be
a problem.
>
> > > Maybe we can compromise here - if the user selects booting from a
> > > device, and qemu sees there is a rom for that device, then qemu can
> > > specify two boot options:
> > >
> > > /pci@i0cf8/ethernet@4/ethernet-phy@0
> > > /pci@i0cf8/rom@4
> > >
> > This patch series implement device paths as defined by Openfirmware
> > spec. /pci@i0cf8/rom@4 sould be out of spec. But I do not see why Seabios
> > can't build later from the former. Also I do not see why it would be
> > needed at all.
>
> The name isn't important to me - call it something else if you want.
> It's value is that SeaBIOS doesn't then need to do fuzzy matching or
> parsing of the device names. That is, we turn the list from boot
> devices to boot methods which makes life easier for the firmware.
>
> > > SeaBIOS will ignore the first entry, and act on the second entry. If
> > > at some later point seabios knows how to natively boot from the device
> > > (eg, scsi), then it will use the first entry and ignore the second.
> > >
> > If you let go to the idea of exact matching of string built by qemu in
> > Seabios it will be easy to see that /pci@i0cf8/ethernet@4/ethernet-phy@0
> > provides everything that Seabios needs to know and even more. If
> > you ignore all the noise it just says "boot from pci device slot 4 fn
> > 0". Seabios may have native support for the card in the slot or it can
> > use option rom on the card. Qemu does not care.
>
> I'm having a hard time letting go of string matching. I understand
> all the info is there if SeaBIOS parses the string. However, I think
> parsing out openbios device strings is overkill in an x86 bios that
> just wants to order the boot objects it knows about.
>
> Is there an issue with qemu generating two strings for devices with
> roms?
>
I just do not see how I can justify this addition to qemu maintainers
given that the parsing code below is very simple.
diff --git a/src/boot.c b/src/boot.c
index 021b8ac..c1ac9af 100644
--- a/src/boot.c
+++ b/src/boot.c
@@ -67,6 +67,47 @@ boot_setup(void)
if (!(inb_cmos(CMOS_BIOS_BOOTFLAG1) & 1))
IPL.checkfloppysig = 1;
}
+
+ u32 file = romfile_find("bootorder");
+ if (!file)
+ return;
+
+ int filesize = romfile_size(file);
+ char *f = malloc_tmphigh(filesize);
+ dprintf(3, "bootorder file found (len %d)\n", filesize);
+
+ if (!f) {
+ dprintf(1, "can't allocate memory for bootorder file\n");
+ return;
+ }
+
+ romfile_copy(file, f, filesize);
+ int i;
+ IPL.fw_bootorder_count = 1;
+ while(f[i]) {
+ if (f[i] == '\n')
+ IPL.fw_bootorder_count++;
+ i++;
+ }
+ IPL.fw_bootorder = malloc_tmphigh(IPL.fw_bootorder_count*sizeof(char*));
+ if (!IPL.fw_bootorder) {
+ dprintf(1, "can't allocate memory for bootorder\n");
+ free(f);
+ return;
+ }
+
+ dprintf(3, "boot order:\n");
+ i = 0;
+ do {
+ IPL.fw_bootorder[i] = f;
+ f = strchr(f, '\n');
+ if (*f) {
+ *f = '\0';
+ f++;
+ dprintf(3, "%d: %s\n", i, IPL.fw_bootorder[i]);
+ i++;
+ }
+ } while(f);
}
// Add a BEV vector for a given pnp compatible option rom.
@@ -506,3 +547,78 @@ handle_19(void)
SET_EBDA(boot_sequence, 0);
do_boot(0);
}
+
+/*
+ * function returns string representing firts device path element in 'dp'
+ * and puts pointer to the reset of the device path into 'end'
+ */
+static char *dev_path_get_node(const char *dp, const char **end)
+{
+ int len;
+ char *node;
+
+ dp += 1; /* skip '/' */
+
+ *end = strchr(dp, '/');
+
+ if (*end == NULL) {
+ len = strlen(dp); /* last path element */
+ *end = dp + len;
+ }
+ else
+ len = *end - dp;
+
+ if (len == 0)
+ return NULL;
+
+ node = malloc_tmphigh(len + 1);
+ memcpy(node, dp, len);
+ node[len] = '\0';
+
+ return node;
+}
+
+static int match_unit_address(const char *pe, const char *unit_address)
+{
+ char *s = strchr(pe, '@');
+
+ if (s == NULL)
+ return 0;
+
+ return !strcmp(s, unit_address);
+}
+
+#define FW_PCI_DOMAIN "/pci@i0cf8"
+
+int bootprio_match_pci_device(int dev, int fn)
+{
+ int i, l;
+ char pci[7];
+
+ if (!fn)
+ l = snprintf(pci, sizeof(pci), "@%x", dev);
+ else
+ l = snprintf(pci, sizeof(pci), "@%x,%x", dev, fn);
+
+ for (i = 0; i < IPL.fw_bootorder_count; i++) {
+ char *node;
+ const char *next, *path = IPL.fw_bootorder[i];
+ int r;
+
+ /* is pci domain? */
+ if (memcmp(path, FW_PCI_DOMAIN, strlen(FW_PCI_DOMAIN)))
+ continue;
+
+ node = dev_path_get_node(path + strlen(FW_PCI_DOMAIN), &next);
+ if (node == NULL)
+ continue;
+
+ r = match_unit_address(node, pci);
+
+ free(node);
+ if (r)
+ return i;
+ }
+
+ return -1;
+}
diff --git a/src/boot.h b/src/boot.h
index db046e3..07467e6 100644
--- a/src/boot.h
+++ b/src/boot.h
@@ -20,6 +20,8 @@ struct ipl_s {
int bevcount, bcvcount;
u32 bootorder;
int checkfloppysig;
+ char **fw_bootorder;
+ int fw_bootorder_count;
};
#define IPL_TYPE_FLOPPY 0x01
@@ -44,5 +46,6 @@ void add_bcv(u16 seg, u16 ip, u16 desc);
struct drive_s;
void add_bcv_internal(struct drive_s *drive_g);
void boot_prep(void);
+int bootprio_match_pci_device(int dev, int fn);
#endif // __BOOT_H
diff --git a/src/optionroms.c b/src/optionroms.c
index 854c33f..5500c56 100644
--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -74,6 +74,13 @@ struct pnp_data {
// The end of the last deployed rom.
u32 RomEnd = BUILD_ROM_START;
+static struct rom_boot_prio {
+ u32 addr;
+ int prio;
+} rom2prio[92];
+
+static int rom2prio_index;
+
/****************************************************************
* Helper functions
@@ -342,7 +349,20 @@ init_pcirom(u16 bdf, int isvga)
if (! rom)
// No ROM present.
return -1;
- return init_optionrom(rom, bdf, isvga);
+
+ int r = init_optionrom(rom, bdf, isvga);
+
+ if (r || !is_valid_rom(rom))
+ return r;
+
+ rom2prio[rom2prio_index].addr = (u32)rom;
+ rom2prio[rom2prio_index].prio =
+ bootprio_match_pci_device(pci_bdf_to_dev(bdf), pci_bdf_to_fn(bdf));
+ dprintf(3, "pci rom at memory address %x has boot prio %d\n",
+ rom2prio[rom2prio_index].addr, rom2prio[rom2prio_index].prio);
+ rom2prio_index++;
+
+ return r;
}
diff --git a/src/util.c b/src/util.c
index 8e02d1e..cfb4add 100644
--- a/src/util.c
+++ b/src/util.c
@@ -253,6 +253,17 @@ strtcpy(char *dest, const char *src, size_t len)
return dest;
}
+// locate first occurance of character c in the string s
+char *
+strchr(const char *s, int c)
+{
+ int i = 0;
+
+ while(s[i] && s[i] != c)
+ i++;
+
+ return s[i] ? (char*)&s[i] : NULL;
+}
/****************************************************************
* Keyboard calls
diff --git a/src/util.h b/src/util.h
index 18ab814..cd46d9c 100644
--- a/src/util.h
+++ b/src/util.h
@@ -208,6 +208,7 @@ void *memcpy(void *d1, const void *s1, size_t len);
void iomemcpy(void *d, const void *s, u32 len);
void *memmove(void *d, const void *s, size_t len);
char *strtcpy(char *dest, const char *src, size_t len);
+char *strchr(const char *s, int c);
int get_keystroke(int msec);
// stacks.c
--
Gleb.
^ permalink raw reply related [flat|nested] 136+ messages in thread* Re: [PATCHv6 00/16] boot order specification
2010-11-30 14:01 ` [Qemu-devel] " Gleb Natapov
@ 2010-12-01 2:53 ` Kevin O'Connor
-1 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-12-01 2:53 UTC (permalink / raw)
To: Gleb Natapov; +Cc: qemu-devel, kvm, seabios
On Tue, Nov 30, 2010 at 04:01:00PM +0200, Gleb Natapov wrote:
> On Mon, Nov 29, 2010 at 08:34:03PM -0500, Kevin O'Connor wrote:
> > On Sun, Nov 28, 2010 at 08:47:34PM +0200, Gleb Natapov wrote:
> > > If you let go to the idea of exact matching of string built by qemu in
> > > Seabios it will be easy to see that /pci@i0cf8/ethernet@4/ethernet-phy@0
> > > provides everything that Seabios needs to know and even more. If
> > > you ignore all the noise it just says "boot from pci device slot 4 fn
> > > 0". Seabios may have native support for the card in the slot or it can
> > > use option rom on the card. Qemu does not care.
> >
> > I'm having a hard time letting go of string matching. I understand
> > all the info is there if SeaBIOS parses the string. However, I think
> > parsing out openbios device strings is overkill in an x86 bios that
> > just wants to order the boot objects it knows about.
> >
> > Is there an issue with qemu generating two strings for devices with
> > roms?
> >
> I just do not see how I can justify this addition to qemu maintainers
> given that the parsing code below is very simple.
It doesn't look correct to me - it doesn't handle the case where the
PCI device is on a bridge.
BTW, what's the plan for handling SCSI adapters? Lets say a user has
a scsi card with three drives (lun 1, lun 3, lun 5) that show up as 3
bcvs (lun1, lun3, lun5 in that order) and the user wishes to boot from
lun3. I understand this use case may not be important for qemu, but
I'd like to use the same code on coreboot. Being able to boot from
any drive is important - it doesn't have to autodetect, but it should
be possible.
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-12-01 2:53 ` Kevin O'Connor
0 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-12-01 2:53 UTC (permalink / raw)
To: Gleb Natapov; +Cc: seabios, qemu-devel, kvm
On Tue, Nov 30, 2010 at 04:01:00PM +0200, Gleb Natapov wrote:
> On Mon, Nov 29, 2010 at 08:34:03PM -0500, Kevin O'Connor wrote:
> > On Sun, Nov 28, 2010 at 08:47:34PM +0200, Gleb Natapov wrote:
> > > If you let go to the idea of exact matching of string built by qemu in
> > > Seabios it will be easy to see that /pci@i0cf8/ethernet@4/ethernet-phy@0
> > > provides everything that Seabios needs to know and even more. If
> > > you ignore all the noise it just says "boot from pci device slot 4 fn
> > > 0". Seabios may have native support for the card in the slot or it can
> > > use option rom on the card. Qemu does not care.
> >
> > I'm having a hard time letting go of string matching. I understand
> > all the info is there if SeaBIOS parses the string. However, I think
> > parsing out openbios device strings is overkill in an x86 bios that
> > just wants to order the boot objects it knows about.
> >
> > Is there an issue with qemu generating two strings for devices with
> > roms?
> >
> I just do not see how I can justify this addition to qemu maintainers
> given that the parsing code below is very simple.
It doesn't look correct to me - it doesn't handle the case where the
PCI device is on a bridge.
BTW, what's the plan for handling SCSI adapters? Lets say a user has
a scsi card with three drives (lun 1, lun 3, lun 5) that show up as 3
bcvs (lun1, lun3, lun5 in that order) and the user wishes to boot from
lun3. I understand this use case may not be important for qemu, but
I'd like to use the same code on coreboot. Being able to boot from
any drive is important - it doesn't have to autodetect, but it should
be possible.
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-12-01 2:53 ` [Qemu-devel] " Kevin O'Connor
@ 2010-12-01 12:27 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-12-01 12:27 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: qemu-devel, kvm, seabios
On Tue, Nov 30, 2010 at 09:53:32PM -0500, Kevin O'Connor wrote:
> On Tue, Nov 30, 2010 at 04:01:00PM +0200, Gleb Natapov wrote:
> > On Mon, Nov 29, 2010 at 08:34:03PM -0500, Kevin O'Connor wrote:
> > > On Sun, Nov 28, 2010 at 08:47:34PM +0200, Gleb Natapov wrote:
> > > > If you let go to the idea of exact matching of string built by qemu in
> > > > Seabios it will be easy to see that /pci@i0cf8/ethernet@4/ethernet-phy@0
> > > > provides everything that Seabios needs to know and even more. If
> > > > you ignore all the noise it just says "boot from pci device slot 4 fn
> > > > 0". Seabios may have native support for the card in the slot or it can
> > > > use option rom on the card. Qemu does not care.
> > >
> > > I'm having a hard time letting go of string matching. I understand
> > > all the info is there if SeaBIOS parses the string. However, I think
> > > parsing out openbios device strings is overkill in an x86 bios that
> > > just wants to order the boot objects it knows about.
> > >
> > > Is there an issue with qemu generating two strings for devices with
> > > roms?
> > >
> > I just do not see how I can justify this addition to qemu maintainers
> > given that the parsing code below is very simple.
>
> It doesn't look correct to me - it doesn't handle the case where the
> PCI device is on a bridge.
>
This is because Seabios does not yet keep pci bus topology information.
Given this information it is very easy to add bridge support to my code.
dev_path_get_node() returns pointer to next node for purpose :)
> BTW, what's the plan for handling SCSI adapters? Lets say a user has
> a scsi card with three drives (lun 1, lun 3, lun 5) that show up as 3
> bcvs (lun1, lun3, lun5 in that order) and the user wishes to boot from
> lun3. I understand this use case may not be important for qemu, but
> I'd like to use the same code on coreboot. Being able to boot from
> any drive is important - it doesn't have to autodetect, but it should
> be possible.
>
We can't. Option rom does not give us back enough information to do so.
Form device path we know exactly what id:lun boot should be done from,
but pnp_data does not have information to map BCV back to id:lun. I do
not see how coreboot can provide better information to Seabios then
qemu here. BTW to create proper EDD entry for SCSI boot device BIOS also
needs too map BCV to id:lun. How it can be done?
SCSI _is_ important for qemu. Not HBA we have now, but something supported
by recent operation systems out of the box. When such HBA will be emulated
in qemu we will add native Seabios support for it.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-12-01 12:27 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-12-01 12:27 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: seabios, qemu-devel, kvm
On Tue, Nov 30, 2010 at 09:53:32PM -0500, Kevin O'Connor wrote:
> On Tue, Nov 30, 2010 at 04:01:00PM +0200, Gleb Natapov wrote:
> > On Mon, Nov 29, 2010 at 08:34:03PM -0500, Kevin O'Connor wrote:
> > > On Sun, Nov 28, 2010 at 08:47:34PM +0200, Gleb Natapov wrote:
> > > > If you let go to the idea of exact matching of string built by qemu in
> > > > Seabios it will be easy to see that /pci@i0cf8/ethernet@4/ethernet-phy@0
> > > > provides everything that Seabios needs to know and even more. If
> > > > you ignore all the noise it just says "boot from pci device slot 4 fn
> > > > 0". Seabios may have native support for the card in the slot or it can
> > > > use option rom on the card. Qemu does not care.
> > >
> > > I'm having a hard time letting go of string matching. I understand
> > > all the info is there if SeaBIOS parses the string. However, I think
> > > parsing out openbios device strings is overkill in an x86 bios that
> > > just wants to order the boot objects it knows about.
> > >
> > > Is there an issue with qemu generating two strings for devices with
> > > roms?
> > >
> > I just do not see how I can justify this addition to qemu maintainers
> > given that the parsing code below is very simple.
>
> It doesn't look correct to me - it doesn't handle the case where the
> PCI device is on a bridge.
>
This is because Seabios does not yet keep pci bus topology information.
Given this information it is very easy to add bridge support to my code.
dev_path_get_node() returns pointer to next node for purpose :)
> BTW, what's the plan for handling SCSI adapters? Lets say a user has
> a scsi card with three drives (lun 1, lun 3, lun 5) that show up as 3
> bcvs (lun1, lun3, lun5 in that order) and the user wishes to boot from
> lun3. I understand this use case may not be important for qemu, but
> I'd like to use the same code on coreboot. Being able to boot from
> any drive is important - it doesn't have to autodetect, but it should
> be possible.
>
We can't. Option rom does not give us back enough information to do so.
Form device path we know exactly what id:lun boot should be done from,
but pnp_data does not have information to map BCV back to id:lun. I do
not see how coreboot can provide better information to Seabios then
qemu here. BTW to create proper EDD entry for SCSI boot device BIOS also
needs too map BCV to id:lun. How it can be done?
SCSI _is_ important for qemu. Not HBA we have now, but something supported
by recent operation systems out of the box. When such HBA will be emulated
in qemu we will add native Seabios support for it.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-12-01 12:27 ` [Qemu-devel] " Gleb Natapov
@ 2010-12-02 2:25 ` Kevin O'Connor
-1 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-12-02 2:25 UTC (permalink / raw)
To: Gleb Natapov; +Cc: qemu-devel, kvm, seabios
On Wed, Dec 01, 2010 at 02:27:40PM +0200, Gleb Natapov wrote:
> On Tue, Nov 30, 2010 at 09:53:32PM -0500, Kevin O'Connor wrote:
> > BTW, what's the plan for handling SCSI adapters? Lets say a user has
> > a scsi card with three drives (lun 1, lun 3, lun 5) that show up as 3
> > bcvs (lun1, lun3, lun5 in that order) and the user wishes to boot from
> > lun3. I understand this use case may not be important for qemu, but
> > I'd like to use the same code on coreboot. Being able to boot from
> > any drive is important - it doesn't have to autodetect, but it should
> > be possible.
> >
> We can't. Option rom does not give us back enough information to do so.
> Form device path we know exactly what id:lun boot should be done from,
> but pnp_data does not have information to map BCV back to id:lun. I do
> not see how coreboot can provide better information to Seabios then
> qemu here.
You're thinking in terms of which device to boot, which does make this
difficult. However, it's equally valid to think in terms of which
boot method to invoke, which makes this easy.
We could tell the coreboot user to edit the "bootorder" file and add
"/pci@i0cf8/rom1@4" (second rom on 4th pci device - the exact syntax
of the name is not important).
>BTW to create proper EDD entry for SCSI boot device BIOS also
> needs too map BCV to id:lun. How it can be done?
It's the responsibility of the rom to build the EDD info. I don't
know if all roms do this - I don't believe it's possible to get at the
EDD info until after the drive has been mapped (ie, too late to use it
for boot ordering).
> SCSI _is_ important for qemu. Not HBA we have now, but something supported
> by recent operation systems out of the box. When such HBA will be emulated
> in qemu we will add native Seabios support for it.
I understand. However, we'll still need to support arbitrary rom
based BEVs and BCVs, so the use case is still important.
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-12-02 2:25 ` Kevin O'Connor
0 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-12-02 2:25 UTC (permalink / raw)
To: Gleb Natapov; +Cc: seabios, qemu-devel, kvm
On Wed, Dec 01, 2010 at 02:27:40PM +0200, Gleb Natapov wrote:
> On Tue, Nov 30, 2010 at 09:53:32PM -0500, Kevin O'Connor wrote:
> > BTW, what's the plan for handling SCSI adapters? Lets say a user has
> > a scsi card with three drives (lun 1, lun 3, lun 5) that show up as 3
> > bcvs (lun1, lun3, lun5 in that order) and the user wishes to boot from
> > lun3. I understand this use case may not be important for qemu, but
> > I'd like to use the same code on coreboot. Being able to boot from
> > any drive is important - it doesn't have to autodetect, but it should
> > be possible.
> >
> We can't. Option rom does not give us back enough information to do so.
> Form device path we know exactly what id:lun boot should be done from,
> but pnp_data does not have information to map BCV back to id:lun. I do
> not see how coreboot can provide better information to Seabios then
> qemu here.
You're thinking in terms of which device to boot, which does make this
difficult. However, it's equally valid to think in terms of which
boot method to invoke, which makes this easy.
We could tell the coreboot user to edit the "bootorder" file and add
"/pci@i0cf8/rom1@4" (second rom on 4th pci device - the exact syntax
of the name is not important).
>BTW to create proper EDD entry for SCSI boot device BIOS also
> needs too map BCV to id:lun. How it can be done?
It's the responsibility of the rom to build the EDD info. I don't
know if all roms do this - I don't believe it's possible to get at the
EDD info until after the drive has been mapped (ie, too late to use it
for boot ordering).
> SCSI _is_ important for qemu. Not HBA we have now, but something supported
> by recent operation systems out of the box. When such HBA will be emulated
> in qemu we will add native Seabios support for it.
I understand. However, we'll still need to support arbitrary rom
based BEVs and BCVs, so the use case is still important.
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-12-02 2:25 ` [Qemu-devel] " Kevin O'Connor
@ 2010-12-02 12:30 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-12-02 12:30 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: seabios, qemu-devel, kvm
On Wed, Dec 01, 2010 at 09:25:40PM -0500, Kevin O'Connor wrote:
> On Wed, Dec 01, 2010 at 02:27:40PM +0200, Gleb Natapov wrote:
> > On Tue, Nov 30, 2010 at 09:53:32PM -0500, Kevin O'Connor wrote:
> > > BTW, what's the plan for handling SCSI adapters? Lets say a user has
> > > a scsi card with three drives (lun 1, lun 3, lun 5) that show up as 3
> > > bcvs (lun1, lun3, lun5 in that order) and the user wishes to boot from
> > > lun3. I understand this use case may not be important for qemu, but
> > > I'd like to use the same code on coreboot. Being able to boot from
> > > any drive is important - it doesn't have to autodetect, but it should
> > > be possible.
> > >
> > We can't. Option rom does not give us back enough information to do so.
> > Form device path we know exactly what id:lun boot should be done from,
> > but pnp_data does not have information to map BCV back to id:lun. I do
> > not see how coreboot can provide better information to Seabios then
> > qemu here.
>
> You're thinking in terms of which device to boot, which does make this
> difficult. However, it's equally valid to think in terms of which
> boot method to invoke, which makes this easy.
It is not. Because boot methods are enumerated by a guest at runtime.
Qemu knows absolutely nothing about them. I am thinking in terms of
devices because this is the only thing I have in qemu. BBS specification
is broken since it doesn't provide a way for discovered boot method
(BCV) to be linked back to a device it will boot from. Nothing we can do
to fix this except moving to EFI (an hope the problem is fixed there).
>
> We could tell the coreboot user to edit the "bootorder" file and add
> "/pci@i0cf8/rom1@4" (second rom on 4th pci device - the exact syntax
> of the name is not important).
>
But how user should knows that second rom (I think you mean "second BCV")
on pci device 4.0 will boot from the new scsi cdrom that he just connected?
How can he tell that it should put second BCV there and not third or fifth
without running Seabios first and looking at F12 menu? Depending on
option rom implementation even F12 menu can have not enough information
for user to guess which boot entry he should use to boot from the device
because product name that is used to distinguish between different boot
entires should be unique, but not necessary provide useful information
about device according to spec. (Both gpxe and lsi 8xx_64.rom provide device
address as part of product name; gpxe puts pci address there and 8xx_64.rom
puts ID LUN). Another important point is that BCV number can change when new
device is added to scsi bus, so next boot will mysteriously fail. Important
property of device path that it is stable and does not depend on HW configuration.
> >BTW to create proper EDD entry for SCSI boot device BIOS also
> > needs too map BCV to id:lun. How it can be done?
>
> It's the responsibility of the rom to build the EDD info. I don't
> know if all roms do this - I don't believe it's possible to get at the
> EDD info until after the drive has been mapped (ie, too late to use it
> for boot ordering).
How can we get to EDD info after device is mapped? Looking at Seabios
implementation it builds EDD table on the fly when int_1348 is called
and it does it only for internal devices. Can we use "disconnect vector"
to connect device temporarily get EDD and then disconnect?
>
> > SCSI _is_ important for qemu. Not HBA we have now, but something supported
> > by recent operation systems out of the box. When such HBA will be emulated
> > in qemu we will add native Seabios support for it.
>
> I understand. However, we'll still need to support arbitrary rom
> based BEVs and BCVs, so the use case is still important.
>
We can't do something that is impossible. For coreboot Seabios should
implement what BBS spec says i.e enumerate all BCVs, present boot menu
to the user, record number of BCVs and user's choice on non-volatile
storage (CMOS). On next boot use recorded user's choice unless number of
BCVs changes, otherwise present boot menu again. This is of course
broken too since number of BCVs may not change even if HW configuration
changes substantially. Spec says that in that case user probably
will want to adjust boot order anyway and will enter boot menu by
itself. Sorry excuse for failing to provide proper functionality if you
ask me :)
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-12-02 12:30 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-12-02 12:30 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: seabios, qemu-devel, kvm
On Wed, Dec 01, 2010 at 09:25:40PM -0500, Kevin O'Connor wrote:
> On Wed, Dec 01, 2010 at 02:27:40PM +0200, Gleb Natapov wrote:
> > On Tue, Nov 30, 2010 at 09:53:32PM -0500, Kevin O'Connor wrote:
> > > BTW, what's the plan for handling SCSI adapters? Lets say a user has
> > > a scsi card with three drives (lun 1, lun 3, lun 5) that show up as 3
> > > bcvs (lun1, lun3, lun5 in that order) and the user wishes to boot from
> > > lun3. I understand this use case may not be important for qemu, but
> > > I'd like to use the same code on coreboot. Being able to boot from
> > > any drive is important - it doesn't have to autodetect, but it should
> > > be possible.
> > >
> > We can't. Option rom does not give us back enough information to do so.
> > Form device path we know exactly what id:lun boot should be done from,
> > but pnp_data does not have information to map BCV back to id:lun. I do
> > not see how coreboot can provide better information to Seabios then
> > qemu here.
>
> You're thinking in terms of which device to boot, which does make this
> difficult. However, it's equally valid to think in terms of which
> boot method to invoke, which makes this easy.
It is not. Because boot methods are enumerated by a guest at runtime.
Qemu knows absolutely nothing about them. I am thinking in terms of
devices because this is the only thing I have in qemu. BBS specification
is broken since it doesn't provide a way for discovered boot method
(BCV) to be linked back to a device it will boot from. Nothing we can do
to fix this except moving to EFI (an hope the problem is fixed there).
>
> We could tell the coreboot user to edit the "bootorder" file and add
> "/pci@i0cf8/rom1@4" (second rom on 4th pci device - the exact syntax
> of the name is not important).
>
But how user should knows that second rom (I think you mean "second BCV")
on pci device 4.0 will boot from the new scsi cdrom that he just connected?
How can he tell that it should put second BCV there and not third or fifth
without running Seabios first and looking at F12 menu? Depending on
option rom implementation even F12 menu can have not enough information
for user to guess which boot entry he should use to boot from the device
because product name that is used to distinguish between different boot
entires should be unique, but not necessary provide useful information
about device according to spec. (Both gpxe and lsi 8xx_64.rom provide device
address as part of product name; gpxe puts pci address there and 8xx_64.rom
puts ID LUN). Another important point is that BCV number can change when new
device is added to scsi bus, so next boot will mysteriously fail. Important
property of device path that it is stable and does not depend on HW configuration.
> >BTW to create proper EDD entry for SCSI boot device BIOS also
> > needs too map BCV to id:lun. How it can be done?
>
> It's the responsibility of the rom to build the EDD info. I don't
> know if all roms do this - I don't believe it's possible to get at the
> EDD info until after the drive has been mapped (ie, too late to use it
> for boot ordering).
How can we get to EDD info after device is mapped? Looking at Seabios
implementation it builds EDD table on the fly when int_1348 is called
and it does it only for internal devices. Can we use "disconnect vector"
to connect device temporarily get EDD and then disconnect?
>
> > SCSI _is_ important for qemu. Not HBA we have now, but something supported
> > by recent operation systems out of the box. When such HBA will be emulated
> > in qemu we will add native Seabios support for it.
>
> I understand. However, we'll still need to support arbitrary rom
> based BEVs and BCVs, so the use case is still important.
>
We can't do something that is impossible. For coreboot Seabios should
implement what BBS spec says i.e enumerate all BCVs, present boot menu
to the user, record number of BCVs and user's choice on non-volatile
storage (CMOS). On next boot use recorded user's choice unless number of
BCVs changes, otherwise present boot menu again. This is of course
broken too since number of BCVs may not change even if HW configuration
changes substantially. Spec says that in that case user probably
will want to adjust boot order anyway and will enter boot menu by
itself. Sorry excuse for failing to provide proper functionality if you
ask me :)
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
2010-12-02 12:30 ` [Qemu-devel] " Gleb Natapov
@ 2010-12-02 15:07 ` Peter Stuge
-1 siblings, 0 replies; 136+ messages in thread
From: Peter Stuge @ 2010-12-02 15:07 UTC (permalink / raw)
To: Gleb Natapov; +Cc: Kevin O'Connor, seabios, qemu-devel, kvm
Gleb Natapov wrote:
> BBS specification is broken since it doesn't provide a way for
> discovered boot method (BCV) to be linked back to a device it will
> boot from. Nothing we can do to fix this except moving to EFI (an
> hope the problem is fixed there).
There is that option, or there could be some simple improvement of
our own, which works in QEMU and maybe even adds value to coreboot.
But then there would be a bit of novel development in firmware - that
can't be a good thing, right?
> Spec says that in that case user probably will want to adjust boot
> order anyway and will enter boot menu by itself. Sorry excuse for
> failing to provide proper functionality if you ask me :)
I agree. I can not believe the absolute resistance to innovation in
this field.
Isn't the scope of BBS logic limited to boot time? (There are calls
to do settings, but that's no problem.)
Maybe it would be possible for SeaBIOS to provide what looks like BBS
to the guest, but on the other side there is something more
intelligent going on, be it together with QEMU or coreboot?
//Peter
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
@ 2010-12-02 15:07 ` Peter Stuge
0 siblings, 0 replies; 136+ messages in thread
From: Peter Stuge @ 2010-12-02 15:07 UTC (permalink / raw)
To: Gleb Natapov; +Cc: Kevin O'Connor, seabios, qemu-devel, kvm
Gleb Natapov wrote:
> BBS specification is broken since it doesn't provide a way for
> discovered boot method (BCV) to be linked back to a device it will
> boot from. Nothing we can do to fix this except moving to EFI (an
> hope the problem is fixed there).
There is that option, or there could be some simple improvement of
our own, which works in QEMU and maybe even adds value to coreboot.
But then there would be a bit of novel development in firmware - that
can't be a good thing, right?
> Spec says that in that case user probably will want to adjust boot
> order anyway and will enter boot menu by itself. Sorry excuse for
> failing to provide proper functionality if you ask me :)
I agree. I can not believe the absolute resistance to innovation in
this field.
Isn't the scope of BBS logic limited to boot time? (There are calls
to do settings, but that's no problem.)
Maybe it would be possible for SeaBIOS to provide what looks like BBS
to the guest, but on the other side there is something more
intelligent going on, be it together with QEMU or coreboot?
//Peter
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
2010-12-02 15:07 ` [Qemu-devel] " Peter Stuge
@ 2010-12-02 17:13 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-12-02 17:13 UTC (permalink / raw)
To: Kevin O'Connor, seabios, qemu-devel, kvm
On Thu, Dec 02, 2010 at 04:07:16PM +0100, Peter Stuge wrote:
> Gleb Natapov wrote:
> > BBS specification is broken since it doesn't provide a way for
> > discovered boot method (BCV) to be linked back to a device it will
> > boot from. Nothing we can do to fix this except moving to EFI (an
> > hope the problem is fixed there).
>
> There is that option, or there could be some simple improvement of
> our own, which works in QEMU and maybe even adds value to coreboot.
> But then there would be a bit of novel development in firmware - that
> can't be a good thing, right?
>
I am all for novel development in firmware, but unfortunately I do not
see what can we do in Seabios + qemu to fix this shortcoming. The problem
should be fixed in each and every option rom. Option rom may set device
address somewhere in pnp header for instance.
>
> > Spec says that in that case user probably will want to adjust boot
> > order anyway and will enter boot menu by itself. Sorry excuse for
> > failing to provide proper functionality if you ask me :)
>
> I agree. I can not believe the absolute resistance to innovation in
> this field.
>
Interested parties want everyone to move to EFI I guess.
> Isn't the scope of BBS logic limited to boot time? (There are calls
> to do settings, but that's no problem.)
>
> Maybe it would be possible for SeaBIOS to provide what looks like BBS
> to the guest, but on the other side there is something more
> intelligent going on, be it together with QEMU or coreboot?
>
>
I don't how it can be done without cooperation with option roms.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
@ 2010-12-02 17:13 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-12-02 17:13 UTC (permalink / raw)
To: Kevin O'Connor, seabios, qemu-devel, kvm
On Thu, Dec 02, 2010 at 04:07:16PM +0100, Peter Stuge wrote:
> Gleb Natapov wrote:
> > BBS specification is broken since it doesn't provide a way for
> > discovered boot method (BCV) to be linked back to a device it will
> > boot from. Nothing we can do to fix this except moving to EFI (an
> > hope the problem is fixed there).
>
> There is that option, or there could be some simple improvement of
> our own, which works in QEMU and maybe even adds value to coreboot.
> But then there would be a bit of novel development in firmware - that
> can't be a good thing, right?
>
I am all for novel development in firmware, but unfortunately I do not
see what can we do in Seabios + qemu to fix this shortcoming. The problem
should be fixed in each and every option rom. Option rom may set device
address somewhere in pnp header for instance.
>
> > Spec says that in that case user probably will want to adjust boot
> > order anyway and will enter boot menu by itself. Sorry excuse for
> > failing to provide proper functionality if you ask me :)
>
> I agree. I can not believe the absolute resistance to innovation in
> this field.
>
Interested parties want everyone to move to EFI I guess.
> Isn't the scope of BBS logic limited to boot time? (There are calls
> to do settings, but that's no problem.)
>
> Maybe it would be possible for SeaBIOS to provide what looks like BBS
> to the guest, but on the other side there is something more
> intelligent going on, be it together with QEMU or coreboot?
>
>
I don't how it can be done without cooperation with option roms.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
2010-12-02 12:30 ` [Qemu-devel] " Gleb Natapov
@ 2010-12-02 21:22 ` Sebastian Herbszt
-1 siblings, 0 replies; 136+ messages in thread
From: Sebastian Herbszt @ 2010-12-02 21:22 UTC (permalink / raw)
To: Gleb Natapov, Kevin O'Connor; +Cc: seabios, qemu-devel, kvm
Gleb Natapov wrote:
> How can we get to EDD info after device is mapped? Looking at Seabios
> implementation it builds EDD table on the fly when int_1348 is called
> and it does it only for internal devices. Can we use "disconnect vector"
> to connect device temporarily get EDD and then disconnect?
>From BIOS Boot Specification 1.01
"6.4.2 Disconnect Vector
Originally, it was thought that the DV would be called by the BIOS if the device's
BCV was called and subsequent booting from the device failed. However, it was later
discovered that current PnP option ROMs are more well behaved by checking during
the BCV call if their device will properly respond to INT 13h calls or not, and simply
not hooking INT 13h if those calls would fail. Because of this, the DV is not called by
a BIOS supporting the BIOS Boot Specification, nor is it necessary to have a valid DV
in the PnP Expansion Header. The DV should be NULL and can't be used for other
storage."
Sebastian
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
@ 2010-12-02 21:22 ` Sebastian Herbszt
0 siblings, 0 replies; 136+ messages in thread
From: Sebastian Herbszt @ 2010-12-02 21:22 UTC (permalink / raw)
To: Gleb Natapov, Kevin O'Connor; +Cc: seabios, qemu-devel, kvm
Gleb Natapov wrote:
> How can we get to EDD info after device is mapped? Looking at Seabios
> implementation it builds EDD table on the fly when int_1348 is called
> and it does it only for internal devices. Can we use "disconnect vector"
> to connect device temporarily get EDD and then disconnect?
>From BIOS Boot Specification 1.01
"6.4.2 Disconnect Vector
Originally, it was thought that the DV would be called by the BIOS if the device's
BCV was called and subsequent booting from the device failed. However, it was later
discovered that current PnP option ROMs are more well behaved by checking during
the BCV call if their device will properly respond to INT 13h calls or not, and simply
not hooking INT 13h if those calls would fail. Because of this, the DV is not called by
a BIOS supporting the BIOS Boot Specification, nor is it necessary to have a valid DV
in the PnP Expansion Header. The DV should be NULL and can't be used for other
storage."
Sebastian
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-12-02 12:30 ` [Qemu-devel] " Gleb Natapov
@ 2010-12-03 2:01 ` Kevin O'Connor
-1 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-12-03 2:01 UTC (permalink / raw)
To: Gleb Natapov; +Cc: qemu-devel, kvm, seabios
On Thu, Dec 02, 2010 at 02:30:42PM +0200, Gleb Natapov wrote:
> On Wed, Dec 01, 2010 at 09:25:40PM -0500, Kevin O'Connor wrote:
> > You're thinking in terms of which device to boot, which does make this
> > difficult. However, it's equally valid to think in terms of which
> > boot method to invoke, which makes this easy.
> It is not. Because boot methods are enumerated by a guest at runtime.
> Qemu knows absolutely nothing about them. I am thinking in terms of
> devices because this is the only thing I have in qemu.
As before, a safe heuristic would be to request a rom boot for any
device with a pci rom that the user requests to boot from.
Note, your original proposal included a boot method:
/rom@genroms/linuxboot.bin
I'm asking to extend this to be able to include roms on PCI devices.
> > We could tell the coreboot user to edit the "bootorder" file and add
> > "/pci@i0cf8/rom1@4" (second rom on 4th pci device - the exact syntax
> > of the name is not important).
> >
> But how user should knows that second rom (I think you mean "second BCV")
> on pci device 4.0 will boot from the new scsi cdrom that he just connected?
> How can he tell that it should put second BCV there and not third or fifth
> without running Seabios first and looking at F12 menu?
Exactly - look at the F12 menu. (Or, for bonus points, one could
write a program that scans roms on the booted coreboot system,
presents the user with a menu, and then writes the requested boot
method to "bootorder".)
Being able to specify which boot method is a requirement for me. It
doesn't have to be pretty, but it does have to be possible.
> > >BTW to create proper EDD entry for SCSI boot device BIOS also
> > > needs too map BCV to id:lun. How it can be done?
> >
> > It's the responsibility of the rom to build the EDD info. I don't
> > know if all roms do this - I don't believe it's possible to get at the
> > EDD info until after the drive has been mapped (ie, too late to use it
> > for boot ordering).
> How can we get to EDD info after device is mapped?
Raise int 0x13 ah=0x48 - once the drive is mapped it will hook that
the 0x13 irq and handle the request (or jump to the bios handler for
drives it doesn't know about).
>Can we use "disconnect vector"
> to connect device temporarily get EDD and then disconnect?
No.
> > I understand. However, we'll still need to support arbitrary rom
> > based BEVs and BCVs, so the use case is still important.
> >
> We can't do something that is impossible.
You've used this word "impossible" a few times - I'm afraid I don't
know what it means.
>For coreboot Seabios should
> implement what BBS spec says i.e enumerate all BCVs, present boot menu
> to the user, record number of BCVs and user's choice on non-volatile
> storage (CMOS).
Bleh - there's no need for that. Much more reliable is to record the
device path for builtin devices or the boot method (device path of
rom, plus bev/bcv instance) for rom based boots.
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-12-03 2:01 ` Kevin O'Connor
0 siblings, 0 replies; 136+ messages in thread
From: Kevin O'Connor @ 2010-12-03 2:01 UTC (permalink / raw)
To: Gleb Natapov; +Cc: seabios, qemu-devel, kvm
On Thu, Dec 02, 2010 at 02:30:42PM +0200, Gleb Natapov wrote:
> On Wed, Dec 01, 2010 at 09:25:40PM -0500, Kevin O'Connor wrote:
> > You're thinking in terms of which device to boot, which does make this
> > difficult. However, it's equally valid to think in terms of which
> > boot method to invoke, which makes this easy.
> It is not. Because boot methods are enumerated by a guest at runtime.
> Qemu knows absolutely nothing about them. I am thinking in terms of
> devices because this is the only thing I have in qemu.
As before, a safe heuristic would be to request a rom boot for any
device with a pci rom that the user requests to boot from.
Note, your original proposal included a boot method:
/rom@genroms/linuxboot.bin
I'm asking to extend this to be able to include roms on PCI devices.
> > We could tell the coreboot user to edit the "bootorder" file and add
> > "/pci@i0cf8/rom1@4" (second rom on 4th pci device - the exact syntax
> > of the name is not important).
> >
> But how user should knows that second rom (I think you mean "second BCV")
> on pci device 4.0 will boot from the new scsi cdrom that he just connected?
> How can he tell that it should put second BCV there and not third or fifth
> without running Seabios first and looking at F12 menu?
Exactly - look at the F12 menu. (Or, for bonus points, one could
write a program that scans roms on the booted coreboot system,
presents the user with a menu, and then writes the requested boot
method to "bootorder".)
Being able to specify which boot method is a requirement for me. It
doesn't have to be pretty, but it does have to be possible.
> > >BTW to create proper EDD entry for SCSI boot device BIOS also
> > > needs too map BCV to id:lun. How it can be done?
> >
> > It's the responsibility of the rom to build the EDD info. I don't
> > know if all roms do this - I don't believe it's possible to get at the
> > EDD info until after the drive has been mapped (ie, too late to use it
> > for boot ordering).
> How can we get to EDD info after device is mapped?
Raise int 0x13 ah=0x48 - once the drive is mapped it will hook that
the 0x13 irq and handle the request (or jump to the bios handler for
drives it doesn't know about).
>Can we use "disconnect vector"
> to connect device temporarily get EDD and then disconnect?
No.
> > I understand. However, we'll still need to support arbitrary rom
> > based BEVs and BCVs, so the use case is still important.
> >
> We can't do something that is impossible.
You've used this word "impossible" a few times - I'm afraid I don't
know what it means.
>For coreboot Seabios should
> implement what BBS spec says i.e enumerate all BCVs, present boot menu
> to the user, record number of BCVs and user's choice on non-volatile
> storage (CMOS).
Bleh - there's no need for that. Much more reliable is to record the
device path for builtin devices or the boot method (device path of
rom, plus bev/bcv instance) for rom based boots.
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-12-03 2:01 ` [Qemu-devel] " Kevin O'Connor
@ 2010-12-03 5:55 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-12-03 5:55 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: qemu-devel, kvm, seabios
On Thu, Dec 02, 2010 at 09:01:25PM -0500, Kevin O'Connor wrote:
> On Thu, Dec 02, 2010 at 02:30:42PM +0200, Gleb Natapov wrote:
> > On Wed, Dec 01, 2010 at 09:25:40PM -0500, Kevin O'Connor wrote:
> > > You're thinking in terms of which device to boot, which does make this
> > > difficult. However, it's equally valid to think in terms of which
> > > boot method to invoke, which makes this easy.
> > It is not. Because boot methods are enumerated by a guest at runtime.
> > Qemu knows absolutely nothing about them. I am thinking in terms of
> > devices because this is the only thing I have in qemu.
>
> As before, a safe heuristic would be to request a rom boot for any
> device with a pci rom that the user requests to boot from.
>
> Note, your original proposal included a boot method:
> /rom@genroms/linuxboot.bin
> I'm asking to extend this to be able to include roms on PCI devices.
>
I already posted here code that maps PCI rom to PCI device path. Why do
you still insist on artificial path like /pci/rom@4?
> > > We could tell the coreboot user to edit the "bootorder" file and add
> > > "/pci@i0cf8/rom1@4" (second rom on 4th pci device - the exact syntax
> > > of the name is not important).
> > >
> > But how user should knows that second rom (I think you mean "second BCV")
> > on pci device 4.0 will boot from the new scsi cdrom that he just connected?
> > How can he tell that it should put second BCV there and not third or fifth
> > without running Seabios first and looking at F12 menu?
>
> Exactly - look at the F12 menu. (Or, for bonus points, one could
> write a program that scans roms on the booted coreboot system,
> presents the user with a menu, and then writes the requested boot
> method to "bootorder".)
>
If you propose that then you probably misunderstand the problem I am
trying to tackle. Qemu should be able to specify boot order for newly
created machine with arbitrary HW configuration without making user
to look at F12 menu. Actually at this point there is not human user
at all. All the process from machine creation till OS installation is
completely unattended. Looking at the BBS spec in several places they
say that if NV ram is corrupted bios should use some predefined default
boot order. This "predefined default boot order" is what qemu tries to
pass to Seabios to use correct boot device without user's input.
To make it clear "unattended" part is absolute requirement.
> Being able to specify which boot method is a requirement for me. It
> doesn't have to be pretty, but it does have to be possible.
For you problem solution is very easy and described in BBS spec. You
just need two numbers IPL to boot from and which BCV is first. No need
for device paths at all. In fact Seabios already tracks IPL order this
way the only thing missing is to track BCV order.
>
> > > >BTW to create proper EDD entry for SCSI boot device BIOS also
> > > > needs too map BCV to id:lun. How it can be done?
> > >
> > > It's the responsibility of the rom to build the EDD info. I don't
> > > know if all roms do this - I don't believe it's possible to get at the
> > > EDD info until after the drive has been mapped (ie, too late to use it
> > > for boot ordering).
> > How can we get to EDD info after device is mapped?
>
> Raise int 0x13 ah=0x48 - once the drive is mapped it will hook that
> the 0x13 irq and handle the request (or jump to the bios handler for
> drives it doesn't know about).
>
> >Can we use "disconnect vector"
> > to connect device temporarily get EDD and then disconnect?
>
> No.
>
And is it possible to call BCV and then restore int13 vector?
So to find out what device each BCV belongs too we do:
foreach(bcv)
call_bcv(bcv)
int 1348
restor(int13)
After that we call call_bcv(bcv) but in correct order.
> > > I understand. However, we'll still need to support arbitrary rom
> > > based BEVs and BCVs, so the use case is still important.
> > >
> > We can't do something that is impossible.
>
> You've used this word "impossible" a few times - I'm afraid I don't
> know what it means.
It means that I do not have a solution and you do not propose one either :)
It seems we were trying to solve differed problems though. I hope now it is
much more clear what I am trying to achieve with proposed bootorder
patches.
>
> >For coreboot Seabios should
> > implement what BBS spec says i.e enumerate all BCVs, present boot menu
> > to the user, record number of BCVs and user's choice on non-volatile
> > storage (CMOS).
>
> Bleh - there's no need for that. Much more reliable is to record the
> device path for builtin devices or the boot method (device path of
> rom, plus bev/bcv instance) for rom based boots.
>
Why is this much more reliable? Suppose user has scsi card with 3 devices
id3 id5 id6. Three BCVs was created for them and user chose to boot
from BCV3(id6). He added /pci/scsi@4/bcv@3 to his coreboot's bootorder
file. Now he adds one more device to this scsi bus with id1. On the next
boot 4 BCVs will be created and now id6 is bootable by BCV4 instead
BCV3. The result is unbootable system.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-12-03 5:55 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-12-03 5:55 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: seabios, qemu-devel, kvm
On Thu, Dec 02, 2010 at 09:01:25PM -0500, Kevin O'Connor wrote:
> On Thu, Dec 02, 2010 at 02:30:42PM +0200, Gleb Natapov wrote:
> > On Wed, Dec 01, 2010 at 09:25:40PM -0500, Kevin O'Connor wrote:
> > > You're thinking in terms of which device to boot, which does make this
> > > difficult. However, it's equally valid to think in terms of which
> > > boot method to invoke, which makes this easy.
> > It is not. Because boot methods are enumerated by a guest at runtime.
> > Qemu knows absolutely nothing about them. I am thinking in terms of
> > devices because this is the only thing I have in qemu.
>
> As before, a safe heuristic would be to request a rom boot for any
> device with a pci rom that the user requests to boot from.
>
> Note, your original proposal included a boot method:
> /rom@genroms/linuxboot.bin
> I'm asking to extend this to be able to include roms on PCI devices.
>
I already posted here code that maps PCI rom to PCI device path. Why do
you still insist on artificial path like /pci/rom@4?
> > > We could tell the coreboot user to edit the "bootorder" file and add
> > > "/pci@i0cf8/rom1@4" (second rom on 4th pci device - the exact syntax
> > > of the name is not important).
> > >
> > But how user should knows that second rom (I think you mean "second BCV")
> > on pci device 4.0 will boot from the new scsi cdrom that he just connected?
> > How can he tell that it should put second BCV there and not third or fifth
> > without running Seabios first and looking at F12 menu?
>
> Exactly - look at the F12 menu. (Or, for bonus points, one could
> write a program that scans roms on the booted coreboot system,
> presents the user with a menu, and then writes the requested boot
> method to "bootorder".)
>
If you propose that then you probably misunderstand the problem I am
trying to tackle. Qemu should be able to specify boot order for newly
created machine with arbitrary HW configuration without making user
to look at F12 menu. Actually at this point there is not human user
at all. All the process from machine creation till OS installation is
completely unattended. Looking at the BBS spec in several places they
say that if NV ram is corrupted bios should use some predefined default
boot order. This "predefined default boot order" is what qemu tries to
pass to Seabios to use correct boot device without user's input.
To make it clear "unattended" part is absolute requirement.
> Being able to specify which boot method is a requirement for me. It
> doesn't have to be pretty, but it does have to be possible.
For you problem solution is very easy and described in BBS spec. You
just need two numbers IPL to boot from and which BCV is first. No need
for device paths at all. In fact Seabios already tracks IPL order this
way the only thing missing is to track BCV order.
>
> > > >BTW to create proper EDD entry for SCSI boot device BIOS also
> > > > needs too map BCV to id:lun. How it can be done?
> > >
> > > It's the responsibility of the rom to build the EDD info. I don't
> > > know if all roms do this - I don't believe it's possible to get at the
> > > EDD info until after the drive has been mapped (ie, too late to use it
> > > for boot ordering).
> > How can we get to EDD info after device is mapped?
>
> Raise int 0x13 ah=0x48 - once the drive is mapped it will hook that
> the 0x13 irq and handle the request (or jump to the bios handler for
> drives it doesn't know about).
>
> >Can we use "disconnect vector"
> > to connect device temporarily get EDD and then disconnect?
>
> No.
>
And is it possible to call BCV and then restore int13 vector?
So to find out what device each BCV belongs too we do:
foreach(bcv)
call_bcv(bcv)
int 1348
restor(int13)
After that we call call_bcv(bcv) but in correct order.
> > > I understand. However, we'll still need to support arbitrary rom
> > > based BEVs and BCVs, so the use case is still important.
> > >
> > We can't do something that is impossible.
>
> You've used this word "impossible" a few times - I'm afraid I don't
> know what it means.
It means that I do not have a solution and you do not propose one either :)
It seems we were trying to solve differed problems though. I hope now it is
much more clear what I am trying to achieve with proposed bootorder
patches.
>
> >For coreboot Seabios should
> > implement what BBS spec says i.e enumerate all BCVs, present boot menu
> > to the user, record number of BCVs and user's choice on non-volatile
> > storage (CMOS).
>
> Bleh - there's no need for that. Much more reliable is to record the
> device path for builtin devices or the boot method (device path of
> rom, plus bev/bcv instance) for rom based boots.
>
Why is this much more reliable? Suppose user has scsi card with 3 devices
id3 id5 id6. Three BCVs was created for them and user chose to boot
from BCV3(id6). He added /pci/scsi@4/bcv@3 to his coreboot's bootorder
file. Now he adds one more device to this scsi bus with id1. On the next
boot 4 BCVs will be created and now id6 is bootable by BCV4 instead
BCV3. The result is unbootable system.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-28 17:15 ` [Qemu-devel] " Kevin O'Connor
@ 2010-11-29 10:50 ` Gerd Hoffmann
-1 siblings, 0 replies; 136+ messages in thread
From: Gerd Hoffmann @ 2010-11-29 10:50 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: Gleb Natapov, qemu-devel, kvm, seabios
Hi,
>> If scsi card has optionrom with only one bcv then Seabios can determine
>> its boot order from device path, so why not provide user with this
>> option today?
>
> It's unclear to me how SeaBIOS is supposed to do that.
Try to keep track of which bcv/bev belongs to which pci device? It
should surely work for devices supported by seabios natively. SeaBIOS
should also know which device's rom registered which entry. It might
become tricky though in case there are multiple identical devices are
present, say two e1000 cards, where the first rom could register entries
for both cards ...
> Maybe we can compromise here - if the user selects booting from a
> device, and qemu sees there is a rom for that device, then qemu can
> specify two boot options:
>
> /pci@i0cf8/ethernet@4/ethernet-phy@0
> /pci@i0cf8/rom@4
>
> SeaBIOS will ignore the first entry, and act on the second entry.
SeaBIOS should be able to operate just fine with the first entry.
"ethernet@4" means "the nic at bus address 4". As this is a PCI bus "4"
is the pci address. So SeaBIOS would just look what entries it has for
"00:04.0", run the rom, and ignore the "/ethernet-phy@0" part as it
can't handle it.
In case of scsi seabios can look at the next path element to figure the
scsi id. With native support it should be able to boot the correct disk
directly. When booting via rom it can either just pick the first entry
unconditionally (probably good enougth in 99% of the cases) or do some
guesswork based on the order the entries are registered.
> BTW, how are PCI locations specified in these paths? They should have
> a (bus, dev, fn) - your examples only seem to show dev. How are the
> other parts specified?
fn is optional for fn=0, IIRC the syntax is "$class@$dev,$fn".
Bus is specified via location in the tree, i.e. you'll see the bridge
for the secondary pci bus in the path, like this:
/pci@i0cf8/bridge@7/ethernet@3/...
(not sure it is actually named 'bridge' in the openfirmware specs though).
cheers,
Gerd
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-29 10:50 ` Gerd Hoffmann
0 siblings, 0 replies; 136+ messages in thread
From: Gerd Hoffmann @ 2010-11-29 10:50 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: seabios, qemu-devel, Gleb Natapov, kvm
Hi,
>> If scsi card has optionrom with only one bcv then Seabios can determine
>> its boot order from device path, so why not provide user with this
>> option today?
>
> It's unclear to me how SeaBIOS is supposed to do that.
Try to keep track of which bcv/bev belongs to which pci device? It
should surely work for devices supported by seabios natively. SeaBIOS
should also know which device's rom registered which entry. It might
become tricky though in case there are multiple identical devices are
present, say two e1000 cards, where the first rom could register entries
for both cards ...
> Maybe we can compromise here - if the user selects booting from a
> device, and qemu sees there is a rom for that device, then qemu can
> specify two boot options:
>
> /pci@i0cf8/ethernet@4/ethernet-phy@0
> /pci@i0cf8/rom@4
>
> SeaBIOS will ignore the first entry, and act on the second entry.
SeaBIOS should be able to operate just fine with the first entry.
"ethernet@4" means "the nic at bus address 4". As this is a PCI bus "4"
is the pci address. So SeaBIOS would just look what entries it has for
"00:04.0", run the rom, and ignore the "/ethernet-phy@0" part as it
can't handle it.
In case of scsi seabios can look at the next path element to figure the
scsi id. With native support it should be able to boot the correct disk
directly. When booting via rom it can either just pick the first entry
unconditionally (probably good enougth in 99% of the cases) or do some
guesswork based on the order the entries are registered.
> BTW, how are PCI locations specified in these paths? They should have
> a (bus, dev, fn) - your examples only seem to show dev. How are the
> other parts specified?
fn is optional for fn=0, IIRC the syntax is "$class@$dev,$fn".
Bus is specified via location in the tree, i.e. you'll see the bridge
for the secondary pci bus in the path, like this:
/pci@i0cf8/bridge@7/ethernet@3/...
(not sure it is actually named 'bridge' in the openfirmware specs though).
cheers,
Gerd
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-29 10:50 ` [Qemu-devel] " Gerd Hoffmann
(?)
@ 2010-11-30 1:55 ` Kevin O'Connor
2010-11-30 14:59 ` [Qemu-devel] " Gleb Natapov
-1 siblings, 1 reply; 136+ messages in thread
From: Kevin O'Connor @ 2010-11-30 1:55 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: Gleb Natapov, qemu-devel, kvm, seabios
On Mon, Nov 29, 2010 at 11:50:45AM +0100, Gerd Hoffmann wrote:
> >>If scsi card has optionrom with only one bcv then Seabios can determine
> >>its boot order from device path, so why not provide user with this
> >>option today?
> >It's unclear to me how SeaBIOS is supposed to do that.
> Try to keep track of which bcv/bev belongs to which pci device? It
> should surely work for devices supported by seabios natively.
No issues for any device with native support. I'm okay with the
proposed syntax.
> SeaBIOS should also know which device's rom registered which entry.
It doesn't today, but that shouldn't be an issue to add.
> It might become tricky though in case there are multiple identical
> devices are present, say two e1000 cards, where the first rom could
> register entries for both cards ...
Right - here's where things get complicated.
> >Maybe we can compromise here - if the user selects booting from a
> >device, and qemu sees there is a rom for that device, then qemu can
> >specify two boot options:
> >
> >/pci@i0cf8/ethernet@4/ethernet-phy@0
> >/pci@i0cf8/rom@4
> >
> >SeaBIOS will ignore the first entry, and act on the second entry.
>
> SeaBIOS should be able to operate just fine with the first entry.
> "ethernet@4" means "the nic at bus address 4". As this is a PCI bus
> "4" is the pci address. So SeaBIOS would just look what entries it
> has for "00:04.0", run the rom, and ignore the "/ethernet-phy@0"
> part as it can't handle it.
Right - I'm not happy about trying to parse out openbios device
descriptors though. The natural flow (as I see it) is for seabios to
find all the boot methods in the system and then see which ones have
been requested to be prioritized. Trying to do fuzzy matching of
found device to requested device just seems like an unnecessary pain
IMO.
>When booting via rom it can either just pick
> the first entry unconditionally (probably good enougth in 99% of the
> cases) or do some guesswork based on the order the entries are
> registered.
I guess that's the crux of the matter - I'd rather not do guessing in
the firmware. The emulator is in a much better position to do
heuristics and guessing - if nothing else, the emulator can allow the
user to pass it in on the command-line.
> >BTW, how are PCI locations specified in these paths? They should have
> >a (bus, dev, fn) - your examples only seem to show dev. How are the
> >other parts specified?
>
> fn is optional for fn=0, IIRC the syntax is "$class@$dev,$fn".
>
> Bus is specified via location in the tree, i.e. you'll see the
> bridge for the secondary pci bus in the path, like this:
>
> /pci@i0cf8/bridge@7/ethernet@3/...
>
> (not sure it is actually named 'bridge' in the openfirmware specs though).
Thanks.
-Kevin
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-30 1:55 ` Kevin O'Connor
@ 2010-11-30 14:59 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-30 14:59 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: Gerd Hoffmann, qemu-devel, kvm, seabios
On Mon, Nov 29, 2010 at 08:55:09PM -0500, Kevin O'Connor wrote:
> On Mon, Nov 29, 2010 at 11:50:45AM +0100, Gerd Hoffmann wrote:
> > >>If scsi card has optionrom with only one bcv then Seabios can determine
> > >>its boot order from device path, so why not provide user with this
> > >>option today?
> > >It's unclear to me how SeaBIOS is supposed to do that.
> > Try to keep track of which bcv/bev belongs to which pci device? It
> > should surely work for devices supported by seabios natively.
>
> No issues for any device with native support. I'm okay with the
> proposed syntax.
>
> > SeaBIOS should also know which device's rom registered which entry.
>
> It doesn't today, but that shouldn't be an issue to add.
>
> > It might become tricky though in case there are multiple identical
> > devices are present, say two e1000 cards, where the first rom could
> > register entries for both cards ...
>
> Right - here's where things get complicated.
>
I don't see how it can be solved at all given that bev->productname
doesn't have any structure so it can't be parsed back to device's pci
address.
> > >Maybe we can compromise here - if the user selects booting from a
> > >device, and qemu sees there is a rom for that device, then qemu can
> > >specify two boot options:
> > >
> > >/pci@i0cf8/ethernet@4/ethernet-phy@0
> > >/pci@i0cf8/rom@4
> > >
> > >SeaBIOS will ignore the first entry, and act on the second entry.
> >
> > SeaBIOS should be able to operate just fine with the first entry.
> > "ethernet@4" means "the nic at bus address 4". As this is a PCI bus
> > "4" is the pci address. So SeaBIOS would just look what entries it
> > has for "00:04.0", run the rom, and ignore the "/ethernet-phy@0"
> > part as it can't handle it.
>
> Right - I'm not happy about trying to parse out openbios device
> descriptors though. The natural flow (as I see it) is for seabios to
> find all the boot methods in the system and then see which ones have
> been requested to be prioritized. Trying to do fuzzy matching of
> found device to requested device just seems like an unnecessary pain
> IMO.
>
> >When booting via rom it can either just pick
> > the first entry unconditionally (probably good enougth in 99% of the
> > cases) or do some guesswork based on the order the entries are
> > registered.
>
> I guess that's the crux of the matter - I'd rather not do guessing in
> the firmware. The emulator is in a much better position to do
> heuristics and guessing - if nothing else, the emulator can allow the
> user to pass it in on the command-line.
>
Actually Seabios is in a much better position to do this heuristics
since only at runtime all IPLs are knows. What heuristics you think
emulator can implement?
> > >BTW, how are PCI locations specified in these paths? They should have
> > >a (bus, dev, fn) - your examples only seem to show dev. How are the
> > >other parts specified?
> >
> > fn is optional for fn=0, IIRC the syntax is "$class@$dev,$fn".
> >
> > Bus is specified via location in the tree, i.e. you'll see the
> > bridge for the secondary pci bus in the path, like this:
> >
> > /pci@i0cf8/bridge@7/ethernet@3/...
> >
> > (not sure it is actually named 'bridge' in the openfirmware specs though).
>
> Thanks.
>
> -Kevin
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-30 14:59 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-30 14:59 UTC (permalink / raw)
To: Kevin O'Connor; +Cc: seabios, Gerd Hoffmann, kvm, qemu-devel
On Mon, Nov 29, 2010 at 08:55:09PM -0500, Kevin O'Connor wrote:
> On Mon, Nov 29, 2010 at 11:50:45AM +0100, Gerd Hoffmann wrote:
> > >>If scsi card has optionrom with only one bcv then Seabios can determine
> > >>its boot order from device path, so why not provide user with this
> > >>option today?
> > >It's unclear to me how SeaBIOS is supposed to do that.
> > Try to keep track of which bcv/bev belongs to which pci device? It
> > should surely work for devices supported by seabios natively.
>
> No issues for any device with native support. I'm okay with the
> proposed syntax.
>
> > SeaBIOS should also know which device's rom registered which entry.
>
> It doesn't today, but that shouldn't be an issue to add.
>
> > It might become tricky though in case there are multiple identical
> > devices are present, say two e1000 cards, where the first rom could
> > register entries for both cards ...
>
> Right - here's where things get complicated.
>
I don't see how it can be solved at all given that bev->productname
doesn't have any structure so it can't be parsed back to device's pci
address.
> > >Maybe we can compromise here - if the user selects booting from a
> > >device, and qemu sees there is a rom for that device, then qemu can
> > >specify two boot options:
> > >
> > >/pci@i0cf8/ethernet@4/ethernet-phy@0
> > >/pci@i0cf8/rom@4
> > >
> > >SeaBIOS will ignore the first entry, and act on the second entry.
> >
> > SeaBIOS should be able to operate just fine with the first entry.
> > "ethernet@4" means "the nic at bus address 4". As this is a PCI bus
> > "4" is the pci address. So SeaBIOS would just look what entries it
> > has for "00:04.0", run the rom, and ignore the "/ethernet-phy@0"
> > part as it can't handle it.
>
> Right - I'm not happy about trying to parse out openbios device
> descriptors though. The natural flow (as I see it) is for seabios to
> find all the boot methods in the system and then see which ones have
> been requested to be prioritized. Trying to do fuzzy matching of
> found device to requested device just seems like an unnecessary pain
> IMO.
>
> >When booting via rom it can either just pick
> > the first entry unconditionally (probably good enougth in 99% of the
> > cases) or do some guesswork based on the order the entries are
> > registered.
>
> I guess that's the crux of the matter - I'd rather not do guessing in
> the firmware. The emulator is in a much better position to do
> heuristics and guessing - if nothing else, the emulator can allow the
> user to pass it in on the command-line.
>
Actually Seabios is in a much better position to do this heuristics
since only at runtime all IPLs are knows. What heuristics you think
emulator can implement?
> > >BTW, how are PCI locations specified in these paths? They should have
> > >a (bus, dev, fn) - your examples only seem to show dev. How are the
> > >other parts specified?
> >
> > fn is optional for fn=0, IIRC the syntax is "$class@$dev,$fn".
> >
> > Bus is specified via location in the tree, i.e. you'll see the
> > bridge for the secondary pci bus in the path, like this:
> >
> > /pci@i0cf8/bridge@7/ethernet@3/...
> >
> > (not sure it is actually named 'bridge' in the openfirmware specs though).
>
> Thanks.
>
> -Kevin
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
2010-11-28 7:45 ` [Qemu-devel] " Gleb Natapov
@ 2010-11-28 19:00 ` Peter Stuge
-1 siblings, 0 replies; 136+ messages in thread
From: Peter Stuge @ 2010-11-28 19:00 UTC (permalink / raw)
To: seabios, qemu-devel, kvm
Gleb Natapov wrote:
> There is no way for qemu to know about BCVs or BEVs
This is very much the key point.
In order to have command line control over the boot process, the
machine and the firmware must agree on things.
I see two options:
1. QEMU works very very hard to provide a machine that will result in
a particular BBS program flow in firmware, in the end resulting in
the desired device being used for booting - as long as QEMU and the
firmware happen to have the same understanding of the BBS.
2. QEMU passes boot instructions to the firmware based on immediate,
common, structured data.
The first option seems disgusting to me, because it has many
drawbacks and no benefits.
The second option requires inventing something that goes beyond the
established BIOS standards, maybe a reason for it to see fierce
resistance, but it is the only thing that makes sense.
Specifying boot device using PCI BDF is a great example of using
common structured data. That BDF exists both in machine and firmware
data models. The scope of BBS is limited to the firmware, so it is
not really practical for creating consistency in a dynamic machine.
//Peter
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
@ 2010-11-28 19:00 ` Peter Stuge
0 siblings, 0 replies; 136+ messages in thread
From: Peter Stuge @ 2010-11-28 19:00 UTC (permalink / raw)
To: seabios, qemu-devel, kvm
Gleb Natapov wrote:
> There is no way for qemu to know about BCVs or BEVs
This is very much the key point.
In order to have command line control over the boot process, the
machine and the firmware must agree on things.
I see two options:
1. QEMU works very very hard to provide a machine that will result in
a particular BBS program flow in firmware, in the end resulting in
the desired device being used for booting - as long as QEMU and the
firmware happen to have the same understanding of the BBS.
2. QEMU passes boot instructions to the firmware based on immediate,
common, structured data.
The first option seems disgusting to me, because it has many
drawbacks and no benefits.
The second option requires inventing something that goes beyond the
established BIOS standards, maybe a reason for it to see fierce
resistance, but it is the only thing that makes sense.
Specifying boot device using PCI BDF is a great example of using
common structured data. That BDF exists both in machine and firmware
data models. The scope of BBS is limited to the firmware, so it is
not really practical for creating consistency in a dynamic machine.
//Peter
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
2010-11-28 19:00 ` [Qemu-devel] " Peter Stuge
@ 2010-11-28 19:11 ` Peter Stuge
-1 siblings, 0 replies; 136+ messages in thread
From: Peter Stuge @ 2010-11-28 19:11 UTC (permalink / raw)
To: seabios, qemu-devel, kvm
Peter Stuge wrote:
> Specifying boot device using PCI BDF is a great example of using
> common structured data. That BDF exists both in machine and firmware
> data models.
Gleb Natapov wrote:
> Bus numbers are assigned by a guest. Qemu knows nothing about them,
> so it specify device path by topology.
Quite. By BDF I of course mean topology. ;)
The BDF itself is not much better than a BBS concept, since only the
firmware knows the details.
But the topology is common, even if bus number differs between
machine and firmware.
How is the topology structured? I'm not sure that firmware can use a
"slot" number. Device number on the bus works, is that what you mean?
//Peter
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
@ 2010-11-28 19:11 ` Peter Stuge
0 siblings, 0 replies; 136+ messages in thread
From: Peter Stuge @ 2010-11-28 19:11 UTC (permalink / raw)
To: seabios, qemu-devel, kvm
Peter Stuge wrote:
> Specifying boot device using PCI BDF is a great example of using
> common structured data. That BDF exists both in machine and firmware
> data models.
Gleb Natapov wrote:
> Bus numbers are assigned by a guest. Qemu knows nothing about them,
> so it specify device path by topology.
Quite. By BDF I of course mean topology. ;)
The BDF itself is not much better than a BBS concept, since only the
firmware knows the details.
But the topology is common, even if bus number differs between
machine and firmware.
How is the topology structured? I'm not sure that firmware can use a
"slot" number. Device number on the bus works, is that what you mean?
//Peter
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
2010-11-28 19:11 ` [Qemu-devel] " Peter Stuge
@ 2010-11-28 19:52 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 19:52 UTC (permalink / raw)
To: seabios, qemu-devel, kvm
On Sun, Nov 28, 2010 at 08:11:45PM +0100, Peter Stuge wrote:
> Peter Stuge wrote:
> > Specifying boot device using PCI BDF is a great example of using
> > common structured data. That BDF exists both in machine and firmware
> > data models.
>
> Gleb Natapov wrote:
> > Bus numbers are assigned by a guest. Qemu knows nothing about them,
> > so it specify device path by topology.
>
> Quite. By BDF I of course mean topology. ;)
>
Ah, then we are in violent agreement :)
> The BDF itself is not much better than a BBS concept, since only the
> firmware knows the details.
>
Yeap.
> But the topology is common, even if bus number differs between
> machine and firmware.
>
Correct.
> How is the topology structured? I'm not sure that firmware can use a
> "slot" number. Device number on the bus works, is that what you mean?
>
To specify device path to PCI card using topology one needs to specify
slot.fn of all pci-to-pci buses from pci host controller to pci device
in question.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
@ 2010-11-28 19:52 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 19:52 UTC (permalink / raw)
To: seabios, qemu-devel, kvm
On Sun, Nov 28, 2010 at 08:11:45PM +0100, Peter Stuge wrote:
> Peter Stuge wrote:
> > Specifying boot device using PCI BDF is a great example of using
> > common structured data. That BDF exists both in machine and firmware
> > data models.
>
> Gleb Natapov wrote:
> > Bus numbers are assigned by a guest. Qemu knows nothing about them,
> > so it specify device path by topology.
>
> Quite. By BDF I of course mean topology. ;)
>
Ah, then we are in violent agreement :)
> The BDF itself is not much better than a BBS concept, since only the
> firmware knows the details.
>
Yeap.
> But the topology is common, even if bus number differs between
> machine and firmware.
>
Correct.
> How is the topology structured? I'm not sure that firmware can use a
> "slot" number. Device number on the bus works, is that what you mean?
>
To specify device path to PCI card using topology one needs to specify
slot.fn of all pci-to-pci buses from pci host controller to pci device
in question.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
2010-11-28 19:00 ` [Qemu-devel] " Peter Stuge
@ 2010-11-28 19:16 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 19:16 UTC (permalink / raw)
To: seabios, qemu-devel, kvm
On Sun, Nov 28, 2010 at 08:00:29PM +0100, Peter Stuge wrote:
> Gleb Natapov wrote:
> > There is no way for qemu to know about BCVs or BEVs
>
> This is very much the key point.
>
> In order to have command line control over the boot process, the
> machine and the firmware must agree on things.
>
> I see two options:
>
> 1. QEMU works very very hard to provide a machine that will result in
> a particular BBS program flow in firmware, in the end resulting in
> the desired device being used for booting - as long as QEMU and the
> firmware happen to have the same understanding of the BBS.
>
Since qemu knows nothing about BCVs and BEVs it can't implement 1 since
it can't know what BBS flow will look like in Seabios.
> 2. QEMU passes boot instructions to the firmware based on immediate,
> common, structured data.
What is this "immediate, common, structured data"? This is the crux of
the problem really.
>
> The first option seems disgusting to me, because it has many
> drawbacks and no benefits.
>
> The second option requires inventing something that goes beyond the
> established BIOS standards, maybe a reason for it to see fierce
> resistance, but it is the only thing that makes sense.
>
> Specifying boot device using PCI BDF is a great example of using
> common structured data. That BDF exists both in machine and firmware
> data models. The scope of BBS is limited to the firmware, so it is
> not really practical for creating consistency in a dynamic machine.
>
B from BDF does not exists in machine data model.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
@ 2010-11-28 19:16 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-28 19:16 UTC (permalink / raw)
To: seabios, qemu-devel, kvm
On Sun, Nov 28, 2010 at 08:00:29PM +0100, Peter Stuge wrote:
> Gleb Natapov wrote:
> > There is no way for qemu to know about BCVs or BEVs
>
> This is very much the key point.
>
> In order to have command line control over the boot process, the
> machine and the firmware must agree on things.
>
> I see two options:
>
> 1. QEMU works very very hard to provide a machine that will result in
> a particular BBS program flow in firmware, in the end resulting in
> the desired device being used for booting - as long as QEMU and the
> firmware happen to have the same understanding of the BBS.
>
Since qemu knows nothing about BCVs and BEVs it can't implement 1 since
it can't know what BBS flow will look like in Seabios.
> 2. QEMU passes boot instructions to the firmware based on immediate,
> common, structured data.
What is this "immediate, common, structured data"? This is the crux of
the problem really.
>
> The first option seems disgusting to me, because it has many
> drawbacks and no benefits.
>
> The second option requires inventing something that goes beyond the
> established BIOS standards, maybe a reason for it to see fierce
> resistance, but it is the only thing that makes sense.
>
> Specifying boot device using PCI BDF is a great example of using
> common structured data. That BDF exists both in machine and firmware
> data models. The scope of BBS is limited to the firmware, so it is
> not really practical for creating consistency in a dynamic machine.
>
B from BDF does not exists in machine data model.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-27 18:40 ` [Qemu-devel] " Kevin O'Connor
@ 2010-11-29 10:19 ` Gerd Hoffmann
-1 siblings, 0 replies; 136+ messages in thread
From: Gerd Hoffmann @ 2010-11-29 10:19 UTC (permalink / raw)
To: Kevin O'Connor
Cc: Gleb Natapov, qemu-devel, kvm, blauwirbel, armbru,
alex.williamson, mst, Anthony Liguori
Hi,
>> BTW are you actually aware of any option rom with multiple BCVs and, if
>> yes, how those BCVs differ?
>
> Multiple BCVs - yes. A SCSI card will define a BCV for each attached
> drive. I don't have a scsi card myself, but the support was added by
> a user who ran into the problem first hand.
FYI: You can test with a virtual card ;)
lsi emulation in recent qemu versions is good enougth that the original
boot rom runs. You can fetch it here:
http://www.lsi.com/DistributionSystem/AssetDocument/files/support/ssp/sdms/Bios/lsi_bios.zip
qemu -drive if=scsi,file=$image -option-rom 8xx_64.rom
Gives you a list like this ...
Press F12 for boot menu.
Select boot device:
1. AHCI/0: QEMU HARDDISK ATA-7 Hard-Disk (8192 MiBytes)
2. #20 ID00 LUN0 QEMU QEMU HARD
3. #20 ID01 LUN0 QEMU QEMU HARD
4. DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
5. DVD/CD [AHCI/2: QEMU DVD-ROM ATAPI-4 DVD/CD]
6. gPXE (PCI 00:03.0)
... where entries 2+3 are created by the scsi rom.
HTH,
Gerd
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-29 10:19 ` Gerd Hoffmann
0 siblings, 0 replies; 136+ messages in thread
From: Gerd Hoffmann @ 2010-11-29 10:19 UTC (permalink / raw)
To: Kevin O'Connor
Cc: Anthony Liguori, kvm, Gleb Natapov, mst, armbru, qemu-devel,
blauwirbel, alex.williamson
Hi,
>> BTW are you actually aware of any option rom with multiple BCVs and, if
>> yes, how those BCVs differ?
>
> Multiple BCVs - yes. A SCSI card will define a BCV for each attached
> drive. I don't have a scsi card myself, but the support was added by
> a user who ran into the problem first hand.
FYI: You can test with a virtual card ;)
lsi emulation in recent qemu versions is good enougth that the original
boot rom runs. You can fetch it here:
http://www.lsi.com/DistributionSystem/AssetDocument/files/support/ssp/sdms/Bios/lsi_bios.zip
qemu -drive if=scsi,file=$image -option-rom 8xx_64.rom
Gives you a list like this ...
Press F12 for boot menu.
Select boot device:
1. AHCI/0: QEMU HARDDISK ATA-7 Hard-Disk (8192 MiBytes)
2. #20 ID00 LUN0 QEMU QEMU HARD
3. #20 ID01 LUN0 QEMU QEMU HARD
4. DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
5. DVD/CD [AHCI/2: QEMU DVD-ROM ATAPI-4 DVD/CD]
6. gPXE (PCI 00:03.0)
... where entries 2+3 are created by the scsi rom.
HTH,
Gerd
^ permalink raw reply [flat|nested] 136+ messages in thread
* Re: [PATCHv6 00/16] boot order specification
2010-11-29 10:19 ` [Qemu-devel] " Gerd Hoffmann
@ 2010-11-29 12:07 ` Gleb Natapov
-1 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-29 12:07 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Kevin O'Connor, qemu-devel, kvm, blauwirbel, armbru,
alex.williamson, mst, Anthony Liguori
On Mon, Nov 29, 2010 at 11:19:29AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> >>BTW are you actually aware of any option rom with multiple BCVs and, if
> >>yes, how those BCVs differ?
> >
> >Multiple BCVs - yes. A SCSI card will define a BCV for each attached
> >drive. I don't have a scsi card myself, but the support was added by
> >a user who ran into the problem first hand.
>
> FYI: You can test with a virtual card ;)
>
> lsi emulation in recent qemu versions is good enougth that the
> original boot rom runs. You can fetch it here:
>
> http://www.lsi.com/DistributionSystem/AssetDocument/files/support/ssp/sdms/Bios/lsi_bios.zip
>
> qemu -drive if=scsi,file=$image -option-rom 8xx_64.rom
>
> Gives you a list like this ...
>
> Press F12 for boot menu.
>
> Select boot device:
>
> 1. AHCI/0: QEMU HARDDISK ATA-7 Hard-Disk (8192 MiBytes)
> 2. #20 ID00 LUN0 QEMU QEMU HARD
> 3. #20 ID01 LUN0 QEMU QEMU HARD
> 4. DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
> 5. DVD/CD [AHCI/2: QEMU DVD-ROM ATAPI-4 DVD/CD]
> 6. gPXE (PCI 00:03.0)
>
> ... where entries 2+3 are created by the scsi rom.
>
Thanks! If BCVs created by optionrom are always sorted by target we can
even determine what BCV correspond to which device path.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread
* [Qemu-devel] Re: [PATCHv6 00/16] boot order specification
@ 2010-11-29 12:07 ` Gleb Natapov
0 siblings, 0 replies; 136+ messages in thread
From: Gleb Natapov @ 2010-11-29 12:07 UTC (permalink / raw)
To: Gerd Hoffmann
Cc: Anthony Liguori, kvm, mst, qemu-devel, armbru, blauwirbel,
alex.williamson, Kevin O'Connor
On Mon, Nov 29, 2010 at 11:19:29AM +0100, Gerd Hoffmann wrote:
> Hi,
>
> >>BTW are you actually aware of any option rom with multiple BCVs and, if
> >>yes, how those BCVs differ?
> >
> >Multiple BCVs - yes. A SCSI card will define a BCV for each attached
> >drive. I don't have a scsi card myself, but the support was added by
> >a user who ran into the problem first hand.
>
> FYI: You can test with a virtual card ;)
>
> lsi emulation in recent qemu versions is good enougth that the
> original boot rom runs. You can fetch it here:
>
> http://www.lsi.com/DistributionSystem/AssetDocument/files/support/ssp/sdms/Bios/lsi_bios.zip
>
> qemu -drive if=scsi,file=$image -option-rom 8xx_64.rom
>
> Gives you a list like this ...
>
> Press F12 for boot menu.
>
> Select boot device:
>
> 1. AHCI/0: QEMU HARDDISK ATA-7 Hard-Disk (8192 MiBytes)
> 2. #20 ID00 LUN0 QEMU QEMU HARD
> 3. #20 ID01 LUN0 QEMU QEMU HARD
> 4. DVD/CD [ata1-0: QEMU DVD-ROM ATAPI-4 DVD/CD]
> 5. DVD/CD [AHCI/2: QEMU DVD-ROM ATAPI-4 DVD/CD]
> 6. gPXE (PCI 00:03.0)
>
> ... where entries 2+3 are created by the scsi rom.
>
Thanks! If BCVs created by optionrom are always sorted by target we can
even determine what BCV correspond to which device path.
--
Gleb.
^ permalink raw reply [flat|nested] 136+ messages in thread