All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Wang <wei.w.wang@intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtio-dev@lists.oasis-open.org, linux-kernel@vger.kernel.org,
	qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
	kvm@vger.kernel.org, linux-mm@kvack.org, mhocko@kernel.org,
	akpm@linux-foundation.org, mawilcox@microsoft.com,
	david@redhat.com, penguin-kernel@I-love.SAKURA.ne.jp,
	cornelia.huck@de.ibm.com, mgorman@techsingularity.net,
	aarcange@redhat.com, amit.shah@redhat.com, pbonzini@redhat.com,
	willy@infradead.org, liliang.opensource@gmail.com,
	yang.zhang.wz@gmail.com, quan.xu@aliyun.com,
	Nitesh Narayan Lal <nilal@redhat.com>,
	Rik van Riel <riel@redhat.com>
Subject: [virtio-dev] Re: [PATCH v17 6/6] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
Date: Thu, 16 Nov 2017 19:59:22 +0800	[thread overview]
Message-ID: <5A0D7D9A.1060509@intel.com> (raw)
In-Reply-To: <20171115152307-mutt-send-email-mst@kernel.org>

On 11/15/2017 09:26 PM, Michael S. Tsirkin wrote:
> On Wed, Nov 15, 2017 at 11:47:58AM +0800, Wei Wang wrote:
>> On 11/15/2017 05:21 AM, Michael S. Tsirkin wrote:
>>> On Tue, Nov 14, 2017 at 08:02:03PM +0800, Wei Wang wrote:
>>>> On 11/14/2017 01:32 AM, Michael S. Tsirkin wrote:
>>>>>> - guest2host_cmd: written by the guest to ACK to the host about the
>>>>>> commands that have been received. The host will clear the corresponding
>>>>>> bits on the host2guest_cmd register. The guest also uses this register
>>>>>> to send commands to the host (e.g. when finish free page reporting).
>>>>> I am not sure what is the role of guest2host_cmd. Reporting of
>>>>> the correct cmd id seems sufficient indication that guest
>>>>> received the start command. Not getting any more seems sufficient
>>>>> to detect stop.
>>>>>
>>>> I think the issue is when the host is waiting for the guest to report pages,
>>>> it does not know whether the guest is going to report more or the report is
>>>> done already. That's why we need a way to let the guest tell the host "the
>>>> report is done, don't wait for more", then the host continues to the next
>>>> step - sending the non-free pages to the destination. The following method
>>>> is a conclusion of other comments, with some new thought. Please have a
>>>> check if it is good.
>>> config won't work well for this IMHO.
>>> Writes to config register are hard to synchronize with the VQ.
>>> For example, guest sends free pages, host says stop, meanwhile
>>> guest sends stop for 1st set of pages.
>> I still don't see an issue with this. Please see below:
>> (before jumping into the discussion, just make sure I've well explained this
>> point: now host-to-guest commands are done via config, and guest-to-host
>> commands are done via the free page vq)
> This is fine by me actually. But right now you have guest to host
> not going through vq, going through command register instead -
> this is how sending stop to host seems to happen.
> If you make it go through vq then I think all will be well.
>
>> Case: Host starts to request the reporting with cmd_id=1. Some time later,
>> Host writes "stop" to config, meantime guest happens to finish the reporting
>> and plan to actively send a "stop" command from the free_page_vq().
>>            Essentially, this is like a sync between two threads - if we view
>> the config interrupt handler as one thread, another is the free page
>> reporting worker thread.
>>
>>          - what the config handler does is simply:
>>                1.1:  WRITE_ONCE(vb->reporting_stop, true);
>>
>>          - what the reporting thread will do is
>>                2.1:  WRITE_ONCE(vb->reporting_stop, true);
>>                2.2:  send_stop_to_host_via_vq();
>>
>>  From the guest point of view, no matter 1.1 is executed first or 2.1 first,
>> it doesn't make a difference to the end result - vb->reporting_stop is set.
>>
>>  From the host point of view, it knows that cmd_id=1 has truly stopped the
>> reporting when it receives a "stop" sign via the vq.
>>
>>
>>> How about adding a buffer with "stop" in the VQ instead?
>>> Wastes a VQ entry which you will need to reserve for this
>>> but is it a big deal?
>> The free page vq is guest-to-host direction.
> Yes, for guest to host stop sign.
>
>> Using it for host-to-guest
>> requests will make it bidirectional, which will result in the same issue
>> described before: https://lkml.org/lkml/2017/10/11/1009 (the first response)
>>
>> On the other hand, I think adding another new vq for host-to-guest
>> requesting doesn't make a difference in essence, compared to using config
>> (same 1.1, 2.1, 2.2 above), but will be more complicated.
> I agree with this. Host to guest can just incremenent the "free command id"
> register.


