From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967090AbcAZRZO (ORCPT ); Tue, 26 Jan 2016 12:25:14 -0500 Received: from mailout2.w1.samsung.com ([210.118.77.12]:20511 "EHLO mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966811AbcAZRZK (ORCPT ); Tue, 26 Jan 2016 12:25:10 -0500 X-AuditID: cbfec7f5-f79b16d000005389-12-56a7abf2d85c From: Pavel Fedin To: "'Eric Auger'" , eric.auger@st.com, alex.williamson@redhat.com, will.deacon@arm.com, christoffer.dall@linaro.org, marc.zyngier@arm.com, linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org Cc: Bharat.Bhushan@freescale.com, pranav.sawargaonkar@gmail.com, suravee.suthikulpanit@amd.com, linux-kernel@vger.kernel.org, patches@linaro.org, iommu@lists.linux-foundation.org References: <1453813968-2024-1-git-send-email-eric.auger@linaro.org> In-reply-to: <1453813968-2024-1-git-send-email-eric.auger@linaro.org> Subject: RE: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 Date: Tue, 26 Jan 2016 20:25:06 +0300 Message-id: <000001d1585e$8097d7e0$81c787a0$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-index: AQImAGWnHKV8x208rSuLXeddGR5I/p5krvcw Content-language: ru X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCIsWRmVeSWpSXmKPExsVy+t/xq7qfVi8PMzh/xsbi2/8eNovjP76y Wbx4/Y/RYv6WM6wWVzefZbJYsN/aYs7UQouPp46zW2x6fI3V4vKuOWwWf+/8Y7OYcvgLi8XT ObNZLCb+WMBo8fLjCRYHfo/WS3/ZPNbMW8Po8e9wP5PHzll32T3uXNvD5nF+0xpmj81L6j0m 31jO6PF+31U2j6c/9jJ7fN4kF8AdxWWTkpqTWZZapG+XwJWxbX8/e8EVzooJ1z+wNTDeZO9i 5OSQEDCRODFjJiuELSZx4d56ti5GLg4hgaWMEjenfmSCcL4wSpx9MJEFpIpNQF3i9NcPLCAJ EYF/jBKT7lwHa2EW2MYo8fJ7CzNIlZCAi8TrnQ1gHZwCrhItf46wgdjCAg4SOy/uBrNZBFQl lr9YwAhi8wpYSqx+8xHKFpT4MfkeWC+zgJbE+p3HmSBseYnNa94yQ9yqILH701GguzmArjCS 2D6vAqJERGLav3vMExiFZiGZNAvJpFlIJs1C0rKAkWUVo2hqaXJBcVJ6rpFecWJucWleul5y fu4mRkjcft3BuPSY1SFGAQ5GJR5ezuJlYUKsiWXFlbmHGCU4mJVEeDV6l4cJ8aYkVlalFuXH F5XmpBYfYpTmYFES5525632IkEB6YklqdmpqQWoRTJaJg1OqgbHKcN2/W5NbPLcZ+V5a0Ws/ v1lkRdPmusVJ+00Fmz2r7UPPqRXumKZsbVAy4+jKhE28LPcTeO1SJNpz7qoVe25S/v6f2dIi vXl5GCv7nNaqCqO40zKPy2eVhf9Xqa7599n7upym4IKA3amJQpaiqVUeYrsUD0ysT7XjZ5Zn PO16p9Jce98SJZbijERDLeai4kQALtUWJtcCAAA= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello! I'd like just to clarify some things for myself and better wrap my head around it... > On x86 all accesses to the 1MB PA region [FEE0_0000h - FEF0_000h] are directed > as interrupt messages: accesses to this special PA window directly target the > APIC configuration space and not DRAM, meaning the downstream IOMMU is bypassed. So, this is effectively the same as always having hardwired 1:1 mappings on all IOMMUs, isn't it ? If so, then we can't we just do the same, just by forcing similar 1:1 mapping? This is what i tried to do in my patchset. All of you are talking about a situation which arises when we are emulating different machine with different physical addresses layout. And e. g. if our host has MSI at 0xABADCAFE, our target could have valid RAM at the same location, and we need to handle it somehow, therefore we have to move our MSI window out of target's RAM. But how does this work on a PC then? What if our host is PC, and we want to emulate some ARM board, which has RAM at FE00 0000 ? Or does it mean that PC architecture is flawed and can reliably handle PCI passthrough only for itself ? Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia