Re: [PATCH RFC] vfio: Move the saving of the config space to the right place in VFIO migration

> I have another question for this, if we restore the config space while in > pre-copy > (include enabling interrupts), does it affect the _RESUMING state (paused) of > the > device on the dst host (cause it to send interrupts? which should not be > allowed > in this stage). Does the restore sequence need to be further discussed and > reach > a consensus(spec) (taking into account other devices and the corresponding > actions > of the vendor driver)? > > > Given our timing relative to QEMU 5.2, the only path I feel comfortable > > with is to move forward with downgrading vfio migration support to be > > enabled via an experimental option. Objections? Thanks, > > Alright, but this issue is related to our ARM GICv4.1 migration scheme, could > you > give a rough idea about this (where to enable interrupts, we hope it to be > after > the restoring of VGIC)? I disagree. If this is only specific to Huawei ARM GIC implementation, why do we want to make the entire VFIO based migration an experimental feature? Thanks, Neo > > Thanks, > Shenming

Re: [RFC PATCH for-QEMU-5.2] vfio: Make migration support experimental

ice migration and even if the practical use > > >> cases are initially small, they will expand over time and hardware will > > >> get better. My objection is that the current behavior masks the > > >> hardware and device limitations, leading to unrealistic expecta

Re: [Qemu-devel] [PATCH 1/2] vfio/mdev: add version field as mandatory attribute for mdev device

compatibility case in the > first place, by only choosing to migrate to a host that we know is going > to be compatible. > > This would need some kind of way to report the full list of supported > versions against the mdev supported types on the host. What would be the typical scenario / use case for mgmt layer to query the version information? Do they expect this get done completely offline as long as the vendor driver installed on each host? Thanks, Neo > >

Re: [Qemu-devel] [PATCH v3 0/5] Add migration support for VFIO device

le / better to have Kirti focus on the QEMU patches and Yan take care GVT-g kernel driver side changes? This will give us the best testing coverage. Hope I don't step on anybody's toes here. ;-) Thanks, Neo > > Thanks > Kevin

Re: [Qemu-devel] [PATCH v14 00/22] Add Mediated device support

mode 100644 samples/vfio-mdev/mtty.c > > As discussed, I dropped patch 12, updated the documentation, and added > 'retries' initialization. This is now applied to my next branch for > v4.10. Thanks to the reviewers and Kirti and Neo for your hard work! Really appreciate your help and reviews to allow us reach here, and thanks to various reviewers for their comments and suggestions! Thanks, Neo > Thanks, > > Alex

Re: [Qemu-devel] [PATCH 1/2] KVM: page track: add a new notifier type: track_flush_slot

On Fri, Oct 14, 2016 at 10:51:24AM -0600, Alex Williamson wrote: > On Fri, 14 Oct 2016 09:35:45 -0700 > Neo Jia <c...@nvidia.com> wrote: > > > On Fri, Oct 14, 2016 at 08:46:01AM -0600, Alex Williamson wrote: > > > On Fri, 14 Oct 2016 08:41:58 -0600 >

Re: [Qemu-devel] [PATCH 1/2] KVM: page track: add a new notifier type: track_flush_slot

;>> > > > >>> > > > >>> On 11/10/2016 04:39, Xiao Guangrong wrote: > > > >>>> > > > >>>> > > > >>>> On 10/11/2016 02:32 AM, Paolo Bonzini wrote: > > > >>>>>

Re: [Qemu-devel] summary of current vfio mdev upstreaming status

Regarding the patch development and given the current status, especially where we are and what we have been through, I am very confident that we should be able to fully handle this ourselves, but thanks for offering help anyway! We should be able to react as fast as possible based on the public mai

Re: [Qemu-devel] summary of current vfio mdev upstreaming status

;gpu" which will pull several attributes as mandatory. Thanks, Neo > > > > PART 1: mdev core driver > > [task] > - the mdev bus/device support > - the utilities of mdev lifecycle management >

Re: [Qemu-devel] [libvirt] [RFC v2] libvirt vGPU QEMU integration

On Thu, Sep 29, 2016 at 09:03:40AM +0100, Daniel P. Berrange wrote: > On Wed, Sep 28, 2016 at 12:22:35PM -0700, Neo Jia wrote: > > On Thu, Sep 22, 2016 at 03:26:38PM +0100, Daniel P. Berrange wrote: > > > On Thu, Sep 22, 2016 at 08:19:21AM -0600, Alex Williamson wrote: > >

Re: [Qemu-devel] [libvirt] [RFC v2] libvirt vGPU QEMU integration

On Wed, Sep 28, 2016 at 04:31:25PM -0400, Laine Stump wrote: > On 09/28/2016 03:59 PM, Neo Jia wrote: > > On Wed, Sep 28, 2016 at 07:45:38PM +, Tian, Kevin wrote: > > > > From: Neo Jia [mailto:c...@nvidia.com] > > > > Sent: Thursday, September 29, 2016 3:23 A

Re: [Qemu-devel] [libvirt] [RFC v2] libvirt vGPU QEMU integration

On Wed, Sep 28, 2016 at 01:55:47PM -0600, Alex Williamson wrote: > On Wed, 28 Sep 2016 12:22:35 -0700 > Neo Jia <c...@nvidia.com> wrote: > > > On Thu, Sep 22, 2016 at 03:26:38PM +0100, Daniel P. Berrange wrote: > > > On Thu, Sep 22, 2016 at 08:19:21A

Re: [Qemu-devel] [libvirt] [RFC v2] libvirt vGPU QEMU integration

On Wed, Sep 28, 2016 at 07:45:38PM +, Tian, Kevin wrote: > > From: Neo Jia [mailto:c...@nvidia.com] > > Sent: Thursday, September 29, 2016 3:23 AM > > > > On Thu, Sep 22, 2016 at 03:26:38PM +0100, Daniel P. Berrange wrote: > > > On Thu, Sep 22, 2016 at 08:19:

Re: [Qemu-devel] [RFC v2] libvirt vGPU QEMU integration

e would be 'gpu'. The fb_length, > resolution, and heads parameters would only be mandatory > when class==gpu. > Hi Daniel, Here you are proposing to add a class named "gpu", which will make all those gpu related attributes mandatory, which libvirt can allow user to better par

Re: [Qemu-devel] [libvirt] [RFC v2] libvirt vGPU QEMU integration

On Thu, Sep 22, 2016 at 03:26:38PM +0100, Daniel P. Berrange wrote: > On Thu, Sep 22, 2016 at 08:19:21AM -0600, Alex Williamson wrote: > > On Thu, 22 Sep 2016 09:41:20 +0530 > > Kirti Wankhede wrote: > > > > > > My concern is that a type id seems arbitrary but we're

Re: [Qemu-devel] [PATCH v7 1/4] vfio: Mediated device Core driver

ow if vfio.ko, or vfio-pci.ko add a few new capabilities in > the future? Exactly my point about the code sharing. If new cap is added inside vfio.ko or vfio-pci.ko, we can just add it into vfio_mdev.ko. Adding the code in one place is better to duplicate in multiple vendor drive

Re: [Qemu-devel] [PATCH v7 0/4] Add Mediated device support

On Wed, Sep 07, 2016 at 07:27:19PM +0100, Daniel P. Berrange wrote: > On Wed, Sep 07, 2016 at 11:17:39AM -0700, Neo Jia wrote: > > On Wed, Sep 07, 2016 at 10:44:56AM -0600, Alex Williamson wrote: > > > On Wed, 7 Sep 2016 21:45:31 +0530 > > > Kirti Wankhede &

Re: [Qemu-devel] [PATCH v7 0/4] Add Mediated device support

t is why Kirti is proposing the "mdev group". Let's see if we can address your concerns / questions in Kirti's reply. Thanks, Neo > Thanks, > > Alex

Re: [Qemu-devel] [RFC v2 0/4] adding mdev bus and vfio support

t you in person in KVM forum couple weeks ago so we can have a better discussion. We are trying our best to accommodate almost all requirements / comments from use cases and code reviews while keeping little (or none) architectural changes between revisions. > We would be highly glad and thank

Re: [Qemu-devel] [RFC v2 4/4] docs: Add Documentation for Mediated devices

of > > mediated device framework. > > > > Signed-off-by: Kirti Wankhede <kwankh...@nvidia.com> > > Signed-off-by: Neo Jia <c...@nvidia.com> > > Signed-off-by: Jike Song <jike.s...@intel.com> > > --- > > Documentation/vfio-mediate

Re: [Qemu-devel] [RFC v2 0/4] adding mdev bus and vfio support

o best accommodate your requirements and needs in the future revisions. I believe that would be the best and fastest way to collaborate and that is the main purpose of having code review cycles. Thanks, Neo > > Alex > > > > > > > Key Changes from Nvidia v6: > &g

Re: [Qemu-devel] [libvirt] [RFC] libvirt vGPU QEMU integration

On Fri, Aug 19, 2016 at 03:22:48PM -0400, Laine Stump wrote: > On 08/18/2016 12:41 PM, Neo Jia wrote: > > Hi libvirt experts, > > > > I am starting this email thread to discuss the potential solution / > > proposal of > > integrating vGPU support i

Re: [Qemu-devel] [libvirt] [RFC] libvirt vGPU QEMU integration

On Fri, Aug 19, 2016 at 02:42:27PM +0200, Michal Privoznik wrote: > On 18.08.2016 18:41, Neo Jia wrote: > > Hi libvirt experts, > > Hi, welcome to the list. > > > > > I am starting this email thread to discuss the potential solution / > > proposal of >

[Qemu-devel] [RFC] libvirt vGPU QEMU integration

ot-unplug, after executing QEMU monitor "device del" command, libvirt needs to write to "destroy" sysfs to complete hot-unplug process. Since hot-plug is optional, then mdev_create or mdev_destroy operations may return an error if it is not supported. Thanks, Neo

Re: [Qemu-devel] [RFC v6-based v1 0/5] refine mdev framework

saves my work of mimicing the > vfio-mpci code in my vfio-mccw driver. I like this incremental patches. Thanks for sharing your progress and good to know our current v6 solution works for you. We are still evaluating the vfio_mdev changes here as I still prefer to share general VFIO pci handling

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

On Tue, Aug 16, 2016 at 02:51:03PM -0600, Alex Williamson wrote: > On Tue, 16 Aug 2016 13:30:06 -0700 > Neo Jia <c...@nvidia.com> wrote: > > > On Mon, Aug 15, 2016 at 04:47:41PM -0600, Alex Williamson wrote: > > > On Mon, 15 Aug 2016 12:59:08 -0700 > &g

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

On Mon, Aug 15, 2016 at 04:47:41PM -0600, Alex Williamson wrote: > On Mon, 15 Aug 2016 12:59:08 -0700 > Neo Jia <c...@nvidia.com> wrote: > > > > > > > > > > > I'm not sure a comma separated list makes sense here, for both > > > > > si

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