OK, thanks for the suggestions. I think one more issue left here:

Previously, when the guest receives a config interrupt, it blindly adds 
the balloon work item to the workqueue in virtballoon_changed(), because 
only ballooning uses the config.
Now, free page reporting is requested via config, too.

We have the following two options:

Option 1: add "diff = towards_target()" to virtballoon_changed(), and if 
diff = 0, it will not add the balloon work item to the wq.

Option 2: add "cmd" for the host-to-guest request, and add the item when 
"cmd | CMD_BALLOON" is true.

I'm inclined to take option 1 now. Which one would you prefer?

Best,
Wei



---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org


WARNING: multiple messages have this Message-ID (diff)
From: Wei Wang <wei.w.wang@intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtio-dev@lists.oasis-open.org, linux-kernel@vger.kernel.org,
	qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
	kvm@vger.kernel.org, linux-mm@kvack.org, mhocko@kernel.org,
	akpm@linux-foundation.org, mawilcox@microsoft.com,
	david@redhat.com, penguin-kernel@I-love.SAKURA.ne.jp,
	cornelia.huck@de.ibm.com, mgorman@techsingularity.net,
	aarcange@redhat.com, amit.shah@redhat.com, pbonzini@redhat.com,
	willy@infradead.org, liliang.opensource@gmail.com,
	yang.zhang.wz@gmail.com, quan.xu@aliyun.com,
	Nitesh Narayan Lal <nilal@redhat.com>,
	Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH v17 6/6] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
Date: Thu, 16 Nov 2017 19:59:22 +0800	[thread overview]
Message-ID: <5A0D7D9A.1060509@intel.com> (raw)
In-Reply-To: <20171115152307-mutt-send-email-mst@kernel.org>

