From: Alex Williamson <alex.williamson@redhat.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Cc: linux-kernel@vger.kernel.org, fujita.tomonori@lab.ntt.co.jp,
iommu@lists.linux-foundation.org, albert_herranz@yahoo.es,
x86@kernel.org
Subject: Re: [PATCH] Xen-SWIOTBL v0.8.3 used for Xen PCI pass through for PV guests.
Date: Tue, 22 Jun 2010 15:23:25 -0600 [thread overview]
Message-ID: <1277241805.4669.691.camel@x201> (raw)
In-Reply-To: <1277235772-26757-1-git-send-email-konrad.wilk@oracle.com>
On Tue, 2010-06-22 at 15:42 -0400, Konrad Rzeszutek Wilk wrote:
> These nineteen patches lay the groundwork for Xen Paravirtualized (PV)
> domains to access PCI pass-through devices. These patches utilize the
> SWIOTLB library modifications (http://lkml.org/lkml/2010/6/4/272).
>
> The end user of this is the Xen PCI frontend and Xen PCI [1] which
> require a DMA API "backend" that understands Xen's MMU. This allows the
> PV domains to use PCI devices.
Hi Konrad,
Sorry if I missed it, but I didn't see any mention or apparent
requirement of a hardware iommu in xen for this code. Is that true? If
so, is there anything to stop a PV guest with ownership of a DMA capable
PCI device from reading all sorts of memory that the domain wouldn't
otherwise have access to? I was under the impression that the old PCI
front/back for PV guests was mainly an interesting hack with limited
applications due to security. Thanks,
Alex
next prev parent reply other threads:[~2010-06-22 21:24 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-22 19:42 [PATCH] Xen-SWIOTBL v0.8.3 used for Xen PCI pass through for PV guests Konrad Rzeszutek Wilk
2010-06-22 19:42 ` [PATCH 01/19] xen: use _PAGE_IOMAP in ioremap to do machine mappings Konrad Rzeszutek Wilk
2010-06-22 19:42 ` [PATCH 02/19] xen: Allow unprivileged Xen domains to create iomap pages Konrad Rzeszutek Wilk
2010-06-22 19:42 ` [PATCH 03/19] xen: Rename the balloon lock Konrad Rzeszutek Wilk
2010-06-22 19:42 ` [PATCH 04/19] xen: Add xen_create_contiguous_region Konrad Rzeszutek Wilk
2010-06-22 19:42 ` [PATCH 05/19] swiotlb-xen: Early skeleton code and explanation Konrad Rzeszutek Wilk
2010-06-22 19:42 ` [PATCH 06/19] swiotlb-xen: Copied swiotlb.c in, added xen_ prefix Konrad Rzeszutek Wilk
2010-06-22 19:42 ` [PATCH 07/19] swiotlb-xen: Make 'xen_swiotlb_alloc_coherent' work Konrad Rzeszutek Wilk
2010-06-22 19:42 ` [PATCH 08/19] swiotlb-xen: Don't allocate DMA-memory beyond 4GB in 32-bit mode Konrad Rzeszutek Wilk
2010-06-22 19:42 ` [PATCH 09/19] swiotlb-xen: Make 'xen_swiotlb_free_coherent' work Konrad Rzeszutek Wilk
2010-06-22 19:42 ` [PATCH 10/19] swiotlb-xen: Make 'xen_swiotlb_[map|unmap]_page' work Konrad Rzeszutek Wilk
2010-06-22 19:42 ` [PATCH 11/19] swiotlb-xen: Make 'xen_swiotlb_sync_single' work Konrad Rzeszutek Wilk
2010-06-22 19:42 ` [PATCH 12/19] swiotlb-xen: Make 'xen_swiotlb_map_sg_attrs' work Konrad Rzeszutek Wilk
2010-06-22 19:42 ` [PATCH 13/19] swiotlb-xen: Remove io_tlb_overflow usage Konrad Rzeszutek Wilk
2010-06-22 19:42 ` [PATCH 14/19] swiotlb-xen: Add 'xen_swiotlb_init' function Konrad Rzeszutek Wilk
2010-06-22 19:42 ` [PATCH 15/19] swiotlb-xen: Put 'swiotlb-xen.c' function declarations in the header Konrad Rzeszutek Wilk
2010-06-22 19:42 ` [PATCH 16/19] swiotlb-xen: Removing the 'struct device' in the address translation routines Konrad Rzeszutek Wilk
2010-06-22 19:42 ` [PATCH 17/19] swiotlb-xen: Coalesce usage of xen_swiotlb_map Konrad Rzeszutek Wilk
2010-06-22 19:42 ` [PATCH 18/19] pci-swiotlb-xen: Add glue code to setup dma_ops utilizing xen_swiotlb_* functions Konrad Rzeszutek Wilk
2010-06-22 19:42 ` [PATCH 19/19] x86: Detect whether we should use Xen SWIOTLB Konrad Rzeszutek Wilk
2010-06-22 21:23 ` Alex Williamson [this message]
2010-06-23 16:32 ` [PATCH] Xen-SWIOTBL v0.8.3 used for Xen PCI pass through for PV guests Konrad Rzeszutek Wilk
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=1277241805.4669.691.camel@x201 \
--to=alex.williamson@redhat.com \
--cc=albert_herranz@yahoo.es \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=iommu@lists.linux-foundation.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox