[PATCH v2 00/19] SeaBIOS as Compatibility Support Module for UEFI/OVMF
by David Woodhouse
Changes from v1:
- Make CONFIG_CSM a top-level build target in parallel with COREBOOT/QEMU.
- More Kconfig cleanup.
- Add generic find_pmtimer() function to find the pmtimer from ACPI tables.
- Make Xen and coreboot builds both use find_pmtimer().
- Merge E820 table one entry at a time instead of wholesale copy.
- Add pic_save_mask() and pic_restore_mask() functions.
- Less intrusive size reduction for handle_post().
- Various other cleanups.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse(a)intel.com Intel Corporation
5 years, 6 months
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
by Andreas Färber
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
5 years, 9 months
[Qemu PATCH] add a boot option to do strict boot
by Amos Kong
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/39aeded2da6254eab2c34de92371ce1...
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
5 years, 10 months
[PATCH] pci vga: Support VGA behind bridges
by Alex Williamson
We currently expect to find VGA devices on the root bus but we will
also support them below bridges iff the VGA routing across the bridges
is pre-configured. This patch maintains that behavior, but also
enables SeaBIOS to enable VGA routing to the first VGA class device it
finds when there is no preconfigured device. This allows us to
support VGA devices behind root ports and bridges without special
setup from QEMU.
Signed-off-by: Alex Williamson <alex.williamson(a)redhat.com>
---
src/optionroms.c | 46 ++++++++++++++++++++++++++++++++++++++++------
1 file changed, 40 insertions(+), 6 deletions(-)
diff --git a/src/optionroms.c b/src/optionroms.c
index caa2151..1c2a714 100644
--- a/src/optionroms.c
+++ b/src/optionroms.c
@@ -439,13 +439,47 @@ vgarom_setup(void)
memset((void*)BUILD_ROM_START, 0, rom_get_max() - BUILD_ROM_START);
// Find and deploy PCI VGA rom.
- struct pci_device *pci;
+ struct pci_device *pci, *pci_vga = NULL;
+ // Search for devices already enabled
foreachpci(pci) {
- if (!is_pci_vga(pci))
- continue;
- vgahook_setup(pci);
- init_pcirom(pci, 1, NULL);
- break;
+ if (is_pci_vga(pci)) {
+ pci_vga = pci;
+ break;
+ }
+ }
+
+ // Find and enable the first VGA device
+ if (!pci_vga && (pci = pci_find_class(PCI_CLASS_DISPLAY_VGA)) != NULL) {
+ dprintf(4, "Enabling device %02x:%02x.%x for primary VGA\n",
+ pci_bdf_to_bus(pci->bdf), pci_bdf_to_dev(pci->bdf),
+ pci_bdf_to_fn(pci->bdf));
+
+ u16 cmd = pci_config_readw(pci->bdf, PCI_COMMAND);
+ cmd |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY;
+ pci_config_writew(pci->bdf, PCI_COMMAND, cmd);
+
+ pci_vga = pci;
+
+ while (pci->parent) {
+ pci = pci->parent;
+
+ dprintf(4, "Setting VGA enable for bridge %02x:%02x.%x\n",
+ pci_bdf_to_bus(pci->bdf), pci_bdf_to_dev(pci->bdf),
+ pci_bdf_to_fn(pci->bdf));
+
+ u8 ctrl = pci_config_readb(pci->bdf, PCI_BRIDGE_CONTROL);
+ ctrl |= PCI_BRIDGE_CTL_VGA;
+ pci_config_writeb(pci->bdf, PCI_BRIDGE_CONTROL, ctrl);
+
+ u16 cmd = pci_config_readw(pci->bdf, PCI_COMMAND);
+ cmd |= PCI_COMMAND_IO | PCI_COMMAND_MEMORY;
+ pci_config_writew(pci->bdf, PCI_COMMAND, cmd);
+ }
+ }
+
+ if (pci_vga) {
+ vgahook_setup(pci_vga);
+ init_pcirom(pci_vga, 1, NULL);
}
// Find and deploy CBFS vga-style roms not associated with a device.
5 years, 10 months
RFC: Primary VGA
by Alex Williamson
When we start adding root ports and bridges to systems we need some
concept of a primary VGA device.The differentiation of the primary
device is that it's the default one that responds to the Legacy VGA
address ranges. PCs often have a BIOS selection for this.
Seabios already seems to have some concept of this and looks for a VGA
class device for which the parent devices all have VGA routing enabled.
This seems to work today if QEMU initializes VGA routing for the path it
considers the primary.
The first question is whether this bridge path pre-configuration is what
we want to keep as the way QEMU communicates the primary VGA device to
Seabios? Obviously we could switch to some kind of fwcfg interface, but
I tend to think what we have is sufficient.
If it is sufficient, then I think we need to rebuild that path on system
reset and we need some way to specify which device to use. One option
would be some kind of per PCIDevice property, perhaps "primary_vga". A
downside is that users can abuse it by trying to set it for more than
one device. Maybe a better approach would be to add a machine property
for it, -machine primary_vga=$id. We'll also need some reasonable way
to pick a default if unspecified.
Does anyone have any thoughts on managing this? Thanks,
Alex
5 years, 10 months
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH] Distinguish between reset types
by Laszlo Ersek
On 02/19/13 23:45, David Woodhouse wrote:
> I'm beginning to wish I'd just ignored the fact that
> we need a properly working "soft" reset to get back from 286 protected
> mode to real mode, and wired up the damn PAM reset unconditionally. I'm
> not convinced that the protected->real mode transition will work for
> anyone anyway.
I believe currently we must be somewhere "between" soft reset & hard
reset. I estimate getting closer to a well-emulated hard reset is more
important than getting closer to a soft one. If you were to extend the
i440FX reset handler so that it unconditionally resets the PAMs, I'd
give my Rb. (Take it for what it's worth :))
The long-term solution covering all targets is being designed, but a
quick shortcut would be nice, and not only for CSM development /
testing. (I gather qemu_prep_reset() in SeaBIOS would not have had to be
written that way, for example.) For CSM stuff we can still carry private
qemu patches of course...
Thanks
Laszlo
5 years, 10 months
[PATCH 1/4] Fix return type of le64_to_cpu() and be64_to_cpu()
by David Woodhouse
From: David Woodhouse <David.Woodhouse(a)intel.com>
Signed-off-by: David Woodhouse <David.Woodhouse(a)intel.com>
---
src/byteorder.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/byteorder.h b/src/byteorder.h
index 5a8a64a..7362aeb 100644
--- a/src/byteorder.h
+++ b/src/byteorder.h
@@ -43,7 +43,7 @@ static inline u16 le16_to_cpu(u16 x) {
static inline u32 le32_to_cpu(u32 x) {
return x;
}
-static inline u32 le64_to_cpu(u64 x) {
+static inline u64 le64_to_cpu(u64 x) {
return x;
}
@@ -62,7 +62,7 @@ static inline u16 be16_to_cpu(u16 x) {
static inline u32 be32_to_cpu(u32 x) {
return swab32(x);
}
-static inline u32 be64_to_cpu(u64 x) {
+static inline u64 be64_to_cpu(u64 x) {
return swab64(x);
}
--
1.8.1.2
5 years, 10 months
Re: [SeaBIOS] [Qemu-devel] [RFC PATCH v4 00/30] ACPI memory hotplug
by Vasilis Liaskovitis
Hi,
sorry for the delay.
On Tue, Feb 19, 2013 at 07:39:40PM -0300, Erlon Cruz wrote:
> On Tue, Dec 18, 2012 at 10:41 AM, Vasilis Liaskovitis <
> vasilis.liaskovitis(a)profitbricks.com> wrote:
>
> > This is v4 of the ACPI memory hotplug functionality. Only x86_64 target is
> > supported (both i440fx and q35). There are still several issues, but it's
> > been a while since v3 and I wanted to get some more feedback on the current
> > state of the patchseries.
> >
> >
> We are working in memory hotplug functionality on pSeries machine. I'm
> wondering whether and how we can better integrate things. Do you think the
> DIMM abstraction is generic enough to be used in other machine types?
I think the DimmDevice is generic enough but I am open to other suggestions.
A related issue is that the patchseries uses a DimmBus to hot-add and hot-remove
DimmDevice. Another approach that has been suggested is to use links<> between
DimmDevices and the dram controller device (piix4 or mch for pc and q35-pc
machines respectively). This would be more similar to the CPUState/qom
patches - see Andreas Färber's earlier reply to this thread.
I think we should get some consensus from the community/maintainers before we
continue to integrate.
I haven't updated the series for a while, but I can rework if there is a more
clear direction for the community.
Another open issue is reference counting of memoryregions in qemu memory
model. In order to make memory hot-remove operations safe, we need to remove
a memoryregion after all users (e.g. both guest and block layer) have stopped
using it, see discussion at
http://lists.gnu.org/archive/html/qemu-devel/2012-10/msg03986.html. There was a
relevant ibm patchset
https://lists.gnu.org/archive/html/qemu-devel/2012-11/msg02697.html
but it was not merged.
>
>
> > Overview:
> >
> > Dimm device layout is modeled with a normal qemu device:
> >
> > "-device dimm,id=name,size=sz,node=pxm,populated=on|off,bus=membus.0"
> >
> >
> How does this will handle the no-hotplugable memory for example the memory
> passed in '-m' parameter?
The non-hotpluggable initial memory (-m) is currently not modelled at all as a
DimmDevice. We may want to model it though.
thanks,
- Vasilis
5 years, 10 months
SeaBIOS v1.7.2.1 stable release
by Kevin O'Connor
A new stable release of SeaBIOS (version 1.7.2.1) has been tagged.
This release contains bug fixes, including several fixes for build
problems.
The release is available via git:
git clone git://git.seabios.org/seabios -b 1.7.2-stable
-Kevin
Kevin O'Connor (4):
Update tools/acpi_extract.py to handle iasl 20130117 release.
Fix Makefile - don't reference "out/" directly, instead use "$(OUT)".
build: Don't require $(OUT) to be a sub-directory of the main directory.
Verify CC is valid during build tests.
Alex Williamson (3):
seabios q35: Enable all PIRQn IRQs at startup
seabios q35: Add new PCI slot to irq routing function
seabios: Add a dummy PCI slot to irq mapping function
Avik Sil (1):
USB-EHCI: Fix null pointer assignment
Makefile | 10 +++++-----
src/Kconfig | 2 +-
src/pciinit.c | 47 ++++++++++++++++++++++++++++++++++++++++++-----
src/usb-ehci.c | 2 +-
tools/acpi_extract.py | 4 ++--
tools/test-build.sh | 23 +++++++++++++++--------
6 files changed, 66 insertions(+), 22 deletions(-)
5 years, 10 months
[RFC] SeaBIOS v1.7.2.1 stable release
by Kevin O'Connor
There's been requests for a stable release. Here's a list of patches
that have been requested / that I think would be useful:
616fb27f - Update tools/acpi_extract.py to handle iasl 20130117 release.
7cac600a - USB-EHCI: Fix null pointer assignment
4c405cbf - Fix Makefile - don't reference "out/" directly, instead use "$(OUT)".
23219122 - build: Don't require $(OUT) to be a sub-directory of the main directory.
bb0808a2 - Verify CC is valid during build tests.
555a2136 - seabios q35: Enable all PIRQn IRQs at startup
b9490408 - seabios q35: Add new PCI slot to irq routing function
dbb7a66f - seabios: Add a dummy PCI slot to irq mapping function
Comments?
-Kevin
5 years, 10 months
