On Wed, Jun 27, 2012 at 9:06 AM, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > On Wed, Jun 27, 2012 at 08:48:55AM -0700, Frank Swiderski wrote: >> On Tue, Jun 26, 2012 at 7:56 PM, Rusty Russell <rusty@xxxxxxxxxxxxxxx> wrote: >> > On Wed, 27 Jun 2012 00:41:06 +0300, "Michael S. Tsirkin" <mst@xxxxxxxxxx> wrote: >> >> On Tue, Jun 26, 2012 at 01:32:58PM -0700, Frank Swiderski wrote: >> >> > This implementation of a virtio balloon driver uses the page cache to >> >> > "store" pages that have been released to the host. The communication >> >> > (outside of target counts) is one way--the guest notifies the host when >> >> > it adds a page to the page cache, allowing the host to madvise(2) with >> >> > MADV_DONTNEED. Reclaim in the guest is therefore automatic and implicit >> >> > (via the regular page reclaim). This means that inflating the balloon >> >> > is similar to the existing balloon mechanism, but the deflate is >> >> > different--it re-uses existing Linux kernel functionality to >> >> > automatically reclaim. >> >> > >> >> > Signed-off-by: Frank Swiderski <fes@xxxxxxxxxx> >> >> >> >> I'm pondering this: >> >> >> >> Should it really be a separate driver/device ID? >> >> If it behaves the same from host POV, maybe it >> >> should be up to the guest how to inflate/deflate >> >> the balloon internally? >> > >> > Well, it shouldn't steal ID 10, either way :) Either use a completely >> > bogus number, or ask for an id. >> > >> > But AFAICT this should be a an alternate driver of for the same device: >> > it's not really a separate device, is it? >> > >> > Cheers, >> > Rusty. >> >> Apologies, Rusty. Asking for an ID is in the virtio spec, and I >> completely neglected that step. Though as you and others have pointed >> out, this probably fits better as a different driver for the same >> device. Since it changes whether or not the deflate operation is >> necessary, it also seems that how this should look is different >> behavior based on a feature bit in the device. >> >> If that sounds reasonable, then what I'll do with this patch is merge >> it with the existing virtio balloon driver with a feature bit for >> determining which behavior to use. >> >> I also think the idea of a generic balloon that the different balloon >> drivers use for the inflate/deflate operations is interesting and >> useful, though I think the suggestion of pending that until later is >> correct. >> >> Sounds reasonable? >> >> Regards, >> fes > > I think a spec patch would be a good spec at this point. > You can get the spec from Rusty, or a mirror > from my git: > > git://git.kernel.org/pub/scm/virt/kvm/mst/virtio-spec.git > > > Got it, thanks, will do. Regards, fes -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
