From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Alexander Duyck <alexander.duyck@gmail.com>,
virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org
Subject: [virtio-dev] Re: [PATCH v25 QEMU 3/3] virtio-balloon: Replace free page hinting references to 'report' with 'hint'
Date: Wed, 24 Jun 2020 16:36:37 -0400 [thread overview]
Message-ID: <20200624163604-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <dd2431be-fd22-9307-51e4-b081026f6315@redhat.com>
On Wed, Jun 24, 2020 at 06:01:02PM +0200, David Hildenbrand wrote:
> On 24.06.20 17:37, Michael S. Tsirkin wrote:
> > On Wed, Jun 24, 2020 at 05:28:59PM +0200, David Hildenbrand wrote:
> >>> So at the high level the idea was simple, we just clear the dirty bit
> >>> when page is hinted, unless we sent a new command since. Implementation
> >>> was reviewed by migration maintainers. If there's a consensus the code
> >>> is written so badly we can't maintain it, maybe we should remove it.
> >>> Which parts are unmaintainable in your eyes - migration or virtio ones?
> >>
> >> QEMU implementation without a propert virtio specification. I hope that
> >> we can *at least* finally document the expected behavior. Alex gave it a
> >> shot, and I was hoping that Wei could jump in to clarify, help move this
> >> forward ... after all he implemented (+designed?) the feature and the
> >> virtio interface.
> >>
> >>> Or maybe it's the general thing that interface was never specced
> >>> properly.
> >>
> >> Yes, a spec would be definitely a good starter ...
> >>
> >> [...]
> >>
> >>>>
> >>>> 1. If migration fails during RAM precopy, the guest will never receive a
> >>>> DONE notification. Probably easy to fix.
> >>>>
> >>>> 2. Unclear semantics. Alex tried to document what the actual semantics
> >>>> of hinted pages are.
> >>>
> >>> I'll reply to that now.
> >>>
> >>>> Assume the following in the guest to a previously
> >>>> hinted page
> >>>>
> >>>> /* page was hinted and is reused now */
> >>>> if (page[x] != Y)
> >>>> page[x] == Y;
> >>>> /* migration ends, we now run on the destination */
> >>>> BUG_ON(page[x] != Y);
> >>>> /* BUG, because the content chan
> >>>
> >>> The assumption hinting makes is that data in page is writtent to before it's used.
> >>>
> >>>
> >>>> A guest can observe that. And that could be a random driver that just
> >>>> allocated a page.
> >>>>
> >>>> (I *assume* in Linux we might catch that using kasan, but I am not 100%
> >>>> sure, also, the actual semantics to document are unclear - e.g., for
> >>>> other guests)
> >>>
> >>> I think it's basically simple: hinting means it's ok to
> >>> fill page with trash unless it has been modified since the command
> >>> ID supplied.
> >>
> >> Yeah, I quite dislike the semantics, especially, as they are different
> >> to well-know semantics as e.g., represent in MADV_FREE. Getting changed
> >> content when reading is really weird. But it seemed to be easier to
> >> implement (low hanging fruit) and nobody complained back then. Well, now
> >> we are stuck with it.
> >>
> >> [..]
> >
> > The difference with MADV_FREE is
> > - asynchronous (using cmd id to synchronize)
> > - zero not guaranteed
> >
> > right?
>
> *looking into man page*, yes, when reading you either get the old
> content or zero.
>
> (I remember that a re-read also makes the content stable, but looks like
> you really have to write to a page)
>
> We should most probably do what Alex suggested and initialize pages (at
> least write a single byte) when leaking them from the shrinker in the
> guest while hinting is active, such that the content is stable for
> anybody to allocate and reuse a page.
Drivers ignore old content from slab though, so I don't really see
the point.
> --
> Thanks,
>
> David / dhildenb
---------------------------------------------------------------------
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: "Michael S. Tsirkin" <mst@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: virtio-dev@lists.oasis-open.org, qemu-devel@nongnu.org,
Alexander Duyck <alexander.duyck@gmail.com>
Subject: Re: [PATCH v25 QEMU 3/3] virtio-balloon: Replace free page hinting references to 'report' with 'hint'
Date: Wed, 24 Jun 2020 16:36:37 -0400 [thread overview]
Message-ID: <20200624163604-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <dd2431be-fd22-9307-51e4-b081026f6315@redhat.com>
On Wed, Jun 24, 2020 at 06:01:02PM +0200, David Hildenbrand wrote:
> On 24.06.20 17:37, Michael S. Tsirkin wrote:
> > On Wed, Jun 24, 2020 at 05:28:59PM +0200, David Hildenbrand wrote:
> >>> So at the high level the idea was simple, we just clear the dirty bit
> >>> when page is hinted, unless we sent a new command since. Implementation
> >>> was reviewed by migration maintainers. If there's a consensus the code
> >>> is written so badly we can't maintain it, maybe we should remove it.
> >>> Which parts are unmaintainable in your eyes - migration or virtio ones?
> >>
> >> QEMU implementation without a propert virtio specification. I hope that
> >> we can *at least* finally document the expected behavior. Alex gave it a
> >> shot, and I was hoping that Wei could jump in to clarify, help move this
> >> forward ... after all he implemented (+designed?) the feature and the
> >> virtio interface.
> >>
> >>> Or maybe it's the general thing that interface was never specced
> >>> properly.
> >>
> >> Yes, a spec would be definitely a good starter ...
> >>
> >> [...]
> >>
> >>>>
> >>>> 1. If migration fails during RAM precopy, the guest will never receive a
> >>>> DONE notification. Probably easy to fix.
> >>>>
> >>>> 2. Unclear semantics. Alex tried to document what the actual semantics
> >>>> of hinted pages are.
> >>>
> >>> I'll reply to that now.
> >>>
> >>>> Assume the following in the guest to a previously
> >>>> hinted page
> >>>>
> >>>> /* page was hinted and is reused now */
> >>>> if (page[x] != Y)
> >>>> page[x] == Y;
> >>>> /* migration ends, we now run on the destination */
> >>>> BUG_ON(page[x] != Y);
> >>>> /* BUG, because the content chan
> >>>
> >>> The assumption hinting makes is that data in page is writtent to before it's used.
> >>>
> >>>
> >>>> A guest can observe that. And that could be a random driver that just
> >>>> allocated a page.
> >>>>
> >>>> (I *assume* in Linux we might catch that using kasan, but I am not 100%
> >>>> sure, also, the actual semantics to document are unclear - e.g., for
> >>>> other guests)
> >>>
> >>> I think it's basically simple: hinting means it's ok to
> >>> fill page with trash unless it has been modified since the command
> >>> ID supplied.
> >>
> >> Yeah, I quite dislike the semantics, especially, as they are different
> >> to well-know semantics as e.g., represent in MADV_FREE. Getting changed
> >> content when reading is really weird. But it seemed to be easier to
> >> implement (low hanging fruit) and nobody complained back then. Well, now
> >> we are stuck with it.
> >>
> >> [..]
> >
> > The difference with MADV_FREE is
> > - asynchronous (using cmd id to synchronize)
> > - zero not guaranteed
> >
> > right?
>
> *looking into man page*, yes, when reading you either get the old
> content or zero.
>
> (I remember that a re-read also makes the content stable, but looks like
> you really have to write to a page)
>
> We should most probably do what Alex suggested and initialize pages (at
> least write a single byte) when leaking them from the shrinker in the
> guest while hinting is active, such that the content is stable for
> anybody to allocate and reuse a page.
Drivers ignore old content from slab though, so I don't really see
the point.
> --
> Thanks,
>
> David / dhildenb
next prev parent reply other threads:[~2020-06-24 20:36 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-27 4:13 [virtio-dev] [PATCH v25 QEMU 0/3] virtio-balloon: add support for page poison and free page reporting Alexander Duyck
2020-05-27 4:13 ` Alexander Duyck
2020-05-27 4:14 ` [virtio-dev] [PATCH v25 QEMU 1/3] virtio-balloon: Implement support for page poison reporting feature Alexander Duyck
2020-05-27 4:14 ` Alexander Duyck
2020-05-27 4:14 ` [virtio-dev] [PATCH v25 QEMU 2/3] virtio-balloon: Provide an interface for free page reporting Alexander Duyck
2020-05-27 4:14 ` Alexander Duyck
2020-05-27 4:14 ` [virtio-dev] [PATCH v25 QEMU 3/3] virtio-balloon: Replace free page hinting references to 'report' with 'hint' Alexander Duyck
2020-05-27 4:14 ` Alexander Duyck
2020-06-13 20:07 ` [virtio-dev] " Alexander Duyck
2020-06-13 20:07 ` Alexander Duyck
2020-06-18 12:54 ` [virtio-dev] " David Hildenbrand
2020-06-18 12:54 ` David Hildenbrand
2020-06-18 15:14 ` [virtio-dev] " Alexander Duyck
2020-06-18 15:14 ` Alexander Duyck
2020-06-18 15:58 ` [virtio-dev] " David Hildenbrand
2020-06-18 15:58 ` David Hildenbrand
2020-06-18 16:09 ` [virtio-dev] " Michael S. Tsirkin
2020-06-18 16:09 ` Michael S. Tsirkin
2020-06-18 17:10 ` [virtio-dev] " David Hildenbrand
2020-06-18 17:10 ` David Hildenbrand
2020-06-18 17:20 ` [virtio-dev] " David Hildenbrand
2020-06-18 17:20 ` David Hildenbrand
2020-06-18 19:45 ` [virtio-dev] " Alexander Duyck
2020-06-18 19:45 ` Alexander Duyck
2020-06-18 20:20 ` [virtio-dev] " David Hildenbrand
2020-06-18 20:20 ` David Hildenbrand
2020-06-24 14:56 ` [virtio-dev] " Michael S. Tsirkin
2020-06-24 14:56 ` Michael S. Tsirkin
2020-06-24 15:28 ` [virtio-dev] " David Hildenbrand
2020-06-24 15:28 ` David Hildenbrand
2020-06-24 15:37 ` [virtio-dev] " Michael S. Tsirkin
2020-06-24 15:37 ` Michael S. Tsirkin
2020-06-24 16:01 ` [virtio-dev] " David Hildenbrand
2020-06-24 16:01 ` David Hildenbrand
2020-06-24 20:36 ` Michael S. Tsirkin [this message]
2020-06-24 20:36 ` Michael S. Tsirkin
2020-06-24 21:06 ` [virtio-dev] " David Hildenbrand
2020-06-24 21:06 ` David Hildenbrand
2020-06-18 19:00 ` [virtio-dev] " Dr. David Alan Gilbert
2020-06-18 19:00 ` Dr. David Alan Gilbert
2020-06-08 15:37 ` [virtio-dev] Re: [PATCH v25 QEMU 0/3] virtio-balloon: add support for page poison and free page reporting Alexander Duyck
2020-06-08 15:37 ` Alexander Duyck
2020-06-08 16:27 ` [virtio-dev] " Michael S. Tsirkin
2020-06-08 16:27 ` 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=20200624163604-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alexander.duyck@gmail.com \
--cc=david@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=virtio-dev@lists.oasis-open.org \
/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.