On Tue, Aug 16, 2016 at 05:58:54AM +, Tian, Kevin wrote: > > From: Neo Jia [mailto:c...@nvidia.com] > > Sent: Tuesday, August 16, 2016 1:44 PM > > > > On Tue, Aug 16, 2016 at 04:52:30AM +, Tian, Kevin wrote: > > > > From: Neo Jia [mailto:c...@nvidia.c

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

On Tue, Aug 16, 2016 at 04:52:30AM +, Tian, Kevin wrote: > > From: Neo Jia [mailto:c...@nvidia.com] > > Sent: Tuesday, August 16, 2016 12:17 PM > > > > On Tue, Aug 16, 2016 at 03:50:44AM +, Tian, Kevin wrote: > > > > From: Neo Jia [mailto:c...@nvidia.c

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

On Tue, Aug 16, 2016 at 03:50:44AM +, Tian, Kevin wrote: > > From: Neo Jia [mailto:c...@nvidia.com] > > Sent: Tuesday, August 16, 2016 11:46 AM > > > > On Tue, Aug 16, 2016 at 12:30:25AM +, Tian, Kevin wrote: > > > > From: Neo Jia [mailto:c...@nvidia.c

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

On Tue, Aug 16, 2016 at 12:30:25AM +, Tian, Kevin wrote: > > From: Neo Jia [mailto:c...@nvidia.com] > > Sent: Tuesday, August 16, 2016 3:59 AM > > > > > > > > For NVIDIA vGPU solution we need to know all devices assigned to a VM in > > > > on

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

On Mon, Aug 15, 2016 at 04:47:41PM -0600, Alex Williamson wrote: > On Mon, 15 Aug 2016 12:59:08 -0700 > Neo Jia <c...@nvidia.com> wrote: > > > On Mon, Aug 15, 2016 at 09:38:52AM +, Tian, Kevin wrote: > > > > From: Kirti Wankhede [mailto:kwankh...@nvidia.com]

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

On Mon, Aug 15, 2016 at 04:52:39PM -0600, Alex Williamson wrote: > On Mon, 15 Aug 2016 15:09:30 -0700 > Neo Jia <c...@nvidia.com> wrote: > > > On Mon, Aug 15, 2016 at 09:59:26AM -0600, Alex Williamson wrote: > > > On Mon, 15 Aug 2016 09:38:52 + > > > &qu

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

s like we're precluding hotplug from the design. I don't > understand what's driving this one-shot requirement. Hi Alex, The requirement here is based on how our internal vGPU device model designed and with this we are able to pre-allocate resources required for multiple virtual devices within same domain. And I don't think this syntax will stop us from supporting hotplug at all. For example, you can always create a virtual mdev and then do echo "mdev_UUID" > /sys/class/mdev/mdev_start then use QEMU monitor to add the device for hotplug. > > > As I relied in another mail, I really hope start/stop become a per-mdev > > attribute instead of global one, e.g.: > > > > echo "0/1" > /sys/class/mdev/12345678-1234-1234-1234-123456789abc/start > > > > In many scenario the user space client may only want to talk to mdev > > instance directly, w/o need to contact its parent device. Still take > > live migration for example, I don't think Qemu wants to know parent > > device of assigned mdev instances. > > Yep, QEMU won't know the parent device, only libvirt level tools > managing the creation and destruction of the mdev device would know > that. Perhaps in addition to migration uses we could even use > start/stop for basic power management, device D3 state in the guest > could translate to a stop command to remove that vGPU from scheduling > while still retaining most of the state and resource allocations. Just recap what I have replied to Kevin on his previous email, the current mdev_start and mdev_stop doesn't require any knowledge of parent device. Thanks, Neo > Thanks, > > Alex

Re: [Qemu-devel] [PATCH v6 1/4] vfio: Mediated device Core driver

gt; and then resume mdev activity on dest device after its state is recovered. > Intel has implemented experimental live migration support in KVMGT (soon > to release), based on above two interfaces (plus another two to get/set > mdev state). > > > > > > > > F

Re: [Qemu-devel] [RFC PATCH v4 1/3] Mediated device Core driver

On Wed, Jun 08, 2016 at 02:13:49PM +0800, Dong Jia wrote: > On Tue, 7 Jun 2016 20:48:42 -0700 > Neo Jia <c...@nvidia.com> wrote: > > > On Wed, Jun 08, 2016 at 11:18:42AM +0800, Dong Jia wrote: > > > On Tue, 7 Jun 2016 19:39:21 -0600 > > > Alex Willia

Re: [Qemu-devel] [RFC PATCH v4 1/3] Mediated device Core driver

> > > > > > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > > > > Sent: Tuesday, June 07, 2016 3:31 AM > > > > > > > > > > > > On Mon, 6 Jun 2016 10:44:25 -0700 > > > > &

Re: [Qemu-devel] [RFC PATCH v4 1/3] Mediated device Core driver

On Mon, Jun 06, 2016 at 04:29:11PM +0800, Dong Jia wrote: > On Sun, 5 Jun 2016 23:27:42 -0700 > Neo Jia <c...@nvidia.com> wrote: > > 2. VFIO_DEVICE_CCW_CMD_REQUEST > This intends to handle an intercepted channel I/O instruction. It > basically need to do the followi

Re: [Qemu-devel] [RFC PATCH v4 1/3] Mediated device Core driver

l reigister > the device and callbacks to mdev framework. With this, I could create > a mediated ccw device for the physical one then. > 2. A vfio-mccw driver for the mediated ccw device, which will add > itself to a vfio_group, mimiced what vfio-mpci did. > > The problem is, vfi

Re: [Qemu-devel] [RFC PATCH v4 3/3] VFIO Type1 IOMMU: Add support for mediated devices

ddr_t iova; > > + long pg_cnt = 1; > > + > > + iova = vaddr[i] << PAGE_SHIFT; > Dear Kirti: > > Got one question for the vaddr-iova conversion here. > Is this a common rule that can be applied to all architectures? > AFAIK, this is wrong for th

Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu

On Fri, May 13, 2016 at 05:23:44PM +0800, Jike Song wrote: > On 05/13/2016 04:31 PM, Neo Jia wrote: > > On Fri, May 13, 2016 at 07:45:14AM +, Tian, Kevin wrote: > >> > >> We use page tracking framework, which is newly added to KVM recently, > >> to mark RAM

Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu

On Fri, May 13, 2016 at 05:46:17PM +0800, Jike Song wrote: > On 05/13/2016 04:12 AM, Neo Jia wrote: > > On Thu, May 12, 2016 at 01:05:52PM -0600, Alex Williamson wrote: > >> > >> If you're trying to equate the scale of what we need to track vs what > >

Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu

On Fri, May 13, 2016 at 04:39:37PM +0800, Dong Jia wrote: > On Fri, 13 May 2016 00:24:34 -0700 > Neo Jia <c...@nvidia.com> wrote: > > > On Fri, May 13, 2016 at 03:10:22PM +0800, Dong Jia wrote: > > > On Thu, 12 May 2016 13:05:52 -0600 > > > Alex Willia

Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu

On Fri, May 13, 2016 at 08:02:41AM +, Tian, Kevin wrote: > > From: Neo Jia [mailto:c...@nvidia.com] > > Sent: Friday, May 13, 2016 3:38 PM > > > > On Fri, May 13, 2016 at 07:13:44AM +, Tian, Kevin wrote: > > > > From: Neo Jia [mailto:c...@nvidia.com]

Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu

On Fri, May 13, 2016 at 07:45:14AM +, Tian, Kevin wrote: > > From: Neo Jia [mailto:c...@nvidia.com] > > Sent: Friday, May 13, 2016 3:42 PM > > > > On Fri, May 13, 2016 at 03:30:27PM +0800, Jike Song wrote: > > > On 05/13/2016 02:43 PM, Neo Jia wrote: > >

Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu

On Fri, May 13, 2016 at 03:30:27PM +0800, Jike Song wrote: > On 05/13/2016 02:43 PM, Neo Jia wrote: > > On Fri, May 13, 2016 at 02:22:37PM +0800, Jike Song wrote: > >> On 05/13/2016 10:41 AM, Tian, Kevin wrote: > >>>> From: Neo Jia [mailto:c...@nvidia.com] Sent: Fr

Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu

On Fri, May 13, 2016 at 07:13:44AM +, Tian, Kevin wrote: > > From: Neo Jia [mailto:c...@nvidia.com] > > Sent: Friday, May 13, 2016 2:42 PM > > > > > > > > > > We possibly have the same requirement from the mediate driver backend: > > > &g

Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu

gt; > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > > > Sent: Thursday, May 12, 2016 6:06 AM > > > > > > > > On Wed, 11 May 2016 17:15:15 +0800 > > > > Jike Song <jike.s...@intel.com> wrote: > > > &

Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu

On Fri, May 13, 2016 at 02:22:37PM +0800, Jike Song wrote: > On 05/13/2016 10:41 AM, Tian, Kevin wrote: > >> From: Neo Jia [mailto:c...@nvidia.com] > >> Sent: Friday, May 13, 2016 3:49 AM > >> > >>> > >>>> Perhaps one possibility would be

Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu

On Fri, May 13, 2016 at 02:08:36PM +0800, Jike Song wrote: > On 05/13/2016 03:49 AM, Neo Jia wrote: > > On Thu, May 12, 2016 at 12:11:00PM +0800, Jike Song wrote: > >> On Thu, May 12, 2016 at 6:06 AM, Alex Williamson > >> <alex.william...@redhat.com> wrote: > &g

Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu

6 AM > > > > > > On Wed, 11 May 2016 17:15:15 +0800 > > > Jike Song <jike.s...@intel.com> wrote: > > > > > > > On 05/11/2016 12:02 AM, Neo Jia wrote: > > > > > On Tue, May 10, 2016 at 03:52:27PM +0800, Jike Song wrote: >

Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu

On Thu, May 12, 2016 at 12:11:00PM +0800, Jike Song wrote: > On Thu, May 12, 2016 at 6:06 AM, Alex Williamson > <alex.william...@redhat.com> wrote: > > On Wed, 11 May 2016 17:15:15 +0800 > > Jike Song <jike.s...@intel.com> wrote: > > > >> On 05/11/201

Re: [Qemu-devel] [RFC PATCH v3 3/3] VFIO Type1 IOMMU change: to support with iommu and without iommu

u case, since > > that fact is out of GPU driver control. A simple way is to use > > dma_map_page which internally will cope with w/ and w/o iommu > > case gracefully, i.e. return HPA w/o iommu and IOVA w/ iommu. > > Then in this file we only need to cache GPA to whatever dm

Re: [Qemu-devel] [PATCH RFC 0/8] basic vfio-ccw infrastructure

standing of your proposal, I should do: > > > > #1. Introduce a vfio_iommu_type1_ccw as the vfio iommu backend for ccw. > > When starting the guest, pin all of guest memory, and form the database. > > I hope that we

Re: [Qemu-devel] [RFC PATCH v3 2/3] VFIO driver for vGPU device

gt; the vendor driver determines what this maps to, do they compare it to > > > > the physical device's own BAR addresses? > > > > > > I didn't quite understand too. Based on earlier discussion, do we need > > > something like this, or could achieve the purpos

Re: [Qemu-devel] [RFC PATCH v3 2/3] VFIO driver for vGPU device

ike a real device, since > > there may be no physical config space implemented for each vGPU. > > So anyway vendor vGPU driver needs to create/emulate the virtualized > > config space while the way how is created might be vendor specific. > > So better to keep the interface

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

IO 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 n

Re: [Qemu-devel] [RFC PATCH v2 3/3] VFIO: Type1 IOMMU mapping support for vGPU

On Fri, Mar 11, 2016 at 10:56:24AM -0700, Alex Williamson wrote: > On Fri, 11 Mar 2016 08:55:44 -0800 > Neo Jia <c...@nvidia.com> wrote: > > > > > Alex, what's your opinion on this? > > > > > > The sticky point is how vfio, which is only handling th

Re: [Qemu-devel] [RFC PATCH v2 3/3] VFIO: Type1 IOMMU mapping support for vGPU

On Fri, Mar 11, 2016 at 09:13:15AM -0700, Alex Williamson wrote: > On Fri, 11 Mar 2016 04:46:23 + > "Tian, Kevin" <kevin.t...@intel.com> wrote: > > > > From: Neo Jia [mailto:c...@nvidia.com] > > > Sent: Friday, March 11, 2016 12:20 PM > >

Re: [Qemu-devel] [RFC PATCH v2 3/3] VFIO: Type1 IOMMU mapping support for vGPU

On Fri, Mar 11, 2016 at 04:46:23AM +, Tian, Kevin wrote: > > From: Neo Jia [mailto:c...@nvidia.com] > > Sent: Friday, March 11, 2016 12:20 PM > > > > On Thu, Mar 10, 2016 at 11:10:10AM +0800, Jike Song wrote: > > > > > > >> Is it supposed t

Re: [Qemu-devel] [RFC PATCH v2 3/3] VFIO: Type1 IOMMU mapping support for vGPU

real GPU should be managed by the GPU vendor driver. With the default TYPE1 IOMMU, it works with the vfio-pci as it owns the device. Thanks, Neo > -- > Thanks, > Jike >

Re: [Qemu-devel] [RFC PATCH v2 3/3] VFIO: Type1 IOMMU mapping support for vGPU

On Mon, Mar 07, 2016 at 02:07:15PM +0800, Jike Song wrote: > Hi Neo, > > On Fri, Mar 4, 2016 at 3:00 PM, Neo Jia <c...@nvidia.com> wrote: > > On Wed, Mar 02, 2016 at 04:38:34PM +0800, Jike Song wrote: > >> On 02/24/2016 12:24 AM, Kirti Wankhede wrote: > &g

Re: [Qemu-devel] [RFC PATCH v2 3/3] VFIO: Type1 IOMMU mapping support for vGPU

On Wed, Mar 02, 2016 at 04:38:34PM +0800, Jike Song wrote: > On 02/24/2016 12:24 AM, Kirti Wankhede wrote: > > + vgpu_dma->size = map->size; > > + > > + vgpu_link_dma(vgpu_iommu, vgpu_dma); > > Hi Kirti & Neo, > > seems that no one actually setup

Re: [Qemu-devel] [RFC PATCH v2 1/3] vGPU Core driver

On Mon, Feb 29, 2016 at 05:39:02AM +, Tian, Kevin wrote: > > From: Kirti Wankhede > > Sent: Wednesday, February 24, 2016 12:24 AM > > > > Signed-off-by: Kirti Wankhede <kwankh...@nvidia.com> > > Signed-off-by: Neo Jia <c...@nvidia.com> > >

[Qemu-devel] [PATCH v2] replace fixed str limit by g_strdup_printf

A trivial change to remove string limit by using g_strdup_printf Tested-by: Neo Jia <c...@nvidia.com> Signed-off-by: Neo Jia <c...@nvidia.com> Signed-off-by: Kirti Wankhede <kwankh...@nvidia.com> --- hw/vfio/pci.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) di

[Qemu-devel] [PATCH] replace fixed str limit by g_strdup_printf

A trivial change to remove string limit by using g_strdup_printf and g_strconcat Tested-by: Neo Jia <c...@nvidia.com> Signed-off-by: Neo Jia <c...@nvidia.com> Signed-off-by: Kirti Wankhede <kwankh...@nvidia.com> --- hw/vfio/pci.c | 19 --- 1 file changed, 1

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

gt; You can use uuids to name the vgpus if you want of course. But the vgpu > uuid will will have no relationship whatsoever to the vm uuid then. > Agree. I should made it clear that it should be a separate object. Thanks, Neo > cheers, > Gerd >

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

On Wed, Feb 17, 2016 at 09:52:04AM +, Tian, Kevin wrote: > > From: Neo Jia [mailto:c...@nvidia.com] > > Sent: Wednesday, February 17, 2016 5:35 PM > > > > On Wed, Feb 17, 2016 at 08:57:08AM +, Tian, Kevin wrote: > > > > From: Neo Jia [mailto:c...

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

On Wed, Feb 17, 2016 at 08:57:08AM +, Tian, Kevin wrote: > > From: Neo Jia [mailto:c...@nvidia.com] > > Sent: Wednesday, February 17, 2016 3:55 PM > > 'whoever' is too strict here. I don't think UUID is required in all scenarios. > > In your scenario: > >

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

On Wed, Feb 17, 2016 at 07:51:12AM +, Tian, Kevin wrote: > > From: Neo Jia [mailto:c...@nvidia.com] > > Sent: Wednesday, February 17, 2016 3:32 PM > > > > On Wed, Feb 17, 2016 at 07:52:53AM +0100, Gerd Hoffmann wrote: > > > Hi, > > > > >

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

On Wed, Feb 17, 2016 at 07:46:15AM +, Tian, Kevin wrote: > > From: Neo Jia > > Sent: Wednesday, February 17, 2016 3:26 PM > > > > > > > > > If your most concern is having this kind of path doesn't provide enough > > information of the virtual de

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

is that having the UUID as part of the virtual vgpu device path will allow whoever is going to config the QEMU to automatically discover the virtual device sysfs for free. Thanks, Neo > > cheers, > Gerd >

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

On Wed, Feb 17, 2016 at 06:02:36AM +, Tian, Kevin wrote: > > From: Neo Jia > > Sent: Wednesday, February 17, 2016 1:38 PM > > > > > > > > > > > > > > > > > > Hi Kevin, > > > > > > > > The answer is simp

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

ad, but getting worse with > each iteration due to excessive quoting. > Hi Eric, Sorry about that, I will pay attention to this. Thanks, Neo > -- > Eric Blake eblake redhat com+1-919-301-3266 > Libvirt virtualization library http://libvirt.org > > > * Unknown Key > * 0x2527436A

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

On Wed, Feb 17, 2016 at 05:04:31AM +, Tian, Kevin wrote: > > From: Neo Jia > > Sent: Wednesday, February 17, 2016 12:18 PM > > > > On Wed, Feb 17, 2016 at 03:31:24AM +, Tian, Kevin wrote: > > > > From: Neo Jia [mailto:c...@nvidia.com] > > &g

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

On Wed, Feb 17, 2016 at 03:31:24AM +, Tian, Kevin wrote: > > From: Neo Jia [mailto:c...@nvidia.com] > > Sent: Tuesday, February 16, 2016 4:49 PM > > > > On Tue, Feb 16, 2016 at 08:10:42AM +, Tian, Kevin wrote: > > > > From: Neo Jia [mailto:c...@nvidia.

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

On Tue, Feb 16, 2016 at 08:10:42AM +, Tian, Kevin wrote: > > From: Neo Jia [mailto:c...@nvidia.com] > > Sent: Tuesday, February 16, 2016 3:53 PM > > > > On Tue, Feb 16, 2016 at 07:40:47AM +, Tian, Kevin wrote: > > > > From: Neo Jia [mailto:c...@nvidia.

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

On Tue, Feb 16, 2016 at 07:40:47AM +, Tian, Kevin wrote: > > From: Neo Jia [mailto:c...@nvidia.com] > > Sent: Tuesday, February 16, 2016 3:37 PM > > > > On Tue, Feb 16, 2016 at 07:27:09AM +, Tian, Kevin wrote: > > > > From: Neo Jia [mailto:c...@nvidia.

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

On Tue, Feb 16, 2016 at 07:27:09AM +, Tian, Kevin wrote: > > From: Neo Jia [mailto:c...@nvidia.com] > > Sent: Tuesday, February 16, 2016 3:13 PM > > > > On Tue, Feb 16, 2016 at 06:49:30AM +, Tian, Kevin wrote: > > > > From: Alex Williamson [mailto:alex

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

ID has any implicit meaning like > > matching the VM UUID.  Having an index within a UUID bothers me a bit, > > but it doesn't seem like too much of a concession to enable the use case > > that NVIDIA is trying to achieve.  Thanks, > > > > I would prefer to making UUID an optional parameter, while not tieing > sysfs vgpu naming to UUID. This would be more flexible to different > scenarios where UUID might not be required. Hi Kevin, Happy Chinese New Year! I think having UUID as the vgpu device name will allow us to have an gpu vendor agnostic solution for the upper layer software stack such as QEMU, who is supposed to open the device. Thanks, Neo > > Thanks > Kevin

Re: [Qemu-devel] RE: [iGVT-g] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...)

(such as exit-less emulation, pin/unpin, etc.). Another thing we need > to think is whether this new design is still compatible to Xen side. > > Thanks a lot all for the great discussion (especially Alex with many good > inputs)! I believe it becomes much clearer now than 2 weeks ago, about > how to integrate KVMGT with VFIO. :-) > It is great to see you guys are onboard with VFIO solution! As Kirti has mentioned in other threads, let's review the current registration APIs and figure out what we need to add for both solutions. Thanks, Neo > Thanks > Kevin > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] [iGVT-g] RE: VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...)

y head, after thinking about the role of VFIO: > > For above 7 services required by vGPU device model, they can fall into > two categories: > > a) services to connect vGPU with VM, which are essentially what a device > driver is doing (so VFIO can fit here), including: > 1)

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

comment gets lost in our previous long email thread. Thanks, Neo > > cheers, > Gerd >

Re: [Qemu-devel] [RFC PATCH v1 1/1] vGPU core driver : to provide common interface for vGPU.

On Tue, Feb 02, 2016 at 08:18:44AM +, Tian, Kevin wrote: > > From: Neo Jia [mailto:c...@nvidia.com] > > Sent: Tuesday, February 02, 2016 4:13 PM > > > > On Tue, Feb 02, 2016 at 09:00:43AM +0100, Gerd Hoffmann wrote: > > > Hi, > > > > >

Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...)

On Wed, Jan 27, 2016 at 09:10:16AM -0700, Alex Williamson wrote: > On Wed, 2016-01-27 at 01:14 -0800, Neo Jia wrote: > > On Tue, Jan 26, 2016 at 04:30:38PM -0700, Alex Williamson wrote: > > > On Tue, 2016-01-26 at 14:28 -0800, Neo Jia wrote: > > > > On Tue, Jan 26,

Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...)

On Tue, Jan 26, 2016 at 04:30:38PM -0700, Alex Williamson wrote: > On Tue, 2016-01-26 at 14:28 -0800, Neo Jia wrote: > > On Tue, Jan 26, 2016 at 01:06:13PM -0700, Alex Williamson wrote: > > > > 1.1 Under per-

Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...)

