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: qemu-devel@nongnu.org, virtio-dev@lists.oasis-open.org,
	quintela@redhat.com, dgilbert@redhat.com, pbonzini@redhat.com,
	liliang.opensource@gmail.com, yang.zhang.wz@gmail.com,
	quan.xu0@gmail.com, nilal@redhat.com, riel@redhat.com,
	zhang.zhanghailiang@huawei.com
Subject: Re: [Qemu-devel] [PATCH v7 4/5] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT
Date: Fri, 01 Jun 2018 11:18:13 +0800	[thread overview]
Message-ID: <5B10BAF5.5080901@intel.com> (raw)
In-Reply-To: <20180531203837-mutt-send-email-mst@kernel.org>

On 06/01/2018 01:42 AM, Michael S. Tsirkin wrote:
> On Thu, May 31, 2018 at 10:27:00AM +0800, Wei Wang wrote:
>> On 05/30/2018 08:47 PM, Michael S. Tsirkin wrote:
>>> On Wed, May 30, 2018 at 05:12:09PM +0800, Wei Wang wrote:
>>>> On 05/29/2018 11:24 PM, Michael S. Tsirkin wrote:
>>>>> On Tue, Apr 24, 2018 at 02:13:47PM +0800, Wei Wang wrote:
>>>>>> +/*
>>>>>> + * Balloon will report pages which were free at the time of this call. As the
>>>>>> + * reporting happens asynchronously, dirty bit logging must be enabled before
>>>>>> + * this call is made.
>>>>>> + */
>>>>>> +void balloon_free_page_start(void)
>>>>>> +{
>>>>>> +    balloon_free_page_start_fn(balloon_opaque);
>>>>>> +}
>>>>> Please create notifier support, not a single global.
>>>> OK. The start is called at the end of bitmap_sync, and the stop is called at
>>>> the beginning of bitmap_sync. In this case, we will need to add two
>>>> migration states, MIGRATION_STATUS_BEFORE_BITMAP_SYNC and
>>>> MIGRATION_STATUS_AFTER_BITMAP_SYNC, right?
>>> If that's the way you do it, you need to ask migration guys, not me.
>> Yeah, I know.. thanks for the virtio part.
>>
>>>>> +
>>>>> +static bool virtio_balloon_free_page_support(void *opaque)
>>>>> +{
>>>>> +    VirtIOBalloon *s = opaque;
>>>>> +    VirtIODevice *vdev = VIRTIO_DEVICE(s);
>>>>> +
>>>>> +    return virtio_vdev_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT);
>>>>> or if poison is negotiated.
>>>> Will make it
>>>> return virtio_vdev_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT) &&
>>>> !virtio_vdev_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)
>>> I mean the reverse:
>>> 	virtio_vdev_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT) ||
>>> 	virtio_vdev_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)
>>>
>>>
>>> If poison has been negotiated you must migrate the
>>> guest supplied value even if you don't use it for hints.
>>
>> Just a little confused with the logic. Writing it that way means that we are
>> taking this possibility "virtio_vdev_has_feature(vdev,
>> VIRTIO_BALLOON_F_FREE_PAGE_HINT)=fasle, virtio_vdev_has_feature(vdev,
>> VIRTIO_BALLOON_F_PAGE_POISON)=true" into account, and let the support
>> function return true when F_FREE_PAGE_HINT isn't supported.
> All I am saying is that in this configuration, you must migrate
> the poison value programmed by guest even if you do not
> yet use it without VIRTIO_BALLOON_F_FREE_PAGE_HINT.
>
> Right now you have
> a section:
> +    .needed = virtio_balloon_free_page_support,
>
> which includes the poison value.
>
> So if guest migrates after writing the poison value,
> it's lost. Not nice.
>
>> If guest doesn't support F_FREE_PAGE_HINT, it doesn't support the free page
>> reporting (even the free page vq). I'm not sure why we tell the migration
>> thread that the free page reporting feature is supported via this support
>> function. If the support function simply returns false when F_FREE_PAGE_HINT
>> isn't negotiated, the legacy migration already migrates the poisoned pages
>> (not skipped, but may be compressed).
>>
>> I think it would be better to simply use the original "return
>> virtio_vdev_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)" here.
>
> So maybe you should put the poison value in a separate section then.

Yes, that looks good to me, thanks.

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: qemu-devel@nongnu.org, virtio-dev@lists.oasis-open.org,
	quintela@redhat.com, dgilbert@redhat.com, pbonzini@redhat.com,
	liliang.opensource@gmail.com, yang.zhang.wz@gmail.com,
	quan.xu0@gmail.com, nilal@redhat.com, riel@redhat.com,
	zhang.zhanghailiang@huawei.com
Subject: [virtio-dev] Re: [PATCH v7 4/5] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT
Date: Fri, 01 Jun 2018 11:18:13 +0800	[thread overview]
Message-ID: <5B10BAF5.5080901@intel.com> (raw)
In-Reply-To: <20180531203837-mutt-send-email-mst@kernel.org>

On 06/01/2018 01:42 AM, Michael S. Tsirkin wrote:
> On Thu, May 31, 2018 at 10:27:00AM +0800, Wei Wang wrote:
>> On 05/30/2018 08:47 PM, Michael S. Tsirkin wrote:
>>> On Wed, May 30, 2018 at 05:12:09PM +0800, Wei Wang wrote:
>>>> On 05/29/2018 11:24 PM, Michael S. Tsirkin wrote:
>>>>> On Tue, Apr 24, 2018 at 02:13:47PM +0800, Wei Wang wrote:
>>>>>> +/*
>>>>>> + * Balloon will report pages which were free at the time of this call. As the
>>>>>> + * reporting happens asynchronously, dirty bit logging must be enabled before
>>>>>> + * this call is made.
>>>>>> + */
>>>>>> +void balloon_free_page_start(void)
>>>>>> +{
>>>>>> +    balloon_free_page_start_fn(balloon_opaque);
>>>>>> +}
>>>>> Please create notifier support, not a single global.
>>>> OK. The start is called at the end of bitmap_sync, and the stop is called at
>>>> the beginning of bitmap_sync. In this case, we will need to add two
>>>> migration states, MIGRATION_STATUS_BEFORE_BITMAP_SYNC and
>>>> MIGRATION_STATUS_AFTER_BITMAP_SYNC, right?
>>> If that's the way you do it, you need to ask migration guys, not me.
>> Yeah, I know.. thanks for the virtio part.
>>
>>>>> +
>>>>> +static bool virtio_balloon_free_page_support(void *opaque)
>>>>> +{
>>>>> +    VirtIOBalloon *s = opaque;
>>>>> +    VirtIODevice *vdev = VIRTIO_DEVICE(s);
>>>>> +
>>>>> +    return virtio_vdev_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT);
>>>>> or if poison is negotiated.
>>>> Will make it
>>>> return virtio_vdev_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT) &&
>>>> !virtio_vdev_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)
>>> I mean the reverse:
>>> 	virtio_vdev_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT) ||
>>> 	virtio_vdev_has_feature(vdev, VIRTIO_BALLOON_F_PAGE_POISON)
>>>
>>>
>>> If poison has been negotiated you must migrate the
>>> guest supplied value even if you don't use it for hints.
>>
>> Just a little confused with the logic. Writing it that way means that we are
>> taking this possibility "virtio_vdev_has_feature(vdev,
>> VIRTIO_BALLOON_F_FREE_PAGE_HINT)=fasle, virtio_vdev_has_feature(vdev,
>> VIRTIO_BALLOON_F_PAGE_POISON)=true" into account, and let the support
>> function return true when F_FREE_PAGE_HINT isn't supported.
> All I am saying is that in this configuration, you must migrate
> the poison value programmed by guest even if you do not
> yet use it without VIRTIO_BALLOON_F_FREE_PAGE_HINT.
>
> Right now you have
> a section:
> +    .needed = virtio_balloon_free_page_support,
>
> which includes the poison value.
>
> So if guest migrates after writing the poison value,
> it's lost. Not nice.
>
>> If guest doesn't support F_FREE_PAGE_HINT, it doesn't support the free page
>> reporting (even the free page vq). I'm not sure why we tell the migration
>> thread that the free page reporting feature is supported via this support
>> function. If the support function simply returns false when F_FREE_PAGE_HINT
>> isn't negotiated, the legacy migration already migrates the poisoned pages
>> (not skipped, but may be compressed).
>>
>> I think it would be better to simply use the original "return
>> virtio_vdev_has_feature(vdev, VIRTIO_BALLOON_F_FREE_PAGE_HINT)" here.
>
> So maybe you should put the poison value in a separate section then.

Yes, that looks good to me, thanks.

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


  reply	other threads:[~2018-06-01  3:14 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-24  6:13 [Qemu-devel] [PATCH v7 0/5] virtio-balloon: free page hint reporting support Wei Wang
2018-04-24  6:13 ` [virtio-dev] " Wei Wang
2018-04-24  6:13 ` [Qemu-devel] [PATCH v7 1/5] bitmap: bitmap_count_one_with_offset Wei Wang
2018-04-24  6:13   ` [virtio-dev] " Wei Wang
2018-04-24  6:13 ` [Qemu-devel] [PATCH v7 2/5] migration: use bitmap_mutex in migration_bitmap_clear_dirty Wei Wang
2018-04-24  6:13   ` [virtio-dev] " Wei Wang
2018-06-01  3:37   ` [Qemu-devel] " Peter Xu
2018-04-24  6:13 ` [Qemu-devel] [PATCH v7 3/5] migration: API to clear bits of guest free pages from the dirty bitmap Wei Wang
2018-04-24  6:13   ` [virtio-dev] " Wei Wang
2018-06-01  4:00   ` [Qemu-devel] " Peter Xu
2018-06-01  7:36     ` Wei Wang
2018-06-01  7:36       ` [virtio-dev] " Wei Wang
2018-06-01 10:06       ` Peter Xu
2018-06-01 12:32         ` Wei Wang
2018-06-01 12:32           ` [virtio-dev] " Wei Wang
2018-06-04  2:49           ` Peter Xu
2018-06-04  7:43             ` Wei Wang
2018-06-04  7:43               ` [virtio-dev] " Wei Wang
2018-04-24  6:13 ` [Qemu-devel] [PATCH v7 4/5] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_HINT Wei Wang
2018-04-24  6:13   ` [virtio-dev] " Wei Wang
2018-05-29 15:24   ` [Qemu-devel] " Michael S. Tsirkin
2018-05-29 15:24     ` [virtio-dev] " Michael S. Tsirkin
2018-05-30  9:12     ` [Qemu-devel] " Wei Wang
2018-05-30  9:12       ` [virtio-dev] " Wei Wang
2018-05-30 12:47       ` [Qemu-devel] " Michael S. Tsirkin
2018-05-30 12:47         ` [virtio-dev] " Michael S. Tsirkin
2018-05-31  2:27         ` [Qemu-devel] " Wei Wang
2018-05-31  2:27           ` [virtio-dev] " Wei Wang
2018-05-31 17:42           ` [Qemu-devel] " Michael S. Tsirkin
2018-05-31 17:42             ` [virtio-dev] " Michael S. Tsirkin
2018-06-01  3:18             ` Wei Wang [this message]
2018-06-01  3:18               ` Wei Wang
2018-06-04  8:04         ` [Qemu-devel] " Wei Wang
2018-06-04  8:04           ` [virtio-dev] " Wei Wang
2018-06-05  6:58           ` [Qemu-devel] " Peter Xu
2018-06-05 13:22             ` Wei Wang
2018-06-05 13:22               ` [virtio-dev] " Wei Wang
2018-06-06  5:42               ` [Qemu-devel] " Peter Xu
2018-06-06 10:04                 ` Wei Wang
2018-06-06 10:04                   ` [virtio-dev] " Wei Wang
2018-06-06 11:02                   ` [Qemu-devel] " Peter Xu
2018-06-07  5:24                     ` Wei Wang
2018-06-07  5:24                       ` [virtio-dev] " Wei Wang
2018-06-07  6:32                       ` [Qemu-devel] " Peter Xu
2018-06-07 11:59                         ` Wei Wang
2018-06-07 11:59                           ` [virtio-dev] " Wei Wang
2018-06-08  2:17                           ` [Qemu-devel] " Peter Xu
2018-06-08  7:14                             ` Wei Wang
2018-06-08  7:14                               ` [virtio-dev] " Wei Wang
2018-06-08  7:31                         ` [Qemu-devel] " Wei Wang
2018-06-08  7:31                           ` [virtio-dev] " Wei Wang
2018-06-06  6:43   ` [Qemu-devel] " Peter Xu
2018-06-06 10:11     ` Wei Wang
2018-06-06 10:11       ` [virtio-dev] " Wei Wang
2018-06-07  3:17       ` Peter Xu
2018-06-07  5:29         ` Wei Wang
2018-06-07  5:29           ` [virtio-dev] " Wei Wang
2018-06-07  6:58           ` Peter Xu
2018-06-07 12:01             ` Wei Wang
2018-06-07 12:01               ` [virtio-dev] " Wei Wang
2018-06-08  1:37               ` Peter Xu
2018-06-08  1:58                 ` Peter Xu
2018-06-08  1:58                 ` Michael S. Tsirkin
2018-06-08  1:58                   ` [virtio-dev] " Michael S. Tsirkin
2018-06-08  2:34                   ` Peter Xu
2018-06-08  2:49                     ` Michael S. Tsirkin
2018-06-08  2:49                       ` [virtio-dev] " Michael S. Tsirkin
2018-06-08  3:34                       ` Peter Xu
2018-04-24  6:13 ` [Qemu-devel] [PATCH v7 5/5] migration: use the free page hint feature from balloon Wei Wang
2018-04-24  6:13   ` [virtio-dev] " Wei Wang
2018-04-24  6:42 ` [Qemu-devel] [PATCH v7 0/5] virtio-balloon: free page hint reporting support Wei Wang
2018-04-24  6:42   ` [virtio-dev] " Wei Wang
2018-05-14  1:22 ` [Qemu-devel] " Wei Wang
2018-05-14  1:22   ` [virtio-dev] " Wei Wang
2018-05-29 15:00 ` [Qemu-devel] " Hailiang Zhang
2018-05-29 15:24   ` Michael S. Tsirkin
2018-05-29 15:24     ` [virtio-dev] " Michael S. Tsirkin
2018-06-01  4:58 ` Peter Xu
2018-06-01  5:07   ` Peter Xu
2018-06-01  7:29     ` Wei Wang
2018-06-01  7:29       ` [virtio-dev] " Wei Wang
2018-06-01 10:02       ` Peter Xu
2018-06-01 12:31         ` Wei Wang
2018-06-01 12:31           ` [virtio-dev] " Wei Wang
2018-06-01  7:21   ` Wei Wang
2018-06-01  7:21     ` [virtio-dev] " Wei Wang
2018-06-01 10:40     ` Peter Xu
2018-06-01 15:33       ` Dr. David Alan Gilbert
2018-06-05  6:42         ` Peter Xu
2018-06-05 14:40           ` Michael S. Tsirkin
2018-06-05 14:40             ` [virtio-dev] " Michael S. Tsirkin
2018-06-05 14:39         ` Michael S. Tsirkin
2018-06-05 14:39           ` [virtio-dev] " 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=5B10BAF5.5080901@intel.com \
    --to=wei.w.wang@intel.com \
    --cc=dgilbert@redhat.com \
    --cc=liliang.opensource@gmail.com \
    --cc=mst@redhat.com \
    --cc=nilal@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quan.xu0@gmail.com \
    --cc=quintela@redhat.com \
    --cc=riel@redhat.com \
    --cc=virtio-dev@lists.oasis-open.org \
    --cc=yang.zhang.wz@gmail.com \
    --cc=zhang.zhanghailiang@huawei.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.