[PATCH 0/2] extend page_track for external usage

[PATCH 0/2] extend page_track for external usage

[Jike Song]

page_track is currently used only by KVM internally to protect guest
page tables. To be used by external user like KVMGT, the callbacks
should carry more information other than KVM/VCPU, and the symbols
should be exported.

Jike Song (2):
  kvm/page_track: call notifiers with kvm_page_track_notifier_node
  kvm/page_track: export symbols for external usage

 arch/x86/include/asm/kvm_page_track.h | 7 +++++--
 arch/x86/kvm/mmu.c                    | 6 ++++--
 arch/x86/kvm/page_track.c             | 8 ++++++--
 3 files changed, 15 insertions(+), 6 deletions(-)

-- 
1.9.1

[PATCH 1/2] kvm/page_track: call notifiers with kvm_page_track_notifier_node

[Jike Song]

The user of page_track might needs extra information, so pass
the kvm_page_track_notifier_node to callbacks.

Signed-off-by: Jike Song <jike.song@intel.com>
Reviewed-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
---
 arch/x86/include/asm/kvm_page_track.h | 7 +++++--
 arch/x86/kvm/mmu.c                    | 6 ++++--
 arch/x86/kvm/page_track.c             | 4 ++--
 3 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/arch/x86/include/asm/kvm_page_track.h b/arch/x86/include/asm/kvm_page_track.h
index 5f66597..d74747b 100644
--- a/arch/x86/include/asm/kvm_page_track.h
+++ b/arch/x86/include/asm/kvm_page_track.h
@@ -29,17 +29,20 @@ struct kvm_page_track_notifier_node {
 	 * @gpa: the physical address written by guest.
 	 * @new: the data was written to the address.
 	 * @bytes: the written length.
+	 * @node: this node
 	 */
 	void (*track_write)(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
-			    int bytes);
+			    int bytes, struct kvm_page_track_notifier_node *node);
 	/*
 	 * It is called when memory slot is being moved or removed
 	 * users can drop write-protection for the pages in that memory slot
 	 *
 	 * @kvm: the kvm where memory slot being moved or removed
 	 * @slot: the memory slot being moved or removed
+	 * @node: this node
 	 */
-	void (*track_flush_slot)(struct kvm *kvm, struct kvm_memory_slot *slot);
+	void (*track_flush_slot)(struct kvm *kvm, struct kvm_memory_slot *slot,
+			    struct kvm_page_track_notifier_node *node);
 };
 
 void kvm_page_track_init(struct kvm *kvm);
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 25ca762..1d2f350 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -4397,7 +4397,8 @@ static u64 *get_written_sptes(struct kvm_mmu_page *sp, gpa_t gpa, int *nspte)
 }
 
 static void kvm_mmu_pte_write(struct kvm_vcpu *vcpu, gpa_t gpa,
-			      const u8 *new, int bytes)
+			      const u8 *new, int bytes,
+			      struct kvm_page_track_notifier_node *node)
 {
 	gfn_t gfn = gpa >> PAGE_SHIFT;
 	struct kvm_mmu_page *sp;
@@ -4610,7 +4611,8 @@ void kvm_mmu_setup(struct kvm_vcpu *vcpu)
 }
 
 static void kvm_mmu_invalidate_zap_pages_in_memslot(struct kvm *kvm,
-			struct kvm_memory_slot *slot)
+			struct kvm_memory_slot *slot,
+			struct kvm_page_track_notifier_node *node)
 {
 	kvm_mmu_invalidate_zap_all_pages(kvm);
 }
diff --git a/arch/x86/kvm/page_track.c b/arch/x86/kvm/page_track.c
index e79bb25..3dae0e3 100644
--- a/arch/x86/kvm/page_track.c
+++ b/arch/x86/kvm/page_track.c
@@ -222,7 +222,7 @@ void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, const u8 *new,
 	idx = srcu_read_lock(&head->track_srcu);
 	hlist_for_each_entry_rcu(n, &head->track_notifier_list, node)
 		if (n->track_write)
-			n->track_write(vcpu, gpa, new, bytes);
+			n->track_write(vcpu, gpa, new, bytes, n);
 	srcu_read_unlock(&head->track_srcu, idx);
 }
 
