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: pbonzini@redhat.com) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by groups.io with SMTP; Tue, 24 Sep 2019 04:47:57 -0700 Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3A8FB85362 for ; Tue, 24 Sep 2019 11:47:57 +0000 (UTC) Received: by mail-wm1-f70.google.com with SMTP id r21so704912wme.5 for ; Tue, 24 Sep 2019 04:47:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZmUP3dVjUP6Ph1ks37nxU36pehuOEitrpcwdPaj7Rqk=; b=m/yGr8P4OBMYy+3H8orIqlr/UCZJlvql0BrKrxPgf032SldI6pA6EoJpCl1TSOa6h6 m2VtWj6PcmoOf72uI1Rhdfp6oMTusbHe6q4zp2yv/QmRgI19KoNbH2Ih/xYRcP6AM4uG tbVvXQVgac2D1wPqr7OLvS8dwyOsW07NQ/ac5DEZgOty6a5aiw/b0m/dN7Git/Ru9Eiw sMcZ7aRd69an9vWDQaWZny54uSOnUwZ0qV0Yyw4sePdHxhfYcdA0YX6zYSHapZQ1iIpn p2swPgcEeMZmjbWAWwhe+tKy4dybZseuC3/7GvDk+g6uNawjAxglDeyeTTAufGuMARNH 04FQ== X-Gm-Message-State: APjAAAW3Jfh4mcF1uyAedusx7eKlL04+lbuf+ji++pbXLCbSLLWmWFtp xSd/W4h4rgD0Asixkpjn5FM4AyGWqaUAr+gb/h8LsrL/MyP4nbHSWffFw4aAFhfj6RhYrfbFGfi tDcDREs5wOb3u9w== X-Received: by 2002:adf:e48f:: with SMTP id i15mr221726wrm.26.1569325675881; Tue, 24 Sep 2019 04:47:55 -0700 (PDT) X-Google-Smtp-Source: APXvYqwYN5lvbTvdGpga0JogVxl1P6Rka6ib4+wnTWx99krQzs82kmUGoXEcVhEeux3fSgMEAVgYvw== X-Received: by 2002:adf:e48f:: with SMTP id i15mr221708wrm.26.1569325675548; Tue, 24 Sep 2019 04:47:55 -0700 (PDT) Received: from ?IPv6:2001:b07:6468:f312:9520:22e6:6416:5c36? ([2001:b07:6468:f312:9520:22e6:6416:5c36]) by smtp.gmail.com with ESMTPSA id b144sm1252690wmb.3.2019.09.24.04.47.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 24 Sep 2019 04:47:55 -0700 (PDT) Subject: Re: [edk2-devel] [Qemu-devel] [PATCH 1/2] q35: implement 128K SMRAM at default SMBASE address To: Laszlo Ersek , Igor Mammedov 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, boris.ostrovsky@oracle.com, rfc@edk2.groups.io, joao.m.martins@oracle.com, Brijesh Singh References: <20190917130708.10281-1-imammedo@redhat.com> <20190917130708.10281-2-imammedo@redhat.com> <561f4440-7c06-10d7-80ce-bbfa810fec59@redhat.com> <20190920102855.3fe2b689@redhat.com> From: "Paolo Bonzini" Openpgp: preference=signencrypt Message-ID: <6799e19d-1aa8-ee09-9ef4-2533a7241360@redhat.com> Date: Tue, 24 Sep 2019 13:47:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 20/09/19 11:28, Laszlo Ersek wrote: >> 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. > > I prefer the black-hole approach, introduced in your current patch > series, if it can work. Way less opportunity for confusion. Another possibility would be to alias the 0xA0000..0xBFFFF SMRAM to 0x30000..0x4FFFF (only when in SMM). I'm not super enthusiastic about adding this kind of QEMU-only feature. The alternative would be to implement VT-d range locking through the intel-iommu device's PCI configuration space (which includes _adding_ the configuration space, i.e. making the IOMMU a PCI device in the first place, and the support to the firmware for configuring the VT-d BAR at 0xfed90000). This would be the right way to do it, but it would entail a lot of work throughout the stack. :( So I guess some variant of this would be okay, as long as it's peppered with "this is not how real hardware does it" comments in both QEMU and EDK2. Thanks, Paolo > I've started work on the counterpart OVMF patches; I'll report back.