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.web10.942.1630650490121218520 for ; Thu, 02 Sep 2021 23:28:10 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=eaH76ANc; 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=1630650489; 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=9I4ew5ccXwOfGCLsJ+s41WIIh+usp62Te3tyPHQ6X5Y=; b=eaH76ANcdgqx4YHg4lYepcWVdrBnT9r4e5URsGwCXj99P6zIuxpnNTFAT5eh9SodAopOLD VhWl7nXAeuDCVcM3+0Zt5xNiuJ1sLDnWnjwbiP39sNdI+24+O8mo6KfYzKQfgMYS41LIZI jFsmJvwq07N6OhkHFebjLr09xWeGKJw= 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-400-qW9eIZ5tMH-zbrvwtf0GmQ-1; Fri, 03 Sep 2021 02:28:06 -0400 X-MC-Unique: qW9eIZ5tMH-zbrvwtf0GmQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AD5A8107ACCA; Fri, 3 Sep 2021 06:28:04 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.91]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4F7AF69FC2; Fri, 3 Sep 2021 06:28:04 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id ABF0F18000A3; Fri, 3 Sep 2021 08:28:02 +0200 (CEST) Date: Fri, 3 Sep 2021 08:28:02 +0200 From: "Gerd Hoffmann" To: Brijesh Singh Cc: devel@edk2.groups.io, James Bottomley , Min Xu , Jiewen Yao , Tom Lendacky , Jordan Justen , Ard Biesheuvel , Erdem Aktas , Michael Roth Subject: Re: [PATCH v6 02/29] OvmfPkg: reserve CPUID page for SEV-SNP Message-ID: <20210903062802.v6pctzlaidockzm6@sirius.home.kraxel.org> References: <20210901161646.24763-1-brijesh.singh@amd.com> <20210901161646.24763-3-brijesh.singh@amd.com> <20210902080448.jjigp62hsfo4o2h6@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 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 Hi, > >> Is this snp-specific? Or could this also be used without snp? > > This is SNP specific format and cannot be used without SNP. > > I should clarify the statement, the format itself does not contain > anything  SNP specific. However, the CPUID page format is documented in > the SNP specific spec. Who populates the page? qemu? sev-snp firmware? > Are you thinking about using it for non SEV guest > to avoid the VM exit ? If so, it should be very much possible. Yes, that is the background. Avoiding vmexits would be one advantage. Being able to test the code without SNP-capable hardware (for example in CI) would be another one. > For that > we should define the format outside of SNP specific spec and make it a > generic so that guest and HV's can implement it consume it in the > non-SNP guest.  I think that would be useful. take care, Gerd