Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1272447 > unrolled thread

Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a  Mediated Graphics Passthrough Solution from Intel Alex Williamson <alex.williamson@redhat.com> - 2015-11-18 19:20 +0100
    RE: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a  Mediated Graphics Passthrough Solution from Intel "Tian, Kevin" <kevin.tian@intel.com> - 2015-11-19 05:10 +0100
      Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated  Graphics Passthrough Solution from Intel Jike Song <jike.song@intel.com> - 2015-11-19 08:30 +0100
        Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated  Graphics Passthrough Solution from Intel Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-11-19 16:40 +0100
          Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a  Mediated Graphics Passthrough Solution from Intel Alex Williamson <alex.williamson@redhat.com> - 2015-11-19 17:00 +0100
            Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated  Graphics Passthrough Solution from Intel Jike Song <jike.song@intel.com> - 2015-11-20 04:00 +0100
              Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a  Mediated Graphics Passthrough Solution from Intel Alex Williamson <alex.williamson@redhat.com> - 2015-11-20 05:30 +0100
                Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated  Graphics Passthrough Solution from Intel Jike Song <jike.song@intel.com> - 2015-11-20 07:00 +0100
                  RE: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a  Mediated Graphics Passthrough Solution from Intel "Tian, Kevin" <kevin.tian@intel.com> - 2015-11-20 07:10 +0100
                  Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a  Mediated Graphics Passthrough Solution from Intel Alex Williamson <alex.williamson@redhat.com> - 2015-11-20 17:50 +0100
                    Re: [Qemu-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT  - a Mediated Graphics Passthrough Solution from Intel Jike Song <jike.song@intel.com> - 2015-11-23 06:00 +0100
          Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated  Graphics Passthrough Solution from Intel Paolo Bonzini <pbonzini@redhat.com> - 2015-11-19 17:00 +0100
            Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated  Graphics Passthrough Solution from Intel Stefano Stabellini <stefano.stabellini@eu.citrix.com> - 2015-11-19 17:20 +0100
      Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a  Mediated Graphics Passthrough Solution from Intel Gerd Hoffmann <kraxel@redhat.com> - 2015-11-19 09:50 +0100
        Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated  Graphics Passthrough Solution from Intel Paolo Bonzini <pbonzini@redhat.com> - 2015-11-19 12:10 +0100
          Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated  Graphics Passthrough Solution from Intel Jike Song <jike.song@intel.com> - 2015-11-20 03:50 +0100
        RE: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a  Mediated Graphics Passthrough Solution from Intel "Tian, Kevin" <kevin.tian@intel.com> - 2015-11-20 07:20 +0100
          Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a  Mediated Graphics Passthrough Solution from Intel Gerd Hoffmann <kraxel@redhat.com> - 2015-11-20 09:30 +0100
            RE: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a  Mediated Graphics Passthrough Solution from Intel "Tian, Kevin" <kevin.tian@intel.com> - 2015-11-20 09:40 +0100
              Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated  Graphics Passthrough Solution from Intel Zhiyuan Lv <zhiyuan.lv@intel.com> - 2015-11-20 10:00 +0100
      Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a  Mediated Graphics Passthrough Solution from Intel Alex Williamson <alex.williamson@redhat.com> - 2015-11-19 21:10 +0100
        RE: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a  Mediated Graphics Passthrough Solution from Intel "Tian, Kevin" <kevin.tian@intel.com> - 2015-11-20 08:20 +0100
          Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a  Mediated Graphics Passthrough Solution from Intel Alex Williamson <alex.williamson@redhat.com> - 2015-11-20 18:10 +0100
        RE: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a  Mediated Graphics Passthrough Solution from Intel "Tian, Kevin" <kevin.tian@intel.com> - 2015-11-20 09:20 +0100
          Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a  Mediated Graphics Passthrough Solution from Intel Alex Williamson <alex.williamson@redhat.com> - 2015-11-20 18:30 +0100
            Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated  Graphics Passthrough Solution from Intel Jike Song <jike.song@intel.com> - 2015-11-23 06:10 +0100
        Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated  Graphics Passthrough Solution from Intel Daniel Vetter <daniel@ffwll.ch> - 2015-11-24 12:20 +0100
          Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated  Graphics Passthrough Solution from Intel Chris Wilson <chris@chris-wilson.co.uk> - 2015-11-24 13:00 +0100
          Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a  Mediated Graphics Passthrough Solution from Intel Gerd Hoffmann <kraxel@redhat.com> - 2015-11-24 13:40 +0100
            Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated  Graphics Passthrough Solution from Intel Daniel Vetter <daniel@ffwll.ch> - 2015-11-24 14:40 +0100
              Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a  Mediated Graphics Passthrough Solution from Intel Gerd Hoffmann <kraxel@redhat.com> - 2015-11-24 15:20 +0100
                Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated  Graphics Passthrough Solution from Intel Daniel Vetter <daniel@ffwll.ch> - 2015-11-24 15:20 +0100

Page 1 of 2  [1] 2  Next page →

#1272447 — Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from 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) processors
> with Intel Graphics processors. A virtual GPU instance is maintained
> for each VM, with part of performance critical resources directly
> assigned. The capability of running native graphics driver inside a
> VM, without hypervisor intervention in performance critical paths,
> achieves a good balance among performance, feature, and sharing
> capability. Xen is currently supported on Intel Processor Graphics
> (a.k.a. XenGT); and the core logic can be easily ported to other
> hypervisors.
> 
> 
> Repositories
> 
>      Kernel: https://github.com/01org/igvtg-kernel (2015q3-3.18.0 branch)
>      Xen: https://github.com/01org/igvtg-xen (2015q3-4.5 branch)
>      Qemu: https://github.com/01org/igvtg-qemu (xengt_public2015q3 branch)
> 
> 
> This update consists of:
> 
>      - XenGT is now merged with KVMGT in unified repositories(kernel and qemu), but currently
>        different branches for qemu.  XenGT and KVMGT share same iGVT-g core logic.

Hi!

At redhat we've been thinking about how to support vGPUs from multiple
vendors in a common way within QEMU.  We want to enable code sharing
between vendors and give new vendors an easy path to add their own
support.  We also have the complication that not all vGPU vendors are as
open source friendly as Intel, so being able to abstract the device
mediation and access outside of QEMU is a big advantage.

The proposal I'd like to make is that a vGPU, whether it is from Intel
or another vendor, is predominantly a PCI(e) device.  We have an
interface in QEMU already for exposing arbitrary PCI devices, vfio-pci.
Currently vfio-pci uses the VFIO API to interact with "physical" devices
and system IOMMUs.  I highlight /physical/ there because some of these
physical devices are SR-IOV VFs, which is somewhat of a fuzzy concept,
somewhere between fixed hardware and a virtual device implemented in
software.  That software just happens to be running on the physical
endpoint.

vGPUs are similar, with the virtual device created at a different point,
host software.  They also rely on different IOMMU constructs, making use
of the MMU capabilities of the GPU (GTTs and such), but really having
similar requirements.

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
module (or extension of i915) can register as a vfio bus driver, create
a struct device per vGPU, create an IOMMU group for that device, and
register that device with the vfio-core.  Since we don't rely on the
system IOMMU for GVT-d vGPU assignment, another vGPU vendor driver (or
extension of the same module) can register a "type1" compliant IOMMU
driver into vfio-core.  From the perspective of QEMU then, all of the
existing vfio-pci code is re-used, QEMU remains largely unaware of any
specifics of the vGPU being assigned, and the only necessary change so
far is how QEMU traverses sysfs to find the device and thus the IOMMU
group leading to the vfio group.

There are a few areas where we know we'll need to extend the VFIO API to
make this work, but it seems like they can all be done generically.  One
is that PCI BARs are described through the VFIO API as regions and each
region has a single flag describing whether mmap (ie. direct mapping) of
that region is possible.  We expect that vGPUs likely need finer
granularity, enabling some areas within a BAR to be trapped and fowarded
as a read or write access for the vGPU-vfio-device module to emulate,
while other regions, like framebuffers or texture regions, are directly
mapped.  I have prototype code to enable this already.

Another area is that we really don't want to proliferate each vGPU
needing a new IOMMU type within vfio.  The existing type1 IOMMU provides
potentially the most simple mapping and unmapping interface possible.
We'd therefore need to allow multiple "type1" IOMMU drivers for vfio,
making type1 be more of an interface specification rather than a single
implementation.  This is a trivial change to make within vfio and one
that I believe is compatible with the existing API.  Note that
implementing a type1-compliant vfio IOMMU does not imply pinning an
mapping every registered page.  A vGPU, with mediated device access, may
use this only to track the current HVA to GPA mappings for a VM.  Only
when a DMA is enabled for the vGPU instance is that HVA pinned and an
HPA to GPA translation programmed into the GPU MMU.

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
framebuffer region could be directly mappable in QEMU while a
non-mappable page, at a standard location with standardized format,
provides a description of framebuffer and potentially even a
communication channel to synchronize framebuffer captures.  This would
be new code for QEMU, but something we could share among all vGPU
implementations.

Another obvious area to be standardized would be how to discover,
create, and destroy vGPU instances.  SR-IOV has a standard mechanism to
create VFs in sysfs and I would propose that vGPU vendors try to
standardize on similar interfaces to enable libvirt to easily discover
the vGPU capabilities of a given GPU and manage the lifecycle of a vGPU
instance.

This is obviously a lot to digest, but I'd certainly be interested in
hearing feedback on this proposal as well as try to clarify anything
I've left out or misrepresented above.  Another benefit to this
mechanism is that direct GPU assignment and vGPU assignment use the same
code within QEMU and same API to the kernel, which should make debugging
and code support between the two easier.  I'd really like to start a
discussion around this proposal, and of course the first open source
implementation of this sort of model will really help to drive the
direction it takes.  Thanks!

Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1272827

PiBGcm9tOiBBbGV4IFdpbGxpYW1zb24gW21haWx0bzphbGV4LndpbGxpYW1zb25AcmVkaGF0LmNv
bV0NCj4gU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDE5LCAyMDE1IDI6MTIgQU0NCj4gDQo+IFtj
YyArcWVtdS1kZXZlbCwgK3Bhb2xvLCArZ2VyZF0NCj4gDQo+IE9uIFR1ZSwgMjAxNS0xMC0yNyBh
dCAxNzoyNSArMDgwMCwgSmlrZSBTb25nIHdyb3RlOg0KPiA+IEhpIGFsbCwNCj4gPg0KPiA+IFdl
IGFyZSBwbGVhc2VkIHRvIGFubm91bmNlIGFub3RoZXIgdXBkYXRlIG9mIEludGVsIEdWVC1nIGZv
ciBYZW4uDQo+ID4NCj4gPiBJbnRlbCBHVlQtZyBpcyBhIGZ1bGwgR1BVIHZpcnR1YWxpemF0aW9u
IHNvbHV0aW9uIHdpdGggbWVkaWF0ZWQNCj4gPiBwYXNzLXRocm91Z2gsIHN0YXJ0aW5nIGZyb20g
NHRoIGdlbmVyYXRpb24gSW50ZWwgQ29yZShUTSkgcHJvY2Vzc29ycw0KPiA+IHdpdGggSW50ZWwg
R3JhcGhpY3MgcHJvY2Vzc29ycy4gQSB2aXJ0dWFsIEdQVSBpbnN0YW5jZSBpcyBtYWludGFpbmVk
DQo+ID4gZm9yIGVhY2ggVk0sIHdpdGggcGFydCBvZiBwZXJmb3JtYW5jZSBjcml0aWNhbCByZXNv
dXJjZXMgZGlyZWN0bHkNCj4gPiBhc3NpZ25lZC4gVGhlIGNhcGFiaWxpdHkgb2YgcnVubmluZyBu
YXRpdmUgZ3JhcGhpY3MgZHJpdmVyIGluc2lkZSBhDQo+ID4gVk0sIHdpdGhvdXQgaHlwZXJ2aXNv
ciBpbnRlcnZlbnRpb24gaW4gcGVyZm9ybWFuY2UgY3JpdGljYWwgcGF0aHMsDQo+ID4gYWNoaWV2
ZXMgYSBnb29kIGJhbGFuY2UgYW1vbmcgcGVyZm9ybWFuY2UsIGZlYXR1cmUsIGFuZCBzaGFyaW5n
DQo+ID4gY2FwYWJpbGl0eS4gWGVuIGlzIGN1cnJlbnRseSBzdXBwb3J0ZWQgb24gSW50ZWwgUHJv
Y2Vzc29yIEdyYXBoaWNzDQo+ID4gKGEuay5hLiBYZW5HVCk7IGFuZCB0aGUgY29yZSBsb2dpYyBj
YW4gYmUgZWFzaWx5IHBvcnRlZCB0byBvdGhlcg0KPiA+IGh5cGVydmlzb3JzLg0KPiA+DQo+ID4N
Cj4gPiBSZXBvc2l0b3JpZXMNCj4gPg0KPiA+ICAgICAgS2VybmVsOiBodHRwczovL2dpdGh1Yi5j
b20vMDFvcmcvaWd2dGcta2VybmVsICgyMDE1cTMtMy4xOC4wIGJyYW5jaCkNCj4gPiAgICAgIFhl
bjogaHR0cHM6Ly9naXRodWIuY29tLzAxb3JnL2lndnRnLXhlbiAoMjAxNXEzLTQuNSBicmFuY2gp
DQo+ID4gICAgICBRZW11OiBodHRwczovL2dpdGh1Yi5jb20vMDFvcmcvaWd2dGctcWVtdSAoeGVu
Z3RfcHVibGljMjAxNXEzIGJyYW5jaCkNCj4gPg0KPiA+DQo+ID4gVGhpcyB1cGRhdGUgY29uc2lz
dHMgb2Y6DQo+ID4NCj4gPiAgICAgIC0gWGVuR1QgaXMgbm93IG1lcmdlZCB3aXRoIEtWTUdUIGlu
IHVuaWZpZWQgcmVwb3NpdG9yaWVzKGtlcm5lbCBhbmQgcWVtdSksIGJ1dA0KPiBjdXJyZW50bHkN
Cj4gPiAgICAgICAgZGlmZmVyZW50IGJyYW5jaGVzIGZvciBxZW11LiAgWGVuR1QgYW5kIEtWTUdU
IHNoYXJlIHNhbWUgaUdWVC1nIGNvcmUgbG9naWMuDQo+IA0KPiBIaSENCj4gDQo+IEF0IHJlZGhh
dCB3ZSd2ZSBiZWVuIHRoaW5raW5nIGFib3V0IGhvdyB0byBzdXBwb3J0IHZHUFVzIGZyb20gbXVs
dGlwbGUNCj4gdmVuZG9ycyBpbiBhIGNvbW1vbiB3YXkgd2l0aGluIFFFTVUuICBXZSB3YW50IHRv
IGVuYWJsZSBjb2RlIHNoYXJpbmcNCj4gYmV0d2VlbiB2ZW5kb3JzIGFuZCBnaXZlIG5ldyB2ZW5k
b3JzIGFuIGVhc3kgcGF0aCB0byBhZGQgdGhlaXIgb3duDQo+IHN1cHBvcnQuICBXZSBhbHNvIGhh
dmUgdGhlIGNvbXBsaWNhdGlvbiB0aGF0IG5vdCBhbGwgdkdQVSB2ZW5kb3JzIGFyZSBhcw0KPiBv
cGVuIHNvdXJjZSBmcmllbmRseSBhcyBJbnRlbCwgc28gYmVpbmcgYWJsZSB0byBhYnN0cmFjdCB0
aGUgZGV2aWNlDQo+IG1lZGlhdGlvbiBhbmQgYWNjZXNzIG91dHNpZGUgb2YgUUVNVSBpcyBhIGJp
ZyBhZHZhbnRhZ2UuDQo+IA0KPiBUaGUgcHJvcG9zYWwgSSdkIGxpa2UgdG8gbWFrZSBpcyB0aGF0
IGEgdkdQVSwgd2hldGhlciBpdCBpcyBmcm9tIEludGVsDQo+IG9yIGFub3RoZXIgdmVuZG9yLCBp
cyBwcmVkb21pbmFudGx5IGEgUENJKGUpIGRldmljZS4gIFdlIGhhdmUgYW4NCj4gaW50ZXJmYWNl
IGluIFFFTVUgYWxyZWFkeSBmb3IgZXhwb3NpbmcgYXJiaXRyYXJ5IFBDSSBkZXZpY2VzLCB2Zmlv
LXBjaS4NCj4gQ3VycmVudGx5IHZmaW8tcGNpIHVzZXMgdGhlIFZGSU8gQVBJIHRvIGludGVyYWN0
IHdpdGggInBoeXNpY2FsIiBkZXZpY2VzDQo+IGFuZCBzeXN0ZW0gSU9NTVVzLiAgSSBoaWdobGln
aHQgL3BoeXNpY2FsLyB0aGVyZSBiZWNhdXNlIHNvbWUgb2YgdGhlc2UNCj4gcGh5c2ljYWwgZGV2
aWNlcyBhcmUgU1ItSU9WIFZGcywgd2hpY2ggaXMgc29tZXdoYXQgb2YgYSBmdXp6eSBjb25jZXB0
LA0KPiBzb21ld2hlcmUgYmV0d2VlbiBmaXhlZCBoYXJkd2FyZSBhbmQgYSB2aXJ0dWFsIGRldmlj
ZSBpbXBsZW1lbnRlZCBpbg0KPiBzb2Z0d2FyZS4gIFRoYXQgc29mdHdhcmUganVzdCBoYXBwZW5z
IHRvIGJlIHJ1bm5pbmcgb24gdGhlIHBoeXNpY2FsDQo+IGVuZHBvaW50Lg0KDQpBZ3JlZS4gDQoN
Ck9uZSBjbGFyaWZpY2F0aW9uIGZvciByZXN0IGRpc2N1c3Npb24sIGlzIHRoYXQgd2UncmUgdGFs
a2luZyBhYm91dCBHVlQtZyB2R1BVIA0KaGVyZSB3aGljaCBpcyBhIHB1cmUgc29mdHdhcmUgR1BV
IHZpcnR1YWxpemF0aW9uIHRlY2huaXF1ZS4gR1ZULWQgKG5vdGUgDQpzb21lIHVzZSBpbiB0aGUg
dGV4dCkgcmVmZXJzIHRvIHBhc3NpbmcgdGhyb3VnaCB0aGUgd2hvbGUgR1BVIG9yIGEgc3BlY2lm
aWMgDQpWRi4gR1ZULWQgYWxyZWFkeSBmYWxscyBpbnRvIGV4aXN0aW5nIFZGSU8gQVBJcyBuaWNl
bHkgKHRob3VnaCBzb21lIG9uLWdvaW5nDQplZmZvcnQgdG8gcmVtb3ZlIEludGVsIHNwZWNpZmlj
IHBsYXRmb3JtIHN0aWNrbmVzcyBmcm9tIGdmeCBkcml2ZXIpLiA6LSkNCg0KPiANCj4gdkdQVXMg
YXJlIHNpbWlsYXIsIHdpdGggdGhlIHZpcnR1YWwgZGV2aWNlIGNyZWF0ZWQgYXQgYSBkaWZmZXJl
bnQgcG9pbnQsDQo+IGhvc3Qgc29mdHdhcmUuICBUaGV5IGFsc28gcmVseSBvbiBkaWZmZXJlbnQg
SU9NTVUgY29uc3RydWN0cywgbWFraW5nIHVzZQ0KPiBvZiB0aGUgTU1VIGNhcGFiaWxpdGllcyBv
ZiB0aGUgR1BVIChHVFRzIGFuZCBzdWNoKSwgYnV0IHJlYWxseSBoYXZpbmcNCj4gc2ltaWxhciBy
ZXF1aXJlbWVudHMuDQoNCk9uZSBpbXBvcnRhbnQgZGlmZmVyZW5jZSBiZXR3ZWVuIHN5c3RlbSBJ
T01NVSBhbmQgR1BVLU1NVSBoZXJlLg0KU3lzdGVtIElPTU1VIGlzIHZlcnkgbXVjaCBhYm91dCB0
cmFuc2xhdGlvbiBmcm9tIGEgRE1BIHRhcmdldA0KKElPVkEgb24gbmF0aXZlLCBvciBHUEEgaW4g
dmlydHVhbGl6YXRpb24gY2FzZSkgdG8gSFBBLiBIb3dldmVyIEdQVQ0KaW50ZXJuYWwgTU1VcyBp
cyB0byB0cmFuc2xhdGUgZnJvbSBHcmFwaGljcyBNZW1vcnkgQWRkcmVzcyAoR01BKQ0KdG8gRE1B
IHRhcmdldCAoSFBBIGlmIHN5c3RlbSBJT01NVSBpcyBkaXNhYmxlZCwgb3IgSU9WQS9HUEEgaWYg
c3lzdGVtDQpJT01NVSBpcyBlbmFibGVkKS4gR01BIGlzIGFuIGludGVybmFsIGFkZHIgc3BhY2Ug
d2l0aGluIEdQVSwgbm90IA0KZXhwb3NlZCB0byBRZW11IGFuZCBmdWxseSBtYW5hZ2VkIGJ5IEdW
VC1nIGRldmljZSBtb2RlbC4gU2luY2UgaXQncyANCm5vdCBhIHN0YW5kYXJkIFBDSSBkZWZpbmVk
IHJlc291cmNlLCB3ZSBkb24ndCBuZWVkIGFic3RyYWN0IHRoaXMgY2FwYWJpbGl0eQ0KaW4gVkZJ
TyBpbnRlcmZhY2UuDQoNCj4gDQo+IFRoZSBwcm9wb3NhbCBpcyB0aGVyZWZvcmUgdGhhdCBHUFUg
dmVuZG9ycyBjYW4gZXhwb3NlIHZHUFVzIHRvDQo+IHVzZXJzcGFjZSwgYW5kIHRodXMgdG8gUUVN
VSwgdXNpbmcgdGhlIFZGSU8gQVBJLiAgRm9yIGluc3RhbmNlLCB2ZmlvDQo+IHN1cHBvcnRzIG1v
ZHVsYXIgYnVzIGRyaXZlcnMgYW5kIElPTU1VIGRyaXZlcnMuICBBbiBpbnRlbC12ZmlvLWd2dC1k
DQo+IG1vZHVsZSAob3IgZXh0ZW5zaW9uIG9mIGk5MTUpIGNhbiByZWdpc3RlciBhcyBhIHZmaW8g
YnVzIGRyaXZlciwgY3JlYXRlDQo+IGEgc3RydWN0IGRldmljZSBwZXIgdkdQVSwgY3JlYXRlIGFu
IElPTU1VIGdyb3VwIGZvciB0aGF0IGRldmljZSwgYW5kDQo+IHJlZ2lzdGVyIHRoYXQgZGV2aWNl
IHdpdGggdGhlIHZmaW8tY29yZS4gIFNpbmNlIHdlIGRvbid0IHJlbHkgb24gdGhlDQo+IHN5c3Rl
bSBJT01NVSBmb3IgR1ZULWQgdkdQVSBhc3NpZ25tZW50LCBhbm90aGVyIHZHUFUgdmVuZG9yIGRy
aXZlciAob3INCj4gZXh0ZW5zaW9uIG9mIHRoZSBzYW1lIG1vZHVsZSkgY2FuIHJlZ2lzdGVyIGEg
InR5cGUxIiBjb21wbGlhbnQgSU9NTVUNCj4gZHJpdmVyIGludG8gdmZpby1jb3JlLiAgRnJvbSB0
aGUgcGVyc3BlY3RpdmUgb2YgUUVNVSB0aGVuLCBhbGwgb2YgdGhlDQo+IGV4aXN0aW5nIHZmaW8t
cGNpIGNvZGUgaXMgcmUtdXNlZCwgUUVNVSByZW1haW5zIGxhcmdlbHkgdW5hd2FyZSBvZiBhbnkN
Cj4gc3BlY2lmaWNzIG9mIHRoZSB2R1BVIGJlaW5nIGFzc2lnbmVkLCBhbmQgdGhlIG9ubHkgbmVj
ZXNzYXJ5IGNoYW5nZSBzbw0KPiBmYXIgaXMgaG93IFFFTVUgdHJhdmVyc2VzIHN5c2ZzIHRvIGZp
bmQgdGhlIGRldmljZSBhbmQgdGh1cyB0aGUgSU9NTVUNCj4gZ3JvdXAgbGVhZGluZyB0byB0aGUg
dmZpbyBncm91cC4NCg0KR1ZULWcgcmVxdWlyZXMgdG8gcGluIGd1ZXN0IG1lbW9yeSBhbmQgcXVl
cnkgR1BBLT5IUEEgaW5mb3JtYXRpb24sDQp1cG9uIHdoaWNoIHNoYWRvdyBHVFRzIHdpbGwgYmUg
dXBkYXRlZCBhY2NvcmRpbmdseSBmcm9tIChHTUEtPkdQQSkNCnRvIChHTUEtPkhQQSkuIFNvIHll
cywgaGVyZSBhIGR1bW15IG9yIHNpbXBsZSAidHlwZTEiIGNvbXBsaWFudCBJT01NVSANCmNhbiBi
ZSBpbnRyb2R1Y2VkIGp1c3QgZm9yIHRoaXMgcmVxdWlyZW1lbnQuDQoNCkhvd2V2ZXIgdGhlcmUn
cyBvbmUgdHJpY2t5IHBvaW50IHdoaWNoIEknbSBub3Qgc3VyZSB3aGV0aGVyIG92ZXJhbGwNClZG
SU8gY29uY2VwdCB3aWxsIGJlIHZpb2xhdGVkLiBHVlQtZyBkb2Vzbid0IHJlcXVpcmUgc3lzdGVt
IElPTU1VDQp0byBmdW5jdGlvbiwgaG93ZXZlciBob3N0IHN5c3RlbSBtYXkgZW5hYmxlIHN5c3Rl
bSBJT01NVSBqdXN0IGZvciANCmhhcmRlbmluZyBwdXJwb3NlLiBUaGlzIG1lYW5zIHR3by1sZXZl
bCB0cmFuc2xhdGlvbnMgZXhpc3RpbmcgKEdNQS0+DQpJT1ZBLT5IUEEpLCBzbyB0aGUgZHVtbXkg
SU9NTVUgZHJpdmVyIGhhcyB0byByZXF1ZXN0IHN5c3RlbSBJT01NVSANCmRyaXZlciB0byBhbGxv
Y2F0ZSBJT1ZBIGZvciBWTXMgYW5kIHRoZW4gc2V0dXAgSU9WQS0+SFBBIG1hcHBpbmcNCmluIElP
TU1VIHBhZ2UgdGFibGUuIEluIHRoaXMgY2FzZSwgbXVsdGlwbGUgVk0ncyB0cmFuc2xhdGlvbnMg
YXJlIA0KbXVsdGlwbGV4ZWQgaW4gb25lIElPTU1VIHBhZ2UgdGFibGUuDQoNCldlIG1pZ2h0IG5l
ZWQgY3JlYXRlIHNvbWUgZ3JvdXAvc3ViLWdyb3VwIG9yIHBhcmVudC9jaGlsZCBjb25jZXB0cw0K
YW1vbmcgdGhvc2UgSU9NTVVzIGZvciB0aG9yb3VnaCBwZXJtaXNzaW9uIGNvbnRyb2wuDQoNCj4g
DQo+IFRoZXJlIGFyZSBhIGZldyBhcmVhcyB3aGVyZSB3ZSBrbm93IHdlJ2xsIG5lZWQgdG8gZXh0
ZW5kIHRoZSBWRklPIEFQSSB0bw0KPiBtYWtlIHRoaXMgd29yaywgYnV0IGl0IHNlZW1zIGxpa2Ug
dGhleSBjYW4gYWxsIGJlIGRvbmUgZ2VuZXJpY2FsbHkuICBPbmUNCj4gaXMgdGhhdCBQQ0kgQkFS
cyBhcmUgZGVzY3JpYmVkIHRocm91Z2ggdGhlIFZGSU8gQVBJIGFzIHJlZ2lvbnMgYW5kIGVhY2gN
Cj4gcmVnaW9uIGhhcyBhIHNpbmdsZSBmbGFnIGRlc2NyaWJpbmcgd2hldGhlciBtbWFwIChpZS4g
ZGlyZWN0IG1hcHBpbmcpIG9mDQo+IHRoYXQgcmVnaW9uIGlzIHBvc3NpYmxlLiAgV2UgZXhwZWN0
IHRoYXQgdkdQVXMgbGlrZWx5IG5lZWQgZmluZXINCj4gZ3JhbnVsYXJpdHksIGVuYWJsaW5nIHNv
bWUgYXJlYXMgd2l0aGluIGEgQkFSIHRvIGJlIHRyYXBwZWQgYW5kIGZvd2FyZGVkDQo+IGFzIGEg
cmVhZCBvciB3cml0ZSBhY2Nlc3MgZm9yIHRoZSB2R1BVLXZmaW8tZGV2aWNlIG1vZHVsZSB0byBl
bXVsYXRlLA0KPiB3aGlsZSBvdGhlciByZWdpb25zLCBsaWtlIGZyYW1lYnVmZmVycyBvciB0ZXh0
dXJlIHJlZ2lvbnMsIGFyZSBkaXJlY3RseQ0KPiBtYXBwZWQuICBJIGhhdmUgcHJvdG90eXBlIGNv
ZGUgdG8gZW5hYmxlIHRoaXMgYWxyZWFkeS4NCg0KWWVzIGluIEdWVC1nIG9uZSBCQVIgcmVzb3Vy
Y2UgbWlnaHQgYmUgcGFydGl0aW9uZWQgYW1vbmcgbXVsdGlwbGUgdkdQVXMuDQpJZiBWRklPIGNh
biBzdXBwb3J0IHN1Y2ggcGFydGlhbCByZXNvdXJjZSBhc3NpZ25tZW50LCBpdCdkIGJlIGdyZWF0
LiBTaW1pbGFyDQpwYXJlbnQvY2hpbGQgY29uY2VwdCBtaWdodCBhbHNvIGJlIHJlcXVpcmVkIGhl
cmUsIHNvIGFueSByZXNvdXJjZSBlbnVtZXJhdGVkIA0Kb24gYSB2R1BVIHNob3VsZG4ndCBicmVh
ayBsaW1pdGF0aW9ucyBlbmZvcmNlZCBvbiB0aGUgcGh5c2ljYWwgZGV2aWNlLg0KDQpPbmUgdW5p
cXVlIHJlcXVpcmVtZW50IGZvciBHVlQtZyBoZXJlLCB0aG91Z2gsIGlzIHRoYXQgdkdQVSBkZXZp
Y2UgbW9kZWwNCm5lZWQgdG8ga25vdyBndWVzdCBCQVIgY29uZmlndXJhdGlvbiBmb3IgcHJvcGVy
IGVtdWxhdGlvbiAoZS5nLiByZWdpc3Rlcg0KSU8gZW11bGF0aW9uIGhhbmRsZXIgdG8gS1ZNKS4g
U2ltaWxhciBpcyBhYm91dCBndWVzdCBNU0kgdmVjdG9yIGZvciB2aXJ0dWFsIA0KaW50ZXJydXB0
IGluamVjdGlvbi4gTm90IHN1cmUgaG93IHRoaXMgY2FuIGJlIGZpdCBpbnRvIGNvbW1vbiBWRklP
IG1vZGVsLiANCkRvZXMgVkZJTyBhbGxvdyB2ZW5kb3Igc3BlY2lmaWMgZXh0ZW5zaW9uIHRvZGF5
Pw0KDQo+IA0KPiBBbm90aGVyIGFyZWEgaXMgdGhhdCB3ZSByZWFsbHkgZG9uJ3Qgd2FudCB0byBw
cm9saWZlcmF0ZSBlYWNoIHZHUFUNCj4gbmVlZGluZyBhIG5ldyBJT01NVSB0eXBlIHdpdGhpbiB2
ZmlvLiAgVGhlIGV4aXN0aW5nIHR5cGUxIElPTU1VIHByb3ZpZGVzDQo+IHBvdGVudGlhbGx5IHRo
ZSBtb3N0IHNpbXBsZSBtYXBwaW5nIGFuZCB1bm1hcHBpbmcgaW50ZXJmYWNlIHBvc3NpYmxlLg0K
PiBXZSdkIHRoZXJlZm9yZSBuZWVkIHRvIGFsbG93IG11bHRpcGxlICJ0eXBlMSIgSU9NTVUgZHJp
dmVycyBmb3IgdmZpbywNCj4gbWFraW5nIHR5cGUxIGJlIG1vcmUgb2YgYW4gaW50ZXJmYWNlIHNw
ZWNpZmljYXRpb24gcmF0aGVyIHRoYW4gYSBzaW5nbGUNCj4gaW1wbGVtZW50YXRpb24uICBUaGlz
IGlzIGEgdHJpdmlhbCBjaGFuZ2UgdG8gbWFrZSB3aXRoaW4gdmZpbyBhbmQgb25lDQo+IHRoYXQg
SSBiZWxpZXZlIGlzIGNvbXBhdGlibGUgd2l0aCB0aGUgZXhpc3RpbmcgQVBJLiAgTm90ZSB0aGF0
DQo+IGltcGxlbWVudGluZyBhIHR5cGUxLWNvbXBsaWFudCB2ZmlvIElPTU1VIGRvZXMgbm90IGlt
cGx5IHBpbm5pbmcgYW4NCj4gbWFwcGluZyBldmVyeSByZWdpc3RlcmVkIHBhZ2UuICBBIHZHUFUs
IHdpdGggbWVkaWF0ZWQgZGV2aWNlIGFjY2VzcywgbWF5DQo+IHVzZSB0aGlzIG9ubHkgdG8gdHJh
Y2sgdGhlIGN1cnJlbnQgSFZBIHRvIEdQQSBtYXBwaW5ncyBmb3IgYSBWTS4gIE9ubHkNCj4gd2hl
biBhIERNQSBpcyBlbmFibGVkIGZvciB0aGUgdkdQVSBpbnN0YW5jZSBpcyB0aGF0IEhWQSBwaW5u
ZWQgYW5kIGFuDQo+IEhQQSB0byBHUEEgdHJhbnNsYXRpb24gcHJvZ3JhbW1lZCBpbnRvIHRoZSBH
UFUgTU1VLg0KPiANCj4gQW5vdGhlciBhcmVhIG9mIGV4dGVuc2lvbiBpcyBob3cgdG8gZXhwb3Nl
IGEgZnJhbWVidWZmZXIgdG8gUUVNVSBmb3INCj4gc2VhbWxlc3MgaW50ZWdyYXRpb24gaW50byBh
IFNQSUNFL1ZOQyBjaGFubmVsLiAgRm9yIHRoaXMgSSBiZWxpZXZlIHdlDQo+IGNvdWxkIHVzZSBh
IG5ldyByZWdpb24sIG11Y2ggbGlrZSB3ZSd2ZSBkb25lIHRvIGV4cG9zZSBWR0EgYWNjZXNzDQo+
IHRocm91Z2ggYSB2ZmlvIGRldmljZSBmaWxlIGRlc2NyaXB0b3IuICBBbiBhcmVhIHdpdGhpbiB0
aGlzIG5ldw0KPiBmcmFtZWJ1ZmZlciByZWdpb24gY291bGQgYmUgZGlyZWN0bHkgbWFwcGFibGUg
aW4gUUVNVSB3aGlsZSBhDQo+IG5vbi1tYXBwYWJsZSBwYWdlLCBhdCBhIHN0YW5kYXJkIGxvY2F0
aW9uIHdpdGggc3RhbmRhcmRpemVkIGZvcm1hdCwNCj4gcHJvdmlkZXMgYSBkZXNjcmlwdGlvbiBv
ZiBmcmFtZWJ1ZmZlciBhbmQgcG90ZW50aWFsbHkgZXZlbiBhDQo+IGNvbW11bmljYXRpb24gY2hh
bm5lbCB0byBzeW5jaHJvbml6ZSBmcmFtZWJ1ZmZlciBjYXB0dXJlcy4gIFRoaXMgd291bGQNCj4g
YmUgbmV3IGNvZGUgZm9yIFFFTVUsIGJ1dCBzb21ldGhpbmcgd2UgY291bGQgc2hhcmUgYW1vbmcg
YWxsIHZHUFUNCj4gaW1wbGVtZW50YXRpb25zLg0KDQpOb3cgR1ZULWcgYWxyZWFkeSBwcm92aWRl
cyBhbiBpbnRlcmZhY2UgdG8gZGVjb2RlIGZyYW1lYnVmZmVyIGluZm9ybWF0aW9uLA0Kdy8gYW4g
YXNzdW1wdGlvbiB0aGF0IHRoZSBmcmFtZWJ1ZmZlciB3aWxsIGJlIGZ1cnRoZXIgY29tcG9zaXRl
ZCBpbnRvIA0KT3BlbkdMIEFQSXMuIFNvIHRoZSBmb3JtYXQgaXMgZGVmaW5lZCBhY2NvcmRpbmcg
dG8gT3BlbkdMIGRlZmluaXRpb24uDQpEb2VzIHRoYXQgbWVldCBTUElDRSByZXF1aXJlbWVudD8N
Cg0KQW5vdGhlciB0aGluZyB0byBiZSBhZGRlZC4gRnJhbWVidWZmZXJzIGFyZSBmcmVxdWVudGx5
IHN3aXRjaGVkIGluDQpyZWFsaXR5LiBTbyBlaXRoZXIgUWVtdSBuZWVkcyB0byBwb2xsIG9yIGEg
bm90aWZpY2F0aW9uIG1lY2hhbmlzbSBpcyByZXF1aXJlZC4NCkFuZCBzaW5jZSBpdCdzIGR5bmFt
aWMsIGhhdmluZyBmcmFtZWJ1ZmZlciBwYWdlIGRpcmVjdGx5IGV4cG9zZWQgaW4gdGhlDQpuZXcg
cmVnaW9uIG1pZ2h0IGJlIHRyaWNreS4gV2UgY2FuIGp1c3QgZXhwb3NlIGZyYW1lYnVmZmVyIGlu
Zm9ybWF0aW9uDQooaW5jbHVkaW5nIGJhc2UsIGZvcm1hdCwgZXRjLikgYW5kIGxldCBRZW11IHRv
IG1hcCBzZXBhcmF0ZWx5IG91dCBvZiBWRklPDQppbnRlcmZhY2UuDQoNCkFuZC4uLiB0aGlzIHdv
cmtzIGZpbmUgd2l0aCB2R1BVIG1vZGVsIHNpbmNlIHNvZnR3YXJlIGtub3dzIGFsbCB0aGUNCmRl
dGFpbCBhYm91dCBmcmFtZWJ1ZmZlci4gSG93ZXZlciBpbiBwYXNzLXRocm91Z2ggY2FzZSwgd2hv
IGRvIHlvdSBleHBlY3QNCnRvIHByb3ZpZGUgdGhhdCBpbmZvcm1hdGlvbj8gSXMgaXQgT0sgdG8g
aW50cm9kdWNlIHZHUFUgc3BlY2lmaWMgQVBJcyBpbg0KVkZJTz8NCg0KPiANCj4gQW5vdGhlciBv
YnZpb3VzIGFyZWEgdG8gYmUgc3RhbmRhcmRpemVkIHdvdWxkIGJlIGhvdyB0byBkaXNjb3ZlciwN
Cj4gY3JlYXRlLCBhbmQgZGVzdHJveSB2R1BVIGluc3RhbmNlcy4gIFNSLUlPViBoYXMgYSBzdGFu
ZGFyZCBtZWNoYW5pc20gdG8NCj4gY3JlYXRlIFZGcyBpbiBzeXNmcyBhbmQgSSB3b3VsZCBwcm9w
b3NlIHRoYXQgdkdQVSB2ZW5kb3JzIHRyeSB0bw0KPiBzdGFuZGFyZGl6ZSBvbiBzaW1pbGFyIGlu
dGVyZmFjZXMgdG8gZW5hYmxlIGxpYnZpcnQgdG8gZWFzaWx5IGRpc2NvdmVyDQo+IHRoZSB2R1BV
IGNhcGFiaWxpdGllcyBvZiBhIGdpdmVuIEdQVSBhbmQgbWFuYWdlIHRoZSBsaWZlY3ljbGUgb2Yg
YSB2R1BVDQo+IGluc3RhbmNlLg0KDQpOb3cgdGhlcmUgaXMgbm8gc3RhbmRhcmQuIFdlIGV4cG9z
ZSB2R1BVIGxpZmUtY3ljbGUgbWdtdC4gQVBJcyB0aHJvdWdoDQpzeXNmcyAodW5kZXIgaTkxNSBu
b2RlKSwgd2hpY2ggaXMgdmVyeSBJbnRlbCBzcGVjaWZpYy4gSW4gcmVhbGl0eSBkaWZmZXJlbnQN
CnZlbmRvcnMgaGF2ZSBxdWl0ZSBkaWZmZXJlbnQgY2FwYWJpbGl0aWVzIGZvciB0aGVpciBvd24g
dkdQVXMsIHNvIG5vdCBzdXJlDQpob3cgc3RhbmRhcmQgd2UgY2FuIGRlZmluZSBzdWNoIGEgbWVj
aGFuaXNtLiBCdXQgdGhpcyBjb2RlIHNob3VsZCBiZQ0KbWlub3IgdG8gYmUgbWFpbnRhaW5lZCBp
biBsaWJ2aXJ0Lg0KDQo+IA0KPiBUaGlzIGlzIG9idmlvdXNseSBhIGxvdCB0byBkaWdlc3QsIGJ1
dCBJJ2QgY2VydGFpbmx5IGJlIGludGVyZXN0ZWQgaW4NCj4gaGVhcmluZyBmZWVkYmFjayBvbiB0
aGlzIHByb3Bvc2FsIGFzIHdlbGwgYXMgdHJ5IHRvIGNsYXJpZnkgYW55dGhpbmcNCj4gSSd2ZSBs
ZWZ0IG91dCBvciBtaXNyZXByZXNlbnRlZCBhYm92ZS4gIEFub3RoZXIgYmVuZWZpdCB0byB0aGlz
DQo+IG1lY2hhbmlzbSBpcyB0aGF0IGRpcmVjdCBHUFUgYXNzaWdubWVudCBhbmQgdkdQVSBhc3Np
Z25tZW50IHVzZSB0aGUgc2FtZQ0KPiBjb2RlIHdpdGhpbiBRRU1VIGFuZCBzYW1lIEFQSSB0byB0
aGUga2VybmVsLCB3aGljaCBzaG91bGQgbWFrZSBkZWJ1Z2dpbmcNCj4gYW5kIGNvZGUgc3VwcG9y
dCBiZXR3ZWVuIHRoZSB0d28gZWFzaWVyLiAgSSdkIHJlYWxseSBsaWtlIHRvIHN0YXJ0IGENCj4g
ZGlzY3Vzc2lvbiBhcm91bmQgdGhpcyBwcm9wb3NhbCwgYW5kIG9mIGNvdXJzZSB0aGUgZmlyc3Qg
b3BlbiBzb3VyY2UNCj4gaW1wbGVtZW50YXRpb24gb2YgdGhpcyBzb3J0IG9mIG1vZGVsIHdpbGwg
cmVhbGx5IGhlbHAgdG8gZHJpdmUgdGhlDQo+IGRpcmVjdGlvbiBpdCB0YWtlcy4gIFRoYW5rcyEN
Cj4gDQoNClRoYW5rcyBmb3Igc3RhcnRpbmcgdGhpcyBkaXNjdXNzaW9uLiBJbnRlbCB3aWxsIGRl
ZmluaXRlbHkgd29yayB3aXRoIA0KY29tbXVuaXR5IG9uIHRoaXMgd29yay4gQmFzZWQgb24gZWFy
bGllciBjb21tZW50cywgSSdtIG5vdCBzdXJlDQp3aGV0aGVyIHdlIGNhbiBleGFjdGx5IHNhbWUg
Y29kZSBmb3IgZGlyZWN0IEdQVSBhc3NpZ25tZW50IGFuZA0KdkdQVSBhc3NpZ25tZW50LCBzaW5j
ZSBldmVuIHdlIGV4dGVuZCBWRklPIHNvbWUgaW50ZXJmYWNlcyBtaWdodA0KYmUgdkdQVSBzcGVj
aWZpYy4gRG9lcyB0aGlzIHdheSBzdGlsbCBhY2hpZXZlIHlvdXIgZW5kIGdvYWw/DQoNClRoYW5r
cw0KS2V2aW4NCg==
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1272893 — Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

Hi Alex,
On 11/19/2015 12:06 PM, Tian, Kevin wrote:
>> From: Alex Williamson [mailto:alex.williamson@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 support vGPUs from multiple
>> vendors in a common way within QEMU.  We want to enable code sharing
>> between vendors and give new vendors an easy path to add their own
>> support.  We also have the complication that not all vGPU vendors are as
>> open source friendly as Intel, so being able to abstract the device
>> mediation and access outside of QEMU is a big advantage.
>>
>> The proposal I'd like to make is that a vGPU, whether it is from Intel
>> or another vendor, is predominantly a PCI(e) device.  We have an
>> interface in QEMU already for exposing arbitrary PCI devices, vfio-pci.
>> Currently vfio-pci uses the VFIO API to interact with "physical" devices
>> and system IOMMUs.  I highlight /physical/ there because some of these
>> physical devices are SR-IOV VFs, which is somewhat of a fuzzy concept,
>> somewhere between fixed hardware and a virtual device implemented in
>> software.  That software just happens to be running on the physical
>> endpoint.
>
> Agree.
>
> One clarification for rest discussion, is that we're talking about GVT-g vGPU
> here which is a pure software GPU virtualization technique. GVT-d (note
> some use in the text) refers to passing through the whole GPU or a specific
> VF. GVT-d already falls into existing VFIO APIs nicely (though some on-going
> effort to remove Intel specific platform stickness from gfx driver). :-)
>

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?

--
Thanks,
Jike

  
>>
>> vGPUs are similar, with the virtual device created at a different point,
>> host software.  They also rely on different IOMMU constructs, making use
>> of the MMU capabilities of the GPU (GTTs and such), but really having
>> similar requirements.
>
> One important difference between system IOMMU and GPU-MMU here.
> System IOMMU is very much about translation from a DMA target
> (IOVA on native, or GPA in virtualization case) to HPA. However GPU
> internal MMUs is to translate from Graphics Memory Address (GMA)
> to DMA target (HPA if system IOMMU is disabled, or IOVA/GPA if system
> IOMMU is enabled). GMA is an internal addr space within GPU, not
> exposed to Qemu and fully managed by GVT-g device model. Since it's
> not a standard PCI defined resource, we don't need abstract this capability
> in VFIO interface.
>
>>
>> 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
>> module (or extension of i915) can register as a vfio bus driver, create
>> a struct device per vGPU, create an IOMMU group for that device, and
>> register that device with the vfio-core.  Since we don't rely on the
>> system IOMMU for GVT-d vGPU assignment, another vGPU vendor driver (or
>> extension of the same module) can register a "type1" compliant IOMMU
>> driver into vfio-core.  From the perspective of QEMU then, all of the
>> existing vfio-pci code is re-used, QEMU remains largely unaware of any
>> specifics of the vGPU being assigned, and the only necessary change so
>> far is how QEMU traverses sysfs to find the device and thus the IOMMU
>> group leading to the vfio group.
>
> GVT-g requires to pin guest memory and query GPA->HPA information,
> upon which shadow GTTs will be updated accordingly from (GMA->GPA)
> to (GMA->HPA). So yes, here a dummy or simple "type1" compliant IOMMU
> can be introduced just for this requirement.
>
> However there's one tricky point which I'm not sure whether overall
> VFIO concept will be violated. GVT-g doesn't require system IOMMU
> to function, however host system may enable system IOMMU just for
> hardening purpose. This means two-level translations existing (GMA->
> IOVA->HPA), so the dummy IOMMU driver has to request system IOMMU
> driver to allocate IOVA for VMs and then setup IOVA->HPA mapping
> in IOMMU page table. In this case, multiple VM's translations are
> multiplexed in one IOMMU page table.
>
> We might need create some group/sub-group or parent/child concepts
> among those IOMMUs for thorough permission control.
>
>>
>> There are a few areas where we know we'll need to extend the VFIO API to
>> make this work, but it seems like they can all be done generically.  One
>> is that PCI BARs are described through the VFIO API as regions and each
>> region has a single flag describing whether mmap (ie. direct mapping) of
>> that region is possible.  We expect that vGPUs likely need finer
>> granularity, enabling some areas within a BAR to be trapped and fowarded
>> as a read or write access for the vGPU-vfio-device module to emulate,
>> while other regions, like framebuffers or texture regions, are directly
>> mapped.  I have prototype code to enable this already.
>
> Yes in GVT-g one BAR resource might be partitioned among multiple vGPUs.
> If VFIO can support such partial resource assignment, it'd be great. Similar
> parent/child concept might also be required here, so any resource enumerated
> on a vGPU shouldn't break limitations enforced on the physical device.
>
> One unique requirement for GVT-g here, though, is that vGPU device model
> need to know guest BAR configuration for proper emulation (e.g. register
> IO emulation handler to KVM). Similar is about guest MSI vector for virtual
> interrupt injection. Not sure how this can be fit into common VFIO model.
> Does VFIO allow vendor specific extension today?
>
>>
>> Another area is that we really don't want to proliferate each vGPU
>> needing a new IOMMU type within vfio.  The existing type1 IOMMU provides
>> potentially the most simple mapping and unmapping interface possible.
>> We'd therefore need to allow multiple "type1" IOMMU drivers for vfio,
>> making type1 be more of an interface specification rather than a single
>> implementation.  This is a trivial change to make within vfio and one
>> that I believe is compatible with the existing API.  Note that
>> implementing a type1-compliant vfio IOMMU does not imply pinning an
>> mapping every registered page.  A vGPU, with mediated device access, may
>> use this only to track the current HVA to GPA mappings for a VM.  Only
>> when a DMA is enabled for the vGPU instance is that HVA pinned and an
>> HPA to GPA translation programmed into the GPU MMU.
>>
>> 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
>> framebuffer region could be directly mappable in QEMU while a
>> non-mappable page, at a standard location with standardized format,
>> provides a description of framebuffer and potentially even a
>> communication channel to synchronize framebuffer captures.  This would
>> be new code for QEMU, but something we could share among all vGPU
>> implementations.
>
> Now GVT-g already provides an interface to decode framebuffer information,
> w/ an assumption that the framebuffer will be further composited into
> OpenGL APIs. So the format is defined according to OpenGL definition.
> Does that meet SPICE requirement?
>
> Another thing to be added. Framebuffers are frequently switched in
> reality. So either Qemu needs to poll or a notification mechanism is required.
> And since it's dynamic, having framebuffer page directly exposed in the
> new region might be tricky. We can just expose framebuffer information
> (including base, format, etc.) and let Qemu to map separately out of VFIO
> interface.
>
> And... this works fine with vGPU model since software knows all the
> detail about framebuffer. However in pass-through case, who do you expect
> to provide that information? Is it OK to introduce vGPU specific APIs in
> VFIO?
>
>>
>> Another obvious area to be standardized would be how to discover,
>> create, and destroy vGPU instances.  SR-IOV has a standard mechanism to
>> create VFs in sysfs and I would propose that vGPU vendors try to
>> standardize on similar interfaces to enable libvirt to easily discover
>> the vGPU capabilities of a given GPU and manage the lifecycle of a vGPU
>> instance.
>
> Now there is no standard. We expose vGPU life-cycle mgmt. APIs through
> sysfs (under i915 node), which is very Intel specific. In reality different
> vendors have quite different capabilities for their own vGPUs, so not sure
> how standard we can define such a mechanism. But this code should be
> minor to be maintained in libvirt.
>
>>
>> This is obviously a lot to digest, but I'd certainly be interested in
>> hearing feedback on this proposal as well as try to clarify anything
>> I've left out or misrepresented above.  Another benefit to this
>> mechanism is that direct GPU assignment and vGPU assignment use the same
>> code within QEMU and same API to the kernel, which should make debugging
>> and code support between the two easier.  I'd really like to start a
>> discussion around this proposal, and of course the first open source
>> implementation of this sort of model will really help to drive the
>> direction it takes.  Thanks!
>>
>
> Thanks for starting this discussion. Intel will definitely work with
> community on this work. Based on earlier comments, I'm not sure
> whether we can exactly same code for direct GPU assignment and
> vGPU assignment, since even we extend VFIO some interfaces might
> be vGPU specific. Does this way still achieve your end goal?
>
> Thanks
> Kevin
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1273222 — Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1273243

On Thu, 2015-11-19 at 15:32 +0000, 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 Xen today. When running on Xen, the IOMMU
> is owned by Xen.

Right, but in this case we're talking about device MMUs, which are owned
by the device driver which I think is running in dom0, right?  This
proposal doesn't require support of the system IOMMU, the dom0 driver
maps IOVA translations just as it would for itself.  We're largely
proposing use of the VFIO API to provide a common interface to expose a
PCI(e) device to QEMU, but what happens in the vGPU vendor device and
IOMMU backends is specific to the device and perhaps even specific to
the hypervisor.  Thanks,

Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1273702 — Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

On 11/19/2015 11:52 PM, Alex Williamson wrote:
> On Thu, 2015-11-19 at 15:32 +0000, 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 Xen today. When running on Xen, the IOMMU
>> is owned by Xen.
>
> Right, but in this case we're talking about device MMUs, which are owned
> by the device driver which I think is running in dom0, right?  This
> proposal doesn't require support of the system IOMMU, the dom0 driver
> maps IOVA translations just as it would for itself.  We're largely
> proposing use of the VFIO API to provide a common interface to expose a
> PCI(e) device to QEMU, but what happens in the vGPU vendor device and
> IOMMU backends is specific to the device and perhaps even specific to
> the hypervisor.  Thanks,

Let me conclude this, and please correct me in case of any misread: the
vGPU interface between kernel and QEMU will be through VFIO, with a new
VFIO backend (instead of the existing type1), for both KVMGT and XenGT?


>
> Alex
>

--
Thanks,
Jike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1273722

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 +0000, 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 Xen today. When running on Xen, the IOMMU
> >> is owned by Xen.
> >
> > Right, but in this case we're talking about device MMUs, which are owned
> > by the device driver which I think is running in dom0, right?  This
> > proposal doesn't require support of the system IOMMU, the dom0 driver
> > maps IOVA translations just as it would for itself.  We're largely
> > proposing use of the VFIO API to provide a common interface to expose a
> > PCI(e) device to QEMU, but what happens in the vGPU vendor device and
> > IOMMU backends is specific to the device and perhaps even specific to
> > the hypervisor.  Thanks,
> 
> Let me conclude this, and please correct me in case of any misread: the
> vGPU interface between kernel and QEMU will be through VFIO, with a new
> VFIO backend (instead of the existing type1), for both KVMGT and XenGT?

My primary concern is KVM and QEMU upstream, the proposal is not
specifically directed at XenGT, but does not exclude it either.  Xen is
welcome to adopt this proposal as well, it simply defines the channel
through which vGPUs are exposed to QEMU as the VFIO API.  The core VFIO
code in the Linux kernel is just as available for use in Xen dom0 as it
is for a KVM host.  VFIO in QEMU certainly knows about some
accelerations for KVM, but these are almost entirely around allowing
eventfd based interrupts to be injected through KVM, which is something
I'm sure Xen could provide as well.  These accelerations are also not
required, VFIO based device assignment in QEMU works with or without
KVM.  Likewise, the VFIO kernel interface knows nothing about KVM and
has no dependencies on it.

There are two components to the VFIO API, one is the type1 compliant
IOMMU interface, which for this proposal is really doing nothing more
than tracking the HVA to GPA mappings for the VM.  This much seems
entirely common regardless of the hypervisor.  The other part is the
device interface.  The lifecycle of the virtual device seems like it
would be entirely shared, as does much of the emulation components of
the device.  When we get to pinning pages, providing direct access to
memory ranges for a VM, and accelerating interrupts, the vGPU drivers
will likely need some per hypervisor branches, but these are areas where
that's true no matter what the interface.  I'm probably over
simplifying, but hopefully not too much, correct me if I'm wrong.

The benefit of course is that aside from some extensions to the API, the
QEMU components are already in place and there's a lot more leverage for
getting both QEMU and libvirt support upstream in being able to support
multiple vendors, perhaps multiple hypervisors, with the same code.
Also, I'm not sure how useful it is, but VFIO is a userspace driver
interface, where here we're predominantly talking about that userspace
driver being QEMU.  It's not limited to that though.  A userspace
compute application could have direct access to a vGPU through this
model.  Thanks,

Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1273739 — Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

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 +0000, 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 Xen today. When running on Xen, the IOMMU
>>>> is owned by Xen.
>>>
>>> Right, but in this case we're talking about device MMUs, which are owned
>>> by the device driver which I think is running in dom0, right?  This
>>> proposal doesn't require support of the system IOMMU, the dom0 driver
>>> maps IOVA translations just as it would for itself.  We're largely
>>> proposing use of the VFIO API to provide a common interface to expose a
>>> PCI(e) device to QEMU, but what happens in the vGPU vendor device and
>>> IOMMU backends is specific to the device and perhaps even specific to
>>> the hypervisor.  Thanks,
>>
>> Let me conclude this, and please correct me in case of any misread: the
>> vGPU interface between kernel and QEMU will be through VFIO, with a new
>> VFIO backend (instead of the existing type1), for both KVMGT and XenGT?
>
> My primary concern is KVM and QEMU upstream, the proposal is not
> specifically directed at XenGT, but does not exclude it either.  Xen is
> welcome to adopt this proposal as well, it simply defines the channel
> through which vGPUs are exposed to QEMU as the VFIO API.  The core VFIO
> code in the Linux kernel is just as available for use in Xen dom0 as it
> is for a KVM host. VFIO in QEMU certainly knows about some
> accelerations for KVM, but these are almost entirely around allowing
> eventfd based interrupts to be injected through KVM, which is something
> I'm sure Xen could provide as well.  These accelerations are also not
> required, VFIO based device assignment in QEMU works with or without
> KVM.  Likewise, the VFIO kernel interface knows nothing about KVM and
> has no dependencies on it.
>
> There are two components to the VFIO API, one is the type1 compliant
> IOMMU interface, which for this proposal is really doing nothing more
> than tracking the HVA to GPA mappings for the VM.  This much seems
> entirely common regardless of the hypervisor.  The other part is the
> device interface.  The lifecycle of the virtual device seems like it
> would be entirely shared, as does much of the emulation components of
> the device.  When we get to pinning pages, providing direct access to
> memory ranges for a VM, and accelerating interrupts, the vGPU drivers
> will likely need some per hypervisor branches, but these are areas where
> that's true no matter what the interface.  I'm probably over
> simplifying, but hopefully not too much, correct me if I'm wrong.
>

Thanks for confirmation. For QEMU/KVM, I totally agree your point; However,
if we take XenGT to consider, it will be a bit more complex: with Xen
hypervisor and Dom0 kernel running in different level, it's not a straight-
forward way for QEMU to do something like mapping a portion of MMIO BAR
via VFIO in Dom0 kernel, instead of calling hypercalls directly.

I don't know if there is a better way to handle this. But I do agree that
channels between kernel and Qemu via VFIO is a good idea, even though we
may have to split KVMGT/XenGT in Qemu a bit.  We are currently working on
moving all of PCI CFG emulation from kernel to Qemu, hopefully we can
release it by end of this year and work with you guys to adjust it for
the agreed method.


> The benefit of course is that aside from some extensions to the API, the
> QEMU components are already in place and there's a lot more leverage for
> getting both QEMU and libvirt support upstream in being able to support
> multiple vendors, perhaps multiple hypervisors, with the same code.
> Also, I'm not sure how useful it is, but VFIO is a userspace driver
> interface, where here we're predominantly talking about that userspace
> driver being QEMU.  It's not limited to that though.  A userspace
> compute application could have direct access to a vGPU through this
> model.  Thanks,


>
> Alex
>
--
Thanks,
Jike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1273742

PiBGcm9tOiBTb25nLCBKaWtlDQo+IFNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMjAsIDIwMTUgMTo1
MiBQTQ0KPiANCj4gT24gMTEvMjAvMjAxNSAxMjoyMiBQTSwgQWxleCBXaWxsaWFtc29uIHdyb3Rl
Og0KPiA+IE9uIEZyaSwgMjAxNS0xMS0yMCBhdCAxMDo1OCArMDgwMCwgSmlrZSBTb25nIHdyb3Rl
Og0KPiA+PiBPbiAxMS8xOS8yMDE1IDExOjUyIFBNLCBBbGV4IFdpbGxpYW1zb24gd3JvdGU6DQo+
ID4+PiBPbiBUaHUsIDIwMTUtMTEtMTkgYXQgMTU6MzIgKzAwMDAsIFN0ZWZhbm8gU3RhYmVsbGlu
aSB3cm90ZToNCj4gPj4+PiBPbiBUaHUsIDE5IE5vdiAyMDE1LCBKaWtlIFNvbmcgd3JvdGU6DQo+
ID4+Pj4+IEhpIEFsZXgsIHRoYW5rcyBmb3IgdGhlIGRpc2N1c3Npb24uDQo+ID4+Pj4+DQo+ID4+
Pj4+IEluIGFkZGl0aW9uIHRvIEtldmluJ3MgcmVwbGllcywgSSBoYXZlIGEgaGlnaC1sZXZlbCBx
dWVzdGlvbjogY2FuIFZGSU8NCj4gPj4+Pj4gYmUgdXNlZCBieSBRRU1VIGZvciBib3RoIEtWTSBh
bmQgWGVuPw0KPiA+Pj4+DQo+ID4+Pj4gTm8uIFZGSU8gY2Fubm90IGJlIHVzZWQgd2l0aCBYZW4g
dG9kYXkuIFdoZW4gcnVubmluZyBvbiBYZW4sIHRoZSBJT01NVQ0KPiA+Pj4+IGlzIG93bmVkIGJ5
IFhlbi4NCj4gPj4+DQo+ID4+PiBSaWdodCwgYnV0IGluIHRoaXMgY2FzZSB3ZSdyZSB0YWxraW5n
IGFib3V0IGRldmljZSBNTVVzLCB3aGljaCBhcmUgb3duZWQNCj4gPj4+IGJ5IHRoZSBkZXZpY2Ug
ZHJpdmVyIHdoaWNoIEkgdGhpbmsgaXMgcnVubmluZyBpbiBkb20wLCByaWdodD8gIFRoaXMNCj4g
Pj4+IHByb3Bvc2FsIGRvZXNuJ3QgcmVxdWlyZSBzdXBwb3J0IG9mIHRoZSBzeXN0ZW0gSU9NTVUs
IHRoZSBkb20wIGRyaXZlcg0KPiA+Pj4gbWFwcyBJT1ZBIHRyYW5zbGF0aW9ucyBqdXN0IGFzIGl0
IHdvdWxkIGZvciBpdHNlbGYuICBXZSdyZSBsYXJnZWx5DQo+ID4+PiBwcm9wb3NpbmcgdXNlIG9m
IHRoZSBWRklPIEFQSSB0byBwcm92aWRlIGEgY29tbW9uIGludGVyZmFjZSB0byBleHBvc2UgYQ0K
PiA+Pj4gUENJKGUpIGRldmljZSB0byBRRU1VLCBidXQgd2hhdCBoYXBwZW5zIGluIHRoZSB2R1BV
IHZlbmRvciBkZXZpY2UgYW5kDQo+ID4+PiBJT01NVSBiYWNrZW5kcyBpcyBzcGVjaWZpYyB0byB0
aGUgZGV2aWNlIGFuZCBwZXJoYXBzIGV2ZW4gc3BlY2lmaWMgdG8NCj4gPj4+IHRoZSBoeXBlcnZp
c29yLiAgVGhhbmtzLA0KDQpBcyBJIGNvbW1lbnRlZCBpbiBhbm90aGVyIHRocmVhZCwgbGV0J3Mg
bm90IGluY2x1ZGluZyBkZXZpY2UgTU1VIGluIHRoaXMNCmRpc2N1c3Npb24sIHdoaWNoIGlzIHB1
cmVseSBkZXZpY2UgaW50ZXJuYWwgc28gbm90IGluIHRoZSBzY29wZSBvZiBWRklPIChRZW11DQpk
b2Vzbid0IG5lZWQgdG8ga25vdykuIExldCdzIGtlZXAgZGlzY3Vzc2lvbiBhYm91dCBhIGR1bW15
IHR5cGUtMQ0KSU9NTVUgZHJpdmVyIGZvciBtYWludGFpbmluZyBHMkggbWFwcGluZy4NCg0KPiA+
Pg0KPiA+PiBMZXQgbWUgY29uY2x1ZGUgdGhpcywgYW5kIHBsZWFzZSBjb3JyZWN0IG1lIGluIGNh
c2Ugb2YgYW55IG1pc3JlYWQ6IHRoZQ0KPiA+PiB2R1BVIGludGVyZmFjZSBiZXR3ZWVuIGtlcm5l
bCBhbmQgUUVNVSB3aWxsIGJlIHRocm91Z2ggVkZJTywgd2l0aCBhIG5ldw0KPiA+PiBWRklPIGJh
Y2tlbmQgKGluc3RlYWQgb2YgdGhlIGV4aXN0aW5nIHR5cGUxKSwgZm9yIGJvdGggS1ZNR1QgYW5k
IFhlbkdUPw0KPiA+DQo+ID4gTXkgcHJpbWFyeSBjb25jZXJuIGlzIEtWTSBhbmQgUUVNVSB1cHN0
cmVhbSwgdGhlIHByb3Bvc2FsIGlzIG5vdA0KPiA+IHNwZWNpZmljYWxseSBkaXJlY3RlZCBhdCBY
ZW5HVCwgYnV0IGRvZXMgbm90IGV4Y2x1ZGUgaXQgZWl0aGVyLiAgWGVuIGlzDQo+ID4gd2VsY29t
ZSB0byBhZG9wdCB0aGlzIHByb3Bvc2FsIGFzIHdlbGwsIGl0IHNpbXBseSBkZWZpbmVzIHRoZSBj
aGFubmVsDQo+ID4gdGhyb3VnaCB3aGljaCB2R1BVcyBhcmUgZXhwb3NlZCB0byBRRU1VIGFzIHRo
ZSBWRklPIEFQSS4gIFRoZSBjb3JlIFZGSU8NCj4gPiBjb2RlIGluIHRoZSBMaW51eCBrZXJuZWwg
aXMganVzdCBhcyBhdmFpbGFibGUgZm9yIHVzZSBpbiBYZW4gZG9tMCBhcyBpdA0KPiA+IGlzIGZv
ciBhIEtWTSBob3N0LiBWRklPIGluIFFFTVUgY2VydGFpbmx5IGtub3dzIGFib3V0IHNvbWUNCj4g
PiBhY2NlbGVyYXRpb25zIGZvciBLVk0sIGJ1dCB0aGVzZSBhcmUgYWxtb3N0IGVudGlyZWx5IGFy
b3VuZCBhbGxvd2luZw0KPiA+IGV2ZW50ZmQgYmFzZWQgaW50ZXJydXB0cyB0byBiZSBpbmplY3Rl
ZCB0aHJvdWdoIEtWTSwgd2hpY2ggaXMgc29tZXRoaW5nDQo+ID4gSSdtIHN1cmUgWGVuIGNvdWxk
IHByb3ZpZGUgYXMgd2VsbC4gIFRoZXNlIGFjY2VsZXJhdGlvbnMgYXJlIGFsc28gbm90DQo+ID4g
cmVxdWlyZWQsIFZGSU8gYmFzZWQgZGV2aWNlIGFzc2lnbm1lbnQgaW4gUUVNVSB3b3JrcyB3aXRo
IG9yIHdpdGhvdXQNCj4gPiBLVk0uICBMaWtld2lzZSwgdGhlIFZGSU8ga2VybmVsIGludGVyZmFj
ZSBrbm93cyBub3RoaW5nIGFib3V0IEtWTSBhbmQNCj4gPiBoYXMgbm8gZGVwZW5kZW5jaWVzIG9u
IGl0Lg0KPiA+DQo+ID4gVGhlcmUgYXJlIHR3byBjb21wb25lbnRzIHRvIHRoZSBWRklPIEFQSSwg
b25lIGlzIHRoZSB0eXBlMSBjb21wbGlhbnQNCj4gPiBJT01NVSBpbnRlcmZhY2UsIHdoaWNoIGZv
ciB0aGlzIHByb3Bvc2FsIGlzIHJlYWxseSBkb2luZyBub3RoaW5nIG1vcmUNCj4gPiB0aGFuIHRy
YWNraW5nIHRoZSBIVkEgdG8gR1BBIG1hcHBpbmdzIGZvciB0aGUgVk0uICBUaGlzIG11Y2ggc2Vl
bXMNCj4gPiBlbnRpcmVseSBjb21tb24gcmVnYXJkbGVzcyBvZiB0aGUgaHlwZXJ2aXNvci4gIFRo
ZSBvdGhlciBwYXJ0IGlzIHRoZQ0KPiA+IGRldmljZSBpbnRlcmZhY2UuICBUaGUgbGlmZWN5Y2xl
IG9mIHRoZSB2aXJ0dWFsIGRldmljZSBzZWVtcyBsaWtlIGl0DQo+ID4gd291bGQgYmUgZW50aXJl
bHkgc2hhcmVkLCBhcyBkb2VzIG11Y2ggb2YgdGhlIGVtdWxhdGlvbiBjb21wb25lbnRzIG9mDQo+
ID4gdGhlIGRldmljZS4gIFdoZW4gd2UgZ2V0IHRvIHBpbm5pbmcgcGFnZXMsIHByb3ZpZGluZyBk
aXJlY3QgYWNjZXNzIHRvDQo+ID4gbWVtb3J5IHJhbmdlcyBmb3IgYSBWTSwgYW5kIGFjY2VsZXJh
dGluZyBpbnRlcnJ1cHRzLCB0aGUgdkdQVSBkcml2ZXJzDQo+ID4gd2lsbCBsaWtlbHkgbmVlZCBz
b21lIHBlciBoeXBlcnZpc29yIGJyYW5jaGVzLCBidXQgdGhlc2UgYXJlIGFyZWFzIHdoZXJlDQo+
ID4gdGhhdCdzIHRydWUgbm8gbWF0dGVyIHdoYXQgdGhlIGludGVyZmFjZS4gIEknbSBwcm9iYWJs
eSBvdmVyDQo+ID4gc2ltcGxpZnlpbmcsIGJ1dCBob3BlZnVsbHkgbm90IHRvbyBtdWNoLCBjb3Jy
ZWN0IG1lIGlmIEknbSB3cm9uZy4NCj4gPg0KPiANCj4gVGhhbmtzIGZvciBjb25maXJtYXRpb24u
IEZvciBRRU1VL0tWTSwgSSB0b3RhbGx5IGFncmVlIHlvdXIgcG9pbnQ7IEhvd2V2ZXIsDQo+IGlm
IHdlIHRha2UgWGVuR1QgdG8gY29uc2lkZXIsIGl0IHdpbGwgYmUgYSBiaXQgbW9yZSBjb21wbGV4
OiB3aXRoIFhlbg0KPiBoeXBlcnZpc29yIGFuZCBEb20wIGtlcm5lbCBydW5uaW5nIGluIGRpZmZl
cmVudCBsZXZlbCwgaXQncyBub3QgYSBzdHJhaWdodC0NCj4gZm9yd2FyZCB3YXkgZm9yIFFFTVUg
dG8gZG8gc29tZXRoaW5nIGxpa2UgbWFwcGluZyBhIHBvcnRpb24gb2YgTU1JTyBCQVINCj4gdmlh
IFZGSU8gaW4gRG9tMCBrZXJuZWwsIGluc3RlYWQgb2YgY2FsbGluZyBoeXBlcmNhbGxzIGRpcmVj
dGx5Lg0KPiANCj4gSSBkb24ndCBrbm93IGlmIHRoZXJlIGlzIGEgYmV0dGVyIHdheSB0byBoYW5k
bGUgdGhpcy4gQnV0IEkgZG8gYWdyZWUgdGhhdA0KPiBjaGFubmVscyBiZXR3ZWVuIGtlcm5lbCBh
bmQgUWVtdSB2aWEgVkZJTyBpcyBhIGdvb2QgaWRlYSwgZXZlbiB0aG91Z2ggd2UNCj4gbWF5IGhh
dmUgdG8gc3BsaXQgS1ZNR1QvWGVuR1QgaW4gUWVtdSBhIGJpdC4gIFdlIGFyZSBjdXJyZW50bHkg
d29ya2luZyBvbg0KPiBtb3ZpbmcgYWxsIG9mIFBDSSBDRkcgZW11bGF0aW9uIGZyb20ga2VybmVs
IHRvIFFlbXUsIGhvcGVmdWxseSB3ZSBjYW4NCj4gcmVsZWFzZSBpdCBieSBlbmQgb2YgdGhpcyB5
ZWFyIGFuZCB3b3JrIHdpdGggeW91IGd1eXMgdG8gYWRqdXN0IGl0IGZvcg0KPiB0aGUgYWdyZWVk
IG1ldGhvZC4NCg0KQ3VycmVudGx5IHBhc3MtdGhyb3VnaCBwYXRoIGlzIGFscmVhZHkgZGlmZmVy
ZW50IGluIFFlbXUgYmV0d2VlbiBYZW4gYW5kIEtWTS4NCkZvciBub3cgbGV0J3Mga2VlcCBpdCBz
aW1wbGUgYWJvdXQgaG93IHRvIGV4dGVuZCBWRklPIHRvIG1hbmFnZSB2R1BVLiBJbg0KdGhlIGZ1
dHVyZSBpZiBYZW4gZGVjaWRlcyB0byB1c2UgVkZJTywgaXQgc2hvdWxkIG5vdCBiZSB0aGF0IGRp
ZmZpY3VsdCB0byBhZGQNCnNvbWUgWGVuIHNwZWNpZmljIHZmaW8gZHJpdmVyIHRoZXJlLg0KDQo+
IA0KPiANCj4gPiBUaGUgYmVuZWZpdCBvZiBjb3Vyc2UgaXMgdGhhdCBhc2lkZSBmcm9tIHNvbWUg
ZXh0ZW5zaW9ucyB0byB0aGUgQVBJLCB0aGUNCj4gPiBRRU1VIGNvbXBvbmVudHMgYXJlIGFscmVh
ZHkgaW4gcGxhY2UgYW5kIHRoZXJlJ3MgYSBsb3QgbW9yZSBsZXZlcmFnZSBmb3INCj4gPiBnZXR0
aW5nIGJvdGggUUVNVSBhbmQgbGlidmlydCBzdXBwb3J0IHVwc3RyZWFtIGluIGJlaW5nIGFibGUg
dG8gc3VwcG9ydA0KPiA+IG11bHRpcGxlIHZlbmRvcnMsIHBlcmhhcHMgbXVsdGlwbGUgaHlwZXJ2
aXNvcnMsIHdpdGggdGhlIHNhbWUgY29kZS4NCj4gPiBBbHNvLCBJJ20gbm90IHN1cmUgaG93IHVz
ZWZ1bCBpdCBpcywgYnV0IFZGSU8gaXMgYSB1c2Vyc3BhY2UgZHJpdmVyDQo+ID4gaW50ZXJmYWNl
LCB3aGVyZSBoZXJlIHdlJ3JlIHByZWRvbWluYW50bHkgdGFsa2luZyBhYm91dCB0aGF0IHVzZXJz
cGFjZQ0KPiA+IGRyaXZlciBiZWluZyBRRU1VLiAgSXQncyBub3QgbGltaXRlZCB0byB0aGF0IHRo
b3VnaC4gIEEgdXNlcnNwYWNlDQo+ID4gY29tcHV0ZSBhcHBsaWNhdGlvbiBjb3VsZCBoYXZlIGRp
cmVjdCBhY2Nlc3MgdG8gYSB2R1BVIHRocm91Z2ggdGhpcw0KPiA+IG1vZGVsLiAgVGhhbmtzLA0K
PiANCg0KT25lIGlkZWEgaW4gb3VyIG1pbmQgaXMgdG8gZXh0ZW5kIHZHUFUgZm9yIG5hdGl2ZSBh
cHBsaWNhdGlvbiwgZS5nLiB0bw0Kc3VwcG9ydCBiZXR0ZXIgaXNvbGF0aW9uIGFtb25nIGNvbnRh
aW5lcnMgcmVnYXJkaW5nIHRvIEdQVSB3b3JrbG9hZHMuDQoNClRoYW5rcw0KS2V2aW4NCg==
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1274258

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 +0000, 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 Xen today. When running on Xen, the IOMMU
> >>>> is owned by Xen.
> >>>
> >>> Right, but in this case we're talking about device MMUs, which are owned
> >>> by the device driver which I think is running in dom0, right?  This
> >>> proposal doesn't require support of the system IOMMU, the dom0 driver
> >>> maps IOVA translations just as it would for itself.  We're largely
> >>> proposing use of the VFIO API to provide a common interface to expose a
> >>> PCI(e) device to QEMU, but what happens in the vGPU vendor device and
> >>> IOMMU backends is specific to the device and perhaps even specific to
> >>> the hypervisor.  Thanks,
> >>
> >> Let me conclude this, and please correct me in case of any misread: the
> >> vGPU interface between kernel and QEMU will be through VFIO, with a new
> >> VFIO backend (instead of the existing type1), for both KVMGT and XenGT?
> >
> > My primary concern is KVM and QEMU upstream, the proposal is not
> > specifically directed at XenGT, but does not exclude it either.  Xen is
> > welcome to adopt this proposal as well, it simply defines the channel
> > through which vGPUs are exposed to QEMU as the VFIO API.  The core VFIO
> > code in the Linux kernel is just as available for use in Xen dom0 as it
> > is for a KVM host. VFIO in QEMU certainly knows about some
> > accelerations for KVM, but these are almost entirely around allowing
> > eventfd based interrupts to be injected through KVM, which is something
> > I'm sure Xen could provide as well.  These accelerations are also not
> > required, VFIO based device assignment in QEMU works with or without
> > KVM.  Likewise, the VFIO kernel interface knows nothing about KVM and
> > has no dependencies on it.
> >
> > There are two components to the VFIO API, one is the type1 compliant
> > IOMMU interface, which for this proposal is really doing nothing more
> > than tracking the HVA to GPA mappings for the VM.  This much seems
> > entirely common regardless of the hypervisor.  The other part is the
> > device interface.  The lifecycle of the virtual device seems like it
> > would be entirely shared, as does much of the emulation components of
> > the device.  When we get to pinning pages, providing direct access to
> > memory ranges for a VM, and accelerating interrupts, the vGPU drivers
> > will likely need some per hypervisor branches, but these are areas where
> > that's true no matter what the interface.  I'm probably over
> > simplifying, but hopefully not too much, correct me if I'm wrong.
> >
> 
> Thanks for confirmation. For QEMU/KVM, I totally agree your point; However,
> if we take XenGT to consider, it will be a bit more complex: with Xen
> hypervisor and Dom0 kernel running in different level, it's not a straight-
> forward way for QEMU to do something like mapping a portion of MMIO BAR
> via VFIO in Dom0 kernel, instead of calling hypercalls directly.

This would need to be part of the support added for Xen.  To directly
map a device MMIO space to the VM, VFIO provides an mmap, QEMU registers
that mmap with KVM, or Xen.  It's all just MemoryRegions in QEMU.
Perhaps it's even already supported by Xen.

> I don't know if there is a better way to handle this. But I do agree that
> channels between kernel and Qemu via VFIO is a good idea, even though we
> may have to split KVMGT/XenGT in Qemu a bit.  We are currently working on
> moving all of PCI CFG emulation from kernel to Qemu, hopefully we can
> release it by end of this year and work with you guys to adjust it for
> the agreed method.

Well, moving PCI config space emulation from kernel to QEMU is exactly
the wrong direction to take for this proposal.  Config space access to
the vGPU would occur through the VFIO API.  So if you already have
config space emulation in the kernel, that's already one less piece of
work for a VFIO model, it just needs to be "wired up" through the VFIO
API.  Thanks,

Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1275048 — Re: [Qemu-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

On 11/21/2015 12:40 AM, Alex Williamson wrote:
>>
>> Thanks for confirmation. For QEMU/KVM, I totally agree your point; However,
>> if we take XenGT to consider, it will be a bit more complex: with Xen
>> hypervisor and Dom0 kernel running in different level, it's not a straight-
>> forward way for QEMU to do something like mapping a portion of MMIO BAR
>> via VFIO in Dom0 kernel, instead of calling hypercalls directly.
>
> This would need to be part of the support added for Xen.  To directly
> map a device MMIO space to the VM, VFIO provides an mmap, QEMU registers
> that mmap with KVM, or Xen.  It's all just MemoryRegions in QEMU.
> Perhaps it's even already supported by Xen.
>

AFAICT, things are different here for Xen. To establish mappings between
Dom0 pfns and DomU gfn, one will have to call Xen hypercalls. In the scene
above, either QEMU calls the hypercall directly, or it asks the VFIO in
dom0 kernel to do it.

I'm not saying that VFIO is not applicable for XenGT. I just want to
say that given the VFIO based kernel/QEMU split model, additional effort
is needed for XenGT.

>> I don't know if there is a better way to handle this. But I do agree that
>> channels between kernel and Qemu via VFIO is a good idea, even though we
>> may have to split KVMGT/XenGT in Qemu a bit.  We are currently working on
>> moving all of PCI CFG emulation from kernel to Qemu, hopefully we can
>> release it by end of this year and work with you guys to adjust it for
>> the agreed method.
>
> Well, moving PCI config space emulation from kernel to QEMU is exactly
> the wrong direction to take for this proposal.  Config space access to
> the vGPU would occur through the VFIO API.  So if you already have
> config space emulation in the kernel, that's already one less piece of
> work for a VFIO model, it just needs to be "wired up" through the VFIO
> API.  Thanks,

If I understand correctly, the idea of moving PCI CFG to QEMU is actually
very similar to your VFIO design:

	a) VM access a CFG regsiter
	b) KVM hands over the access to QEMU
	c) QEMU may emulate it, and when necessary, ioctl into kernel(i915/vgt)


>
> Alex
>
>
--
Thanks,
Jike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1273248 — Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

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 compatibility between KVM and Xen should
be a design goal for GVT-g.

Nevertheless, it shouldn't be a problem to use a "virtual" VFIO (which
doesn't need the IOMMU, because it uses the MMU in the physical GPU)
even under Xen.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1273263 — Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

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 owned by Xen.
> 
> I don't think QEMU command line compatibility between KVM and Xen should
> be a design goal for GVT-g.

Right, I agree.

In fact I don't want my comment to be taken as "VFIO should not be used
at all". I only meant to reply to the question. I think it is unlikely
to be the best path for Xen, but it could very well be the right answer
for KVM.


> Nevertheless, it shouldn't be a problem to use a "virtual" VFIO (which
> doesn't need the IOMMU, because it uses the MMU in the physical GPU)
> even under Xen.

That could be true, but I would expect some extra work to be needed to
make use of VFIO on Xen. Also it might cause some duplication of
functionalities with the current Xen passthrough code base.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1272941

  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
> > framebuffer region could be directly mappable in QEMU while a
> > non-mappable page, at a standard location with standardized format,
> > provides a description of framebuffer and potentially even a
> > communication channel to synchronize framebuffer captures.  This would
> > be new code for QEMU, but something we could share among all vGPU
> > implementations.
> 
> Now GVT-g already provides an interface to decode framebuffer information,
> w/ an assumption that the framebuffer will be further composited into 
> OpenGL APIs.

