[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |