Re: [PATCH] KVM: PCIPT: VT-d: fix guest unmap

[Muli Ben-Yehuda <muli@il.ibm.com>]

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