On Mon, Jan 25, 2016 at 09:45:14PM +, Tian, Kevin wrote: > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Tuesday, January 26, 2016 5:30 AM > > > > [cc +Neo @Nvidia] > > > > Hi Jike, > > > > On Mon, 2016-01-25 at 19:34 +

Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...)

On Mon, Jan 25, 2016 at 09:45:14PM +, Tian, Kevin wrote: > > From: Alex Williamson [mailto:alex.william...@redhat.com] > > Sent: Tuesday, January 26, 2016 5:30 AM > > > > [cc +Neo @Nvidia] > > > > Hi Jike, > > > > On Mon, 2016-01-25 at 19:34 +

Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...)

On Tue, Jan 26, 2016 at 07:24:52PM +, Tian, Kevin wrote: > > From: Neo Jia [mailto:c...@nvidia.com] > > Sent: Tuesday, January 26, 2016 6:21 PM > > > > 0. High level overview > > = > >

Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...)

Song wrote: > > > > On 01/26/2016 05:30 AM, Alex Williamson wrote: > > > > > [cc +Neo @Nvidia] > > > > > > > > > > Hi Jike, > > > > > > > > > > On Mon, 2016-01-25 at 19:34 +0800, Jike Song wrote: > >

Re: [Qemu-devel] VFIO based vGPU(was Re: [Announcement] 2015-Q3 release of XenGT - a Mediated ...)

On Tue, Jan 26, 2016 at 01:06:13PM -0700, Alex Williamson wrote: > On Tue, 2016-01-26 at 02:20 -0800, Neo Jia wrote: > > On Mon, Jan 25, 2016 at 09:45:14PM +, Tian, Kevin wrote: > > > > From: Alex Williamson [mailto:alex.william...@redhat.com] > >  > > Hi Alex

[Qemu-devel] [Bug 1248427] [NEW] weather qemu-img convert will support -s option in the newer version

Public bug reported: In ubuntu os, my qemu-img version is 0.12.0 and its help message show that qemu-img convert command supports -s option, but it disappeared in qemu-img 0.12.1. However, though it disappeared, it does support in RHEL6.4, and the rpm version is

[Qemu-devel] [Bug 1248427] Re: weather qemu-img convert will support -s option in the newer version

Hi Serge, you are right. I have reported this issue to redhat. They said that RHEL 6.5 have removed this option. https://bugzilla.redhat.com/show_bug.cgi?id=1027074 ** Bug watch added: Red Hat Bugzilla #1027074 https://bugzilla.redhat.com/show_bug.cgi?id=1027074 ** Summary changed: -

[Qemu-devel] Windows guest debugging on KVM/Qemu

/msg21145.html). Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using!

[Qemu-devel] Windows guest debugging on KVM/Qemu

/msg21145.html). Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using!

[Qemu-devel] Re: guest kernel debugging through serial port

Here is what I have asked before. The problem that I want to assign a real serial port to the guest is that the debugging through network becomes really slow. Thanks, Neo On Thu, Mar 11, 2010 at 2:44 AM, Neo Jia neo...@gmail.com wrote: hi, I have followed the windows guest debugging procedure

[Qemu-devel] guest kernel debugging through serial port

can't talk to it from my dev machine that has connected to ttyS1 with target machine (host). Is this a known problem? Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using!

[Qemu-devel] Could not initialize SDL (kqemu)

hi, When I am trying to using kqemu on my IA32 linux, it throws out Could not initialize SDL -- exiting. Could you help me to figure it out? Thanks, Neo -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using!

[Qemu-devel] How can qemu to generate a signal 0 on i386 target (Linux) and i386 host?

/gdb/2004-03/msg1.html, it seems that this signal is generated from the qemu instead of sent by the bottom hardware. So, I am wondering if there is anybody can point me to the code of qemu, which will take care those signals. Thanks, Neo -- I would remember that if researchers were

[Qemu-devel] Re: How to debug Linux kernel on qemu with kgdb?

On 4/25/07, Jan Kiszka [EMAIL PROTECTED] wrote: Neo Jia wrote: hi, I am trying to use debug kgdb patched linux kernel on my qemu. Both the native and target platform are IA32. I am wondering if there is anyone can show me the procedure? Yep, see https://mail.gna.org/public/xenomai-core

  1   2   >