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 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: Question about KVM and PC speaker
malc wrote: On Wed, 13 May 2009, Sebastian Herbszt wrote: Jan Kiszka wrote: Moreover, does sound work at all with your qemu? The image I tried [1] issues two beeps after loading (obviously via direct hw access) - a good way to check general support. Note that one reason for broken host sound with qemu can be OSS. For that reason I always configure my qemu with --audio-drv-list=alsa. Thats a good hint :) Seems i used to compile qemu without --audio-drv-list. Since dsound and fmod drivers don't compile here (i likely miss some libs in my mingw), i used sdl. Don't do that. Here's a nice tutorial Kazu made that will probably help you: http://www.h7.dion.ne.jp/~qemu-win/Audio-en.html So you're saying the use of sdl for audio is not recommended? Now i can hear those two beeps with the image you suggested. Tho those are coming thru my sound card and not the hosts pc speaker (even with -soundhw pcspk, but maybe that option means something different). And it will always come through your soundcard. pcspk is not a passthrough thing. Thanks for the clarification. With INT 10h AH=0Eh i now can hear a beep too, but it doesn't stop and qemu somewhat freezes. Huh? With this INT 10h function qemu should beep once, but it does loop the beep infinitely. Normally i can exit qemu by clicking on the [x] window close icon, but while it does endlessly beep that doesn't work (vista says process doesn't respond). Using quit in the monitor window doesn't work either. - Sebastian -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: Question about KVM and PC speaker
Jan Kiszka wrote: Sebastian Herbszt wrote: Jan Kiszka wrote: Sebastian Herbszt wrote: Simon Bienlein wrote: Is a support for BIOS worked on right now? The vgabios (vgabios.c) has a FIXME should beep. Volker, do you plan to fix this? Which frequency should be used for the beep? Which delay? I would try 1 KHz and some hundred milliseconds. I just looked at some vga bios and it uses about 896,45 Hz. Getting a delay using inb(0x61) 0x10 is still a no go on qemu, right? Looks like (should be far too inaccurate for longer delays). What about 0x40:0x6c, the BIOS' daily timer counter? The bios i looked at used the refresh request port 0x61. This is supported by bochs and there is also a patch for qemu to replace the dummy [1]. The rombios uses this to provide INT 15h AH=86h functionality; this is likely broken with the dummy code in qemu. I see no problem with improving qemu's emulation accuracy this way a bit. But I wouldn't built new delay implementations on top of it, specifically if the code is in fact aware of running over a hypervisor. Such micro-timings are far too inaccurate for longer delays in an environment where you cannot be sure of running all the time during that period. Volker, mind to resubmit the patch once again? Anyway, using timer ticks since midnight should be possible (INT 08h handler is set up before vga bios is called). I have implemented the beep for vgabios-6b and it works on bochs but fails on qemu. With -soundhw pcspk i should hear it thru the hosts pc speaker, right? - Sebastian -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: Question about KVM and PC speaker
Jan Kiszka wrote: Sebastian Herbszt wrote: Simon Bienlein wrote: Is a support for BIOS worked on right now? The vgabios (vgabios.c) has a FIXME should beep. Volker, do you plan to fix this? Which frequency should be used for the beep? Which delay? I would try 1 KHz and some hundred milliseconds. I just looked at some vga bios and it uses about 896,45 Hz. Getting a delay using inb(0x61) 0x10 is still a no go on qemu, right? Looks like (should be far too inaccurate for longer delays). What about 0x40:0x6c, the BIOS' daily timer counter? The bios i looked at used the refresh request port 0x61. This is supported by bochs and there is also a patch for qemu to replace the dummy [1]. The rombios uses this to provide INT 15h AH=86h functionality; this is likely broken with the dummy code in qemu. Anyway, using timer ticks since midnight should be possible (INT 08h handler is set up before vga bios is called). [1] http://article.gmane.org/gmane.comp.emulators.bochs.devel/7594 - Sebastian -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] BIOS changes for configuring irq0-inti2 override
Beth Kon wrote: @@ -477,6 +480,7 @@ void wrmsr_smp(uint32_t index, uint64_t val) #define QEMU_CFG_SIGNATURE 0x00 #define QEMU_CFG_ID 0x01 #define QEMU_CFG_UUID 0x02 +#define QEMU_CFG_IRQ0_OVERRIDE 0x0e Small thing to consider before you resubmit: In his patch read-additional-acpi-tables-from-a-vm.patch Gleb introduced: #define QEMU_CFG_ARCH_LOCAL 0x8000 #define QEMU_CFG_ACPI_TABLES (QEMU_CFG_ARCH_LOCAL + 0) I think the idea behind this was to seperate the generic part from arch specific. The IRQ0 override seems to be arch specific (x86 only?) just like the ACPI tables, right? - Sebastian -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Re: Question about KVM and PC speaker
Simon Bienlein wrote: Is a support for BIOS worked on right now? The vgabios (vgabios.c) has a FIXME should beep. Volker, do you plan to fix this? Which frequency should be used for the beep? Which delay? Getting a delay using inb(0x61) 0x10 is still a no go on qemu, right? - Sebastian -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] exec.c: fix typo in comment (fluch - flush)
Fix typo in comment in exec.c (fluch - flush). Signed-off-by: Sebastian Herbszt herb...@gmx.de Index: kvm-84-714-g2919cca/exec.c === --- kvm-84-714-g2919cca.orig/exec.c +++ kvm-84-714-g2919cca/exec.c @@ -3187,7 +3187,7 @@ void cpu_physical_memory_rw(target_phys_ (0xff ~CODE_DIRTY_FLAG); } /* qemu doesn't execute guest code directly, but kvm does - therefore fluch instruction caches */ + therefore flush instruction caches */ if (kvm_enabled()) flush_icache_range((unsigned long)ptr, ((unsigned long)ptr)+l); -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Makefile.target: remove second addition of msmouse.o to OBJS
msmouse.o is added twice to OBJS. Signed-off-by: Sebastian Herbszt herb...@gmx.de Index: kvm-84-714-g2919cca/Makefile.target === --- kvm-84-714-g2919cca.orig/Makefile.target +++ kvm-84-714-g2919cca/Makefile.target @@ -644,9 +644,6 @@ OBJS += e1000.o # Serial mouse OBJS += msmouse.o -# Serial mouse -OBJS += msmouse.o - ifeq ($(USE_KVM_DEVICE_ASSIGNMENT), 1) OBJS+= device-assignment.o LIBS+=-lpci -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bochs-developers] [PATCH 0/3] Add BIOS splash image support
Laurent Vivier wrote: This series of patches adds a nice BIOS startup splash screen. It adds a -splash option allowing to specify the picture file name (a 640x480 (or less) and true color PNG) to display. You can enable/disable fade in, fade out and bootmenu. The time to display the image can be also given (in seconds). Idea and some parts of code are stollen from VirtualBox (GPLv2/CDDL). rombios.c is LGPL. Can we mix it with GPLv2/CDDL code without any downsides? - Sebastian -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] [PATCH 0/3] Add BIOS splash image support
Anthony Liguori wrote: Paul Brook wrote: BTW, why does qemu not carry all bochs bios source? For reference, but also to fully comply with the LGPL (pointing to the original source is not sufficient when delivering binaries - like e.g. bios.bin...). If this is really an issue, then I strongly suggest we fix it by moving the bios into its own project, and have everyone fetch it from there. This would be the best solution. How do the bochs folks feel about this? There is the pcbios project available at http://savannah.nongnu.org/projects/pcbios It seems fairly out of date tho. Volker, you happen to know the status? - Sebastian -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bochs-developers] [Qemu-devel] [PATCH 0/3] Add BIOS splashimage support
Carl-Daniel Hailfinger wrote: On 16.12.2008 22:51, Laurent Vivier wrote: But in fact, my first idea was to read the image data from the configuration device (which is always possible with LOGO_CMD_OFFSET), but when I saw how it has been done in VirtualBox, I though it was a good idea. Vbox used MMIO and port I/O before moving the splash support to the VGA device. Modern x86 BIOSes read the splash screen from the BIOS ROM and the settings from NVRAM (sometimes the BIOS ROM is used for that as well by reflashing a sector of the ROM on every boot). I think Vbox used run-length encoding for the innotek logo bitmap. Its size was about 10 KB. If this could be used for Bochs we could put the logo into rombios32.bin and load it from the 0xe000 segment. This should be comparable to other BIOSes. - Sebastian -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bochs-developers] [PATCH][BIOS] Fill IPL tableaccordingdiscovered ATA drives
Laurent Vivier wrote: Le dimanche 07 décembre 2008 à 19:11 +0100, Sebastian Herbszt a écrit : Laurent Vivier wrote: This patch shows in boot menu only available devices. This patch has been tested with Bochs BIOS version from the KVM source tree. Signed-off-by: Laurent Vivier [EMAIL PROTECTED] --- bios/rombios.c | 54 +- 1 files changed, 37 insertions(+), 17 deletions(-) diff --git a/bios/rombios.c b/bios/rombios.c index 70b3584..d2a7c09 100644 --- a/bios/rombios.c +++ b/bios/rombios.c @@ -1981,18 +1981,6 @@ init_boot_vectors() memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, e, sizeof (e)); count++; - /* First HDD */ - e.type = IPL_TYPE_HARDDISK; e.flags = 0; e.vector = 0; e.description = 0; e.reserved = 0; - memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, e, sizeof (e)); - count++; We need this bit for the !BX_USE_ATADRV case. Please #if !BX_USE_ATADRV ... #endif it instead of removing. If there is no ATA drive, what is the aim of adding an harddrive in the IPL table ? I think BX_USE_ATADRV enables the new ATA/ATAPI driver. You can still use hard drives with the older code enabled by BX_USE_ATADRV=0. - Sebastian -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bochs-developers] [PATCH][BIOS] Add BCV option rom in boot menu
Laurent Vivier wrote:
This patch allows to select and boot from an option ROM
with a Boot Connection Vector (BCV) entry.
The BIOS detects the BCV option ROM and adds it to the IPL table, and then
you are able to select it to boot.
This patch has been tested with Bochs BIOS version from the KVM source tree
and a gPXE ROM modified to be a BCV one.
Any plans to convert extboot into a compatible option rom?
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
bios/rombios.c | 71 ++-
1 files changed, 64 insertions(+), 7 deletions(-)
diff --git a/bios/rombios.c b/bios/rombios.c
index 9a1cdd6..70b3584 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -180,7 +180,11 @@
might as well also add
#define IPL_TYPE_RESERVED 0x00
#define IPL_TYPE_FLOPPY 0x01
#define IPL_TYPE_HARDDISK0x02
#define IPL_TYPE_CDROM 0x03
+#define IPL_TYPE_PCMCIA 0x04
+#define IPL_TYPE_USBDEVICE 0x05
+#define IPL_TYPE_NETWORK 0x06
Should this be somehow marked as embedded network? Maybe a comment.
#define IPL_TYPE_BEV 0x80
+#define IPL_TYPE_UNKNOWN 0xff
// Sanity Checks
#if BX_USE_ATADRV BX_CPU3
@@ -2009,6 +2013,31 @@ Bit16u i; ipl_entry_t *e;
return 1;
}
+static Bit8u
+get_bootdrv(i)
+Bit16u i;
+{
+ Bit16u count;
+ Bit16u type;
+ Bit16u curr_type;
+ Bit16u curr;
+ Bit16u drv;
+ /* Get the count of boot devices, and refuse to overrun the array */
+ count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+ if (i = count) return 0;
Add a comment that we return floppy on overrun?
+ type = read_word(IPL_SEG, IPL_TABLE_OFFSET + i * sizeof (ipl_entry_t),
+ sizeof(Bit16u));
+ if (type != IPL_TYPE_HARDDISK)
+return 0;
+ for (curr = 0, drv = 0; curr i; curr++) {
+curr_type = read_word(IPL_SEG,
+ IPL_TABLE_OFFSET + curr * sizeof (ipl_entry_t),
+ sizeof(Bit16u));
+if (type == curr_type) drv++;
+ }
+ return 0x80 + drv;
+}
+
#if BX_ELTORITO_BOOT
void
interactive_bootkey()
@@ -2047,8 +2076,15 @@ interactive_bootkey()
case IPL_TYPE_FLOPPY:
case IPL_TYPE_HARDDISK:
case IPL_TYPE_CDROM:
-printf(%s\n, drivetypes[e.type]);
-break;
+printf(%s, drivetypes[e.type]);
+if (e.description != 0)
+{
+ memcpyb(ss, description, (Bit16u)(e.description 16),
(Bit16u)(e.description 0x), 32);
+ description[32] = 0;
+ printf( [%S], ss, description);
+ }
+ printf(\n);
+ break;
case IPL_TYPE_BEV:
printf(%s, drivetypes[4]);
if (e.description != 0)
@@ -8045,7 +8081,7 @@ Bit16u seq_nr;
case IPL_TYPE_FLOPPY: /* FDD */
case IPL_TYPE_HARDDISK: /* HDD */
-bootdrv = (e.type == IPL_TYPE_HARDDISK) ? 0x80 : 0x00;
+bootdrv = get_bootdrv(bootdev);
bootseg = 0x07c0;
status = 0;
@@ -10245,10 +10281,11 @@ block_count_rounded:
mov bx, 0x001a ;; 0x1A is the offset into ROM header that contains...
mov ax, [bx] ;; the offset of PnP expansion header, where...
cmp ax, #0x5024 ;; we look for signature $PnP
- jne no_bev
+ jne no_pnp
mov ax, 2[bx]
cmp ax, #0x506e
- jne no_bev
+ jne no_pnp
+ ;; Look for the Bootstrap Entry Vector (BEV)
mov ax, 0x1a[bx] ;; 0x1A is also the offset into the expansion header of...
cmp ax, #0x ;; the Bootstrap Entry Vector, or zero if there is none.
je no_bev
@@ -10259,9 +10296,29 @@ block_count_rounded:
mov ds, bx
mov bx, IPL_COUNT_OFFSET;; Read the number of entries so far
cmp bx, #IPL_TABLE_ENTRIES
- je no_bev ;; Get out if the table is full
+ je no_pnp ;; Get out if the table is full
shl bx, #0x4;; Turn count into offset (entries are 16 bytes)
mov 0[bx], #IPL_TYPE_BEV;; This entry is a BEV device
+ jmp add_ipl
+
+no_bev:
+ ;; Look for the Boot Connection Vector (BCV)
+ mov ax, 0x16[bx] ;; 0x16 is also the offset into the expansion header of...
also is wrong in this comment
+ cmp ax, #0x ;; the Boots Entry Vector, or zero if there is none.
Boot Connection Vector
+ je no_pnp
+
+ ;; Found a device that thinks it can boot the system.
+ mov di, 0x10[bx];; Pointer to the product name string or zero
if none
+ mov bx, #IPL_SEG;; Go to the segment where the IPL table lives
+ mov ds, bx
+ mov bx, IPL_COUNT_OFFSET;; Read the number of entries so far
+ cmp bx, #IPL_TABLE_ENTRIES
+ je no_pnp ;; Get out if the table is full
+ shl bx, #0x4;; Turn count into offset (entries are 16 bytes)
+ mov 0[bx], #IPL_TYPE_HARDDISK;; This entry is a BEV device
BCV device
+
+add_ipl:
+
mov 6[bx], cx ;; Build a far pointer from the segment...
mov 4[bx], ax ;; and the offset
cmp di, #0x
@@ -10273,7 +10330,7 @@
Re: [Bochs-developers] [PATCH][BIOS] Fill IPL table accordingdiscovered ATA drives
Laurent Vivier wrote:
This patch shows in boot menu only available devices.
This patch has been tested with Bochs BIOS version from the KVM source tree.
Signed-off-by: Laurent Vivier [EMAIL PROTECTED]
---
bios/rombios.c | 54 +-
1 files changed, 37 insertions(+), 17 deletions(-)
diff --git a/bios/rombios.c b/bios/rombios.c
index 70b3584..d2a7c09 100644
--- a/bios/rombios.c
+++ b/bios/rombios.c
@@ -1981,18 +1981,6 @@ init_boot_vectors()
memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, e, sizeof (e));
count++;
- /* First HDD */
- e.type = IPL_TYPE_HARDDISK; e.flags = 0; e.vector = 0; e.description = 0;
e.reserved = 0;
- memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, e, sizeof (e));
- count++;
We need this bit for the !BX_USE_ATADRV case. Please #if !BX_USE_ATADRV ...
#endif it
instead of removing.
-#if BX_ELTORITO_BOOT
- /* CDROM */
- e.type = IPL_TYPE_CDROM; e.flags = 0; e.vector = 0; e.description = 0;
e.reserved = 0;
- memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e), ss, e, sizeof (e));
- count++;
-#endif
This is ok since BX_ELTORITO_BOOT depends on BX_USE_ATADRV.
/* Remember how many devices we have */
write_word(IPL_SEG, IPL_COUNT_OFFSET, count);
/* Not tried booting anything yet */
@@ -2027,15 +2015,19 @@ Bit16u i;
if (i = count) return 0;
type = read_word(IPL_SEG, IPL_TABLE_OFFSET + i * sizeof (ipl_entry_t),
sizeof(Bit16u));
- if (type != IPL_TYPE_HARDDISK)
+ if (type == IPL_TYPE_HARDDISK)
+drv = 0x80;
+ else if(type == IPL_TYPE_CDROM)
Please put a space between if and (.
+drv = 0xe0;
+ else
return 0;
- for (curr = 0, drv = 0; curr i; curr++) {
+ for (curr = 0; curr i; curr++) {
curr_type = read_word(IPL_SEG,
IPL_TABLE_OFFSET + curr * sizeof (ipl_entry_t),
sizeof(Bit16u));
if (type == curr_type) drv++;
}
- return 0x80 + drv;
+ return drv;
}
#if BX_ELTORITO_BOOT
@@ -2082,6 +2074,9 @@ interactive_bootkey()
memcpyb(ss, description, (Bit16u)(e.description 16),
(Bit16u)(e.description 0x), 32);
description[32] = 0;
printf( [%S], ss, description);
+ } else {
+ Bit16u drive = get_bootdrv(i);
+ if (drive) printf( (0x%02x), drive);
get_bootdrv() returns Bit8u.
}
printf(\n);
break;
@@ -2484,6 +2479,9 @@ void ata_detect( )
Bit16u ebda_seg=read_word(0x0040,0x000E);
Bit8u hdcount, cdcount, device, type;
Bit8u buffer[0x0200];
+ Bit16u ss = get_SS();
+ ipl_entry_t e;
+ Bit16u count;
#if BX_MAX_ATA_INTERFACES 0
write_byte(ebda_seg,EbdaData-ata.channels[0].iface,ATA_IFACE_ISA);
@@ -2750,6 +2748,16 @@ void ata_detect( )
printf( ATA-%d Hard-Disk (%4u MBytes)\n, version,
(Bit16u)sizeinmb);
else
printf( ATA-%d Hard-Disk (%4u GBytes)\n, version,
(Bit16u)(sizeinmb10));
+ /* add to IPL list */
+ count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+ e.type = IPL_TYPE_HARDDISK;
+ e.flags = 0;
+ e.vector = 0;
+ e.description = 0;
+ e.reserved = 0;
+ memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e),
+ ss, e, sizeof (e));
+ write_word(IPL_SEG, IPL_COUNT_OFFSET, count + 1);
break;
case ATA_TYPE_ATAPI:
printf(ata%d %s: ,channel,slave? slave:master);
@@ -2758,6 +2766,18 @@ void ata_detect( )
printf( ATAPI-%d CD-Rom/DVD-Rom\n,version);
else
printf( ATAPI-%d Device\n,version);
+ /* add to IPL list */
+#if BX_ELTORITO_BOOT
+ count = read_word(IPL_SEG, IPL_COUNT_OFFSET);
+ e.type = IPL_TYPE_CDROM;
+ e.flags = 0;
+ e.vector = 0;
+ e.description = 0;
+ e.reserved = 0;
+ memcpyb(IPL_SEG, IPL_TABLE_OFFSET + count * sizeof (e),
+ ss, e, sizeof (e));
+ write_word(IPL_SEG, IPL_COUNT_OFFSET, count + 1);
+#endif
break;
case ATA_TYPE_UNKNOWN:
printf(ata%d %s: Unknown device\n,channel,slave? slave:master);
@@ -10663,6 +10683,8 @@ post_default_ints:
;;
call hard_drive_post
+ call _init_boot_vectors
+
#if BX_USE_ATADRV
;;
@@ -10682,8 +10704,6 @@ post_default_ints:
;;
#endif // BX_ELTORITO_BOOT
- call _init_boot_vectors
-
mov cx, #0xc800 ;; init option roms
mov ax, #0xe000
call rom_scan
--
- Sebastian
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] Support for S3 ACPI state (suspend to memory)
Gleb Natapov wrote: Hello, This patch series adds S3 (suspend to RAM) ACPI state. Most changes are in the BIOS code and concern themselves with preventing BIOS from using memory available to OS. --- Gleb Natapov (8): Don't power down vga card on entering S3 state. Add DPMS support to cirrus vga bios. Don't use unreserved memory in BIOS. Execute rombios32 code from rom address 0xe. Disable init of SMM. Add S3 state to DSDT. Handle resume event in the BIOS. Handle suspend in qemu. Move PIC initialization out of line to save space in post code area. Earlier this year patches were posted on xen-devel for S3 support [1]. They include qemu [2] and rombios [3] changes. It might be worth checking them out in case you did not. [1] [PATCH 0/4] HVM Virtual S3 http://lists.xensource.com/archives/html/xen-devel/2007-05/msg00603.html [2] [PATCH 2/4]: QEMU interface for HVM virtual S3 http://lists.xensource.com/archives/html/xen-devel/2007-05/msg00605.html [3] [PATCH 3/4] rombios interface for HVM S3 http://lists.xensource.com/archives/html/xen-devel/2007-05/msg00606.html - Sebastian -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm-intel + vista64 installer == BSOD.
Paweł Sikora wrote: Hi, added cc: kvm@vger.kernel.org - Sebastian i'm trying to install vista64 with integrated sp1 on virtual machine and getting bsod during installer startup - http://imagebin.org/25860 hardware: intel q9300 with 8GB of ram. software: kvm-74, qemu-0.9.1-13k, kernel-2.6.26 in dmesg i found only few lines: [ 277.882001] SIPI to vcpu 1 vector 0x10 [ 277.882001] SIPI to vcpu 2 vector 0x10 [ 277.882001] SIPI to vcpu 3 vector 0x10 [ 283.352002] apic write: bad size=1 fee00030 [ 283.352002] Ignoring de-assert INIT to vcpu 0 [ 283.352002] Ignoring de-assert INIT to vcpu 1 [ 283.352002] Ignoring de-assert INIT to vcpu 2 [ 283.352002] Ignoring de-assert INIT to vcpu 3 i have no idea what's wrong :( -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: bios: end AP boot code execution in rombios
Avi Kivity wrote: .code16 smp_ap_boot_code_start: + cli Redundant (but no harm done). I added it so it's explicit this code is run with IF=0. Kind of serves a documentation purpose so we don't have to look up whether the cpu starts with IF=0 or not. - Sebastian -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm: bios: end AP boot code execution in rombios
Jump to rombios before executing the halt loop. Signed-off-by: Sebastian Herbszt [EMAIL PROTECTED] diff -uNrp a/bios/rombios32start.S b/bios/rombios32start.S --- a/bios/rombios32start.S 2008-08-17 23:30:42.0 +0200 +++ b/bios/rombios32start.S 2008-08-17 23:38:42.0 +0200 @@ -40,6 +40,7 @@ _start: .code16 smp_ap_boot_code_start: + cli xor %ax, %ax mov %ax, %ds xor %eax, %eax @@ -60,6 +61,7 @@ smp_ap_boot_code_start: 12: incw CPU_COUNT_ADDR + ljmp $0xe000, $(1f-_start) 1: hlt jmp 1b -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: bios: Put AP boot up code to 0x1000
Avi Kivity wrote: The AP enters HALT state with IF=0. What can make it resume at the following jmp 1b? NMI? SMI? Yes, but also INIT. Are you sure the AP will continue after the hlt instruction on INIT? I think it will start to execute code from the reset vector (0xfff0). We might ignore IF=0 for hlt (which would be a bug). I think i read something about a need for 4kb alignment for the startup vector in the mp specs. AP_BOOT_ADDR is currently at 0x1 (16 x 4kb). Yes, the SIPI address is 4K x sipi vector. - Sebastian -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: bios: Put AP boot up code to 0x1000
Yang, Sheng wrote: Please refer to my another patch comment. Basicly, AP is running HLT in 0x10038, but it can exit due to some reason, here QEmu want to raise it up . But after AP exit from HLT, it can't return to it because the code was overrided by grub and no HLT loop there. Then AP had gone away... Thank you for pointing me to [PATCH] KVM: Fix QEmu interrupted HLT emulation. You wrote there: Though I also sent a patch for BIOS, it's necessary to get correct behavior here. Would i be correct saying the problem is kvm/qemu only and with that patch applied the bios fix is not needed? No... I think more important is get bios fixed. Anyway, copy BIOS part of running code to a place that may overwritten by userspace program is wrong, if you expect AP still running when userspace program is running. In fact, if BIOS code in right place, we won't need fix HLT, for HLT have a assumption that it might be interrupt by some event, so usually it is wrapped by a loop, as current BIOS did. The AP enters HALT state with IF=0. What can make it resume at the following jmp 1b? NMI? SMI? If you still want to change the bios code i would suggest jumping to the original smp_ap_boot_code location in rombios32.bin which should not get overwritten. The following patch is based on the bochs version. Yeah, I just curious why we need to copy BIOS here and there in the beginning... Thanks for your patch, but is it based on bochs upstream? Yes it's based on bochs upstream rombios32start.S r1.5. I found the patch don't apply... This one should apply to current kvm version. I also want to know why we need copy AP boot code, if anyone know the detail... I think i read something about a need for 4kb alignment for the startup vector in the mp specs. AP_BOOT_ADDR is currently at 0x1 (16 x 4kb). - Sebastian --- rombios32start.S.orig Wed Aug 6 21:37:22 2008 +++ rombios32start.S Wed Aug 6 21:39:17 2008 @@ -40,6 +40,7 @@ _start: .code16 smp_ap_boot_code_start: + cli xor %ax, %ax mov %ax, %ds xor %eax, %eax @@ -60,6 +61,7 @@ smp_ap_boot_code_start: 12: incw CPU_COUNT_ADDR + ljmp $0xe000, $(1f-_start) 1: hlt jmp 1b -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: bios: Put AP boot up code to 0x1000
Yang, Sheng wrote: Please refer to my another patch comment. Basicly, AP is running HLT in 0x10038, but it can exit due to some reason, here QEmu want to raise it up . But after AP exit from HLT, it can't return to it because the code was overrided by grub and no HLT loop there. Then AP had gone away... Thank you for pointing me to [PATCH] KVM: Fix QEmu interrupted HLT emulation. You wrote there: Though I also sent a patch for BIOS, it's necessary to get correct behavior here. Would i be correct saying the problem is kvm/qemu only and with that patch applied the bios fix is not needed? If you still want to change the bios code i would suggest jumping to the original smp_ap_boot_code location in rombios32.bin which should not get overwritten. The following patch is based on the bochs version. - Sebastian --- rombios32start.orig 2008-08-02 19:37:34.0 +0200 +++ rombios32start.S2008-08-02 20:19:15.0 +0200 @@ -40,9 +40,11 @@ .code16 smp_ap_boot_code_start: + cli xor %ax, %ax mov %ax, %ds lock incw CPU_COUNT_ADDR + ljmp $0xe000, $(1f-_start) 1: hlt jmp 1b -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm: bios: Put AP boot up code to 0x1000
Yang, Sheng wrote: Rather than 0x1, which can be overrided by userspace program like grub. Could you please explain this problem? If i don't misunderstand this smp_ap_boot_code_start from rombios32start.S gets copied to AP_BOOT_CODE and then there is a broadcast INIT and SIPI. After the code is run it's not used anymore so there should be no need to care where it's located. - Sebastian -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add HPET support to BIOS
Beth Kon wrote:
This patch, written by Ryan Harper, adds HPET support to BIOS.
Signed-off-by: Beth Kon [EMAIL PROTECTED]
diff --git a/bios/Makefile b/bios/Makefile
index 48022ea..3e73fb5 100644
--- a/bios/Makefile
+++ b/bios/Makefile
@@ -40,7 +40,7 @@ LIBS = -lm
RANLIB = ranlib
BCC = bcc
-GCC = gcc -m32
+GCC = gcc -m32 -fno-stack-protector
HOST_CC = gcc
AS86 = as86
diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index d1bfa2c..1548c86 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -262,6 +262,24 @@ DefinitionBlock (
Return (MEMP)
}
}
+Device(HPET) {
+Name(_HID, EISAID(PNP0103))
+Name(_UID, 0)
_UID is optional if only one timer block is present.
+Method (_STA, 0, NotSerialized) {
+Return(0x00)
Not present?
+}
+Name(_CRS, ResourceTemplate() {
+DWordMemory(
+ResourceConsumer, PosDecode, MinFixed, MaxFixed,
+NonCacheable, ReadWrite,
+0x,
+0xFED0,
+0xFED003FF,
+0x,
+0x0400 /* 1K memory: FED0 - FED003FF */
+)
+})
+}
}
Scope(\_SB.PCI0) {
@@ -628,7 +646,7 @@ DefinitionBlock (
{
Or (PRQ3, 0x80, PRQ3)
}
-Method (_CRS, 0, NotSerialized)
+Method (_CRS, 1, NotSerialized)
{
Name (PRR0, ResourceTemplate ()
{
Is this change related?
diff --git a/bios/rombios32.c b/bios/rombios32.c
index 2dc1d25..c1ec015 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -1182,7 +1182,7 @@ struct rsdp_descriptor /* Root System
Descriptor Pointer */
struct rsdt_descriptor_rev1
{
ACPI_TABLE_HEADER_DEF /* ACPI common table
header */
- uint32_t table_offset_entry [2]; /* Array
of pointers to other */
+ uint32_t table_offset_entry [3]; /* Array
of pointers to other */
/* ACPI tables */
};
@@ -1322,6 +1322,30 @@ struct madt_processor_apic
#endif
};
+/*
+ * ACPI 2.0 Generic Address Space definition.
+ */
+struct acpi_20_generic_address {
+uint8_t address_space_id;
+uint8_t register_bit_width;
+uint8_t register_bit_offset;
+uint8_t reserved;
+uint64_t address;
+};
+
+/*
+ * HPET Description Table
+ */
+struct acpi_20_hpet {
+ACPI_TABLE_HEADER_DEF /* ACPI common
table header */
+uint32_t timer_block_id;
+struct acpi_20_generic_address addr;
+uint8_thpet_number;
+uint16_t min_tick;
+uint8_tpage_protect;
+};
+#define ACPI_HPET_ADDRESS 0xFED0UL
+
struct madt_io_apic
{
APIC_HEADER_DEF
@@ -1393,8 +1417,9 @@ void acpi_bios_init(void)
struct fadt_descriptor_rev1 *fadt;
struct facs_descriptor_rev1 *facs;
struct multiple_apic_table *madt;
+struct acpi_20_hpet *hpet;
uint8_t *dsdt;
-uint32_t base_addr, rsdt_addr, fadt_addr, addr, facs_addr,
dsdt_addr;
+uint32_t base_addr, rsdt_addr, fadt_addr, addr, facs_addr,
dsdt_addr, hpet_addr;
uint32_t acpi_tables_size, madt_addr, madt_size;
int i;
@@ -1436,6 +1461,11 @@ void acpi_bios_init(void)
madt = (void *)(addr);
addr += madt_size;
+addr = (addr + 7) ~7;
+hpet_addr = addr;
+hpet = (void *)(addr);
+addr += sizeof(*hpet);
+
acpi_tables_size = addr - base_addr;
BX_INFO(ACPI tables: RSDP addr=0x%08lx ACPI DATA addr=0x%08lx
size=0x%x\n,
@@ -1457,6 +1487,7 @@ void acpi_bios_init(void)
memset(rsdt, 0, sizeof(*rsdt));
rsdt-table_offset_entry[0] = cpu_to_le32(fadt_addr);
rsdt-table_offset_entry[1] = cpu_to_le32(madt_addr);
+rsdt-table_offset_entry[2] = cpu_to_le32(hpet_addr);
acpi_build_table_header((struct acpi_table_header *)rsdt,
RSDT, sizeof(*rsdt), 1);
@@ -1540,6 +1571,15 @@ void acpi_bios_init(void)
acpi_build_table_header((struct acpi_table_header *)madt,
APIC, madt_size, 1);
}
+
+/* HPET */
+memset(hpet, 0, sizeof(*hpet));
+hpet-timer_block_id = cpu_to_le32(0x8086a201);
+ // hpet-timer_block_id = cpu_to_le32(0x80862201);
This magic value could need some explanation so people don't have to look it
up.
Something like:
8086 = pci vendor id
a201 = 10100011
1 LegacyReplacement IRQ Routing Capable
0reserved
1 COUNT_SIZE_CAP counter size
00010 Number of Comparators
0001 Hardwave revision id
Also add a comment that it should be kept in sync with the emulation (hpet.c).
- Sebastian
+hpet-addr.address = cpu_to_le32(ACPI_HPET_ADDRESS);
+
Re: [PATCH] Add HPET support to BIOS
Ryan Harper wrote:
Hey Sebastian,
Thanks for the review,
Beth Kon wrote:
This patch, written by Ryan Harper, adds HPET support to BIOS.
Signed-off-by: Beth Kon [EMAIL PROTECTED]
diff --git a/bios/Makefile b/bios/Makefile
index 48022ea..3e73fb5 100644
--- a/bios/Makefile
+++ b/bios/Makefile
@@ -40,7 +40,7 @@ LIBS = -lm
RANLIB = ranlib
BCC = bcc
-GCC = gcc -m32
+GCC = gcc -m32 -fno-stack-protector
HOST_CC = gcc
AS86 = as86
diff --git a/bios/acpi-dsdt.dsl b/bios/acpi-dsdt.dsl
index d1bfa2c..1548c86 100755
--- a/bios/acpi-dsdt.dsl
+++ b/bios/acpi-dsdt.dsl
@@ -262,6 +262,24 @@ DefinitionBlock (
Return (MEMP)
}
}
+Device(HPET) {
+Name(_HID, EISAID(PNP0103))
+Name(_UID, 0)
_UID is optional if only one timer block is present.
OK
+Method (_STA, 0, NotSerialized) {
+Return(0x00)
Not present?
Was playing around with this when trying to get Linux to see the device
in the ACPI tables. AFAICT, Linux doesn't care about this value. Should
be 1 here then?
I would suggest 0x0F (present, enabled and more).
It would be nice to runtime detect the presence of the hpet and return the
proper value, e.g. 0x0 if not present and skip the HPET ACPI table creation.
The Xen DSDT does it with the help of a bios info table which gets created at
runtime. It detects the hpet by reading the vendor id from HPET_BASE.
Something like this might also be possible inside the DSDT (OperationRegion,
Field and LEqual).
+}
+Name(_CRS, ResourceTemplate() {
+DWordMemory(
+ResourceConsumer, PosDecode, MinFixed, MaxFixed,
+NonCacheable, ReadWrite,
+0x,
+0xFED0,
+0xFED003FF,
+0x,
+0x0400 /* 1K memory: FED0 - FED003FF */
+)
+})
+}
}
Scope(\_SB.PCI0) {
@@ -628,7 +646,7 @@ DefinitionBlock (
{
Or (PRQ3, 0x80, PRQ3)
}
-Method (_CRS, 0, NotSerialized)
+Method (_CRS, 1, NotSerialized)
{
Name (PRR0, ResourceTemplate ()
{
Is this change related?
Doubtful, I'll confirm whether or not it is needed.
diff --git a/bios/rombios32.c b/bios/rombios32.c
index 2dc1d25..c1ec015 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -1182,7 +1182,7 @@ struct rsdp_descriptor /* Root System
Descriptor Pointer */
struct rsdt_descriptor_rev1
{
ACPI_TABLE_HEADER_DEF /* ACPI common table
header */
- uint32_t table_offset_entry [2]; /* Array
of pointers to other */
+ uint32_t table_offset_entry [3]; /* Array
of pointers to other */
/* ACPI tables */
};
@@ -1322,6 +1322,30 @@ struct madt_processor_apic
#endif
};
+/*
+ * ACPI 2.0 Generic Address Space definition.
+ */
+struct acpi_20_generic_address {
+uint8_t address_space_id;
+uint8_t register_bit_width;
+uint8_t register_bit_offset;
+uint8_t reserved;
+uint64_t address;
+};
+
+/*
+ * HPET Description Table
+ */
+struct acpi_20_hpet {
+ACPI_TABLE_HEADER_DEF /* ACPI common
table header */
+uint32_t timer_block_id;
+struct acpi_20_generic_address addr;
+uint8_thpet_number;
+uint16_t min_tick;
+uint8_tpage_protect;
+};
+#define ACPI_HPET_ADDRESS 0xFED0UL
+
struct madt_io_apic
{
APIC_HEADER_DEF
@@ -1393,8 +1417,9 @@ void acpi_bios_init(void)
struct fadt_descriptor_rev1 *fadt;
struct facs_descriptor_rev1 *facs;
struct multiple_apic_table *madt;
+struct acpi_20_hpet *hpet;
uint8_t *dsdt;
-uint32_t base_addr, rsdt_addr, fadt_addr, addr, facs_addr,
dsdt_addr;
+uint32_t base_addr, rsdt_addr, fadt_addr, addr, facs_addr,
dsdt_addr, hpet_addr;
uint32_t acpi_tables_size, madt_addr, madt_size;
int i;
@@ -1436,6 +1461,11 @@ void acpi_bios_init(void)
madt = (void *)(addr);
addr += madt_size;
+addr = (addr + 7) ~7;
+hpet_addr = addr;
+hpet = (void *)(addr);
+addr += sizeof(*hpet);
+
acpi_tables_size = addr - base_addr;
BX_INFO(ACPI tables: RSDP addr=0x%08lx ACPI DATA addr=0x%08lx
size=0x%x\n,
@@ -1457,6 +1487,7 @@ void acpi_bios_init(void)
memset(rsdt, 0, sizeof(*rsdt));
rsdt-table_offset_entry[0] = cpu_to_le32(fadt_addr);
rsdt-table_offset_entry[1] = cpu_to_le32(madt_addr);
+rsdt-table_offset_entry[2] = cpu_to_le32(hpet_addr);
acpi_build_table_header((struct acpi_table_header *)rsdt,
RSDT, sizeof(*rsdt), 1);
@@ -1540,6 +1571,15 @@ void acpi_bios_init(void)
acpi_build_table_header((struct acpi_table_header *)madt,
APIC, madt_size, 1);
}
+
+/* HPET */
