[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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@xxxxxxxxxx] >Sent: Tuesday, September 18, 2007 11:26 PM >To: Keir Fraser >Cc: Kay, Allen M; xen-devel@xxxxxxxxxxxxxxxxxxx; 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |