All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: KVM <kvm@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: [RFC] virtio-mem: paravirtualized memory
Date: Fri, 16 Jun 2017 18:04:06 +0300	[thread overview]
Message-ID: <20170616175748-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <547865a9-d6c2-7140-47e2-5af01e7d761d@redhat.com>

On Fri, Jun 16, 2017 at 04:20:02PM +0200, David Hildenbrand wrote:
> Hi,
> 
> this is an idea that is based on Andrea Arcangeli's original idea to
> host enforce guest access to memory given up using virtio-balloon using
> userfaultfd in the hypervisor. While looking into the details, I
> realized that host-enforcing virtio-balloon would result in way too many
> problems (mainly backwards compatibility) and would also have some
> conceptual restrictions that I want to avoid. So I developed the idea of
> virtio-mem - "paravirtualized memory".

Thanks! I went over this quickly, will read some more in the
coming days. I would like to ask for some clarifications
on one part meanwhile:

> Q: Why not reuse virtio-balloon?
> 
> A: virtio-balloon is for cooperative memory management. It has a fixed
>    page size

We are fixing that with VIRTIO_BALLOON_F_PAGE_CHUNKS btw.
I would appreciate you looking into that patchset.

> and will deflate in certain situations.

What does this refer to?

> Any change we
>    introduce will break backwards compatibility.

Why does this have to be the case?

> virtio-balloon was not
>    designed to give guarantees. Nobody can hinder the guest from
>    deflating/reusing inflated memory.

Reusing without deflate is forbidden with TELL_HOST, right?

>    In addition, it might make perfect
>    sense to have both, virtio-balloon and virtio-mem at the same time,
>    especially looking at the DEFLATE_ON_OOM or STATS features of
>    virtio-balloon. While virtio-mem is all about guarantees, virtio-
>    balloon is about cooperation.

Thanks, and I intend to look more into this next week.

-- 
MST

WARNING: multiple messages have this Message-ID (diff)
From: "Michael S. Tsirkin" <mst@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: KVM <kvm@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: [RFC] virtio-mem: paravirtualized memory
Date: Fri, 16 Jun 2017 18:04:06 +0300	[thread overview]
Message-ID: <20170616175748-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <547865a9-d6c2-7140-47e2-5af01e7d761d@redhat.com>

On Fri, Jun 16, 2017 at 04:20:02PM +0200, David Hildenbrand wrote:
> Hi,
> 
> this is an idea that is based on Andrea Arcangeli's original idea to
> host enforce guest access to memory given up using virtio-balloon using
> userfaultfd in the hypervisor. While looking into the details, I
> realized that host-enforcing virtio-balloon would result in way too many
> problems (mainly backwards compatibility) and would also have some
> conceptual restrictions that I want to avoid. So I developed the idea of
> virtio-mem - "paravirtualized memory".

Thanks! I went over this quickly, will read some more in the
coming days. I would like to ask for some clarifications
on one part meanwhile:

> Q: Why not reuse virtio-balloon?
> 
> A: virtio-balloon is for cooperative memory management. It has a fixed
>    page size

We are fixing that with VIRTIO_BALLOON_F_PAGE_CHUNKS btw.
I would appreciate you looking into that patchset.

> and will deflate in certain situations.

What does this refer to?

> Any change we
>    introduce will break backwards compatibility.

Why does this have to be the case?

> virtio-balloon was not
>    designed to give guarantees. Nobody can hinder the guest from
>    deflating/reusing inflated memory.

Reusing without deflate is forbidden with TELL_HOST, right?

>    In addition, it might make perfect
>    sense to have both, virtio-balloon and virtio-mem at the same time,
>    especially looking at the DEFLATE_ON_OOM or STATS features of
>    virtio-balloon. While virtio-mem is all about guarantees, virtio-
>    balloon is about cooperation.

Thanks, and I intend to look more into this next week.

-- 
MST

--
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: "Michael S. Tsirkin" <mst@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: KVM <kvm@vger.kernel.org>,
	"virtualization@lists.linux-foundation.org"
	<virtualization@lists.linux-foundation.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Andrea Arcangeli <aarcange@redhat.com>
Subject: Re: [Qemu-devel] [RFC] virtio-mem: paravirtualized memory
Date: Fri, 16 Jun 2017 18:04:06 +0300	[thread overview]
Message-ID: <20170616175748-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <547865a9-d6c2-7140-47e2-5af01e7d761d@redhat.com>

On Fri, Jun 16, 2017 at 04:20:02PM +0200, David Hildenbrand wrote:
> Hi,
> 
> this is an idea that is based on Andrea Arcangeli's original idea to
> host enforce guest access to memory given up using virtio-balloon using
> userfaultfd in the hypervisor. While looking into the details, I
> realized that host-enforcing virtio-balloon would result in way too many
> problems (mainly backwards compatibility) and would also have some
> conceptual restrictions that I want to avoid. So I developed the idea of
> virtio-mem - "paravirtualized memory".

Thanks! I went over this quickly, will read some more in the
coming days. I would like to ask for some clarifications
on one part meanwhile:

> Q: Why not reuse virtio-balloon?
> 
> A: virtio-balloon is for cooperative memory management. It has a fixed
>    page size

We are fixing that with VIRTIO_BALLOON_F_PAGE_CHUNKS btw.
I would appreciate you looking into that patchset.

> and will deflate in certain situations.

What does this refer to?

> Any change we
>    introduce will break backwards compatibility.

Why does this have to be the case?

> virtio-balloon was not
>    designed to give guarantees. Nobody can hinder the guest from
>    deflating/reusing inflated memory.

Reusing without deflate is forbidden with TELL_HOST, right?

>    In addition, it might make perfect
>    sense to have both, virtio-balloon and virtio-mem at the same time,
>    especially looking at the DEFLATE_ON_OOM or STATS features of
>    virtio-balloon. While virtio-mem is all about guarantees, virtio-
>    balloon is about cooperation.

Thanks, and I intend to look more into this next week.

-- 
MST

  reply	other threads:[~2017-06-16 15:04 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-16 14:20 [RFC] virtio-mem: paravirtualized memory David Hildenbrand
2017-06-16 14:20 ` [Qemu-devel] " David Hildenbrand
2017-06-16 14:20 ` David Hildenbrand
2017-06-16 15:04 ` Michael S. Tsirkin [this message]
2017-06-16 15:04   ` [Qemu-devel] " Michael S. Tsirkin
2017-06-16 15:04   ` Michael S. Tsirkin
2017-06-16 15:59   ` David Hildenbrand
2017-06-16 15:59     ` [Qemu-devel] " David Hildenbrand
2017-06-16 20:19     ` Michael S. Tsirkin
2017-06-16 20:19     ` Michael S. Tsirkin
2017-06-16 20:19       ` [Qemu-devel] " Michael S. Tsirkin
2017-06-16 20:19       ` Michael S. Tsirkin
2017-06-18 10:17       ` David Hildenbrand
2017-06-18 10:17       ` David Hildenbrand
2017-06-18 10:17         ` [Qemu-devel] " David Hildenbrand
2017-06-16 15:59   ` David Hildenbrand
2017-06-16 15:04 ` Michael S. Tsirkin
2017-06-19 10:08 ` Stefan Hajnoczi
2017-06-19 10:08 ` Stefan Hajnoczi
2017-06-19 10:08   ` [Qemu-devel] " Stefan Hajnoczi
2017-06-19 10:26   ` David Hildenbrand
2017-06-19 10:26   ` David Hildenbrand
2017-06-19 10:26     ` [Qemu-devel] " David Hildenbrand
2017-06-19 10:26     ` David Hildenbrand
2017-06-21 11:08     ` Stefan Hajnoczi
2017-06-21 11:08     ` Stefan Hajnoczi
2017-06-21 11:08       ` [Qemu-devel] " Stefan Hajnoczi
2017-06-21 12:32       ` David Hildenbrand
2017-06-21 12:32         ` [Qemu-devel] " David Hildenbrand
2017-06-23 12:45         ` Stefan Hajnoczi
2017-06-23 12:45         ` Stefan Hajnoczi
2017-06-23 12:45           ` [Qemu-devel] " Stefan Hajnoczi
2017-06-21 12:32       ` David Hildenbrand
2017-07-25  8:21 ` David Hildenbrand
2017-07-25  8:21   ` [Qemu-devel] " David Hildenbrand
2017-07-25  8:21   ` David Hildenbrand
2017-07-25  8:21 ` David Hildenbrand
2017-07-28 11:09 ` David Hildenbrand
2017-07-28 11:09 ` David Hildenbrand
2017-07-28 11:09   ` [Qemu-devel] " David Hildenbrand
2017-07-28 11:09   ` David Hildenbrand
2017-07-28 15:16   ` Dan Williams
2017-07-28 15:16     ` [Qemu-devel] " Dan Williams
2017-07-28 15:48     ` David Hildenbrand
2017-07-28 15:48     ` David Hildenbrand
2017-07-28 15:48       ` [Qemu-devel] " David Hildenbrand
2017-07-31 14:12       ` Michael S. Tsirkin
2017-07-31 14:12         ` [Qemu-devel] " Michael S. Tsirkin
2017-07-31 14:12         ` Michael S. Tsirkin
2017-07-31 15:04         ` David Hildenbrand
2017-07-31 15:04         ` David Hildenbrand
2017-07-31 15:04           ` [Qemu-devel] " David Hildenbrand
2017-07-28 15:16   ` Dan Williams

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=20170616175748-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=david@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=qemu-devel@nongnu.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.