On 18.05.2015 20:48, John Ferlan wrote: > > > 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: A-ha! Looking at qemu-options.hx (more precisely on commit b155eb1d0409eff4d0e7f33c746c81434f0ea629) it shows that qemu supports @family. Well, digging deeper into the code shows it doesn't. I'll patch qemu firstly and then resend my patches. > > ./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@xxxxxxxxxx> >> --- >> 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. Fortunately, this is filled in with some defaults by qemu. So we can save that for later. The rest of the comments will be addressed in v2. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list