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

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

I took a look, and it seems that spec does say so:
----
Modifying Root and Context Entries

When DMA-remapping hardware is active:

* Software must serially invalidate the context-cache and the 
IOTLB when updating root-entries or context-entries. The 
serialization is required since hardware may utilize information 
from the context-caches to tag new entries inserted to the 
IOTLB while processing in-flight DMA requests.

* 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. 
----

I guess RMRR mapping may be OK even by voilating the 
spec, since even stale entry is used which serves same.
But since spec explicitly states it, I agree with Keir that
current solution is easiest.

For normal device re-assignment, that's why some reset
action is required before re-assignment, like FLR, etc. as
discussed in other thread from Dexuan.

Thanks,
Kevin

>From: Espen Skoglund
>Sent: 2008年7月24日 22:17
>
>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
>

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