On 11/15/2017 09:26 PM, Michael S. Tsirkin wrote:
> On Wed, Nov 15, 2017 at 11:47:58AM +0800, Wei Wang wrote:
>> On 11/15/2017 05:21 AM, Michael S. Tsirkin wrote:
>>> On Tue, Nov 14, 2017 at 08:02:03PM +0800, Wei Wang wrote:
>>>> On 11/14/2017 01:32 AM, Michael S. Tsirkin wrote:
>>>>>> - guest2host_cmd: written by the guest to ACK to the host about the
>>>>>> commands that have been received. The host will clear the corresponding
>>>>>> bits on the host2guest_cmd register. The guest also uses this register
>>>>>> to send commands to the host (e.g. when finish free page reporting).
>>>>> I am not sure what is the role of guest2host_cmd. Reporting of
>>>>> the correct cmd id seems sufficient indication that guest
>>>>> received the start command. Not getting any more seems sufficient
>>>>> to detect stop.
>>>>>
>>>> I think the issue is when the host is waiting for the guest to report pages,
>>>> it does not know whether the guest is going to report more or the report is
>>>> done already. That's why we need a way to let the guest tell the host "the
>>>> report is done, don't wait for more", then the host continues to the next
>>>> step - sending the non-free pages to the destination. The following method
>>>> is a conclusion of other comments, with some new thought. Please have a
>>>> check if it is good.
>>> config won't work well for this IMHO.
>>> Writes to config register are hard to synchronize with the VQ.
>>> For example, guest sends free pages, host says stop, meanwhile
>>> guest sends stop for 1st set of pages.
>> I still don't see an issue with this. Please see below:
>> (before jumping into the discussion, just make sure I've well explained this
>> point: now host-to-guest commands are done via config, and guest-to-host
>> commands are done via the free page vq)
> This is fine by me actually. But right now you have guest to host
> not going through vq, going through command register instead -
> this is how sending stop to host seems to happen.
> If you make it go through vq then I think all will be well.
>
>> Case: Host starts to request the reporting with cmd_id=1. Some time later,
>> Host writes "stop" to config, meantime guest happens to finish the reporting
>> and plan to actively send a "stop" command from the free_page_vq().
>>            Essentially, this is like a sync between two threads - if we view
>> the config interrupt handler as one thread, another is the free page
>> reporting worker thread.
>>
>>          - what the config handler does is simply:
>>                1.1:  WRITE_ONCE(vb->reporting_stop, true);
>>
>>          - what the reporting thread will do is
>>                2.1:  WRITE_ONCE(vb->reporting_stop, true);
>>                2.2:  send_stop_to_host_via_vq();
>>
>>  From the guest point of view, no matter 1.1 is executed first or 2.1 first,
>> it doesn't make a difference to the end result - vb->reporting_stop is set.
>>
>>  From the host point of view, it knows that cmd_id=1 has truly stopped the
>> reporting when it receives a "stop" sign via the vq.
>>
>>
>>> How about adding a buffer with "stop" in the VQ instead?
>>> Wastes a VQ entry which you will need to reserve for this
>>> but is it a big deal?
>> The free page vq is guest-to-host direction.
> Yes, for guest to host stop sign.
>
>> Using it for host-to-guest
>> requests will make it bidirectional, which will result in the same issue
>> described before: https://lkml.org/lkml/2017/10/11/1009 (the first response)
>>
>> On the other hand, I think adding another new vq for host-to-guest
>> requesting doesn't make a difference in essence, compared to using config
>> (same 1.1, 2.1, 2.2 above), but will be more complicated.
> I agree with this. Host to guest can just incremenent the "free command id"
> register.


OK, thanks for the suggestions. I think one more issue left here:

Previously, when the guest receives a config interrupt, it blindly adds 
the balloon work item to the workqueue in virtballoon_changed(), because 
only ballooning uses the config.
Now, free page reporting is requested via config, too.

We have the following two options:

Option 1: add "diff = towards_target()" to virtballoon_changed(), and if 
diff = 0, it will not add the balloon work item to the wq.

Option 2: add "cmd" for the host-to-guest request, and add the item when 
"cmd | CMD_BALLOON" is true.

I'm inclined to take option 1 now. Which one would you prefer?

Best,
Wei

WARNING: multiple messages have this Message-ID (diff)
From: Wei Wang <wei.w.wang@intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtio-dev@lists.oasis-open.org, linux-kernel@vger.kernel.org,
	qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
	kvm@vger.kernel.org, linux-mm@kvack.org, mhocko@kernel.org,
	akpm@linux-foundation.org, mawilcox@microsoft.com,
	david@redhat.com, penguin-kernel@I-love.SAKURA.ne.jp,
	cornelia.huck@de.ibm.com, mgorman@techsingularity.net,
	aarcange@redhat.com, amit.shah@redhat.com, pbonzini@redhat.com,
	willy@infradead.org, liliang.opensource@gmail.com,
	yang.zhang.wz@gmail.com, quan.xu@aliyun.com,
	Nitesh Narayan Lal <nilal@redhat.com>,
	Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH v17 6/6] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
Date: Thu, 16 Nov 2017 19:59:22 +0800	[thread overview]
Message-ID: <5A0D7D9A.1060509@intel.com> (raw)
In-Reply-To: <20171115152307-mutt-send-email-mst@kernel.org>

