-----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 <redacted>; virtualization@lists.linux-foundation.org; dri-
devel@lists.freedesktop.org; Vetter, Daniel [off-list ref];
daniel.vetter@ffwll.ch; Kim, Dongwon [off-list ref];
sumit.semwal@linaro.org; christian.koenig@amd.com; linux-media@vger.kernel.org
Subject: Re: [RFC v3 2/3] virtio: Introduce Vdmabuf driver
Hi,
quoted
quoted
quoted
quoted
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?
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?
quoted
[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.
quoted
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
From: Christian König <christian.koenig@amd.com> Date: 2021-02-10 08:06:51
Hi Vivek,
Am 10.02.21 um 05:47 schrieb Kasireddy, Vivek:
Hi Gerd,
quoted
-----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 <redacted>; virtualization@lists.linux-foundation.org; dri-
devel@lists.freedesktop.org; Vetter, Daniel [off-list ref];
daniel.vetter@ffwll.ch; Kim, Dongwon [off-list ref];
sumit.semwal@linaro.org; christian.koenig@amd.com; linux-media@vger.kernel.org
Subject: Re: [RFC v3 2/3] virtio: Introduce Vdmabuf driver
Hi,
quoted
quoted
quoted
quoted
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.
quoted
quoted
[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.
quoted
quoted
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
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?
Hmm, why a big mode switch? You should be able to do that without
modifying the virtio-gpu guest driver. On the host side qemu needs
some work to support the most recent virtio-gpu features like the
buffer uuids (assuming you use qemu userspace), right now those
are only supported by crosvm.
It might be useful to add support for display-less virtio-gpu, i.e.
"qemu -device virtio-gpu-pci,max_outputs=0". Right now the linux
driver throws an error in case no output (crtc) is present. Should
be fixable without too much effort though, effectively the sanity
check would have to be moved from driver initialization to commands
like SET_SCANOUT which manage the outputs.
take care,
Gerd
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
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] Just to confirm my understanding of what you are suggesting, are
you saying that we need to either have Weston allocate scanout buffers (GBM surface/BO)
using virtio-gpu and render into them using i915; or have virtio-gpu allocate pages and
export a dma-buf and have Weston create a GBM BO by calling gbm_bo_import(fd) and
render into the BO using i915?
Hmm, why a big mode switch? You should be able to do that without modifying the
virtio-gpu guest driver. On the host side qemu needs some work to support the most
recent virtio-gpu features like the buffer uuids (assuming you use qemu userspace), right
now those are only supported by crosvm.
[Kasireddy, Vivek] We are only interested in Qemu UI at the moment but if we were to use
virtio-gpu, we are going to need to add one more vq and support for managing buffers,
events, etc.
Thanks,
Vivek
It might be useful to add support for display-less virtio-gpu, i.e.
"qemu -device virtio-gpu-pci,max_outputs=0". Right now the linux driver throws an error
in case no output (crtc) is present. Should be fixable without too much effort though,
effectively the sanity check would have to be moved from driver initialization to
commands like SET_SCANOUT which manage the outputs.
take care,
Gerd
[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.
quoted
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.
[Kasireddy, Vivek] What is your recommended/acceptable way for doing what I am trying to
do?
Thanks,
Vivek
From: Christian König <christian.koenig@amd.com> Date: 2021-02-12 08:48:52
Hi Vivek,
Am 12.02.21 um 09:36 schrieb Kasireddy, Vivek:
Hi Christian,
quoted
Hi Vivek,
quoted
[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.
quoted
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.
[Kasireddy, Vivek] What is your recommended/acceptable way for doing what I am trying to
do?
I'm not an expert on virtualisation, but Gerd seems to have a couple of
ideas of how to get this working.
In general I think it is pretty much impossible to export stuff from the
guest to the host by DMA-buf.
This is because of the fundamental concept of DMA-buf that the exporter
needs to setup mappings (both CPU page tables as well as stuff like
IOMMU). When the guest exports something it would mean that you give the
guest control over the IOMMU and/or host page tables. And that is not
something you can do as far as I can see.
You can only export stuff the other way around so that the host is
providing the memory and the guest is consuming it. If I understand it
correctly that's exactly what Gerd is suggesting here.
Regards,
Christian.
This is because of the fundamental concept of DMA-buf that the exporter
needs to setup mappings (both CPU page tables as well as stuff like IOMMU).
When the guest exports something it would mean that you give the guest
control over the IOMMU and/or host page tables. And that is not something
you can do as far as I can see.
Correct.
You can only export stuff the other way around so that the host is providing
the memory and the guest is consuming it. If I understand it correctly
that's exactly what Gerd is suggesting here.
It can also work the other way around (guest allocating and host
consuming). That is just an implementation detail. The /important/
thing is that the driver which exports the dma-buf (and thus handles the
mappings) must be aware of the virtualization so it can properly
coordinate things with the host side.
So vdmabuf allocating and exporting dma-bufs works.
But vdmabuf importing dma-bufs doesn't because you can't ask the
exporter to create *host* mappings as Christian outlined above. Sure,
you can try to sidestep the exporter, fish the list of pages out of the
scatter list and run with that. That will explode as soon as you meet a
dma-buf which is not backed by pages in the first place. And even for
page-backed dma-bufs you can run into trouble, for example due to
mapping pages with the wrong caching attributes. Alternatively you can
double-buffer and copy data from the imported dma-buf to some
host-shared memory, but I guess you don't want that for performance
reasons ...
take care,
Gerd
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Fri, Feb 12, 2021 at 08:15:12AM +0000, Kasireddy, Vivek wrote:
Hi Gerd,
quoted
quoted
quoted
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] Just to confirm my understanding of what you are suggesting, are
you saying that we need to either have Weston allocate scanout buffers (GBM surface/BO)
using virtio-gpu and render into them using i915; or have virtio-gpu allocate pages and
export a dma-buf and have Weston create a GBM BO by calling gbm_bo_import(fd) and
render into the BO using i915?
Not sure what the difference between the former and the latter is.
quoted
Hmm, why a big mode switch? You should be able to do that without modifying the
virtio-gpu guest driver. On the host side qemu needs some work to support the most
recent virtio-gpu features like the buffer uuids (assuming you use qemu userspace), right
now those are only supported by crosvm.
[Kasireddy, Vivek] We are only interested in Qemu UI at the moment but if we were to use
virtio-gpu, we are going to need to add one more vq and support for managing buffers,
events, etc.
Should be easy and it should not need any virtio-gpu driver changes.
You can use virtio-gpu like a dumb scanout device. Create a dumb
bo, create a framebuffer for the bo, map the framebuffer to the crtc.
Then export the bo, import into i915, use it as render target. When
rendering is done flush (DRM_IOCTL_MODE_DIRTYFB). Alternatively
allocate multiple bo's + framebuffers and pageflip.
Pretty standard workflow for cases where rendering and scanout are
handled by different devices. As far I know not uncommon in the arm
world.
Right now this will involve a memcpy() for any display update because
qemu is a bit behind on supporting recent virtio-gpu features.
take care,
Gerd
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
On Fri, Feb 12, 2021 at 08:15:12AM +0000, Kasireddy, Vivek wrote:
quoted
Hi Gerd,
[Kasireddy, Vivek] Just to confirm my understanding of what you are
suggesting, are you saying that we need to either have Weston allocate
scanout buffers (GBM surface/BO) using virtio-gpu and render into them
using i915; or have virtio-gpu allocate pages and export a dma-buf and
have Weston create a GBM BO by calling gbm_bo_import(fd) and render into the BO
using i915?
Not sure what the difference between the former and the latter is.
[Kasireddy, Vivek] Oh, what I meant is whether you were suggesting that we
create a GBM device and create a GBM surface and BOs using this device or
just create a raw/dumb GEM object and create a GBM BO by importing it. As
we just discovered, the former means we have to initialize virgl which complicates
things so we went with the latter.
quoted
[Kasireddy, Vivek] We are only interested in Qemu UI at the moment but
if we were to use virtio-gpu, we are going to need to add one more vq
and support for managing buffers, events, etc.
Should be easy and it should not need any virtio-gpu driver changes.
You can use virtio-gpu like a dumb scanout device. Create a dumb bo, create a
framebuffer for the bo, map the framebuffer to the crtc.
Then export the bo, import into i915, use it as render target. When rendering is done flush
(DRM_IOCTL_MODE_DIRTYFB). Alternatively allocate multiple bo's + framebuffers
and pageflip.
[Kasireddy, Vivek] Since we are testing with Weston, we are looking at pageflips (4 color
buffers). And, this part so far seems to work where virtio-gpu is used for kms (max_outputs=1)
and Iris/i915 is used for rendering. We are currently glueing virtio-gpu and i915 in Weston but
eventually the plan is to glue them (virgl/virtio-gpu and Iris) in Mesa if possible using KMSRO
(KMS render only) to avoid having to change Weston or X or other user-space components.
Pretty standard workflow for cases where rendering and scanout are handled by different
devices. As far I know not uncommon in the arm world.
Right now this will involve a memcpy() for any display update because qemu is a bit
behind on supporting recent virtio-gpu features.
[Kasireddy, Vivek] IIUC, I think you are referring to creating the Pixman image in set_scanout.
What additional features need to be implemented or what is your recommendation in terms of
what needs to be done to turn the memcpy() into a dma-buf? Also, how should we ensure that
access to the guest fb/dmabuf is synchronized to ensure that the Guest and the Host do not access
the backing storage of the dmabuf at the same time?
Thanks,
Vivek
From: Zhang, Tina <hidden> Date: 2021-03-15 02:28:34
-----Original Message-----
From: dri-devel <redacted> On Behalf Of Gerd
Hoffmann
Sent: Friday, February 12, 2021 7:02 PM
To: Kasireddy, Vivek <vivek.kasireddy@intel.com>
Cc: Kim, Dongwon <redacted>; christian.koenig@amd.com;
daniel.vetter@ffwll.ch; dri-devel@lists.freedesktop.org;
virtualization@lists.linux-foundation.org; Vetter, Daniel
[off-list ref]; linux-media@vger.kernel.org
Subject: Re: [RFC v3 2/3] virtio: Introduce Vdmabuf driver
On Fri, Feb 12, 2021 at 08:15:12AM +0000, Kasireddy, Vivek wrote:
quoted
Hi Gerd,
quoted
quoted
quoted
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] Just to confirm my understanding of what you are
suggesting, are you saying that we need to either have Weston allocate
scanout buffers (GBM surface/BO) using virtio-gpu and render into them
using i915; or have virtio-gpu allocate pages and export a dma-buf and
have Weston create a GBM BO by calling gbm_bo_import(fd) and render into
the BO using i915?
Not sure what the difference between the former and the latter is.
quoted
quoted
Hmm, why a big mode switch? You should be able to do that without
modifying the virtio-gpu guest driver. On the host side qemu needs
some work to support the most recent virtio-gpu features like the
buffer uuids (assuming you use qemu userspace), right now those are only
supported by crosvm.
quoted
[Kasireddy, Vivek] We are only interested in Qemu UI at the moment but
if we were to use virtio-gpu, we are going to need to add one more vq
and support for managing buffers, events, etc.
Should be easy and it should not need any virtio-gpu driver changes.
You can use virtio-gpu like a dumb scanout device. Create a dumb bo, create a
framebuffer for the bo, map the framebuffer to the crtc.
Then export the bo, import into i915, use it as render target. When rendering is
done flush (DRM_IOCTL_MODE_DIRTYFB). Alternatively allocate multiple bo's +
framebuffers and pageflip.
Pretty standard workflow for cases where rendering and scanout are handled by
different devices. As far I know not uncommon in the arm world.
Right now this will involve a memcpy() for any display update because qemu is a
bit behind on supporting recent virtio-gpu features.
take care,
Gerd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel