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