[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release
From: |
Tian, Kevin |
Subject: |
Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...) |
Date: |
Tue, 26 Jan 2016 22:15:43 +0000 |
> From: Alex Williamson [mailto:address@hidden
> Sent: Wednesday, January 27, 2016 6:08 AM
>
> > > > >
> > > >
> > > > Today KVMGT (not using VFIO yet) registers I/O emulation callbacks 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 emulation
> > > > path would be unnecessarily long with obvious performance impact. We
> > > > either need a new flag here to indicate in-kernel emulation (bias from
> > > > passthrough support), or just hide the region alternatively (let KVMGT
> > > > to handle I/O emulation itself like today).
> > >
> > > That sounds like a future optimization TBH. There's very strict
> > > layering between vfio and kvm. Physical device assignment could make
> > > use of it as well, avoiding a round trip through userspace when an
> > > ioread/write would do. Userspace also needs to orchestrate those kinds
> > > of accelerators, there might be cases where userspace wants to see those
> > > transactions for debugging or manipulating the device. We can't simply
> > > take shortcuts to provide such direct access. Thanks,
> > >
> >
> > But we have to balance such debugging flexibility and acceptable
> > performance.
> > To me the latter one is more important otherwise there'd be no real usage
> > around this technique, while for debugging there are other alternative (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...
>
> Are you jumping to the conclusion that it cannot be done with proper
> layering in place? Performance is important, but it's not an excuse to
> abandon designing interfaces between independent components. Thanks,
>
Two are not controversial. My point is to remove unnecessary long trip
as possible. After another thought, yes we can reuse existing read/write
flags:
- KVMGT will expose a private control variable whether in-kernel
delivery is required;
- when the variable is true, KVMGT will register in-kernel MMIO
emulation callbacks then VM MMIO request will be delivered to KVMGT
directly;
- when the variable is false, KVMGT will not register anything.
VM MMIO request will then be delivered to Qemu and then ioread/write
will be used to finally reach KVMGT emulation logic;
Thanks
Kevin
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), (continued)
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Kirti Wankhede, 2016/01/27
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Jike Song, 2016/01/26
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Yang Zhang, 2016/01/26
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Alex Williamson, 2016/01/26
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Tian, Kevin, 2016/01/26
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Neo Jia, 2016/01/26
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Tian, Kevin, 2016/01/26
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Alex Williamson, 2016/01/26
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Tian, Kevin, 2016/01/26
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Alex Williamson, 2016/01/26
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...),
Tian, Kevin <=
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Alex Williamson, 2016/01/26
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Tian, Kevin, 2016/01/26
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Alex Williamson, 2016/01/26
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Jike Song, 2016/01/26
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Alex Williamson, 2016/01/26
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Jike Song, 2016/01/27
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Alex Williamson, 2016/01/27
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Jike Song, 2016/01/28
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Alex Williamson, 2016/01/28
- Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...), Jike Song, 2016/01/29