From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.groups.io (mail02.groups.io [66.175.222.108]) by spool.mail.gandi.net (Postfix) with ESMTPS id 1B1E4AC1852 for ; Thu, 26 Oct 2023 13:35:45 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=EC1PzcU78wP8RvSY9XMAt9IvYjrdYInnk6KWFHZUojE=; c=relaxed/simple; d=groups.io; h=Date:From:To:CC:Subject:Message-ID:In-Reply-To:References:Organization:MIME-Version:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Transfer-Encoding; s=20140610; t=1698327344; v=1; b=ccy0SVa/ZGymV3aON8iZ47vkhQr8lYjAPu263R2VKsanonml0yUlcgADcqxlCOljKS+zN0pF rj0y6L2lpQuf5IQ1GNtIePiAgN1HZrWIDCS/+SNQVR8e5ruuj/A1RUJfCKHu/oLSW2B4tw/XEVE W49cwvBJeIlLVtlJ0Qm6g3bg= X-Received: by 127.0.0.2 with SMTP id UAp5YY7687511xQzDyaF3KSw; Thu, 26 Oct 2023 06:35:44 -0700 X-Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by mx.groups.io with SMTP id smtpd.web10.200352.1698327343552881009 for ; Thu, 26 Oct 2023 06:35:44 -0700 X-Received: from lhrpeml500005.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4SGRXq3C45z6JB2V; Thu, 26 Oct 2023 21:31:55 +0800 (CST) X-Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Thu, 26 Oct 2023 14:35:39 +0100 Date: Thu, 26 Oct 2023 14:35:38 +0100 From: "Jonathan Cameron via groups.io" To: Laszlo Ersek CC: , , , "Ni, Ray" , Sayanta Pattanayak Subject: Re: [edk2-devel] question about cxl device enumeration in pci bus driver Message-ID: <20231026143538.00005d15@Huawei.com> In-Reply-To: <5df5f698-7f1d-98f3-e6a2-7b1a4c978528@redhat.com> References: <74c5f6c4.3480.18b656cafb8.Coremail.yoshinoyatoko@163.com> <5df5f698-7f1d-98f3-e6a2-7b1a4c978528@redhat.com> Organization: Huawei Technologies Research and Development (UK) Ltd. MIME-Version: 1.0 X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml500001.china.huawei.com (7.191.163.213) To lhrpeml500005.china.huawei.com (7.191.163.240) X-CFilter-Loop: Reflected Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Reply-To: devel@edk2.groups.io,jonathan.cameron@huawei.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: mqfBSa2BPlHA3CYufXfbvpFAx7686176AA= Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b="ccy0SVa/"; dmarc=none; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io On Thu, 26 Oct 2023 11:49:28 +0200 "Laszlo Ersek" wrote: > On 10/26/23 10:33, Gerd Hoffmann wrote: > > On Thu, Oct 26, 2023 at 10:36:35AM +0800, Yoshinoya wrote: > > =20 > >> CXL Host Bridge / Root Port / Switch / Device enumeration / HDM Config= , maybe could be integrated into pci drivers stack. =20 > >=20 > > Point being? Can or should the firmware do anything useful with > > the CXL hardware? If so, what exactly and why? > >=20 > > Current state of affairs is that the PCI stack does the usual PCI > > initialization (enumerate, assign resources to PCI bars) and leaves > > everything else to the OS. =20 >=20 > (I don't know what "HDM Config" stands for.) >=20 > The only utility for driving CXL devices from the firmware could be, AFAI= CT: >=20 > - booting off of such a device (or at least "supporting OS boot" in some > manner) >=20 > - using such a device for UEFI console purposes There are different models for how to use CXL devices and what's possible d= epends on the version of CXL. CXL 1.1 wasn't great for standards defined discovery, so EDK2 platform logic basically has to do everything. The one mostly expected for early CXL servers, for backwards compatibility,= makes setting up the CXL memory decoders (Host managed Device Memory - HDM) in al= l the components in the path to memory + locking them down an EDK2 problem. They= are then presented in the memory map and in SRAT, HMAT etc the same as normal DDR me= mory. Idea being that an old OS will be fine with that and doesn't have to be CXL= aware at all. Note this also involves walking the CDAT tables via DOE mailboxes = in PCI config space to get the magic numbers needed to compute HMAT. The other model is to do very little in EDK2 and make entirely a problem fo= r the OS. The logic is necessary anyway if you want to support hotplug etc, so use it= for the cold plug paths 2. That's all we've currently supported on QEMU. There was a presentation at Linux Plumbers last year on some out of tree su= pport from ARM for doing the setup on a CXL 2.0 platform (I think) in EDK2=20 https://lpc.events/event/16/contributions/1254/ But I guess it never went upstream. https://github.com/SayantaP-arm/edk2-platforms/tree/cxl-type-3 +CC Sayanta Jonathan >=20 > Laszlo >=20 >=20 >=20 >=20 >=20 >=20 -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#110100): https://edk2.groups.io/g/devel/message/110100 Mute This Topic: https://groups.io/mt/102173204/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-