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.129.124]) by mx.groups.io with SMTP id smtpd.web09.33804.1649072316638743347 for ; Mon, 04 Apr 2022 04:38:37 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=UOcEqCh4; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1649072315; 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: in-reply-to:in-reply-to:references:references; bh=9Rvx1G7dgnD6tSZXefFuDYqijrvaTv74w5p+Pqdp7G4=; b=UOcEqCh4dZfokSsPMIzd2azE8YS0Fya1mzRaWpd+gmyDSOX6LgC/frppn24p4ChBDrZd59 ZSOPq0t4oW8v6YXJHvyTuodVaoB08QnlSgTCVuy3UPCp7qbDSXJOONznyGG/xhK8b+wYmq P+/1ky/hm2Eho3dvk9cB37qIIE2yiTo= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-139-AKOmKWnYPo-yPV9gXE-5ag-1; Mon, 04 Apr 2022 07:38:32 -0400 X-MC-Unique: AKOmKWnYPo-yPV9gXE-5ag-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 069D8811E7A; Mon, 4 Apr 2022 11:38:32 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.194.10]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B2AEFC44CF9; Mon, 4 Apr 2022 11:38:31 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 3D505180060A; Mon, 4 Apr 2022 13:38:30 +0200 (CEST) Date: Mon, 4 Apr 2022 13:38:30 +0200 From: "Gerd Hoffmann" To: Corvin =?utf-8?B?S8O2aG5l?= Cc: virtualization@freebsd.org, Corvin =?utf-8?B?S8O2aG5l?= , Ard Biesheuvel , Jiewen Yao , Jordan Justen , Rebecca Cran , Peter Grehan , devel@edk2.groups.io Subject: Re: [PATCH] OvmfPkg: reserve igd memory by E820 Message-ID: <20220404113830.6novz55zpid3l6fl@sirius.home.kraxel.org> References: <20220404063448.280-1-c.koehne@beckhoff.com> MIME-Version: 1.0 In-Reply-To: <20220404063448.280-1-c.koehne@beckhoff.com> X-Scanned-By: MIMEDefang 2.85 on 10.11.54.8 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kraxel@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit On Mon, Apr 04, 2022 at 08:34:48AM +0200, Corvin Köhne wrote: > Hi all, > > I'd like to discuss the following patch. At the moment, it's bhyve > specific but I'd like to merge it into stock OVMF too. I'm working > on GPU passthrough support for Intels integrated graphics devices > (Intel calls it GVT-d). In order to get GVT-d working properly, > the guest bios should allocate two memory areas (Graphics Stolen > Memory and OpRegion). I'm trying to create a platform independent > patch which allows to allocate those regions. Oh no. Not that discussion again. First, there is no need to communicate memory regions from the hypervisor to the guest. The IGD hardware has registers pointing to the opregion and to stolen memory, so the guest can simply allocate and initialize memory, then program the registers accordingly. Same procedure you have when initializing IGD on physical hardware. Second, that doesn't belong into OVMF. Drivers for virtual/emulated hardware are fine, but we certainly don't want enter the business of maintaining drivers for physical hardware in OVMF. An EFI driver in the igd option rom should be able to handle all of the above just fine, and for Intel it should also be easy to cover differences in hardware generations in the driver. Bonus points for also setting up a GOP for the IGD ;) Unfortunately Intel didn't manage it yet to provide an igd option rom for virtual machines (or fix their regular driver to also work in virtual machines) even though this discussion is ongoing on and off for years meanwhile :( BTW: Do you talk about GVT-d (== build virtual IGD devices with some resources of the physical device, roughly comparable to SR-IOV but with the igd kernel driver instead of the hardware handling this)? Or do you want pci-assign the complete igd device? > At the moment, I'm using an E820 table that bhyve provides to the > guest. Another approach would be to use the QemuLoader which is > used for loader Qemu's ACPI tables. While this has the advantage > that the guest bios allocates the memory by it's own, the > hypervisor has less control over the address. E.g. the ACRN > hypervisor uses an indentical mapping for the Graphics Stolen > Memory on Tiger Lake platforms and above (see > https://github.com/projectacrn/acrn-hypervisor/blob/master/devicemodel/hw/pci/passthrough.c#L519-L523). Lovely. Intel should fix their broken windows drivers ... The etc/e820 fw_cfg file can have both 'ram' and 'reserved' entries. And, yes, adding a 'reserved' entry there for the region which requires an identity mapping (to workaround the driver bug) is fine and should make sure the region is not used for something else. Everything else should be handled by the igd efi driver / optionrom. Also: As far I know the stolen memory is only needed at boot, for the EFI GOP. Once the guest OS loaded the native drivers for the IGD the stolen memory is not needed / not used any more, and in theory the drivers should cope with a stolen memory region not being present just fine. For the opregion: qemu has, for historical reasons, an (optional and disabled by default) etc/igd-opregion fw_cfg file. It was a quick hack which ended up staying. When a option rom is needed anyway the content of the opregion can simply be passed to the guest as part of the option rom image. But if you prefer to use fw_cfg instead you should at least use the same hack instead of inventing a new one ... See also: https://gitlab.com/qemu-project/qemu/-/blob/master/docs/igd-assign.txt Seabios uses etc/igd-opregion, guest code is here: https://gitlab.com/qemu-project/seabios/-/blob/master/src/fw/pciinit.c#L291 Ideally we'd move that to a proper vgabios too ... take care, Gerd