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 BD534D8027A for ; Thu, 22 Feb 2024 11:24:25 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=31+gd5al61uhm+xOZK1qLBgHeP8TF5942t5brm1tvIc=; c=relaxed/simple; d=groups.io; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:In-Reply-To:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Disposition:Content-Transfer-Encoding; s=20140610; t=1708601064; v=1; b=MH63eZn1oEQgfa9r9AfNg/rQzVQ9ZKpUIPHPICdUtPsHQQ3RShr0eV/JQmXXBhNNpsps4uDn yraLfkztvY26RBxeurfGpZeaTE3iuUZEN1G108EddXiViePw8vEAGxWnF08VBx9rwYWM5c3XNs7 egt6OCv6RLQ3AkgIxWsTRUa4= X-Received: by 127.0.0.2 with SMTP id azcDYY7687511xJEzoMQa5Hd; Thu, 22 Feb 2024 03:24:24 -0800 X-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.web11.10639.1708601063764580090 for ; Thu, 22 Feb 2024 03:24:23 -0800 X-Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-554-vRO4peJPO0Kn4x2WugiH3g-1; Thu, 22 Feb 2024 06:24:19 -0500 X-MC-Unique: vRO4peJPO0Kn4x2WugiH3g-1 X-Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 33A5584A293; Thu, 22 Feb 2024 11:24:19 +0000 (UTC) X-Received: from sirius.home.kraxel.org (unknown [10.39.192.237]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AC40B8BCC; Thu, 22 Feb 2024 11:24:18 +0000 (UTC) X-Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 7A33518007A1; Thu, 22 Feb 2024 12:24:17 +0100 (CET) Date: Thu, 22 Feb 2024 12:24:17 +0100 From: "Gerd Hoffmann" To: devel@edk2.groups.io Cc: Michael Roth , Jiewen Yao , Liming Gao , Laszlo Ersek , Tom Lendacky , Paolo Bonzini , Ard Biesheuvel , Min Xu , Erdem Aktas , Oliver Steffen , Ard Biesheuvel Subject: [edk2-devel] GuestPhysAddrSize questions (was: Re: [PATCH v4 3/3] OvmfPkg/PlatformInitLib: add 5-level paging) support Message-ID: <32oty4asp3xrecjruatwm77fbevcaizswovjc5jqct5bdofwiq@sgff2gzgau7o> References: <20240222105407.75735-1-kraxel@redhat.com> <20240222105407.75735-4-kraxel@redhat.com> MIME-Version: 1.0 In-Reply-To: <20240222105407.75735-4-kraxel@redhat.com> X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com 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,kraxel@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: X-Gm-Message-State: JOLGUaeIr0tGudzOcZ68vDkvx7686176AA= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20140610 header.b=MH63eZn1; spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 66.175.222.108 as permitted sender) smtp.mailfrom=bounce@groups.io; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none) Hi, > + if (Cr4.Bits.LA57) { > + if (PhysBits > 48) { > + /* > + * Some Intel CPUs support 5-level paging, have more than 48 > + * phys-bits but support only 4-level EPT, which effectively > + * limits guest phys-bits to 48. > + * > + * AMD Processors have a different but somewhat related > + * problem: They can handle guest phys-bits larger than 48 > + * only in case the host runs in 5-level paging mode. > + * > + * Until we have some way to communicate that kind of > + * limitations from hypervisor to guest, limit phys-bits > + * to 48 unconditionally. > + */ So I'm looking for some communication path. One option would be to use some bits in the KVM cpuid leaves. Another possible candidate is cpuid leaf 0x80000008. >From the AMD APM (revision 3.35): CPUID Fn8000_0008_EAX Long Mode Size Identifiers ------------------------------------------------ The value returned in EAX provides information about the maximum host and guest physical and linear address width (in bits) supported by the processor. Bits FieldName Description 31:24 — Reserved 23:16 GuestPhysAddrSize Maximum guest physical address size in bits. This number applies only to guests using nested paging. When this field is zero, refer to the PhysAddrSize field for the maximum guest physical address size. See “Secure Virtual Machine” in APM Volume 2. 15:8 LinAddrSize Maximum linear address size in bits. 7:0 PhysAddrSize Maximum physical address size in bits. When GuestPhysAddrSize is zero, this field also indicates the maximum guest physical address size. The description of the GuestPhysAddrSize is somewhat vague. Is this a value the hypervisor should use to figure how much address space it can give to guests? Or is this a value the hypervisor can set to inform the guest about the available address space (which would be a solution to the problem outlined in the comment above)? Or both? In case GuestPhysAddrSize should not be used this way: Is it possible allocate the currently reserved bits 31:24 for that purpose? Tom? Michael? thanks & take care, Gerd -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#115801): https://edk2.groups.io/g/devel/message/115801 Mute This Topic: https://groups.io/mt/104506481/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=-=-=-=-=-=-=-=-=-=-=-