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]) by mx.groups.io with SMTP id smtpd.web08.3741.1616144812374636565 for ; Fri, 19 Mar 2021 02:06:52 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Z5jMUSvs; spf=pass (domain: redhat.com, ip: 170.10.133.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1616144811; 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: in-reply-to:in-reply-to:references:references; bh=g/8G2Raggy/Ye69dpVDf8aCEGU6c8A/k1nn3owyC4P4=; b=Z5jMUSvsOIv8xJqHicvE8sKOxq0OJRZscba/sesSn1drDuA89xEyn3KN+xdUsd55xjcoFc 5+5re3hDd44hU48PzYKT3+oP24B8DH3o9Ylrac7xAjNiwmXW1zUFNNpWXpCpngRl1wEak2 TMmUW9pvXQMrWGpbDBZHp9FUFD505C0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-206-fUCFNFTuM-OntDCx_Jxj-g-1; Fri, 19 Mar 2021 05:06:47 -0400 X-MC-Unique: fUCFNFTuM-OntDCx_Jxj-g-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 58E308143FE; Fri, 19 Mar 2021 09:06:46 +0000 (UTC) Received: from sirius.home.kraxel.org (ovpn-112-41.ams2.redhat.com [10.36.112.41]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C92B16F98A; Fri, 19 Mar 2021 09:06:42 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 30B9D18000B3; Fri, 19 Mar 2021 10:06:41 +0100 (CET) Date: Fri, 19 Mar 2021 10:06:41 +0100 From: kraxel@redhat.com To: Colin Xu Cc: zhenyuw@linux.intel.com, devel@edk2.groups.io, lersek@redhat.com, alex.williamson@redhat.com, rebecca@bsdio.com Subject: Re: [edk2-devel] [PATCH v2 1/2] OvmfPkg/IntelGvtGopDxe: Intel GVT-g GOP Implementation. Message-ID: <20210319090641.zx7ly4ev7ileticc@sirius.home.kraxel.org> References: <714af4f188644d03cbb93eb7621c34a6386dff32.1614924813.git.colin.xu@intel.com> <60a24d26-e332-c907-61fe-648957708793@redhat.com> <20210312123544.uarnizkane27phcl@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 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=us-ascii Content-Disposition: inline Hi, > operations but handle the common logic. In this opregion case, QEMU and > seabios only copies the raw data, but the contents are left to gvt to fill > so that gvt could fill different data in different cases. Yes, gvt could do that. The big question is: does that actually happen? When looking at drivers/gpu/drm/i915/gvt/opregion.c it seems the opregion is pretty static. Are there plausible reasons for that capability being needed in the future? > Otherwise any change requires SEABIOS update, instead of dyncamilly > filled by gvt. That clearly isn't an option. > One benefit OVMF overcomes SEABIOS is that IntelGvtGopDxe can be loaded > as a standalone driver. Well, seabios allows standalone drivers too. It's called vgabios ;) > So it maybe possible that in OVMF case, both gvt and > IntelGvtGopDxe can act part of Intel vGPU virtualization component. However > the behavior of gvt+seabios and gvt+ovmf will be inconsistent. Well, in case the opregion is not static there is still the option to use the pci rom bar instead of fw_cfg to deliver the opregion content to the guest. > May need > update gvt logic so that if IntelGvtGopDxe generate opregion, gvt can still > update it before any opregion consumer using it. Hmm. Can gvt trap pci config space writes? IIRC pci config space is simply yet another vfio region, so that should be possible. gvt could update the opregion then when the firmware updates the opregion address. If that actually works there is little reason for IntelGvtGopDxe (and seabios) to fill the opregion in the first place though. We could change the opregion initialization protocol to something like this: (1) firmware allocates memory for the opregion (2) firmware fills signature and size (3) firmware writes opregion address to pci config space (4) gvt goes fill opregion at the given address in guest memory. Maybe it would be better to reserve a paravirtual mmio register for that purpose to make the whole thing a bit more robust. > Then, loading fw_cfg can be > dropped without preventing guest OS driver find it. I guess we have to keep that for a while for backward compatibility reasons. take care, Gerd