Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754107AbbKXOTx (ORCPT ); Tue, 24 Nov 2015 09:19:53 -0500 Received: from mail-wm0-f52.google.com ([74.125.82.52]:34249 "EHLO mail-wm0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753234AbbKXOTv (ORCPT ); Tue, 24 Nov 2015 09:19:51 -0500 Date: Tue, 24 Nov 2015 15:19:47 +0100 From: Daniel Vetter To: Gerd Hoffmann Cc: Daniel Vetter , Alex Williamson , "igvt-g@ml01.01.org" , "Li, Susie" , "White, Michael L" , "Dong, Eddie" , "intel-gfx@lists.freedesktop.org" , "Reddy, Raghuveer" , "Cowperthwaite, David J" , "linux-kernel@vger.kernel.org" , "xen-devel@lists.xen.org" , qemu-devel , "Zhou, Chao" , Paolo Bonzini , "Zhu, Libo" , "Wang, Hongbo" Subject: Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel Message-ID: <20151124141946.GH17050@phenom.ffwll.local> Mail-Followup-To: Gerd Hoffmann , Alex Williamson , "igvt-g@ml01.01.org" , "Li, Susie" , "White, Michael L" , "Dong, Eddie" , "intel-gfx@lists.freedesktop.org" , "Reddy, Raghuveer" , "Cowperthwaite, David J" , "linux-kernel@vger.kernel.org" , "xen-devel@lists.xen.org" , qemu-devel , "Zhou, Chao" , Paolo Bonzini , "Zhu, Libo" , "Wang, Hongbo" References: <5527CEC4.9080700@intel.com> <559B3E38.1080707@intel.com> <562F4311.9@intel.com> <1447870341.4697.92.camel@redhat.com> <1447963356.4697.184.camel@redhat.com> <20151124111917.GO17050@phenom.ffwll.local> <1448368735.27648.110.camel@redhat.com> <20151124133135.GY17050@phenom.ffwll.local> <1448374351.27648.128.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1448374351.27648.128.camel@redhat.com> X-Operating-System: Linux phenom 4.1.0-2-amd64 User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2158 Lines: 45 On Tue, Nov 24, 2015 at 03:12:31PM +0100, Gerd Hoffmann wrote: > Hi, > > > But there's some work to add generic mmap support to dma-bufs, and for > > really simple case (where we don't have a gl driver to handle the dma-buf > > specially) for untiled framebuffers that would be all we need? > > 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. GL, wayland, X, EGL and soonish Android's surface flinger (hwc already has it afaik) all track damage. There's plans to add the same to the atomic kms api too. But if you do damage tracking you really don't want to support (maybe allow for perf reasons if the guest is stupid) frontbuffer rendering, which means you need buffer handles + damage, and not a static region. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- 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/