From: Gerd Hoffmann <kraxel@redhat.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: "igvt-g@ml01.01.org" <igvt-g@ml01.01.org>,
qemu-devel <qemu-devel@nongnu.org>,
"Reddy, Raghuveer" <raghuveer.reddy@intel.com>,
"White, Michael L" <michael.l.white@intel.com>,
"Cowperthwaite, David J" <david.j.cowperthwaite@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>,
"Li, Susie" <susie.li@intel.com>,
"Dong, Eddie" <eddie.dong@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
Alex Williamson <alex.williamson@redhat.com>,
"Zhou, Chao" <chao.zhou@intel.com>,
Paolo Bonzini <pbonzini@redhat.com>,
"Zhu, Libo" <libo.zhu@intel.com>,
"Wang, Hongbo" <hongbo.wang@intel.com>
Subject: Re: [Qemu-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel
Date: Tue, 24 Nov 2015 15:12:31 +0100 [thread overview]
Message-ID: <1448374351.27648.128.camel@redhat.com> (raw)
In-Reply-To: <20151124133135.GY17050@phenom.ffwll.local>
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 opengl support to reduce the attach surface and/or package
dependency chain.
And, yes, requirements for the non-gl rendering path are pretty low.
qemu needs something it can mmap, and which it can ask pixman to handle.
Preferred format is PIXMAN_x8r8g8b8 (qemu uses that internally in alot
of places so this avoids conversions).
Current plan is to have a special vfio region (not visible to the guest)
where the framebuffer lives, with one or two pages at the end for meta
data (format and size). Status field is there too and will be used by
qemu to request updates and the kernel to signal update completion.
Guess I should write that down as vfio rfc patch ...
I don't think it makes sense to have fields to notify qemu about which
framebuffer regions have been updated, I'd expect with full-screen
composing we have these days this information isn't available anyway.
Maybe a flag telling whenever there have been updates or not, so qemu
can skip update processing in case we have the screensaver showing a
black screen all day long.
cheers,
Gerd
next prev parent reply other threads:[~2015-11-24 14:12 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <53D215D3.50608@intel.com>
[not found] ` <547FCAAD.2060406@intel.com>
[not found] ` <54AF967B.3060503@intel.com>
[not found] ` <5527CEC4.9080700@intel.com>
[not found] ` <559B3E38.1080707@intel.com>
[not found] ` <562F4311.9@intel.com>
2015-11-18 18:12 ` [Qemu-devel] [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel Alex Williamson
2015-11-19 4:06 ` Tian, Kevin
2015-11-19 7:22 ` Jike Song
2015-11-19 15:32 ` Stefano Stabellini
2015-11-19 15:49 ` Paolo Bonzini
2015-11-19 16:12 ` Stefano Stabellini
2015-11-19 15:52 ` Alex Williamson
2015-11-20 2:58 ` Jike Song
2015-11-20 4:22 ` Alex Williamson
2015-11-20 5:51 ` Jike Song
2015-11-20 6:01 ` Tian, Kevin
2015-11-20 16:40 ` Alex Williamson
2015-11-23 4:52 ` Jike Song
2015-11-19 8:40 ` Gerd Hoffmann
2015-11-19 11:09 ` Paolo Bonzini
2015-11-20 2:46 ` Jike Song
2015-11-20 6:12 ` Tian, Kevin
2015-11-20 8:26 ` Gerd Hoffmann
2015-11-20 8:36 ` Tian, Kevin
2015-11-20 8:46 ` Zhiyuan Lv
2015-12-03 6:57 ` Tian, Kevin
2015-12-04 10:13 ` Gerd Hoffmann
2015-11-19 20:02 ` Alex Williamson
2015-11-20 7:09 ` Tian, Kevin
2015-11-20 17:03 ` Alex Williamson
2015-11-20 8:10 ` Tian, Kevin
2015-11-20 17:25 ` Alex Williamson
2015-11-23 5:05 ` Jike Song
2015-11-24 11:19 ` Daniel Vetter
2015-11-24 11:49 ` Chris Wilson
2015-11-24 12:38 ` Gerd Hoffmann
2015-11-24 13:31 ` Daniel Vetter
2015-11-24 14:12 ` Gerd Hoffmann [this message]
2015-11-24 14:19 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1448374351.27648.128.camel@redhat.com \
--to=kraxel@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=chao.zhou@intel.com \
--cc=daniel@ffwll.ch \
--cc=david.j.cowperthwaite@intel.com \
--cc=eddie.dong@intel.com \
--cc=hongbo.wang@intel.com \
--cc=igvt-g@ml01.01.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=libo.zhu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michael.l.white@intel.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=raghuveer.reddy@intel.com \
--cc=susie.li@intel.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).