From: Pavel Fedin <p.fedin@samsung.com>
To: "'Eric Auger'" <eric.auger@linaro.org>,
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
Subject: RE: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64
Date: Thu, 28 Jan 2016 10:13:21 +0300 [thread overview]
Message-ID: <00aa01d1599b$5fd3bd10$1f7b3730$@samsung.com> (raw)
In-Reply-To: <56A8854F.3030209@linaro.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
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Fedin <p.fedin@samsung.com>
To: 'Eric Auger' <eric.auger@linaro.org>,
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: patches@linaro.org, linux-kernel@vger.kernel.org,
iommu@lists.linux-foundation.org
Subject: RE: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64
Date: Thu, 28 Jan 2016 10:13:21 +0300 [thread overview]
Message-ID: <00aa01d1599b$5fd3bd10$1f7b3730$@samsung.com> (raw)
In-Reply-To: <56A8854F.3030209@linaro.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
WARNING: multiple messages have this Message-ID (diff)
From: p.fedin@samsung.com (Pavel Fedin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64
Date: Thu, 28 Jan 2016 10:13:21 +0300 [thread overview]
Message-ID: <00aa01d1599b$5fd3bd10$1f7b3730$@samsung.com> (raw)
In-Reply-To: <56A8854F.3030209@linaro.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
next prev parent reply other threads:[~2016-01-28 7:13 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-26 13:12 [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` [PATCH 01/10] iommu: Add DOMAIN_ATTR_MSI_MAPPING attribute Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` [PATCH 02/10] vfio: expose MSI mapping requirement through VFIO_IOMMU_GET_INFO Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` [PATCH 03/10] vfio_iommu_type1: add reserved binding RB tree management Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` [PATCH 04/10] vfio: introduce VFIO_IOVA_RESERVED vfio_dma type Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` [PATCH 05/10] vfio/type1: attach a reserved iova domain to vfio_domain Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` [PATCH 06/10] vfio: introduce vfio_group_alloc_map_/unmap_free_reserved_iova Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 16:17 ` kbuild test robot
2016-01-26 16:17 ` kbuild test robot
2016-01-26 16:17 ` kbuild test robot
2016-01-26 16:17 ` kbuild test robot
2016-01-26 16:37 ` Eric Auger
2016-01-26 16:37 ` Eric Auger
2016-01-26 16:37 ` Eric Auger
2016-01-26 13:12 ` [PATCH 07/10] vfio: pci: cache the vfio_group in vfio_pci_device Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` [PATCH 08/10] vfio: introduce vfio_group_require_msi_mapping Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` [PATCH 09/10] vfio-pci: create an iommu mapping for msi address Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 14:43 ` kbuild test robot
2016-01-26 14:43 ` kbuild test robot
2016-01-26 14:43 ` kbuild test robot
2016-01-26 14:43 ` kbuild test robot
2016-01-26 15:14 ` Eric Auger
2016-01-26 15:14 ` Eric Auger
2016-01-26 15:14 ` Eric Auger
2016-01-26 13:12 ` [PATCH 10/10] vfio: allow the user to register reserved iova range for MSI mapping Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 13:12 ` Eric Auger
2016-01-26 16:42 ` kbuild test robot
2016-01-26 16:42 ` kbuild test robot
2016-01-26 16:42 ` kbuild test robot
2016-01-26 18:32 ` kbuild test robot
2016-01-26 18:32 ` kbuild test robot
2016-01-26 18:32 ` kbuild test robot
2016-01-26 18:32 ` kbuild test robot
2016-01-26 17:25 ` [PATCH 00/10] KVM PCIe/MSI passthrough on ARM/ARM64 Pavel Fedin
2016-01-26 17:25 ` Pavel Fedin
2016-01-26 17:25 ` Pavel Fedin
2016-01-27 8:52 ` Eric Auger
2016-01-27 8:52 ` Eric Auger
2016-01-27 8:52 ` Eric Auger
2016-01-28 7:13 ` Pavel Fedin [this message]
2016-01-28 7:13 ` Pavel Fedin
2016-01-28 7:13 ` Pavel Fedin
2016-01-28 9:50 ` Eric Auger
2016-01-28 9:50 ` Eric Auger
2016-01-28 21:51 ` Alex Williamson
2016-01-28 21:51 ` Alex Williamson
2016-01-28 21:51 ` Alex Williamson
2016-01-29 14:35 ` Eric Auger
2016-01-29 14:35 ` Eric Auger
2016-01-29 14:35 ` Eric Auger
2016-01-29 19:33 ` Alex Williamson
2016-01-29 19:33 ` Alex Williamson
2016-01-29 21:25 ` Eric Auger
2016-01-29 21:25 ` Eric Auger
2016-01-29 21:25 ` Eric Auger
2016-02-01 14:03 ` Will Deacon
2016-02-01 14:03 ` Will Deacon
2016-02-01 14:03 ` Will Deacon
2016-02-03 12:50 ` Christoffer Dall
2016-02-03 12:50 ` Christoffer Dall
2016-02-03 12:50 ` Christoffer Dall
2016-02-03 13:10 ` Will Deacon
2016-02-03 13:10 ` Will Deacon
2016-02-03 13:10 ` Will Deacon
2016-02-03 15:36 ` Christoffer Dall
2016-02-03 15:36 ` Christoffer Dall
2016-02-03 15:36 ` Christoffer Dall
2016-02-05 17:32 ` ARM PCI/MSI KVM passthrough with GICv2M Eric Auger
2016-02-05 17:32 ` Eric Auger
2016-02-05 18:17 ` Alex Williamson
2016-02-05 18:17 ` Alex Williamson
2016-02-05 18:17 ` Alex Williamson
2016-02-08 9:48 ` Christoffer Dall
2016-02-08 9:48 ` Christoffer Dall
2016-02-08 9:48 ` Christoffer Dall
2016-02-08 13:27 ` Eric Auger
2016-02-08 13:27 ` Eric Auger
2016-02-08 13:27 ` Eric Auger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='00aa01d1599b$5fd3bd10$1f7b3730$@samsung.com' \
--to=p.fedin@samsung.com \
--cc=Bharat.Bhushan@freescale.com \
--cc=alex.williamson@redhat.com \
--cc=christoffer.dall@linaro.org \
--cc=eric.auger@linaro.org \
--cc=eric.auger@st.com \
--cc=iommu@lists.linux-foundation.org \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=patches@linaro.org \
--cc=pranav.sawargaonkar@gmail.com \
--cc=suravee.suthikulpanit@amd.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.