[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



I have another concern, when BIOS is initiating DMA operation using
RMRR, can we use RMRR VT-d page table to replace dom0 VT-d page table?
Does it result in some DMA failures?

Randy (weidong)

Han, Weidong wrote:
> Espen Skoglund wrote:
>> [Keir Fraser]
>>> On 23/7/08 10:26, "Han, Weidong" <weidong.han@xxxxxxxxx> wrote:
>>>>> So this would be one extra VT-d pagetable, for the whole system,
>>>>> which would be the fallback location for RMRR mappings for devices
>>>>> which are currently not assigned to any domain? Thus allowing
>>>>> firmware to successfully initiate DMA operations on those devices?
>>>>> Sounds sensible.
>> 
>> Well, the VT-d page table for RMRR devices need not contain the whole
>> system memory---only those regions specified in the DMAR tables.
>> 
>>>> Is it possible that idle_domain owns the RMRR VT-d page table?
>> 
>>> If that's a convenient place to stash it then why not? Either way,
>>> seems you're going to have it special-cased in the code as fallback
>>> owner for unassigned devices. It's possible that having it stashed
>>> in the idle domain will simply make the code more confusing. I'm not
>>> sure though.
>> 
>> Right.  I don't see any particular good reason to associate it with
>> the idle domain.  As noted above, the page table need not even cover
>> the whole memory, and it will never change after being set up at boot
>> time.  If special case code is needed anyway, then one might as well
>> install a custom VT-d page table.
> 
> What does "custom VT-d page table" mean?
> 
> Due to domain id is not the same with DID field in context, we can
> reverse a DID for RMRR VT-d page table, it can avoid to associate
> with idle domain.  
> 
> Currently we reassign the device from dom0 to target domain when
> assign a device, and return the device to dom0 when target domain
> tears down. It's not correct due to some devices may be not assigned
> to any domain. Current device_assigned() also needs to be changed.
> Maybe it needs more changes on VT-d.    
> 
> I have some concerns, maybe I missed something. Why did you use dom0
> hypercall approach to replace original method? What's the main
> benefit? I also wonder it's suitable to wrap pci_bus_probe()
> function.   
> 
> Randy (Weidong)
> 
>> 
>> If supported by hardware, the extra page tables can even be skipped
>> altogether and the device marked as having passthrough access.  That
>> would give the RMRR device complete access to system memory, though.
>> 
>>      eSk


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.