These patches, with the support in QEMU (patches in the QEMU mailing
list) make the Linux kernel setup and boot approximately 10x faster.
TODO:
* Other ways to boot when detecting fw_cfg DMA interface?
* Is 0xfef00000 a good address? Is there any better address? Is it
possible to not make it hardcoded?
Marc Marí (2):
Add QEMU fw_cfg dma interface support
Add Linux boot code for the fw_cfg dma interface
src/boot.c | 14 ++-
src/config.h | 1 +
src/fw/paravirt.c | 298 +++++++++++++++++++++++++++++++++++++++++++-----------
src/fw/paravirt.h | 50 +++++++++
src/romlayout.S | 20 ++++
5 files changed, 321 insertions(+), 62 deletions(-)
--
2.4.3
This series expands the sdcard init sequence (as detailed in the SDHCI
spec). It will probably still only work under QEMU, but it's further
along.
-Kevin
Kevin O'Connor (5):
sdcard: Check if card is present before sending commands to card
sdcard: Implement controller frequency setting according to sdhci spec
sdcard: Make sure controller support 3.3V before enabling it
sdcard: Set timeout control register during init (to max allowed
timeout)
sdcard: Improve SD card initialization command sequence
src/hw/sdcard.c | 110 +++++++++++++++++++++++++++++++++++++++++++++++++++-----
1 file changed, 101 insertions(+), 9 deletions(-)
--
1.9.3
Bits 16-31 of the SMM revision ID are feature bits. We only need to
check that SMBASE relocation is supported, but do not care about other
features. In particular, this allows the SMM I/O instruction restart
feature to be present.
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
---
src/fw/smm.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/fw/smm.c b/src/fw/smm.c
index dabc677..6cb484e 100644
--- a/src/fw/smm.c
+++ b/src/fw/smm.c
@@ -18,8 +18,14 @@
#include "util.h" // smm_setup
#include "x86.h" // wbinvd
-#define SMM_REV_I32 0x00020000
-#define SMM_REV_I64 0x00020064
+/*
+ * Check SMM state save area format (bits 0-15) and require support
+ * for SMBASE relocation.
+ */
+#define SMM_REV_MASK 0x0002ffff
+
+#define SMM_REV_I32 0x00020000
+#define SMM_REV_I64 0x00020064
struct smm_state {
union {
@@ -62,9 +68,10 @@ handle_smi(u16 cs)
if (smm == (void*)BUILD_SMM_INIT_ADDR) {
// relocate SMBASE to 0xa0000
- if (smm->cpu.i32.smm_rev == SMM_REV_I32) {
+ u32 rev = smm->cpu.i32.smm_rev & SMM_REV_MASK;
+ if (rev == SMM_REV_I32) {
smm->cpu.i32.smm_base = BUILD_SMM_ADDR;
- } else if (smm->cpu.i64.smm_rev == SMM_REV_I64) {
+ } else if (rev == SMM_REV_I64) {
smm->cpu.i64.smm_base = BUILD_SMM_ADDR;
} else {
warn_internalerror();
--
2.3.5
The value is the first argument and the port is the second, but the code
was using the opposite order.
Reported-by: Stefan Weil <sw(a)weilnetz.de>
Reviewed-by: Stefan Weil <sw(a)weilnetz.de>
Signed-off-by: Paolo Bonzini <pbonzini(a)redhat.com>
---
src/fw/smm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/fw/smm.c b/src/fw/smm.c
index 6cb484e..5145f14 100644
--- a/src/fw/smm.c
+++ b/src/fw/smm.c
@@ -184,7 +184,7 @@ static void piix4_apmc_smm_setup(int isabdf, int i440_bdf)
/* enable SMI generation */
value = inl(acpi_pm_base + PIIX_PMIO_GLBCTL);
- outl(acpi_pm_base + PIIX_PMIO_GLBCTL, value | PIIX_PMIO_GLBCTL_SMI_EN);
+ outl(value | PIIX_PMIO_GLBCTL_SMI_EN, acpi_pm_base + PIIX_PMIO_GLBCTL);
smm_relocate_and_restore();
--
2.4.3
hi,all
When qemu vcpus value is 76~86, the qemu cannot find boot disk.
The problem happens on seabios: mptable_setup will use much ZoneFSeg
memory with the increase of the vcpus,and init_atadrive zonefseg
allocation fails,so the seabios cannot find disk. 87 vcpus works just
because mptable_setup ZoneFSeg allocation fails, then init_atadrive gets
the memory.
Because I am not familiar with bios, init_atadrive with ZoneLow or
ZoneHigh instead of ZoneFSeg causes problems. and ZoneFSeg does not seem
to be extended. init_atadrive also cannot be ahead of mptable_setup.
it maybe a way for qemu that using "CONFIG_MPTABLE" to omit
mptable_setup, because qemu with 87 and more vcpus works well.
Any advices can be given to me for the bugfix ?
Thanks
Huaitong
On Mon, 27 Jul 2015 21:40:59 -0400
"Kevin O'Connor" <kevin(a)koconnor.net> wrote:
> On Mon, Jul 27, 2015 at 05:13:52PM +0200, Marc Marí wrote:
> > Hi again
> >
> > Another way to speed up boot times we are looking at is using
> > Intel's new PMEM, based on NVDIMMs (non-volatile DIMMs). These are
> > discoverable through ACPI tables and mapped in the address space
> > (they can also be used as a block device). Intel already
> > implemented the emulation for QEMU [1], and we think it might be
> > even faster than QEMU's pflash.
> >
> > This generates a new problem: this new device is mapped above 4G.
> > This means, the zone cannot be accessed directly by 32 bits
> > SeaBIOS. There are some solutions to this problem. The ones I've
> > read about are:
> > - Do some magic with paging
> > - Enable 64 bit long mode
> >
> > Which do you think is the best way to proceed, at least for the
> > sake of testing this PMEM?
> >
> > From a wider point of view: do you think it's worth to move (all or
> > some part) of SeaBIOS to 64 bits?
> >
> > [1] http://permalink.gmane.org/gmane.comp.emulators.kvm.devel/137514
>
> I don't think it would make sense to convert all of SeaBIOS to 64bit
> as SeaBIOS still needs to be able to run in 16bit and 32bit mode. So,
> it would be an extra mode.
>
> I suspect to add something like this it would be easiest to just have
> a kernel booting shim that used 64bit mode or setup paging.
Yes, that seems the most sensible option. A link about implementation:
http://wiki.osdev.org/Setting_Up_Long_Mode
If there are no more ideas, I'll be working on it for the next weeks.
Any suggestions/tips/other about x86 or how to do it are appreciated.
> Note that if it's defined in the ACPI DSDT, then it could be a real
> pain to parse. The DSDT is it's own interpreted language.
It is not defined in the ACPI DSDT. It is a new ACPI table (ACPI version
6, NFIT table). I've already been able to read and parse that table from
SeaBIOS.
> Also, if the kernel has to be copied to a memory location, then I
> would be surprised that DMA fw_cfg would be slower than a PMEM
> solution. Ultimately, I would think that QEMU could copy the kernel
> to ram as fast or faster than the guest could.
Another thing that I have in my bucket of things to try is booting
Linux directly in 32 bit or 64 bit mode. If the kernel is boot in 64
bit mode directly, the image can be mapped anywhere, including above
4G. This avoids copying, and some 16 bit mode things. But that's not
the intention at this precise moment. It might be the next step.
At the end of:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Docu...
> It would be great if we could go on-list with this discussion.
>
Added the NVDIMM link again and CC'd list.
Thanks
Marc
Hi,
I've discovered a mess:
- bootorder paths for ATA-SFF devices do not use the
channel/port-on-controller number in the path, instead they use a
volatile and unique-to-each-channel number that has no relation
to the actual arrangement of the hardware.
For instance, on a MCP55-based machine (no AHCI, but plenty of
ATA-SFF channels/ports:
The master drive on the PATA channel is (and should be, but is only
by coincidence) /pci@i0cf8/*@4/drive@0/disk@0 but the first SATA port
on /pci@i0cf8/*@5 is currently detected by SeaBIOS as something other
than /pci@i0cf8/*@5/drive@0/disk@0 (the drive@ number is something
like 2) and the second SATA port is something other than
/pci@i0cf8/*@5/drive@1/disk@0 (drive@ number is usually more like 3)
The /pci@i0cf8/*@5 controller only has two ports on it.
- bootprio_find_ata_device() is shared between the ahci.c and ata.c
drivers. This becomes interesting in a system using SeaBIOS as CSM
and/or having certain combinations of ATA-SFF and/or AHCI controllers.
(And why does the SeaBIOS CSM even have drivers in it? I would have
thought it would be using the UEFI drivers...but maybe we had to
ExitBootServices() to work properly...)
- Thus the chanid argument to csm_bootprio_ata() could be any of two
unrelated things:
- the global-based index of a ata.c channel
- the controller-based port index of any of the ahci.c controllers in
the system
I've attached a patch that attempts to address the issue with the ata.c
bootorder paths, but it doesn't really fix the actual problem.
Jonathan Kollasch
Don't require coreboot to use CONFIG_FLASH_FLOPPY - with the latest
QEMU, it's possible to place a floppy image into fw_cfg using the qemu
command line (eg, "-fw_cfg name=floppyimg/MyFloppy,file=file.img").
Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net>
---
src/Kconfig | 13 +++++++------
src/hw/ramdisk.c | 2 +-
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/src/Kconfig b/src/Kconfig
index b14e554..d70624e 100644
--- a/src/Kconfig
+++ b/src/Kconfig
@@ -96,12 +96,6 @@ endchoice
the CBFS filesystem is at a non-standard location (eg,
0xffe00000 if CBFS ends 2Meg below the end of flash).
- config FLASH_FLOPPY
- depends on COREBOOT_FLASH
- bool "Floppy images in CBFS"
- default y
- help
- Support floppy images in coreboot flash.
config MULTIBOOT
depends on COREBOOT
bool "multiboot support"
@@ -220,6 +214,13 @@ menu "Hardware support"
default y
help
Support floppy drive access.
+ config FLASH_FLOPPY
+ depends on DRIVES
+ bool "Floppy images from CBFS or fw_cfg"
+ default y
+ help
+ Support floppy images stored in coreboot flash or from
+ QEMU fw_cfg.
config PS2PORT
depends on KEYBOARD || MOUSE
diff --git a/src/hw/ramdisk.c b/src/hw/ramdisk.c
index e847824..4cdf95f 100644
--- a/src/hw/ramdisk.c
+++ b/src/hw/ramdisk.c
@@ -53,7 +53,7 @@ ramdisk_setup(void)
if (!drive)
return;
drive->type = DTYPE_RAMDISK;
- dprintf(1, "Mapping CBFS floppy %s to addr %p\n", filename, pos);
+ dprintf(1, "Mapping floppy %s to addr %p\n", filename, pos);
char *desc = znprintf(MAXDESCSIZE, "Ramdisk [%s]", &filename[10]);
boot_add_floppy(drive, desc, bootprio_find_named_rom(filename, 0));
}
--
1.9.3