On 11/15/2017 09:26 PM, Michael S. Tsirkin wrote:
> On Wed, Nov 15, 2017 at 11:47:58AM +0800, Wei Wang wrote:
>> On 11/15/2017 05:21 AM, Michael S. Tsirkin wrote:
>>> On Tue, Nov 14, 2017 at 08:02:03PM +0800, Wei Wang wrote:
>>>> On 11/14/2017 01:32 AM, Michael S. Tsirkin wrote:
>>>>>> - guest2host_cmd: written by the guest to ACK to the host about the
>>>>>> commands that have been received. The host will clear the corresponding
>>>>>> bits on the host2guest_cmd register. The guest also uses this register
>>>>>> to send commands to the host (e.g. when finish free page reporting).
>>>>> I am not sure what is the role of guest2host_cmd. Reporting of
>>>>> the correct cmd id seems sufficient indication that guest
>>>>> received the start command. Not getting any more seems sufficient
>>>>> to detect stop.
>>>>>
>>>> I think the issue is when the host is waiting for the guest to report pages,
>>>> it does not know whether the guest is going to report more or the report is
>>>> done already. That's why we need a way to let the guest tell the host "the
>>>> report is done, don't wait for more", then the host continues to the next
>>>> step - sending the non-free pages to the destination. The following method
>>>> is a conclusion of other comments, with some new thought. Please have a
>>>> check if it is good.
>>> config won't work well for this IMHO.
>>> Writes to config register are hard to synchronize with the VQ.
>>> For example, guest sends free pages, host says stop, meanwhile
>>> guest sends stop for 1st set of pages.
>> I still don't see an issue with this. Please see below:
>> (before jumping into the discussion, just make sure I've well explained this
>> point: now host-to-guest commands are done via config, and guest-to-host
>> commands are done via the free page vq)
> This is fine by me actually. But right now you have guest to host
> not going through vq, going through command register instead -
> this is how sending stop to host seems to happen.
> If you make it go through vq then I think all will be well.
>
>> Case: Host starts to request the reporting with cmd_id=1. Some time later,
>> Host writes "stop" to config, meantime guest happens to finish the reporting
>> and plan to actively send a "stop" command from the free_page_vq().
>>            Essentially, this is like a sync between two threads - if we view
>> the config interrupt handler as one thread, another is the free page
>> reporting worker thread.
>>
>>          - what the config handler does is simply:
>>                1.1:  WRITE_ONCE(vb->reporting_stop, true);
>>
>>          - what the reporting thread will do is
>>                2.1:  WRITE_ONCE(vb->reporting_stop, true);
>>                2.2:  send_stop_to_host_via_vq();
>>
>>  From the guest point of view, no matter 1.1 is executed first or 2.1 first,
>> it doesn't make a difference to the end result - vb->reporting_stop is set.
>>
>>  From the host point of view, it knows that cmd_id=1 has truly stopped the
>> reporting when it receives a "stop" sign via the vq.
>>
>>
>>> How about adding a buffer with "stop" in the VQ instead?
>>> Wastes a VQ entry which you will need to reserve for this
>>> but is it a big deal?
>> The free page vq is guest-to-host direction.
> Yes, for guest to host stop sign.
>
>> Using it for host-to-guest
>> requests will make it bidirectional, which will result in the same issue
>> described before: https://lkml.org/lkml/2017/10/11/1009 (the first response)
>>
>> On the other hand, I think adding another new vq for host-to-guest
>> requesting doesn't make a difference in essence, compared to using config
>> (same 1.1, 2.1, 2.2 above), but will be more complicated.
> I agree with this. Host to guest can just incremenent the "free command id"
> register.


OK, thanks for the suggestions. I think one more issue left here:

Previously, when the guest receives a config interrupt, it blindly adds 
the balloon work item to the workqueue in virtballoon_changed(), because 
only ballooning uses the config.
Now, free page reporting is requested via config, too.

We have the following two options:

Option 1: add "diff = towards_target()" to virtballoon_changed(), and if 
diff = 0, it will not add the balloon work item to the wq.

Option 2: add "cmd" for the host-to-guest request, and add the item when 
"cmd | CMD_BALLOON" is true.

I'm inclined to take option 1 now. Which one would you prefer?

