WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] Dom0 hypercall for adding and removing PCI devices

Except, the RMRR mappings should be the same in both the old and the
new VT-d tables.  The fields in the page tables would not change ---
only the context entry (and the location of the VT-d page tables).

I haven't got the VT-d spec in front of me, but the quote below seems
to suggest that one can not directly reassign a device to another
domain.  One would first have to mark it as non present in the context
table before reassigning it.  Can someone from Intel confirm whether
this is the case or not?

        eSk



[Weidong Han]
> VT-d spec says: Software must not modify fields other than the
> Present (P) field of currently present root-entries or
> context-entries. If modifications to other fields are required,
> software must first make these entries not-present (P=0), which
> requires serial invalidation of context-cache and IOTLB, and then
> transition them to present (P=1) state along with the modifications.
> 
> So your suggestion is not feasible.
> 
> Randy (Weidong)
> 
> Keir Fraser wrote:
>> Exactly my thought.
>>
>>  K.
>>
>> On 24/7/08 09:43, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>>
>>> Isn't enough to first switch VT-d page table, and then flush IOTLB?
>>> As long as RMRRs are kept same in two VT-d tables, and in any
>>> time a valid entry (either in IOTLB or by walking) can be found,
>>> above sequence seems complete.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel