qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v3 0/3] Add vGPU support


From: Alex Williamson
Subject: Re: [Qemu-devel] [RFC PATCH v3 0/3] Add vGPU support
Date: Wed, 4 May 2016 11:07:55 -0600

On Tue, 3 May 2016 23:17:24 -0700
Neo Jia <address@hidden> wrote:

> On Wed, May 04, 2016 at 01:05:36AM +0000, Tian, Kevin wrote:
> > > From: Kirti Wankhede
> > > Sent: Tuesday, May 03, 2016 2:41 AM
> > > 
> > > This series adds vGPU support to v4.6 Linux host kernel. Purpose of this 
> > > series
> > > is to provide a common interface for vGPU management that can be used
> > > by different GPU drivers. This series introduces vGPU core module that 
> > > create
> > > and manage vGPU devices, VFIO based driver for vGPU devices that are 
> > > created by
> > > vGPU core module and update VFIO type1 IOMMU module to support vGPU 
> > > devices.
> > > 
> > > What's new in v3?
> > > VFIO type1 IOMMU module supports devices which are IOMMU capable. This 
> > > version
> > > of patched adds support for vGPU devices, which are not IOMMU capable, to 
> > > use
> > > existing VFIO IOMMU module. VFIO Type1 IOMMU patch provide new set of 
> > > APIs for
> > > guest page translation.
> > > 
> > > What's left to do?
> > > VFIO driver for vGPU device doesn't support devices with MSI-X enabled.
> > > 
> > > Please review.
> > >   
> > 
> > Thanks Kirti/Neo for your nice work! We are integrating this common
> > framework with KVMGT. Once ready it'll be released as an experimental
> > feature in our next community release.
> > 
> > One curious question. There are some additional changes in our side.
> > What is the best way to collaborate our effort before this series is
> > accepted in upstream kernel? Do you prefer to receiving patches from
> > us directly, or having it hosted some place so both sides can contribute?  
> 
> Yes, sending it directly to Kirti and myself will work the best, we can sort
> out this process offline.

Please do it online, in the open, on public mailing lists.  We
specifically do not want to develop the interfaces in private.  Thanks,

Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]