SeaBIOS

seabios@seabios.org

4 participants
3801 discussions

[PATCH] tsc: use kvmclock for calibration
by Gerd Hoffmann 13 Aug '12

13 Aug '12

Use kvmclock for tsc calibration when running on kvm. Without this the tsc frequency calibrated by seabios can be *way* off in case the virtual machine is booted on a loaded host. I've seen seabios calibrating 27 instead of ca. 2800 MHz, resulting in timeouts being to short by factor 100. Which in turn leads to disk I/O errors due to timeouts, especially as I/O requests tend to take a bit longer than usual on a loaded box ... Signed-off-by: Gerd Hoffmann <kraxel(a)redhat.com> --- src/clock.c | 9 +++++ src/paravirt.c | 90 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ src/paravirt.h | 1 + 3 files changed, 100 insertions(+), 0 deletions(-) diff --git a/src/clock.c b/src/clock.c index 69e9f17..5883b1a 100644 --- a/src/clock.c +++ b/src/clock.c @@ -13,6 +13,7 @@ #include "bregs.h" // struct bregs #include "biosvar.h" // GET_GLOBAL #include "usb-hid.h" // usb_check_event +#include "paravirt.h" // kvm clock // RTC register flags #define RTC_A_UIP 0x80 @@ -80,6 +81,14 @@ calibrate_tsc(void) return; } + if (kvm_para_available()) { + u32 khz = kvm_tsc_khz(); + if (khz != 0) { + SET_GLOBAL(cpu_khz, khz); + return; + } + } + // Setup "timer2" u8 orig = inb(PORT_PS2_CTRLB); outb((orig & ~PPCB_SPKR) | PPCB_T2GATE, PORT_PS2_CTRLB); diff --git a/src/paravirt.c b/src/paravirt.c index 2a98d53..942ce11 100644 --- a/src/paravirt.c +++ b/src/paravirt.c @@ -12,6 +12,7 @@ #include "ioport.h" // outw #include "paravirt.h" // qemu_cfg_port_probe #include "smbios.h" // struct smbios_structure_header +#include "biosvar.h" // GET_GLOBAL int qemu_cfg_present; @@ -346,3 +347,92 @@ void qemu_cfg_romfile_setup(void) dprintf(3, "Found fw_cfg file: %s (size=%d)\n", file->name, file->size); } } + +#define KVM_CPUID_SIGNATURE 0x40000000 +#define KVM_CPUID_FEATURES 0x40000001 +#define KVM_FEATURE_CLOCKSOURCE 0 +#define KVM_FEATURE_CLOCKSOURCE2 3 +#define MSR_KVM_SYSTEM_TIME 0x12 +#define MSR_KVM_SYSTEM_TIME_NEW 0x4b564d01 + +struct pvclock_vcpu_time_info { + u32 version; + u32 pad0; + u64 tsc_timestamp; + u64 system_time; + u32 tsc_to_system_mul; + s8 tsc_shift; + u8 flags; + u8 pad[2]; +} PACKED; + +/* + * do_div() is NOT a C function. It wants to return + * two values (the quotient and the remainder), but + * since that doesn't work very well in C, what it + * does is: + * + * - modifies the 64-bit dividend _in_place_ + * - returns the 32-bit remainder + * + * This ends up being the most efficient "calling + * convention" on x86. + */ +#define do_div(n, base) \ + ({ \ + unsigned long __upper, __low, __high, __mod, __base; \ + __base = (base); \ + asm("" : "=a" (__low), "=d" (__high) : "A" (n)); \ + __upper = __high; \ + if (__high) { \ + __upper = __high % (__base); \ + __high = __high / (__base); \ + } \ + asm("divl %2" : "=a" (__low), "=d" (__mod) \ + : "rm" (__base), "0" (__low), "1" (__upper)); \ + asm("" : "=A" (n) : "a" (__low), "d" (__high)); \ + __mod; \ + }) + +static u64 pvclock_tsc_khz(struct pvclock_vcpu_time_info *src) +{ + u64 pv_tsc_khz = 1000000ULL << 32; + + do_div(pv_tsc_khz, src->tsc_to_system_mul); + if (src->tsc_shift < 0) + pv_tsc_khz <<= -src->tsc_shift; + else + pv_tsc_khz >>= src->tsc_shift; + return pv_tsc_khz; +} + +u64 kvm_tsc_khz(void) +{ + u32 eax, ebx, ecx, edx, msr; + struct pvclock_vcpu_time_info time; + u32 addr = (u32)(&time); + u64 khz; + + /* check presence and figure msr number */ + cpuid(KVM_CPUID_FEATURES, &eax, &ebx, &ecx, &edx); + if (eax & KVM_FEATURE_CLOCKSOURCE2) { + msr = MSR_KVM_SYSTEM_TIME_NEW; + } else if (eax & KVM_FEATURE_CLOCKSOURCE) { + msr = MSR_KVM_SYSTEM_TIME; + } else { + return 0; + } + + /* ask kvm hypervisor to fill struct */ + memset(&time, 0, sizeof(time)); + wrmsr(msr, addr | 1); + wrmsr(msr, 0); + if (time.version < 2 || time.tsc_to_system_mul == 0) + return 0; + + /* go figure tsc frequency */ + khz = pvclock_tsc_khz(&time); + dprintf(1, "Using kvmclock, msr 0x%x, tsc %d MHz\n", + msr, (u32)khz / 1000); + return khz; +} diff --git a/src/paravirt.h b/src/paravirt.h index a284c41..eedfcc3 100644 --- a/src/paravirt.h +++ b/src/paravirt.h @@ -27,6 +27,7 @@ static inline int kvm_para_available(void) return 0; } +extern u64 kvm_tsc_khz(void); #define QEMU_CFG_SIGNATURE 0x00 #define QEMU_CFG_ID 0x01 -- 1.7.1

