From mboxrd@z Thu Jan  1 00:00:00 1970
Authentication-Results: mx.groups.io;
 dkim=missing; spf=pass (domain: redhat.com, ip: 209.132.183.28, mailfrom: imammedo@redhat.com)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28])
 by groups.io with SMTP; Fri, 20 Sep 2019 01:29:04 -0700
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mx1.redhat.com (Postfix) with ESMTPS id 948FD18CB91B;
	Fri, 20 Sep 2019 08:29:03 +0000 (UTC)
Received: from localhost (unknown [10.43.2.182])
	by smtp.corp.redhat.com (Postfix) with ESMTP id 8A47260BF1;
	Fri, 20 Sep 2019 08:28:56 +0000 (UTC)
Date: Fri, 20 Sep 2019 10:28:55 +0200
From: "Igor Mammedov" <imammedo@redhat.com>
To: "Laszlo Ersek" <lersek@redhat.com>
Cc: devel@edk2.groups.io, qemu-devel@nongnu.org, yingwen.chen@intel.com,
 phillip.goerl@oracle.com, alex.williamson@redhat.com, jiewen.yao@intel.com,
 jun.nakajima@intel.com, michael.d.kinney@intel.com, pbonzini@redhat.com,
 boris.ostrovsky@oracle.com, rfc@edk2.groups.io, joao.m.martins@oracle.com,
 Brijesh Singh <brijesh.singh@amd.com>
Subject: Re: [edk2-devel] [Qemu-devel] [PATCH 1/2] q35: implement 128K SMRAM at default SMBASE address
Message-ID: <20190920102855.3fe2b689@redhat.com>
In-Reply-To: <561f4440-7c06-10d7-80ce-bbfa810fec59@redhat.com>
References: <20190917130708.10281-1-imammedo@redhat.com>
	<20190917130708.10281-2-imammedo@redhat.com>
	<561f4440-7c06-10d7-80ce-bbfa810fec59@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.63]); Fri, 20 Sep 2019 08:29:03 +0000 (UTC)
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Thu, 19 Sep 2019 19:02:07 +0200
"Laszlo Ersek" <lersek@redhat.com> wrote:

> Hi Igor,
> 
> (+Brijesh)
> 
> long-ish pondering ahead, with a question at the end.
[...]

> Finally: can you please remind me why we lock down 128KB (32 pages) at
> 0x3_0000, and not just half of that? What do we need the range at
> [0x4_0000..0x4_FFFF] for?


If I recall correctly, CPU consumes 64K of save/restore area.
The rest 64K are temporary RAM for using in SMI relocation handler,
if it's possible to get away without it then we can drop it and
lock only 64K required for CPU state. It won't help with SEV
conflict though as it's in the first 64K.

On QEMU side,  we can drop black-hole approach and allocate
dedicated SMRAM region, which explicitly gets mapped into
RAM address space and after SMI hanlder initialization, gets
unmapped (locked). So that SMRAM would be accessible only
from SMM context. That way RAM at 0x30000 could be used as
normal when SMRAM is unmapped.