Best,
Wei


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Wei Wang <wei.w.wang@intel.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: virtio-dev@lists.oasis-open.org, linux-kernel@vger.kernel.org,
	qemu-devel@nongnu.org, virtualization@lists.linux-foundation.org,
	kvm@vger.kernel.org, linux-mm@kvack.org, mhocko@kernel.org,
	akpm@linux-foundation.org, mawilcox@microsoft.com,
	david@redhat.com, penguin-kernel@I-love.SAKURA.ne.jp,
	cornelia.huck@de.ibm.com, mgorman@techsingularity.net,
	aarcange@redhat.com, amit.shah@redhat.com, pbonzini@redhat.com,
	willy@infradead.org, liliang.opensource@gmail.com,
	yang.zhang.wz@gmail.com, quan.xu@aliyun.com,
	Nitesh Narayan Lal <nilal@redhat.com>,
	Rik van Riel <riel@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v17 6/6] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
Date: Thu, 16 Nov 2017 19:59:22 +0800	[thread overview]
Message-ID: <5A0D7D9A.1060509@intel.com> (raw)
In-Reply-To: <20171115152307-mutt-send-email-mst@kernel.org>

On 11/15/2017 09:26 PM, Michael S. Tsirkin wrote:
> On Wed, Nov 15, 2017 at 11:47:58AM +0800, Wei Wang wrote:
>> On 11/15/2017 05:21 AM, Michael S. Tsirkin wrote:
>>> On Tue, Nov 14, 2017 at 08:02:03PM +0800, Wei Wang wrote:
>>>> On 11/14/2017 01:32 AM, Michael S. Tsirkin wrote:
>>>>>> - guest2host_cmd: written by the guest to ACK to the host about the
>>>>>> commands that have been received. The host will clear the corresponding
>>>>>> bits on the host2guest_cmd register. The guest also uses this register
>>>>>> to send commands to the host (e.g. when finish free page reporting).
>>>>> I am not sure what is the role of guest2host_cmd. Reporting of
>>>>> the correct cmd id seems sufficient indication that guest
>>>>> received the start command. Not getting any more seems sufficient
>>>>> to detect stop.
>>>>>
>>>> I think the issue is when the host is waiting for the guest to report pages,
>>>> it does not know whether the guest is going to report more or the report is
>>>> done already. That's why we need a way to let the guest tell the host "the
>>>> report is done, don't wait for more", then the host continues to the next
>>>> step - sending the non-free pages to the destination. The following method
>>>> is a conclusion of other comments, with some new thought. Please have a
>>>> check if it is good.
>>> config won't work well for this IMHO.
>>> Writes to config register are hard to synchronize with the VQ.
>>> For example, guest sends free pages, host says stop, meanwhile
>>> guest sends stop for 1st set of pages.
>> I still don't see an issue with this. Please see below:
>> (before jumping into the discussion, just make sure I've well explained this
>> point: now host-to-guest commands are done via config, and guest-to-host
>> commands are done via the free page vq)
> This is fine by me actually. But right now you have guest to host
> not going through vq, going through command register instead -
> this is how sending stop to host seems to happen.
> If you make it go through vq then I think all will be well.
>
>> Case: Host starts to request the reporting with cmd_id=1. Some time later,
>> Host writes "stop" to config, meantime guest happens to finish the reporting
>> and plan to actively send a "stop" command from the free_page_vq().
>>            Essentially, this is like a sync between two threads - if we view
>> the config interrupt handler as one thread, another is the free page
>> reporting worker thread.
>>
>>          - what the config handler does is simply:
>>                1.1:  WRITE_ONCE(vb->reporting_stop, true);
>>
>>          - what the reporting thread will do is
>>                2.1:  WRITE_ONCE(vb->reporting_stop, true);
>>                2.2:  send_stop_to_host_via_vq();
>>
>>  From the guest point of view, no matter 1.1 is executed first or 2.1 first,
>> it doesn't make a difference to the end result - vb->reporting_stop is set.
>>
>>  From the host point of view, it knows that cmd_id=1 has truly stopped the
>> reporting when it receives a "stop" sign via the vq.
>>
>>
>>> How about adding a buffer with "stop" in the VQ instead?
>>> Wastes a VQ entry which you will need to reserve for this
>>> but is it a big deal?
>> The free page vq is guest-to-host direction.
> Yes, for guest to host stop sign.
>
>> Using it for host-to-guest
>> requests will make it bidirectional, which will result in the same issue
>> described before: https://lkml.org/lkml/2017/10/11/1009 (the first response)
>>
>> On the other hand, I think adding another new vq for host-to-guest
>> requesting doesn't make a difference in essence, compared to using config
>> (same 1.1, 2.1, 2.2 above), but will be more complicated.
> I agree with this. Host to guest can just incremenent the "free command id"
> register.


