Re: [Qemu-devel] [RFC] virtio-mem: paravirtualized memory

On 31.07.2017 16:12, Michael S. Tsirkin wrote: > On Fri, Jul 28, 2017 at 05:48:07PM +0200, David Hildenbrand wrote: >> In general, a paravirtualized interface (for detection of PMEM regions) >> might have one big advantage: not limited to certain architectures. > > What follows is a generic rant,

Re: [Qemu-devel] [RFC] virtio-mem: paravirtualized memory

On Fri, Jul 28, 2017 at 05:48:07PM +0200, David Hildenbrand wrote: > In general, a paravirtualized interface (for detection of PMEM regions) > might have one big advantage: not limited to certain architectures. What follows is a generic rant, and slightly offtopic -sorry about that. I thought

Re: [Qemu-devel] [RFC] virtio-mem: paravirtualized memory

On 28.07.2017 17:16, Dan Williams wrote: > On Fri, Jul 28, 2017 at 4:09 AM, David Hildenbrand wrote: >> Btw, I am thinking about the following addition to the concept: >> >> 1. Add a type to each virtio-mem device. >> >> This describes the type of the memory region we expose to

Re: [Qemu-devel] [RFC] virtio-mem: paravirtualized memory

On Fri, Jul 28, 2017 at 4:09 AM, David Hildenbrand wrote: > Btw, I am thinking about the following addition to the concept: > > 1. Add a type to each virtio-mem device. > > This describes the type of the memory region we expose to the guest. > Initially, we could have RAM and

Re: [Qemu-devel] [RFC] virtio-mem: paravirtualized memory

Btw, I am thinking about the following addition to the concept: 1. Add a type to each virtio-mem device. This describes the type of the memory region we expose to the guest. Initially, we could have RAM and RAM_HUGE. The latter one would be interesting, because the guest would know that this

Re: [Qemu-devel] [RFC] virtio-mem: paravirtualized memory

(ping) Hi, this has been on these lists for quite some time now. I want to start preparing a virtio spec for virtio-mem soon. So if you have any more comments/ideas/objections/questions, now is the right time to post them :) Thanks! On 16.06.2017 16:20, David Hildenbrand wrote: > Hi, > >

Re: [Qemu-devel] [RFC] virtio-mem: paravirtualized memory

On Wed, Jun 21, 2017 at 02:32:48PM +0200, David Hildenbrand wrote: > On 21.06.2017 13:08, Stefan Hajnoczi wrote: > > On Mon, Jun 19, 2017 at 12:26:52PM +0200, David Hildenbrand wrote: > >> On 19.06.2017 12:08, Stefan Hajnoczi wrote: > >>> On Fri, Jun 16, 2017 at 04:20:02PM +0200, David Hildenbrand

Re: [Qemu-devel] [RFC] virtio-mem: paravirtualized memory

On 21.06.2017 13:08, Stefan Hajnoczi wrote: > On Mon, Jun 19, 2017 at 12:26:52PM +0200, David Hildenbrand wrote: >> On 19.06.2017 12:08, Stefan Hajnoczi wrote: >>> On Fri, Jun 16, 2017 at 04:20:02PM +0200, David Hildenbrand wrote: Important restrictions of this concept: - Guests without

Re: [Qemu-devel] [RFC] virtio-mem: paravirtualized memory

On Mon, Jun 19, 2017 at 12:26:52PM +0200, David Hildenbrand wrote: > On 19.06.2017 12:08, Stefan Hajnoczi wrote: > > On Fri, Jun 16, 2017 at 04:20:02PM +0200, David Hildenbrand wrote: > >> Important restrictions of this concept: > >> - Guests without a virtio-mem guest driver can't see that

Re: [Qemu-devel] [RFC] virtio-mem: paravirtualized memory

On 19.06.2017 12:08, Stefan Hajnoczi wrote: > On Fri, Jun 16, 2017 at 04:20:02PM +0200, David Hildenbrand wrote: >> Important restrictions of this concept: >> - Guests without a virtio-mem guest driver can't see that memory. >> - We will always require some boot memory that cannot get unplugged.

Re: [Qemu-devel] [RFC] virtio-mem: paravirtualized memory

On Fri, Jun 16, 2017 at 04:20:02PM +0200, David Hildenbrand wrote: > Important restrictions of this concept: > - Guests without a virtio-mem guest driver can't see that memory. > - We will always require some boot memory that cannot get unplugged. > Also, virtio-mem memory (as all other

Re: [Qemu-devel] [RFC] virtio-mem: paravirtualized memory

>> A Linux guest will deflate the balloon (all or some pages) in the >> following scenarios: >> a) page migration > > It inflates it first, doesn't it? Yes, that that is true. I was just listing all scenarios. > >> b) unload virtio-balloon kernel module >> c) hibernate/suspension >> d)

Re: [Qemu-devel] [RFC] virtio-mem: paravirtualized memory

On Fri, Jun 16, 2017 at 05:59:07PM +0200, David Hildenbrand wrote: > On 16.06.2017 17:04, Michael S. Tsirkin wrote: > > 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

Re: [Qemu-devel] [RFC] virtio-mem: paravirtualized memory

On 16.06.2017 17:04, Michael S. Tsirkin wrote: > 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

Re: [Qemu-devel] [RFC] virtio-mem: paravirtualized memory

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

[Qemu-devel] [RFC] virtio-mem: paravirtualized memory

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