From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nbfkord-smmo02.seg.att.com (nbfkord-smmo02.seg.att.com [209.65.160.78]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 2EFF48220F for ; Fri, 3 Mar 2017 08:33:23 -0800 (PST) Received: from unknown [193.34.186.16] (EHLO webmail.solarflare.com) by nbfkord-smmo02.seg.att.com(mxl_mta-7.2.4-7) over TLS secured channel with ESMTP id 2da99b85.0.1078919.00-2315.2976671.nbfkord-smmo02.seg.att.com (envelope-from ); Fri, 03 Mar 2017 16:33:23 +0000 (UTC) X-MXL-Hash: 58b99ad3237d2fab-bc4560e8f034f3c6e0e5a9481a83dd7d8add226f Received: from tp-desktop.uk.solarflarecom.com (10.17.20.51) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 3 Mar 2017 16:32:57 +0000 To: "edk2-devel@lists.01.org" From: "Tomas Pilar (tpilar)" Message-ID: <08cbd2c5-5d7e-bdc7-cf74-e5c48edf86c0@solarflare.com> Date: Fri, 3 Mar 2017 16:32:53 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 X-Originating-IP: [10.17.20.51] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-22918.003 X-TM-AS-Result: No--9.284100-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.1 cv=T6yKOq+Q c=1 sm=1 tr=0 a=8P+NB+fYZDP74ap4g4d9Kw==] X-AnalysisOut: [:17 a=uKoR9wHPcrcA:10 a=IkcTkHD0fZMA:10 a=6Iz7jQTuP9IA:10 ] X-AnalysisOut: [a=wvrG-K9YChnRi13a8XYA:9 a=QEXdDO2ut3YA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [193.34.186.16] Subject: Hiding physical memory from OS and VT-d/IOMMU X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 16:33:23 -0000 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I am trying to implement a message-box communication protocol between PCIe devices in the same host without the assistance of the OS. For irreducible reasons, I can't use PCIe endpoint-to-endpoint communication so I thought I could create a DMA based message-box protocol where in UEFI driver probe (during DXE) I blot out some physical memory (by leaking a page of memory allocated as EfiRuntimeServicesData) that the devices will then use to communicate even when the OS loads. This runs into a problem when VT-d/IOMMU is involved because it still stops the device from DMA into that page, even though the OS shouldn't touch the page as it's been allocated using EfiRuntimeServicesData. So my query is: Can I achieve this by allocating the box as a different memory type (such as EfiUnusableMemory or EfiReservedMemoryType) and if not, what would be a better way of doing this? Cheers, Tom The information contained in this message is confidential and is intended f= or the addressee(s) only. If you have received this message in error, pleas= e notify the sender immediately and delete the message. Unless you are an a= ddressee (or authorized to receive for an addressee), you may not use, copy= or disclose to anyone this message or any information contained in this me= ssage. The unauthorized use, disclosure, copying or alteration of this mess= age is strictly prohibited.