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. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
