From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B3FEE23372C for ; Tue, 27 Jan 2026 09:59:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769507991; cv=none; b=F3Y2hVbYxk8zkMc9xXmGV3nSY2c4lhvWEYQdA8FgFtoWfY8Q4QCxWnXVawf4xeu5kwAp1tFDyweobScT3pEugTeavviICbFdwJkLsrmsN0qnQnMsWmrnIkb/ocyN2hl9yHCOqFGGcU8vuzq4CsBqxWs3HMJGgVuBu6q5+ZRNcFk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769507991; c=relaxed/simple; bh=dA6fSw5Uhi13cgD1IdyhHXNpYfWQc56DtVnXMGM5xSw=; h=From:To:Cc:Subject:Date:Message-ID:Content-Type:MIME-Version; b=oX0foSFI/lzVW1gbmQjkM8lZDVhXILvh1AZ5pnA/p7V9ls5bVnA0Kb39B7K89JvDhCdHd7R+B+ljImhz7I8Hvj8j8szBAVMfSg0QtAOKpVV3+gIAwmeeF7m6QVErDVrOFF5T/mnd+xFsUGAi5aM1VkDt4UvM+fNOuYNEQY41L9Q= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=asnw1/LA; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="asnw1/LA" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1769507988; 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=BPWHHfJh7xbgl/6C4Tu0Z1jBwCiMaLIsMJ2m2VM8bjM=; b=asnw1/LAgU7iqOHPnJrgypbyxfAPU6VSGe213DoJOWi0NJoS8AEnp60Mc1jKNmhiHwPFFZ nTBEq0JJcPvawLuxZcAw+S4suKYtxP608S9OM8X1p3MIk5aSmyyN9hy1xYXvsYZLl8m6/d mEmLtIWf3oVH+gJeC0e/BWRbGtRnQf4= Received: from mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-610-0HkW4zaOO6-JBfgv2QkmSw-1; Tue, 27 Jan 2026 04:59:45 -0500 X-MC-Unique: 0HkW4zaOO6-JBfgv2QkmSw-1 X-Mimecast-MFC-AGG-ID: 0HkW4zaOO6-JBfgv2QkmSw_1769507984 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id DC98B1800350; Tue, 27 Jan 2026 09:59:43 +0000 (UTC) Received: from osteffen-thinkpadx1carbongen12.rmtde.csb (unknown [10.44.34.174]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 04E9C19560B2; Tue, 27 Jan 2026 09:59:37 +0000 (UTC) From: Oliver Steffen To: qemu-devel@nongnu.org Cc: Ani Sinha , Eduardo Habkost , Stefano Garzarella , Igor Mammedov , Richard Henderson , Gerd Hoffmann , Paolo Bonzini , Luigi Leonardi , Joerg Roedel , "Michael S. Tsirkin" , Marcelo Tosatti , Marcel Apfelbaum , Zhao Liu , kvm@vger.kernel.org, Oliver Steffen Subject: [PATCH v5 0/6] igvm: Supply MADT via IGVM parameter Date: Tue, 27 Jan 2026 10:59:30 +0100 Message-ID: <20260127095936.1072464-1-osteffen@redhat.com> Content-Type: text/plain; charset="utf-8" Precedence: bulk X-Mailing-List: kvm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 When launching using an IGVM file, supply a copy of the MADT (part of the ACPI tables) via an IGVM parameter (IGVM_VHY_MADT) to the guest, in addition to the regular fw_cfg mechanism. The IGVM parameter can be consumed by Coconut SVSM [1], instead of relying on the fw_cfg interface, which has caused problems before due to unexpected access [2,3]. Using IGVM parameters is the default way for Coconut SVSM; switching over would allow removing specialized code paths for QEMU in Coconut. Coconut SVSM needs to know the SMP configuration, but does not look at any other ACPI data, nor does it interact with the PCI bus settings. Since the MADT is static and not linked with other ACPI tables, it can be supplied stand-alone like this. Generating the MADT twice (IGVM processing and ACPI table building) seems acceptable, since there is no infrastructure to obtain the MADT out of the ACPI table memory area during IGVM processing. In any case OVMF, which runs after SVSM has already been initialized, will continue reading all ACPI tables via fw_cfg and provide fixed up ACPI data to the OS as before. This series makes ACPI table building more generic by making the BIOS linker optional. This allows the MADT to be generated outside of the ACPI build context. A new function (acpi_build_madt_standalone()) is added for that. With that, the IGVM MADT parameter field can be filled with the MADT data during processing of the IGVM file. [1] https://github.com/coconut-svsm/svsm/pull/858 [2] https://gitlab.com/qemu-project/qemu/-/issues/2882 [3] https://github.com/coconut-svsm/svsm/issues/646 v5: - Make qigvm_find_parameter_entry() more generic and use everywhere possible; It now takes the index as input, instead of the full parameter struct - Consistently use early returns when looking up parameter entries - Emit a warning message if no parameter area can be found for a given index v4: - Add ACPI table checksum calculation without BIOS linker, used for the standalone MADT. - Don't pass ConfidentialGuestState into the IGVM backend anymore. Not needed, since we already have the full MachineState there now. - Move the NULL check patch out into a new series (to be posted). - Address remaining cleanup comments. v3: - Pass the machine state into IGVM file processing context instead of MADT data - Generate MADT from inside the IGVM backend - Refactor: Extract common code for finding IGVM parameter from IGVM parameter handlers - Add NULL pointer check for igvm_get_buffer() v2: - Provide more context in the message of the main commit - Document the madt parameter of IgvmCfgClass::process() - Document why no MADT data is provided the process call in sev.c Based-on: <20251118122133.1695767-1-kraxel@redhat.com> Signed-off-by: Oliver Steffen Oliver Steffen (6): hw/acpi: Make BIOS linker optional hw/acpi: Add standalone function to build MADT igvm: Add common function for finding parameter entries igvm: Refactor qigvm_parameter_insert igvm: Pass machine state to IGVM file processing igvm: Fill MADT IGVM parameter field backends/igvm-cfg.c | 2 +- backends/igvm.c | 255 +++++++++++++++++++++++--------------- hw/acpi/aml-build.c | 29 ++++- hw/i386/acpi-build.c | 9 ++ hw/i386/acpi-build.h | 2 + include/system/igvm-cfg.h | 3 +- include/system/igvm.h | 5 +- target/i386/sev.c | 3 +- 8 files changed, 197 insertions(+), 111 deletions(-) -- 2.52.0