5 22

Re: [SeaBIOS] Compiling SeaBIOS for coreboot has problems with its ACPI code
by Michael S. Tsirkin 12 Aug '12

12 Aug '12

On Thu, Aug 09, 2012 at 02:59:45AM +0000, Moore, Robert wrote: > > > >-----Original Message----- > >From: Kevin O'Connor [mailto:kevin@koconnor.net] > >Sent: Wednesday, August 08, 2012 7:23 PM > >To: Moore, Robert > >Cc: Michael S. Tsirkin; Idwer Vollering; seabios(a)seabios.org; Tang, Feng; > >coreboot(a)coreboot.org > >Subject: Re: [SeaBIOS] Compiling SeaBIOS for coreboot has problems with its > >ACPI code > > > >On Tue, Aug 07, 2012 at 07:34:37PM +0000, Moore, Robert wrote: > >> This is very interesting. If I understand correctly, you are using a > >> utility plus various directives to generate tables of AML offsets -- > >> presumably in order to dynamically change AML values, correct? > > > >Yes - exactly. We started off completely generating the SSDT > >dynamically, but that got awkward when we needed to generate Processor > >objects dynamically. So, we compiled an SSDT as template and then > >patched it. It was fragile to hard-code the offsets, so a tool was > >written to parse the IASL output and generate the offsets > >automatically. > > > >I'm CC'ing the coreboot list - they have also been doing SSDT runtime > >generation. > > > >> I have to say that I have not seen anything like this, from any BIOS > >vendor. > >> > >> > By the way, is there interest in adding some of the functionality that > >> > we get by parsing the listing to iasl directly? > >> > >> We are always interested in adding features to make the compiler > >> more useful. What would you suggest? > > > >The tool currently generates offsets and can rename the Amlcode[] > >variable to something more unique. I'm sure additional features could > >be thought up. > > > >-Kevin > > > Here are additional thoughts and questions that I sent out earlier today: > > > > > >From what we have seen, standard BIOS code often modifies the AML on the fly (before the OS gets the ACPI tables) to handle the various setup options and other things. Some vendors do this better than others (we've seen checksum errors because of this, as well as package length issues because, for example, a byte constant is replaced by a dword constant but there is no room for the 32-bit value.) > > Obviously, the iASL compiler knows the offset of not only the start of every ASL statement, but also the start of every argument of every ASL statement. > > What we would be willing to provide is a new type of output file that provides arrays of offsets for you to use when modifying the AML. Something like this should be useful for your project, as well as standard BIOS code that needs this information as well. > > The -sc option for iASL already provides a limited version of this, but only at the statement level with offsets within a trailing comment field: > > /* > * 10....{ > * 11.... Method (MAIN, 0, NotSerialized) > */ > unsigned char DSDT_Template_MAIN [] = > { > 0x14,0x08,0x4D,0x41,0x49,0x4E,0x00, /* 00000023 "..MAIN." */ > > /* > * 12.... { > * 13.... Return (Zero) > */ > 0xA4,0x00, /* 00000025 ".." */ > > A new type of output file could instead create arrays of offsets, one offset per ASL term (statement or argument). The format could be something like one array per ASL statement or one array per method. You could then pick and choose which of these arrays you want to use/include into your BIOS code. > > Does this sound like it would solve your issues? > > Thanks, > Bob Hmm. How would C code know which of the statements it needs? For example, we could have many Return(Zero) statements but only want to patch some of them. Would it be possible to allow some tags in the AML code that specifies which offsets to extract, and how to name the arrays? It would also be useful to specify the array names for the AML code, to avoid dependencies between C code and makefiles. For example, code could look like this: /* Pull in required macros, also allows iasl to figure out it is not in compatibility mode. */ #include <acpi-extract.h> /* Put all code in this definition block in AmlCode array */ ACPI_EXTRACT_CODE(AmlCode) DefinitionBlock ("ssdt-pcihp.aml", "SSDT", 0x01, "BXPC", "BXSSDTPCIHP", 0x1) Name (_S4, /* Put offset of next argument in acpi_s4_pkg array */ ACPI_EXTRACT_OFFSET(acpi_s4_pkg) Package (0x04) { 0x2, /* PM1a_CNT.SLP_TYP */ 0x2, /* PM1b_CNT.SLP_TYP */ Zero, /* reserved */ Zero /* reserved */ }) One other thing to note about our scripts is that offsets are often small, our scripts make the array the correct type (char,short,int,long) to make it fit, to avoid wasting memory. You might want to do the same. -- MST

1 0

Re: [SeaBIOS] SeaBIOS "latest updates" broken for few weeks
by Alec Ari 11 Aug '12

11 Aug '12

To: Alec Ari <neotheuser(a)ymail.com> Cc: "seabios(a)seabios.org" <seabios(a)seabios.org> Sent: Sunday, August 5, 2012 1:44 AM Subject: Re: [SeaBIOS] SeaBIOS "latest updates" broken for few weeks >I get the same error. Thanks for the feedback! -Alec

1 1

Re: [SeaBIOS] How much RAM is required?
by Markus Armbruster 10 Aug '12

10 Aug '12

"Fred ." <eldmannen(a)gmail.com> writes: > On Fri, Aug 10, 2012 at 5:28 PM, Markus Armbruster <armbru(a)redhat.com> wrote: >> Frediano Ziglio <frediano.ziglio(a)citrix.com> writes: >> >>> On Fri, 2012-08-10 at 16:24 +0200, Peter Stuge wrote: >>>> Fred . wrote: >>>> > No, I am not. >>>> >>>> Ok, so there's only a hypothesis. >>>> >>>> >>>> > But I believe QEMU does have the functionality to load an arbitrary >>>> > firmware. So the firmware doesn't necessarily have to be SeaBIOS. >>>> >>>> As you may know the 8086 reset vector is at 1MB-16 so it will be >>>> really difficult to run a PC-like machine with less than 1MB of >>>> memory. I don't believe one has ever existed. >>>> >>> >>> I remember that my manual of the NEC V20 (a 8086 clone with 10 MHZ!) has >>> settings for 256KB of RAM (jumpers of course!) >>> >>> The ROM was "mapped" (physically!) at f0000 with extended ROM at e0000. >> >> According to Wikipedia, the original IBM PC was sold with as little as >> 16KiB RAM. IIRC, 64KiB BIOS ROM at the top of the 1MiB address space. >> >> http://en.wikipedia.org/wiki/IBM_PC >> >> [...] > Some machines also have broken memory modules. > So some computers have 0 byte RAM in that case. :D Yup, be we *can* catch that in QEMU :)

2 1

Re: [SeaBIOS] How much RAM is required?
by Markus Armbruster 10 Aug '12

10 Aug '12

Frediano Ziglio <frediano.ziglio(a)citrix.com> writes: > On Fri, 2012-08-10 at 16:24 +0200, Peter Stuge wrote: >> Fred . wrote: >> > No, I am not. >> >> Ok, so there's only a hypothesis. >> >> >> > But I believe QEMU does have the functionality to load an arbitrary >> > firmware. So the firmware doesn't necessarily have to be SeaBIOS. >> >> As you may know the 8086 reset vector is at 1MB-16 so it will be >> really difficult to run a PC-like machine with less than 1MB of >> memory. I don't believe one has ever existed. >> > > I remember that my manual of the NEC V20 (a 8086 clone with 10 MHZ!) has > settings for 256KB of RAM (jumpers of course!) > > The ROM was "mapped" (physically!) at f0000 with extended ROM at e0000. According to Wikipedia, the original IBM PC was sold with as little as 16KiB RAM. IIRC, 64KiB BIOS ROM at the top of the 1MiB address space. http://en.wikipedia.org/wiki/IBM_PC [...]

2 1

Re: [SeaBIOS] How much RAM is required?
by Peter Stuge 10 Aug '12

10 Aug '12

Fred . wrote: > No, I am not. Ok, so there's only a hypothesis. > But I believe QEMU does have the functionality to load an arbitrary > firmware. So the firmware doesn't necessarily have to be SeaBIOS. As you may know the 8086 reset vector is at 1MB-16 so it will be really difficult to run a PC-like machine with less than 1MB of memory. I don't believe one has ever existed. > Don't know if its possible to make QEMU use an UEFI or OpenFirmware > image instead, or if such an image exists. Sure, but UEFI rather requires 1GB than 1MB. //Peter

2 1

Re: [SeaBIOS] How much RAM is required?
by Peter Stuge 09 Aug '12

09 Aug '12

Fred . wrote: > But QEMU may use other firmware/payload than SeaBIOS which might > require less than 1 MB of RAM. Really? Are you working on one? //Peter

2 1

How much RAM is required?
by Markus Armbruster 09 Aug '12

09 Aug '12

Watch this: $ qemu-system-x86_64 -nodefaults -vnc :0 -monitor stdio -m 16k QEMU 1.1.50 monitor - type 'help' for more information (qemu) qemu: fatal: Trying to execute code outside RAM or ROM at 0x0000000000004000 Admittedly a silly thing to try. I don't really expect SeaBIOS to work with 16KiB of RAM. But I'm curious: how much does it require?

3 4

Re: [SeaBIOS] Compiling SeaBIOS for coreboot has problems with its ACPI code
by Kevin O'Connor 09 Aug '12

09 Aug '12

On Tue, Aug 07, 2012 at 07:34:37PM +0000, Moore, Robert wrote: > This is very interesting. If I understand correctly, you are using a > utility plus various directives to generate tables of AML offsets -- > presumably in order to dynamically change AML values, correct? Yes - exactly. We started off completely generating the SSDT dynamically, but that got awkward when we needed to generate Processor objects dynamically. So, we compiled an SSDT as template and then patched it. It was fragile to hard-code the offsets, so a tool was written to parse the IASL output and generate the offsets automatically. I'm CC'ing the coreboot list - they have also been doing SSDT runtime generation. > I have to say that I have not seen anything like this, from any BIOS vendor. > > > By the way, is there interest in adding some of the functionality that > > we get by parsing the listing to iasl directly? > > We are always interested in adding features to make the compiler > more useful. What would you suggest? The tool currently generates offsets and can rename the Amlcode[] variable to something more unique. I'm sure additional features could be thought up. -Kevin

2 1

Re: [SeaBIOS] Compiling SeaBIOS for coreboot has problems with its ACPI code
by Gleb Natapov 08 Aug '12

08 Aug '12

On Tue, Aug 07, 2012 at 07:34:37PM +0000, Moore, Robert wrote: > This is very interesting. If I understand correctly, you are using a utility plus various directives to generate tables of AML offsets -- presumably in order to dynamically change AML values, correct? > Yes. > I have to say that I have not seen anything like this, from any BIOS vendor. > Physical HW is not as dynamic (if at all) as virtualized one. We do not want to have separate AML table for each possible HW configuration user can create while starting QEMU. > > By the way, is there interest in adding some of the functionality that > > we get by parsing the listing to iasl directly? > > We are always interested in adding features to make the compiler more useful. What would you suggest? > The tool depends on the compiler output and thus fragile. It broke with new compiler version. It would be nice if compiler had a way to generate offsets for us. > Bob > > > > -----Original Message----- > > From: Michael S. Tsirkin [mailto:mst@redhat.com] > > Sent: Sunday, August 05, 2012 1:45 PM > > To: Moore, Robert > > Cc: Idwer Vollering; Kevin O'Connor; seabios(a)seabios.org; Tang, Feng > > Subject: Re: [SeaBIOS] Compiling SeaBIOS for coreboot has problems with > > its ACPI code > > > > On Sun, Aug 05, 2012 at 11:36:15PM +0300, Michael S. Tsirkin wrote: > > > On Mon, Jul 30, 2012 at 07:42:48PM +0000, Moore, Robert wrote: > > > > Yes, you are correct, the listing no longer includes the comments. > > > > > > > > Sorry for causing you a problem. > > > > > > > > What is happening is that the preprocessor parser is stripping the > > comments during the creation of the .i file. Then, the compiler is > > invoked on the .i file -- thus, the comments are gone. > > > > > > > > This is going to take a bit of work to correct, but we will do it. > > > > > > > > In the meantime, try using the -Pn flag to disable the > > preprocessor. When this flag is set, the preprocessor is completely > > bypassed and the compiler should function as it did previously. > > > > > > > > > So we are doing it this way meanwhile. If you change this > > > preprocessor behaviour like you indicated you would, please let us > > > know so e can test. > > > > > > Thanks! > > > > By the way, is there interest in adding some of the functionality that > > we get by parsing the listing to iasl directly? > > Here's what our tool currently supports: > > > > # Process mixed ASL/AML listing (.lst file) produced by iasl -l # > > Locate and execute ACPI_EXTRACT directives, output offset info # # > > Documentation of ACPI_EXTRACT_* directive tags: > > # > > # These directive tags output offset information from AML for BIOS > > runtime # table generation. > > # Each directive is of the form: > > # ACPI_EXTRACT_<TYPE> <array_name> <Operator> (...) # and causes the > > extractor to create an array # named <array_name> with offset, in the > > generated AML, # of an object of a given type in the following > > <Operator>. > > # > > # A directive must fit on a single code line. > > # > > # Object type in AML is verified, a mismatch causes a build failure. > > # > > # Directives and operators currently supported are: > > # ACPI_EXTRACT_NAME_DWORD_CONST - extract a Dword Const object from > > Name() # ACPI_EXTRACT_NAME_WORD_CONST - extract a Word Const object > > from Name() # ACPI_EXTRACT_NAME_BYTE_CONST - extract a Byte Const > > object from Name() # ACPI_EXTRACT_METHOD_STRING - extract a NameString > > from Method() # ACPI_EXTRACT_NAME_STRING - extract a NameString from > > Name() # ACPI_EXTRACT_PROCESSOR_START - start of Processor() block # > > ACPI_EXTRACT_PROCESSOR_STRING - extract a NameString from Processor() # > > ACPI_EXTRACT_PROCESSOR_END - offset at last byte of Processor() + 1 # > > ACPI_EXTRACT_PKG_START - start of Package block # # > > ACPI_EXTRACT_ALL_CODE - create an array storing the generated AML > > bytecode # # ACPI_EXTRACT is not allowed anywhere else in code, except > > in comments. > > > > > > Example: > > > > ACPI_EXTRACT_NAME_DWORD_CONST aml_adr_dword > > Name (_ADR, 0x00010000) > > > > adds the offset of 0x00010000 constant to array aml_adr_dword > > > > Example: > > > > ACPI_EXTRACT_METHOD_STRING aml_ej0_name > > Method (_EJ0, 1) { Return(PCEJ(0x0001)) } > > > > adds the offset of _EJ0 string to array aml_ej0_name > > > > ACPI_EXTRACT_ALL_CODE ssdp_pcihp_aml > > > > names the array to include the generated AML code > > > > -- > > MST > > _______________________________________________ > SeaBIOS mailing list > SeaBIOS(a)seabios.org > http://www.seabios.org/mailman/listinfo/seabios -- Gleb.

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

SeaBIOS