search for: page_to_balloon_pfns

This series contains one cleanup and two bug fixes for the virtio balloon driver.

This series contains one cleanup and two bug fixes for the virtio balloon driver.

As reported by David Gibson, current code handles PAGE_SIZE != 4k completely wrong which can lead to guest memory corruption errors. - page_to_balloon_pfn is wrong: e.g. on system with 64K page size it gives the same pfn value for 16 different pages. - we also need to convert back to linux pfns when we free. - for each linux page we need to tell host about multiple balloon pages, but code

As reported by David Gibson, current code handles PAGE_SIZE != 4k completely wrong which can lead to guest memory corruption errors. - page_to_balloon_pfn is wrong: e.g. on system with 64K page size it gives the same pfn value for 16 different pages. - we also need to convert back to linux pfns when we free. - for each linux page we need to tell host about multiple balloon pages, but code

Everything should be LE when using virtio-1, but the linux balloon driver does not seem to care about that. Cc: stable at vger.kernel.org Reported-by: Cornelia Huck <cornelia.huck at de.ibm.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_balloon.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git

Everything should be LE when using virtio-1, but the linux balloon driver does not seem to care about that. Cc: stable at vger.kernel.org Reported-by: Cornelia Huck <cornelia.huck at de.ibm.com> Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/virtio/virtio_balloon.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git

> > > > > This can be pre-initialized, correct? > > > > > > > > pre-initialized? I am not quite understand your mean. > > > > > > I think you can maintain sg as part of device state and init sg with the > bitmap. > > > > > > > I got it. > > > > > > > This is grossly inefficient if you only

> > > > > This can be pre-initialized, correct? > > > > > > > > pre-initialized? I am not quite understand your mean. > > > > > > I think you can maintain sg as part of device state and init sg with the > bitmap. > > > > > > > I got it. > > > > > > > This is grossly inefficient if you only

On Wed, May 18, 2016 at 03:38:53PM +0300, Michael S. Tsirkin wrote: > Everything should be LE when using virtio-1, but > the linux balloon driver does not seem to care about that. > > Cc: stable at vger.kernel.org > Reported-by: Cornelia Huck <cornelia.huck at de.ibm.com> > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> Forgot to CC stable. Please consider

On Fri, Oct 21, 2016 at 02:24:37PM +0800, Liang Li wrote: > The implementation of the current virtio-balloon is not very > efficient, the time spends on different stages of inflating > the balloon to 7GB of a 8GB idle guest: > > a. allocating pages (6.5%) > b. sending PFNs to host (68.3%) > c. address translation (6.1%) > d. madvise (19%) > > It takes about 4126ms

On Fri, Oct 21, 2016 at 02:24:37PM +0800, Liang Li wrote: > The implementation of the current virtio-balloon is not very > efficient, the time spends on different stages of inflating > the balloon to 7GB of a 8GB idle guest: > > a. allocating pages (6.5%) > b. sending PFNs to host (68.3%) > c. address translation (6.1%) > d. madvise (19%) > > It takes about 4126ms

On Fri, Dec 04, 2015 at 02:37:50PM +0100, Petr Mladek wrote: > fill_balloon() and leak_balloon() manipulate only a limited number > of pages in one call. This is the reason why remove_common() calls > leak_balloon() in a while cycle. > > remove_common() is called also when the system is being frozen. > But fill_balloon() is called only once when the system is being >

On Fri, Dec 04, 2015 at 02:37:50PM +0100, Petr Mladek wrote: > fill_balloon() and leak_balloon() manipulate only a limited number > of pages in one call. This is the reason why remove_common() calls > leak_balloon() in a while cycle. > > remove_common() is called also when the system is being frozen. > But fill_balloon() is called only once when the system is being >

> > > > { > > > > - struct scatterlist sg; > > > > unsigned int len; > > > > > > > > - sg_init_one(&sg, vb->pfns, sizeof(vb->pfns[0]) * vb->num_pfns); > > > > + if (virtio_has_feature(vb->vdev, > > > VIRTIO_BALLOON_F_PAGE_BITMAP)) { > > > > + u32 page_shift = PAGE_SHIFT; > > >

> > > > { > > > > - struct scatterlist sg; > > > > unsigned int len; > > > > > > > > - sg_init_one(&sg, vb->pfns, sizeof(vb->pfns[0]) * vb->num_pfns); > > > > + if (virtio_has_feature(vb->vdev, > > > VIRTIO_BALLOON_F_PAGE_BITMAP)) { > > > > + u32 page_shift = PAGE_SHIFT; > > >

The implementation of the current virtio-balloon is not very efficient, the time spends on different stages of inflating the balloon to 7GB of a 8GB idle guest: a. allocating pages (6.5%) b. sending PFNs to host (68.3%) c. address translation (6.1%) d. madvise (19%) It takes about 4126ms for the inflating process to complete. Debugging shows that the bottle neck are the stage b and stage d. If

The implementation of the current virtio-balloon is not very efficient, the time spends on different stages of inflating the balloon to 7GB of a 8GB idle guest: a. allocating pages (6.5%) b. sending PFNs to host (68.3%) c. address translation (6.1%) d. madvise (19%) It takes about 4126ms for the inflating process to complete. Debugging shows that the bottle neck are the stage b and stage d. If

The implementation of the current virtio-balloon is not very efficient, the time spends on different stages of inflating the balloon to 7GB of a 8GB idle guest: a. allocating pages (6.5%) b. sending PFNs to host (68.3%) c. address translation (6.1%) d. madvise (19%) It takes about 4126ms for the inflating process to complete. Debugging shows that the bottle neck are the stage b and stage d. If

On Wed, Jul 27, 2016 at 09:23:33AM +0800, Liang Li wrote: > The implementation of the current virtio-balloon is not very > efficient, the time spends on different stages of inflating > the balloon to 7GB of a 8GB idle guest: > > a. allocating pages (6.5%) > b. sending PFNs to host (68.3%) > c. address translation (6.1%) > d. madvise (19%) > > It takes about 4126ms

On Wed, Jul 27, 2016 at 09:23:33AM +0800, Liang Li wrote: > The implementation of the current virtio-balloon is not very > efficient, the time spends on different stages of inflating > the balloon to 7GB of a 8GB idle guest: > > a. allocating pages (6.5%) > b. sending PFNs to host (68.3%) > c. address translation (6.1%) > d. madvise (19%) > > It takes about 4126ms