From: Alex Williamson <alex.williamson@redhat.com>
To: Jike Song <jike.song@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
"Tian, Kevin" <kevin.tian@intel.com>, Neo Jia <cjia@nvidia.com>,
kvm@vger.kernel.org, guangrong.xiao@intel.com,
Xiaoguang Chen <xiaoguang.chen@intel.com>,
qemu-devel <qemu-devel@nongnu.org>,
Kirti Wankhede <kwankhede@nvidia.com>,
Xiao Guangrong <guangrong.xiao@linux.intel.com>
Subject: Re: [Qemu-devel] [PATCH 1/2] KVM: page track: add a new notifier type: track_flush_slot
Date: Fri, 14 Oct 2016 08:46:01 -0600 [thread overview]
Message-ID: <20161014084601.2a50ba87@t450s.home> (raw)
In-Reply-To: <20161014084158.623087aa@t450s.home>
On Fri, 14 Oct 2016 08:41:58 -0600
Alex Williamson <alex.williamson@redhat.com> wrote:
> On Fri, 14 Oct 2016 18:37:45 +0800
> Jike Song <jike.song@intel.com> wrote:
>
> > On 10/11/2016 05:47 PM, Paolo Bonzini wrote:
> > >
> > >
> > > On 11/10/2016 11:21, Xiao Guangrong wrote:
> > >>
> > >>
> > >> On 10/11/2016 04:54 PM, Paolo Bonzini wrote:
> > >>>
> > >>>
> > >>> On 11/10/2016 04:39, Xiao Guangrong wrote:
> > >>>>
> > >>>>
> > >>>> On 10/11/2016 02:32 AM, Paolo Bonzini wrote:
> > >>>>>
> > >>>>>
> > >>>>> On 10/10/2016 20:01, Neo Jia wrote:
> > >>>>>>> Hi Neo,
> > >>>>>>>
> > >>>>>>> AFAIK this is needed because KVMGT doesn't paravirtualize the PPGTT,
> > >>>>>>> while nVidia does.
> > >>>>>>
> > >>>>>> Hi Paolo and Xiaoguang,
> > >>>>>>
> > >>>>>> I am just wondering how device driver can register a notifier so he
> > >>>>>> can be
> > >>>>>> notified for write-protected pages when writes are happening.
> > >>>>>
> > >>>>> It can't yet, but the API is ready for that. kvm_vfio_set_group is
> > >>>>> currently where a struct kvm_device* and struct vfio_group* touch.
> > >>>>> Given
> > >>>>> a struct kvm_device*, dev->kvm provides the struct kvm to be passed to
> > >>>>> kvm_page_track_register_notifier. So I guess you could add a callback
> > >>>>> that passes the struct kvm_device* to the mdev device.
> > >>>>>
> > >>>>> Xiaoguang and Guangrong, what were your plans? We discussed it briefly
> > >>>>> at KVM Forum but I don't remember the details.
> > >>>>
> > >>>> Your suggestion was that pass kvm fd to KVMGT via VFIO, so that we can
> > >>>> figure out the kvm instance based on the fd.
> > >>>>
> > >>>> We got a new idea, how about search the kvm instance by mm_struct, it
> > >>>> can work as KVMGT is running in the vcpu context and it is much more
> > >>>> straightforward.
> > >>>
> > >>> Perhaps I didn't understand your suggestion, but the same mm_struct can
> > >>> have more than 1 struct kvm so I'm not sure that it can work.
> > >>
> > >> vcpu->pid is valid during vcpu running so that it can be used to figure
> > >> out which kvm instance owns the vcpu whose pid is the one as current
> > >> thread, i think it can work. :)
> > >
> > > No, don't do that. There's no reason for a thread to run a single VCPU,
> > > and if you can have multiple VCPUs you can also have multiple VCPUs from
> > > multiple VMs.
> > >
> > > Passing file descriptors around are the right way to connect subsystems.
> >
> > [CC Alex, Kevin and Qemu-devel]
> >
> > Hi Paolo & Alex,
> >
> > IIUC, passing file descriptors means touching QEMU and the UAPI between
> > QEMU and VFIO. Would you guys have a look at below draft patch? If it's
> > on the correct direction, I'll send the split ones. Thanks!
> >
> > --
> > Thanks,
> > Jike
> >
> >
> > diff --git a/hw/vfio/pci-quirks.c b/hw/vfio/pci-quirks.c
> > index bec694c..f715d37 100644
> > --- a/hw/vfio/pci-quirks.c
> > +++ b/hw/vfio/pci-quirks.c
> > @@ -10,12 +10,14 @@
> > * the COPYING file in the top-level directory.
> > */
> >
> > +#include <sys/ioctl.h>
> > #include "qemu/osdep.h"
> > #include "qemu/error-report.h"
> > #include "qemu/range.h"
> > #include "qapi/error.h"
> > #include "hw/nvram/fw_cfg.h"
> > #include "pci.h"
> > +#include "sysemu/kvm.h"
> > #include "trace.h"
> >
> > /* Use uin32_t for vendor & device so PCI_ANY_ID expands and cannot match hw */
> > @@ -1844,3 +1846,15 @@ void vfio_setup_resetfn_quirk(VFIOPCIDevice *vdev)
> > break;
> > }
> > }
> > +
> > +void vfio_quirk_kvmgt(VFIOPCIDevice *vdev)
> > +{
> > + int vmfd;
> > +
> > + if (!kvm_enabled() || !vdev->kvmgt)
> > + return;
> > +
> > + /* Tell the device what KVM it attached */
> > + vmfd = kvm_get_vmfd(kvm_state);
> > + ioctl(vdev->vbasedev.fd, VFIO_SET_KVMFD, vmfd);
> > +}
> > diff --git a/hw/vfio/pci.c b/hw/vfio/pci.c
> > index a5a620a..8732552 100644
> > --- a/hw/vfio/pci.c
> > +++ b/hw/vfio/pci.c
> > @@ -2561,6 +2561,8 @@ static int vfio_initfn(PCIDevice *pdev)
> > return ret;
> > }
> >
> > + vfio_quirk_kvmgt(vdev);
> > +
> > /* Get a copy of config space */
> > ret = pread(vdev->vbasedev.fd, vdev->pdev.config,
> > MIN(pci_config_size(&vdev->pdev), vdev->config_size),
> > @@ -2832,6 +2834,7 @@ static Property vfio_pci_dev_properties[] = {
> > DEFINE_PROP_UINT32("x-pci-sub-device-id", VFIOPCIDevice,
> > sub_device_id, PCI_ANY_ID),
> > DEFINE_PROP_UINT32("x-igd-gms", VFIOPCIDevice, igd_gms, 0),
> > + DEFINE_PROP_BOOL("kvmgt", VFIOPCIDevice, kvmgt, false),
>
> Just a side note, device options are a headache, users are prone to get
> them wrong and minimally it requires an entire round to get libvirt
> support. We should be able to detect from the device or vfio API
> whether such a call is required. Obviously if we can use the existing
> kvm-vfio device, that's the better option anyway. Thanks,
Also, vfio devices currently have no hard dependencies on KVM, if kvmgt
does, it needs to produce a device failure when unavailable. Thanks,
Alex
> > /*
> > * TODO - support passed fds... is this necessary?
> > * DEFINE_PROP_STRING("vfiofd", VFIOPCIDevice, vfiofd_name),
> > diff --git a/hw/vfio/pci.h b/hw/vfio/pci.h
> > index 7d482d9..813832c 100644
> > --- a/hw/vfio/pci.h
> > +++ b/hw/vfio/pci.h
> > @@ -143,6 +143,7 @@ typedef struct VFIOPCIDevice {
> > bool no_kvm_intx;
> > bool no_kvm_msi;
> > bool no_kvm_msix;
> > + bool kvmgt;
> > } VFIOPCIDevice;
> >
> > uint32_t vfio_pci_read_config(PCIDevice *pdev, uint32_t addr, int len);
> > @@ -166,4 +167,6 @@ int vfio_populate_vga(VFIOPCIDevice *vdev);
> > int vfio_pci_igd_opregion_init(VFIOPCIDevice *vdev,
> > struct vfio_region_info *info);
> >
> > +void vfio_quirk_kvmgt(VFIOPCIDevice *vdev);
> > +
> > #endif /* HW_VFIO_VFIO_PCI_H */
> > diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
> > index df67cc0..dd8320a 100644
> > --- a/include/sysemu/kvm.h
> > +++ b/include/sysemu/kvm.h
> > @@ -254,6 +254,7 @@ void phys_mem_set_alloc(void *(*alloc)(size_t, uint64_t *align));
> > int kvm_ioctl(KVMState *s, int type, ...);
> >
> > int kvm_vm_ioctl(KVMState *s, int type, ...);
> > +int kvm_get_vmfd(KVMState *s);
> >
> > int kvm_vcpu_ioctl(CPUState *cpu, int type, ...);
> >
> > diff --git a/kvm-all.c b/kvm-all.c
> > index efb5fe3..bd72ce3 100644
> > --- a/kvm-all.c
> > +++ b/kvm-all.c
> > @@ -2065,6 +2065,11 @@ int kvm_vm_ioctl(KVMState *s, int type, ...)
> > return ret;
> > }
> >
> > +int kvm_get_vmfd(KVMState *s)
> > +{
> > + return s->vmfd;
> > +}
> > +
> > int kvm_vcpu_ioctl(CPUState *cpu, int type, ...)
> > {
> > int ret;
> > diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h
> > index 759b850..952303f 100644
> > --- a/linux-headers/linux/vfio.h
> > +++ b/linux-headers/linux/vfio.h
> > @@ -686,6 +686,12 @@ struct vfio_iommu_spapr_tce_remove {
> > };
> > #define VFIO_IOMMU_SPAPR_TCE_REMOVE _IO(VFIO_TYPE, VFIO_BASE + 20)
> >
> > +
> > +/**
> > + * VFIO_SET_KVMFD - _IO(VFIO_TYPE, VFIO_BASE + 21, __u32)
> > + */
> > +#define VFIO_SET_KVMFD _IO(VFIO_TYPE, VFIO_BASE + 21)
> > +
> > /* ***************************************************************** */
> >
> > #endif /* VFIO_H */
> >
>
next prev parent reply other threads:[~2016-10-14 14:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1475998904-13456-1-git-send-email-xiaoguang.chen@intel.com>
[not found] ` <1475998904-13456-2-git-send-email-xiaoguang.chen@intel.com>
[not found] ` <20161009083134.GA19090@nvidia.com>
[not found] ` <ad547eac-428c-751b-05c4-52002d78ecb4@redhat.com>
[not found] ` <20161010180140.GA27757@nvidia.com>
[not found] ` <c9d63f52-9b6f-5752-2111-773b33adc426@redhat.com>
[not found] ` <1259cdba-c137-c3da-abe2-ecf51aec6738@linux.intel.com>
[not found] ` <e992eb4e-0806-8f6e-851d-36eaf389a897@redhat.com>
[not found] ` <ea9dffe6-7afa-4862-e46f-6f780a309e46@linux.intel.com>
[not found] ` <523e1446-75f1-fe3a-d818-f7d238d57751@redhat.com>
2016-10-14 10:37 ` [Qemu-devel] [PATCH 1/2] KVM: page track: add a new notifier type: track_flush_slot Jike Song
2016-10-14 10:43 ` Paolo Bonzini
2016-10-14 12:26 ` Jike Song
2016-10-14 14:41 ` Alex Williamson
2016-10-14 14:46 ` Alex Williamson [this message]
2016-10-14 16:35 ` Neo Jia
2016-10-14 16:51 ` Alex Williamson
2016-10-14 22:19 ` Neo Jia
2016-10-17 16:02 ` Alex Williamson
2016-10-18 12:38 ` Jike Song
2016-10-18 14:59 ` Alex Williamson
2016-10-19 2:32 ` Jike Song
2016-10-19 5:45 ` Xiao Guangrong
2016-10-19 11:56 ` Paolo Bonzini
2016-10-19 13:39 ` Xiao Guangrong
2016-10-19 14:14 ` Paolo Bonzini
2016-10-20 1:48 ` Xiao Guangrong
2016-10-20 17:06 ` Paolo Bonzini
2016-10-20 17:19 ` Xiao, Guangrong
2016-10-21 2:47 ` Jike Song
2016-10-26 13:44 ` Jike Song
2016-10-26 14:45 ` Paolo Bonzini
2016-10-29 4:07 ` Jike Song
2016-10-19 13:56 ` Eric Blake
2016-10-24 6:32 ` Jike Song
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161014084601.2a50ba87@t450s.home \
--to=alex.williamson@redhat.com \
--cc=cjia@nvidia.com \
--cc=guangrong.xiao@intel.com \
--cc=guangrong.xiao@linux.intel.com \
--cc=jike.song@intel.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=xiaoguang.chen@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).