From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: Alexander Duyck <alexander.duyck@gmail.com>,
Jason Wang <jasowang@redhat.com>,
virtio-dev@lists.oasis-open.org,
virtualization@lists.linux-foundation.org
Subject: Re: [virtio-dev] Re: [PATCH] virtio-balloon: Disable free page hinting/reporting if page poison is disabled
Date: Fri, 17 Apr 2020 04:50:00 -0400 [thread overview]
Message-ID: <20200417044641-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <08d2c4e2-8c0f-7d3c-89f1-0e6c6a2756c8@redhat.com>
On Fri, Apr 17, 2020 at 09:49:03AM +0200, David Hildenbrand wrote:
> On 17.04.20 08:28, Michael S. Tsirkin wrote:
> > On Thu, Apr 16, 2020 at 04:52:42PM -0700, Alexander Duyck wrote:
> >> On Thu, Apr 16, 2020 at 3:13 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >>>
> >>> On Thu, Apr 16, 2020 at 12:30:38PM -0700, Alexander Duyck wrote:
> >>>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> >>>>
> >>>> If we have free page hinting or page reporting enabled we should disable it
> >>>> if the pages are poisoned or initialized on free and we cannot notify the
> >>>> hypervisor.
> >>>>
> >>>> Fixes: 5d757c8d518d ("virtio-balloon: add support for providing free page reports to host")
> >>>>
> >>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> >>>
> >>>
> >>> Why not put this logic in the hypervisor?
> >>
> >> I did that too. This is to cover the case where somebody is running
> >> the code prior to my QEMU changes where the page poison feature wasn't
> >> being enabled.
> >
> >
> > Hmm so that one looks like a QEMU bug (does not expose poison flag). In
> > the past we just said need to fix the bug where it's found unless the
> > issue is very widespread and major. Let's assume QEMU learns to always
> > expose POISON with HINT. Then this configuration (HINT && !POISON)
> > allows us to detect old QEMU (pre your changes).
>
> Don't see why this is a QEMU bug. It's just a feature it does not
> implement. Perfectly valid.
I'll need to think about this.
We need to remember that the whole HINT thing is not a mandate for host to
corrupt memory. It's just some info about page use guest
gives host. If host corrupts memory it's broken ...
> [...]
> >>
> >> The problem is we cannot communicate the full situation to the
> >> hypervisor without the page poison feature being present. As such I
> >> would worry about that backfiring on us due to the hypervisor acting
> >> on incomplete data.
> >
> >
> > I'll try to think about VIRTIO_BALLOON_F_FREE_PAGE_HINT situation
> > over the weekend. But for the new page reporting, why not
>
> I shared my thoughts about VIRTIO_BALLOON_F_FREE_PAGE_HINT in the other
> thread and think we should simply not care at all for now.
>
> > assume host implementation will be sane?
>
> I don't think we should enforce having poison support around. See my
> reply to this mail for an alternative.
OK so you basically say leave this to host to handle? That's more or
less what I'm saying too.
> --
> 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: Alexander Duyck <alexander.duyck@gmail.com>,
Jason Wang <jasowang@redhat.com>,
virtio-dev@lists.oasis-open.org,
virtualization@lists.linux-foundation.org
Subject: Re: Re: [PATCH] virtio-balloon: Disable free page hinting/reporting if page poison is disabled
Date: Fri, 17 Apr 2020 04:50:00 -0400 [thread overview]
Message-ID: <20200417044641-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <08d2c4e2-8c0f-7d3c-89f1-0e6c6a2756c8@redhat.com>
On Fri, Apr 17, 2020 at 09:49:03AM +0200, David Hildenbrand wrote:
> On 17.04.20 08:28, Michael S. Tsirkin wrote:
> > On Thu, Apr 16, 2020 at 04:52:42PM -0700, Alexander Duyck wrote:
> >> On Thu, Apr 16, 2020 at 3:13 PM Michael S. Tsirkin <mst@redhat.com> wrote:
> >>>
> >>> On Thu, Apr 16, 2020 at 12:30:38PM -0700, Alexander Duyck wrote:
> >>>> From: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> >>>>
> >>>> If we have free page hinting or page reporting enabled we should disable it
> >>>> if the pages are poisoned or initialized on free and we cannot notify the
> >>>> hypervisor.
> >>>>
> >>>> Fixes: 5d757c8d518d ("virtio-balloon: add support for providing free page reports to host")
> >>>>
> >>>> Signed-off-by: Alexander Duyck <alexander.h.duyck@linux.intel.com>
> >>>
> >>>
> >>> Why not put this logic in the hypervisor?
> >>
> >> I did that too. This is to cover the case where somebody is running
> >> the code prior to my QEMU changes where the page poison feature wasn't
> >> being enabled.
> >
> >
> > Hmm so that one looks like a QEMU bug (does not expose poison flag). In
> > the past we just said need to fix the bug where it's found unless the
> > issue is very widespread and major. Let's assume QEMU learns to always
> > expose POISON with HINT. Then this configuration (HINT && !POISON)
> > allows us to detect old QEMU (pre your changes).
>
> Don't see why this is a QEMU bug. It's just a feature it does not
> implement. Perfectly valid.
I'll need to think about this.
We need to remember that the whole HINT thing is not a mandate for host to
corrupt memory. It's just some info about page use guest
gives host. If host corrupts memory it's broken ...
> [...]
> >>
> >> The problem is we cannot communicate the full situation to the
> >> hypervisor without the page poison feature being present. As such I
> >> would worry about that backfiring on us due to the hypervisor acting
> >> on incomplete data.
> >
> >
> > I'll try to think about VIRTIO_BALLOON_F_FREE_PAGE_HINT situation
> > over the weekend. But for the new page reporting, why not
>
> I shared my thoughts about VIRTIO_BALLOON_F_FREE_PAGE_HINT in the other
> thread and think we should simply not care at all for now.
>
> > assume host implementation will be sane?
>
> I don't think we should enforce having poison support around. See my
> reply to this mail for an alternative.
OK so you basically say leave this to host to handle? That's more or
less what I'm saying too.
> --
> Thanks,
>
> David / dhildenb
next prev parent reply other threads:[~2020-04-17 8:50 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-16 19:30 [virtio-dev] [PATCH] virtio-balloon: Disable free page hinting/reporting if page poison is disabled Alexander Duyck
2020-04-16 19:30 ` Alexander Duyck
2020-04-16 22:13 ` [virtio-dev] " Michael S. Tsirkin
2020-04-16 22:13 ` Michael S. Tsirkin
2020-04-16 23:52 ` [virtio-dev] " Alexander Duyck
2020-04-16 23:52 ` Alexander Duyck
2020-04-17 6:28 ` [virtio-dev] " Michael S. Tsirkin
2020-04-17 6:28 ` Michael S. Tsirkin
2020-04-17 7:49 ` [virtio-dev] " David Hildenbrand
2020-04-17 7:49 ` David Hildenbrand
2020-04-17 8:50 ` Michael S. Tsirkin [this message]
2020-04-17 8:50 ` Michael S. Tsirkin
2020-04-17 9:07 ` [virtio-dev] " David Hildenbrand
2020-04-17 9:07 ` David Hildenbrand
2020-04-17 9:21 ` [virtio-dev] " Michael S. Tsirkin
2020-04-17 9:21 ` Michael S. Tsirkin
2020-04-17 9:51 ` [virtio-dev] " David Hildenbrand
2020-04-17 9:51 ` David Hildenbrand
2020-04-17 9:59 ` [virtio-dev] " Michael S. Tsirkin
2020-04-17 9:59 ` Michael S. Tsirkin
2020-04-17 10:09 ` [virtio-dev] " David Hildenbrand
2020-04-17 10:09 ` David Hildenbrand
2020-04-17 10:19 ` [virtio-dev] " Michael S. Tsirkin
2020-04-17 10:19 ` Michael S. Tsirkin
2020-04-17 10:26 ` David Hildenbrand
2020-04-17 10:26 ` David Hildenbrand
2020-04-17 10:29 ` [virtio-dev] " Michael S. Tsirkin
2020-04-17 10:29 ` Michael S. Tsirkin
2020-04-17 10:31 ` [virtio-dev] " David Hildenbrand
2020-04-17 10:31 ` David Hildenbrand
2020-04-17 11:02 ` [virtio-dev] " Michael S. Tsirkin
2020-04-17 11:02 ` Michael S. Tsirkin
2020-04-17 11:18 ` [virtio-dev] " David Hildenbrand
2020-04-17 11:18 ` David Hildenbrand
2020-04-17 16:22 ` [virtio-dev] " Alexander Duyck
2020-04-17 16:22 ` Alexander Duyck
2020-04-20 13:28 ` [virtio-dev] " David Hildenbrand
2020-04-20 13:28 ` David Hildenbrand
2020-04-20 18:32 ` [virtio-dev] " Alexander Duyck
2020-04-20 18:32 ` Alexander Duyck
2020-04-21 7:29 ` [virtio-dev] " David Hildenbrand
2020-04-21 7:29 ` David Hildenbrand
2020-04-21 15:05 ` [virtio-dev] " Alexander Duyck
2020-04-21 15:05 ` Alexander Duyck
2020-04-21 15:18 ` [virtio-dev] " David Hildenbrand
2020-04-21 15:18 ` David Hildenbrand
2020-04-21 15:50 ` Alexander Duyck
2020-04-21 15:50 ` Alexander Duyck
2020-04-22 10:24 ` [virtio-dev] " David Hildenbrand
2020-04-22 10:24 ` David Hildenbrand
2020-04-22 15:49 ` [virtio-dev] " Alexander Duyck
2020-04-22 15:49 ` Alexander Duyck
2020-04-17 7:46 ` [virtio-dev] " David Hildenbrand
2020-04-17 7:46 ` David Hildenbrand
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=20200417044641-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=alexander.duyck@gmail.com \
--cc=david@redhat.com \
--cc=jasowang@redhat.com \
--cc=virtio-dev@lists.oasis-open.org \
--cc=virtualization@lists.linux-foundation.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.