From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: Dom0 hypercall for adding and removing PCI devices Date: Thu, 24 Jul 2008 09:23:49 +0100 Message-ID: References: <0122C7C995D32147B66BF4F440D30163016B6BE9@pdsmsx415.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <0122C7C995D32147B66BF4F440D30163016B6BE9@pdsmsx415.ccr.corp.intel.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: "Han, Weidong" , Espen Skoglund Cc: joshua.levasseur@netronome.com, xen-devel@lists.xensource.com, "Li, Xin B" , "Jiang, Yunhong" List-Id: xen-devel@lists.xenproject.org If a device is assigned to a domain (in this case dom0) then that domain's VT-d pagetables will contain the RMRR mappings for that device. Hence BIOS can perform DMA in those RMRR-indicated regions without swapping to and fro between domain tables and fallback RMRR tables. The new fallback RMRR table would be just that -- a fallback table used for any device not currently assigned to any domain (and hence those devices should only have DMAs initiated by the BIOS, if at all). -- Keir On 24/7/08 09:20, "Han, Weidong" wrote: > 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" 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 >