From: "Christian König" <christian.koenig@amd.com>
To: "Kasireddy, Vivek" <vivek.kasireddy@intel.com>,
Gerd Hoffmann <kraxel@redhat.com>
Cc: "Kim, Dongwon" <dongwon.kim@intel.com>,
"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
Daniel Vetter <daniel@ffwll.ch>,
"Vetter, Daniel" <daniel.vetter@intel.com>,
"sumit.semwal@linaro.org" <sumit.semwal@linaro.org>,
"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>
Subject: Re: [RFC v3 2/3] virtio: Introduce Vdmabuf driver
Date: Wed, 10 Feb 2021 09:05:27 +0100 [thread overview]
Message-ID: <8ac10b1d-3d64-4e39-42e6-6c65b61f0794@amd.com> (raw)
In-Reply-To: <2ef01dc941684a15a4f30e6239ae42df@intel.com>
Hi Vivek,
Am 10.02.21 um 05:47 schrieb Kasireddy, Vivek:
> Hi Gerd,
>
>> -----Original Message-----
>> From: Gerd Hoffmann <kraxel@redhat.com>
>> Sent: Tuesday, February 09, 2021 12:45 AM
>> To: Kasireddy, Vivek <vivek.kasireddy@intel.com>
>> Cc: Daniel Vetter <daniel@ffwll.ch>; virtualization@lists.linux-foundation.org; dri-
>> devel@lists.freedesktop.org; Vetter, Daniel <daniel.vetter@intel.com>;
>> daniel.vetter@ffwll.ch; Kim, Dongwon <dongwon.kim@intel.com>;
>> sumit.semwal@linaro.org; christian.koenig@amd.com; linux-media@vger.kernel.org
>> Subject: Re: [RFC v3 2/3] virtio: Introduce Vdmabuf driver
>>
>> Hi,
>>
>>>>>> Nack, this doesn't work on dma-buf. And it'll blow up at runtime
>>>>>> when you enable the very recently merged CONFIG_DMABUF_DEBUG (would
>>>>>> be good to test with that, just to make sure).
>>> [Kasireddy, Vivek] Although, I have not tested it yet but it looks like this will
>>> throw a wrench in our solution as we use sg_next to iterate over all the struct page *
>>> and get their PFNs. I wonder if there is any other clean way to get the PFNs of all
>>> the pages associated with a dmabuf.
>> Well, there is no guarantee that dma-buf backing storage actually has
>> struct page ...
> [Kasireddy, Vivek] What if I do mmap() on the fd followed by mlock() or mmap()
> followed by get_user_pages()? If it still fails, would ioremapping the device memory
> and poking at the backing storage be an option? Or, if I bind the passthrough'd GPU device
> to vfio-pci and tap into the memory region associated with the device memory, can it be
> made to work?
get_user_pages() is not allowed on mmaped DMA-bufs in the first place.
Daniel is currently adding code to make sure that this is never ever used.
> And, I noticed that for PFNs that do not have valid struct page associated with it, KVM
> does a memremap() to access/map them. Is this an option?
No, even for system memory which has a valid struct page touching it
when it is part of a DMA-buf is illegal since the reference count and
mapping fields in struct page might be used for something different.
Keep in mind that struct page is a heavily overloaded structure for
different use cases. You can't just use it for a different use case than
what the owner of the page has intended it.
Regards,
Christian.
>
>>> [Kasireddy, Vivek] To exclude such cases, would it not be OK to limit the scope
>>> of this solution (Vdmabuf) to make it clear that the dma-buf has to live in Guest RAM?
>>> Or, are there any ways to pin the dma-buf pages in Guest RAM to make this
>>> solution work?
>> At that point it becomes (i915) driver-specific. If you go that route
>> it doesn't look that useful to use dma-bufs in the first place ...
> [Kasireddy, Vivek] I prefer not to make this driver specific if possible.
>
>>> IIUC, Virtio GPU is used to present a virtual GPU to the Guest and all the rendering
>>> commands are captured and forwarded to the Host GPU via Virtio.
>> You don't have to use the rendering pipeline. You can let the i915 gpu
>> render into a dma-buf shared with virtio-gpu, then use virtio-gpu only for
>> buffer sharing with the host.
> [Kasireddy, Vivek] Is this the most viable path forward? I am not sure how complex or
> feasible it would be but I'll look into it.
> Also, not using the rendering capabilities of virtio-gpu and turning it into a sharing only
> device means there would be a giant mode switch with a lot of if() conditions sprinkled
> across. Are you OK with that?
>
> Thanks,
> Vivek
>> take care,
>> Gerd
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2021-02-10 8:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-03 7:35 [RFC v3 0/3] Introduce Virtio based Dmabuf driver Vivek Kasireddy
2021-02-03 7:35 ` [RFC v3 1/3] kvm: Add a notifier for create and destroy VM events Vivek Kasireddy
2021-02-03 7:35 ` [RFC v3 2/3] virtio: Introduce Vdmabuf driver Vivek Kasireddy
2021-02-05 16:03 ` Daniel Vetter
2021-02-08 7:57 ` Gerd Hoffmann
2021-02-08 9:38 ` Daniel Vetter
2021-02-09 0:25 ` Kasireddy, Vivek
[not found] ` <20210209084453.5oqepy7zdwtxgrpu@sirius.home.kraxel.org>
2021-02-10 4:47 ` Kasireddy, Vivek
2021-02-10 8:05 ` Christian König [this message]
2021-02-12 8:36 ` Kasireddy, Vivek
2021-02-12 8:47 ` Christian König
2021-02-12 10:14 ` Gerd Hoffmann
2021-02-10 9:16 ` Gerd Hoffmann
2021-02-12 8:15 ` Kasireddy, Vivek
2021-02-12 11:01 ` Gerd Hoffmann
2021-02-22 8:52 ` Kasireddy, Vivek
2021-03-15 2:27 ` Zhang, Tina
2021-02-03 7:35 ` [RFC v3 3/3] vhost: Add Vdmabuf backend Vivek Kasireddy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8ac10b1d-3d64-4e39-42e6-6c65b61f0794@amd.com \
--to=christian.koenig@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel.vetter@intel.com \
--cc=daniel@ffwll.ch \
--cc=dongwon.kim@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kraxel@redhat.com \
--cc=linux-media@vger.kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=virtualization@lists.linux-foundation.org \
--cc=vivek.kasireddy@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).