On Thu, Mar 06, 2008 at 09:39:48AM +1100, Rusty Russell wrote:
> On Thursday 06 March 2008 03:28:32 Marcelo Tosatti wrote:
> > Handle the case where the balloon target is larger than total ram size.
> >
> > BUG: unable to handle kernel paging request at 0000000000100100
> > IP: [<ffffffff881970f9>] :virtio_balloon:leak__balloon+0x2e/0xbe
> >
> > Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
>
> Hi Marcelo,
>
> My deepest concern is that we're papering over some real bug, if you
> tripped this. Zeroing num_pages makes sense as a hack, but we're clearly in
> trouble at this point and there should be some indication of that.
>
> If I may ask, how did this happen?
Rusty,
QEMU allows the user to set a target larger than the memory size which
the guest was booted with:
dev->num_pages = (ram_size - target) >> TARGET_PAGE_BITS;
virtio_notify_config(&dev->vdev);
num_pages goes negative, so driver attempts deflate back -num_pages from
its balloon.
There is no other bug here, its just a matter of guest driver being
fragile. You can avoid that condition in the host backend:
--- virtio-balloon.c.orig 2008-03-08 14:39:51.000000000 -0300
+++ virtio-balloon.c 2008-03-08 14:41:08.000000000 -0300
@@ -113,6 +113,8 @@
VirtIOBalloon *dev = opaque;
if (target) {
+ if (target > ram_size)
+ target = ram_size;
dev->num_pages = (ram_size - target) >> TARGET_PAGE_BITS;
virtio_notify_config(&dev->vdev);
}
But making the driver robust against it seems sensate. I agree that
zeroing num_pages is hackish. What do you suggest?
Thanks
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