Can I have a pointer to docs / code?

iGVT-g_Setup_Guide.txt mentions a "Indirect Display Mode", but doesn't
explain how the guest framebuffer can be accessed then.

> So the format is defined according to OpenGL definition.
> Does that meet SPICE requirement?

Yes and no ;)

Some more background:  We basically have two rendering paths in qemu.
The classic one, without opengl, and a new, still emerging one, using
opengl and dma-bufs (gtk support merged for qemu 2.5, sdl2 support will
land in 2.6, spice support still WIP, hopefully 2.6 too).  For best
performance you probably want use the new opengl-based rendering
whenever possible.  However I do *not* expect the classic rendering path
disappear, we'll continue to need that in various cases, most prominent
one being vnc support.

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.

> Another thing to be added. Framebuffers are frequently switched in
> reality. So either Qemu needs to poll or a notification mechanism is required.

The idea is to have qemu poll (and adapt poll rate, i.e. without vnc
client connected qemu will poll alot less frequently).

> And since it's dynamic, having framebuffer page directly exposed in the
> new region might be tricky.  We can just expose framebuffer information
> (including base, format, etc.) and let Qemu to map separately out of VFIO
> interface.

Allocate some memory, ask gpu to blit the guest framebuffer there, i.e.
provide a snapshot of the current guest display instead of playing
mapping tricks?

