Kay, Allen M
2007-Sep-05 00:09 UTC
[Xen-devel] [VTD-NEO][patch 5/6] Intel VT-d/Neocleus 1:1 mreged code for PCI passthrough
xen/arch/x86 and xen/common change minus vt-d and pt directories. Signed-off-by: Allen Kay <allen.m.kay@intel.com> Signed-off-by: Guy Zana <guy@neocleus.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kay, Allen M
2007-Sep-17 22:17 UTC
RE: [Xen-devel] [VTD-NEO][patch 5/6] Intel VT-d/Neocleus 1:1 mregedcode for PCI passthrough
These two patches contains miscellaneous xen and interrupt handling changes contains in previous xen.patch. xen_misc.c: miscellaneous collection of xen changes intr.c : patch for hvm interrupt injection mechanism I''m still working on mm changes work Tim Deegan - which should be the very last piece of this series of patches. The above two patches were tested against cs# 15894. Allen Signed-off-by: Allen Kay <allen.m.kay@intel.com> Signed-off-by: Guy Zana <guy@neocleus.com>>-----Original Message----- >From: xen-devel-bounces@lists.xensource.com >[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of >Kay, Allen M >Sent: Tuesday, September 04, 2007 5:09 PM >To: xen-devel@lists.xensource.com >Cc: Guy Zana; Keir Fraser >Subject: [Xen-devel] [VTD-NEO][patch 5/6] Intel VT-d/Neocleus >1:1 mregedcode for PCI passthrough > >xen/arch/x86 and xen/common change minus vt-d and pt directories. > >Signed-off-by: Allen Kay <allen.m.kay@intel.com> >Signed-off-by: Guy Zana <guy@neocleus.com> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Sep-18 14:18 UTC
Re: [Xen-devel] [VTD-NEO][patch 5/6] Intel VT-d/Neocleus 1:1 mregedcode for PCI passthrough
On 17/9/07 23:17, "Kay, Allen M" <allen.m.kay@intel.com> wrote:> These two patches contains miscellaneous xen and interrupt handling > changes contains in previous xen.patch. > > xen_misc.c: miscellaneous collection of xen changesThe changes to common code reference an x86-specific variable. Also I don''t see how the changes make sense. Gnttab_transfer is deprecated so why would you care about modifying that path? The changes in page_alloc.c are dependent on !hvm_domain(), but I thought the iommu changes were specifically to support PCI passthru for HVM domains? -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kay, Allen M
2007-Sep-18 20:41 UTC
RE: [Xen-devel] [VTD-NEO][patch 5/6] Intel VT-d/Neocleus 1:1 mregedcode for PCI passthrough
Gnntab_transfer changes were originally made by one of my colleagus for supporting PV guest in another configuration. We will resubmit this in the future after we clean this up. The reason we are checking for !hvm_domain in page_alloc() is for setting up vt-d page tables for dom0 and PV domain. Note that once vt-d DMA translation is enabled, it applies to all domains. VT-d page table for HVM domain is shared with p2m table. It is setup by vtd/intel-iommu.c/iommu_set_pgd() - call from p2m.c. This is the reason we don''t need to do anything from hvm domain in page_alloc.c. I was checking for vtd_enabled in common/page_alloc.c. What is the proper place to define this? I will defer submission of common changes until we reach an agreement on this. I have split the remaining xen_misc.patch into following two pieces: - io.patch : ioport handling and 2 trivial header file changes - xen_misc.patch: the remaining misc. xen changes. Allen Signed-off-by: Allen Kay <allen.m.kay@intel.com> Signed-off-by: Guy Zana <guy@neocleus.com>>-----Original Message----- >From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk] >Sent: Tuesday, September 18, 2007 7:18 AM >To: Kay, Allen M; xen-devel@lists.xensource.com >Cc: Guy Zana >Subject: Re: [Xen-devel] [VTD-NEO][patch 5/6] Intel >VT-d/Neocleus 1:1 mregedcode for PCI passthrough > >On 17/9/07 23:17, "Kay, Allen M" <allen.m.kay@intel.com> wrote: > >> These two patches contains miscellaneous xen and interrupt handling >> changes contains in previous xen.patch. >> >> xen_misc.c: miscellaneous collection of xen changes > >The changes to common code reference an x86-specific variable. >Also I don''t >see how the changes make sense. Gnttab_transfer is deprecated >so why would >you care about modifying that path? The changes in page_alloc.c are >dependent on !hvm_domain(), but I thought the iommu changes were >specifically to support PCI passthru for HVM domains? > > -- Keir >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2007-Sep-19 06:24 UTC
Re: [Xen-devel] [VTD-NEO][patch 5/6] Intel VT-d/Neocleus 1:1 mregedcode for PCI passthrough
On 18/9/07 21:41, "Kay, Allen M" <allen.m.kay@intel.com> wrote:> I was checking for vtd_enabled in common/page_alloc.c. What is the > proper place to define this? I will defer submission of common changes > until we reach an agreement on this.Since this initial patchset is about translation (for HVM guests) rather than security, you could have a global iommu table for all PV guests that 1:1 maps everything. That can be set up at start-of-day with no common-code hooks. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Muli Ben-Yehuda
2007-Sep-19 06:26 UTC
Re: [Xen-devel] [VTD-NEO][patch 5/6] Intel VT-d/Neocleus 1:1 mregedcode for PCI passthrough
On Wed, Sep 19, 2007 at 07:24:33AM +0100, Keir Fraser wrote:> On 18/9/07 21:41, "Kay, Allen M" <allen.m.kay@intel.com> wrote: > > > I was checking for vtd_enabled in common/page_alloc.c. What is the > > proper place to define this? I will defer submission of common changes > > until we reach an agreement on this. > > Since this initial patchset is about translation (for HVM guests) > rather than security, you could have a global iommu table for all PV > guests that 1:1 maps everything. That can be set up at start-of-day > with no common-code hooks.Since VT-d has a per BDF translation table, why does enabling translation for some BDF''s require enabling it for everyone else too? Cheers, Muli _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kay, Allen M
2007-Sep-19 06:32 UTC
RE: [Xen-devel] [VTD-NEO][patch 5/6] Intel VT-d/Neocleus 1:1 mregedcode for PCI passthrough
Translation enabling is on per vt-d engine granularity - not BDF granularity. Each BDF context entry can point to a different page table structure. Setup a single 1:1 mapping structure to be used by all PV domains is a good idea. I will give it a try tomorrow. Allen>-----Original Message----- >From: Muli Ben-Yehuda [mailto:muli@il.ibm.com] >Sent: Tuesday, September 18, 2007 11:26 PM >To: Keir Fraser >Cc: Kay, Allen M; xen-devel@lists.xensource.com; Guy Zana >Subject: Re: [Xen-devel] [VTD-NEO][patch 5/6] Intel >VT-d/Neocleus 1:1 mregedcode for PCI passthrough > >On Wed, Sep 19, 2007 at 07:24:33AM +0100, Keir Fraser wrote: >> On 18/9/07 21:41, "Kay, Allen M" <allen.m.kay@intel.com> wrote: >> >> > I was checking for vtd_enabled in common/page_alloc.c. What is the >> > proper place to define this? I will defer submission of >common changes >> > until we reach an agreement on this. >> >> Since this initial patchset is about translation (for HVM guests) >> rather than security, you could have a global iommu table for all PV >> guests that 1:1 maps everything. That can be set up at start-of-day >> with no common-code hooks. > >Since VT-d has a per BDF translation table, why does enabling >translation for some BDF''s require enabling it for everyone else too? > >Cheers, >Muli >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Muli Ben-Yehuda
2007-Sep-19 06:37 UTC
Re: [Xen-devel] [VTD-NEO][patch 5/6] Intel VT-d/Neocleus 1:1 mregedcode for PCI passthrough
On Tue, Sep 18, 2007 at 11:32:25PM -0700, Kay, Allen M wrote:> Translation enabling is on per vt-d engine granularity - not BDF > granularity. Each BDF context entry can point to a different page > table structure. > > Setup a single 1:1 mapping structure to be used by all PV domains is > a good idea. I will give it a try tomorrow.I see, thanks for clarifying. That seems pretty strange... do you have a notion of the overhead incured by the 1-1 mapping and the average IOTLB hit/miss rates? Cheers, Muli _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Kay, Allen M
2007-Sep-19 23:55 UTC
RE: [Xen-devel] [VTD-NEO][patch 5/6] Intel VT-d/Neocleus 1:1 mregedcode for PCI passthrough
My informal tests did not show much performance degradation. It is not easy to figure out miss rates without performance counters. If you look at the latest vt-d spec on the web, there is a passthru feature in the context entry which will allow passthru DMA on BDF granularity in the future. http://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Di rect_IO.pdf Allen>-----Original Message----- >From: Muli Ben-Yehuda [mailto:muli@il.ibm.com] >Sent: Tuesday, September 18, 2007 11:38 PM >To: Kay, Allen M >Cc: Keir Fraser; xen-devel@lists.xensource.com; Guy Zana >Subject: Re: [Xen-devel] [VTD-NEO][patch 5/6] Intel >VT-d/Neocleus 1:1 mregedcode for PCI passthrough > >On Tue, Sep 18, 2007 at 11:32:25PM -0700, Kay, Allen M wrote: > >> Translation enabling is on per vt-d engine granularity - not BDF >> granularity. Each BDF context entry can point to a different page >> table structure. >> >> Setup a single 1:1 mapping structure to be used by all PV domains is >> a good idea. I will give it a try tomorrow. > >I see, thanks for clarifying. That seems pretty strange... do you have >a notion of the overhead incured by the 1-1 mapping and the average >IOTLB hit/miss rates? > >Cheers, >Muli >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel