qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEM


From: Gabriel L. Somlo
Subject: [Qemu-devel] E820 (Re: [v4 PATCH 00/12] SMBIOS: build full tables in QEMU)
Date: Wed, 26 Mar 2014 15:58:50 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Mar 18, 2014 at 07:23:17PM -0400, Gabriel L. Somlo wrote:
> At this point, can anyone with access to a real, physical, NUMA
> system dump the smbios tables with dmidecode and post them here?
> I think that would be very informative.

So I thrashed around a bit trying to find a real NUMA box,
and found a Dell R410 whose BIOS claims to support NUMA by
disabling the "Node Interleaving" option (haven't actually
configured it to run NUMA, but based on what else I found,
I no longer think I need to -- keep reading :)

So, to my surprise, I noticed this machine did NOT have any
Type 20 tables in SMBIOS at all !!!

Then, after a more careful reading of the SMBIOS manual, I
noticed that Type 20 was made OPTIONAL as v2.5 of the spec,
cca. 2006 !!!

In conclusion, we *could* simply scan e820 for E820_RAM type
regions and generate Type 19 tables for each one we find,
and we no longer have to care at all about generating Type 20
nodes to link 19s to 17s, which basically makes the problem
go away, as far as I am concerned.

I tested this (omitting Type 20) on OS X (10.6 through 10.9),
XPsp3 and Win7, successfully, without either of them noticing
any changes from previous executions where smbios tables
were "different" (i.e., when they used to include T20).


At this point, though, I'd like some feedback before I shoot
out another version (v5) of this patch set:


- Should I pretend we're generating v2.5 tables ?

        - this means Type 4 now has extra fields (i.e. the
          number of cores, etc), which should be relatively
          easy to add, so I'd be OK doing that, if we agree
          on everything else. Heck, how about going all out
          and implementing v2.8 ? That would get us past the
          2T limit in Types 16, 17, and 19 !

- SeaBIOS is still in charge of providing the smbios_entry_point
  structure, and it's unlikely we can reasonably expect it to
  bump the version to 2.5 (not that it seems to matter, if my
  tests are to be believed)

        - on that note, SeaBIOS will still cheerfully generate
          Type 20 tables if nothing is supplied to it via fw_cfg
          from QEMU, and, again, I'm not sure how likely it is
          we can get it to stop doing that :)

- Does anyone still care ? ;)


Let me know what you all think!

Thanks,
--Gabriel



reply via email to

[Prev in Thread] Current Thread [Next in Thread]