> And... this works fine with vGPU model since software knows all the
> detail about framebuffer. However in pass-through case, who do you expect
> to provide that information? Is it OK to introduce vGPU specific APIs in
> VFIO?

It will only be used in the vgpu case, not for pass-though.

We think it is better to extend the vfio interface to improve vgpu
support rather than inventing something new while vfio can satisfy 90%
of the vgpu needs already.  We want avoid vendor-specific extensions
though, the vgpu extension should work across vendors.

> Now there is no standard. We expose vGPU life-cycle mgmt. APIs through
> sysfs (under i915 node), which is very Intel specific. In reality different
> vendors have quite different capabilities for their own vGPUs, so not sure
> how standard we can define such a mechanism.

Agree when it comes to create vGPU instances.

> 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.

cheers,
  Gerd


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1273036 — Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

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 look like SR/IOV devices.

The interface may look a little like the sysfs interface that GVT-g is
already using.  However, it should at least be extended to support
multiple vGPUs in a single VM.  This might not be possible for Intel
integrated graphics, but it should definitely be possible for discrete
graphics cards.

Another nit is that the VM id should probably be replaced by a UUID
(because it's too easy to stumble on an existing VM id), assuming a VM
id is needed at all.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1273701 — Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

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
>> libvirt.
>
> I don't think they will look like SR/IOV devices.
>
> The interface may look a little like the sysfs interface that GVT-g is
> already using.  However, it should at least be extended to support
> multiple vGPUs in a single VM.  This might not be possible for Intel
> integrated graphics, but it should definitely be possible for discrete
> graphics cards.

Didn't hear about multiple vGPUs for a single VM before. Yes If we
expect same vGPU interfaces for different vendors, abstraction and
vendor specific stuff should be implemented.


> Another nit is that the VM id should probably be replaced by a UUID
> (because it's too easy to stumble on an existing VM id), assuming a VM
> id is needed at all.

For the last assumption, yes, a VM id is not necessary for gvt-g, it's
only a temporary implementation.

As long as libvirt is used, UUID should be enough for gvt-g. However,
UUID is not mandatory? What should we do if user don't specify an UUID
in QEMU cmdline?

>
> Paolo
>

--
Thanks,
Jike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1273743

PiBGcm9tOiBHZXJkIEhvZmZtYW5uIFttYWlsdG86a3JheGVsQHJlZGhhdC5jb21dDQo+IFNlbnQ6
IFRodXJzZGF5LCBOb3ZlbWJlciAxOSwgMjAxNSA0OjQxIFBNDQo+IA0KPiAgIEhpLA0KPiANCj4g
PiA+IEFub3RoZXIgYXJlYSBvZiBleHRlbnNpb24gaXMgaG93IHRvIGV4cG9zZSBhIGZyYW1lYnVm
ZmVyIHRvIFFFTVUgZm9yDQo+ID4gPiBzZWFtbGVzcyBpbnRlZ3JhdGlvbiBpbnRvIGEgU1BJQ0Uv
Vk5DIGNoYW5uZWwuICBGb3IgdGhpcyBJIGJlbGlldmUgd2UNCj4gPiA+IGNvdWxkIHVzZSBhIG5l
dyByZWdpb24sIG11Y2ggbGlrZSB3ZSd2ZSBkb25lIHRvIGV4cG9zZSBWR0EgYWNjZXNzDQo+ID4g
PiB0aHJvdWdoIGEgdmZpbyBkZXZpY2UgZmlsZSBkZXNjcmlwdG9yLiAgQW4gYXJlYSB3aXRoaW4g
dGhpcyBuZXcNCj4gPiA+IGZyYW1lYnVmZmVyIHJlZ2lvbiBjb3VsZCBiZSBkaXJlY3RseSBtYXBw
YWJsZSBpbiBRRU1VIHdoaWxlIGENCj4gPiA+IG5vbi1tYXBwYWJsZSBwYWdlLCBhdCBhIHN0YW5k
YXJkIGxvY2F0aW9uIHdpdGggc3RhbmRhcmRpemVkIGZvcm1hdCwNCj4gPiA+IHByb3ZpZGVzIGEg
ZGVzY3JpcHRpb24gb2YgZnJhbWVidWZmZXIgYW5kIHBvdGVudGlhbGx5IGV2ZW4gYQ0KPiA+ID4g
Y29tbXVuaWNhdGlvbiBjaGFubmVsIHRvIHN5bmNocm9uaXplIGZyYW1lYnVmZmVyIGNhcHR1cmVz
LiAgVGhpcyB3b3VsZA0KPiA+ID4gYmUgbmV3IGNvZGUgZm9yIFFFTVUsIGJ1dCBzb21ldGhpbmcg
d2UgY291bGQgc2hhcmUgYW1vbmcgYWxsIHZHUFUNCj4gPiA+IGltcGxlbWVudGF0aW9ucy4NCj4g
Pg0KPiA+IE5vdyBHVlQtZyBhbHJlYWR5IHByb3ZpZGVzIGFuIGludGVyZmFjZSB0byBkZWNvZGUg
ZnJhbWVidWZmZXIgaW5mb3JtYXRpb24sDQo+ID4gdy8gYW4gYXNzdW1wdGlvbiB0aGF0IHRoZSBm
cmFtZWJ1ZmZlciB3aWxsIGJlIGZ1cnRoZXIgY29tcG9zaXRlZCBpbnRvDQo+ID4gT3BlbkdMIEFQ
SXMuDQo+IA0KPiBDYW4gSSBoYXZlIGEgcG9pbnRlciB0byBkb2NzIC8gY29kZT8NCj4gDQo+IGlH
VlQtZ19TZXR1cF9HdWlkZS50eHQgbWVudGlvbnMgYSAiSW5kaXJlY3QgRGlzcGxheSBNb2RlIiwg
YnV0IGRvZXNuJ3QNCj4gZXhwbGFpbiBob3cgdGhlIGd1ZXN0IGZyYW1lYnVmZmVyIGNhbiBiZSBh
Y2Nlc3NlZCB0aGVuLg0KDQpZb3UgY2FuIGNoZWNrICJmYl9kZWNvZGVyLmgiLiBPbmUgdGhpbmcg
dG8gY2xhcmlmeS4gSXRzIGZvcm1hdCBpcw0KYWN0dWFsbHkgYmFzZWQgb24gZHJtIGRlZmluaXRp
b24sIGluc3RlYWQgb2YgT3BlbkdMLiBTb3JyeSBmb3INCnRoYXQuDQoNCj4gDQo+ID4gU28gdGhl
IGZvcm1hdCBpcyBkZWZpbmVkIGFjY29yZGluZyB0byBPcGVuR0wgZGVmaW5pdGlvbi4NCj4gPiBE
b2VzIHRoYXQgbWVldCBTUElDRSByZXF1aXJlbWVudD8NCj4gDQo+IFllcyBhbmQgbm8gOykNCj4g
DQo+IFNvbWUgbW9yZSBiYWNrZ3JvdW5kOiAgV2UgYmFzaWNhbGx5IGhhdmUgdHdvIHJlbmRlcmlu
ZyBwYXRocyBpbiBxZW11Lg0KPiBUaGUgY2xhc3NpYyBvbmUsIHdpdGhvdXQgb3BlbmdsLCBhbmQg
YSBuZXcsIHN0aWxsIGVtZXJnaW5nIG9uZSwgdXNpbmcNCj4gb3BlbmdsIGFuZCBkbWEtYnVmcyAo
Z3RrIHN1cHBvcnQgbWVyZ2VkIGZvciBxZW11IDIuNSwgc2RsMiBzdXBwb3J0IHdpbGwNCj4gbGFu
ZCBpbiAyLjYsIHNwaWNlIHN1cHBvcnQgc3RpbGwgV0lQLCBob3BlZnVsbHkgMi42IHRvbykuICBG
b3IgYmVzdA0KPiBwZXJmb3JtYW5jZSB5b3UgcHJvYmFibHkgd2FudCB1c2UgdGhlIG5ldyBvcGVu
Z2wtYmFzZWQgcmVuZGVyaW5nDQo+IHdoZW5ldmVyIHBvc3NpYmxlLiAgSG93ZXZlciBJIGRvICpu
b3QqIGV4cGVjdCB0aGUgY2xhc3NpYyByZW5kZXJpbmcgcGF0aA0KPiBkaXNhcHBlYXIsIHdlJ2xs
IGNvbnRpbnVlIHRvIG5lZWQgdGhhdCBpbiB2YXJpb3VzIGNhc2VzLCBtb3N0IHByb21pbmVudA0K
PiBvbmUgYmVpbmcgdm5jIHN1cHBvcnQuDQo+IA0KPiBTbywgZm9yIG5vbi1vcGVuZ2wgcmVuZGVy
aW5nIHFlbXUgbmVlZHMgdGhlIGd1ZXN0IGZyYW1lYnVmZmVyIGRhdGEgc28gaXQNCj4gY2FuIGZl
ZWQgaXQgaW50byB0aGUgdm5jIHNlcnZlci4gIFRoZSB2ZmlvIGZyYW1lYnVmZmVyIHJlZ2lvbiBp
cyBtZWFudA0KPiB0byBzdXBwb3J0IHRoaXMgdXNlIGNhc2UuDQoNCndoYXQncyB0aGUgZm9ybWF0
IHJlcXVpcmVtZW50IG9uIHRoYXQgZnJhbWVidWZmZXI/IElmIHlvdSBhcmUgZmFtaWxpYXINCndp
dGggSW50ZWwgR3JhcGhpY3MsIHRoZXJlJ3MgYSBzby1jYWxsZWQgdGlsaW5nIGZlYXR1cmUgYXBw
bGllZCBvbiBmcmFtZQ0KYnVmZmVyIHNvIGl0IGNhbid0IGJlIHVzZWQgYXMgYSByYXcgaW5wdXQg
dG8gdm5jIHNlcnZlci4gdy9vIG9wZW5nbCB5b3UNCm5lZWQgZG8gc29tZSBjb252ZXJzaW9uIG9u
IENQVSBmaXJzdC4NCg0KPiANCj4gPiBBbm90aGVyIHRoaW5nIHRvIGJlIGFkZGVkLiBGcmFtZWJ1
ZmZlcnMgYXJlIGZyZXF1ZW50bHkgc3dpdGNoZWQgaW4NCj4gPiByZWFsaXR5LiBTbyBlaXRoZXIg
UWVtdSBuZWVkcyB0byBwb2xsIG9yIGEgbm90aWZpY2F0aW9uIG1lY2hhbmlzbSBpcyByZXF1aXJl
ZC4NCj4gDQo+IFRoZSBpZGVhIGlzIHRvIGhhdmUgcWVtdSBwb2xsIChhbmQgYWRhcHQgcG9sbCBy
YXRlLCBpLmUuIHdpdGhvdXQgdm5jDQo+IGNsaWVudCBjb25uZWN0ZWQgcWVtdSB3aWxsIHBvbGwg
YWxvdCBsZXNzIGZyZXF1ZW50bHkpLg0KPiANCj4gPiBBbmQgc2luY2UgaXQncyBkeW5hbWljLCBo
YXZpbmcgZnJhbWVidWZmZXIgcGFnZSBkaXJlY3RseSBleHBvc2VkIGluIHRoZQ0KPiA+IG5ldyBy
ZWdpb24gbWlnaHQgYmUgdHJpY2t5LiAgV2UgY2FuIGp1c3QgZXhwb3NlIGZyYW1lYnVmZmVyIGlu
Zm9ybWF0aW9uDQo+ID4gKGluY2x1ZGluZyBiYXNlLCBmb3JtYXQsIGV0Yy4pIGFuZCBsZXQgUWVt
dSB0byBtYXAgc2VwYXJhdGVseSBvdXQgb2YgVkZJTw0KPiA+IGludGVyZmFjZS4NCj4gDQo+IEFs
bG9jYXRlIHNvbWUgbWVtb3J5LCBhc2sgZ3B1IHRvIGJsaXQgdGhlIGd1ZXN0IGZyYW1lYnVmZmVy
IHRoZXJlLCBpLmUuDQo+IHByb3ZpZGUgYSBzbmFwc2hvdCBvZiB0aGUgY3VycmVudCBndWVzdCBk
aXNwbGF5IGluc3RlYWQgb2YgcGxheWluZw0KPiBtYXBwaW5nIHRyaWNrcz8NCg0KeWVzIGl0IHdv
cmtzIGJ1dCBiZXR0ZXIgdG8gYmUgY29tcGxldGVkIGluIHVzZXIgbGV2ZWwuDQoNCj4gDQo+ID4g
QW5kLi4uIHRoaXMgd29ya3MgZmluZSB3aXRoIHZHUFUgbW9kZWwgc2luY2Ugc29mdHdhcmUga25v
d3MgYWxsIHRoZQ0KPiA+IGRldGFpbCBhYm91dCBmcmFtZWJ1ZmZlci4gSG93ZXZlciBpbiBwYXNz
LXRocm91Z2ggY2FzZSwgd2hvIGRvIHlvdSBleHBlY3QNCj4gPiB0byBwcm92aWRlIHRoYXQgaW5m
b3JtYXRpb24/IElzIGl0IE9LIHRvIGludHJvZHVjZSB2R1BVIHNwZWNpZmljIEFQSXMgaW4NCj4g
PiBWRklPPw0KPiANCj4gSXQgd2lsbCBvbmx5IGJlIHVzZWQgaW4gdGhlIHZncHUgY2FzZSwgbm90
IGZvciBwYXNzLXRob3VnaC4NCj4gDQo+IFdlIHRoaW5rIGl0IGlzIGJldHRlciB0byBleHRlbmQg
dGhlIHZmaW8gaW50ZXJmYWNlIHRvIGltcHJvdmUgdmdwdQ0KPiBzdXBwb3J0IHJhdGhlciB0aGFu
IGludmVudGluZyBzb21ldGhpbmcgbmV3IHdoaWxlIHZmaW8gY2FuIHNhdGlzZnkgOTAlDQo+IG9m
IHRoZSB2Z3B1IG5lZWRzIGFscmVhZHkuICBXZSB3YW50IGF2b2lkIHZlbmRvci1zcGVjaWZpYyBl
eHRlbnNpb25zDQo+IHRob3VnaCwgdGhlIHZncHUgZXh0ZW5zaW9uIHNob3VsZCB3b3JrIGFjcm9z
cyB2ZW5kb3JzLg0KDQppdCdzIGZpbmUsIGFzIGxvbmcgYXMgdmdwdSBzcGVjaWZpYyBpbnRlcmZh
Y2UgaXMgYWxsb3dlZC4gOi0pDQoNCj4gDQo+ID4gTm93IHRoZXJlIGlzIG5vIHN0YW5kYXJkLiBX
ZSBleHBvc2UgdkdQVSBsaWZlLWN5Y2xlIG1nbXQuIEFQSXMgdGhyb3VnaA0KPiA+IHN5c2ZzICh1
bmRlciBpOTE1IG5vZGUpLCB3aGljaCBpcyB2ZXJ5IEludGVsIHNwZWNpZmljLiBJbiByZWFsaXR5
IGRpZmZlcmVudA0KPiA+IHZlbmRvcnMgaGF2ZSBxdWl0ZSBkaWZmZXJlbnQgY2FwYWJpbGl0aWVz
IGZvciB0aGVpciBvd24gdkdQVXMsIHNvIG5vdCBzdXJlDQo+ID4gaG93IHN0YW5kYXJkIHdlIGNh
biBkZWZpbmUgc3VjaCBhIG1lY2hhbmlzbS4NCj4gDQo+IEFncmVlIHdoZW4gaXQgY29tZXMgdG8g
Y3JlYXRlIHZHUFUgaW5zdGFuY2VzLg0KPiANCj4gPiBCdXQgdGhpcyBjb2RlIHNob3VsZCBiZQ0K
PiA+IG1pbm9yIHRvIGJlIG1haW50YWluZWQgaW4gbGlidmlydC4NCj4gDQo+IEFzIGZhciBJIGtu
b3cgbGlidmlydCBvbmx5IG5lZWRzIHRvIGRpc2NvdmVyIHRob3NlIGRldmljZXMuICBJZiB0aGV5
DQo+IGxvb2sgbGlrZSBzci9pb3YgZGV2aWNlcyBpbiBzeXNmcyB0aGlzIG1pZ2h0IHdvcmsgd2l0
aG91dCBhbnkgY2hhbmdlcyB0bw0KPiBsaWJ2aXJ0Lg0KPiANCj4gY2hlZXJzLA0KPiAgIEdlcmQN
Cj4gDQoNCg==
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1273820

  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 fine.  That header explains the format, but not how it can be
accessed.  Is the guest fb exported as dma-buf?

> > 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 requirement on that framebuffer? If you are familiar
> with Intel Graphics, there's a so-called tiling feature applied on frame
> buffer so it can't be used as a raw input to vnc server. w/o opengl you
> need do some conversion on CPU first.

Yes, that conversion needs to happen, qemu can't deal with tiled
graphics.  Anything which pixman can handle will work.  Prefered would
be PIXMAN_x8r8g8b8 (aka DRM_FORMAT_XRGB8888 on little endian host) which
is the format used by the vnc server (and other places in qemu)
internally.

qemu can also use the opengl texture for the guest fb, then fetch the
data with glReadPixels().  Which will probably do exactly the same
conversion.  But it'll add a opengl dependency to the non-opengl
rendering path in qemu, would be nice if we can avoid that.

While being at it:  When importing a dma-buf with a tiled framebuffer
into opengl (via eglCreateImageKHR + EGL_LINUX_DMA_BUF_EXT) I suspect we
have to pass in the tile size as attribute to make it work.  Is that
correct?

cheers,
  Gerd


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1273828

PiBGcm9tOiBHZXJkIEhvZmZtYW5uIFttYWlsdG86a3JheGVsQHJlZGhhdC5jb21dDQo+IFNlbnQ6
IEZyaWRheSwgTm92ZW1iZXIgMjAsIDIwMTUgNDoyNiBQTQ0KPiANCj4gICBIaSwNCj4gDQo+ID4g
PiBpR1ZULWdfU2V0dXBfR3VpZGUudHh0IG1lbnRpb25zIGEgIkluZGlyZWN0IERpc3BsYXkgTW9k
ZSIsIGJ1dCBkb2Vzbid0DQo+ID4gPiBleHBsYWluIGhvdyB0aGUgZ3Vlc3QgZnJhbWVidWZmZXIg
Y2FuIGJlIGFjY2Vzc2VkIHRoZW4uDQo+ID4NCj4gPiBZb3UgY2FuIGNoZWNrICJmYl9kZWNvZGVy
LmgiLiBPbmUgdGhpbmcgdG8gY2xhcmlmeS4gSXRzIGZvcm1hdCBpcw0KPiA+IGFjdHVhbGx5IGJh
c2VkIG9uIGRybSBkZWZpbml0aW9uLCBpbnN0ZWFkIG9mIE9wZW5HTC4gU29ycnkgZm9yDQo+ID4g
dGhhdC4NCj4gDQo+IGRybSBpcyBmaW5lLiAgVGhhdCBoZWFkZXIgZXhwbGFpbnMgdGhlIGZvcm1h
dCwgYnV0IG5vdCBob3cgaXQgY2FuIGJlDQo+IGFjY2Vzc2VkLiAgSXMgdGhlIGd1ZXN0IGZiIGV4
cG9ydGVkIGFzIGRtYS1idWY/DQoNCkN1cnJlbnRseSBub3QsIGJ1dCBwZXIgb3VyIHByZXZpb3Vz
IGRpc2N1c3Npb24gd2Ugc2hvdWxkIG1vdmUgdG8gdXNlDQpkbWEtYnVmLiBXZSBoYXZlIHNvbWUg
ZGVtbyBjb2RlIGluIHVzZXIgc3BhY2UuIE5vdCBzdXJlIHdoZXRoZXINCnRoZXkncmUgcHVibGlj
IG5vdy4gSmlrZSBjb3VsZCB5b3UgaGVscCBkbyBhIGNoZWNrPw0KDQo+IA0KPiA+ID4gU28sIGZv
ciBub24tb3BlbmdsIHJlbmRlcmluZyBxZW11IG5lZWRzIHRoZSBndWVzdCBmcmFtZWJ1ZmZlciBk
YXRhIHNvIGl0DQo+ID4gPiBjYW4gZmVlZCBpdCBpbnRvIHRoZSB2bmMgc2VydmVyLiAgVGhlIHZm
aW8gZnJhbWVidWZmZXIgcmVnaW9uIGlzIG1lYW50DQo+ID4gPiB0byBzdXBwb3J0IHRoaXMgdXNl
IGNhc2UuDQo+ID4NCj4gPiB3aGF0J3MgdGhlIGZvcm1hdCByZXF1aXJlbWVudCBvbiB0aGF0IGZy
YW1lYnVmZmVyPyBJZiB5b3UgYXJlIGZhbWlsaWFyDQo+ID4gd2l0aCBJbnRlbCBHcmFwaGljcywg
dGhlcmUncyBhIHNvLWNhbGxlZCB0aWxpbmcgZmVhdHVyZSBhcHBsaWVkIG9uIGZyYW1lDQo+ID4g
YnVmZmVyIHNvIGl0IGNhbid0IGJlIHVzZWQgYXMgYSByYXcgaW5wdXQgdG8gdm5jIHNlcnZlci4g
dy9vIG9wZW5nbCB5b3UNCj4gPiBuZWVkIGRvIHNvbWUgY29udmVyc2lvbiBvbiBDUFUgZmlyc3Qu
DQo+IA0KPiBZZXMsIHRoYXQgY29udmVyc2lvbiBuZWVkcyB0byBoYXBwZW4sIHFlbXUgY2FuJ3Qg
ZGVhbCB3aXRoIHRpbGVkDQo+IGdyYXBoaWNzLiAgQW55dGhpbmcgd2hpY2ggcGl4bWFuIGNhbiBo
YW5kbGUgd2lsbCB3b3JrLiAgUHJlZmVyZWQgd291bGQNCj4gYmUgUElYTUFOX3g4cjhnOGI4IChh
a2EgRFJNX0ZPUk1BVF9YUkdCODg4OCBvbiBsaXR0bGUgZW5kaWFuIGhvc3QpIHdoaWNoDQo+IGlz
IHRoZSBmb3JtYXQgdXNlZCBieSB0aGUgdm5jIHNlcnZlciAoYW5kIG90aGVyIHBsYWNlcyBpbiBx
ZW11KQ0KPiBpbnRlcm5hbGx5Lg0KPiANCj4gcWVtdSBjYW4gYWxzbyB1c2UgdGhlIG9wZW5nbCB0
ZXh0dXJlIGZvciB0aGUgZ3Vlc3QgZmIsIHRoZW4gZmV0Y2ggdGhlDQo+IGRhdGEgd2l0aCBnbFJl
YWRQaXhlbHMoKS4gIFdoaWNoIHdpbGwgcHJvYmFibHkgZG8gZXhhY3RseSB0aGUgc2FtZQ0KPiBj
b252ZXJzaW9uLiAgQnV0IGl0J2xsIGFkZCBhIG9wZW5nbCBkZXBlbmRlbmN5IHRvIHRoZSBub24t
b3BlbmdsDQo+IHJlbmRlcmluZyBwYXRoIGluIHFlbXUsIHdvdWxkIGJlIG5pY2UgaWYgd2UgY2Fu
IGF2b2lkIHRoYXQuDQo+IA0KPiBXaGlsZSBiZWluZyBhdCBpdDogIFdoZW4gaW1wb3J0aW5nIGEg
ZG1hLWJ1ZiB3aXRoIGEgdGlsZWQgZnJhbWVidWZmZXINCj4gaW50byBvcGVuZ2wgKHZpYSBlZ2xD
cmVhdGVJbWFnZUtIUiArIEVHTF9MSU5VWF9ETUFfQlVGX0VYVCkgSSBzdXNwZWN0IHdlDQo+IGhh
dmUgdG8gcGFzcyBpbiB0aGUgdGlsZSBzaXplIGFzIGF0dHJpYnV0ZSB0byBtYWtlIGl0IHdvcmsu
ICBJcyB0aGF0DQo+IGNvcnJlY3Q/DQo+IA0KDQpJJ2QgZ3Vlc3Mgc28sIGJ1dCBuZWVkIGRvdWJs
ZSBjb25maXJtIGxhdGVyIHdoZW4gcmVhY2hpbmcgdGhhdCBsZXZlbCBvZiBkZXRhaWwuIA0Kc29t
ZSBob21ld29yayBvbiBkbWEtYnVmIGlzIHJlcXVpcmVkIGZpcnN0LiA6LSkNCg0KVGhhbmtzDQpL
ZXZpbg0K
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1273858 — Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

On Fri, Nov 20, 2015 at 04:36:15PM +0800, Tian, Kevin wrote:
> > From: Gerd Hoffmann [mailto:kraxel@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 clarify. Its format is
> > > actually based on drm definition, instead of OpenGL. Sorry for
> > > that.
> > 
> > drm is fine.  That header explains the format, but not how it can be
> > accessed.  Is the guest fb exported as dma-buf?
> 
> Currently not, but per our previous discussion we should move to use
> dma-buf. We have some demo code in user space. Not sure whether
> they're public now. Jike could you help do a check?

Our current implementation did not use dma-buf yet, still based on DRM_FLINK
interface. We will switch to dma-buf. Thanks!

Regards,
-Zhiyuan

> 
> > 
> > > > 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 requirement on that framebuffer? If you are familiar
> > > with Intel Graphics, there's a so-called tiling feature applied on frame
> > > buffer so it can't be used as a raw input to vnc server. w/o opengl you
> > > need do some conversion on CPU first.
> > 
> > Yes, that conversion needs to happen, qemu can't deal with tiled
> > graphics.  Anything which pixman can handle will work.  Prefered would
> > be PIXMAN_x8r8g8b8 (aka DRM_FORMAT_XRGB8888 on little endian host) which
> > is the format used by the vnc server (and other places in qemu)
> > internally.
> > 
> > qemu can also use the opengl texture for the guest fb, then fetch the
> > data with glReadPixels().  Which will probably do exactly the same
> > conversion.  But it'll add a opengl dependency to the non-opengl
> > rendering path in qemu, would be nice if we can avoid that.
> > 
> > While being at it:  When importing a dma-buf with a tiled framebuffer
> > into opengl (via eglCreateImageKHR + EGL_LINUX_DMA_BUF_EXT) I suspect we
> > have to pass in the tile size as attribute to make it work.  Is that
> > correct?
> > 
> 
> I'd guess so, but need double confirm later when reaching that level of detail. 
> some homework on dma-buf is required first. :-)
> 
> Thanks
> Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.kernel

csiph-web