Re: [libvirt] [PATCH 3/3] virSysinfo: Introduce SMBIOS type 2 support

On 05/12/2015 10:56 AM, Michal Privoznik wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1220527 > > This type of information defines attributes of a system > baseboard. With one caveat: in qemu they call it family, while > in the specification it's referred to as type. I'm sticking with > the latter. Hmm... It seems qemu_smbios_type2_opts has 'type' (and it's a number, more on that later...)... The "type1_opts" has 'family'... Or am I looking at the wrong place... I just pulled/built the latest sources from git://git.qemu.org/qemu.git and see:

./qemu-system-x86_64 --help | grep smbios -smbios file=binary -smbios type=0[,vendor=str][,version=str][,date=str][,release=%d.%d] -smbios type=1[,manufacturer=str][,product=str][,version=str][,serial=str] -smbios type=2[,manufacturer=str][,product=str][,version=str][,serial=str] -smbios type=3[,manufacturer=str][,version=str][,serial=str][,asset=str] -smbios type=4[,sock_pfx=str][,manufacturer=str][,version=str][,serial=str] -smbios type=17[,loc_pfx=str][,bank=str][,manufacturer=str][,serial=str] > > Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com&gt; > --- > docs/formatdomain.html.in | 37 +++++- > docs/schemas/domaincommon.rng | 24 ++++ > src/conf/domain_conf.c | 57 +++++++++ > src/libvirt_private.syms | 1 + > src/qemu/qemu_command.c | 48 +++++++ > src/util/virsysinfo.c | 160 +++++++++++++++++++++++- > src/util/virsysinfo.h | 14 +++ > tests/qemuxml2argvdata/qemuxml2argv-smbios.args | 2 + > tests/qemuxml2argvdata/qemuxml2argv-smbios.xml | 9 ++ > 9 files changed, 346 insertions(+), 6 deletions(-) > According to how I read page 34 of the pdf file from .0: NOTE If more than one Type 2 structure is provided by an SMBIOS implementation, each structure shall include the Number of Contained Object Handles and Contained Object Handles fields to specify which system elements are contained on which boards. It seems we can have one of these in the SMBIOS... our .rng supports it, but we don't document it that way nor does the code handle more than one. Although I'll note that the Type0 (BIOS) and Type1 (SYSTEM) only support one, but the .rng has "oneOrMore"... If QEMU doesn't support more than 1, then we will need to document/ describe that. I assume there could be some other hypervisor that may want to support more than one. Also it seems that based on settings found in Type2, there could be a need/use for Type3 data.