Hi,
> btw some questions here:
>
> for non-gl and gl rendering in Qemu, are they based on dma-buf already?
> once we can export guest framebuffer in dma-buf, is there additional work
> required or just straightforward to integrate with SPICE?
Right now we are busy integrating dma-buf support
Hi,
> btw some questions here:
>
> for non-gl and gl rendering in Qemu, are they based on dma-buf already?
> once we can export guest framebuffer in dma-buf, is there additional work
> required or just straightforward to integrate with SPICE?
Right now we are busy integrating dma-buf support
> From: Tian, Kevin
> Sent: Friday, November 20, 2015 4:36 PM
>
> >
> > > > So, for non-opengl rendering qemu needs the guest framebuffer data so it
> > > > can feed it into the vnc server. The vfio framebuffer region is meant
> > > > to support this use case.
> > >
> > > what's the format
> From: Tian, Kevin
> Sent: Friday, November 20, 2015 4:36 PM
>
> >
> > > > So, for non-opengl rendering qemu needs the guest framebuffer data so it
> > > > can feed it into the vnc server. The vfio framebuffer region is meant
> > > > to support this use case.
> > >
> > > what's the format
On Tue, Nov 24, 2015 at 03:12:31PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > But there's some work to add generic mmap support to dma-bufs, and for
> > really simple case (where we don't have a gl driver to handle the dma-buf
> > specially) for untiled framebuffers that would be all we need?
>
>
Hi,
> But there's some work to add generic mmap support to dma-bufs, and for
> really simple case (where we don't have a gl driver to handle the dma-buf
> specially) for untiled framebuffers that would be all we need?
Not requiring gl is certainly a bonus, people might want build qemu
without
On Tue, Nov 24, 2015 at 01:38:55PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > Yes, vGPU may have additional features, like a framebuffer area, that
> > > aren't present or optional for direct assignment. Obviously we support
> > > direct assignment of GPUs for some vendors already without this
Hi,
> > Yes, vGPU may have additional features, like a framebuffer area, that
> > aren't present or optional for direct assignment. Obviously we support
> > direct assignment of GPUs for some vendors already without this feature.
>
> For exposing framebuffers for spice/vnc I highly recommend
On Tue, Nov 24, 2015 at 12:19:18PM +0100, Daniel Vetter wrote:
> Downside: Tracking mapping changes on the guest side won't be any easier.
> This is mostly a problem for integrated gpus, since discrete ones usually
> require contiguous vram for scanout. I think saying "don't do that" is a
> valid
On Thu, Nov 19, 2015 at 01:02:36PM -0700, Alex Williamson wrote:
> On Thu, 2015-11-19 at 04:06 +, Tian, Kevin wrote:
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Thursday, November 19, 2015 2:12 AM
> > >
> > > [cc +qemu-devel, +paolo, +gerd]
> > >
> > > Another
Hi,
> But there's some work to add generic mmap support to dma-bufs, and for
> really simple case (where we don't have a gl driver to handle the dma-buf
> specially) for untiled framebuffers that would be all we need?
Not requiring gl is certainly a bonus, people might want build qemu
without
On Tue, Nov 24, 2015 at 03:12:31PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > But there's some work to add generic mmap support to dma-bufs, and for
> > really simple case (where we don't have a gl driver to handle the dma-buf
> > specially) for untiled framebuffers that would be all we need?
>
>
On Thu, Nov 19, 2015 at 01:02:36PM -0700, Alex Williamson wrote:
> On Thu, 2015-11-19 at 04:06 +, Tian, Kevin wrote:
> > > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > > Sent: Thursday, November 19, 2015 2:12 AM
> > >
> > > [cc +qemu-devel, +paolo, +gerd]
> > >
> > > Another
Hi,
> > Yes, vGPU may have additional features, like a framebuffer area, that
> > aren't present or optional for direct assignment. Obviously we support
> > direct assignment of GPUs for some vendors already without this feature.
>
> For exposing framebuffers for spice/vnc I highly recommend
On Tue, Nov 24, 2015 at 12:19:18PM +0100, Daniel Vetter wrote:
> Downside: Tracking mapping changes on the guest side won't be any easier.
> This is mostly a problem for integrated gpus, since discrete ones usually
> require contiguous vram for scanout. I think saying "don't do that" is a
> valid
On Tue, Nov 24, 2015 at 01:38:55PM +0100, Gerd Hoffmann wrote:
> Hi,
>
> > > Yes, vGPU may have additional features, like a framebuffer area, that
> > > aren't present or optional for direct assignment. Obviously we support
> > > direct assignment of GPUs for some vendors already without this
On 11/21/2015 01:25 AM, Alex Williamson wrote:
On Fri, 2015-11-20 at 08:10 +, Tian, Kevin wrote:
Here is a more concrete example:
KVMGT doesn't require IOMMU. All DMA targets are already replaced with
HPA thru shadow GTT. So DMA requests from GPU all contain HPAs.
When IOMMU is enabled,
On 11/21/2015 01:25 AM, Alex Williamson wrote:
On Fri, 2015-11-20 at 08:10 +, Tian, Kevin wrote:
Here is a more concrete example:
KVMGT doesn't require IOMMU. All DMA targets are already replaced with
HPA thru shadow GTT. So DMA requests from GPU all contain HPAs.
When IOMMU is enabled,
On Fri, 2015-11-20 at 08:10 +, Tian, Kevin wrote:
> > From: Tian, Kevin
> > Sent: Friday, November 20, 2015 3:10 PM
>
> > > > >
> > > > > The proposal is therefore that GPU vendors can expose vGPUs to
> > > > > userspace, and thus to QEMU, using the VFIO API. For instance, vfio
> > > > >
On Fri, 2015-11-20 at 07:09 +, Tian, Kevin wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Friday, November 20, 2015 4:03 AM
> >
> > > >
> > > > The proposal is therefore that GPU vendors can expose vGPUs to
> > > > userspace, and thus to QEMU, using the VFIO
On Fri, 2015-11-20 at 13:51 +0800, Jike Song wrote:
> On 11/20/2015 12:22 PM, Alex Williamson wrote:
> > On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
> >> On 11/19/2015 11:52 PM, Alex Williamson wrote:
> >>> On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
> On Thu, 19 Nov
On Fri, Nov 20, 2015 at 04:36:15PM +0800, Tian, Kevin wrote:
> > From: Gerd Hoffmann [mailto:kra...@redhat.com]
> > Sent: Friday, November 20, 2015 4:26 PM
> >
> > Hi,
> >
> > > > iGVT-g_Setup_Guide.txt mentions a "Indirect Display Mode", but doesn't
> > > > explain how the guest framebuffer
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Friday, November 20, 2015 4:26 PM
>
> Hi,
>
> > > iGVT-g_Setup_Guide.txt mentions a "Indirect Display Mode", but doesn't
> > > explain how the guest framebuffer can be accessed then.
> >
> > You can check "fb_decoder.h". One thing to
Hi,
> > iGVT-g_Setup_Guide.txt mentions a "Indirect Display Mode", but doesn't
> > explain how the guest framebuffer can be accessed then.
>
> You can check "fb_decoder.h". One thing to clarify. Its format is
> actually based on drm definition, instead of OpenGL. Sorry for
> that.
drm is
> From: Tian, Kevin
> Sent: Friday, November 20, 2015 3:10 PM
> > > >
> > > > The proposal is therefore that GPU vendors can expose vGPUs to
> > > > userspace, and thus to QEMU, using the VFIO API. For instance, vfio
> > > > supports modular bus drivers and IOMMU drivers. An intel-vfio-gvt-d
>
On Fri, 2015-11-20 at 13:51 +0800, Jike Song wrote:
> On 11/20/2015 12:22 PM, Alex Williamson wrote:
> > On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
> >> On 11/19/2015 11:52 PM, Alex Williamson wrote:
> >>> On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
> On Thu, 19 Nov
On Fri, 2015-11-20 at 07:09 +, Tian, Kevin wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Friday, November 20, 2015 4:03 AM
> >
> > > >
> > > > The proposal is therefore that GPU vendors can expose vGPUs to
> > > > userspace, and thus to QEMU, using the VFIO
On Fri, 2015-11-20 at 08:10 +, Tian, Kevin wrote:
> > From: Tian, Kevin
> > Sent: Friday, November 20, 2015 3:10 PM
>
> > > > >
> > > > > The proposal is therefore that GPU vendors can expose vGPUs to
> > > > > userspace, and thus to QEMU, using the VFIO API. For instance, vfio
> > > > >
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Friday, November 20, 2015 4:26 PM
>
> Hi,
>
> > > iGVT-g_Setup_Guide.txt mentions a "Indirect Display Mode", but doesn't
> > > explain how the guest framebuffer can be accessed then.
> >
> > You can check "fb_decoder.h". One thing to
On Fri, Nov 20, 2015 at 04:36:15PM +0800, Tian, Kevin wrote:
> > From: Gerd Hoffmann [mailto:kra...@redhat.com]
> > Sent: Friday, November 20, 2015 4:26 PM
> >
> > Hi,
> >
> > > > iGVT-g_Setup_Guide.txt mentions a "Indirect Display Mode", but doesn't
> > > > explain how the guest framebuffer
> From: Tian, Kevin
> Sent: Friday, November 20, 2015 3:10 PM
> > > >
> > > > The proposal is therefore that GPU vendors can expose vGPUs to
> > > > userspace, and thus to QEMU, using the VFIO API. For instance, vfio
> > > > supports modular bus drivers and IOMMU drivers. An intel-vfio-gvt-d
>
Hi,
> > iGVT-g_Setup_Guide.txt mentions a "Indirect Display Mode", but doesn't
> > explain how the guest framebuffer can be accessed then.
>
> You can check "fb_decoder.h". One thing to clarify. Its format is
> actually based on drm definition, instead of OpenGL. Sorry for
> that.
drm is
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, November 20, 2015 4:03 AM
>
> > >
> > > The proposal is therefore that GPU vendors can expose vGPUs to
> > > userspace, and thus to QEMU, using the VFIO API. For instance, vfio
> > > supports modular bus drivers and
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Thursday, November 19, 2015 4:41 PM
>
> Hi,
>
> > > Another area of extension is how to expose a framebuffer to QEMU for
> > > seamless integration into a SPICE/VNC channel. For this I believe we
> > > could use a new region, much like
> From: Song, Jike
> Sent: Friday, November 20, 2015 1:52 PM
>
> On 11/20/2015 12:22 PM, Alex Williamson wrote:
> > On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
> >> On 11/19/2015 11:52 PM, Alex Williamson wrote:
> >>> On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
> On
On 11/20/2015 12:22 PM, Alex Williamson wrote:
On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
On 11/19/2015 11:52 PM, Alex Williamson wrote:
On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
On Thu, 19 Nov 2015, Jike Song wrote:
Hi Alex, thanks for the discussion.
In
On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
> On 11/19/2015 11:52 PM, Alex Williamson wrote:
> > On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
> >> On Thu, 19 Nov 2015, Jike Song wrote:
> >>> Hi Alex, thanks for the discussion.
> >>>
> >>> In addition to Kevin's replies, I
On 11/19/2015 11:52 PM, Alex Williamson wrote:
On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
On Thu, 19 Nov 2015, Jike Song wrote:
Hi Alex, thanks for the discussion.
In addition to Kevin's replies, I have a high-level question: can VFIO
be used by QEMU for both KVM and Xen?
On 11/19/2015 07:09 PM, Paolo Bonzini wrote:
On 19/11/2015 09:40, Gerd Hoffmann wrote:
But this code should be
minor to be maintained in libvirt.
As far I know libvirt only needs to discover those devices. If they
look like sr/iov devices in sysfs this might work without any changes to
Hi Kevin,
On Thu, 2015-11-19 at 04:06 +, Tian, Kevin wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Thursday, November 19, 2015 2:12 AM
> >
> > [cc +qemu-devel, +paolo, +gerd]
> >
> > On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
> > > Hi all,
> > >
> >
On Thu, 19 Nov 2015, Paolo Bonzini wrote:
> On 19/11/2015 16:32, Stefano Stabellini wrote:
> > > In addition to Kevin's replies, I have a high-level question: can VFIO
> > > be used by QEMU for both KVM and Xen?
> >
> > No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU
> > is
On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
> On Thu, 19 Nov 2015, Jike Song wrote:
> > Hi Alex, thanks for the discussion.
> >
> > In addition to Kevin's replies, I have a high-level question: can VFIO
> > be used by QEMU for both KVM and Xen?
>
> No. VFIO cannot be used with
On 19/11/2015 16:32, Stefano Stabellini wrote:
> > In addition to Kevin's replies, I have a high-level question: can VFIO
> > be used by QEMU for both KVM and Xen?
>
> No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU
> is owned by Xen.
I don't think QEMU command line
On Thu, 19 Nov 2015, Jike Song wrote:
> Hi Alex, thanks for the discussion.
>
> In addition to Kevin's replies, I have a high-level question: can VFIO
> be used by QEMU for both KVM and Xen?
No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU
is owned by Xen.
--
To unsubscribe
On 19/11/2015 09:40, Gerd Hoffmann wrote:
>> > But this code should be
>> > minor to be maintained in libvirt.
> As far I know libvirt only needs to discover those devices. If they
> look like sr/iov devices in sysfs this might work without any changes to
> libvirt.
I don't think they will
Hi,
> > Another area of extension is how to expose a framebuffer to QEMU for
> > seamless integration into a SPICE/VNC channel. For this I believe we
> > could use a new region, much like we've done to expose VGA access
> > through a vfio device file descriptor. An area within this new
> >
Hi,
> > Another area of extension is how to expose a framebuffer to QEMU for
> > seamless integration into a SPICE/VNC channel. For this I believe we
> > could use a new region, much like we've done to expose VGA access
> > through a vfio device file descriptor. An area within this new
> >
Hi Kevin,
On Thu, 2015-11-19 at 04:06 +, Tian, Kevin wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Thursday, November 19, 2015 2:12 AM
> >
> > [cc +qemu-devel, +paolo, +gerd]
> >
> > On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
> > > Hi all,
> > >
> >
On 19/11/2015 09:40, Gerd Hoffmann wrote:
>> > But this code should be
>> > minor to be maintained in libvirt.
> As far I know libvirt only needs to discover those devices. If they
> look like sr/iov devices in sysfs this might work without any changes to
> libvirt.
I don't think they will
On 11/19/2015 11:52 PM, Alex Williamson wrote:
On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
On Thu, 19 Nov 2015, Jike Song wrote:
Hi Alex, thanks for the discussion.
In addition to Kevin's replies, I have a high-level question: can VFIO
be used by QEMU for both KVM and Xen?
On 11/19/2015 07:09 PM, Paolo Bonzini wrote:
On 19/11/2015 09:40, Gerd Hoffmann wrote:
But this code should be
minor to be maintained in libvirt.
As far I know libvirt only needs to discover those devices. If they
look like sr/iov devices in sysfs this might work without any changes to
On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
> On 11/19/2015 11:52 PM, Alex Williamson wrote:
> > On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
> >> On Thu, 19 Nov 2015, Jike Song wrote:
> >>> Hi Alex, thanks for the discussion.
> >>>
> >>> In addition to Kevin's replies, I
On 11/20/2015 12:22 PM, Alex Williamson wrote:
On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
On 11/19/2015 11:52 PM, Alex Williamson wrote:
On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
On Thu, 19 Nov 2015, Jike Song wrote:
Hi Alex, thanks for the discussion.
In
On Thu, 19 Nov 2015, Paolo Bonzini wrote:
> On 19/11/2015 16:32, Stefano Stabellini wrote:
> > > In addition to Kevin's replies, I have a high-level question: can VFIO
> > > be used by QEMU for both KVM and Xen?
> >
> > No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU
> > is
> From: Song, Jike
> Sent: Friday, November 20, 2015 1:52 PM
>
> On 11/20/2015 12:22 PM, Alex Williamson wrote:
> > On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
> >> On 11/19/2015 11:52 PM, Alex Williamson wrote:
> >>> On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
> On
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Thursday, November 19, 2015 4:41 PM
>
> Hi,
>
> > > Another area of extension is how to expose a framebuffer to QEMU for
> > > seamless integration into a SPICE/VNC channel. For this I believe we
> > > could use a new region, much like
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, November 20, 2015 4:03 AM
>
> > >
> > > The proposal is therefore that GPU vendors can expose vGPUs to
> > > userspace, and thus to QEMU, using the VFIO API. For instance, vfio
> > > supports modular bus drivers and
On 19/11/2015 16:32, Stefano Stabellini wrote:
> > In addition to Kevin's replies, I have a high-level question: can VFIO
> > be used by QEMU for both KVM and Xen?
>
> No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU
> is owned by Xen.
I don't think QEMU command line
On Thu, 19 Nov 2015, Jike Song wrote:
> Hi Alex, thanks for the discussion.
>
> In addition to Kevin's replies, I have a high-level question: can VFIO
> be used by QEMU for both KVM and Xen?
No. VFIO cannot be used with Xen today. When running on Xen, the IOMMU
is owned by Xen.
--
To unsubscribe
On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
> On Thu, 19 Nov 2015, Jike Song wrote:
> > Hi Alex, thanks for the discussion.
> >
> > In addition to Kevin's replies, I have a high-level question: can VFIO
> > be used by QEMU for both KVM and Xen?
>
> No. VFIO cannot be used with
Hi Alex,
On 11/19/2015 12:06 PM, Tian, Kevin wrote:
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Thursday, November 19, 2015 2:12 AM
[cc +qemu-devel, +paolo, +gerd]
On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
{snip}
Hi!
At redhat we've been thinking about how to
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, November 19, 2015 2:12 AM
>
> [cc +qemu-devel, +paolo, +gerd]
>
> On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
> > Hi all,
> >
> > We are pleased to announce another update of Intel GVT-g for Xen.
> >
> > Intel
[cc +qemu-devel, +paolo, +gerd]
On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
> Hi all,
>
> We are pleased to announce another update of Intel GVT-g for Xen.
>
> Intel GVT-g is a full GPU virtualization solution with mediated
> pass-through, starting from 4th generation Intel Core(TM)
[cc +qemu-devel, +paolo, +gerd]
On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
> Hi all,
>
> We are pleased to announce another update of Intel GVT-g for Xen.
>
> Intel GVT-g is a full GPU virtualization solution with mediated
> pass-through, starting from 4th generation Intel Core(TM)
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Thursday, November 19, 2015 2:12 AM
>
> [cc +qemu-devel, +paolo, +gerd]
>
> On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
> > Hi all,
> >
> > We are pleased to announce another update of Intel GVT-g for Xen.
> >
> > Intel
Hi Alex,
On 11/19/2015 12:06 PM, Tian, Kevin wrote:
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Thursday, November 19, 2015 2:12 AM
[cc +qemu-devel, +paolo, +gerd]
On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
{snip}
Hi!
At redhat we've been thinking about how to
Hi all,
We are pleased to announce another update of Intel GVT-g for Xen.
Intel GVT-g is a full GPU virtualization solution with mediated pass-through,
starting from 4th generation Intel Core(TM) processors with Intel Graphics
processors. A virtual GPU instance is maintained for each VM, with
Hi all,
We are pleased to announce another update of Intel GVT-g for Xen.
Intel GVT-g is a full GPU virtualization solution with mediated pass-through,
starting from 4th generation Intel Core(TM) processors with Intel Graphics
processors. A virtual GPU instance is maintained for each VM, with
68 matches
Mail list logo
