On Wed, Apr 23, 2014 at 12:13:48PM +0200, Gerd Hoffmann wrote:
> Series looks good to me.
Awesome, thanks! Here's one more iteration, rearranging things
to start with the most benign and uncontroversial patches, and
progressing toward the "payload" at the end :)
> /me wonders though how you've tested the final revision and the compat
> stuff. Patch #6 doesn't actually add a new machine type where the
> non-legacy mode is active ...
Why, by commenting and uncommenting "smbios_legacy_mode = true;"
in the *compat_2_0() functions :) I realized I was being silly
after sending out the v7 series, and added something more or less
similar to what you wrote, and was saving it for v8. I squashed it
on top of the compat functions, see patch 2/7.
> I'll go wait for a few days for additional feedback, then [...]
> send out a pull request.
Sounds like a plan! BTW, would it make sense to have Kevin apply
this: http://www.seabios.org/pipermail/seabios/2014-April/007856.html
to SeaBIOS and then pull a new blob from there around the same
time (or before ?) this patch set is applied to QEMU ?
Thanks much,
Gabriel
Gabriel L. Somlo (7):
E820: Add interface for accessing e820 table
PC: Add machine version 2.1 for piix and q35
SMBIOS: Rename symbols to better reflect future use
SMBIOS: Update header file definitions
SMBIOS: Use macro to set smbios defaults
SMBIOS: Use bitmaps to prevent incompatible comand line options
SMBIOS: Build aggregate smbios tables and entry point
hw/i386/pc.c | 39 ++-
hw/i386/pc_piix.c | 43 ++-
hw/i386/pc_q35.c | 37 ++-
hw/i386/smbios.c | 789 +++++++++++++++++++++++++++++++++++++++++++----
include/hw/i386/pc.h | 2 +
include/hw/i386/smbios.h | 99 ++++--
6 files changed, 902 insertions(+), 107 deletions(-)
--
1.9.0
New in version 7 of the patch set:
- patch set now down to only 7 patches;
- machine versions 2.0 and older currently unaffected by this patch set,
will continue using field overrides as before
- patches 1..6 are very small and simple, and set the stage for patch #7
- patch 7 introduces the new aggregate-table functionality; it consists
mostly of insertions, and should therefore be relatively easy to follow.
- "-smbios file=<foo>" functionality happens before we know whether we're
in legacy or new/aggregate-table mode, so we insert the file blob(s) into
both the legacy and the aggregate tables, and keep the one we need once
we know which one that is.
For those interested, the code is also structured for easy subsequent removal
of the legacy mode, if/when that becomes applicable ;)
Thanks again for any feedback and comments (or for just applying the patch) !
Gabriel
Gabriel L. Somlo (7):
SMBIOS: Rename symbols to better reflect future use
SMBIOS: Update header file definitions
SMBIOS: Use macro to set smbios defaults
SMBIOS: Use bitmaps to prevent incompatible comand line options
E820: Add interface for accessing e820 table
PC: Add (empty) compat functions for machine version 2.0
SMBIOS: Build aggregate smbios tables and entry point
hw/i386/pc.c | 39 ++-
hw/i386/pc_piix.c | 29 +-
hw/i386/pc_q35.c | 25 +-
hw/i386/smbios.c | 789 +++++++++++++++++++++++++++++++++++++++++++----
include/hw/i386/pc.h | 2 +
include/hw/i386/smbios.h | 99 ++++--
6 files changed, 879 insertions(+), 104 deletions(-)
--
1.9.0
New in version 6 of the patch set:
- down to 17 patches (squashed adding spec v2.4 fields
in together with adding v2.8 fields further down).
- switching to monolithic aggregate tables plus entry point
in patch 11/17, right after accomplishing full SeaBIOS
compatibility (in 10/17).
- Type 0 (bios info) structure continues to be optional. The BIOS
is expected to supply its own Type 0 structure unless we force
one to be provided via the command line.
On Mon, Apr 14, 2014 at 11:14:08AM +0200, Gerd Hoffmann wrote:
> I also think we should continue providing the tables one-by-one using
> the old interface, at least for a transition period, so older seabios
> versions continue to work.
Is *this* a hard requirement for merging ? I'm currently brainstorming
for ways to do this that won't be horrifyingly ugly, but so far everything
I managed to come up with makes me want to scratch my eyes out :)
Thanks,
Gabriel
Gabriel L. Somlo (17):
SMBIOS: Rename smbios_set_type1_defaults() for more general use
SMBIOS: Use macro to set smbios defaults
SMBIOS: Use bitmaps to check for smbios table collisions
SMBIOS: Add code to build full smbios tables; build type 2 table
SMBIOS: Build full tables for types 0 and 1
SMBIOS: Remove unused code for passing individual fields to bios
SMBIOS: Build full type 3 table
SMBIOS: Build full type 4 tables
SMBIOS: Build full smbios memory tables (type 16, 17, 19, and 20)
SMBIOS: Build full tables for type 32 and 127
SMBIOS: Generate aggregate smbios tables, including entry point
SMBIOS: Remove SeaBIOS compatibility quirks
SMBIOS: Stop including type 20 tables
SMBIOS: Use e820 memory map to generate type 19 tables
SMBIOS: Update type 3 definition to smbios spec v2.7
SMBIOS: Update type 4 definition to smbios spec v2.6
SMBIOS: Update memory table types (16, 17, and 19) to smbios spec v2.8
hw/i386/pc.c | 35 ++-
hw/i386/pc_piix.c | 14 +-
hw/i386/pc_q35.c | 10 +-
hw/i386/smbios.c | 762 +++++++++++++++++++++++++++++++++++++++--------
include/hw/i386/pc.h | 2 +
include/hw/i386/smbios.h | 98 ++++--
6 files changed, 745 insertions(+), 176 deletions(-)
--
1.9.0
Am Samstag, den 19.04.2014, 12:30 -0400 schrieb Kevin O'Connor:
> Modify the int 1587 handler to check if the POST phase is still
> running. If it is, use bigreal mode segment limits so that the caller
> remains in bigreal mode when the 1587 handler completes. This helps
> with SeaVGABIOS' use of "direct" framebuffer accesses (an option rom
> may attempt to display text during its option rom execution which can
> cause SeaVGABIOS to make the int 1587 calls).
Did you experience this or is that just a precaution? If you did
experience this, could you please elaborate what hardware you used and
which Option ROMs were executed?
[…]
Thanks,
Paul
On Sat, Apr 12, 2014 at 12:00:50PM -0400, Kevin O'Connor wrote:
> Signed-off-by: Kevin O'Connor <kevin(a)koconnor.net>
FYI, I have committed this patch.
-Kevin
v5 -> v6:
- Minor, fixed a typo in the subject
v4 -> v5
- Addressed Michael S. Tsirkin's comments (patch 2/2):
- Open-coded pci_config_is_reserved() method.
v3 -> v4:
- Addressed Kevin O'Connor's comments:
- Refactored a for loop in patch 1/2.
- Addressed Michael S. Tsirkin's comments (patch 2/2):
- Removed not needed method
- Test only base registers (dropped limits tests)
- Renamed a helper method
- Used 0xFF to test if the memory is reserved
- Simplified code in pci_bridge_has_region
- I did keep the code that restores base's address as I don't want
to modify the registers in a 'query' method. (as replied on the mail thread)
v2 -> v3:
- Addressed Michael S. Tsirkin's comments:
- I/O and Prefetchable Memory are optional. Do not allocate ranges
if they are not implemented (2/2).
- Note that 2/2 patch can be seen as a separate fix. However, it
is related to ranges reservation.
v1 -> v2:
- Thanks Gerd Hoffmann for the review.
- Addressed Michael S. Tsirkin's comments:
- Limit capabilities query to 256 iterations, to make sure we
don't get into an infinite loop with a broken device.
If a pci-2-pci bridge supports hot-plug functionality but there are no devices
connected to it, reserve IO/mem in order to be able to attach devices
later. Do not waste space, use minimum allowed.
Marcel Apfelbaum (2):
hw/pci: reserve IO and mem for pci-2-pci bridges with no devices
attached
hw/pci: check if pci2pci bridges implement optional limit registers
src/fw/pciinit.c | 12 +++++-------
src/hw/pci.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
src/hw/pci.h | 10 ++++++++++
3 files changed, 60 insertions(+), 7 deletions(-)
--
1.8.3.1
On 15/04/14 19:57, Idwer Vollering wrote:
> 2014-04-15 19:22 GMT+02:00 Roger Pau Monne <roger.pau(a)citrix.com>:
>> On FreeBSD, the name of the emulation is "-melf_i386_fbsd", so allow
>> SeaBIOS to fetch the emulation to use from the environment variables.
>>
>> This allows SeaBIOS to compile on FreeBSD with gcc.
>
> What about clang? On FreeBSD >= 10 you need gcc from ports.
Well, as stated on the commit message, this only fixes the linker issue,
it still requires gcc. I will certainly look into getting it compiled
with clang, but it is not a priority for me right now.
Roger.