On Thu, Jan 6, 2022 at 4:19 AM Sean Christopherson <sea...@google.com> wrote: > > On Wed, Jan 05, 2022, Sean Christopherson wrote: > > Ah, I got royally confused by ensure_pfn_ref()'s comment > > > > * Certain IO or PFNMAP mappings can be backed with valid > > * struct pages, but be allocated without refcounting e.g., > > * tail pages of non-compound higher order allocations, which > > * would then underflow the refcount when the caller does the > > * required put_page. Don't allow those pages here. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > that doesn't apply here because kvm_faultin_pfn() uses the low level > > __gfn_to_pfn_page_memslot(). > > On fifth thought, I think this is wrong and doomed to fail. By mapping these > pages > into the guest, KVM is effectively saying it supports these pages. But if > the guest > uses the corresponding gfns for an action that requires KVM to access the > page, > e.g. via kvm_vcpu_map(), ensure_pfn_ref() will reject the access and all > sorts of > bad things will happen to the guest. > > So, why not fully reject these types of pages? If someone is relying on KVM > to > support these types of pages, then we'll fail fast and get a bug report > letting us > know we need to properly support these types of pages. And if not, then we > reduce > KVM's complexity and I get to keep my precious WARN :-)
Our current use case here is virtio-gpu blob resources [1]. Blob resources are useful because they avoid a guest shadow buffer and the associated memcpys, and as I understand it they are also required for virtualized vulkan. One type of blob resources requires mapping dma-bufs allocated by the host directly into the guest. This works on Intel platforms and the ARM platforms I've tested. However, the amdgpu driver sometimes allocates higher order, non-compound pages via ttm_pool_alloc_page. These are the type of pages which KVM is currently rejecting. Is this something that KVM can support? +olv, who has done some of the blob resource work. [1] https://patchwork.kernel.org/project/dri-devel/cover/20200814024000.2485-1-gurchetansi...@chromium.org/ -David _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm