From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E452B21C93EC7 for ; Thu, 1 Jun 2017 06:47:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1496324909; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZRD77aCJnEaXGvCsb8rVYhr7VRzUnD5TanL2nOftGdI=; b=d8zQh0DWBsaCkBH9WfWNMECbs8Jwi3fFBxsgrjIW7fn0WNpGg+ZjRy/WC9ZXEF3X WNFJ396gVbqex6TA8gNueWQQTSKwY7XyWQJ73298PyY7K3x1ylNA4O0DP0pAIXWp sd3sOKAsAP8idQlE3WUokZ//QQeOUy921jsavEQh2/IPzF2/7i5tF/vNuMgGy4Lx E4t3ODQk2noZSNJUlGHTGpbhr4yd84cJ6jmnWLsvkAgFwyGKTFkZK5gOA8XYDeAj lWIC+C5OBe/eK9TxH1D6+lL22p+etaWFc93d9FFaujZ2QpQ5NZtVqlBK7CTPjEjk lNtTH1D+X3/v9boUhsjK2Q==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 0E.50.01052.D2B10395; Thu, 1 Jun 2017 06:48:29 -0700 (PDT) X-AuditID: 11973e12-7285e9a00000041c-85-59301b2d6319 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay3.apple.com (Apple SCV relay) with SMTP id 11.D5.15148.D2B10395; Thu, 1 Jun 2017 06:48:29 -0700 (PDT) MIME-version: 1.0 Received: from [17.153.79.34] (unknown [17.153.79.34]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OQV006QJFOSWY00@nwk-mmpp-sz09.apple.com>; Thu, 01 Jun 2017 06:48:29 -0700 (PDT) Sender: afish@apple.com From: Andrew Fish Message-id: <181773F8-7C21-4CBD-A552-AEC02B57CEA0@apple.com> Date: Thu, 01 Jun 2017 06:48:28 -0700 In-reply-to: Cc: Jordan Justen , Brijesh Singh , edk2-devel-01 , Thomas.Lendacky@amd.com, leo.duran@amd.com, Jeff Fan , Liming Gao , Jiewen Yao To: Laszlo Ersek References: <1495809845-32472-1-git-send-email-brijesh.singh@amd.com> <149583274037.25973.13062338567511386932@jljusten-skl> <6ecd0138-454e-6a6e-d034-beaf63466120@redhat.com> <149609029319.5770.13917390389219314003@jljusten-skl> <14301d64-9fa3-8231-42c1-52c2dcd9f96f@amd.com> <149630284935.10663.16670660897918560882@jljusten-skl> X-Mailer: Apple Mail (2.3273) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpikeLIzCtJLcpLzFFi42IRbCgM1tWVNog0WP9cz2Lmpj5Giz2HjjJb nFy/hNFi3UcPix3X+lksup+fZLdYdmwHi8WKexvYLY5M2cfqwOnReukvm8fiPS+ZPLpn/2Px eL/vKlsASxSXTUpqTmZZapG+XQJXxtaZa5kLHh9lqlh2q4mpgfH7LKYuRk4OCQETiacb17J1 MXJxCAmsZpLofXOAvYuRAyzxYH4SRPwgo8ThS0uYQRp4BQQlfky+xwJiMwuESVw/vZ8Zoqif SWLzmslsIAlhAXGJd2c2gTWwCShLrJj/gR2i2Ubi18sPTBA1/hJnfl5hBlnGIqAq8fGXIkiY U8BOYuf342AzmQWmMUkcPXAbrFdEQEVi9oQHTBDLOpgljr7qhHpBVuLW7EtgHRIC/ewSDQf/ s09gFJqF5NpZSK6FsLUkvj9qBYpzANnyEgfPy0KENSWe3fvEDmFrSzx5d4F1ASPbKkah3MTM HN3MPBO9xIKCnFS95PzcTYygSJtuJ7SD8dQqq0OMAhyMSjy8Ahf1IoVYE8uKK3MPMUpzsCiJ 85pm60cKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYGSrq3/yM2OD2e1Xs99ucql4c7jjXmmV yR/j9E+lm57fyDhn31n2ZHedum3S7/WKd/dFtx6ZUfjIfFtw6omYk+ey9nHGtfDbf7LLqebu b7Tnjdr0O+RLSOwfuXWyb7TeXtqcMzXWQci/zb6vp7Nz5a/6zRKPXzJevO4988L/xWtnW004 a+u23FiJpTgj0VCLuag4EQBnec58lQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUi2FAcoKsrbRBpsH2yrMXMTX2MFnsOHWW2 OLl+CaPFuo8eFjuu9bNYdD8/yW6x7NgOFosV9zawWxyZso/VgdOj9dJfNo/Fe14yeXTP/sfi 8X7fVbYAligum5TUnMyy1CJ9uwSujK0z1zIXPD7KVLHsVhNTA+P3WUxdjBwcEgImEg/mJ3Ux cnEICRxklDh8aQlzFyMnB6+AoMSPyfdYQGxmgTCJ66f3M0MU9TNJbF4zmQ0kISwgLvHuzCaw BjYBZYkV8z+wQzTbSPx6+YEJosZf4szPK8wgy1gEVCU+/lIECXMK2Ens/H4cbCazwDQmiaMH boP1igioSMye8IAJYlkHs8TRV51ggyQEZCVuzb7EPIGRfxaSA2chORDC1pL4/qgVKM4BZMtL HDwvCxHWlHh27xM7hK0t8eTdBdYFjGyrGAWKUnMSK431EgsKclL1kvNzNzGCI6MweAfjn2VW hxgFOBiVeHgFLupFCrEmlhVX5h5ilOBgVhLhFZA0iBTiTUmsrEotyo8vKs1JLT7EOJER6MuJ zFKiyfnAuM0riTc0MTEwMTY2MzY2NzGnpbCSOC8rp36kkEB6YklqdmpqQWoRzFFMHJxSDYyO t/6ueZGYsat3wesDJw/F/zn2XjbPMDv32IVLa663PhTbdaEu5902yxuvl4t1X57vu2hf9fUb p1K7Io/dO9aUxdCmt3ihH3vp7QeS2u8Tp56L+JCeFrLXs2JNh8m5au9TN6avfaZ1ac7O521M M1RcZmbqrFsgapXrfHbB06QrHjzWNhnM0yfNVWIpzkg01GIuKk4EALtpeez/AgAA X-Content-Filtered-By: Mailman/MimeDel 2.1.22 Subject: Re: [PATCH v6 00/17] x86: Secure Encrypted Virtualization (AMD) X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 13:47:29 -0000 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Laszlo, The current design is DXE IPL and gEfiCpuArchProtocolGuid abstract the CPU specifics from the DXE Core. https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L866 if (Operation == GCD_SET_ATTRIBUTES_MEMORY_OPERATION) { // // Call CPU Arch Protocol to attempt to set attributes on the range // CpuArchAttributes = ConverToCpuArchAttributes (Attributes); if (CpuArchAttributes != INVALID_CPU_ARCH_ATTRIBUTES) { if (gCpu == NULL) { Status = EFI_NOT_AVAILABLE_YET; } else { Status = gCpu->SetMemoryAttributes ( gCpu, BaseAddress, Length, CpuArchAttributes ); } if (EFI_ERROR (Status)) { CoreFreePool (TopEntry); CoreFreePool (BottomEntry); goto Done; } } } Maybe the issue is there is an attempt to change attributes too early and they currently get sent to the bit bucket? I guess they could get queued up and replayed after gEfiCpuArchProtocolGuid is preset? Thanks, Andrew Fish > On Jun 1, 2017, at 2:10 AM, Laszlo Ersek wrote: > > On 06/01/17 09:40, Jordan Justen wrote: >> On 2017-05-29 14:59:46, Brijesh Singh wrote: >>> >>> >>> On 5/29/17 3:38 PM, Jordan Justen wrote: >>>> On 2017-05-29 04:16:15, Laszlo Ersek wrote: >>>>> (looks like I was the one to comment as second reviewer after all :) ) >>>>> >>>>> On 05/26/17 23:05, Jordan Justen wrote: >>>>>> On 2017-05-26 07:43:48, Brijesh Singh wrote: >>>>>>> Changes since v4: >>>>>>> - decouple IoMmu protocol implementation from AmdSevDxe into a seperate >>>>>>> IoMmuDxe driver. And introduce a placeholder protocol to provide the >>>>>>> dependency support for the dependent modules. >>>>>> I think you split IoMmuDxe out from AmdSevDxe based on my feedback >>>>>> regarding APRIORI, but I don't think this helped. >>>>>> >>>>>> Ideally I would like to see one driver named IoMmuDxe that is *not* in >>>>>> APRIORI. >>>>> There are two separate goals here: >>>>> >>>>> (1) Make sure that any driver that adds MMIO ranges will automatically >>>>> add those ranges with the C bit cleared in the PTEs, without actually >>>>> knowing about SEV. >>>> Ok, this sounds reasonable. >>>> >>>> The APRIORI method looks like a hack. Why is this not being handled at >>>> the time the page tables are being built, in DxeIpl? Couldn't we >>>> define a platform Page Tables library to allow a platform to somehow >>>> modify the page tables as they are built? Or, maybe just after? This >>>> would also make sure it happens before DXE runs. >>> >>> Before introducing AmdSevDxe driver, we did proposed patches to clear >>> the C-bit during the page table creation time. In the first patch [1], >>> Leo tried to teach gcd.c to clear the C-bit from MMIO. IIRC, the main >>> concern was -- typically Dxecore does not do any CPU specific thing >>> hence we should try to find some alternative approach. >> >> DxeCore doesn't build the page tables. DxeIpl builds them. I agree >> that DxeCore is not the right place to handle this. In >> https://lists.01.org/pipermail/edk2-devel/2017-March/008987.html >> Jiewen suggested that DxeIpl could be updated during page table >> creation time. >> >> In https://lists.01.org/pipermail/edk2-devel/2017-April/009883.html >> Leo said that DxeIpl won't work because new I/O ranges might be added. >> I don't understand this, because isn't DxeIpl and an early APRIORI >> entry are roughly equivalent in the boot sequence? > > I think you are right. I believe a patch for this exact idea hasn't been > posted yet. Jiewen's message that you linked above contains the expression > > always clear SEV mask for MMIO *and all rest* > > (emphasis mine), which I think we may have missed *in combination with* > the DxeIpl. > > So the idea would be to iterate over all the HOBs in the DxeIpl PEIM. > Keep the C bit set for system memory regions. Clear the C bit for MMIO > regions that are known from the HOB list. Also clear the C bit > everywhere else in the address space (known from the CPU HOB) where no > coverage is provided by any memory resource descriptor HOB. > > This is going to be harder than the current approach, because: > > - The current approach can work off of the GCD memory space map, which > provides explicit NonExistent entries, covering the entire address space > (according to the CPU HOB). > > - However, the DxeIpl method would take place before entering DXE, so no > GCD memory space map would be available -- the "NonExistent" entries > would have to be synthesized manually from the address space size (known > from the CPU HOB) and the lack of coverage by memory resource descriptor > HOBs. > > Basically, in order to move the current GCD memory space map traversal > from early DXE to late PEI, the memory space map building logic of the > DXE Core would have to be duplicated in the DxeIpl PEIM. If I understand > correctly. (The DxeIpl PEIM may already contain very similar code, for > the page table building, which might not be difficult to extend like > this -- I haven't looked.) > > Is this what you have in mind? > > Thanks > Laszlo > >> -Jordan >> >>> In second patch >>> [2], Leo tried to introduce a new notify protocol to get MMIO add/remove >>> events. During discussion Jiewen suggested to look into adding a new >>> platform driver into APRIORI to avoid the need for any modifications >>> inside the Gcdcore - this seems workable solution which did not require >>> adding any CPU specific code inside the Gcd. >>> >>> [1] https://lists.01.org/pipermail/edk2-devel/2017-March/008974.html >>> [2] https://lists.01.org/pipermail/edk2-devel/2017-April/009852.html >>> > > _______________________________________________ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel