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

To: "Espen Skoglund" <espen.skoglund@xxxxxxxxxxxxx>, "Han, Weidong" <weidong.han@xxxxxxxxx>
Subject: RE: [Xen-devel] Dom0 hypercall for adding and removing PCI devices
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Thu, 24 Jul 2008 22:47:34 +0800
Cc: joshua.levasseur@xxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, "Li, Xin B" <xin.b.li@xxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Jiang, Yunhong" <yunhong.jiang@xxxxxxxxx>
Delivery-date: Thu, 24 Jul 2008 07:50:10 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <18568.36563.318369.254235@xxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <D470B4E54465E3469E2ABBC5AFAC390F024D95D6@xxxxxxxxxxxxxxxxxxxxxxxxxxxx><C4AE001B.1B835%keir.fraser@xxxxxxxxxxxxx><0122C7C995D32147B66BF4F440D30163016B6CB9@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <18568.36563.318369.254235@xxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcjtmARJjw0BW3l3SeOiYAS/4dkPkAAA2+0g
Thread-topic: [Xen-devel] Dom0 hypercall for adding and removing PCI devices
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