Re: [Qemu-devel] [PATCH] Ensure PCIR is aligned to 4 bytes
Andreas Färber wrote: Same for http://patchwork.ozlabs.org/patch/273758/ - vgabios seems to be falling through the cracks... Andreas Is this patch still required? I was under the impression that no patch is needed for Win 8 after reading the thread on SeaBIOS list. Sebastian
Re: [Qemu-devel] [PATCH] Ensure PCIR is aligned to 4 bytes
Brad Smith wrote: On 19/09/13 12:53 PM, Sebastian Herbszt wrote: Brad Smith wrote: On 20/01/13 1:12 PM, David Woodhouse wrote: The PCI Firmware Specification apparently requires that the PCI Data Structure be DWORD-aligned. The implementation in OVMF also requires this, so vgabios ROMs don't work there. With this fixed, I can now initialise the VGA ROM from EFI, and EFI can display using INT 10h services. --- vgabios-0.6c/vgabios.c.orig 2013-01-20 11:33:36.138548472 -0600 +++ vgabios-0.6c/vgabios.c 2013-01-20 11:36:26.060270163 -0600 @@ -204,6 +204,7 @@ vgabios_website: .byte0x00 #ifdef PCIBIOS +.align 4 // DWORD alignment required by PCI Firmware Specification vgabios_pci_data: .ascii PCIR #ifdef CIRRUS We have had this in the OpenBSD port of QEMU for awhile now. Is it possible to have this reviewed and commited? This change was commited to upstream vgabios back in February [1]. But that has not resulted in it being brought into QEMU. Gerd, Anthony, care to update QEMU's vgabios repository [1] with changes from upstream CVS repository [2]? [1] http://git.qemu.org/?p=vgabios.git [2] http://cvs.savannah.gnu.org/viewvc/?root=vgabios Sebastian
Re: [Qemu-devel] [PATCH] Ensure PCIR is aligned to 4 bytes
Brad Smith wrote: On 20/01/13 1:12 PM, David Woodhouse wrote: The PCI Firmware Specification apparently requires that the PCI Data Structure be DWORD-aligned. The implementation in OVMF also requires this, so vgabios ROMs don't work there. With this fixed, I can now initialise the VGA ROM from EFI, and EFI can display using INT 10h services. --- vgabios-0.6c/vgabios.c.orig 2013-01-20 11:33:36.138548472 -0600 +++ vgabios-0.6c/vgabios.c 2013-01-20 11:36:26.060270163 -0600 @@ -204,6 +204,7 @@ vgabios_website: .byte 0x00 #ifdef PCIBIOS +.align 4 // DWORD alignment required by PCI Firmware Specification vgabios_pci_data: .ascii PCIR #ifdef CIRRUS We have had this in the OpenBSD port of QEMU for awhile now. Is it possible to have this reviewed and commited? This change was commited to upstream vgabios back in February [1]. [1] http://cvs.savannah.gnu.org/viewvc/vgabios/vgabios.c?root=vgabiosview=log Sebastian
Re: [Qemu-devel] APM regression since v1.3.0-408-g9ee59f3
Gerd Hoffmann wrote: On 07/03/13 22:25, Sebastian Herbszt wrote: Commit 9ee59f3 (pc: remove bochs bios debug ports) broke the APM interface between QEMU and Bochs BIOS/SeaBIOS. Without APM support older guests are no longer able to power off the VM. This regression also affects older machine types like pc-1.2. --verbose please. Which guest? Which firmware? The guest is syslinux. Its poweroff module [1] uses the APM interface. I'am also no longer able to power off linux (2.6.20) with acpi=off. Firmware is SeaBIOS 1.7.2. ACPI poweroff with seabios works just fine. If APM support in seabios uses something else it should be switched to use the same hardware ports ACPI uses for poweroff (some piix4 pm device register I think) instead of the debug ports which where never meant to be used that way. SeaBIOS uses the same QEMU / BIOS interface as Bochs BIOS (port 0x8900). This interface was removed by commit 9ee59f3. Does bochs bios run on recent qemu versions in the first place? Last time I checked it did, but recent is relative. [1] http://www.syslinux.org/archives/2013-July/020367.html Sebastian
[Qemu-devel] APM regression since v1.3.0-408-g9ee59f3
Commit 9ee59f3 (pc: remove bochs bios debug ports) broke the APM interface between QEMU and Bochs BIOS/SeaBIOS. Without APM support older guests are no longer able to power off the VM. This regression also affects older machine types like pc-1.2. Sebastian
Re: [Qemu-devel] [PATCH] Init win32 CRITICAL_SECTION before starting thread; crash when attaching disks
Stefan Weil wrote: Tested-by: Stefan Weil s...@weilnetz.de Hi Bogdan, I can confirm that your patch fixes a crash which otherwise makes QEMU unusable on Windows hosts. This patch likely fixes bug #922131 [1]. [1] https://bugs.launchpad.net/qemu/+bug/922131 Sebastian
[Qemu-devel] [PATCH V2] Make python mandatory
Make python mandatory. Signed-off-by: Sebastian Herbszt herb...@gmx.de --- configure | 10 +++--- 1 files changed, 3 insertions(+), 7 deletions(-) diff --git a/configure b/configure index 640e815..a54439d 100755 --- a/configure +++ b/configure @@ -1185,13 +1185,9 @@ if test $solaris = yes ; then fi fi -if test $guest_agent != no ; then - if has $python; then -: - else -echo Python not found. Use --python=/path/to/python -exit 1 - fi +if ! has $python; then + echo Python not found. Use --python=/path/to/python + exit 1 fi if test -z $target_list ; then -- 1.7.3.4
Re: [Qemu-devel] Compiling without python?
Sebastian Herbszt wrote: Is it still possible to compile without python? python /v1.0-267-gda5361c/scripts/qapi-commands.py -m -o . /bin/sh: python: command not found make: *** [qmp-commands.h] Error 127 Sebastian Care to answer? Thanks, Sebastian
[Qemu-devel] Subject: [PATCH] Make python mandatory
Make python mandatory. Signed-off-by: Sebastian Herbszt herb...@gmx.de --- configure | 12 +--- 1 files changed, 5 insertions(+), 7 deletions(-) diff --git a/configure b/configure index 640e815..6c2a1b4 100755 --- a/configure +++ b/configure @@ -1185,13 +1185,11 @@ if test $solaris = yes ; then fi fi -if test $guest_agent != no ; then - if has $python; then -: - else -echo Python not found. Use --python=/path/to/python -exit 1 - fi +if has $python; then + : +else + echo Python not found. Use --python=/path/to/python + exit 1 fi if test -z $target_list ; then -- 1.7.3.4
Re: [Qemu-devel] Subject: [PATCH] Make python mandatory
Peter Maydell wrote: On 30 December 2011 23:59, Sebastian Herbszt herb...@gmx.de wrote: Make python mandatory. +if has $python; then + : +else + echo Python not found. Use --python=/path/to/python + exit 1 fi if test -z $target_list ; then I know you've just removed the outer condition here, but while we're fiddling with it, wouldn't if ! has $python; then echo Python not found etc fi be better? -- PMM I just restored it to the state it was before commit guest agent: add --enable-guest-agent config option. This check was added in commit Let users select their pythons. Sebastian
[Qemu-devel] Compiling without python?
Is it still possible to compile without python? python /v1.0-267-gda5361c/scripts/qapi-commands.py -m -o . /bin/sh: python: command not found make: *** [qmp-commands.h] Error 127 Sebastian
[Qemu-devel] coroutine-win32.c:36: error: thread-local storage not supported for this target
CCcoroutine-win32.o coroutine-win32.c:36: error: thread-local storage not supported for this target coroutine-win32.c:37: error: thread-local storage not supported for this target make: *** [coroutine-win32.o] Error 1 Sebastian
Re: [Qemu-devel] coroutine-win32.c:36: error: thread-local storage not supported for this target
Paolo Bonzini wrote: On 08/09/2011 05:53 PM, Sebastian Herbszt wrote: CC coroutine-win32.o coroutine-win32.c:36: error: thread-local storage not supported for this target coroutine-win32.c:37: error: thread-local storage not supported for this target make: *** [coroutine-win32.o] Error 1 You need a newer GCC. Alternatively we can change it to use TlsAlloc/TlsFree, but I would like to support __thread-based TLS always (for example for liburcu---userspace RCU...). Paolo I guess gcc version 3.4.5 (mingw32 special) is no longer supported then? What's the minimum gcc version needed now? Sebastian
Re: [Qemu-devel] [SeaBIOS] SeaBIOS error with Juniper FreeBSD kernel
Kevin O'Connor wrote: I investigated this a bit and I believe the Juniper OS has two SMBIOS bugs: it crashes when the table is in high memory, and when searching Are all versions based on FreeBSD 4.11? Are newer versions still affected? So, moving the SMBIOS back to the f-segment would fix this. But, there's an issue with that. The SMBIOS table is normally pretty small (eg, 263 bytes), but it increases with the amount of ram and number of CPUs. If one starts QEmu with 255 cpus, the SMBIOS size is over 11K. Fitting that into the f-segment (64K shared with all the other 16bit code and data) is going to be a real problem. This is also an issue for the mptable (which is over 5K at 255 cpus), but newer OSes don't care about mptable - not so for the smbios table though. You might want to introduce CONFIG_SMBIOS_LOCATION and check for space shortage in the F-segment case. Bochs BIOS panics if all requested tables don't fit into the available space. Sebastian
[Qemu-devel] Re: [PATCH] piix: use pci_config_set_prog_interface()
Michael S. Tsirkin wrote:
On Tue, Dec 28, 2010 at 07:48:23PM +0100, Sebastian Herbszt wrote:
Michael S. Tsirkin wrote:
On Tue, Dec 28, 2010 at 05:24:06PM +0100, Sebastian Herbszt wrote:
Michael S. Tsirkin wrote:
On Mon, Dec 20, 2010 at 10:18:01PM +0100, Sebastian Herbszt wrote:
Use pci_config_set_prog_interface().
Signed-off-by: Sebastian Herbszt herb...@gmx.de
Since I was asked explicitly - I don't have a problem
with these changes: both class and prog interface.
However, they aren't all that useful in themselves.
For class, what I would like to see is a system where
the device class is put in the qdev info table,
and where -device ?
(and hopefully the legacy -help, -nic etc as well)
use this information.
I am not sure if you mean something like the patch below.
Not exactly
- I'd like to keep the pci_config_set_class in the devices,
just make it do an assert.
Assert on which condition?
That PCI class matches device type defined in qdev.
This will serve to verify that all devices are converted properly.
- Nics already have DEFINE_NIC_PROPERTIES - can this be used somehow?
Same for other devices ...
We got DEFINE_NIC_PROPERTIES and DEFINE_BLOCK_PROPERTIES.
Something like DEFINE_PCI_PROPERTIES could be introduced, but i am not sure
This shouldn't have to do anything with PCI.
We should define the device type as NIC,
PCI class can be derived from that.
So you want to introduce a device property like device_type and set it to
NIC and
then translate NIC to the correct PCI class code. Are you sure this is
unambiguous?
NIC could be ethernet or token ring. A generic name like HBA could
translate to even
more codes (scsi, ide, raid, sata, ...).
which device properties it should hold (vendor_id, device_id, class, etc?).
Those will then be user-modifiable with e.g. -device e1000,pci_class=1234.
Sebastian
Why is this helpful?
- tweaking class will just break guests
- binary representation is unfriendly, let's not require users to read
pci spec just to run qemu.
pci_class is optional. I just wanted to show that qdev device properties are
user-modifiable and i didn't find a way to prevent this.
I can imagine some useful features implemented by sticking the type in qdev:
- -device ? would sort devices by type and print the type,
- something like this for qtree etc
- -help would get all e.g. nic models from qdev,
- allow easy to remember aliases with per-type scope (e.g.
-device virtio,type=nic to be equivalent to -device virtio-net-pci)
Is this just a virtio problem?
- filter (for device ?, qtree etc) system devices that user has no business
tweaking (could be type=system or something like that)
diff --git a/hw/e1000.c b/hw/e1000.c
index af101bd..e302703 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -1171,6 +1171,7 @@ static PCIDeviceInfo e1000_info = {
.romfile= pxe-e1000.bin,
.qdev.props = (Property[]) {
DEFINE_NIC_PROPERTIES(E1000State, conf),
+DEFINE_PROP_UINT16(pci_class, E1000State, dev.class,
PCI_CLASS_NETWORK_ETHERNET),
DEFINE_PROP_END_OF_LIST(),
}
};
diff --git a/hw/pci.c b/hw/pci.c
index ef00d20..06bbf04 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1620,6 +1620,9 @@ static int pci_qdev_init(DeviceState *qdev, DeviceInfo
*base)
info-is_bridge);
if (pci_dev == NULL)
return -1;
+
+pci_config_set_class(pci_dev-config, pci_dev-class);
+
rc = info-init(pci_dev);
if (rc != 0) {
do_pci_unregister_device(pci_dev);
diff --git a/hw/pci.h b/hw/pci.h
index 17744dc..5dc9053 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -189,6 +189,9 @@ struct PCIDevice {
char *romfile;
ram_addr_t rom_offset;
uint32_t rom_bar;
+
+/* class */
Please don't copy code into comments verbatim.
+uint16_t class;
Ugh. We have class in config already.
But i could not get qdev to use it.
};
PCIDevice *pci_register_device(PCIBus *bus, const char *name,
Sebastian
[Qemu-devel] Re: [PATCH] piix: use pci_config_set_prog_interface()
Michael S. Tsirkin wrote:
On Mon, Dec 20, 2010 at 10:18:01PM +0100, Sebastian Herbszt wrote:
Use pci_config_set_prog_interface().
Signed-off-by: Sebastian Herbszt herb...@gmx.de
Since I was asked explicitly - I don't have a problem
with these changes: both class and prog interface.
However, they aren't all that useful in themselves.
For class, what I would like to see is a system where
the device class is put in the qdev info table,
and where -device ?
(and hopefully the legacy -help, -nic etc as well)
use this information.
I am not sure if you mean something like the patch below.
pci_config_set_prog_interface can then have an assert to
verify that value.
Maybe we can even make e.g. -device nic work.
In a similar way, pci_config_set_prog_interface
would really become useful if we put the handling
for the legacy classes in a central place
(e.g. pci_class.c)
Which are legacy classes?
Any chance of doing something like the above?
I'd be happy to apply such patches.
Sebastian
diff --git a/hw/e1000.c b/hw/e1000.c
index af101bd..88ace8f 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -1117,7 +1117,6 @@ static int pci_e1000_init(PCIDevice *pci_dev)
/* TODO: we have no capabilities, so why is this bit set? */
pci_set_word(pci_conf + PCI_STATUS, PCI_STATUS_CAP_LIST);
pci_conf[PCI_REVISION_ID] = 0x03;
-pci_config_set_class(pci_conf, PCI_CLASS_NETWORK_ETHERNET);
/* TODO: RST# value should be 0, PCI spec 6.2.4 */
pci_conf[PCI_CACHE_LINE_SIZE] = 0x10;
@@ -1169,6 +1168,7 @@ static PCIDeviceInfo e1000_info = {
.init = pci_e1000_init,
.exit = pci_e1000_uninit,
.romfile= pxe-e1000.bin,
+.class = PCI_CLASS_NETWORK_ETHERNET,
.qdev.props = (Property[]) {
DEFINE_NIC_PROPERTIES(E1000State, conf),
DEFINE_PROP_END_OF_LIST(),
diff --git a/hw/pci.c b/hw/pci.c
index ef00d20..de0038c 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1620,6 +1620,11 @@ static int pci_qdev_init(DeviceState *qdev, DeviceInfo
*base)
info-is_bridge);
if (pci_dev == NULL)
return -1;
+
+if (info-class) {
+pci_config_set_class(pci_dev-config, info-class);
+}
+
rc = info-init(pci_dev);
if (rc != 0) {
do_pci_unregister_device(pci_dev);
diff --git a/hw/pci.h b/hw/pci.h
index 17744dc..29b9280 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -436,6 +436,9 @@ typedef struct {
/* rom bar */
const char *romfile;
+
+/* class */
+uint16_t class;
} PCIDeviceInfo;
void pci_qdev_register(PCIDeviceInfo *info);
[Qemu-devel] Re: [PATCH] piix: use pci_config_set_prog_interface()
Michael S. Tsirkin wrote:
On Tue, Dec 28, 2010 at 05:24:06PM +0100, Sebastian Herbszt wrote:
Michael S. Tsirkin wrote:
On Mon, Dec 20, 2010 at 10:18:01PM +0100, Sebastian Herbszt wrote:
Use pci_config_set_prog_interface().
Signed-off-by: Sebastian Herbszt herb...@gmx.de
Since I was asked explicitly - I don't have a problem
with these changes: both class and prog interface.
However, they aren't all that useful in themselves.
For class, what I would like to see is a system where
the device class is put in the qdev info table,
and where -device ?
(and hopefully the legacy -help, -nic etc as well)
use this information.
I am not sure if you mean something like the patch below.
Not exactly
- I'd like to keep the pci_config_set_class in the devices,
just make it do an assert.
Assert on which condition?
- Nics already have DEFINE_NIC_PROPERTIES - can this be used somehow?
Same for other devices ...
We got DEFINE_NIC_PROPERTIES and DEFINE_BLOCK_PROPERTIES.
Something like DEFINE_PCI_PROPERTIES could be introduced, but i am not sure
which device properties it should hold (vendor_id, device_id, class, etc?).
Those will then be user-modifiable with e.g. -device e1000,pci_class=1234.
Sebastian
diff --git a/hw/e1000.c b/hw/e1000.c
index af101bd..e302703 100644
--- a/hw/e1000.c
+++ b/hw/e1000.c
@@ -1171,6 +1171,7 @@ static PCIDeviceInfo e1000_info = {
.romfile= pxe-e1000.bin,
.qdev.props = (Property[]) {
DEFINE_NIC_PROPERTIES(E1000State, conf),
+DEFINE_PROP_UINT16(pci_class, E1000State, dev.class,
PCI_CLASS_NETWORK_ETHERNET),
DEFINE_PROP_END_OF_LIST(),
}
};
diff --git a/hw/pci.c b/hw/pci.c
index ef00d20..06bbf04 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -1620,6 +1620,9 @@ static int pci_qdev_init(DeviceState *qdev, DeviceInfo
*base)
info-is_bridge);
if (pci_dev == NULL)
return -1;
+
+pci_config_set_class(pci_dev-config, pci_dev-class);
+
rc = info-init(pci_dev);
if (rc != 0) {
do_pci_unregister_device(pci_dev);
diff --git a/hw/pci.h b/hw/pci.h
index 17744dc..5dc9053 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -189,6 +189,9 @@ struct PCIDevice {
char *romfile;
ram_addr_t rom_offset;
uint32_t rom_bar;
+
+/* class */
+uint16_t class;
};
PCIDevice *pci_register_device(PCIBus *bus, const char *name,
Re: [Qemu-devel] [PATCH 1/8] ahci: split ICH9 from core
Alexander Graf wrote: Am 23.12.2010 um 09:23 schrieb Stefan Hajnoczi stefa...@gmail.com: On Mon, Dec 20, 2010 at 9:13 PM, Alexander Graf ag...@suse.de wrote: From: Sebastian Herbszt herb...@gmx.de There are multiple ahci devices out there. The currently implemented ich-9 is only one of the many. So let's split that one out into a separate file to stress the difference. Signed-off-by: Sebastian Herbszt herb...@gmx.de Signed-off-by: Alexander Graf ag...@suse.de --- Makefile.objs |1 + hw/ide/ahci.c | 305 +--- hw/ide/ahci.h | 309 + hw/ide/ich.c | 61 +++ 4 files changed, 375 insertions(+), 301 deletions(-) create mode 100644 hw/ide/ahci.h create mode 100644 hw/ide/ich.c Do you want to add copyright headers on the new files? That's what patch 2 does :) Alex, feel free to merge patch 1 and 2 if it's more reasonable. Sebastian
[Qemu-devel] [PATCH] xio3130: use pci_config_set_revision()
Use pci_config_set_revision(). Signed-off-by: Sebastian Herbszt herb...@gmx.de diff --git a/hw/xio3130_downstream.c b/hw/xio3130_downstream.c index 1a2d258..fe16475 100644 --- a/hw/xio3130_downstream.c +++ b/hw/xio3130_downstream.c @@ -71,7 +71,7 @@ static int xio3130_downstream_initfn(PCIDevice *d) pcie_port_init_reg(d); pci_config_set_vendor_id(d-config, PCI_VENDOR_ID_TI); pci_config_set_device_id(d-config, PCI_DEVICE_ID_TI_XIO3130D); -d-config[PCI_REVISION_ID] = XIO3130_REVISION; +pci_config_set_revision(d-config, XIO3130_REVISION); rc = msi_init(d, XIO3130_MSI_OFFSET, XIO3130_MSI_NR_VECTOR, XIO3130_MSI_SUPPORTED_FLAGS PCI_MSI_FLAGS_64BIT, diff --git a/hw/xio3130_upstream.c b/hw/xio3130_upstream.c index 387bf6c..bd2b452 100644 --- a/hw/xio3130_upstream.c +++ b/hw/xio3130_upstream.c @@ -67,7 +67,7 @@ static int xio3130_upstream_initfn(PCIDevice *d) pcie_port_init_reg(d); pci_config_set_vendor_id(d-config, PCI_VENDOR_ID_TI); pci_config_set_device_id(d-config, PCI_DEVICE_ID_TI_XIO3130U); -d-config[PCI_REVISION_ID] = XIO3130_REVISION; +pci_config_set_revision(d-config, XIO3130_REVISION); rc = msi_init(d, XIO3130_MSI_OFFSET, XIO3130_MSI_NR_VECTOR, XIO3130_MSI_SUPPORTED_FLAGS PCI_MSI_FLAGS_64BIT,
[Qemu-devel] [PATCH] ioh3420: use pci_config_set_revision()
Use pci_config_set_revision(). Signed-off-by: Sebastian Herbszt herb...@gmx.de diff --git a/hw/ioh3420.c b/hw/ioh3420.c index 95adf09..25ed2eb 100644 --- a/hw/ioh3420.c +++ b/hw/ioh3420.c @@ -104,7 +104,7 @@ static int ioh3420_initfn(PCIDevice *d) return rc; } -d-config[PCI_REVISION_ID] = PCI_DEVICE_ID_IOH_REV; +pci_config_set_revision(d-config, PCI_DEVICE_ID_IOH_REV); pcie_port_init_reg(d); pci_config_set_vendor_id(d-config, PCI_VENDOR_ID_INTEL);
[Qemu-devel] [PATCH] dec_pci: use pci_config_set_revision()
Use pci_config_set_revision(). Signed-off-by: Sebastian Herbszt herb...@gmx.de diff --git a/hw/dec_pci.c b/hw/dec_pci.c index bf88f2a..75dd373 100644 --- a/hw/dec_pci.c +++ b/hw/dec_pci.c @@ -110,7 +110,7 @@ static int dec_21154_pci_host_init(PCIDevice *d) /* PCI2PCI bridge same values as PearPC - check this */ pci_config_set_vendor_id(d-config, PCI_VENDOR_ID_DEC); pci_config_set_device_id(d-config, PCI_DEVICE_ID_DEC_21154); -pci_set_byte(d-config + PCI_REVISION_ID, 0x02); +pci_config_set_revision(d-config, 0x02); pci_config_set_class(d-config, PCI_CLASS_BRIDGE_PCI); return 0; }
[Qemu-devel] [PATCH] apb_pci: use pci_config_set_revision()
Use pci_config_set_revision(). Signed-off-by: Sebastian Herbszt herb...@gmx.de diff --git a/hw/apb_pci.c b/hw/apb_pci.c index 84e9af7..97b3032 100644 --- a/hw/apb_pci.c +++ b/hw/apb_pci.c @@ -321,7 +321,7 @@ static int apb_pci_bridge_initfn(PCIDevice *dev) pci_set_word(dev-config + PCI_STATUS, PCI_STATUS_FAST_BACK | PCI_STATUS_66MHZ | PCI_STATUS_DEVSEL_MEDIUM); -pci_set_byte(dev-config + PCI_REVISION_ID, 0x11); +pci_config_set_revision(dev-config, 0x11); return 0; }
[Qemu-devel] [PATCH] piix: use pci_config_set_prog_interface()
Use pci_config_set_prog_interface().
Signed-off-by: Sebastian Herbszt herb...@gmx.de
diff --git a/hw/ide/piix.c b/hw/ide/piix.c
index 1cad906..2772e08 100644
--- a/hw/ide/piix.c
+++ b/hw/ide/piix.c
@@ -135,7 +135,7 @@ static int pci_piix_ide_initfn(PCIIDEState *d)
{
uint8_t *pci_conf = d-dev.config;
-pci_conf[PCI_CLASS_PROG] = 0x80; // legacy ATA mode
+pci_config_set_prog_interface(pci_conf, 0x80); // legacy ATA mode
pci_config_set_class(pci_conf, PCI_CLASS_STORAGE_IDE);
qemu_register_reset(piix3_reset, d);
[Qemu-devel] [PATCH] cmd646: use pci_config_set_prog_interface()
Use pci_config_set_prog_interface(). Signed-off-by: Sebastian Herbszt herb...@gmx.de diff --git a/hw/ide/cmd646.c b/hw/ide/cmd646.c index 5d5464a..e125dfc 100644 --- a/hw/ide/cmd646.c +++ b/hw/ide/cmd646.c @@ -230,7 +230,7 @@ static int pci_cmd646_ide_initfn(PCIDevice *dev) pci_config_set_device_id(pci_conf, PCI_DEVICE_ID_CMD_646); pci_conf[PCI_REVISION_ID] = 0x07; // IDE controller revision -pci_conf[PCI_CLASS_PROG] = 0x8f; +pci_config_set_prog_interface(pci_conf, 0x8f); pci_config_set_class(pci_conf, PCI_CLASS_STORAGE_IDE);
[Qemu-devel] [PATCH] rtl8139: use pci_config_set_revision()
Use pci_config_set_revision(). Signed-off-by: Sebastian Herbszt herb...@gmx.de diff --git a/hw/rtl8139.c b/hw/rtl8139.c index a8aed89..6407ce0 100644 --- a/hw/rtl8139.c +++ b/hw/rtl8139.c @@ -3346,7 +3346,7 @@ static int pci_rtl8139_init(PCIDevice *dev) pci_conf = s-dev.config; pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_REALTEK); pci_config_set_device_id(pci_conf, PCI_DEVICE_ID_REALTEK_8139); -pci_conf[PCI_REVISION_ID] = RTL8139_PCI_REVID; /* =0x20 is for 8139C+ */ +pci_config_set_revision(pci_conf, RTL8139_PCI_REVID); /* =0x20 is for 8139C+ */ pci_config_set_class(pci_conf, PCI_CLASS_NETWORK_ETHERNET); pci_conf[PCI_INTERRUPT_PIN] = 1;/* interrupt pin 0 */ /* TODO: start of capability list, but no capability
[Qemu-devel] [PATCH] pcnet-pci: use pci_config_set_revision()
Use pci_config_set_revision(). Signed-off-by: Sebastian Herbszt herb...@gmx.de diff --git a/hw/pcnet-pci.c b/hw/pcnet-pci.c index 339a401..c9811e2 100644 --- a/hw/pcnet-pci.c +++ b/hw/pcnet-pci.c @@ -282,7 +282,7 @@ static int pci_pcnet_init(PCIDevice *pci_dev) pci_config_set_device_id(pci_conf, PCI_DEVICE_ID_AMD_LANCE); pci_set_word(pci_conf + PCI_STATUS, PCI_STATUS_FAST_BACK | PCI_STATUS_DEVSEL_MEDIUM); -pci_conf[PCI_REVISION_ID] = 0x10; +pci_config_set_revision(pci_conf, 0x10); pci_config_set_class(pci_conf, PCI_CLASS_NETWORK_ETHERNET); pci_set_word(pci_conf + PCI_SUBSYSTEM_VENDOR_ID, 0x0);
[Qemu-devel] [PATCH] e1000: use pci_config_set_revision()
Use pci_config_set_revision(). Signed-off-by: Sebastian Herbszt herb...@gmx.de diff --git a/hw/e1000.c b/hw/e1000.c index af101bd..7bad51a 100644 --- a/hw/e1000.c +++ b/hw/e1000.c @@ -1116,7 +1116,7 @@ static int pci_e1000_init(PCIDevice *pci_dev) pci_config_set_device_id(pci_conf, E1000_DEVID); /* TODO: we have no capabilities, so why is this bit set? */ pci_set_word(pci_conf + PCI_STATUS, PCI_STATUS_CAP_LIST); -pci_conf[PCI_REVISION_ID] = 0x03; +pci_config_set_revision(pci_conf, 0x03); pci_config_set_class(pci_conf, PCI_CLASS_NETWORK_ETHERNET); /* TODO: RST# value should be 0, PCI spec 6.2.4 */ pci_conf[PCI_CACHE_LINE_SIZE] = 0x10;
[Qemu-devel] [PATCH] usb-uhci: use pci_config_set_revision()
Use pci_config_set_revision(). Signed-off-by: Sebastian Herbszt herb...@gmx.de diff --git a/hw/usb-uhci.c b/hw/usb-uhci.c index b9b822f..5b3bf21 100644 --- a/hw/usb-uhci.c +++ b/hw/usb-uhci.c @@ -1106,7 +1106,7 @@ static int usb_uhci_common_initfn(UHCIState *s) uint8_t *pci_conf = s-dev.config; int i; -pci_conf[PCI_REVISION_ID] = 0x01; // revision number +pci_config_set_revision(pci_conf, 0x01); // revision number pci_conf[PCI_CLASS_PROG] = 0x00; pci_config_set_class(pci_conf, PCI_CLASS_SERIAL_USB); /* TODO: reset value should be 0. */
[Qemu-devel] Re: [SeaBIOS] [PATCHv6 00/16] boot order specification
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
[Qemu-devel] Re: [PATCH 14/15] megasas: LSI Megaraid SAS emulation
Hannes Reinecke wrote:
+static int megasas_scsi_init(PCIDevice *dev)
+{
+MPTState *s = DO_UPCAST(MPTState, dev, dev);
+uint8_t *pci_conf;
+int i;
+
+pci_conf = s-dev.config;
+
+/* PCI Vendor ID (word) */
+pci_config_set_vendor_id(pci_conf, PCI_VENDOR_ID_LSI_LOGIC);
+/* PCI device ID (word) */
+pci_config_set_device_id(pci_conf, PCI_DEVICE_ID_LSI_SAS1078);
+/* PCI subsystem ID */
+pci_set_word(pci_conf[PCI_SUBSYSTEM_VENDOR_ID], 0x1000);
PCI_VENDOR_ID_LSI_LOGIC
+pci_set_word(pci_conf[PCI_SUBSYSTEM_ID], 0x1013);
What is 0x1013?
+/* PCI base class code */
+pci_config_set_class(pci_conf, PCI_CLASS_STORAGE_RAID);
+
+/* PCI latency timer = 0 */
+pci_conf[0x0d] = 0;
PCI_LATENCY_TIMER
+/* Interrupt pin 1 */
+pci_conf[0x3d] = 0x01;
pci_config_set_interrupt_pin()
Sebastian
Re: [SeaBIOS] [Qemu-devel] [RFC] Passing boot order from qemu to seabios
H. Peter Anvin wrote: On 10/11/2010 01:30 PM, Anthony Liguori wrote: On 10/11/2010 02:59 PM, Gleb Natapov wrote: No boot rom should do that. extboot wreaks havoc when it is used. And since virtio is now supported by bios there is no reason to use it. You don't really have a choice. You could be doing hardware passthrough and the ROM on the card may hijack int19. The BBS standard actually documents how to deal with that -- it pretty much works out to let the card initialize, then see if it mucked with int19, and then put int19 back... if we want to run that card, then we invoke the int19 that the card set up. The BIOS Boot Specification, Version 1.01 from January 11, 1996 seems not to recommend this: 3.4 Legacy IPL Devices Legacy IPL devices will be allowed to take control of the system (via hooking interrupts) in both Legacy and PnP systems. The Plug and Play BIOS specification recommends that Legacy devices that hook a bootstrap interrupt such as INT 19h, 18h, or 13h have the interrupt re-captured by the BIOS. This is not done because grabbing an interrupt vector back after a device has hooked it can produce unpredictable results. Further, by allowing the card to take control, the behavior of these Legacy cards will be the same on both PnP and Legacy machines. 6.8 Notes on the POST Process The Plug and Play BIOS Specification says that if a Legacy IPL device's option ROM captures INT 18h or INT 19h, the BIOS should save this vector and then restore the original one put there by the BIOS. The BIOS Boot Specification deviates from this in that these vectors are not recaptured after each Legacy option ROM returns from initialization. That would be considered unsafe. Sebastian
[Qemu-devel] Re: [SeaBIOS] SMBIOS strings
Kevin O'Connor wrote: On Tue, Jun 01, 2010 at 10:26:12PM +0200, Sebastian Herbszt wrote: Jes Sorensen wrote: Handle 0x0401, DMI type 4, 32 bytes Processor Information - Socket Designation: CPU 1 + Socket Designation: CPU01 smbios.c got snprintf((char*)start, 6, CPU%2x, cpu_number); It should print CPU 1 instead of CPU01 because the padding should be done with spaces not zeros. Maybe bvprintf() doesn't handle it correctly? Space padding hasn't been implemented - nothing needed it. With correct space padding this would be a non issue, because the socket designation string would not have changed. Sebastian The bvprintf code is called from 16bit code which is very stack sensitive - if space padding is implemented it will have to be tested carefully. -Kevin
[Qemu-devel] Re: [SeaBIOS] SMBIOS strings
Jes Sorensen wrote: On 06/01/10 22:26, Sebastian Herbszt wrote: Jes Sorensen wrote: Handle 0x0401, DMI type 4, 32 bytes Processor Information - Socket Designation: CPU 1 + Socket Designation: CPU01 smbios.c got snprintf((char*)start, 6, CPU%2x, cpu_number); It should print CPU 1 instead of CPU01 because the padding should be done with spaces not zeros. Maybe bvprintf() doesn't handle it correctly? I looked at the man page for snprintf() and it isn't clear to me that it is required to space pad when printing hex numbers. The flag characters ... 0 The value should be zero padded. For d, i, o, u, x, X, a, A, e, E, f, F, g, and G conversions, the converted value is padded on the left with zeros rather than blanks. If the 0 and - flags both appear, the 0 flag is ignored. If a precision is given with a numeric conversion (d, i, o, u, x, and X), the 0 flag is ignored. For other conversions, the behavior is undefined. [1] So without 0 flag it should be space padded. Having looked at the other pieces, I think this is probably the only one we might want to change. It should be pretty easy to just do something like: if (cpu_number 0x10) snprintf(CPU %x, cpu_number); else snprintf(CPU%2x, cpu_number); Esthetically I think this would be prettier, but question is whether it's something to worry about or not. Either change it here or fix bvprintf(). Also CPU a looks a bit weird. Maybe change it to CPU A (upper case letter) ? Cheers, Jes [1] http://linux.die.net/man/3/printf Sebastian
[Qemu-devel] [PATCH] ahci: drop ATA_CMD constants
Drop ATA_CMD constants and use constants from ide/internal.h.
Signed-off-by: Sebastian Herbszt herb...@gmx.de
diff --git a/hw/ahci.c b/hw/ahci.c
index 9987459..b4eafdf 100644
--- a/hw/ahci.c
+++ b/hw/ahci.c
@@ -153,33 +153,6 @@ do { fprintf(stderr,ahci: fmt , ## __VA_ARGS__); }
while (0)
#define STATE_RESET 1
/*
- * ATA Commands (only mandatory commands listed here)
- */
-#define ATA_CMD_READ 0x20/* Read Sectors (with retries) */
-#define ATA_CMD_READN 0x21/* Read Sectors ( no retries) */
-#define ATA_CMD_WRITE 0x30/* Write Sectores (with retries)*/
-#define ATA_CMD_WRITEN 0x31/* Write Sectors ( no retries)*/
-#define ATA_CMD_VRFY 0x40/* Read Verify (with retries) */
-#define ATA_CMD_VRFYN 0x41/* Read verify ( no retries) */
-#define ATA_CMD_SEEK 0x70/* Seek */
-#define ATA_CMD_DIAG 0x90/* Execute Device Diagnostic*/
-#define ATA_CMD_INIT 0x91/* Initialize Device Parameters */
-#define ATA_CMD_RD_MULT0xC4/* Read Multiple*/
-#define ATA_CMD_WR_MULT0xC5/* Write Multiple */
-#define ATA_CMD_SETMULT0xC6/* Set Multiple Mode*/
-#define ATA_CMD_RD_DMA 0xC8/* Read DMA (with retries) */
-#define ATA_CMD_RD_DMAN0xC9/* Read DMS ( no retries) */
-#define ATA_CMD_WR_DMA 0xCA/* Write DMA (with retries) */
-#define ATA_CMD_WR_DMAN0xCB/* Write DMA ( no retires) */
-#define ATA_CMD_IDENT 0xEC/* Identify Device */
-#define ATA_CMD_SETF 0xEF/* Set Features */
-#define ATA_CMD_CHK_PWR0xE5/* Check Power Mode */
-
-#define ATA_CMD_READ_EXT 0x24 /* Read Sectors (with retries) with 48bit
addressing */
-#define ATA_CMD_WRITE_EXT 0x34/* Write Sectores (with retries) with
48bit addressing */
-#define ATA_CMD_VRFY_EXT 0x42/* Read Verify (with retries) with
48bit addressing */
-
-/*
* ATAPI Commands
*/
#define ATAPI_CMD_IDENT 0xA1 /* Identify AT Atachment Packed Interface Device
*/
@@ -1067,7 +1040,7 @@ static void handle_cmd(AHCIState *s,int port,int slot)
pr-irq_stat |= (12);
break;
- case ATA_CMD_IDENT:
+ case WIN_IDENTIFY:
ide_identify(ide_state);
write_to_sglist(ide_state-identify_data,
sizeof(ide_state-identify_data),s-prdt_buf,prdt_num);
pr-irq_stat |= (12);
@@ -1091,7 +1064,7 @@ static void handle_cmd(AHCIState *s,int port,int slot)
case WIN_SETFEATURES:
pr-irq_stat |= (12);
break;
- case ATA_CMD_RD_DMA:
+ case WIN_READDMA:
sector_num=(((int64_t)fis[10])40)|(((int64_t)fis[9])32)|(fis[8]24)|(fis[6]16)|(fis[5]8)|fis[4];
nb_sectors=(fis[13]8)|fis[12];
if(!nb_sectors)nb_sectors=256;
@@ -1103,7 +1076,7 @@ static void handle_cmd(AHCIState *s,int port,int slot)
}
pr-irq_stat |= (12);
break;
- case ATA_CMD_WR_DMA:
+ case WIN_WRITEDMA:
sector_num=(((int64_t)fis[10])40)|(((int64_t)fis[9])32)|(fis[8]24)|(fis[6]16)|(fis[5]8)|fis[4];
nb_sectors=(fis[13]8)|fis[12];
if(!nb_sectors)nb_sectors=256;
[Qemu-devel] Re: [SeaBIOS] SMBIOS strings
Jes Sorensen wrote: Handle 0x0401, DMI type 4, 32 bytes Processor Information - Socket Designation: CPU 1 + Socket Designation: CPU01 smbios.c got snprintf((char*)start, 6, CPU%2x, cpu_number); It should print CPU 1 instead of CPU01 because the padding should be done with spaces not zeros. Maybe bvprintf() doesn't handle it correctly? Sebastian
[Qemu-devel] [PATCH] ahci: drop board_ahci constants
Drop not used board_ahci constants.
Signed-off-by: Sebastian Herbszt herb...@gmx.de
diff --git a/hw/ahci.c b/hw/ahci.c
index 3476cea..4090def 100644
--- a/hw/ahci.c
+++ b/hw/ahci.c
@@ -65,12 +65,6 @@ do { fprintf(stderr,ahci: fmt , ## __VA_ARGS__); } while
(0)
#define RX_FIS_SDB0x58 /* offset of SDB FIS data */
#define RX_FIS_UNK0x60 /* offset of Unknown FIS data */
-#define board_ahci0
-#define board_ahci_pi 1
-#define board_ahci_vt8251 2
-#define board_ahci_ign_iferr 3
-#define board_ahci_sb600 4
-
/* global controller registers */
#define HOST_CAP 0x00 /* host capabilities */
#define HOST_CTL 0x04 /* global host control */
[Qemu-devel] Re: [Qemu-ahci-devel] [PATCH] ahci: drop board_ahci constants
Alexander Graf wrote:
On 31.05.2010, at 22:12, Sebastian Herbszt wrote:
Drop not used board_ahci constants.
Signed-off-by: Sebastian Herbszt herb...@gmx.de
diff --git a/hw/ahci.c b/hw/ahci.c
index 3476cea..4090def 100644
--- a/hw/ahci.c
+++ b/hw/ahci.c
@@ -65,12 +65,6 @@ do { fprintf(stderr,ahci: fmt , ## __VA_ARGS__); } while
(0)
#define RX_FIS_SDB0x58 /* offset of SDB FIS data */
#define RX_FIS_UNK0x60 /* offset of Unknown FIS data */
-#define board_ahci0
-#define board_ahci_pi 1
-#define board_ahci_vt8251 2
-#define board_ahci_ign_iferr 3
-#define board_ahci_sb600 4
-
They weren't used before? Why are they there at all then?
Alex
Copy and paste from the linux kernel (ahci.c/h)?
Sebastian
[Qemu-devel] Re: [SeaBIOS] SMBIOS strings
Gleb Natapov wrote: I don't care much as long as we will not have CPU :. It looks like something that can change after BIOS upgrade, so it is hard to believe Windows will stop working because of this change. Maybe it could trigger the Windows activation process? Sebastian
[Qemu-devel] [PATCH] ahci: drop ATAPI_CMD constants
Drop not used ATAPI_CMD constants.
Signed-off-by: Sebastian Herbszt herb...@gmx.de
diff --git a/hw/ahci.c b/hw/ahci.c
index 9987459..a024706 100644
--- a/hw/ahci.c
+++ b/hw/ahci.c
@@ -179,21 +179,6 @@ do { fprintf(stderr,ahci: fmt , ## __VA_ARGS__); }
while (0)
#define ATA_CMD_WRITE_EXT 0x34/* Write Sectores (with retries) with
48bit addressing */
#define ATA_CMD_VRFY_EXT 0x42/* Read Verify (with retries) with
48bit addressing */
-/*
- * ATAPI Commands
- */
-#define ATAPI_CMD_IDENT 0xA1 /* Identify AT Atachment Packed Interface Device
*/
-#define ATAPI_CMD_PACKET 0xA0 /* Packed Command */
-
-
-#define ATAPI_CMD_INQUIRY 0x12
-#define ATAPI_CMD_REQ_SENSE 0x03
-#define ATAPI_CMD_READ_CAP 0x25
-#define ATAPI_CMD_START_STOP 0x1B
-#define ATAPI_CMD_READ_12 0xA8
-
-
-
typedef struct ahci_control_regs {
uint32_t cap;
uint32_t ghc;
[Qemu-devel] Re: [SeaBIOS] SMBIOS strings
Jes Sorensen wrote: Hi, We were looking at the dmidecode output from qemu-kvm pre-seabios and current qemu-kvm and noticed some of the strings have changed. The main problem with this is that certain OSes are quite sensitive to system changes and avoiding to change things unnecessarily would probably be a good thing. Which OSes do care? Windows only? I wanted to check with the lists if there are any strong feelings about this, and whether some of these changes were made for specific reasons? For example: Handle 0x, DMI type 0, 24 bytes BIOS Information - Vendor: QEMU - Version: QEMU + Vendor: Bochs + Version: Bochs Release Date: 01/01/2007 Address: 0xE8000 Runtime Size: 96 kB You can configure this with CONFIG_APPNAME. and this: Handle 0x0401, DMI type 4, 32 bytes Processor Information - Socket Designation: CPU 1 + Socket Designation: CPU01 Type: Central Processor Family: Other - Manufacturer: QEMU - ID: 63 06 00 00 FD FB 8B 07 + Manufacturer: Bochs + ID: 23 06 00 00 FD FB 8B 07 Version: Not Specified Voltage: Unknown External Clock: Unknown I guess the Socket Designation in particular might have been done for a reason? Otherwise, if there are no objections, I'll look at adding some patches to make it more backwards compatible. Cheers, Jes Is the different ID displayed on the same VM configuration (esp. -cpu option) ? The value is gained by calling CPUID so it should not be different. Which pre-seabios qemu-kvm bios are you comparing to? Sebastian
[Qemu-devel] [PATCH] ahci: handle writes to generic host control registers
Handle writes to Generic Host Control registers.
Signed-off-by: Sebastian Herbszt herb...@gmx.de
diff --git a/hw/ahci.c b/hw/ahci.c
index f8e198c..178f9ea 100644
--- a/hw/ahci.c
+++ b/hw/ahci.c
@@ -425,7 +425,6 @@ static uint32_t ahci_mem_readl(void *ptr,
target_phys_addr_t addr)
static void ahci_mem_writel(void *ptr, target_phys_addr_t addr, uint32_t val)
{
AHCIState *s = ptr;
- uint32_t *p;
addr=addr0xfff;
/* Only aligned reads are allowed on OHCI */
@@ -435,17 +434,30 @@ static void ahci_mem_writel(void *ptr, target_phys_addr_t
addr, uint32_t val)
return;
}
- if(addr0x20)
- {
- switch(addr)
- {
- case HOST_IRQ_STAT:
+ if (addr 0x20) { /* Generic Host Control */
+ switch(addr) {
+ case HOST_CAP: /* R/WO, RO */
+ /* FIXME handle R/WO */
+ break;
+ case HOST_CTL: /* R/W */
+ if (val HOST_RESET) {
+ DPRINTF(HBA Reset\n);
+ /* FIXME reset? */
+ } else
+ s-control_regs.ghc = val;
+ break;
+ case HOST_IRQ_STAT: /* R/WC, RO */
s-control_regs.irqstatus = ~val;
ahci_check_irq(s);
break;
+ case HOST_PORTS_IMPL: /* R/WO, RO */
+ /* FIXME handle R/WO */
+ break;
+ case HOST_VERSION: /* RO */
+ /* FIXME report write? */
+ break;
default:
- /* genernal host control */
- p=(uint32_t *)s-control_regs;
+ DPRINTF(write to unknown register 0x%x\n,
(unsigned)addr);
}
}
else if(addr=0x100 addr0x300)
[Qemu-devel] [PATCH] ahci: fix global hba control default value
Global HBA Control default value should be zero.
Signed-off-by: Sebastian Herbszt herb...@gmx.de
diff --git a/hw/ahci.c b/hw/ahci.c
index 178f9ea..ce87cbe 100644
--- a/hw/ahci.c
+++ b/hw/ahci.c
@@ -485,7 +485,6 @@ static void ahci_reg_init(AHCIState *s)
{
int i;
s-control_regs.cap = 3 | (0x1f 8) | (1 20) ; /* 4 ports, 32
command slots, 1.5 Gb/s */
- s-control_regs.ghc = 1 31; /* AHCI Enable */
s-control_regs.impl = 15; /* Ports 0-3 implemented */
s-control_regs.version = 0x1;
for(i=0;iSATA_PORTS;i++)
Re: [Qemu-devel] [PATCH] ahci: convert enum to #define
Nathan Froyd wrote: On Thu, May 13, 2010 at 07:19:30PM +0200, Sebastian Herbszt wrote: Convert enum to #define. This doesn't buy you anything except code churn. It actually makes things worse at usual debug levels, too, because the debugger understands enums, but not #define. -Nathan Alex asked for this in http://lists.gnu.org/archive/html/qemu-devel/2010-05/msg00114.html Sebastian
[Qemu-devel] [PATCH] ahci: enhance usable port count to 4
Make all 4 SATA ports usable.
Signed-off-by: Sebastian Herbszt herb...@gmx.de
diff --git a/hw/ahci.c b/hw/ahci.c
index 6f7b807..a343839 100644
--- a/hw/ahci.c
+++ b/hw/ahci.c
@@ -17,7 +17,6 @@
*
* TODO:
* o ahci cd support should use ide,but now ide 's bmdma prdt is different
from ahci's prdt.
- * make ahci use multi-devices at the same time
* make code to reuse ide's code
*/
#include hw.h
@@ -266,7 +265,7 @@ typedef struct AHCIState{
uint32_t port_state[SATA_PORTS];
int mem;
QEMUTimer *timer;
- IDEBus *ide;
+ IDEBus *ide[SATA_PORTS];
ahci_sg *prdt_buf;
qemu_irq irq;
} AHCIState;
@@ -291,7 +290,7 @@ static uint32_t ahci_port_read(AHCIState *s,int port,int
offset)
switch(offset)
{
case PORT_SCR:
- if(s-ide port==0)
+ if(s-ide[port])
val= 3 /* DET */ | (1 4) /* SPD */ | (1
8) /* IPM */;
else
val=0;
@@ -489,7 +488,7 @@ static void ahci_reg_init(AHCIState *s)
int i;
s-control_regs.cap = 3 | (0x1f 8) | (1 20) ; /* 4 ports, 32
command slots, 1.5 Gb/s */
s-control_regs.ghc = 1 31; /* AHCI Enable */
- s-control_regs.impl = 1; /* Port 0 implemented */
+ s-control_regs.impl = 15; /* Ports 0-3 implemented */
s-control_regs.version = 0x1;
for(i=0;iSATA_PORTS;i++)
s-port_state[i]=STATE_RUN;
@@ -736,13 +735,13 @@ static inline int media_is_cd(IDEState *s)
{
return (media_present(s) s-nb_sectors = CD_MAX_SECTORS);
}
-static void ide_atapi_cmd(AHCIState *s,int prdt_num)
+static void ide_atapi_cmd(AHCIState *s,int prdt_num, int port)
{
const uint8_t *packet;
uint8_t *buf;
int max_len;
IDEState *ide_state;
- ide_state=s-ide-ifs[0];
+ ide_state=s-ide[port]-ifs[0];
packet = ide_state-io_buffer;
buf = ide_state-io_buffer;
@@ -1055,8 +1054,8 @@ static void handle_cmd(AHCIState *s,int port,int slot)
case STATE_RESET:
if(!(fis[15]ATA_SRST))
{
- if(!s-ide)hw_error(no ahci sata disk now\n);
- ide_state=s-ide-ifs[0];
+ if(!s-ide[port])hw_error(no ahci sata disk
now\n);
+ ide_state=s-ide[port]-ifs[0];
s-port_state[port]=STATE_RUN;
if(bdrv_get_type_hint(ide_state-bs)==BDRV_TYPE_CDROM)
s-port_regs[port].sig=0xeb1416;
@@ -1067,8 +1066,8 @@ static void handle_cmd(AHCIState *s,int port,int slot)
if(fis[1]==(17))
{
- if(!s-ide)hw_error(no ahci sata disk now\n);
- ide_state=s-ide-ifs[0];
+ if(!s-ide[port])hw_error(no ahci sata disk now\n);
+ ide_state=s-ide[port]-ifs[0];
switch(fis[2])
{
case WIN_PIDENTIFY:
@@ -1094,7 +1093,7 @@ static void handle_cmd(AHCIState *s,int port,int slot)
ide_state-atapi_dma = 1;
ide_state-nsector = 1;
memcpy(ide_state-io_buffer,acmd,32);
- ide_atapi_cmd(s,prdt_num);
+ ide_atapi_cmd(s,prdt_num,port);
pr-irq_stat |= (12);
break;
case WIN_STANDBYNOW1:
@@ -1151,20 +1150,26 @@ static void ahci_timer_function(void *opaque)
static AHCIState *ahci_new(void)
{
+ int i;
DriveInfo *dinfo;
- IDEBus *bus = qemu_mallocz(sizeof(IDEBus));
- BMDMAState *bmdma=qemu_mallocz(sizeof(BMDMAState));
+ IDEBus *bus[SATA_PORTS];
+ BMDMAState *bmdma[SATA_PORTS];
+ for (i = 0; i SATA_PORTS; i++) {
+ bus[i] = qemu_mallocz(sizeof(IDEBus));
+ bmdma[i] = qemu_mallocz(sizeof(BMDMAState));
+ }
AHCIState *s = qemu_mallocz(sizeof(AHCIState));
ahci_reg_init(s);
s-mem = cpu_register_io_memory(ahci_readfn, ahci_writefn, s);
s-timer = qemu_new_timer(vm_clock, ahci_timer_function, s);
s-prdt_buf = qemu_malloc(65535*32);
- if ((dinfo = drive_get(IF_SATA, 0, 0)) != NULL)
- {
- ide_init2(bus, dinfo, NULL,0);
- s-ide=bus;
- s-ide-bmdma=bmdma;
+ for (i = 0; i SATA_PORTS; i++) {
+ if ((dinfo = drive_get(IF_SATA, 0, i)) != NULL) {
+ ide_init2(bus[i], dinfo, NULL,0);
+ s-ide[i]=bus[i];
+ s-ide[i]-bmdma=bmdma[i];
+ }
}
return s;
}
[Qemu-devel] [PATCH] ahci: increase MAX_SATA_DEVS to 4
All ICH6 ports are now available.
Signed-off-by: Sebastian Herbszt herb...@gmx.de
diff --git a/sysemu.h b/sysemu.h
index 70d5a33..022be18 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -177,7 +177,7 @@ typedef struct DriveInfo {
#define MAX_IDE_DEVS 2
#define MAX_SCSI_DEVS 7
-#define MAX_SATA_DEVS 1
+#define MAX_SATA_DEVS 4
#define MAX_DRIVES 32
extern QTAILQ_HEAD(drivelist, DriveInfo) drives;
[Qemu-devel] [PATCH] ahci: convert enum to #define
Convert enum to #define.
Signed-off-by: Sebastian Herbszt herb...@gmx.de
diff --git a/hw/ahci.c b/hw/ahci.c
index 6f7b807..8d8605c 100644
--- a/hw/ahci.c
+++ b/hw/ahci.c
@@ -40,138 +40,124 @@ do { fprintf(stderr,ahci: fmt , ## __VA_ARGS__); }
while (0)
#define DPRINTF(fmt, ...) do {} while(0)
#endif
-enum {
- AHCI_PCI_BAR= 5,
- AHCI_MAX_PORTS = 32,
- AHCI_MAX_SG = 168, /* hardware max is 64K */
- AHCI_DMA_BOUNDARY = 0x,
- AHCI_USE_CLUSTERING = 0,
- AHCI_MAX_CMDS = 32,
- AHCI_CMD_SZ = 32,
- AHCI_CMD_SLOT_SZ= AHCI_MAX_CMDS * AHCI_CMD_SZ,
- AHCI_RX_FIS_SZ = 256,
- AHCI_CMD_TBL_CDB= 0x40,
- AHCI_CMD_TBL_HDR_SZ = 0x80,
- AHCI_CMD_TBL_SZ = AHCI_CMD_TBL_HDR_SZ + (AHCI_MAX_SG * 16),
- AHCI_CMD_TBL_AR_SZ = AHCI_CMD_TBL_SZ * AHCI_MAX_CMDS,
- AHCI_PORT_PRIV_DMA_SZ = AHCI_CMD_SLOT_SZ + AHCI_CMD_TBL_AR_SZ +
- AHCI_RX_FIS_SZ,
- AHCI_IRQ_ON_SG = (1 31),
- AHCI_CMD_ATAPI = (1 5),
- AHCI_CMD_WRITE = (1 6),
- AHCI_CMD_PREFETCH = (1 7),
- AHCI_CMD_RESET = (1 8),
- AHCI_CMD_CLR_BUSY = (1 10),
-
- RX_FIS_D2H_REG = 0x40, /* offset of D2H Register FIS data */
- RX_FIS_SDB = 0x58, /* offset of SDB FIS data */
- RX_FIS_UNK = 0x60, /* offset of Unknown FIS data */
-
- board_ahci = 0,
- board_ahci_pi = 1,
- board_ahci_vt8251 = 2,
- board_ahci_ign_iferr= 3,
- board_ahci_sb600= 4,
-
- /* global controller registers */
- HOST_CAP= 0x00, /* host capabilities */
- HOST_CTL= 0x04, /* global host control */
- HOST_IRQ_STAT = 0x08, /* interrupt status */
- HOST_PORTS_IMPL = 0x0c, /* bitmap of implemented ports */
- HOST_VERSION= 0x10, /* AHCI spec. version compliancy */
-
- /* HOST_CTL bits */
- HOST_RESET = (1 0), /* reset controller; self-clear */
- HOST_IRQ_EN = (1 1), /* global IRQ enable */
- HOST_AHCI_EN= (1 31), /* AHCI enabled */
-
- /* HOST_CAP bits */
- HOST_CAP_SSC= (1 14), /* Slumber capable */
- HOST_CAP_CLO= (1 24), /* Command List Override support */
- HOST_CAP_SSS= (1 27), /* Staggered Spin-up */
- HOST_CAP_NCQ= (1 30), /* Native Command Queueing */
- HOST_CAP_64 = (1 31), /* PCI DAC (64-bit DMA) support */
-
- /* registers for each SATA port */
- PORT_LST_ADDR = 0x00, /* command list DMA addr */
- PORT_LST_ADDR_HI= 0x04, /* command list DMA addr hi */
- PORT_FIS_ADDR = 0x08, /* FIS rx buf addr */
- PORT_FIS_ADDR_HI= 0x0c, /* FIS rx buf addr hi */
- PORT_IRQ_STAT = 0x10, /* interrupt status */
- PORT_IRQ_MASK = 0x14, /* interrupt enable/disable mask */
- PORT_CMD= 0x18, /* port command */
- PORT_TFDATA = 0x20, /* taskfile data */
- PORT_SIG= 0x24, /* device TF signature */
- PORT_CMD_ISSUE = 0x38, /* command issue */
- PORT_SCR= 0x28, /* SATA phy register block */
- PORT_SCR_STAT = 0x28, /* SATA phy register: SStatus */
- PORT_SCR_CTL= 0x2c, /* SATA phy register: SControl */
- PORT_SCR_ERR= 0x30, /* SATA phy register: SError */
- PORT_SCR_ACT= 0x34, /* SATA phy register: SActive */
-
- /* PORT_IRQ_{STAT,MASK} bits */
- PORT_IRQ_COLD_PRES = (1 31), /* cold presence detect */
- PORT_IRQ_TF_ERR = (1 30), /* task file error */
- PORT_IRQ_HBUS_ERR = (1 29), /* host bus fatal error */
- PORT_IRQ_HBUS_DATA_ERR = (1 28), /* host bus data error */
- PORT_IRQ_IF_ERR = (1 27), /* interface fatal error */
- PORT_IRQ_IF_NONFATAL= (1 26), /* interface non-fatal error */
- PORT_IRQ_OVERFLOW = (1 24), /* xfer exhausted available S/G */
- PORT_IRQ_BAD_PMP= (1 23), /* incorrect port multiplier */
-
- PORT_IRQ_PHYRDY = (1 22), /* PhyRdy changed */
- PORT_IRQ_DEV_ILCK = (1 7), /* device interlock */
- PORT_IRQ_CONNECT= (1 6), /* port connect change status */
- PORT_IRQ_SG_DONE= (1 5), /* descriptor processed */
- PORT_IRQ_UNK_FIS= (1 4), /* unknown FIS rx'd */
- PORT_IRQ_SDB_FIS= (1 3), /* Set Device Bits FIS rx'd */
- PORT_IRQ_DMAS_FIS = (1 2), /* DMA Setup FIS rx'd */
- PORT_IRQ_PIOS_FIS = (1 1), /* PIO Setup FIS rx'd */
- PORT_IRQ_D2H_REG_FIS= (1 0), /* D2H
[Qemu-devel] [PATCH] ahci: use interface type IF_SATA
Use interface type IF_SATA instead of IF_SCSI.
Signed-off-by: Sebastian Herbszt herb...@gmx.de
diff --git a/hw/ahci.c b/hw/ahci.c
index 2763075..6f7b807 100644
--- a/hw/ahci.c
+++ b/hw/ahci.c
@@ -1160,7 +1160,7 @@ static AHCIState *ahci_new(void)
s-timer = qemu_new_timer(vm_clock, ahci_timer_function, s);
s-prdt_buf = qemu_malloc(65535*32);
- if ((dinfo = drive_get(IF_SCSI, 0, 0)) != NULL)
+ if ((dinfo = drive_get(IF_SATA, 0, 0)) != NULL)
{
ide_init2(bus, dinfo, NULL,0);
s-ide=bus;
[Qemu-devel] Re: [SeaBIOS] [PATCH] smbios: avoid counting io hole as ram
Kevin O'Connor wrote: On Fri, May 07, 2010 at 01:38:55PM -0600, Alex Williamson wrote: Avoid counting the io hole as part of ram, a vm started with 4G should report 4G in smbios, not 4.5G. Signed-off-by: Alex Williamson alex.william...@redhat.com Looks okay to me. If there are no other comments, I'll commit in the next couple of days. -Kevin If i don't mistake it seems to address what i have reported back in January in the wrong memsize in smbios_init() thread [1], correct? [1] http://www.seabios.org/pipermail/seabios/2010-January/000146.html Sebastian
[Qemu-devel] [PATCH] add interface type IF_SATA
Add interface type IF_SATA.
Signed-off-by: Sebastian Herbszt herb...@gmx.de
diff --git a/sysemu.h b/sysemu.h
index fa921df..b88bae9 100644
--- a/sysemu.h
+++ b/sysemu.h
@@ -151,7 +151,7 @@ extern unsigned int nb_prom_envs;
typedef enum {
IF_NONE,
IF_IDE, IF_SCSI, IF_FLOPPY, IF_PFLASH, IF_MTD, IF_SD, IF_VIRTIO, IF_XEN,
-IF_COUNT
+IF_SATA, IF_COUNT
} BlockInterfaceType;
typedef enum {
@@ -177,6 +177,7 @@ typedef struct DriveInfo {
#define MAX_IDE_DEVS 2
#define MAX_SCSI_DEVS 7
+#define MAX_SATA_DEVS 1
#define MAX_DRIVES 32
extern QTAILQ_HEAD(drivelist, DriveInfo) drives;
diff --git a/vl.c b/vl.c
index 85bcc84..cd3a343 100644
--- a/vl.c
+++ b/vl.c
@@ -849,6 +849,9 @@ DriveInfo *drive_init(QemuOpts *opts, void *opaque,
} else if (!strcmp(buf, xen)) {
type = IF_XEN;
max_devs = 0;
+ } else if (!strcmp(buf, sata)) {
+ type = IF_SATA;
+max_devs = MAX_SATA_DEVS;
} else if (!strcmp(buf, none)) {
type = IF_NONE;
max_devs = 0;
@@ -1039,7 +1042,7 @@ DriveInfo *drive_init(QemuOpts *opts, void *opaque,
} else {
/* no id supplied - create one */
dinfo-id = qemu_mallocz(32);
-if (type == IF_IDE || type == IF_SCSI)
+if (type == IF_IDE || type == IF_SCSI || type == IF_SATA)
mediastr = (media == MEDIA_CDROM) ? -cd : -hd;
if (max_devs)
snprintf(dinfo-id, 32, %s%i%s%i,
@@ -1064,6 +1067,7 @@ DriveInfo *drive_init(QemuOpts *opts, void *opaque,
case IF_IDE:
case IF_SCSI:
case IF_XEN:
+case IF_SATA:
case IF_NONE:
switch(media) {
case MEDIA_DISK:
[Qemu-devel] Re: [PATCH 0/1] [RFC][AHCI] add cdrom support for ahci.
Alexander Graf wrote: Hi Chong, On 10.05.2010, at 13:55, QiaoChong wrote: When ahci init ,driver will send ATA_SRST command,ahci device report device type through port's sig register. Ahci disk lookup change from IF_SD to IF_SCSI now,because IF_SD does not support cdrom media. I just copy ide_atapi_cmd from hw/ide/core.c into hw/ahci.c,change a little,then the cdrom can be identified,and read by os. If qemu can change dma_buf_prepare,dma_buf_rw,dma_buf_commit to a function pointer in BMDMAState,then I can rewrite three functions to support ahci's prtd,because it is different from ide's. test a sata disk like this: ./i386-softmmu/qemu -cdrom KNOPPIX_V6.0.1CD-2009-02-08-EN.iso -drive if=scsi,file=/tmp/disk test a sata cd like this: ./i386-softmmu/qemu -cdrom KNOPPIX_V6.0.1CD-2009-02-08-EN.iso -drive if=scsi,media=cdrom,file=KNOPPIX_V6.0.1CD-2009-02-08-EN.iso Thanks for improving the patch, but I have some nitpicks considering on how to process here. For starters, this patch is incremental to the previous one. Since the previous patch did not get applied to qemu, it doesn't make sense to send an incremental patch. Please send the full patchset but bump up the version in that case. You will find many examples for that on the mailing list. In most cases it also makes sense to rethink the splitting between patches. The problem of incremental patches will be a non issue as soon as the git tree is available. Sebastian
[Qemu-devel] AHCI support integration
The ICH6 AHCI implementation submitted by Chong is an all-in-one attempt (ahci.c). It includes all needed parts of the ICH6, AHCI, SATA and ATA specification. The code in hw/ide/* on the other hand is split (or could be split) into smaller parts like port based and bus master access, IDE and ATA core. I think it might be reasonable to split ahci.c into ICH6, AHCI and SATA parts and strip the limited ATA support and reuse it from the ide core. This would give us something like the following: hw/ide/piix.c (PIIX3 and PIIX4) hw/ide/pci.c and core.c (IDE, BM) hw/ata-core.c (ATA) hw/sata/ich6.c (ICH6) hw/sata-core.c (SATA) hw/ahci-core.c (AHCI) Should this be a goal or am i over-engineering here? Sebastian
[Qemu-devel] Re: vgabios + qemu: issues and plans.
Gerd Hoffmann wrote: Hi, First, I'd like to be able to load the vgabios via PCI ROM bar on all pci vga cards (stdvga, vmware, soon qxl). The PCI ID in the bios has to match the PCI ID of the card, so we'll need a bunch of vga bios binaries, all identical except for the PCI ID. Or we need some kind of binary patching. Otherwise seabios will not load them from the PCI ROM bar. vgabios could be build multiple times with PCIBIOS set and VENDOR_ID and DEVICE_ID supplied from the Makefile like it's already done with VGABIOS_DATE. Yes, something like this I have in mind. Works for stdvga and qxl. vmware fails as it has the memory at pci region 1 (region 0 has ioports) and it seems vgabios isn't prepared to handle that ... Do you mean vgabios currently doesn't work with qemu and -vga vmware ? Anyone knows what the best place to send patches to is? vgabios-developers list @ savannah looks pretty much dead. It has one (!) message in 2009 which is an unanswered question. Or is upstream dead anyway and we should just go with http://git.qemu.org/vgabios.git/ ? From the amount of messages on the mailing list i conclude vgabios just works good enough for most people. I would not say the developement is dead, but event driven and there is no itch to strach at the moment. Try sending patches to the mailing list and/or the vgabios home at http://savannah.nongnu.org/projects/vgabios . Sebastian cheers, Gerd
[Qemu-devel] Re: vgabios + qemu: issues and plans.
Gerd Hoffmann wrote: First, I'd like to be able to load the vgabios via PCI ROM bar on all pci vga cards (stdvga, vmware, soon qxl). The PCI ID in the bios has to match the PCI ID of the card, so we'll need a bunch of vga bios binaries, all identical except for the PCI ID. Or we need some kind of binary patching. Otherwise seabios will not load them from the PCI ROM bar. Make vga bios aware of all ids? Would work for the code doing the lfb address lookup. But I don't think the PCI option rom header allows multiple entries. AFAIK it does not, but you can put multiple PCI option roms (concatenated) on the BAR (see 6.3.1. PCI Expansion ROM Contents). I also want to eliminate the magic number. Boch vga bios is paravirtualized to get VBE address dynamically via a new pci device with special pci device of device id 0x1234. 0x1234 happens to be the vendor id the qemu stdvga has. Probably the same is true for bochs. So this code actually looks up the emulated vga card ;) Bochs and qemu use 0x1234:0x. Sebastian Are you meaning to follow bochs way? Yes. cheers, Gerd
[Qemu-devel] Re: Re: [RFC] [PATCH] add ahci support into qemu
Stuart Brady wrote: On Tue, May 04, 2010 at 10:51:37PM +0200, Sebastian Herbszt wrote: diff --git a/hw/pci_ids.h b/hw/pci_ids.h index fe7a121..4d4de93 100644 --- a/hw/pci_ids.h +++ b/hw/pci_ids.h @@ -97,3 +97,4 @@ #define PCI_DEVICE_ID_INTEL_82371AB 0x7111 #define PCI_DEVICE_ID_INTEL_82371AB_20x7112 #define PCI_DEVICE_ID_INTEL_82371AB_30x7113 +#define PCI_DEVICE_ID_INTEL_ICH6R_AHCI0x2652 The list is sorted by vendor and device id. This entry should go after PCI_DEVICE_ID_INTEL_ESB_9. The naming scheme seems to be VENDOR_DEVICE_FUNCTION, so i suggest something like PCI_DEVICE_ID_INTEL_ICH6R_2 or PCI_DEVICE_ID_INTEL_82801FR_2. Linux seems to have called this PCI_DEVICE_ID_INTEL_ICH6_4 at one point. So this should be function 4, no? Well, i am not sure if the last part is the function number. pci_ids.h from the linux kernel got this: #define PCI_DEVICE_ID_INTEL_ICH6_0 0x2640 #define PCI_DEVICE_ID_INTEL_ICH6_1 0x2641 #define PCI_DEVICE_ID_INTEL_ICH6_2 0x2642 #define PCI_DEVICE_ID_INTEL_ICH6_16 0x266a #define PCI_DEVICE_ID_INTEL_ICH6_17 0x266d #define PCI_DEVICE_ID_INTEL_ICH6_18 0x266e #define PCI_DEVICE_ID_INTEL_ICH6_19 0x266f According to the Intel spec the SATA controller is D31:F2. So we got device 31 and function 2. The IDE controller is D31:F1, but above it's ICH6_19. Sebastian Cheers, -- Stuart Brady
[Qemu-devel] Re: vgabios + qemu: issues and plans.
Gerd Hoffmann wrote: Hi, Works for stdvga and qxl. vmware fails as it has the memory at pci region 1 (region 0 has ioports) and it seems vgabios isn't prepared to handle that ... Do you mean vgabios currently doesn't work with qemu and -vga vmware ? It works, but uses the bochs lfb at the magic address 0xe000. Killing the 0xe00 alias mapping and switching over to use the pci region instead requires some changes in pci_get_lfb_addr to handle the situation. Does this only happen with VBE? Sebastian
Re: [Qemu-devel] Re: [RFC] [PATCH] add ahci support into qemu
乔崇 wrote:
I add Sebastian Herbsz's patch,add WIN_WIN_STANDBYNOW1 support to fix
hw_error on linux shut down etc.
I am not familiar with git send-email,I am studying it now :).
[snip]
From e94912b03ed33080d550eb5764fc99911498101b Mon Sep 17 00:00:00 2001
From: QiaoChong qiaoch...@loongson.cn
Date: Tue, 4 May 2010 07:31:30 +0800
Subject: [PATCH] ahci pci ids into pci_ids.h,add warning messages.
move ahci pci device id define into pci_ids.h,add warning messages for
unsupported features.
Signed-off-by: QiaoChong qiaoch...@loongson.cn
---
hw/ahci.c| 10 +-
hw/pci_ids.h |1 +
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/hw/ahci.c b/hw/ahci.c
index cb4a851..e1aed4a 100644
--- a/hw/ahci.c
+++ b/hw/ahci.c
@@ -662,7 +662,9 @@ static void handle_cmd(AHCIState *s,int port,int slot)
if(fis[1]==0)
{
-
+#ifdef DEBUG_AHCI
+ printf(now,just ignore command fis[0]=%02x fis[1]=%02x
fis[2]=%02x\n,fis[0],fis[1],fis[2]);
+#endif
}
if(fis[1]==(17))
@@ -755,15 +757,13 @@ static void ahci_pci_map(PCIDevice *pci_dev, int
region_num,
cpu_register_physical_memory(addr, size, s-mem);
}
-#define PCI_VENDOR_MYDEVICE 0x8086
-#define PCI_PRODUCT_MYDEVICE 0x2652
static int pci_ahci_init(PCIDevice *dev)
{
struct ahci_pci_state *d;
d = DO_UPCAST(struct ahci_pci_state, card, dev);
- pci_config_set_vendor_id(d-card.config,PCI_VENDOR_MYDEVICE);
- pci_config_set_device_id(d-card.config,PCI_PRODUCT_MYDEVICE);
+ pci_config_set_vendor_id(d-card.config,PCI_VENDOR_ID_INTEL);
+ pci_config_set_device_id(d-card.config,PCI_DEVICE_ID_INTEL_ICH6R_AHCI);
d-card.config[PCI_COMMAND] = PCI_COMMAND_IO | PCI_COMMAND_MEMORY |
PCI_COMMAND_MASTER;
d-card.config[PCI_CLASS_DEVICE] = 0;
d-card.config[0x0b] = 1;//storage
diff --git a/hw/pci_ids.h b/hw/pci_ids.h
index fe7a121..4d4de93 100644
--- a/hw/pci_ids.h
+++ b/hw/pci_ids.h
@@ -97,3 +97,4 @@
#define PCI_DEVICE_ID_INTEL_82371AB 0x7111
#define PCI_DEVICE_ID_INTEL_82371AB_20x7112
#define PCI_DEVICE_ID_INTEL_82371AB_30x7113
+#define PCI_DEVICE_ID_INTEL_ICH6R_AHCI0x2652
The list is sorted by vendor and device id. This entry should go
after PCI_DEVICE_ID_INTEL_ESB_9. The naming scheme seems
to be VENDOR_DEVICE_FUNCTION, so i suggest something like
PCI_DEVICE_ID_INTEL_ICH6R_2 or PCI_DEVICE_ID_INTEL_82801FR_2.
Sebastian
[Qemu-devel] Re: [RFC] [PATCH] add ahci support into qemu
Elek Roland wrote: On v, 2010-05-02 at 17:56 +0200, Elek Roland wrote: I'm going to try the patch in practice as soon as I finish my university project. (It's due today.) I've tried the patch, and I can confirm that it does provide an AHCI device and a SATA disk. It shows up in qemu as an Intel Corporation 82801FR/FRW (ICH6R/ICH6RW) SATA Controller, which is consistent with the device and vendor IDs in the code. I could successfully create an ext2 filesystem on the virtual disk, mount it, write a text file on it and read it back. I've noticed the following errors: - The source code claims to implement 2 ports, Linux reports 3. - When I halt the guest OS, the AHCI device throws a hardware error about an unimplemented command. Those issues should be fixed now by the following two patches: 0001-fix-port-count-cap-and-version-etc-to-ahci.patch 0002-add-WIN_STANDBYNOW1-process-into-ahci.patch Sebastian I think we could clean up the code and use it as a basis for full support. Regards, Roland
[Qemu-devel] Re: vgabios + qemu: issues and plans.
Gerd Hoffmann wrote: Hi, Today we have two vgabios versions in qemu: The standard one (vgabios.bin) and the cirrus one (vgabios-cirrus.bin). The cirrus vgabios is a PCI ROM. We can (and do) load it into the ROM PCI bar. The vgabios checks the pci config space to figure where the linear framebuffer (for vesa graphics) is mapped to. It knows how to program the cirrus. The standard bios isn't a PCI ROM. We have to load it using the seabios firmware interface. It expects to find the linear framebuffer at the magic address 0xe000. It uses the bochs extentions to implement vesa graphics support. So, what is wrong with this? First, I'd like to be able to load the vgabios via PCI ROM bar on all pci vga cards (stdvga, vmware, soon qxl). The PCI ID in the bios has to match the PCI ID of the card, so we'll need a bunch of vga bios binaries, all identical except for the PCI ID. Or we need some kind of binary patching. Otherwise seabios will not load them from the PCI ROM bar. vgabios could be build multiple times with PCIBIOS set and VENDOR_ID and DEVICE_ID supplied from the Makefile like it's already done with VGABIOS_DATE. Second, I want to get rid of the magic address 0xe000 (except for isa-vga). This is basically just a matter of updating to vgabios version 0.6c. And this needs one vga bios binary per vga card too as the PCI ID is used to lookup the card (and then the framebuffer address) in PCI config space. Comments? Especially on the binary patching? Worth it? Or just build a bunch of binaries? They are not *that* big after all ... Few more bios binaries should do no harm. This is currently used for eepro100 (gpxe-eepro100-80861209.rom and gpxe-eepro100-80861229.rom). So maybe define a similar naming convention for the vgabios. Sebastian cheers, Gerd
[Qemu-devel] eepro100: missing gpxe-eepro100-80862449.rom?
eepro100_register_devices() references three option roms: - gpxe-eepro100-80861209.rom - gpxe-eepro100-80861229.rom - gpxe-eepro100-80862449.rom The last one seems to be missing because it's not in the pc-bios directory. Sebastian
[Qemu-devel] Re: [RFC] [PATCH] add ahci support into qemu
Hi, 乔崇 wrote: Hi,Alexander Graf. I am very glad you noticed my patch about ahci.I love qemu just like I love linux.I wish I could do much more work on qemu development. I had cloned qemu from master branch,add my patch into it,and tested ahci on i386 softmmu. If anyone is interested on ahci,you can test my patch like this: git-clone -ls git://git.savannah.nongnu.org/qemu patch -p1 -i 0001-add-ahci-support-into-qemu-only-support-sata-disk.patch patch -p1 -i 0002-add-ahci-device-into-i386-pc-just-for-test.patch The last submission was missing the qemu glue, but this one looks complete. Nonetheless the old one was working fine enough. ./configure --target-list=i386-softmmu make dd if=/dev/zero of=/tmp/disk bs=1M count=100 ./i386-softmmu/qemu -cdrom KNOPPIX_V6.0.1CD-2009-02-08-EN.iso -boot d -drive if=sd,file=/tmp/disk After linux boot,you will find a ahci device named sda. Now this patch only support sata disk. Most ahci registers and operations which are not necessary on linux are ignored. Now this patch support disk identify,dma read,dma write,ignore other opertions. Do you intent to work on this and complet the support? There are also some minor changes needed like moving PCI_VENDOR_MYDEVICE and PCI_PRODUCT_MYDEVICE to pci.h and others. Did you use the Intel document #301473 for reference? By the way how you send patch to mail list? Try git send-email. Regards, Sebastian
[Qemu-devel] Re: [RFC] [PATCH] add ahci support into qemu
Hi again,
please consider the following minor changes:
- debug output with DEBUG_AHCI
- set port count to 4
- change return value of PxSSTS to include SPD and IPM
- change cap and version default values according to Intel #301473-002
Regards,
Sebastian
--- hw/ahci.c.orig Sun May 2 15:43:58 2010
+++ hw/ahci.c Sun May 2 22:03:26 2010
@@ -26,8 +26,15 @@
#include dma.h
#include cpu-common.h
#include hw/ide/internal.h
-#define DPRINTF(...)
+#define DEBUG_AHCI
+
+#ifdef DEBUG_AHCI
+#define DPRINTF(fmt, ...) \
+do { printf(ahci: fmt , ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) do {} while(0)
+#endif
enum {
AHCI_PCI_BAR = 5,
@@ -203,6 +210,8 @@
uint32_t version;
} ahci_control_regs;
+#define SATA_PORTS 4
+
typedef struct ahci_port_regs {
uint32_t lst_addr;
uint32_t lst_addr_hi;
@@ -240,7 +249,7 @@
typedef struct AHCIState{
ahci_control_regs control_regs;
- ahci_port_regs port_regs[2];
+ ahci_port_regs port_regs[SATA_PORTS];
int mem;
QEMUTimer *timer;
IDEBus *ide;
@@ -268,8 +277,10 @@
switch(offset)
{
case PORT_SCR:
- if(s-ide port==0) val=3;
- else val=0;
+ if(s-ide port==0)
+val= 3 /* DET */ | (1 4) /* SPD */ | (1 8) /* IPM */;
+ else
+val=0;
break;
case PORT_IRQ_STAT:
val=pr-irq_stat;
@@ -291,6 +302,7 @@
val= p[offset2];
break;
}
+ DPRINTF(ahci_port_read: port: 0x%x offset: 0x%x val: 0x%x\n, port, offset,
val);
return val;
}
@@ -299,7 +311,7 @@
{
ahci_port_regs *pr;
int i;
- for(i=0;i2;i++)
+ for(i=0;iSATA_PORTS;i++)
{
pr=s-port_regs[i];
@@ -319,6 +331,7 @@
ahci_port_regs *pr=s-port_regs[port];
uint32_t *p;
+ DPRINTF(ahci_port_write: port: 0x%x offset: 0x%x val: 0x%x\n, port, offset,
val);
switch(offset)
{
case PORT_LST_ADDR:
@@ -396,7 +409,7 @@
val=p[addr2];
}
}
- else if(addr=0x100 addr0x200)
+ else if(addr=0x100 addr0x300)
{
val=ahci_port_read(s,(addr-0x100)7,addr0x7f);
}
@@ -436,7 +449,7 @@
p=(uint32_t *)s-control_regs;
}
}
- else if(addr=0x100 addr0x200)
+ else if(addr=0x100 addr0x300)
{
ahci_port_write(s,(addr-0x100)7,addr0x7f,val);
}
@@ -459,10 +472,10 @@
static void ahci_reg_init(AHCIState *s)
{
- s-control_regs.cap=2|(0x1f8); /*2 ports,32 cmd slot*/
- s-control_regs.ghc=131;
- s-control_regs.impl=1;/*2 ports*/
- s-control_regs.version=0x10100;
+ s-control_regs.cap = 3 | (0x1f 8) | (1 20) ; /* 4 ports, 32 command
slots, 1.5 Gb/s */
+ s-control_regs.ghc = 1 31; /* AHCI Enable */
+ s-control_regs.impl = 1; /* Port 0 implemented */
+ s-control_regs.version = 0x1;
}
static void padstr(char *str, const char *src, int len)
@@ -619,19 +632,22 @@
prdt_num=cmd_hdr.opts16;
if(prdt_num) cpu_physical_memory_read(cmd_hdr.tbl_addr+0x80,(uint8_t
*)s-prdt_buf,prdt_num*32);
-
+#ifdef DEBUG_AHCI
+DPRINTF(fis:);
for(i=0;icmd_len;i++)
{
- if((i0xf)==0)DPRINTF(\n%02x:,i);
- DPRINTF(%02x ,fis[i]);
+ if((i0xf)==0) printf(\n%02x:,i);
+ printf(%02x ,fis[i]);
}
+printf(\n);
+#endif
switch(fis[0])
{
case 0x27:
break;
default:
- hw_error(unkonow command fis[0]=%02x fis[1]=%02x
fis[2]=%02x\n,fis[0],fis[1],fis[2]);break;
+ hw_error(unknown command fis[0]=%02x fis[1]=%02x
fis[2]=%02x\n,fis[0],fis[1],fis[2]);break;
}
switch(fis[1])
@@ -641,7 +657,7 @@
case 0:
break;
default:
- hw_error(unkonow command fis[0]=%02x fis[1]=%02x
fis[2]=%02x\n,fis[0],fis[1],fis[2]);break;
+ hw_error(unknown command fis[0]=%02x fis[1]=%02x
fis[2]=%02x\n,fis[0],fis[1],fis[2]);break;
}
if(fis[1]==0)
@@ -684,7 +700,7 @@
pr-irq_stat |= (12);
break;
default:
-hw_error(unkonow command fis[0]=%02x fis[1]=%02x
fis[2]=%02x\n,fis[0],fis[1],fis[2]);break;
+hw_error(unknown command fis[0]=%02x fis[1]=%02x
fis[2]=%02x\n,fis[0],fis[1],fis[2]);break;
}
}
@@ -698,7 +714,7 @@
AHCIState *s = opaque;
ahci_port_regs *pr;
int i,j;
- for(i=0;i2;i++)
+ for(i=0;iSATA_PORTS;i++)
{
pr=s-port_regs[i];
for(j=0;j32 pr-cmd_issue;j++)
@@ -741,23 +757,21 @@
#define PCI_VENDOR_MYDEVICE 0x8086
#define PCI_PRODUCT_MYDEVICE 0x2652
-#define PCI_CLASS_HEADERTYPE_00h 0x00
-
static int pci_ahci_init(PCIDevice *dev)
{
struct ahci_pci_state *d;
d = DO_UPCAST(struct ahci_pci_state, card, dev);
pci_config_set_vendor_id(d-card.config,PCI_VENDOR_MYDEVICE);
pci_config_set_device_id(d-card.config,PCI_PRODUCT_MYDEVICE);
- d-card.config[PCI_COMMAND] = 0x07; /* I/O + Memory */
+ d-card.config[PCI_COMMAND] = PCI_COMMAND_IO | PCI_COMMAND_MEMORY |
PCI_COMMAND_MASTER;
d-card.config[PCI_CLASS_DEVICE] = 0;
d-card.config[0x0b] = 1;//storage
- d-card.config[0x0c] = 0x08; /* Cache line size */
- d-card.config[0x0d] = 0x40; /* Latency timer */
- d-card.config[0x0e] = PCI_CLASS_HEADERTYPE_00h;
- d-card.config[0x3d] = 1;/* interrupt pin 0 */
+ d-card.config[PCI_CACHE_LINE_SIZE] = 0x08; /* Cache line size */
+ d-card.config[PCI_LATENCY_TIMER] = 0x00; /* Latency timer */
+ d-card.config[PCI_HEADER_TYPE] = PCI_HEADER_TYPE_NORMAL;
+ d-card.config[PCI_INTERRUPT_PIN] = 1; /*
[Qemu-devel] Re: Seabios dislikes -M isapc
Kevin O'Connor wrote: On Mon, Feb 08, 2010 at 08:09:17PM +0100, Jan Kiszka wrote: Sebastian Herbszt wrote: Jan Kiszka wrote: Hi, Seabios seems to have some assumptions built in that break when -M isapc is selected. Is this supposed to work or is isapc about to die? SeaBIOS doesn't POST if the F-segment is not writeable [1]. A possible, but IMO wrong fix was posted on the list [2]. [1] http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg01188.html [2] http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg00445.html Indeed, [2] makes it work again. But taking away IO_MEM_ROM really looks like a lazy workaround. I don't know how much Seabios needs to write - can't it use normal RAM for this? Handling a read-only f-segment in SeaBIOS would result in significant code complexity, and some features (like smbios) couldn't be made to work at all. I believe it would be far simpler to add a mechanism for locking/unlocking the f-segment in non-pci mode than it would be to make seabios work with a read-only f-segment. Finally, in the normal pci enabled case, both SeaBIOS and bochs bios will lock the f-segment regardless of how it starts. So, the patch at [1] is pretty harmless and it leads to an overall simplification. On the other hand the F-segment will stay unlocked on isapc. Bochs BIOS comes in two flavours: BIOS-bochs-legacy (rombios) and BIOS-bochs-latest (rombios + rombios32). None of both requires the F-segment to be writeable. BIOS-bochs-legacy doesn't put anything there. BIOS-bochs-latest puts some tables (e.g. mp, acpi) there unless BX_USE_EBDA_TABLES is set. - Sebastian
[Qemu-devel] Re: Seabios dislikes -M isapc
Jan Kiszka wrote: Hi, Seabios seems to have some assumptions built in that break when -M isapc is selected. Is this supposed to work or is isapc about to die? SeaBIOS doesn't POST if the F-segment is not writeable [1]. A possible, but IMO wrong fix was posted on the list [2]. [1] http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg01188.html [2] http://lists.gnu.org/archive/html/qemu-devel/2009-12/msg00445.html - Sebastian
[Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
Anthony Liguori wrote: On 12/21/2009 01:43 PM, Gleb Natapov wrote: Please stop thinking so :) Especially about user driven upgrades. Why combine disadvantages of vitalization with pain of physical HW management? Or may be next step will be to require uploading of CPU microcode to take advantage of KVM/tcg bug fixes? I think your real argument boils down to that we can be better than real hardware therefore we should. I actually agree with you for 90% of users. Let me summarize where I'm at. - We are currently horribly broken with respect to how we handle roms particularly with respect to backwards compatibility - We must support running older roms on newer qemu at least within a stable series (because of live migration) - We need a mechanism to include roms specific to a machine type - Probably by default, we want new roms to be used by guests at some well defined time (either first reset or first power-down/start-up) Start-up sounds good. - We ought to make all roms live in qemu_ram_alloc()'d memory and we ought to change that api to contain contexts, this will make sure rom live migration works properly. The best approach I can think of is to introduce an nvram mechanism. A tar file probably work really well. If a user doesn't supply an explicit -nvram, we could create a temporary file and delete it. If the nvram is empty, we populate it with whatever the appropriate roms are for the machine type. I would also suggest that we support the guest updating roms on its own (through fw_cfg). I can think of a number of reasons for this. For instance, why shouldn't a guest be able to update the gPXE associated with the network card? The code runs entirely in the guest so there's no harm to the host. You mean the nvram file on the host or in memory? Will there be a size limit? Allow a guest to do this sort of thing takes pressure off of the management system so particularly in an environment like a cloud, I think this could prove very useful. It might not be desired and make support efforts harder. Could have security implications too. It could be possible to add an option to -nvram to make it re-read roms from disk every reboot. I really think this is a bad idea though, I'd like to hear more people comment on it but it's certainly technically feasible. - Sebastian
[Qemu-devel] Re: Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
Gleb Natapov wrote: On Mon, Dec 21, 2009 at 07:24:43PM +0100, Sebastian Herbszt wrote: Does any OS (Windows?) depend on the tables the bios creates (e.g. smbios) for licensing? It would be ugly if Windows wants you to re-activate after a reboot following a migration to newer qemu version and therefore possibly changed tables due to newer bios. I am not talking about OS visible stuff. How do you want to avoid OS visible changes if the bios is reread on each reset? People can upgrade/change their bios in the pc-bios directory and bad things could happen if its reloaded on each reset. - Sebastian
[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
Anthony Liguori wrote: On 12/21/2009 12:24 PM, Sebastian Herbszt wrote: As stated before i don't like the idea of automagically upgrading the firmware on reset, e.g. after a live migration to a newer qemu version. You have explained that qemu-kvm needs this in order to work with live migration and changed hw support because of bug fixes. Is this only needed in the kvm case? It's not needed, it's desired. The same case can be made for real hardware (automated firmware updates). Tho on real hardware those updates are initiated by someone and not automagic. Does any OS (Windows?) depend on the tables the bios creates (e.g. smbios) for licensing? It would be ugly if Windows wants you to re-activate after a reboot following a migration to newer qemu version and therefore possibly changed tables due to newer bios. Yes, and this is a good point. ACPI table changes can absolutely cause re-activation. If we migrate from 0.12 - 0.13 and make major changes to the ACPI tables in 0.13, then it's very likely that will result in problems for Windows guests. Another problem could be on guest resume from S3 after migration if the bios or acpi tables change. I really think that we need to snapshot the FW and store it with the guest state. If we switch all FW to be allocated with qemu_ram_alloc() and we use an id mechanism, then this will Just Work for savevm based snapshots and live migration. However, for it to work with -M pc-0.11 started from a cold boot, we need an nvram file. We probably want to make available versioned nvram files from each release too. So the idea is to store the bios/option roms in the guest state and read them from there on reset or power cycle? - Sebastian
[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loadingoverhaul.
Gleb Natapov wrote: On Mon, Dec 21, 2009 at 08:39:03PM +0100, Sebastian Herbszt wrote: Anthony Liguori wrote: On 12/21/2009 12:24 PM, Sebastian Herbszt wrote: As stated before i don't like the idea of automagically upgrading the firmware on reset, e.g. after a live migration to a newer qemu version. You have explained that qemu-kvm needs this in order to work with live migration and changed hw support because of bug fixes. Is this only needed in the kvm case? It's not needed, it's desired. The same case can be made for real hardware (automated firmware updates). Tho on real hardware those updates are initiated by someone and not automagic. Because on real hardware it is impossible to do it differently may be? My cable TV provider upgrades FW on my set-top-box automatically. Your cable TV provider does likely also control what beside the FW (if anything) runs on your set-top-box. So he can verify the FW upgrade doesn't break anything in the field. That pre-deployment verification is not possible in non closed environments. Does any OS (Windows?) depend on the tables the bios creates (e.g. smbios) for licensing? It would be ugly if Windows wants you to re-activate after a reboot following a migration to newer qemu version and therefore possibly changed tables due to newer bios. Yes, and this is a good point. ACPI table changes can absolutely cause re-activation. If we migrate from 0.12 - 0.13 and make major changes to the ACPI tables in 0.13, then it's very likely that will result in problems for Windows guests. Another problem could be on guest resume from S3 after migration if the bios or acpi tables change. On resume from S3 BIOS doesn't recreate ACPI tables. ACPI tables are not part of a BIOS image and in fact OS can reuse memory ACPI tables reside in. So such problem definitely does not exist. If the OS recycles the whole memory which holds the ACPI tables i am not sure how the BIOS will find the firmware_waking_vector. Maybe the OS can only use the memory which holds the DSDT? Anyway, will the guest even resume from S3 if the hw changed on migration and the bios doesn't know how to init it? - Sebastian
Re: [Qemu-devel] ne2k_isa: how to specify a custom iobase and irq?
Gerd Hoffmann wrote: On 12/18/09 07:12, Markus Armbruster wrote: Sebastian Herbsztherb...@gmx.de writes: The default iobase and irq for the ne2k_isa card are 0x300 and 9. It should be possible to override both using the -net syntax like -net nic,model=ne2k_isa,irq=5,iobase=0x280. -device ne2k_isa,irq=5,iobase=0x280 Also needs vlan=0, otherwise you'll end up with an unconnected nic. Shouldn't vlan have a default value of 0 like it does with the -net syntax? - Sebastian
Re: [Qemu-devel] ne2k_isa: how to specify a custom iobase and irq?
Markus Armbruster wrote: Sebastian Herbszt herb...@gmx.de writes: The default iobase and irq for the ne2k_isa card are 0x300 and 9. It should be possible to override both using the -net syntax like -net nic,model=ne2k_isa,irq=5,iobase=0x280. -device ne2k_isa,irq=5,iobase=0x280 Shouldn't this also be possible with the -net syntax? It does accept addr which is pci specific. - Sebastian
[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
Anthony Liguori wrote: Sebastian Herbszt wrote: Gerd Hoffmann wrote: On 12/18/09 17:42, Anthony Liguori wrote: Do we need to do something for -M pc-0.11? Like loading the pci roms via fw_cfg too so the guest doesn't see the new pci rom bar? Yes, we do. We can fix that problem as a stable-0.12 update though. Right now, migration with pc-0.11 is broken in other areas too. Ok. When it is fine to defer this to stable-0.12 then I have no objections to merge it for 0.12 (assuming the seabios folks ack+merge the seabios changes). 0.12 will contain known regressions? Migrating between versions is not a regression. If SeaBIOS would not have any regressions compared to Bochs BIOS then maybe. Does it? I'm not aware of any SeaBIOS regressions. E.g. BIOS32 and INT 15h function 89h. Indeed. In theory even the switch of the option rom loading should work just fine. After migration old bios and roms are still in memory, the next reboot will be the world switch to new seabios, new roms, new way to deploy roms and everything. Automagical world switch on reboot sounds like a nightmare. The VM environment should be stable during reboots and only change if requested by the user. That's extremely difficult to support. Isn't this what VMotion supports? - Sebastian
Re: [Qemu-devel] ne2k_isa: how to specify a custom iobase and irq?
Markus Armbruster wrote: Sebastian Herbszt herb...@gmx.de writes: The default iobase and irq for the ne2k_isa card are 0x300 and 9. It should be possible to override both using the -net syntax like -net nic,model=ne2k_isa,irq=5,iobase=0x280. -device ne2k_isa,irq=5,iobase=0x280 If i specify -net nic,model=pcnet i end up only with a pcnet nic. With the above syntax i get a e1000 and a ne2k_isa. It also loads the e1000 rom. - Sebastian
[Qemu-devel] Re: [SeaBIOS] [PATCH 0/8] option rom loading overhaul.
Gerd Hoffmann wrote: On 12/18/09 17:42, Anthony Liguori wrote: Do we need to do something for -M pc-0.11? Like loading the pci roms via fw_cfg too so the guest doesn't see the new pci rom bar? Yes, we do. We can fix that problem as a stable-0.12 update though. Right now, migration with pc-0.11 is broken in other areas too. Ok. When it is fine to defer this to stable-0.12 then I have no objections to merge it for 0.12 (assuming the seabios folks ack+merge the seabios changes). 0.12 will contain known regressions? Note that I'll be offline for x-mas and newyear starting tomorrow, so I will not be able to work on that until January. It's really unclear to me the best way to handle live migration. The rom_offset is not enough because unfortunately it's not stable after invocations of qemu. I think we're going to have to actually save the some contents with the PCIDevices. With hotplug this will become a issue indeed. Is 0.11 - 0.12 migration supposed to work? That could become quite nasty too. But maybe that is impossible anyway due to the switch to seabios? In theory, it should work. SeaBIOS should not be a guest visible change because the guest should not depend on what BIOS we're using. If SeaBIOS would not have any regressions compared to Bochs BIOS then maybe. Indeed. In theory even the switch of the option rom loading should work just fine. After migration old bios and roms are still in memory, the next reboot will be the world switch to new seabios, new roms, new way to deploy roms and everything. Automagical world switch on reboot sounds like a nightmare. The VM environment should be stable during reboots and only change if requested by the user. - Sebastian
Re: [Qemu-devel] ne2k_isa: how to specify a custom iobase and irq?
Anthony Liguori wrote: Sebastian Herbszt wrote: Markus Armbruster wrote: Sebastian Herbszt herb...@gmx.de writes: The default iobase and irq for the ne2k_isa card are 0x300 and 9. It should be possible to override both using the -net syntax like -net nic,model=ne2k_isa,irq=5,iobase=0x280. -device ne2k_isa,irq=5,iobase=0x280 If i specify -net nic,model=pcnet i end up only with a pcnet nic. With the above syntax i get a e1000 and a ne2k_isa. It also loads the e1000 rom. Can you supply the full command lines. I'm a little confused about what you're reporting. qemu -device ne2k_isa,irq=10 and info qtree has e1000 and ne2k_isa. qemu -net nic,model=pcnet and info qtree has only pcnet. Maybe because of hw/pc.c: if (!pci_enabled || (nd-model strcmp(nd-model, ne2k_isa) == 0)) pc_init_ne2k_isa(nd); else pci_nic_init_nofail(nd, e1000, NULL); - Sebastian
Re: [Qemu-devel] ne2k_isa: how to specify a custom iobase and irq?
Anthony Liguori wrote: Sebastian Herbszt wrote: Gerd Hoffmann wrote: On 12/18/09 07:12, Markus Armbruster wrote: Sebastian Herbsztherb...@gmx.de writes: The default iobase and irq for the ne2k_isa card are 0x300 and 9. It should be possible to override both using the -net syntax like -net nic,model=ne2k_isa,irq=5,iobase=0x280. -device ne2k_isa,irq=5,iobase=0x280 Also needs vlan=0, otherwise you'll end up with an unconnected nic. Shouldn't vlan have a default value of 0 like it does with the -net syntax? No, you don't actually have to tie it to a vlan. Actually you have to else networking doesn't work at all. Without specifying vlan with the -device syntax you end up with vlan=null and not vlan=0 with info qtree. - Sebastian
Re: Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)
Gerd Hoffmann wrote: On 12/15/09 23:51, Sebastian Herbszt wrote: Qemu will map rom1.bin to PC_ROM_MIN_OPTION (0xc8000) and map rom2.bin to 0xd. No. rom1.bin will be loaded to max(0xc8000, 0xc + cirrus-bios-size) aligned to 2k, which (with cirrus) is 0xc9. My bad - for some reason i assumed the vga bios has to be 32k max. rom2.bin will be loaded after rom1.bin (also 2k aligned), so the address will depend on rom1.bin size. Either qemu will map vga bios to PC_ROM_MIN_VGA (0xc) or SeaBIOS will map it there (with pci 3.0 it could map it somewhere else, but i doubt thats a good idea). In case the vga bios size is below 0x8000, some rom space is lost. Because it is larger than 0x8000 option roms will be overwritten when loaded to 0xc8000 SeaBIOS will scan the option rom space starting at PC_ROM_MIN_OPTION and adjust its RomEnd in case a rom is found. Then it will start the pci scan and map pci option roms after RomEnd. Doesn't fly. I think either qemu or seabios should load *all* roms. I think the idea to provide non-pci roms via fw_cfg and let seabios load them is the best idea we had so far. I don't think that is what happens on real hardware with ISA cards which have an option rom. Therefore i suggest inverting some of my suggestion from above and put the qemu loaded roms not at the beginning of the option rom space, but starting at the end of it, e.g. rom1.bin below 0xe and rom2.bin below rom1.bin (considering rom length and alignment). SeaBIOS could then locate those roms and setup it's RomEnd (max. pci rom loading address) according to it. - Sebastian
Re: Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)
Anthony Liguori wrote: Sebastian Herbszt wrote: What about isapc? Or (pci)pc with isa card? I'm not sure how the bios enumerates isa option roms on bare metal. Let's give this a shot: A typical isa expansion card seems to have a jumper to select a I/O port, IRQ and boot rom location, e.g. 280, 10, cc00. In its default configuration the PMC directs access to 0xc-0xd to pci and doesn't respond to those. Those accesses are forwarded to isa. Now they can be decoded by the expansion card. I assume isa option roms just appear to be there and the bios only needs to scan for them. This seems to be exactly what qemu does right now with -option-rom. - Sebastian
[Qemu-devel] ne2k_isa: how to specify a custom iobase and irq?
The default iobase and irq for the ne2k_isa card are 0x300 and 9. It should be possible to override both using the -net syntax like -net nic,model=ne2k_isa,irq=5,iobase=0x280. - Sebastian
Re: Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)
Anthony Liguori wrote: Sebastian Herbszt wrote: Anthony Liguori wrote: Gerd Hoffmann wrote: I'm more worried about the CONFIG_OPTIONROMS_DEPLOYED patches for seabios, although I don't fully understand what they are doing. There are non-pci option roms (linuxboot, multiboot, extboot) which qemu will continue to deploy the way roms are deployed today. That's a good point. Need to think about how to best handle that. SeaBIOS supports up to two static option roms so maybe what we need to do is make use of that mechanism for things like linuxboot/extboot. Keep loading custom roms (e.g. from -option-rom) with rom_add_file starting at 0xc8000. Modify SeaBIOS to scan the memory range for pre-deployed option roms before deploying PCI roms. SeaBIOS will find the last pre-deployed rom and have a starting address for deploying PCI roms. This will keep ISA option roms working. If we make -option-rom appear through a PCI device, then DDIM will work properly for those roms. Also, it would be nice if Linux boot used a PCI device instead of fw_cfg to load the kernel into memory. What about isapc? Or (pci)pc with isa card? Keeping the possibility of having option roms pre-deployed also allows using Bochs BIOS until SeaBIOS has no more regressions. - Sebastian
Re: Proper support for PCI-based option rom loading (was Re: [Qemu-devel] Re: qdev property bug?)
Anthony Liguori wrote: Michael S. Tsirkin wrote: I think it's stable-0.12 material because it's badly broken right now I thought the rule was no guest visible changes in stable series? Yeah, good point, so we need to figure out something for 0.12.0. Sebastian's suggestion of loading roms from 0xc first and then from PCI devices is a good one, but I think the problem with that is that the roms don't necessarily have to be contiguous in that space. For instance, the lower bios portions are technically in the rom area which leaves a big gap in the middle. I don't think i get your objection - mind to explain it a little bit? My suggestion was like this: PCI pc and -option-rom rom1.bin -option-rom rom2.bin Qemu will map rom1.bin to PC_ROM_MIN_OPTION (0xc8000) and map rom2.bin to 0xd. Either qemu will map vga bios to PC_ROM_MIN_VGA (0xc) or SeaBIOS will map it there (with pci 3.0 it could map it somewhere else, but i doubt thats a good idea). In case the vga bios size is below 0x8000, some rom space is lost. SeaBIOS will scan the option rom space starting at PC_ROM_MIN_OPTION and adjust its RomEnd in case a rom is found. Then it will start the pci scan and map pci option roms after RomEnd. - Sebastian
Re: [Qemu-devel] Re: qdev property bug?
Anthony Liguori wrote: Michael S. Tsirkin wrote: Further, we should error out when device is added. Doing this during boot is way too late, management won't be able to understand such errors and won't be able to recover. I don't quite understand this. In 0.11, we never loaded option roms unless a user specified -boot n. If a user specified -boot n and used more than one nic type, I'm fairly certain it would error out during start up because it would run out of option rom space. Maybe it required three types of nics, but the point still remains. I think it used to be possible to have two different nic types and only load one rom, e.g. -net nic,model=pcnet -net nic,model=e1000 -option-rom e1000.rom Then use the boot menu to select the e1000 nic. In 0.12, we always load the option rom for a PCI device. An easy solution here would be to just gracefully handle the case where we ran out of option rom space and (silently) stop loading additional roms. With respect to -boot n, it makes the behavior buggy (you cannot boot from the second nic) but my original point is that that is not a regression from 0.11. Even if i repeat myself [1] i suggest putting an option-rom loading flag to the -net option: -net nic,model=e1000,rom=[on,off,e1000.bin] For 0.13, we should probably allow a user to suppress option rom loading for a given PCI device. The limited space is a pretty good justification for that. The default behaviour should be not loading option-roms; users should request those. [1] http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg01095.html - Sebastian
Re: [Qemu-devel] Re: qdev property bug?
Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 08:12:48PM +0100, Sebastian Herbszt wrote: Anthony Liguori wrote: Michael S. Tsirkin wrote: Further, we should error out when device is added. Doing this during boot is way too late, management won't be able to understand such errors and won't be able to recover. I don't quite understand this. In 0.11, we never loaded option roms unless a user specified -boot n. If a user specified -boot n and used more than one nic type, I'm fairly certain it would error out during start up because it would run out of option rom space. Maybe it required three types of nics, but the point still remains. I think it used to be possible to have two different nic types and only load one rom, e.g. -net nic,model=pcnet -net nic,model=e1000 -option-rom e1000.rom Then use the boot menu to select the e1000 nic. In 0.12, we always load the option rom for a PCI device. An easy solution here would be to just gracefully handle the case where we ran out of option rom space and (silently) stop loading additional roms. With respect to -boot n, it makes the behavior buggy (you cannot boot from the second nic) but my original point is that that is not a regression from 0.11. Even if i repeat myself [1] i suggest putting an option-rom loading flag to the -net option: -net nic,model=e1000,rom=[on,off,e1000.bin] For 0.13, we should probably allow a user to suppress option rom loading for a given PCI device. The limited space is a pretty good justification for that. The default behaviour should be not loading option-roms; users should request those. [1] http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg01095.html - Sebastian I am not sure I agree. This is common for PXE and I think makes sense there, but I think this might not make sense for VGA rom or e.g. scsi. I think it makes sense at least for nic and scsi. It might even be useful for vga, e.g. choose between pci/onboard and agp vga and only load one of both roms. - Sebastian
Re: [Qemu-devel] Re: qdev property bug?
Anthony Liguori wrote: Sebastian Herbszt wrote: Anthony Liguori wrote: Michael S. Tsirkin wrote: Further, we should error out when device is added. Doing this during boot is way too late, management won't be able to understand such errors and won't be able to recover. I don't quite understand this. In 0.11, we never loaded option roms unless a user specified -boot n. If a user specified -boot n and used more than one nic type, I'm fairly certain it would error out during start up because it would run out of option rom space. Maybe it required three types of nics, but the point still remains. I think it used to be possible to have two different nic types and only load one rom, e.g. -net nic,model=pcnet -net nic,model=e1000 -option-rom e1000.rom Then use the boot menu to select the e1000 nic. That's a super hack :-) The fact that works is pure luck. Super hack? Maybe. Pure luck - no. Even if, it's still a regression if that's no longer possible. In 0.12, we always load the option rom for a PCI device. An easy solution here would be to just gracefully handle the case where we ran out of option rom space and (silently) stop loading additional roms. With respect to -boot n, it makes the behavior buggy (you cannot boot from the second nic) but my original point is that that is not a regression from 0.11. Even if i repeat myself [1] i suggest putting an option-rom loading flag to the -net option: -net nic,model=e1000,rom=[on,off,e1000.bin] Well it ought to be a qdev property and it ought to be applicable to every PCI device. And ISA too. For 0.13, we should probably allow a user to suppress option rom loading for a given PCI device. The limited space is a pretty good justification for that. The default behaviour should be not loading option-roms; users should request those. I disagree. A user should not have to decide whether they want PXE boot or not when they create a VM. The less decisions a user has to make up front the easier qemu is to use. If i want PXE boot on my computer, i have to enter the BIOS and enable it. If qemu starts to automagically enable stuff people might want to use, some people will end up with long command lines just to disable it again. - Sebastian
Re: [Qemu-devel] Re: qdev property bug?
Gerd Hoffmann wrote: On 12/14/09 21:20, Michael S. Tsirkin wrote: So far, it's not clear to me that anyone has demonstrated how this is harmful for people that don't want pxe booting. Assuming we fix the bug about rom loading, then there's really no impact to users. Fix (v2) is on the list already. PXE booting might have security impact. You do not want to do this if you are on a hostile network. Option rom loaded doesn't imply pxe boot will be tried. It only means PXE boot can be selected, either via -boot order=[something with 'n' here] or via -boot menu=on + F12 + picking menu entry By default qemu doesn't try to PXE-boot, even if no other bootable device is available. Tho this depends on the option rom, e.g. Etherboot hooks INT 19h. - Sebastian
Re: [Qemu-devel] Re: qdev property bug?
Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 09:32:30PM +0100, Gerd Hoffmann wrote: On 12/14/09 21:20, Michael S. Tsirkin wrote: So far, it's not clear to me that anyone has demonstrated how this is harmful for people that don't want pxe booting. Assuming we fix the bug about rom loading, then there's really no impact to users. Fix (v2) is on the list already. PXE booting might have security impact. You do not want to do this if you are on a hostile network. Option rom loaded doesn't imply pxe boot will be tried. It only means PXE boot can be selected, either via -boot order=[something with 'n' here] or via -boot menu=on + F12 + picking menu entry By default qemu doesn't try to PXE-boot, even if no other bootable device is available. cheers, Gerd I guess so. But then, why are we loading it in BIOS and wasting memory? Let's only shadow the ROM when PXE is selected? Some DOS-based software might need the UMA (RAM UMB). - Sebastian
Re: [Qemu-devel] Re: qdev property bug?
Anthony Liguori wrote: Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 02:43:38PM -0600, Anthony Liguori wrote: Because it can be selected by the user via the menu and because it can be selected at runtime via the boot_set monitor command. Yes, but it's not like we have nowhere to store them. We could shadow ROM when it is actually needed. I believe the way this works with real BIOSes is that the rom is initially loaded somewhere outside of the 1M region and it's init is executed. It's then the rom's job to execute it's initialization. Afterwards, the bios copies the rom into the 1M region. This is how PMM works. The idea is that while outside of the 1M region, the rom can eliminate unnecessary code and update it's own header to reflect it's new, improved code size. It's more like the following (pci 2.2): - enable and map expansion rom bar - find rom and copy to ram (0xC000-0xD) - disable expansion rom bar - call rom init - rom might resize itself (DDIM) - write protect rom PMM doesn't have (anything?) to do with this and the rom doesn't have to be loaded outside of 1MB. I don't know whether gpxe will actually reduce it's size as part of this process so it may not matter. After running the option roms init vector, the rom must be relocated into the option rom space though so even this technique is not a solution unless gpxe is able to discard a lot of bits it doesn't need. gPXE supports DDIM. Also, the comment about wasting memory not quite accurate. The memory region in question is only used for roms. If we didn't put roms there, it would go to waste. Some BIOSes I saw have an option not to use the first 1M for rom shadowing :). Seriously as you see we are already running out of that 1M. I think that's just the first phase of rom loading. - Sebastian
Re: [Qemu-devel] Re: qdev property bug?
Anthony Liguori wrote: Sebastian Herbszt wrote: Anthony Liguori wrote: Michael S. Tsirkin wrote: On Mon, Dec 14, 2009 at 02:43:38PM -0600, Anthony Liguori wrote: Because it can be selected by the user via the menu and because it can be selected at runtime via the boot_set monitor command. Yes, but it's not like we have nowhere to store them. We could shadow ROM when it is actually needed. I believe the way this works with real BIOSes is that the rom is initially loaded somewhere outside of the 1M region and it's init is executed. It's then the rom's job to execute it's initialization. Afterwards, the bios copies the rom into the 1M region. This is how PMM works. The idea is that while outside of the 1M region, the rom can eliminate unnecessary code and update it's own header to reflect it's new, improved code size. It's more like the following (pci 2.2): - enable and map expansion rom bar - find rom and copy to ram (0xC000-0xD) - disable expansion rom bar - call rom init - rom might resize itself (DDIM) - write protect rom PMM doesn't have (anything?) to do with this and the rom doesn't have to be loaded outside of 1MB. Well PMM is used to do the resizing. You can shrink in-place with rom layout like [header, run-time code, init code]. The init code can then just be truncated. You only need PMM if you can't manage with the allocated memory. But it sounds like the problem is that we should not be loading the roms into the rom space. Instead, seabios should be mapping them into that space, running the rom init, then moving to the next one. I suspect we need to either need to implement the proper pci interface for seabios to do this or we need to provide a pv channel. I suggested a proper pci interface before [1]; please no pv channel. [1] http://lists.gnu.org/archive/html/qemu-devel/2009-11/msg01823.html - Sebastian
Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios
Gleb Natapov wrote: On Fri, Nov 27, 2009 at 09:42:19PM +0100, Sebastian Herbszt wrote: Gleb Natapov wrote: On Thu, Nov 26, 2009 at 09:55:28PM +0100, Sebastian Herbszt wrote: Gleb Natapov wrote: On Wed, Nov 25, 2009 at 11:04:20PM +0100, Sebastian Herbszt wrote: Gleb Natapov wrote: On Wed, Nov 25, 2009 at 06:09:51AM +, Jamie Lokier wrote: Gleb Natapov wrote: But QEMU is used to run old OSes too. That's OK. I don't expect BIOS to be reloaded if OS restart by jumping to BIOS reset code. That's good then. What about DOS and DOS-extender programs which do a soft reset by triple-faulting the CPU (see Sebastian's notes on i440FX behaviour), and asking the keyboard controller? Both of those methods are used by DOS and DOS-extender programs to switch from protected mode to real mode. Keyboard controller was used originally, but then someone figured out that triple fault can be used (on most PCs) and is faster. The switch to real mode is done by writing somewhere the BIOS checks, so the BIOS just branches back to the application. If offset 0x0f in CMOS contains 0x0a then BIOS jumps to address stored in memory address 0x467. I think that may imply it has to be a soft reset as described by Sebastian in the i440FX description, and I would think the BIOS must not be reloaded. Reading ich9 spec I see that on this chipset it is possible to configure what kind of reset triple fault generates. Make it not very reliable. Was this triple fault trick only needed on 286 anyway? It seems to be INIT# vs. PLTRST# (Platform Reset). On the latter all devices are reset. Table 5-40 is pretty descriptive and there seem to be way too many ways to trigger a reset. I think PLTRST# is used when a reset is triggered by the ACPI method. Fortunatelly we don't have to implement this (yet) since it's not available on the 440fx. Using triple fault to reset is used on 286+. Triple fault use as a reset is widely used today. Use of triple fault to switch from protected mode to real mode was specific for 286. Whether triple fault is used just for a reset or to switch from protected mode to real mode is irrelevant, because from the hardware point of view this is exactly the same reset. And old applications can still use this method on new CPUs. If triple fault is used just for a reset we can do hard reset like we do now. It may violate HW spec but it works. Bad things might happen tho, because some of the hardware state is reset even if it should not be. If some OS does program the PIIX3 PIRQx route control registers and then uses triple fault to return from protected mode and qemu does reset those registers back to default values, the OS might not like it when the BIOS resumes it. We already concluded that return to PM by triple fault is not something we want to support. It was needed only on 286 and QEMU doesn't even support 286 cpu emulation. I don't think you can conclude this because it's not an optional feature. Whether qemu emulates a 286 cpu is irrelevant in this case because the hardware qemu emulates has to be backward compatible. But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard controller method is used and the word asking for a branch back to the application has not been set. Because that's how a modern OS (if not using ACPI) asks for a system reset. Do you think the above is (a) correct, and (b) what's implemented? Do different things during reset depending on CMOS values doesn't sound right to me. I don't know what is implemented right now. I thought that we reload BIOS on reset. Currently the BIOS seems to be only loaded once and not reloaded during the life time of a VM. I don't think there is a notion of BIOS reload on real hardware. CPU access to it is either directed to the rom (power-up configuration, all those fancy reset conditions) or to ram. Reloading BIOS in QEMU is needed for a reason not present on real HW. Think about migration from old QEMU to new QEMU. Suppose old BIOS can't properly initialize new QEMU. Then next reboot after migration will fail since old BIOS will be used. Do you mean live migration between different QEMU versions? That doesn't sound safe, especially if the hardware changes on reboot. Does the competition support this? Of course. The ability to upgrade cluster transparently is a major feature. So migration from older version to newer one is must to have. I am wondering how this works on VMware. A VM has a virtualHW.version assigned, so the hardware doesn't automagically change on software upgrades. You have to power off the VM and request an upgrade for it to change. They also likely have a fairly stable BIOS version. If a VM is created on ESX 3.5 with virtualHW.version 4 and live migrated to ESX 4.0, which also supports virtualHW.version 7, i would assume it still has the same hardware on a hard reset and even if you shutdown and restart it, since no hardware upgrade was requested by the user. If the hardware has been
Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios
Jamie Lokier wrote: Sebastian Herbszt wrote: We could have qemu do a soft reset (not reload rom) on a triple fault or keyboard controller reset, and then have SeaBIOS request a hard reset (have qemu reload rom) if it detects a soft reset that is not a resume request. I'm also not sure what qemu does today. I don't think such an interface would add a long time benefit and would prefer a proper solution which will not tie seabios even more to qemu. One day it might be possible to run a commercial BIOS on qemu, just like it is possible on Bochs. Adding this interface might prevent that. What does a real BIOS on real hardware do? Do real BIOSes make a decision as described above, and we're just assuming they don't? A real BIOS gets started, checks CMOS shutdown status byte and decides whether to POST or resume execution somewhere else. One way to answer may be: On a real PC with i440FX, what kind of reset are the different reset methods (triple fault, keyboard etc.) normally configured to do? Should be those power on - hard reset CPU shutdown bus cycle - soft reset TRC register (BISTE=0, SHRE=0, RCPU=1) - soft reset TRC register (BISTE=0, SHRE=1, RCPU=1) - hard reset keyboard controller - soft reset I/O port 92h - soft reset RC register (SRST=0, RCPU=1) - soft reset RC register (SRST=1, RCPU=1) - hard reset IIRC, HIMEM.SYS in DOS must use at least one of the switch-to-real-mode methods to work, and that driver is needed by Windows 3/3.11/95/98/ME, but I'm a bit vague on the details. The highmem.sys version i got here seems to use CR0 to switch between real and protected mode. I can't find where/if it loads a hosed IDT. - Sebastian
Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios
Gleb Natapov wrote: On Thu, Nov 26, 2009 at 09:55:28PM +0100, Sebastian Herbszt wrote: Gleb Natapov wrote: On Wed, Nov 25, 2009 at 11:04:20PM +0100, Sebastian Herbszt wrote: Gleb Natapov wrote: On Wed, Nov 25, 2009 at 06:09:51AM +, Jamie Lokier wrote: Gleb Natapov wrote: But QEMU is used to run old OSes too. That's OK. I don't expect BIOS to be reloaded if OS restart by jumping to BIOS reset code. That's good then. What about DOS and DOS-extender programs which do a soft reset by triple-faulting the CPU (see Sebastian's notes on i440FX behaviour), and asking the keyboard controller? Both of those methods are used by DOS and DOS-extender programs to switch from protected mode to real mode. Keyboard controller was used originally, but then someone figured out that triple fault can be used (on most PCs) and is faster. The switch to real mode is done by writing somewhere the BIOS checks, so the BIOS just branches back to the application. If offset 0x0f in CMOS contains 0x0a then BIOS jumps to address stored in memory address 0x467. I think that may imply it has to be a soft reset as described by Sebastian in the i440FX description, and I would think the BIOS must not be reloaded. Reading ich9 spec I see that on this chipset it is possible to configure what kind of reset triple fault generates. Make it not very reliable. Was this triple fault trick only needed on 286 anyway? It seems to be INIT# vs. PLTRST# (Platform Reset). On the latter all devices are reset. Table 5-40 is pretty descriptive and there seem to be way too many ways to trigger a reset. I think PLTRST# is used when a reset is triggered by the ACPI method. Fortunatelly we don't have to implement this (yet) since it's not available on the 440fx. Using triple fault to reset is used on 286+. Triple fault use as a reset is widely used today. Use of triple fault to switch from protected mode to real mode was specific for 286. Whether triple fault is used just for a reset or to switch from protected mode to real mode is irrelevant, because from the hardware point of view this is exactly the same reset. And old applications can still use this method on new CPUs. If triple fault is used just for a reset we can do hard reset like we do now. It may violate HW spec but it works. Bad things might happen tho, because some of the hardware state is reset even if it should not be. If some OS does program the PIIX3 PIRQx route control registers and then uses triple fault to return from protected mode and qemu does reset those registers back to default values, the OS might not like it when the BIOS resumes it. But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard controller method is used and the word asking for a branch back to the application has not been set. Because that's how a modern OS (if not using ACPI) asks for a system reset. Do you think the above is (a) correct, and (b) what's implemented? Do different things during reset depending on CMOS values doesn't sound right to me. I don't know what is implemented right now. I thought that we reload BIOS on reset. Currently the BIOS seems to be only loaded once and not reloaded during the life time of a VM. I don't think there is a notion of BIOS reload on real hardware. CPU access to it is either directed to the rom (power-up configuration, all those fancy reset conditions) or to ram. Reloading BIOS in QEMU is needed for a reason not present on real HW. Think about migration from old QEMU to new QEMU. Suppose old BIOS can't properly initialize new QEMU. Then next reboot after migration will fail since old BIOS will be used. Do you mean live migration between different QEMU versions? That doesn't sound safe, especially if the hardware changes on reboot. Does the competition support this? Of course. The ability to upgrade cluster transparently is a major feature. So migration from older version to newer one is must to have. I am wondering how this works on VMware. A VM has a virtualHW.version assigned, so the hardware doesn't automagically change on software upgrades. You have to power off the VM and request an upgrade for it to change. They also likely have a fairly stable BIOS version. If a VM is created on ESX 3.5 with virtualHW.version 4 and live migrated to ESX 4.0, which also supports virtualHW.version 7, i would assume it still has the same hardware on a hard reset and even if you shutdown and restart it, since no hardware upgrade was requested by the user. If the hardware has been upgraded it can't be migrated back to the ESX 3.5 host. The BIOS might be special tho. It does likely support both hardware versions. If the VM got migrated, the old BIOS should be run and reloaded as long as the VM has not been destroyed / stopped. This should happen even if the VM has been hard reset. Now if the VM is shutdown and recreated on the new host it might be ok to load the new BIOS even if the hardware version was not upgraded
Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios
Gleb Natapov wrote: On Wed, Nov 25, 2009 at 11:04:20PM +0100, Sebastian Herbszt wrote: Gleb Natapov wrote: On Wed, Nov 25, 2009 at 06:09:51AM +, Jamie Lokier wrote: Gleb Natapov wrote: But QEMU is used to run old OSes too. That's OK. I don't expect BIOS to be reloaded if OS restart by jumping to BIOS reset code. That's good then. What about DOS and DOS-extender programs which do a soft reset by triple-faulting the CPU (see Sebastian's notes on i440FX behaviour), and asking the keyboard controller? Both of those methods are used by DOS and DOS-extender programs to switch from protected mode to real mode. Keyboard controller was used originally, but then someone figured out that triple fault can be used (on most PCs) and is faster. The switch to real mode is done by writing somewhere the BIOS checks, so the BIOS just branches back to the application. If offset 0x0f in CMOS contains 0x0a then BIOS jumps to address stored in memory address 0x467. I think that may imply it has to be a soft reset as described by Sebastian in the i440FX description, and I would think the BIOS must not be reloaded. Reading ich9 spec I see that on this chipset it is possible to configure what kind of reset triple fault generates. Make it not very reliable. Was this triple fault trick only needed on 286 anyway? It seems to be INIT# vs. PLTRST# (Platform Reset). On the latter all devices are reset. Table 5-40 is pretty descriptive and there seem to be way too many ways to trigger a reset. I think PLTRST# is used when a reset is triggered by the ACPI method. Fortunatelly we don't have to implement this (yet) since it's not available on the 440fx. Using triple fault to reset is used on 286+. Triple fault use as a reset is widely used today. Use of triple fault to switch from protected mode to real mode was specific for 286. Whether triple fault is used just for a reset or to switch from protected mode to real mode is irrelevant, because from the hardware point of view this is exactly the same reset. And old applications can still use this method on new CPUs. But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard controller method is used and the word asking for a branch back to the application has not been set. Because that's how a modern OS (if not using ACPI) asks for a system reset. Do you think the above is (a) correct, and (b) what's implemented? Do different things during reset depending on CMOS values doesn't sound right to me. I don't know what is implemented right now. I thought that we reload BIOS on reset. Currently the BIOS seems to be only loaded once and not reloaded during the life time of a VM. I don't think there is a notion of BIOS reload on real hardware. CPU access to it is either directed to the rom (power-up configuration, all those fancy reset conditions) or to ram. Reloading BIOS in QEMU is needed for a reason not present on real HW. Think about migration from old QEMU to new QEMU. Suppose old BIOS can't properly initialize new QEMU. Then next reboot after migration will fail since old BIOS will be used. Do you mean live migration between different QEMU versions? That doesn't sound safe, especially if the hardware changes on reboot. Does the competition support this? - Sebastian
[Qemu-devel] Re: [PATCH][SEABIOS] Make SMBIOS table pass MS SVVP test
Gleb Natapov wrote: On Wed, Nov 25, 2009 at 09:09:19PM +0100, Sebastian Herbszt wrote: Gleb Natapov wrote: On Tue, Nov 24, 2009 at 10:57:02AM -0500, Kevin O'Connor wrote: That said, I think SeaBIOS should autodetect any values where that's feasible. So, for example, if the cpu identification is available via cpuid, then I think that should be used. However, for example, if cpu model isn't available anywhere, then I think hardcoding something is okay. It is used already where appropriate. To fill processor_id field in type 4 table. CPU manufacturer is different issue. CPU a guest is running on is not manufactured by Intel or AMD, it is emulated by QEMU. I am still wondering why you're against using the vendor reported by CPUID. I am still wondering why you want this :) But let me ask you a question: You are running some program inside QEMU and you encounter a bug. Some instruction does not update eflags like it should and program fails. Do you complain to a) AMD b) Intel c) QEMU mailing list. If your answer is (c), then I don't see how you can propose to put something else then QEMU in manufacturer field. Since i know i run the program inside QEMU my answer has to be (c). On the other hand the competition doesn't put VMware there. The cross vendor host cpu migration doesn't seem to be a sound reason, because the cpu in the guest is emulated and has no relationship to the host cpu. If i specify -cpu phenom, i end up with an AMD cpu. Since noone but AMD produces this cpu it seems only reasonable to advertise the vendor as AMD. -p-max_speed = 0; /* unknown */ -p-current_speed = 0; /* unknown */ +p-max_speed = 2000; +p-current_speed = 2000; SeaBIOS detects the current Mhz - see calibrate_tsc() in src/clock.c. How accurate is it? What if I boot 100 guests on 16 cpu host simultaneously? Not uncommon scenario. Those field really have no meaning in virtualization environment. I'd rather have predictable values there from boot to boot. Who know what Windows may use them for. Speaking of not knowing what an OS or application might do with values in the SMBIOS table. Doesn't the same argument apply to the cpu vendor? I am concern with SMBIOS table be different on each boot, not what information is stored in those fields. CPU manufacturer is free form string. I have computers that have Intel there, others have Intel(R) Corporation. As long as it consistent from boot to boot it is OK IMO. Then i must admit i understood your Who know what Windows may use them for statement different. - Sebastian
Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios
Kevin O'Connor wrote: On Wed, Nov 25, 2009 at 11:04:20PM +0100, Sebastian Herbszt wrote: Do different things during reset depending on CMOS values doesn't sound right to me. I don't know what is implemented right now. I thought that we reload BIOS on reset. Currently the BIOS seems to be only loaded once and not reloaded during the life time of a VM. I don't think there is a notion of BIOS reload on real hardware. CPU access to it is either directed to the rom (power-up configuration, all those fancy reset conditions) or to ram. I see a BIOS reload as equivalent to directing access to rom. How is shadowing currently implemented in qemu? Is the only BIOS copy overwritten or is the rom copy separate from the ram copy? My understanding is that both the ram and rom are kept. (Though, on a BIOS reload I don't know if the ram is preserved.) The BIOS is mapped read only in hw/pc.c bios_offset = qemu_ram_alloc(bios_size) ... cpu_register_physical_memory(0x10 - isa_bios_size, isa_bios_size, (bios_offset + bios_size - isa_bios_size) | IO_MEM_ROM); Then it is remapped by update_pam() in hw/piix_pci.c cpu_register_physical_memory(start, end - start, start); Since the memory is only allocated once i assume when the content gets overwritten because of shadowing the original data is gone. To summarize the discussion so far, there seems to be a potential issue with reset: * If qemu doesn't reload the bios (a soft-reset) then there is a potential issue with the bios and option roms not running properly after a system reset invoked by Linux or other modern OSs. If a system reset (hard, power cycle) is requested and the hardware is reset to the default power up state and it does require an option rom to initialize, but the option rom is not reloaded and was shrunk and now only contains the runtime part, there will likely be a problem. Maybe the expansion rom bar can be used for pci devices like on real hardware. The bios will check it and load the rom itself instead of relying on qemu to do the job. * If qemu does reload the bios (a hard-reset) then there is a good chance that old DOS programs will break when they invoke a reset in an attempt to switch from protected mode to real mode. If a soft reset is requested with the goal of a transition from protected to real mode and the bios is reloaded, it should not do any harm because the internal device states are kept and the cmos still has the correct shutdown status code for the transition. Bochs bios doesn't rely on shadowing so none of its internal state is lost either, but the created tables (smbios, mp table, etc.) will be gone. - Sebastian
[Qemu-devel] Re: [PATCH][SEABIOS] Make SMBIOS table pass MS SVVP test
Gleb Natapov wrote: On Tue, Nov 24, 2009 at 10:57:02AM -0500, Kevin O'Connor wrote: That said, I think SeaBIOS should autodetect any values where that's feasible. So, for example, if the cpu identification is available via cpuid, then I think that should be used. However, for example, if cpu model isn't available anywhere, then I think hardcoding something is okay. It is used already where appropriate. To fill processor_id field in type 4 table. CPU manufacturer is different issue. CPU a guest is running on is not manufactured by Intel or AMD, it is emulated by QEMU. I am still wondering why you're against using the vendor reported by CPUID. The cross vendor host cpu migration doesn't seem to be a sound reason, because the cpu in the guest is emulated and has no relationship to the host cpu. If i specify -cpu phenom, i end up with an AMD cpu. Since noone but AMD produces this cpu it seems only reasonable to advertise the vendor as AMD. -p-max_speed = 0; /* unknown */ -p-current_speed = 0; /* unknown */ +p-max_speed = 2000; +p-current_speed = 2000; SeaBIOS detects the current Mhz - see calibrate_tsc() in src/clock.c. How accurate is it? What if I boot 100 guests on 16 cpu host simultaneously? Not uncommon scenario. Those field really have no meaning in virtualization environment. I'd rather have predictable values there from boot to boot. Who know what Windows may use them for. Speaking of not knowing what an OS or application might do with values in the SMBIOS table. Doesn't the same argument apply to the cpu vendor? - Sebastian
Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios
Jamie Lokier wrote: What about DOS and DOS-extender programs which do a soft reset by triple-faulting the CPU (see Sebastian's notes on i440FX behaviour), and asking the keyboard controller? Both of those methods are used by DOS and DOS-extender programs to switch from protected mode to real mode. Keyboard controller was used originally, but then someone figured out that triple fault can be used (on most PCs) and is faster. The switch to real mode is done by writing somewhere the BIOS checks, so the BIOS just branches back to the application. I think that may imply it has to be a soft reset as described by Sebastian in the i440FX description, and I would think the BIOS must not be reloaded. But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard controller method is used and the word asking for a branch back to the application has not been set. Because that's how a modern OS (if not using ACPI) asks for a system reset. Do you think the above is (a) correct, and (b) what's implemented? The 440fx spec says External logic is required to combine the PMC soft reset with the keyboard controller and I/O port 92 soft reset generation. I conclude from this, that the keyboard controller generates a soft reset too. The ACPI spec says The optional ACPI reset mechanism specifies a standard mechanism that provides a complete system reset. When implemented, this mechanism must reset the entire system. This includes processors, core logic, all buses, and all peripherals. From an OSPM perspective, asserting the reset mechanism is the logical equivalent to power cycling the machine. Upon gaining control after a reset, OSPM will perform actions in like manner to a cold boot. I think this power cycle behaviour is what system_reset should implement. - Sebastian
Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios
Gleb Natapov wrote: On Wed, Nov 25, 2009 at 06:09:51AM +, Jamie Lokier wrote: Gleb Natapov wrote: But QEMU is used to run old OSes too. That's OK. I don't expect BIOS to be reloaded if OS restart by jumping to BIOS reset code. That's good then. What about DOS and DOS-extender programs which do a soft reset by triple-faulting the CPU (see Sebastian's notes on i440FX behaviour), and asking the keyboard controller? Both of those methods are used by DOS and DOS-extender programs to switch from protected mode to real mode. Keyboard controller was used originally, but then someone figured out that triple fault can be used (on most PCs) and is faster. The switch to real mode is done by writing somewhere the BIOS checks, so the BIOS just branches back to the application. If offset 0x0f in CMOS contains 0x0a then BIOS jumps to address stored in memory address 0x467. I think that may imply it has to be a soft reset as described by Sebastian in the i440FX description, and I would think the BIOS must not be reloaded. Reading ich9 spec I see that on this chipset it is possible to configure what kind of reset triple fault generates. Make it not very reliable. Was this triple fault trick only needed on 286 anyway? It seems to be INIT# vs. PLTRST# (Platform Reset). On the latter all devices are reset. Table 5-40 is pretty descriptive and there seem to be way too many ways to trigger a reset. I think PLTRST# is used when a reset is triggered by the ACPI method. Fortunatelly we don't have to implement this (yet) since it's not available on the 440fx. Using triple fault to reset is used on 286+. But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard controller method is used and the word asking for a branch back to the application has not been set. Because that's how a modern OS (if not using ACPI) asks for a system reset. Do you think the above is (a) correct, and (b) what's implemented? Do different things during reset depending on CMOS values doesn't sound right to me. I don't know what is implemented right now. I thought that we reload BIOS on reset. Currently the BIOS seems to be only loaded once and not reloaded during the life time of a VM. I don't think there is a notion of BIOS reload on real hardware. CPU access to it is either directed to the rom (power-up configuration, all those fancy reset conditions) or to ram. How is shadowing currently implemented in qemu? Is the only BIOS copy overwritten or is the rom copy separate from the ram copy? - Sebastian
Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios
Kevin O'Connor wrote: On Wed, Nov 25, 2009 at 02:20:39PM +0200, Gleb Natapov wrote: On Wed, Nov 25, 2009 at 06:09:51AM +, Jamie Lokier wrote: But the BIOS must be reloaded from ROM, I'm guessing, if the keyboard controller method is used and the word asking for a branch back to the application has not been set. Because that's how a modern OS (if not using ACPI) asks for a system reset. Do you think the above is (a) correct, and (b) what's implemented? Do different things during reset depending on CMOS values doesn't sound right to me. I don't know what is implemented right now. I thought that we reload BIOS on reset. We could have qemu do a soft reset (not reload rom) on a triple fault or keyboard controller reset, and then have SeaBIOS request a hard reset (have qemu reload rom) if it detects a soft reset that is not a resume request. I'm also not sure what qemu does today. I don't think such an interface would add a long time benefit and would prefer a proper solution which will not tie seabios even more to qemu. One day it might be possible to run a commercial BIOS on qemu, just like it is possible on Bochs. Adding this interface might prevent that. - Sebastian
Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios
Gleb Natapov wrote: On Mon, Nov 23, 2009 at 10:30:56PM +0100, Sebastian Herbszt wrote: Gleb Natapov wrote: On Mon, Nov 23, 2009 at 08:19:54PM +0100, Sebastian Herbszt wrote: Gleb Natapov wrote: On Sun, Nov 22, 2009 at 09:01:45PM +0100, Sebastian Herbszt wrote: Gleb Natapov wrote: On Sun, Nov 22, 2009 at 04:31:24PM +0100, Sebastian Herbszt wrote: Bad things could happen if someone modifies the BIOS because it's unprotected (e.g. VM crash). BIOS is reloaded during VM reset. The BIOS is not reloaded - tested with reboot on Linux and system_reset in monitor. Looks like a bug. Tested with latest QEMU version I assume? Tested with v0.11.0-rc0-1677-gf165b53. Where do you suspect a bug? In the behaviour on reboot or system_reset? I think it depends wheter it's a software or hardware reset. The bug is that BIOS rom is not reloaded on hardware reset (what do you call software reset?). Can you retest with latest git? Same with v0.11.0-rc0-1699-gb0293e5. Bochs has the notion of BX_RESET_SOFTWARE and BX_RESET_HARDWARE. Those two describe the source of the reset and the hardware, in most cases just the cpu, is reset differently depending on the source (e.g. hardware reset / power on vs. INIT#). I think this behaviour is also described in the 440fx spec (chapter 4.5.3 SYSTEM RESET). If the monitor command system_reset is supposed to be the equivalent of pushing the reset button of the box, then the bios should be reloaded (i think, not entirely sure what the pin is wired to). But the bios should not be reloaded if the OS just jumps to the bios reset code. Correct, but modern OSes never jump to the bios reset code. They use ACPI reset, kbd reset or triple fault to do reset. All of those generate exactly the same kind of reset as system_reset monitor command. With the 440FX you get two sources of a hard reset - power on and i/o write to reset control register. Tho the PMC should not be used to generate a hard reset if used with a PIIX3. You get a soft reset on CPU shutdown bus cycle, i/o write to keyboard controller, i/o write to port 92h and i/o write to reset control register. The latter can be used for hard and soft resets. During a hard reset the PMC sets its configuration registers to default values. The PAM registers are set to 0 and the BIOS is accessed thru rom and not shadow ram. On a triple fault the CPU generates the shutdown bus cycle and since the PMC responds to it with a soft reset the BIOS is not reloaded (?). I might have missed something in some specification tho. - Sebastian
Re: [Qemu-devel] Re: POST failure (loop) with isapc and seabios
Gleb Natapov wrote: On Sun, Nov 22, 2009 at 10:38:42AM -0500, Kevin O'Connor wrote: On Sun, Nov 22, 2009 at 05:10:53PM +0200, Gleb Natapov wrote: On Sun, Nov 22, 2009 at 04:07:56PM +0100, Sebastian Herbszt wrote: Gleb Natapov wrote: May be make qemu to map it writable if isapc is specified. I don't think keeping the segment writable after POST is a good idea. Isn't it writable now after POST with pcipc? Why this is not a good idea? SeaBIOS and bochs bios will make the f-segment readonly at the end of post. See make_bios_readonly() in src/shadow.c. I see SeaBIOS does this, but I don't see where bochs bios does this. bios_lock_shadow_ram() in rombio32.c. - Sebastian
Re: [Qemu-devel] Re: [PATCH][SEABIOS] Make SMBIOS table pass MS SVVP test
Gleb Natapov wrote: On Mon, Nov 23, 2009 at 12:57:14AM +0100, Carl-Daniel Hailfinger wrote: On 22.11.2009 18:39, Sebastian Herbszt wrote: Gleb Natapov wrote: On Sun, Nov 22, 2009 at 05:51:41PM +0100, Sebastian Herbszt wrote: Is the requirement for Targeted Content Delivery specified somewhere with something more clear than SMBIOS data is useful in identifying the computer for targeted delivery of model-specific software and firmware content (e.g. changing BIOS version, release date, etc.)? @@ -130,8 +131,8 @@ smbios_init_type_1(void *start) p-header.length = sizeof(struct smbios_type_1); p-header.handle = 0x100; -load_str_field_or_skip(1, manufacturer_str); -load_str_field_or_skip(1, product_name_str); +load_str_field_with_default(1, manufacturer_str, QEMU); +load_str_field_with_default(1, product_name_str, QEMU); Use QEMU Virtual Platform product name derivated from VMware Virtual Platform ? Use QEMU Project or QEMU Community throughout for manufacturer name? I'll change this to use defines as per Kevin's request, so to keep number of defines to minimum lets make it QEMU Project everywhere. Will you introduce something like CONFIG_SYSVENDOR? Would be useful in case some other project (Bochs, Xen?) starts to use seabios. coreboot already uses SeaBIOS on various x86 hardware platforms. But does coreboot use SMBIOS tables generated by SeaBIOS? seabios seems to generate SMBIOS tables when used with coreboot. See coreboot_copy_biostable() in coreboot.c: // XXX - just create dummy smbios table for now - should detect if // smbios/dmi table is found from coreboot and use that instead. smbios_init(); - Sebastian
[Qemu-devel] Re: [PATCH][SEABIOS] Make SMBIOS table pass MS SVVP test
Gleb Natapov wrote: On Sun, Nov 22, 2009 at 09:41:26PM +0100, Sebastian Herbszt wrote: Gleb Natapov wrote: On Sun, Nov 22, 2009 at 06:39:16PM +0100, Sebastian Herbszt wrote: Gleb Natapov wrote: On Sun, Nov 22, 2009 at 05:51:41PM +0100, Sebastian Herbszt wrote: Gleb Natapov wrote: Microsoft SVVP (Server Virtualization Validation Program) expects arbitrary SMBIOS field to have certain values otherwise it fails. We all want to make Microsoft happy don't we? So lets put values MS expects in there. Values modified by the patch: Type 0: Bit 2 of byte 2 must be 1 Type 1: Manufacturer/product string should not be empty Type 3: Manufacturer string should not be empty Type 4: Processor manufacturer should no be empty Max/current CPU speed shouldn't be unknown Type 16: Memory should have error correction. Signed-off-by: Gleb Natapov g...@redhat.com diff --git a/src/smbios.c b/src/smbios.c index f1b43f2..332bb4e 100644 --- a/src/smbios.c +++ b/src/smbios.c @@ -96,7 +96,8 @@ smbios_init_type_0(void *start) memset(p-bios_characteristics, 0, 8); p-bios_characteristics[0] = 0x08; /* BIOS characteristics not supported */ p-bios_characteristics_extension_bytes[0] = 0; -p-bios_characteristics_extension_bytes[1] = 0; +/* Enable targeted content distribution. Needed for SVVP */ +p-bios_characteristics_extension_bytes[1] = 4; if (!qemu_cfg_smbios_load_field(0, offsetof(struct smbios_type_0, system_bios_major_release), Are the BIOS characteristics extension bytes valid if BIOS characteristics is not supported? I have no idea. SVVP test complains though. p-bios_characteristics[0] = 0x08; /* BIOS characteristics not supported */ Can you retest with this line removed? I will, but I don't expect different result. Why should I? I would suggest to remove the line if it still does pass the test. As a different patch. Also may be putting real info there instead of just deleting the line? Ok - sounds good if bios_characteristics gets proper system based values. [snip] /* Type 4 -- Processor Information */ @@ -198,7 +199,7 @@ smbios_init_type_4(void *start, unsigned int cpu_number) p-socket_designation_str = 1; p-processor_type = 0x03; /* CPU */ p-processor_family = 0x01; /* other */ -p-processor_manufacturer_str = 0; +p-processor_manufacturer_str = 2; u32 cpuid_signature, ebx, ecx, cpuid_features; cpuid(1, cpuid_signature, ebx, ecx, cpuid_features); @@ -209,8 +210,8 @@ smbios_init_type_4(void *start, unsigned int cpu_number) p-voltage = 0; p-external_clock = 0; -p-max_speed = 0; /* unknown */ -p-current_speed = 0; /* unknown */ +p-max_speed = 2000; +p-current_speed = 2000; p-status = 0x41; /* socket populated, CPU enabled */ p-processor_upgrade = 0x01; /* other */ @@ -221,10 +222,10 @@ smbios_init_type_4(void *start, unsigned int cpu_number) start += sizeof(struct smbios_type_4); -memcpy((char *)start, CPU \0 \0 , 7); - ((char *)start)[4] = cpu_number + '0'; +memcpy((char *)start, CPU \0QEMU\0\0, 12); +((char *)start)[4] = cpu_number + '0'; -return start+7; +return start+12; } Should the manufacturer not depend on the emulated cpu? At least VMware uses the output from CPUID (GenuineIntel) ; tho my BIOS does just report Intel. I what it to be something fictional. We support migration from Intel to AMD and back so this info is meaningless in virtualization environment. Does the system still report GenuineIntel if migrated from Intel to AMD host? I don't see a problem reporting the emulated cpu vendor, since it's not supposed to change during the lifetime of a VM, right? Well, real system don't report cpuid value here why should we? It is QEMU and not intel or amd manufactured this CPU after all. I don't think this argumentation brings us forward. After all i could argue for stopping using Intels pci vendor id for the pci bridge since they didn't manufactured it either. pci ids are different in that they are used to find driver for a device. If there was a field in PCI config space to store device manufacturer name it would be reasonable to put QEMU there. This SMBIOS field describe CPU manufacturer and serves only informational purpose. Look at /proc/cpuinfo on qemu VM. The model name reported there is QEMU Virtual CPU version 0.9.1 not some real value. Actually mine has vendor_id: GenuineIntel model_name: Pentium II (Klamath) Might be different on KVM tho (or if you specify -cpu). Beside if seabios is used with coreboot on a real system the cpu vendor is not QEMU; nor is it on Bochs. - Sebastian
