RE: [Xen-devel] [VTD-NEO][patch 5/6] Intel VT-d/Neocleus 1:1 mregedcode for PCI passthrough

["Kay, Allen M" <allen.m.kay@xxxxxxxxx>]

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