@@ -247,6 +247,6 @@ void kvm_page_track_flush_slot(struct kvm *kvm, struct kvm_memory_slot *slot)
 	idx = srcu_read_lock(&head->track_srcu);
 	hlist_for_each_entry_rcu(n, &head->track_notifier_list, node)
 		if (n->track_flush_slot)
-			n->track_flush_slot(kvm, slot);
+			n->track_flush_slot(kvm, slot, n);
 	srcu_read_unlock(&head->track_srcu, idx);
 }
-- 
1.9.1

[PATCH 2/2] kvm/page_track: export symbols for external usage

[Jike Song]

Signed-off-by: Jike Song <jike.song@intel.com>
Reviewed-by: Xiao Guangrong <guangrong.xiao@linux.intel.com>
---
 arch/x86/kvm/page_track.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/kvm/page_track.c b/arch/x86/kvm/page_track.c
index 3dae0e3..4a1c13e 100644
--- a/arch/x86/kvm/page_track.c
+++ b/arch/x86/kvm/page_track.c
@@ -106,6 +106,7 @@ void kvm_slot_page_track_add_page(struct kvm *kvm,
 		if (kvm_mmu_slot_gfn_write_protect(kvm, slot, gfn))
 			kvm_flush_remote_tlbs(kvm);
 }
+EXPORT_SYMBOL_GPL(kvm_slot_page_track_add_page);
 
 /*
  * remove the guest page from the tracking pool which stops the interception
@@ -135,6 +136,7 @@ void kvm_slot_page_track_remove_page(struct kvm *kvm,
 	 */
 	kvm_mmu_gfn_allow_lpage(slot, gfn);
 }
+EXPORT_SYMBOL_GPL(kvm_slot_page_track_remove_page);
 
 /*
  * check if the corresponding access on the specified guest page is tracked.
@@ -181,6 +183,7 @@ void kvm_page_track_init(struct kvm *kvm)
 	hlist_add_head_rcu(&n->node, &head->track_notifier_list);
 	spin_unlock(&kvm->mmu_lock);
 }
+EXPORT_SYMBOL_GPL(kvm_page_track_register_notifier);
 
 /*
  * stop receiving the event interception. It is the opposed operation of
@@ -199,6 +202,7 @@ void kvm_page_track_init(struct kvm *kvm)
 	spin_unlock(&kvm->mmu_lock);
 	synchronize_srcu(&head->track_srcu);
 }
+EXPORT_SYMBOL_GPL(kvm_page_track_unregister_notifier);
 
 /*
  * Notify the node that write access is intercepted and write emulation is
-- 
1.9.1

Re: [PATCH 0/2] extend page_track for external usage

[Jike Song]

+Guangrong

//just knew that git send-email doesn't respect "Reviewed-by" :)


--
Thanks,
Jike

On 10/25/2016 03:50 PM, Jike Song wrote:
> page_track is currently used only by KVM internally to protect guest
> page tables. To be used by external user like KVMGT, the callbacks
> should carry more information other than KVM/VCPU, and the symbols
> should be exported.
> 
> Jike Song (2):
>   kvm/page_track: call notifiers with kvm_page_track_notifier_node
>   kvm/page_track: export symbols for external usage
> 
>  arch/x86/include/asm/kvm_page_track.h | 7 +++++--
>  arch/x86/kvm/mmu.c                    | 6 ++++--
>  arch/x86/kvm/page_track.c             | 8 ++++++--
>  3 files changed, 15 insertions(+), 6 deletions(-)
> 

Re: [PATCH 0/2] extend page_track for external usage

[Neo Jia]

On Tue, Oct 25, 2016 at 03:50:41PM +0800, Jike Song wrote:
> page_track is currently used only by KVM internally to protect guest
> page tables. To be used by external user like KVMGT, the callbacks
> should carry more information other than KVM/VCPU, and the symbols
> should be exported.
> 
> Jike Song (2):
>   kvm/page_track: call notifiers with kvm_page_track_notifier_node
>   kvm/page_track: export symbols for external usage
> 
>  arch/x86/include/asm/kvm_page_track.h | 7 +++++--
>  arch/x86/kvm/mmu.c                    | 6 ++++--
>  arch/x86/kvm/page_track.c             | 8 ++++++--
>  3 files changed, 15 insertions(+), 6 deletions(-)

Hi Jike,

What is the plan of providing this functionality to the VFIO based mediated
vendor driver?

JFYI, this is a useful feature that NVIDIA vGPU also needs.

Thanks,
Neo

> 
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] extend page_track for external usage

[Jike Song]

On 10/26/2016 12:42 AM, Neo Jia wrote:
> On Tue, Oct 25, 2016 at 03:50:41PM +0800, Jike Song wrote:
>> page_track is currently used only by KVM internally to protect guest
>> page tables. To be used by external user like KVMGT, the callbacks
>> should carry more information other than KVM/VCPU, and the symbols
>> should be exported.
>>
>> Jike Song (2):
>>   kvm/page_track: call notifiers with kvm_page_track_notifier_node
>>   kvm/page_track: export symbols for external usage
>>
>>  arch/x86/include/asm/kvm_page_track.h | 7 +++++--
>>  arch/x86/kvm/mmu.c                    | 6 ++++--
>>  arch/x86/kvm/page_track.c             | 8 ++++++--
>>  3 files changed, 15 insertions(+), 6 deletions(-)
> 
> Hi Jike,
> 
> What is the plan of providing this functionality to the VFIO based mediated
> vendor driver?
> 
> JFYI, this is a useful feature that NVIDIA vGPU also needs.

Hi Neo,

The page_track implementation is almost ready for external usage, my
changes here are quite trivial. I guess the external user like your
vendor driver can call them directly.

BTW, do you also have to shadow the device page-tables? Per my previous
understanding you don't have to.


--
Thanks,
Jike

Re: [PATCH 0/2] extend page_track for external usage

[Neo Jia]

On Wed, Oct 26, 2016 at 10:18:56AM +0800, Jike Song wrote:
> On 10/26/2016 12:42 AM, Neo Jia wrote:
> > On Tue, Oct 25, 2016 at 03:50:41PM +0800, Jike Song wrote:
> >> page_track is currently used only by KVM internally to protect guest
> >> page tables. To be used by external user like KVMGT, the callbacks
> >> should carry more information other than KVM/VCPU, and the symbols
> >> should be exported.
> >>
> >> Jike Song (2):
> >>   kvm/page_track: call notifiers with kvm_page_track_notifier_node
> >>   kvm/page_track: export symbols for external usage
> >>
> >>  arch/x86/include/asm/kvm_page_track.h | 7 +++++--
> >>  arch/x86/kvm/mmu.c                    | 6 ++++--
> >>  arch/x86/kvm/page_track.c             | 8 ++++++--
> >>  3 files changed, 15 insertions(+), 6 deletions(-)
> > 
> > Hi Jike,
> > 
> > What is the plan of providing this functionality to the VFIO based mediated
> > vendor driver?
> > 
> > JFYI, this is a useful feature that NVIDIA vGPU also needs.
> 
> Hi Neo,
> 
> The page_track implementation is almost ready for external usage, my
> changes here are quite trivial. I guess the external user like your
> vendor driver can call them directly.

Hi Jike,

Unfortunately, I don't think the current implementation is accessible to us,
could you please change?

> 
> BTW, do you also have to shadow the device page-tables? Per my previous
> understanding you don't have to.

It is not for the page table, we have other features will require such wp
capabilities to trap guest memory access.

Thanks,
Neo

> 
> 
> --
> Thanks,
> Jike

Re: [PATCH 0/2] extend page_track for external usage

[Paolo Bonzini]

On 26/10/2016 09:39, Neo Jia wrote:
> > The page_track implementation is almost ready for external usage, my
> > changes here are quite trivial. I guess the external user like your
> > vendor driver can call them directly.
> 
> Unfortunately, I don't think the current implementation is accessible to us,
> could you please change?

How so?

> > BTW, do you also have to shadow the device page-tables? Per my previous
> > understanding you don't have to.
> 
> It is not for the page table, we have other features will require such wp
> capabilities to trap guest memory access.

Can you please expand?

Paolo

RE: [PATCH 0/2] extend page_track for external usage

[Tian, Kevin]

> From: Paolo Bonzini [mailto:pbonzini@redhat.com]
> Sent: Wednesday, October 26, 2016 3:44 PM
> 
> 
> 
> On 26/10/2016 09:39, Neo Jia wrote:
> > > The page_track implementation is almost ready for external usage, my
> > > changes here are quite trivial. I guess the external user like your
> > > vendor driver can call them directly.
> >
> > Unfortunately, I don't think the current implementation is accessible to us,
> > could you please change?
> 
> How so?
> 
> > > BTW, do you also have to shadow the device page-tables? Per my previous
> > > understanding you don't have to.
> >
> > It is not for the page table, we have other features will require such wp
> > capabilities to trap guest memory access.
> 
> Can you please expand?
> 
> Paolo

also is it for optional features or mandatory? It's the first time we hear
similar requirement of this interface from your side...

Thanks
Kevin

Re: [PATCH 0/2] extend page_track for external usage

[Neo Jia]

On Wed, Oct 26, 2016 at 09:44:05AM +0200, Paolo Bonzini wrote:
> 
> 
> On 26/10/2016 09:39, Neo Jia wrote:
> > > The page_track implementation is almost ready for external usage, my
> > > changes here are quite trivial. I guess the external user like your
> > > vendor driver can call them directly.
> > 
> > Unfortunately, I don't think the current implementation is accessible to us,
> > could you please change?
> 
> How so?
> 
> > > BTW, do you also have to shadow the device page-tables? Per my previous
> > > understanding you don't have to.
> > 
> > It is not for the page table, we have other features will require such wp
> > capabilities to trap guest memory access.
> 
> Can you please expand?

Sure, this wp capabilities will allow us to check GPU command stream for VMs.

Thanks,
Neo

> 
> Paolo

Re: [PATCH 0/2] extend page_track for external usage

[Paolo Bonzini]

On 25/10/2016 09:50, Jike Song wrote:
> page_track is currently used only by KVM internally to protect guest
> page tables. To be used by external user like KVMGT, the callbacks
> should carry more information other than KVM/VCPU, and the symbols
> should be exported.
> 
> Jike Song (2):
>   kvm/page_track: call notifiers with kvm_page_track_notifier_node
>   kvm/page_track: export symbols for external usage
> 
>  arch/x86/include/asm/kvm_page_track.h | 7 +++++--
>  arch/x86/kvm/mmu.c                    | 6 ++++--
>  arch/x86/kvm/page_track.c             | 8 ++++++--
>  3 files changed, 15 insertions(+), 6 deletions(-)

Thanks, applied to kvm/queue.

Paolo

Re: [PATCH 0/2] extend page_track for external usage

[Jike Song]

On 10/26/2016 03:48 PM, Paolo Bonzini wrote:
> On 25/10/2016 09:50, Jike Song wrote:
>> page_track is currently used only by KVM internally to protect guest
>> page tables. To be used by external user like KVMGT, the callbacks
>> should carry more information other than KVM/VCPU, and the symbols
>> should be exported.
>>
>> Jike Song (2):
>>   kvm/page_track: call notifiers with kvm_page_track_notifier_node
>>   kvm/page_track: export symbols for external usage
>>
>>  arch/x86/include/asm/kvm_page_track.h | 7 +++++--
>>  arch/x86/kvm/mmu.c                    | 6 ++++--
>>  arch/x86/kvm/page_track.c             | 8 ++++++--
>>  3 files changed, 15 insertions(+), 6 deletions(-)
> 
> Thanks, applied to kvm/queue.
> 
> Paolo
> 

Hi Paolo,

I just synced kvm repo and it seemd there was a forced-update on
kvm/queue, and the commits are dropped? 


--
Thanks,
Jike

Re: [PATCH 0/2] extend page_track for external usage

[Paolo Bonzini]

On 04/11/2016 06:47, Jike Song wrote:
> On 10/26/2016 03:48 PM, Paolo Bonzini wrote:
>> On 25/10/2016 09:50, Jike Song wrote:
>>> page_track is currently used only by KVM internally to protect guest
>>> page tables. To be used by external user like KVMGT, the callbacks
>>> should carry more information other than KVM/VCPU, and the symbols
>>> should be exported.
>>>
>>> Jike Song (2):
>>>   kvm/page_track: call notifiers with kvm_page_track_notifier_node
>>>   kvm/page_track: export symbols for external usage
>>>
>>>  arch/x86/include/asm/kvm_page_track.h | 7 +++++--
>>>  arch/x86/kvm/mmu.c                    | 6 ++++--
>>>  arch/x86/kvm/page_track.c             | 8 ++++++--
>>>  3 files changed, 15 insertions(+), 6 deletions(-)
>>
>> Thanks, applied to kvm/queue.
>>
>> Paolo
>>
> 
> Hi Paolo,
> 
> I just synced kvm repo and it seemd there was a forced-update on
> kvm/queue, and the commits are dropped? 

I temporarily reverted everything after the APICv patches.  They'll be
back soon (and in kvm/next).

Paolo

Re: [PATCH 0/2] extend page_track for external usage

[Zhenyu Wang]

[-- Attachment #1: Type: text/plain, Size: 1756 bytes --]

On 2016.11.04 11:02:05 +0100, Paolo Bonzini wrote:
> >> On 25/10/2016 09:50, Jike Song wrote:
> >>> page_track is currently used only by KVM internally to protect guest
> >>> page tables. To be used by external user like KVMGT, the callbacks
> >>> should carry more information other than KVM/VCPU, and the symbols
> >>> should be exported.
> >>>
> >>> Jike Song (2):
> >>>   kvm/page_track: call notifiers with kvm_page_track_notifier_node
> >>>   kvm/page_track: export symbols for external usage
> >>>
> >>>  arch/x86/include/asm/kvm_page_track.h | 7 +++++--
> >>>  arch/x86/kvm/mmu.c                    | 6 ++++--
> >>>  arch/x86/kvm/page_track.c             | 8 ++++++--
> >>>  3 files changed, 15 insertions(+), 6 deletions(-)
> >>
> >> Thanks, applied to kvm/queue.
> >>
> >> Paolo
> >>
> > 
> > Hi Paolo,
> > 
> > I just synced kvm repo and it seemd there was a forced-update on
> > kvm/queue, and the commits are dropped? 
> 
> I temporarily reverted everything after the APICv patches.  They'll be
> back soon (and in kvm/next).
> 

Paolo, for this case, do you think it's feasible we pick them through
drm/i915 merge path? As currently initial KVMGT patch sets require these
exported symbols, that's why I ask how we should handle this dependency.

Current KVMGT initial patch set is on https://github.com/01org/gvt-linux/tree/topic/gvt-next-kvmgt
I'm planning to send pull request for Daniel next week.

Also cc Daniel, this is first case we need kvm dependency, in near
future there would also be VFIO/mdev and other kvm small changes.
So might better to sync about way to handle this.

Thanks

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [PATCH 0/2] extend page_track for external usage

[Paolo Bonzini]

[-- Attachment #1.1: Type: text/plain, Size: 2610 bytes --]



On 04/11/2016 11:29, Zhenyu Wang wrote:
> On 2016.11.04 11:02:05 +0100, Paolo Bonzini wrote:
>>>> On 25/10/2016 09:50, Jike Song wrote:
>>>>> page_track is currently used only by KVM internally to protect guest
>>>>> page tables. To be used by external user like KVMGT, the callbacks
>>>>> should carry more information other than KVM/VCPU, and the symbols
>>>>> should be exported.
>>>>>
>>>>> Jike Song (2):
>>>>>   kvm/page_track: call notifiers with kvm_page_track_notifier_node
>>>>>   kvm/page_track: export symbols for external usage
>>>>>
>>>>>  arch/x86/include/asm/kvm_page_track.h | 7 +++++--
>>>>>  arch/x86/kvm/mmu.c                    | 6 ++++--
>>>>>  arch/x86/kvm/page_track.c             | 8 ++++++--
>>>>>  3 files changed, 15 insertions(+), 6 deletions(-)
>>>>
>>>> Thanks, applied to kvm/queue.
>>>>
>>>> Paolo
>>>>
>>>
>>> Hi Paolo,
>>>
>>> I just synced kvm repo and it seemd there was a forced-update on
>>> kvm/queue, and the commits are dropped? 
>>
>> I temporarily reverted everything after the APICv patches.  They'll be
>> back soon (and in kvm/next).
> 
> Paolo, for this case, do you think it's feasible we pick them through
> drm/i915 merge path? As currently initial KVMGT patch sets require these
> exported symbols, that's why I ask how we should handle this dependency.

Then it's actually a good thing that I dropped from kvm/queue!  You can
certainly include these patches, but please do that through a topic branch.

I've prepared a branch for you
(git://git.kernel.org/pub/scm/virt/kvm/kvm.git branch for-kvmgt).  Once
Linus processes my outstanding pull request, the branch will only
include the three page-tracking patches.  Please pull that topic branch
into your own branch, and ensure you have a merge commit when you send
the pull request to Daniel.  The merge commit ensures that the workflow
was correct; use --no-ff if necessary.

You can do the same for Jike's patches for the KVM-VFIO device, when
Alex reviews them, and I suppose you'll need a topic branch for mdev
too?  I didn't know that KVMGT was planned for 4.10.  In the future,
let's synchronize ahead so that we can prepare topic branches for you.

Thanks,

Paolo

> Current KVMGT initial patch set is on https://github.com/01org/gvt-linux/tree/topic/gvt-next-kvmgt
> I'm planning to send pull request for Daniel next week.
> 
> Also cc Daniel, this is first case we need kvm dependency, in near
> future there would also be VFIO/mdev and other kvm small changes.
> So might better to sync about way to handle this.
> 
> Thanks
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [PATCH 0/2] extend page_track for external usage

[Zhenyu Wang]

[-- Attachment #1: Type: text/plain, Size: 2805 bytes --]

On 2016.11.04 12:22:14 +0100, Paolo Bonzini wrote:
> >>>> On 25/10/2016 09:50, Jike Song wrote:
> >>>>> page_track is currently used only by KVM internally to protect guest
> >>>>> page tables. To be used by external user like KVMGT, the callbacks
> >>>>> should carry more information other than KVM/VCPU, and the symbols
> >>>>> should be exported.
> >>>>>
> >>>>> Jike Song (2):
> >>>>>   kvm/page_track: call notifiers with kvm_page_track_notifier_node
> >>>>>   kvm/page_track: export symbols for external usage
> >>>>>
> >>>>>  arch/x86/include/asm/kvm_page_track.h | 7 +++++--
> >>>>>  arch/x86/kvm/mmu.c                    | 6 ++++--
> >>>>>  arch/x86/kvm/page_track.c             | 8 ++++++--
> >>>>>  3 files changed, 15 insertions(+), 6 deletions(-)
> >>>>
> >>>> Thanks, applied to kvm/queue.
> >>>>
> >>>> Paolo
> >>>>
> >>>
> >>> Hi Paolo,
> >>>
> >>> I just synced kvm repo and it seemd there was a forced-update on
> >>> kvm/queue, and the commits are dropped? 
> >>
> >> I temporarily reverted everything after the APICv patches.  They'll be
> >> back soon (and in kvm/next).
> > 
> > Paolo, for this case, do you think it's feasible we pick them through
> > drm/i915 merge path? As currently initial KVMGT patch sets require these
> > exported symbols, that's why I ask how we should handle this dependency.
> 
> Then it's actually a good thing that I dropped from kvm/queue!  You can
> certainly include these patches, but please do that through a topic branch.
> 
> I've prepared a branch for you
> (git://git.kernel.org/pub/scm/virt/kvm/kvm.git branch for-kvmgt).  Once
> Linus processes my outstanding pull request, the branch will only
> include the three page-tracking patches.  Please pull that topic branch
> into your own branch, and ensure you have a merge commit when you send
> the pull request to Daniel.  The merge commit ensures that the workflow
> was correct; use --no-ff if necessary.
>

Thanks a lot, Paolo! It looks good to me.

> You can do the same for Jike's patches for the KVM-VFIO device, when
> Alex reviews them, and I suppose you'll need a topic branch for mdev
> too?  I didn't know that KVMGT was planned for 4.10.  In the future,
> let's synchronize ahead so that we can prepare topic branches for you.
>

yeah, will need Jike's KVM instance patch too, but depends on VFIO/mdev
to land first I think, will need a topic branch for sure.

Our current KVMGT testing turns out good for 4.10 and we're trying to
push that. Sorry that we've ignored to sync with KVM side as we might
assume required change will be surely ready for 4.10. ;) We'll prepare
and notify earlier in future.

Thanks

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [PATCH 0/2] extend page_track for external usage

[Jike Song]

On 11/04/2016 07:22 PM, Paolo Bonzini wrote:
> Then it's actually a good thing that I dropped from kvm/queue!  You can
> certainly include these patches, but please do that through a topic branch.
> 
> I've prepared a branch for you
> (git://git.kernel.org/pub/scm/virt/kvm/kvm.git branch for-kvmgt).  Once
> Linus processes my outstanding pull request, the branch will only
> include the three page-tracking patches.  Please pull that topic branch
> into your own branch, and ensure you have a merge commit when you send
> the pull request to Daniel.  The merge commit ensures that the workflow
> was correct; use --no-ff if necessary.
> 

Hi Paolo,

Thanks for all the information and kind help! :)

--
Thanks,
Jike

> You can do the same for Jike's patches for the KVM-VFIO device, when
> Alex reviews them, and I suppose you'll need a topic branch for mdev
> too?  I didn't know that KVMGT was planned for 4.10.  In the future,
> let's synchronize ahead so that we can prepare topic branches for you.
> 
> Thanks,
> 
> Paolo
> 
>> Current KVMGT initial patch set is on https://github.com/01org/gvt-linux/tree/topic/gvt-next-kvmgt
>> I'm planning to send pull request for Daniel next week.
>>
>> Also cc Daniel, this is first case we need kvm dependency, in near
>> future there would also be VFIO/mdev and other kvm small changes.
>> So might better to sync about way to handle this.
>>
>> Thanks
>>
> 

Re: [PATCH 0/2] extend page_track for external usage

[Daniel Vetter]

On Fri, Nov 4, 2016 at 12:22 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 04/11/2016 11:29, Zhenyu Wang wrote:
>> On 2016.11.04 11:02:05 +0100, Paolo Bonzini wrote:
>>>>> On 25/10/2016 09:50, Jike Song wrote:
>>>>>> page_track is currently used only by KVM internally to protect guest
>>>>>> page tables. To be used by external user like KVMGT, the callbacks
>>>>>> should carry more information other than KVM/VCPU, and the symbols
>>>>>> should be exported.
>>>>>>
>>>>>> Jike Song (2):
>>>>>>   kvm/page_track: call notifiers with kvm_page_track_notifier_node
>>>>>>   kvm/page_track: export symbols for external usage
>>>>>>
>>>>>>  arch/x86/include/asm/kvm_page_track.h | 7 +++++--
>>>>>>  arch/x86/kvm/mmu.c                    | 6 ++++--
>>>>>>  arch/x86/kvm/page_track.c             | 8 ++++++--
>>>>>>  3 files changed, 15 insertions(+), 6 deletions(-)
>>>>>
>>>>> Thanks, applied to kvm/queue.
>>>>>
>>>>> Paolo
>>>>>
>>>>
>>>> Hi Paolo,
>>>>
>>>> I just synced kvm repo and it seemd there was a forced-update on
>>>> kvm/queue, and the commits are dropped?
>>>
>>> I temporarily reverted everything after the APICv patches.  They'll be
>>> back soon (and in kvm/next).
>>
>> Paolo, for this case, do you think it's feasible we pick them through
>> drm/i915 merge path? As currently initial KVMGT patch sets require these
>> exported symbols, that's why I ask how we should handle this dependency.
>
> Then it's actually a good thing that I dropped from kvm/queue!  You can
> certainly include these patches, but please do that through a topic branch.
>
> I've prepared a branch for you
> (git://git.kernel.org/pub/scm/virt/kvm/kvm.git branch for-kvmgt).  Once
> Linus processes my outstanding pull request, the branch will only
> include the three page-tracking patches.  Please pull that topic branch
> into your own branch, and ensure you have a merge commit when you send
> the pull request to Daniel.  The merge commit ensures that the workflow
> was correct; use --no-ff if necessary.
>
> You can do the same for Jike's patches for the KVM-VFIO device, when
> Alex reviews them, and I suppose you'll need a topic branch for mdev
> too?  I didn't know that KVMGT was planned for 4.10.  In the future,
> let's synchronize ahead so that we can prepare topic branches for you.

Ok, back from the useless wifi at plumbers, I can mail again. Zhenyu
confirmed on irc that the initial code pile only needs this. For the
cross-maintainer topic tree I prefer a formal pull request with stable
tag. Please also cc: intel-gfx on that, since I plan to merge that one
directly into i915.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 0/2] extend page_track for external usage

[Zhenyu Wang]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

On 2016.11.07 10:17:54 +0100, Daniel Vetter wrote:
> >> Paolo, for this case, do you think it's feasible we pick them through
> >> drm/i915 merge path? As currently initial KVMGT patch sets require these
> >> exported symbols, that's why I ask how we should handle this dependency.
> >
> > Then it's actually a good thing that I dropped from kvm/queue!  You can
> > certainly include these patches, but please do that through a topic branch.
> >
> > I've prepared a branch for you
> > (git://git.kernel.org/pub/scm/virt/kvm/kvm.git branch for-kvmgt).  Once
> > Linus processes my outstanding pull request, the branch will only
> > include the three page-tracking patches.  Please pull that topic branch
> > into your own branch, and ensure you have a merge commit when you send
> > the pull request to Daniel.  The merge commit ensures that the workflow
> > was correct; use --no-ff if necessary.
> >
> > You can do the same for Jike's patches for the KVM-VFIO device, when
> > Alex reviews them, and I suppose you'll need a topic branch for mdev
> > too?  I didn't know that KVMGT was planned for 4.10.  In the future,
> > let's synchronize ahead so that we can prepare topic branches for you.
> 
> Ok, back from the useless wifi at plumbers, I can mail again. Zhenyu
> confirmed on irc that the initial code pile only needs this. For the
> cross-maintainer topic tree I prefer a formal pull request with stable
> tag. Please also cc: intel-gfx on that, since I plan to merge that one
> directly into i915.
> 

Paolo, could you help to do this for Daniel? Daniel would like to merge
current KVMGT required change for KVM directly, then I'd base KVMGT change
on that.

p.s, Daniel gave me this example https://lists.freedesktop.org/archives/intel-gfx/2015-December/082600.html,
which was for audio change merge.

Thanks

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

Re: [PATCH 0/2] extend page_track for external usage

[Paolo Bonzini]

[-- Attachment #1.1: Type: text/plain, Size: 1798 bytes --]



On 09/11/2016 03:03, Zhenyu Wang wrote:
> On 2016.11.07 10:17:54 +0100, Daniel Vetter wrote:
>>>> Paolo, for this case, do you think it's feasible we pick them through
>>>> drm/i915 merge path? As currently initial KVMGT patch sets require these
>>>> exported symbols, that's why I ask how we should handle this dependency.
>>>
>>> Then it's actually a good thing that I dropped from kvm/queue!  You can
>>> certainly include these patches, but please do that through a topic branch.
>>>
>>> I've prepared a branch for you
>>> (git://git.kernel.org/pub/scm/virt/kvm/kvm.git branch for-kvmgt).  Once
>>> Linus processes my outstanding pull request, the branch will only
>>> include the three page-tracking patches.  Please pull that topic branch
>>> into your own branch, and ensure you have a merge commit when you send
>>> the pull request to Daniel.  The merge commit ensures that the workflow
>>> was correct; use --no-ff if necessary.
>>>
>>> You can do the same for Jike's patches for the KVM-VFIO device, when
>>> Alex reviews them, and I suppose you'll need a topic branch for mdev
>>> too?  I didn't know that KVMGT was planned for 4.10.  In the future,
>>> let's synchronize ahead so that we can prepare topic branches for you.
>>
>> Ok, back from the useless wifi at plumbers, I can mail again. Zhenyu
>> confirmed on irc that the initial code pile only needs this. For the
>> cross-maintainer topic tree I prefer a formal pull request with stable
>> tag. Please also cc: intel-gfx on that, since I plan to merge that one
>> directly into i915.
>>
> 
> Paolo, could you help to do this for Daniel? Daniel would like to merge
> current KVMGT required change for KVM directly, then I'd base KVMGT change
> on that.

Yes, I'll send it today.

Paolo


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]