On Wed, Jun 18, 2008 at 03:48:33PM -0500, Anthony Liguori wrote: > Right. But this is not ideal. Instead of pinning up-front, it > would make more sense IMHO to build the VT-d table as the shadow > page table gets faulted in. In certain circumstances, this will > result in extraneous updates (because a GPA=>HPA mapping is already > present) and that's where we should eliminate iotlb flushes.
As Ben wrote, we can't do this and must fault everything in up-front (assuming no PVDMA API). Assume we don't do this: it is valid for the guest to program the device with a GPA that does not yet have a corresponding HPA (because the guest did not write or read to/from it and thus we haven't yet faulted in a frame for it). Then, once the device DMA's to it, the DMA will be stopped incorrectly. >> Obviously, pinning the entire guest is not desirable since we waste >> a lot of memory resources, but this is the approach that we >> currently have. Do you find it good enough for a merge with the >> main KVM tree, and optimize later? > > No, it's not safe. What happens mmap(MAP_FIXED) into phys_ram_base? > We need to use MMU notifiers to handle such events and appropriately > flush the iotlb. Could you elaborate on what you mean here and what is not safe? Our current approach is to just fault in all of guest memory---are you concerned about a case where some of the guest frames get replaced by other frames because of the mmap()? I'd like to stress that we are shooting at the moment for the simplest possible solution that is good enough, so that we'll be able to finally merge this into the tree... >> I'm not sure how we can do that... the guest can send a guest >> physical address to the device for DMA, even without generating a >> page-fault on the host for that address... which implies that the >> host must pin the entire guest memory in advance. agree? > > See above. Ideally we would wait until the first PCI config space > access for a device before special casing the guest. Otherwise, > there's no way to allow a DMA-aware guest to avoid pinning up front. Err, if the user gave the guest pass-through access to a PCI device, presumably it is because the guest will use it... What do we win by delaying the inevitable? Cheers, Muli -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
