Am 18.12.2012 13:41, schrieb Vasilis Liaskovitis:
> Because dimm layout needs to be configured on machine-boot, all dimm devices
> need to be specified on startup command line (either with populated=on or with
> populated=off). The dimm information is stored in dimm configuration structures.
>
> After machine startup, dimms are hot-added or removed with normal device_add
> and device_del operations e.g.:
> Hot-add syntax: "device_add dimm,id=mydimm0,bus=membus.0"
> Hot-remove syntax: "device_del dimm,id=mydimm0"
This sounds contradictory: Either all devices need to be specified on
the command line, or they can be hot-added via monitor.
Assuming a fixed layout at startup, I wonder if there is another clever
way to model this... For CPU hotplug Anthony had suggested to have a
fixed set of link<Socket> properties that get set to a CPU socket as
needed. Might a similar strategy work for memory, i.e. a
startup-configured amount of link<DIMM>s on /machine/dimm[n] that point
to a QOM DIMM object or NULL if unpopulated? Hot(un)plug would then
simply work via QMP qom-set command. (CC'ing some people)
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Current seabios will try to boot from selected devices first,
if they are all failed, seabios will also try to boot from
un-selected devices.
We need to make it configurable. I already posted a seabios
patch to add a new device type to halt booting. Qemu can add
"HALT" at the end of bootindex string, then seabios will halt
booting after trying to boot from selected devices.
This option only effects when boot priority is changed by
bootindex options, the old style(-boot order=..) will still
try to boot from un-selected devices.
Signed-off-by: Amos Kong <akong(a)redhat.com>
---
[SeaBIOS PATCH v3] boot: add a new type to halt booting
https://github.com/kongove/seabios/commit/39aeded2da6254eab2c34de92371ce1ca…
bios.bin: http://kongove.fedorapeople.org/pub/added-halt-type-bios.bin
---
qemu-config.c | 3 +++
qemu-options.hx | 8 ++++++--
vl.c | 28 +++++++++++++++++++++++++++-
3 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/qemu-config.c b/qemu-config.c
index 2188c3e..dd6d249 100644
--- a/qemu-config.c
+++ b/qemu-config.c
@@ -612,6 +612,9 @@ QemuOptsList qemu_boot_opts = {
}, {
.name = "reboot-timeout",
.type = QEMU_OPT_STRING,
+ }, {
+ .name = "strict",
+ .type = QEMU_OPT_STRING,
},
{ /*End of list */ }
},
diff --git a/qemu-options.hx b/qemu-options.hx
index 9df0cde..5408837 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -376,14 +376,14 @@ ETEXI
DEF("boot", HAS_ARG, QEMU_OPTION_boot,
"-boot [order=drives][,once=drives][,menu=on|off]\n"
- " [,splash=sp_name][,splash-time=sp_time][,reboot-timeout=rb_time]\n"
+ " [,splash=sp_name][,splash-time=sp_time][,reboot-timeout=rb_time][,strict=on|off]\n"
" 'drives': floppy (a), hard disk (c), CD-ROM (d), network (n)\n"
" 'sp_name': the file's name that would be passed to bios as logo picture, if menu=on\n"
" 'sp_time': the period that splash picture last if menu=on, unit is ms\n"
" 'rb_timeout': the timeout before guest reboot when boot failed, unit is ms\n",
QEMU_ARCH_ALL)
STEXI
-@item -boot [order=@var{drives}][,once=@var{drives}][,menu=on|off][,splash=@var{sp_name}][,splash-time=@var{sp_time}][,reboot-timeout=@var{rb_timeout}]
+@item -boot [order=@var{drives}][,once=@var{drives}][,menu=on|off][,splash=@var{sp_name}][,splash-time=@var{sp_time}][,reboot-timeout=@var{rb_timeout}][,strict=on|off]
@findex -boot
Specify boot order @var{drives} as a string of drive letters. Valid
drive letters depend on the target achitecture. The x86 PC uses: a, b
@@ -407,6 +407,10 @@ when boot failed, then reboot. If @var{rb_timeout} is '-1', guest will not
reboot, qemu passes '-1' to bios by default. Currently Seabios for X86
system support it.
+Do strict boot via @option{strict=on} as far as firmware/BIOS
+supports it. This only effects when boot priority is changed by
+bootindex options. The default is non-strict boot.
+
@example
# try to boot from network first, then from hard disk
qemu-system-i386 -boot order=nc
diff --git a/vl.c b/vl.c
index 79e5122..de79f6c 100644
--- a/vl.c
+++ b/vl.c
@@ -230,6 +230,7 @@ int ctrl_grab = 0;
unsigned int nb_prom_envs = 0;
const char *prom_envs[MAX_PROM_ENVS];
int boot_menu;
+int boot_strict;
uint8_t *boot_splash_filedata;
int boot_splash_filedata_size;
uint8_t qemu_extra_params_fw[2];
@@ -2804,7 +2805,7 @@ int main(int argc, char **argv, char **envp)
static const char * const params[] = {
"order", "once", "menu",
"splash", "splash-time",
- "reboot-timeout", NULL
+ "reboot-timeout", "strict", NULL
};
char buf[sizeof(boot_devices)];
char *standard_boot_devices;
@@ -2847,6 +2848,19 @@ int main(int argc, char **argv, char **envp)
exit(1);
}
}
+ if (get_param_value(buf, sizeof(buf),
+ "strict", optarg)) {
+ if (!strcmp(buf, "on")) {
+ boot_strict = 1;
+ } else if (!strcmp(buf, "off")) {
+ boot_strict = 0;
+ } else {
+ fprintf(stderr,
+ "qemu: invalid option value '%s'\n",
+ buf);
+ exit(1);
+ }
+ }
qemu_opts_parse(qemu_find_opts("boot-opts"),
optarg, 0);
}
@@ -3907,6 +3921,18 @@ int main(int argc, char **argv, char **envp)
net_check_clients();
+ if (boot_strict) {
+ /* do strict boot, only boot from selected devices */
+ FWBootEntry *node;
+
+ QTAILQ_FOREACH(node, &fw_boot_order, link) {
+ if (!node->link.tqe_next) {
+ add_boot_device_path(node->bootindex + 1, NULL, "HALT");
+ break;
+ }
+ }
+ }
+
/* just use the first displaystate for the moment */
ds = get_displaystate();
--
1.7.1
This patch series adds support for using SeaBIOS as a Compatibility Support
Module (CSM) to provide "Legacy" BIOS services under UEFI/OVMF.
With a version of OVMF suitably patched to stop it from marking our stack
in the 0xE0000 segment as read-only (see README.CSM), it has been tested
with various Linux systems, Windows 7, OpenBSD 5.2, FreeBSD 8/9, NetBSD,
DragonflyBSD, Solaris 10/11.
It also fixes issues with Windows 2008r2 which rather stupidly invokes
INT 10h for video setup even when booted in EFI mode!
I haven't quite finished going through the corporate bureaucracy for
releasing this, so it's for review only.
Git tree at git://git.infradead.org/users/dwmw2/seabios.git or gitweb at
http://git.infradead.org/users/dwmw2/seabios.git
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
On Wed, 2013-01-30 at 22:13 -0500, Kevin OConnor wrote:
> This bothers me a little as well. Would it be possible to
> separate out the UMBStart/End stuff into a separate patch. (The
> main patch would assume OVMF doesn't lock 0xc0000-0xfffff at all,
> and the UMBStart/End patch would assume that OVMF has your
> proposed extensions.)
I've done that and pushed it to the git tree. Although the latest
version actually works fine anyway, as long as OVMF has the simple
one-line to avoid locking the range.
The extra fields in the table don't bother it at all since the table has
a TableLength field and the checksum is calculated over that. So they're
just ignored.
--
dwmw2
On Wed, 2013-01-30 at 09:58 -0700, Marc Jones wrote:
>
> > Not-yet-signed-off-by: David Woodhouse <David.Woodhouse(a)intel.com>
> would-be-acked-by: Marc Jones <marc.jones(a)se-eng.com>
Thanks. I've updated the git tree at git://,
http://git.infradead.org/users/dwmw2/seabios.git accordingly.
The 'not yet' bit has been revoked, btw. The bureaucracy is done and
it's ready for merging once it's passed review.
The main thing that bothers me is the UMBStart,UMBEnd fields and
corresponding patch to OVMF; we haven't finalised that side of it yet
but we certainly *need* it.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
cf. http://lists.gnu.org/archive/html/qemu-devel/2013-01/msg03650.html
Signed-off-by: David Woodhouse <David.Woodhouse(a)intel.com>
diff --git a/src/Kconfig b/src/Kconfig
index f35b0f5..e49dd82 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -293,6 +293,13 @@ menu "BIOS interfaces"
default y
help
Support finding and running option roms during POST.
+ config PERMIT_UNALIGNED_PCIROM
+ bool "Allow broken PCI option ROMs with unaligned PCIR table"
+ default n
+ help
+ Support initialising PCI ROMs which violate the spec by having
+ their PCI information at an unaligned offset, and which may not
+ be accepted by other firmwares.
config OPTIONROMS_DEPLOYED
depends on OPTIONROMS
bool "Option roms are already at 0xc0000-0xf0000"
diff --git a/src/optionroms.c b/src/optionroms.c
index c9e7d7b..99c4135 100644
--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -107,6 +107,8 @@ static struct pci_data *
get_pci_rom(struct rom_header *rom)
{
struct pci_data *pd = (void*)((u32)rom + rom->pcioffset);
+ if ((rom->pcioffset & 3) && !CONFIG_PERMIT_UNALIGNED_PCIROM)
+ return NULL;
if (pd->signature != PCI_ROM_SIGNATURE)
return NULL;
return pd;
--
dwmw2
Just a brief update for those who are interested... the CSM is fairly
functional now. I've tested with:
Various Linuxes including CentOS [56], Fedora 17.
Windows 7
Windows 2008r2 (via EFI)
OpenBSD 5.2
FreeBSD 9
FreeBSD 8
Debian/kFreeBSD (also FBSD 8 kernel I think)
DragonflyBSD
NetBSD
Solaris 10
Solaris 11
OpenIndiana
FreeDOS
I think everything is working except a few problems with the ACPI tables
that OVMF produces. OpenBSD crashes in its AML interpreter unless I
revert OVMF commit r14403.
FreeBSD 9 crashes when assigning PCI interrupts:
pcib0: allocated type 3 (0x82000000-0x8201ffff) for rid 10 of pci0:0:3:0
map[14]: type I/O Port, range 32, base 0xc000, size 6, enabled
pcib0: allocated type 4 (0xc000-0xc03f) for rid 14 of pci0:0:3:0
pcib0: matched entry for 0.3.INTA (src \_SB_.PCI0.LPC_.LNKC:0)
... and then it just sits there. If I boot with a normal SeaBIOS, it
looks like this:
pcib0: allocated type 3 (0xfeba0000-0xfebbffff) for rid 10 of pci0:0:3:0
map[14]: type I/O Port, range 32, base 0xc000, size 6, enabled
pcib0: allocated type 4 (0xc000-0xc03f) for rid 14 of pci0:0:3:0
pcib0: matched entry for 0.3.INTA (src \_SB_.LNKC:0)
pcib0: slot 3 INTA routed to irq 11 via \_SB_.LNKC
isab0: <PCI-ISA bridge> at device 1.0 on pci0
isa0: <ISA bus> on isab0
... and continues happily.
FreeBSD 8 (and Debian/kFreeBSD) seem to work but keep complaining of a
storm of IRQ9, which is the ACPI interrupt.
At this point, I'm fairly much prepared to declare that all of those are
Not My Fault™ and that the CSM is basically working.
I'm probably going to look at NV variable storage for OVMF next, using
qemu's fw_cfg (which *is* writeable) directly instead of the evil thing
it does now with storing a file on the EFI partition. And also fix up
the device detection on the OVMF side, and fix the fact that OVMF won't
even *ask* the CSM to boot from a virtio or SCSI disk if they exist.
--
dwmw2
I'm probably going to have to chase this one down for myself, but before
I do I figured I'd ask if anyone's seen anything similar before, and can
give me some pointers...
When booting FreeBSD 9 under real SeaBIOS, it all works fine. When
SeaBIOS is invoked for a 'legacy' boot under EFI, the FreeBSD bootloader
gets as far as displaying its main screen with the FreeBSD banner and
the ASCII-art dæmon and the options, but then seems to *stop* before
displaying the 'Autoboot in 9 seconds. Press [Space] to pause' message.
The qemu log shows that it's in an endless stream of
Servicing hardware INT=0x20
44024: v=20 cr0=00000032 e=0000 i=0 cpl=0 IP=f000:000000000000ffec pc=00000000000fffec SP=0000:0000000000005d9c EAX=0000000000000000
EAX=00000000 EBX=00005dd0 ECX=0000ffea EDX=00000000
ESI=0000c350 EDI=00000000 EBP=00000000 ESP=00005d9c
EIP=0000ffec EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =d500 000d5000 ffffffff 00cf9300
CS =f000 000f0000 0000ffff 00009a00
SS =0000 00000000 ffffffff 00cf9300
DS =0000 00000000 ffffffff 00cf9300
FS =0000 00000000 ffffffff 00cff300
GS =0000 00000000 ffffffff 00cff300
LDT=0000 00000000 0000ffff 00008200
TR =0038 00005f98 00002067 00008900
GDT= 00009590 0000003f
IDT= 00000000 000003ff
CR0=00000032 CR2=00000000 CR3=7fb36000 CR4=00000648
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000044 CCD=00000000 CCO=EFLAGS
EFER=0000000000000000
44025: v=1c cr0=00000032 e=0000 i=1 cpl=0 IP=f000:000000000000f856 pc=00000000000ff856 SP=0000:0000000000005d72 EAX=0000000000000000
EAX=00000000 EBX=00000000 ECX=00000000 EDX=00000000
ESI=00000000 EDI=00000000 EBP=00000000 ESP=00005d72
EIP=0000f856 EFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0000 00000000 ffffffff 00cf9300
CS =f000 000f0000 0000ffff 00009a00
SS =0000 00000000 ffffffff 00cf9300
DS =0000 00000000 ffffffff 00cf9300
FS =0000 00000000 ffffffff 00cff300
GS =0000 00000000 ffffffff 00cff300
LDT=0000 00000000 0000ffff 00008200
TR =0038 00005f98 00002067 00008900
GDT= 00009590 0000003f
IDT= 00000000 000003ff
CR0=00000032 CR2=00000000 CR3=7fb36000 CR4=00000648
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=00000000 CCD=00000000 CCO=EFLAGS
EFER=0000000000000000
Servicing hardware INT=0x20
--
dwmw2