OK, thanks for the suggestions. I think one more issue left here:

Previously, when the guest receives a config interrupt, it blindly adds 
the balloon work item to the workqueue in virtballoon_changed(), because 
only ballooning uses the config.
Now, free page reporting is requested via config, too.

We have the following two options:

Option 1: add "diff = towards_target()" to virtballoon_changed(), and if 
diff = 0, it will not add the balloon work item to the wq.

Option 2: add "cmd" for the host-to-guest request, and add the item when 
"cmd | CMD_BALLOON" is true.

I'm inclined to take option 1 now. Which one would you prefer?

Best,
Wei

  reply	other threads:[~2017-11-16 11:57 UTC|newest]

Thread overview: 158+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-03  8:13 [virtio-dev] [PATCH v17 0/6] Virtio-balloon Enhancement Wei Wang
2017-11-03  8:13 ` [Qemu-devel] " Wei Wang
2017-11-03  8:13 ` Wei Wang
2017-11-03  8:13 ` Wei Wang
2017-11-03  8:13 ` [PATCH v17 1/6] lib/xbitmap: Introduce xbitmap Wei Wang
2017-11-03  8:13 ` [virtio-dev] " Wei Wang
2017-11-03  8:13   ` [Qemu-devel] " Wei Wang
2017-11-03  8:13   ` Wei Wang
2017-11-03  8:13   ` Wei Wang
2017-11-03 10:55   ` Tetsuo Handa
2017-11-03 10:55   ` Tetsuo Handa
2017-11-03 10:55     ` [Qemu-devel] " Tetsuo Handa
2017-11-03 10:55     ` Tetsuo Handa
2017-11-06  8:15     ` [virtio-dev] " Wei Wang
2017-11-06  8:15       ` [Qemu-devel] " Wei Wang
2017-11-06  8:15       ` Wei Wang
2017-11-06  8:15       ` Wei Wang
2017-11-06  8:15     ` Wei Wang
2017-11-03  8:13 ` [virtio-dev] [PATCH v17 2/6] radix tree test suite: add tests for xbitmap Wei Wang
2017-11-03  8:13   ` [Qemu-devel] " Wei Wang
2017-11-03  8:13   ` Wei Wang
2017-11-03  8:13   ` Wei Wang
2017-11-06 17:00   ` Matthew Wilcox
2017-11-06 17:00     ` [Qemu-devel] " Matthew Wilcox
2017-11-06 17:00     ` Matthew Wilcox
2017-11-29 14:20     ` [virtio-dev] " Wei Wang
2017-11-29 14:20       ` [Qemu-devel] " Wei Wang
2017-11-29 14:20       ` Wei Wang
2017-11-29 14:20       ` Wei Wang
2017-11-29 14:20     ` Wei Wang
2017-11-06 17:00   ` Matthew Wilcox
2017-11-03  8:13 ` Wei Wang
2017-11-03  8:13 ` [PATCH v17 3/6] mm/balloon_compaction.c: split balloon page allocation and enqueue Wei Wang
2017-11-03  8:13 ` [virtio-dev] " Wei Wang
2017-11-03  8:13   ` [Qemu-devel] " Wei Wang
2017-11-03  8:13   ` Wei Wang
2017-11-03  8:13   ` Wei Wang
2017-11-03 10:59   ` Tetsuo Handa
2017-11-03 10:59   ` Tetsuo Handa
2017-11-03 10:59     ` [Qemu-devel] " Tetsuo Handa
2017-11-03 10:59     ` Tetsuo Handa
2017-11-03  8:13 ` [PATCH v17 4/6] virtio-balloon: VIRTIO_BALLOON_F_SG Wei Wang
2017-11-03  8:13 ` [virtio-dev] " Wei Wang
2017-11-03  8:13   ` [Qemu-devel] " Wei Wang
2017-11-03  8:13   ` Wei Wang
2017-11-03  8:13   ` Wei Wang
2017-11-03 11:25   ` Tetsuo Handa
2017-11-03 11:25   ` Tetsuo Handa
2017-11-03 11:25     ` [Qemu-devel] " Tetsuo Handa
2017-11-03 11:25     ` Tetsuo Handa
2017-11-04 11:09     ` [virtio-dev] " Wei Wang
2017-11-04 11:09       ` [Qemu-devel] " Wei Wang
2017-11-04 11:09       ` Wei Wang
2017-11-04 11:09       ` Wei Wang
2017-11-04 11:09       ` Wei Wang
2017-11-04 11:28       ` Tetsuo Handa
2017-11-04 11:28       ` Tetsuo Handa
2017-11-04 11:28         ` [Qemu-devel] " Tetsuo Handa
2017-11-04 11:28         ` Tetsuo Handa
2017-11-06  8:21         ` Wei Wang
2017-11-06  8:21         ` [virtio-dev] " Wei Wang
2017-11-06  8:21           ` [Qemu-devel] " Wei Wang
2017-11-06  8:21           ` Wei Wang
2017-11-06  8:21           ` Wei Wang
2017-11-03  8:13 ` [virtio-dev] [PATCH v17 5/6] mm: support reporting free page blocks Wei Wang
2017-11-03  8:13   ` [Qemu-devel] " Wei Wang
2017-11-03  8:13   ` Wei Wang
2017-11-03  8:13   ` Wei Wang
2017-11-03  8:13 ` Wei Wang
2017-11-03  8:13 ` [virtio-dev] [PATCH v17 6/6] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ Wei Wang
2017-11-03  8:13   ` [Qemu-devel] " Wei Wang
2017-11-03  8:13   ` Wei Wang
2017-11-03  8:13   ` Wei Wang
2017-11-13 10:34   ` Wei Wang
2017-11-13 10:34   ` [virtio-dev] " Wei Wang
2017-11-13 10:34     ` [Qemu-devel] " Wei Wang
2017-11-13 10:34     ` Wei Wang
2017-11-13 10:34     ` Wei Wang
2017-11-13 17:32     ` Michael S. Tsirkin
2017-11-13 17:32     ` [virtio-dev] " Michael S. Tsirkin
2017-11-13 17:32       ` [Qemu-devel] " Michael S. Tsirkin
2017-11-13 17:32       ` Michael S. Tsirkin
2017-11-13 17:32       ` Michael S. Tsirkin
2017-11-14 12:02       ` Wei Wang
2017-11-14 12:02       ` [virtio-dev] " Wei Wang
2017-11-14 12:02         ` [Qemu-devel] " Wei Wang
2017-11-14 12:02         ` Wei Wang
2017-11-14 12:02         ` Wei Wang
2017-11-14 21:21         ` Michael S. Tsirkin
2017-11-14 21:21         ` [virtio-dev] " Michael S. Tsirkin
2017-11-14 21:21           ` [Qemu-devel] " Michael S. Tsirkin
2017-11-14 21:21           ` Michael S. Tsirkin
2017-11-14 21:21           ` Michael S. Tsirkin
2017-11-15  3:47           ` [virtio-dev] " Wei Wang
2017-11-15  3:47             ` [Qemu-devel] " Wei Wang
2017-11-15  3:47             ` Wei Wang
2017-11-15  3:47             ` Wei Wang
2017-11-15 13:26             ` [virtio-dev] " Michael S. Tsirkin
2017-11-15 13:26               ` [Qemu-devel] " Michael S. Tsirkin
2017-11-15 13:26               ` Michael S. Tsirkin
2017-11-15 13:26               ` Michael S. Tsirkin
2017-11-16 11:59               ` Wei Wang [this message]
2017-11-16 11:59                 ` [Qemu-devel] " Wei Wang
2017-11-16 11:59                 ` Wei Wang
2017-11-16 11:59                 ` Wei Wang
2017-11-16 11:59               ` Wei Wang
2017-11-15 13:26             ` Michael S. Tsirkin
2017-11-15  3:47           ` Wei Wang
2017-11-20 11:42       ` [virtio-dev] " Wei Wang
2017-11-20 11:42         ` [Qemu-devel] " Wei Wang
2017-11-20 11:42         ` Wei Wang
2017-11-20 11:42         ` Wei Wang
2017-11-20 11:42       ` Wei Wang
2017-11-15 20:32   ` [virtio-dev] " Michael S. Tsirkin
2017-11-15 20:32     ` [Qemu-devel] " Michael S. Tsirkin
2017-11-15 20:32     ` Michael S. Tsirkin
2017-11-15 20:32     ` Michael S. Tsirkin
2017-11-15 20:32     ` Michael S. Tsirkin
2017-11-16 13:27     ` [virtio-dev] " Wei Wang
2017-11-16 13:27     ` Wei Wang
2017-11-16 13:27       ` [Qemu-devel] " Wei Wang
2017-11-16 13:27       ` Wei Wang
2017-11-16 13:27       ` Wei Wang
2017-11-17 11:35       ` Wei Wang
2017-11-17 11:35         ` [Qemu-devel] " Wei Wang
2017-11-17 11:35         ` Wei Wang
2017-11-17 11:35         ` Wei Wang
2017-11-17 11:35         ` Wei Wang
2017-11-17 11:48         ` [virtio-dev] " Wei Wang
2017-11-17 11:48         ` Wei Wang
2017-11-17 11:48           ` [Qemu-devel] " Wei Wang
2017-11-17 11:48           ` Wei Wang
2017-11-17 11:48           ` Wei Wang
2017-11-17 12:44         ` Michael S. Tsirkin
2017-11-17 12:44           ` [Qemu-devel] " Michael S. Tsirkin
2017-11-17 12:44           ` Michael S. Tsirkin
2017-11-17 12:44           ` Michael S. Tsirkin
2017-11-17 12:44           ` Michael S. Tsirkin
2017-11-18  5:22           ` [virtio-dev] " Wang, Wei W
2017-11-18  5:22           ` Wang, Wei W
2017-11-18  5:22             ` [Qemu-devel] " Wang, Wei W
2017-11-18  5:22             ` Wang, Wei W
2017-11-18  5:22             ` Wang, Wei W
2017-11-18  5:22             ` Wang, Wei W
2017-11-19 15:11             ` Michael S. Tsirkin
2017-11-19 15:11               ` [Qemu-devel] " Michael S. Tsirkin
2017-11-19 15:11               ` Michael S. Tsirkin
2017-11-19 15:11               ` Michael S. Tsirkin
2017-11-19 15:11               ` Michael S. Tsirkin
2017-11-19 15:11             ` Michael S. Tsirkin
2017-11-17 12:44         ` Michael S. Tsirkin
2017-11-17 11:35       ` Wei Wang
2017-11-17 13:18       ` Michael S. Tsirkin
2017-11-17 13:18         ` [Qemu-devel] " Michael S. Tsirkin
2017-11-17 13:18         ` Michael S. Tsirkin
2017-11-17 13:18         ` Michael S. Tsirkin
2017-11-17 13:18         ` Michael S. Tsirkin
2017-11-03  8:13 ` Wei Wang

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=5A0D7D9A.1060509@intel.com \
    --to=wei.w.wang@intel.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=amit.shah@redhat.com \
    --cc=cornelia.huck@de.ibm.com \
    --cc=david@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=liliang.opensource@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mawilcox@microsoft.com \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=mst@redhat.com \
    --cc=nilal@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=qemu-devel@nongnu.org \
    --cc=quan.xu@aliyun.com \
    --cc=riel@redhat.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=virtualization@lists.linux-foundation.org \
    --cc=willy@infradead.org \
    --cc=yang.zhang.wz@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.