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: aarcange@redhat.com, virtio-dev@lists.oasis-open.org,
	kvm@vger.kernel.org, mawilcox@microsoft.com,
	qemu-devel@nongnu.org, amit.shah@redhat.com,
	penguin-kernel@I-love.SAKURA.ne.jp, linux-kernel@vger.kernel.org,
	willy@infradead.org, virtualization@lists.linux-foundation.org,
	linux-mm@kvack.org, yang.zhang.wz@gmail.com, quan.xu@aliyun.com,
	cornelia.huck@de.ibm.com, pbonzini@redhat.com,
	akpm@linux-foundation.org, mhocko@kernel.org,
	mgorman@techsingularity.net, liliang.opensource@gmail.com
Subject: Re: [virtio-dev] Re: [PATCH v17 6/6] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
Date: Fri, 17 Nov 2017 19:48:37 +0800	[thread overview]
Message-ID: <5A0ECC95.7070300@intel.com> (raw)
In-Reply-To: <5A0EC967.5090407@intel.com>

On 11/17/2017 07:35 PM, Wei Wang wrote:
> On 11/16/2017 09:27 PM, Wei Wang wrote:
>> On 11/16/2017 04:32 AM, Michael S. Tsirkin wrote:
>>> On Fri, Nov 03, 2017 at 04:13:06PM +0800, Wei Wang wrote:
>>>> Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_VQ feature indicates the
>>>> support of reporting hints of guest free pages to the host via
>>>> virtio-balloon. The host requests the guest to report the free 
>>>> pages by
>>>> sending commands via the virtio-balloon configuration registers.
>>>>
>>>> When the guest starts to report, the first element added to the 
>>>> free page
>>>> vq is a sequence id of the start reporting command. The id is given by
>>>> the host, and it indicates whether the following free pages correspond
>>>> to the command. For example, the host may stop the report and start 
>>>> again
>>>> with a new command id. The obsolete pages for the previous start 
>>>> command
>>>> can be detected by the id dismatching on the host. The id is added 
>>>> to the
>>>> vq using an output buffer, and the free pages are added to the vq 
>>>> using
>>>> input buffer.
>>>>
>>>> Here are some explainations about the added configuration registers:
>>>> - host2guest_cmd: a register used by the host to send commands to the
>>>> guest.
>>>> - 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).
>>>> - free_page_cmd_id: the sequence id of the free page report command
>>>> given by the host.
>>>>
>>>> Signed-off-by: Wei Wang <wei.w.wang@intel.com>
>>>> Signed-off-by: Liang Li <liang.z.li@intel.com>
>>>> Cc: Michael S. Tsirkin <mst@redhat.com>
>>>> Cc: Michal Hocko <mhocko@kernel.org>
>>>> ---
>>>>
>>>> +
>>>> +static void report_free_page(struct work_struct *work)
>>>> +{
>>>> +    struct virtio_balloon *vb;
>>>> +
>>>> +    vb = container_of(work, struct virtio_balloon, 
>>>> report_free_page_work);
>>>> +    report_free_page_cmd_id(vb);
>>>> +    walk_free_mem_block(vb, 0, &virtio_balloon_send_free_pages);
>>>> +    /*
>>>> +     * The last few free page blocks that were added may not reach 
>>>> the
>>>> +     * batch size, but need a kick to notify the device to handle 
>>>> them.
>>>> +     */
>>>> +    virtqueue_kick(vb->free_page_vq);
>>>> +    report_free_page_end(vb);
>>>> +}
>>>> +
>>> I think there's an issue here: if pages are poisoned and hypervisor
>>> subsequently drops them, testing them after allocation will
>>> trigger a false positive.
>>>
>>> The specific configuration:
>>>
>>> PAGE_POISONING on
>>> PAGE_POISONING_NO_SANITY off
>>> PAGE_POISONING_ZERO off
>>>
>>>
>>> Solutions:
>>> 1. disable the feature in that configuration
>>>     suggested as an initial step
>>
>> Thanks for the finding.
>> Similar to this option: I'm thinking could we make 
>> walk_free_mem_block() simply return if that option is on?
>> That is, at the beginning of the function:
>>     if (!page_poisoning_enabled())
>>                 return;
>>
>
>
> Thought about it more, I think it would be better to put this logic to 
> virtio_balloon:
>
>         send_free_page_cmd_id(vb, &vb->start_cmd_id);
>         if (page_poisoning_enabled() &&
>             !IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY))
>                 walk_free_mem_block(vb, 0, 
> &virtio_balloon_send_free_pages);

logic should be inverse:
     if (!(page_poisoning_enabled() &&
             !IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY)))

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: aarcange@redhat.com, virtio-dev@lists.oasis-open.org,
	kvm@vger.kernel.org, mawilcox@microsoft.com,
	qemu-devel@nongnu.org, amit.shah@redhat.com,
	penguin-kernel@I-love.SAKURA.ne.jp, linux-kernel@vger.kernel.org,
	willy@infradead.org, virtualization@lists.linux-foundation.org,
	linux-mm@kvack.org, yang.zhang.wz@gmail.com, quan.xu@aliyun.com,
	cornelia.huck@de.ibm.com, pbonzini@redhat.com,
	akpm@linux-foundation.org, mhocko@kernel.org,
	mgorman@techsingularity.net, liliang.opensource@gmail.com
Subject: Re: [virtio-dev] Re: [PATCH v17 6/6] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
Date: Fri, 17 Nov 2017 19:48:37 +0800	[thread overview]
Message-ID: <5A0ECC95.7070300@intel.com> (raw)
In-Reply-To: <5A0EC967.5090407@intel.com>

On 11/17/2017 07:35 PM, Wei Wang wrote:
> On 11/16/2017 09:27 PM, Wei Wang wrote:
>> On 11/16/2017 04:32 AM, Michael S. Tsirkin wrote:
>>> On Fri, Nov 03, 2017 at 04:13:06PM +0800, Wei Wang wrote:
>>>> Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_VQ feature indicates the
>>>> support of reporting hints of guest free pages to the host via
>>>> virtio-balloon. The host requests the guest to report the free 
>>>> pages by
>>>> sending commands via the virtio-balloon configuration registers.
>>>>
>>>> When the guest starts to report, the first element added to the 
>>>> free page
>>>> vq is a sequence id of the start reporting command. The id is given by
>>>> the host, and it indicates whether the following free pages correspond
>>>> to the command. For example, the host may stop the report and start 
>>>> again
>>>> with a new command id. The obsolete pages for the previous start 
>>>> command
>>>> can be detected by the id dismatching on the host. The id is added 
>>>> to the
>>>> vq using an output buffer, and the free pages are added to the vq 
>>>> using
>>>> input buffer.
>>>>
>>>> Here are some explainations about the added configuration registers:
>>>> - host2guest_cmd: a register used by the host to send commands to the
>>>> guest.
>>>> - 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).
>>>> - free_page_cmd_id: the sequence id of the free page report command
>>>> given by the host.
>>>>
>>>> Signed-off-by: Wei Wang <wei.w.wang@intel.com>
>>>> Signed-off-by: Liang Li <liang.z.li@intel.com>
>>>> Cc: Michael S. Tsirkin <mst@redhat.com>
>>>> Cc: Michal Hocko <mhocko@kernel.org>
>>>> ---
>>>>
>>>> +
>>>> +static void report_free_page(struct work_struct *work)
>>>> +{
>>>> +    struct virtio_balloon *vb;
>>>> +
>>>> +    vb = container_of(work, struct virtio_balloon, 
>>>> report_free_page_work);
>>>> +    report_free_page_cmd_id(vb);
>>>> +    walk_free_mem_block(vb, 0, &virtio_balloon_send_free_pages);
>>>> +    /*
>>>> +     * The last few free page blocks that were added may not reach 
>>>> the
>>>> +     * batch size, but need a kick to notify the device to handle 
>>>> them.
>>>> +     */
>>>> +    virtqueue_kick(vb->free_page_vq);
>>>> +    report_free_page_end(vb);
>>>> +}
>>>> +
>>> I think there's an issue here: if pages are poisoned and hypervisor
>>> subsequently drops them, testing them after allocation will
>>> trigger a false positive.
>>>
>>> The specific configuration:
>>>
>>> PAGE_POISONING on
>>> PAGE_POISONING_NO_SANITY off
>>> PAGE_POISONING_ZERO off
>>>
>>>
>>> Solutions:
>>> 1. disable the feature in that configuration
>>>     suggested as an initial step
>>
>> Thanks for the finding.
>> Similar to this option: I'm thinking could we make 
>> walk_free_mem_block() simply return if that option is on?
>> That is, at the beginning of the function:
>>     if (!page_poisoning_enabled())
>>                 return;
>>
>
>
> Thought about it more, I think it would be better to put this logic to 
> virtio_balloon:
>
>         send_free_page_cmd_id(vb, &vb->start_cmd_id);
>         if (page_poisoning_enabled() &&
>             !IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY))
>                 walk_free_mem_block(vb, 0, 
> &virtio_balloon_send_free_pages);

logic should be inverse:
     if (!(page_poisoning_enabled() &&
             !IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY)))

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: aarcange@redhat.com, virtio-dev@lists.oasis-open.org,
	kvm@vger.kernel.org, mawilcox@microsoft.com,
	qemu-devel@nongnu.org, amit.shah@redhat.com,
	penguin-kernel@I-love.SAKURA.ne.jp, linux-kernel@vger.kernel.org,
	willy@infradead.org, virtualization@lists.linux-foundation.org,
	linux-mm@kvack.org, yang.zhang.wz@gmail.com, quan.xu@aliyun.com,
	cornelia.huck@de.ibm.com, pbonzini@redhat.com,
	akpm@linux-foundation.org, mhocko@kernel.org,
	mgorman@techsingularity.net, liliang.opensource@gmail.com
Subject: Re: [Qemu-devel] [virtio-dev] Re: [PATCH v17 6/6] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
Date: Fri, 17 Nov 2017 19:48:37 +0800	[thread overview]
Message-ID: <5A0ECC95.7070300@intel.com> (raw)
In-Reply-To: <5A0EC967.5090407@intel.com>

On 11/17/2017 07:35 PM, Wei Wang wrote:
> On 11/16/2017 09:27 PM, Wei Wang wrote:
>> On 11/16/2017 04:32 AM, Michael S. Tsirkin wrote:
>>> On Fri, Nov 03, 2017 at 04:13:06PM +0800, Wei Wang wrote:
>>>> Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_VQ feature indicates the
>>>> support of reporting hints of guest free pages to the host via
>>>> virtio-balloon. The host requests the guest to report the free 
>>>> pages by
>>>> sending commands via the virtio-balloon configuration registers.
>>>>
>>>> When the guest starts to report, the first element added to the 
>>>> free page
>>>> vq is a sequence id of the start reporting command. The id is given by
>>>> the host, and it indicates whether the following free pages correspond
>>>> to the command. For example, the host may stop the report and start 
>>>> again
>>>> with a new command id. The obsolete pages for the previous start 
>>>> command
>>>> can be detected by the id dismatching on the host. The id is added 
>>>> to the
>>>> vq using an output buffer, and the free pages are added to the vq 
>>>> using
>>>> input buffer.
>>>>
>>>> Here are some explainations about the added configuration registers:
>>>> - host2guest_cmd: a register used by the host to send commands to the
>>>> guest.
>>>> - 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).
>>>> - free_page_cmd_id: the sequence id of the free page report command
>>>> given by the host.
>>>>
>>>> Signed-off-by: Wei Wang <wei.w.wang@intel.com>
>>>> Signed-off-by: Liang Li <liang.z.li@intel.com>
>>>> Cc: Michael S. Tsirkin <mst@redhat.com>
>>>> Cc: Michal Hocko <mhocko@kernel.org>
>>>> ---
>>>>
>>>> +
>>>> +static void report_free_page(struct work_struct *work)
>>>> +{
>>>> +    struct virtio_balloon *vb;
>>>> +
>>>> +    vb = container_of(work, struct virtio_balloon, 
>>>> report_free_page_work);
>>>> +    report_free_page_cmd_id(vb);
>>>> +    walk_free_mem_block(vb, 0, &virtio_balloon_send_free_pages);
>>>> +    /*
>>>> +     * The last few free page blocks that were added may not reach 
>>>> the
>>>> +     * batch size, but need a kick to notify the device to handle 
>>>> them.
>>>> +     */
>>>> +    virtqueue_kick(vb->free_page_vq);
>>>> +    report_free_page_end(vb);
>>>> +}
>>>> +
>>> I think there's an issue here: if pages are poisoned and hypervisor
>>> subsequently drops them, testing them after allocation will
>>> trigger a false positive.
>>>
>>> The specific configuration:
>>>
>>> PAGE_POISONING on
>>> PAGE_POISONING_NO_SANITY off
>>> PAGE_POISONING_ZERO off
>>>
>>>
>>> Solutions:
>>> 1. disable the feature in that configuration
>>>     suggested as an initial step
>>
>> Thanks for the finding.
>> Similar to this option: I'm thinking could we make 
>> walk_free_mem_block() simply return if that option is on?
>> That is, at the beginning of the function:
>>     if (!page_poisoning_enabled())
>>                 return;
>>
>
>
> Thought about it more, I think it would be better to put this logic to 
> virtio_balloon:
>
>         send_free_page_cmd_id(vb, &vb->start_cmd_id);
>         if (page_poisoning_enabled() &&
>             !IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY))
>                 walk_free_mem_block(vb, 0, 
> &virtio_balloon_send_free_pages);

logic should be inverse:
     if (!(page_poisoning_enabled() &&
             !IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY)))

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: aarcange@redhat.com, virtio-dev@lists.oasis-open.org,
	kvm@vger.kernel.org, mawilcox@microsoft.com,
	qemu-devel@nongnu.org, amit.shah@redhat.com,
	penguin-kernel@I-love.SAKURA.ne.jp, linux-kernel@vger.kernel.org,
	willy@infradead.org, virtualization@lists.linux-foundation.org,
	linux-mm@kvack.org, yang.zhang.wz@gmail.com, quan.xu@aliyun.com,
	cornelia.huck@de.ibm.com, pbonzini@redhat.com,
	akpm@linux-foundation.org, mhocko@kernel.org,
	mgorman@techsingularity.net, liliang.opensource@gmail.com
Subject: Re: [virtio-dev] Re: [PATCH v17 6/6] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ
Date: Fri, 17 Nov 2017 19:48:37 +0800	[thread overview]
Message-ID: <5A0ECC95.7070300@intel.com> (raw)
In-Reply-To: <5A0EC967.5090407@intel.com>

On 11/17/2017 07:35 PM, Wei Wang wrote:
> On 11/16/2017 09:27 PM, Wei Wang wrote:
>> On 11/16/2017 04:32 AM, Michael S. Tsirkin wrote:
>>> On Fri, Nov 03, 2017 at 04:13:06PM +0800, Wei Wang wrote:
>>>> Negotiation of the VIRTIO_BALLOON_F_FREE_PAGE_VQ feature indicates the
>>>> support of reporting hints of guest free pages to the host via
>>>> virtio-balloon. The host requests the guest to report the free 
>>>> pages by
>>>> sending commands via the virtio-balloon configuration registers.
>>>>
>>>> When the guest starts to report, the first element added to the 
>>>> free page
>>>> vq is a sequence id of the start reporting command. The id is given by
>>>> the host, and it indicates whether the following free pages correspond
>>>> to the command. For example, the host may stop the report and start 
>>>> again
>>>> with a new command id. The obsolete pages for the previous start 
>>>> command
>>>> can be detected by the id dismatching on the host. The id is added 
>>>> to the
>>>> vq using an output buffer, and the free pages are added to the vq 
>>>> using
>>>> input buffer.
>>>>
>>>> Here are some explainations about the added configuration registers:
>>>> - host2guest_cmd: a register used by the host to send commands to the
>>>> guest.
>>>> - 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).
>>>> - free_page_cmd_id: the sequence id of the free page report command
>>>> given by the host.
>>>>
>>>> Signed-off-by: Wei Wang <wei.w.wang@intel.com>
>>>> Signed-off-by: Liang Li <liang.z.li@intel.com>
>>>> Cc: Michael S. Tsirkin <mst@redhat.com>
>>>> Cc: Michal Hocko <mhocko@kernel.org>
>>>> ---
>>>>
>>>> +
>>>> +static void report_free_page(struct work_struct *work)
>>>> +{
>>>> +    struct virtio_balloon *vb;
>>>> +
>>>> +    vb = container_of(work, struct virtio_balloon, 
>>>> report_free_page_work);
>>>> +    report_free_page_cmd_id(vb);
>>>> +    walk_free_mem_block(vb, 0, &virtio_balloon_send_free_pages);
>>>> +    /*
>>>> +     * The last few free page blocks that were added may not reach 
>>>> the
>>>> +     * batch size, but need a kick to notify the device to handle 
>>>> them.
>>>> +     */
>>>> +    virtqueue_kick(vb->free_page_vq);
>>>> +    report_free_page_end(vb);
>>>> +}
>>>> +
>>> I think there's an issue here: if pages are poisoned and hypervisor
>>> subsequently drops them, testing them after allocation will
>>> trigger a false positive.
>>>
>>> The specific configuration:
>>>
>>> PAGE_POISONING on
>>> PAGE_POISONING_NO_SANITY off
>>> PAGE_POISONING_ZERO off
>>>
>>>
>>> Solutions:
>>> 1. disable the feature in that configuration
>>>     suggested as an initial step
>>
>> Thanks for the finding.
>> Similar to this option: I'm thinking could we make 
>> walk_free_mem_block() simply return if that option is on?
>> That is, at the beginning of the function:
>>     if (!page_poisoning_enabled())
>>                 return;
>>
>
>
> Thought about it more, I think it would be better to put this logic to 
> virtio_balloon:
>
>         send_free_page_cmd_id(vb, &vb->start_cmd_id);
>         if (page_poisoning_enabled() &&
>             !IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY))
>                 walk_free_mem_block(vb, 0, 
> &virtio_balloon_send_free_pages);

logic should be inverse:
     if (!(page_poisoning_enabled() &&
             !IS_ENABLED(CONFIG_PAGE_POISONING_NO_SANITY)))

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


  parent reply	other threads:[~2017-11-17 11:46 UTC|newest]

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

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=5A0ECC95.7070300@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=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=pbonzini@redhat.com \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=qemu-devel@nongnu.org \
    --cc=quan.xu@aliyun.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.