From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org 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 smtp.lore.kernel.org (Postfix) with ESMTPS id ED84AC61DA4 for ; Mon, 13 Mar 2023 21:59:47 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pbqC7-0007IJ-Q1; Mon, 13 Mar 2023 17:59:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pbqC6-0007I6-8M for qemu-devel@nongnu.org; Mon, 13 Mar 2023 17:59:02 -0400 Received: from mga06b.intel.com ([134.134.136.31] helo=mga06.intel.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pbqC4-0005jU-5c for qemu-devel@nongnu.org; Mon, 13 Mar 2023 17:59:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1678744740; x=1710280740; h=message-id:date:mime-version:from:subject:to:cc: content-transfer-encoding; bh=bi3vB1Afvu+51J4YDYc5L/oLWYB9ZiZboTTv4WXhCbs=; b=fsVZPtAzZiDi+OPJvlq9FmZXu/XzRbx9Gqx+mKuYpUm8U8DynDQpcf80 PTb9LXC6eRQgutisejFwwz6YDeywYGlxxpKIdmMMCYyUh4lB3hXbQiNJA rYkpUwiyMSa6x44mTpz5o5dRtVZU01linv0vHKyMpBe34WQ4B5T88Wr+o MtyjQQZpBI80kLx5mb9+QGCzF++il6FVGiPhbcqTGSJd1pCas98nZQEo8 n2LSgu+04sjxxmxYy2qA/YqxbhVqjGEMSlVsyNJrmTpMMg5hUTFG7yVbf LKSk3J5BemcA/Hd7I2NjWbJtoUqeO3bx6pXZ5sUgD4N58xlG8vCkIEZhN A==; X-IronPort-AV: E=McAfee;i="6500,9779,10648"; a="399860148" X-IronPort-AV: E=Sophos;i="5.98,258,1673942400"; d="scan'208";a="399860148" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Mar 2023 14:58:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10648"; a="743052742" X-IronPort-AV: E=Sophos;i="5.98,258,1673942400"; d="scan'208";a="743052742" Received: from djiang5-mobl3.amr.corp.intel.com (HELO [10.212.10.158]) ([10.212.10.158]) by fmsmga008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Mar 2023 14:58:42 -0700 Message-ID: Date: Mon, 13 Mar 2023 14:58:42 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.6.0 Content-Language: en-US From: Dave Jiang Subject: need help with ACPI generic port implementation for QEMU To: qemu-devel@nongnu.org Cc: Jonathan Cameron , Ira Weiny , Michael Tsirkin , Ben Widawsky Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=134.134.136.31; envelope-from=dave.jiang@intel.com; helo=mga06.intel.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 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_MED=-2.3, 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.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org I'm attempting to implement the support of ACPI "generic port" detailed in the ACPI r6.5 spec in QEMU. The spec section 5.2.16.7 details the Generi Port Affinity Structure where it ties a Device Handle to a Proximity Domain. And with section 6.2.28.4 for the HMAT table, the latency and bandwidth information are provided by the System Locality Latency and Bandwidth Information Structure (SLLBIS) sub-table. In the CXL world, a hotplugged type-3 device would not have the approriate end to end latency and bandwidth data provided by the HMAT. The QoS data needs to be computed from the CXL host bridge (HB) and the endpoint device. Some parts of the data are supplemented by the CDAT from the endpoint device and the CXL switch(es) if they exist in the path. The component missing is the path between the CPU and the CXL HB (generic port). The data provided by HMAT for generic port will fill that gap. In QEMU, the SRAT is generated by code and the table entry addition is a somewhat straight forward implementation. The HMAT information is fed through user parameter inputs and will require a new object to allow the representation of generic port. The intention is to be able to do something like: "-object genport,id=genport0" "-numa node,genport=genport0,nodeid=5,initiator=0" "-numa dist,src=0,dst=5,val=$dist" "-numa hmat-lb,initiator=0,target=5,hierachy=memory,data-type=access-latency,latency=$lat" "-numa hmat-lb,initiator=0,target=5,hierarchy=memory,data-type=access-bandwidth,bandwidth=$bw" I put together a skeletal generic port device that seems to pass the numa parsing code parts. However I'm hitting an error after that that I can't figure out how to deal with: qemu-system-x86_64: ../hw/core/qdev.c:316: qdev_assert_realized_properly_cb: Assertion `dev->realized' failed. At what point is qdev_realize() being called for a device object? It seems that this never happens for this generic port device. What am I missing in terms of initialization or setup? Any assistance is appreciated. Thanks in advance. Here's my latest code that I'm playing with as reference: https://github.com/davejiang/qemu/tree/genport