From patchwork Tue Sep 8 16:54:33 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= X-Patchwork-Id: 305919 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1F1E3C433E2 for ; Tue, 8 Sep 2020 16:55:50 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 665A62075A for ; Tue, 8 Sep 2020 16:55:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="QCeuF4ci" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 665A62075A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:37742 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kFguK-0007id-FN for qemu-devel@archiver.kernel.org; Tue, 08 Sep 2020 12:55:48 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:54028) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kFgta-0006cg-NA for qemu-devel@nongnu.org; Tue, 08 Sep 2020 12:55:02 -0400 Received: from us-smtp-1.mimecast.com ([205.139.110.61]:34532 helo=us-smtp-delivery-1.mimecast.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1kFgtX-000486-Vk for qemu-devel@nongnu.org; Tue, 08 Sep 2020 12:55:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1599584098; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=xChAJfksluoJ4gGGMqRpilMygrKMPZ8vHyLA+0pd1Sw=; b=QCeuF4citZ+BKKC92Ob57Xs2YjOAZ5h4a6yPwUryp9gZqdCPSN7ogZDhqDlxiSShyzNsk0 M/+BAZ/fgn1uWHRYqbm3Q+y9aJdMD/eEXq2DR/ho9PBKGul+7A6LZRaGqWZyKu8Fm9ZPo7 ilbDbBUbphrqajMem6B4LSCzj8YAUbQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-314-uBnZ8_0KPP6qOi23pDsHDQ-1; Tue, 08 Sep 2020 12:54:54 -0400 X-MC-Unique: uBnZ8_0KPP6qOi23pDsHDQ-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id DF9B7CD003; Tue, 8 Sep 2020 16:54:50 +0000 (UTC) Received: from localhost.localdomain.com (ovpn-113-154.ams2.redhat.com [10.36.113.154]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7A01A60C0F; Tue, 8 Sep 2020 16:54:39 +0000 (UTC) From: =?utf-8?q?Daniel_P=2E_Berrang=C3=A9?= To: qemu-devel@nongnu.org Subject: [PATCH 0/5] Add support for loading SMBIOS OEM strings from a file Date: Tue, 8 Sep 2020 17:54:33 +0100 Message-Id: <20200908165438.1008942-1-berrange@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=berrange@redhat.com X-Mimecast-Spam-Score: 0.002 X-Mimecast-Originator: redhat.com Received-SPF: pass client-ip=205.139.110.61; envelope-from=berrange@redhat.com; helo=us-smtp-delivery-1.mimecast.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/08 01:08:25 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , =?utf-8?q?Daniel_P=2E_Berran?= =?utf-8?b?Z8Op?= , Eduardo Habkost , "Michael S. Tsirkin" , Laszlo Ersek , Markus Armbruster , qemu-arm@nongnu.org, Paolo Bonzini , Igor Mammedov , Richard Henderson Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" I previously added support for SMBIOS OEM strings tables but only allowed for data to be passed inline. Potential users indicated they wanted to pass some quite large data blobs which is inconvenient todo inline. Thus I'm adding support for passing the data from a file. In testing this I discovered the hard way that on x86 we're limited to using the SMBIOS 2.1 entry point currently. This has a maximum size of 0xffff, and if you exceed this all sorts of wierd behaviour happens. QEMU forces SMBIOS 2.1 on x86 because the default SeaBIOS firmware does not support SMBIOS 3.0. The EDK2 firmware supports SMBIOS 3.0 and QEMU defaults to this on the ARM virt machine type. This series adds support for checking the SMBIOS 2.1 limits to protect users from impossible to diagnose problems. There is also a fix needed to SeaBIOS which fails to check for integer overflow when it appends the type 0 table. https://mail.coreboot.org/hyperkitty/list/seabios@seabios.org/thread/3EMIOY= 6YS6MG5UQN3JJJS2A3DJZOVFR6/ IIUC, SMBIOS 3.0 should onlky be limited by what you can fit into RAM, but in testing, EDK2 appears to hang shortly after the SMBIOS 3.0 data size exceeds 128 KB. I've not spotted an obvious flaw in EDK2 or QEMU, nor do I attempt to enforce a limit in QEMU for SMBIOS 3.0. The 4th and 5th patches are what I used to test x86 machine types with EDK2 support for SMBIOS 3.0. I'm ambivalent on whether we really need them or not, but it does feel desirable to have parity of features between x86 and ARM when using SMBIOS with EDK2. Daniel P. Berrang=C3=A9 (5): hw/smbios: support loading OEM strings values from a file hw/smbios: report error if table size is too large qemu-options: document SMBIOS type 11 settings hw/smbios: use qapi for SMBIOS entry point type enum hw/i386: expose a "smbios_ep" PC machine property hw/arm/virt.c | 2 +- hw/i386/pc.c | 26 ++++++++++ hw/i386/pc_piix.c | 2 +- hw/i386/pc_q35.c | 2 +- hw/smbios/smbios.c | 93 +++++++++++++++++++++++++++++------- include/hw/firmware/smbios.h | 9 +--- include/hw/i386/pc.h | 3 ++ qapi/machine.json | 12 +++++ qemu-options.hx | 41 ++++++++++++++++ 9 files changed, 164 insertions(+), 26 deletions(-) --=20 2.26.2