From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 5468021E70D2B for ; Tue, 29 Aug 2017 16:00:19 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C60CFC047B6F; Tue, 29 Aug 2017 23:02:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C60CFC047B6F Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=lersek@redhat.com Received: from lacos-laptop-7.usersys.redhat.com (ovpn-120-189.rdu2.redhat.com [10.10.120.189]) by smtp.corp.redhat.com (Postfix) with ESMTP id 0F3DE5D9C1; Tue, 29 Aug 2017 23:02:57 +0000 (UTC) From: Laszlo Ersek To: edk2-devel-01 Cc: Jordan Justen , Tom Lendacky , Ard Biesheuvel , Brijesh Singh References: <20170828132436.15933-1-lersek@redhat.com> Message-ID: <9bcab01d-d07f-45ce-f0a3-405dec5ec4d2@redhat.com> Date: Wed, 30 Aug 2017 01:02:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170828132436.15933-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 29 Aug 2017 23:02:59 +0000 (UTC) Subject: Re: [PATCH 0/6] OvmfPkg/VirtioGpuDxe: map system memory addresses to device addresses 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: Tue, 29 Aug 2017 23:00:19 -0000 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 08/28/17 15:24, Laszlo Ersek wrote: > Repo: https://github.com/lersek/edk2.git > Branch: virtio_gpu_map > > This series brings IOMMU support to VirtioGpuDxe. The interesting part > is patch#5. > > I formatted the patches with function context, for easier review. > > I regression-tested this series in various environments; IA32, X64, > AARCH64. My access to a SEV machine is still in the making, so I > couldn't test the patches on SEV. > > Brijesh, if you could test the series for me on SEV, that would be > great. I also plan to test it on SEV, once my access is established. I have great test results on SEV. Everything works as expected: - normal display behavior (setup browser, shell commands, scrolling), - connect, disconnect, reconnect in the UEFI shell, issued from the serial console, - mode changes in the UEFI shell (after reconnect too). I can see the IOMMU / SEV library debug messages too, and I can associate them with GPU actions. I also tested ExitBootServices(). In the log, I see the following six (+1) consecutive lines (broken up here for easier reading): > 244888 IoMmuUnmap PlainText 0x7D273000 Crypted 0x7D273000 Pages 0x300 Bytes 0x300000 > 244889 IoMmuDxe:InternalMemEncryptSevSetMemoryEncrypted Set C-bit Cr3 0 Base 7D273000 Length 300000 flush 1 > 244890 IoMmuUnmap PlainText 0x7ED81000 Crypted 0x7ED81000 Pages 0x2 Bytes 0x2000 > 244891 IoMmuDxe:InternalMemEncryptSevSetMemoryEncrypted Set C-bit Cr3 0 Base 7ED81000 Length 2000 flush 1 > 244892 IoMmuUnmap PlainText 0x7F0DA000 Crypted 0x7F0DA000 Pages 0x2 Bytes 0x2000 > 244893 IoMmuDxe:InternalMemEncryptSevSetMemoryEncrypted Set C-bit Cr3 0 Base 7F0DA000 Length 2000 flush 1 > 244894 MpInitChangeApLoopCallback() done! * The first two lines correspond to unmapping (re-encrypting) the backing store of the GOP's current video mode (see VirtioGpuExitBoot() in patch #5). Searching the log backwards for the same address (0x7D273000), I find it associated with the latest MODE change from the UEFI shell (when this backing store was allocated and decrypted): > 188052 IoMmuAllocateBuffer Address 0x7D273000 Pages 0x300 > 188053 IoMmuDxe:InternalMemEncryptSevSetMemoryDecrypted Clear C-bit Cr3 0 Base 7D273000 Length 300000 flush 1 > 188054 IoMmuDxe:SetMemoryEncDec Spliting 2MB page at 7D273000 > 188055 IoMmuMap PlainText 0x7D273000 Crypted 0x7D273000 Pages 0x300 Bytes 0x300000 * The second two lines correspond to unmapping (re-encrypting) the virtio ring for the virtio-gpu device (see VirtioGpuExitBoot() in patch #1). Searching the log backwards for the same address (0x7ED81000), I find it associated with the latest connecting of the virtio-gpu device, which is when the virtio-ring is allocated and mapped/decrypted (see VirtioRingMap() in patch #1): > 158667 InstallProtocolInterface: [VirtioDeviceProtocol] 7F104B20 > 158668 IoMmuAllocateBuffer Address 0x7ED81000 Pages 0x2 > 158669 IoMmuDxe:InternalMemEncryptSevSetMemoryDecrypted Clear C-bit Cr3 0 Base 7ED81000 Length 2000 flush 1 > 158670 IoMmuMap PlainText 0x7ED81000 Crypted 0x7ED81000 Pages 0x2 Bytes 0x2000 > ... > 158700 InstallProtocolInterface: [EfiGraphicsOutputProtocol] 7F1546C0 > 158701 VirtioGpuDriverBindingStart: produced GOP while binding VirtIo=7F104B20 * The third pair of lines stands for unmapping the virtio ring of the virtio-blk device that I have also configured for the guest. Searching the log backwards for the same address (0x7F0DA000), we find > 7347 IoMmuAllocateBuffer Address 0x7F0DA000 Pages 0x2 > 7348 IoMmuDxe:InternalMemEncryptSevSetMemoryDecrypted Clear C-bit Cr3 0 Base 7F0DA000 Length 2000 flush 1 > 7349 IoMmuMap PlainText 0x7F0DA000 Crypted 0x7F0DA000 Pages 0x2 Bytes 0x2000 > 7350 VirtioBlkInit: LbaSize=0x200[B] NumBlocks=0xC800000[Lba] > 7351 VirtioBlkInit: FirstAligned=0x0[Lba] PhysBlkSize=0x1[Lba] > 7352 VirtioBlkInit: OptimalTransferLengthGranularity=0x0[Lba] > 7353 InstallProtocolInterface: [EfiBlockIoProtocol] 7F0DE310 > 7354 InstallProtocolInterface: [EfiDiskIoProtocol] 7F0DE4A0 * The final line that I quoted ("MpInitChangeApLoopCallback") is just another (unrelated) ExitBootServices() handler's message. I'm going to call these results successful. Thanks, Laszlo > Cc: Ard Biesheuvel > Cc: Brijesh Singh > Cc: Jordan Justen > Cc: Tom Lendacky > > Thanks, > Laszlo > > Laszlo Ersek (6): > OvmfPkg/VirtioGpuDxe: map VRING for bus master common buffer operation > OvmfPkg/VirtioGpuDxe: map virtio GPU command objects to device > addresses > OvmfPkg/VirtioGpuDxe: take EFI_PHYSICAL_ADDRESS in > ResourceAttachBacking() > OvmfPkg/VirtioGpuDxe: helpers for backing store > (de)allocation+(un)mapping > OvmfPkg/VirtioGpuDxe: map backing store to bus master device address > OvmfPkg/VirtioGpuDxe: negotiate VIRTIO_F_IOMMU_PLATFORM > > OvmfPkg/VirtioGpuDxe/VirtioGpu.h | 89 ++++++- > OvmfPkg/VirtioGpuDxe/Commands.c | 263 ++++++++++++++++++-- > OvmfPkg/VirtioGpuDxe/DriverBinding.c | 1 - > OvmfPkg/VirtioGpuDxe/Gop.c | 62 +++-- > 4 files changed, 370 insertions(+), 45 deletions(-) >