| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [VTD-NEO][patch 5/6] Intel VT-d/Neocleus 1:1 mregedcode
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
|
|
|
| |
|
Home