From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Williamson Subject: Re: VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...) Date: Tue, 26 Jan 2016 15:27:30 -0700 Message-ID: <1453847250.18049.5.camel@redhat.com> References: <569C5071.6080004@intel.com> <1453092476.32741.67.camel@redhat.com> <569CA8AD.6070200@intel.com> <1453143919.32741.169.camel@redhat.com> <569F4C86.2070501@intel.com> <56A6083E.10703@intel.com> <1453757426.32741.614.camel@redhat.com> <56A72313.9030009@intel.com> <56A77D2D.40109@gmail.com> <1453826249.26652.54.camel@redhat.com> <1453844613.18049.1.camel@redhat.com> <1453846073.18049.3.camel@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: "Ruan, Shuai" , Neo Jia , "kvm@vger.kernel.org" , "igvt-g@lists.01.org" , qemu-devel , Gerd Hoffmann , Paolo Bonzini , "Lv, Zhiyuan" To: "Tian, Kevin" , Yang Zhang , "Song, Jike" Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On Tue, 2016-01-26 at 22:15 +0000, Tian, Kevin wrote: > > From: Alex Williamson [mailto:alex.williamson@redhat.com] > > Sent: Wednesday, January 27, 2016 6:08 AM > >=C2=A0 > > > > > >=C2=A0 > > > > >=C2=A0 > > > > > Today KVMGT (not using VFIO yet) registers I/O emulation callba= cks to > > > > > KVM, so VM MMIO access will be forwarded to KVMGT directly for > > > > > emulation in kernel. If we reuse above R/W flags, the whole emu= lation > > > > > path would be unnecessarily long with obvious performance impac= t. We > > > > > either need a new flag here to indicate in-kernel emulation (bi= as from > > > > > passthrough support), or just hide the region alternatively (le= t KVMGT > > > > > to handle I/O emulation itself like today). > > > >=C2=A0 > > > > That sounds like a future optimization TBH.=C2=A0=C2=A0There's ve= ry strict > > > > layering between vfio and kvm.=C2=A0=C2=A0Physical device assignm= ent could make > > > > use of it as well, avoiding a round trip through userspace when a= n > > > > ioread/write would do.=C2=A0=C2=A0Userspace also needs to orchest= rate those kinds > > > > of accelerators, there might be cases where userspace wants to se= e those > > > > transactions for debugging or manipulating the device.=C2=A0=C2=A0= We can't simply > > > > take shortcuts to provide such direct access.=C2=A0=C2=A0Thanks, > > > >=C2=A0 > > >=C2=A0 > > > But we have to balance such debugging flexibility and acceptable pe= rformance. > > > To me the latter one is more important otherwise there'd be no real= usage > > > around this technique, while for debugging there are other alternat= ive (e.g. > > > ftrace) Consider some extreme case with 100k traps/second and then = see > > > how much impact a 2-3x longer emulation path can bring... > >=C2=A0 > > Are you jumping to the conclusion that it cannot be done with proper > > layering in place?=C2=A0=C2=A0Performance is important, but it's not = an excuse to > > abandon designing interfaces between independent components.=C2=A0=C2= =A0Thanks, > >=C2=A0 >=C2=A0 > Two are not controversial. My point is to remove unnecessary long trip > as possible. After another thought, yes we can reuse existing read/writ= e > flags: >=C2=A0 - KVMGT will expose a private control variable whether in-kernel > delivery is required; But in-kernel delivery is never *required*.=C2=A0=C2=A0Wouldn't userspace= want to deliver in-kernel any time it possibly could? >=C2=A0 - when the variable is true, KVMGT will register in-kernel MMIO=C2= =A0 > emulation callbacks then VM MMIO request will be delivered to KVMGT=C2=A0 > directly; >=C2=A0 - when the variable is false, KVMGT will not register anything.=C2= =A0 > VM MMIO request will then be delivered to Qemu and then ioread/write > will be used to finally reach KVMGT emulation logic; No, that means the interface is entirely dependent on a backdoor through KVM.=C2=A0=C2=A0Why can't userspace (QEMU) do something like register an = MMIO region with KVM handled via a provided file descriptor and offset, couldn't KVM then call the file ops without a kernel exit?=C2=A0=C2=A0Tha= nks, Alex