From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932484AbcA1HN2 (ORCPT ); Thu, 28 Jan 2016 02:13:28 -0500 Received: from mailout4.w1.samsung.com ([210.118.77.14]:48797 "EHLO mailout4.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751382AbcA1HN0 (ORCPT ); Thu, 28 Jan 2016 02:13:26 -0500 X-AuditID: cbfec7f5-f79b16d000005389-bc-56a9bf935383 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> <000001d1585e$8097d7e0$81c787a0$@samsung.com> <56A8854F.3030209@linaro.org> In-reply-to: <56A8854F.3030209@linaro.org> Subject: RE: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 Date: Thu, 28 Jan 2016 10:13:21 +0300 Message-id: <00aa01d1599b$5fd3bd10$1f7b3730$@samsung.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-index: AQImAGWnHKV8x208rSuLXeddGR5I/gH19NStAl4h2bqeRJSHIA== Content-language: ru X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKIsWRmVeSWpSXmKPExsVy+t/xy7qT968MM/i+R8ri2/8eNovjP76y Wbx4/Y/RYv6WM6wWVzefZbJYsN/aYs7UQouPp46zW2x6fI3V4vKuOWwWf+/8Y7OYcvgLi8XT ObNZLCb+WMBo8fLjCRYHfo/WS3/ZPNbMW8Po8e9wP5PHzll32T3uXNvD5nF+0xpmj81L6j0m 31jO6PF+31U2j6c/9jJ7fN4kF8AdxWWTkpqTWZZapG+XwJXxfPYx5oJb7BXXb69hbmDsYOti 5OSQEDCR2NW3iBnCFpO4cG89WFxIYCmjxOazsl2MXED2d0aJS7sPMoEk2ATUJU5//cACkhAR +McoMenOdTYQh1lgG6PEy+8tzBAtkxglJm9+yQrSwimgJTHp5TywdmEBB4mdF3eD7WARUJX4 1TabEcTmFbCUmP1/DRuELSjxY/I9FhCbGah3/c7jTBC2vMTmNW+hblWQ2HH2NViviICTxITp n5khakQkpv27xzyBUWgWklGzkIyahWTULCQtCxhZVjGKppYmFxQnpeca6RUn5haX5qXrJefn bmKERO7XHYxLj1kdYhTgYFTi4WWIWhkmxJpYVlyZe4hRgoNZSYRXsRooxJuSWFmVWpQfX1Sa k1p8iFGag0VJnHfmrvchQgLpiSWp2ampBalFMFkmDk6pBkYuF9O/NxOX8fzui+Ov+/m+77k2 +4PdTBdFBA8UmxQuPXJk3Xy5iESu5IBtHAU3i1acFmww5vxqE3pGto87U0I6f5JThvMq56Wh hSL7I2oYH7Z1V34Nm200Z53QslQ/KYMDJlejHoVt/7vllKT5e69XebW5VadrV4oHe66sujRZ 0OvcVUWBViWW4oxEQy3mouJEADZwXGfYAgAA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello! > x86 isn't problem-free in this space. An x86 VM is going to know that > the 0xfee00000 address range is special, it won't be backed by RAM and > won't be a DMA target, thus we'll never attempt to map it for an iova > address. However, if we run a non-x86 VM or a userspace driver, it > doesn't necessarily know that there's anything special about that range > of iovas. I intend to resolve this with an extension to the iommu info > ioctl that describes the available iova space for the iommu. The > interrupt region would simply be excluded. I see now, but i still don't understand how it would work. How can we tell the guest OS that we cannot do DMA to this particular area? Just exclude it from RAM at all? But this means we would have to modify machine's model... I know that this is a bit different story from what we are implementing now. Just curious. Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Fedin Subject: RE: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 Date: Thu, 28 Jan 2016 10:13:21 +0300 Message-ID: <00aa01d1599b$5fd3bd10$1f7b3730$@samsung.com> References: <1453813968-2024-1-git-send-email-eric.auger@linaro.org> <000001d1585e$8097d7e0$81c787a0$@samsung.com> <56A8854F.3030209@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: patches@linaro.org, linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org 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 Return-path: In-reply-to: <56A8854F.3030209@linaro.org> Content-language: ru List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu List-Id: kvm.vger.kernel.org Hello! > x86 isn't problem-free in this space. An x86 VM is going to know that > the 0xfee00000 address range is special, it won't be backed by RAM and > won't be a DMA target, thus we'll never attempt to map it for an iova > address. However, if we run a non-x86 VM or a userspace driver, it > doesn't necessarily know that there's anything special about that range > of iovas. I intend to resolve this with an extension to the iommu info > ioctl that describes the available iova space for the iommu. The > interrupt region would simply be excluded. I see now, but i still don't understand how it would work. How can we tell the guest OS that we cannot do DMA to this particular area? Just exclude it from RAM at all? But this means we would have to modify machine's model... I know that this is a bit different story from what we are implementing now. Just curious. Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia From mboxrd@z Thu Jan 1 00:00:00 1970 From: p.fedin@samsung.com (Pavel Fedin) Date: Thu, 28 Jan 2016 10:13:21 +0300 Subject: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 In-Reply-To: <56A8854F.3030209@linaro.org> References: <1453813968-2024-1-git-send-email-eric.auger@linaro.org> <000001d1585e$8097d7e0$81c787a0$@samsung.com> <56A8854F.3030209@linaro.org> Message-ID: <00aa01d1599b$5fd3bd10$1f7b3730$@samsung.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hello! > x86 isn't problem-free in this space. An x86 VM is going to know that > the 0xfee00000 address range is special, it won't be backed by RAM and > won't be a DMA target, thus we'll never attempt to map it for an iova > address. However, if we run a non-x86 VM or a userspace driver, it > doesn't necessarily know that there's anything special about that range > of iovas. I intend to resolve this with an extension to the iommu info > ioctl that describes the available iova space for the iommu. The > interrupt region would simply be excluded. I see now, but i still don't understand how it would work. How can we tell the guest OS that we cannot do DMA to this particular area? Just exclude it from RAM at all? But this means we would have to modify machine's model... I know that this is a bit different story from what we are implementing now. Just curious. Kind regards, Pavel Fedin Senior Engineer Samsung Electronics Research center Russia