From nobody Tue Apr 05 07:47:38 2022 X-Original-To: virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6DFF41A99E0A for ; Tue, 5 Apr 2022 07:47:44 +0000 (UTC) (envelope-from C.Koehne@beckhoff.com) Received: from netsrv01.beckhoff.com (netsrv01.beckhoff.com [62.159.14.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.beckhoff.com", Issuer "Thawte TLS RSA CA G1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4KXfrG5J6xz4XYh; Tue, 5 Apr 2022 07:47:42 +0000 (UTC) (envelope-from C.Koehne@beckhoff.com) Received: from 172.17.5.171 by netsrv01.beckhoff.com (Tls12, Aes256, Sha384, DiffieHellmanEllipticKey256); Tue, 05 Apr 2022 07:47:42 GMT Received: from ex04.beckhoff.com (172.17.5.170) by ex06.beckhoff.com (172.17.5.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.24; Tue, 5 Apr 2022 09:47:39 +0200 Received: from ex04.beckhoff.com ([fe80::c545:54e6:8481:2958]) by ex04.beckhoff.com ([fe80::c545:54e6:8481:2958%6]) with mapi id 15.01.2375.024; Tue, 5 Apr 2022 09:47:39 +0200 From: =?iso-8859-1?Q?Corvin_K=F6hne?= To: Gerd Hoffmann CC: "virtualization@freebsd.org" , Ard Biesheuvel , Jiewen Yao , Jordan Justen , Rebecca Cran , Peter Grehan , "devel@edk2.groups.io" Subject: RE: [PATCH] OvmfPkg: reserve igd memory by E820 Thread-Topic: [PATCH] OvmfPkg: reserve igd memory by E820 Thread-Index: AQHYR+4gR0J1mf/cg0yeubefYjkNkKzff6AAgAAoPdCAAR4jgIAAJajQ Date: Tue, 5 Apr 2022 07:47:38 +0000 Message-ID: <7de01ae500554923941dc5ff9e537637@beckhoff.com> References: <20220404063448.280-1-c.koehne@beckhoff.com> <20220404113830.6novz55zpid3l6fl@sirius.home.kraxel.org> <20220405070639.uq5uiydxhirwu4gb@sirius.home.kraxel.org> In-Reply-To: <20220405070639.uq5uiydxhirwu4gb@sirius.home.kraxel.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.204.203] x-olx-disclaimer: EX06.BECKHOFF.COM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org MIME-Version: 1.0 X-Rspamd-Queue-Id: 4KXfrG5J6xz4XYh X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of C.Koehne@beckhoff.com designates 62.159.14.10 as permitted sender) smtp.mailfrom=C.Koehne@beckhoff.com X-Spamd-Result: default: False [-1.79 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_RCPT(0.00)[tianocore]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[beckhoff.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_SEVEN(0.00)[8]; NEURAL_HAM_MEDIUM(-0.99)[-0.992]; MLMMJ_DEST(0.00)[virtualization]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3320, ipnet:62.156.0.0/14, country:DE]; RCVD_TLS_LAST(0.00)[]; SUSPICIOUS_RECIPS(1.50)[] X-ThisMailContainsUnwantedMimeParts: N Hi, > Where does the intel gop driver come from? Extracted from host > firmware? https://projectacrn.github.io/latest/tutorials/gpu-passthru.html#enable-the= -gvt-d-gop-driver I don't know if it's possible to extract it from host firmware within OS context easily. According to Intel you should ask your board manufacturer. We're producing our own motherboards with an own BIOS. So, I'm reusing the Intel GOP driver from our host BIOS. > Ah, ok, didn't notice the subtile differences with the small letter at > the end. GVT-d + GVT-g is clear then. What is GVT-s ? https://01.org/sites/default/files/downloads/igvt-g/gvtflyer.pdf I'm not familiar with GVT-s. I just know that it exists. > Ideally the guest would allocate and initialize this all itself. > That is hard for the GSM though when it requires an identity > mapping. > > Having the guest check whenever the GSM register points to reserved > memory and if so use it instead of allocating memory should work I > think. To allocate GSM, the guest has to detect the size of GSM. Detecting the size is platform dependent. Writing a small EFI driver to detect the GSM size and to allocate a proper memory region should be easy. https://github.com/torvalds/linux/blob/master/arch/x86/kernel/early-quirks.= c#L353-L460 > Once we have the code for vgabios and PlatformGopPolicy we can roll them > with the intelgop driver into a rom image with EfiRom. Ideally also add > opregion content to the rom somehow. Sounds good. Does these EFI drivers have to be maintained outside of EDKII? Best regards Corvin Beckhoff Automation GmbH & Co. KG | Managing Director: Dipl. Phys. Hans Bec= khoff Registered office: Verl, Germany | Register court: Guetersloh HRA 7075