OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [virtio] [OASIS Issue Tracker] Created: (VIRTIO-28) Implement new balloon device (ID 13)

On (Wed) 25 Sep 2013 [16:32:51], Rusty Russell wrote:
> Amit Shah <amit.shah@redhat.com> writes:
> > On (Wed) 11 Sep 2013 [04:51:39], OASIS Issues Tracker wrote:
> >> Implement new balloon device (ID 13)
> >> ------------------------------------
> >> 
> >>                  Key: VIRTIO-28
> >>                  URL: http://tools.oasis-open.org/issues/browse/VIRTIO-28
> >>              Project: OASIS Virtual I/O Device (VIRTIO) TC
> >>           Issue Type: New Feature
> >>             Reporter: Rusty Russell
> >> 
> >> 
> >> The current virtio balloon device is bad enough that fixing it yields something completely incompatible:
> >> 1) The page size is 4096, always, rather than some configurable page size.
> >> 2) Page numbers are 32 bits.
> >> 3) The deflate queue is not actually used by any device implementation (see issue virtio-25).
> >> 4) The "actual" number is kind of useless, and (along with the deflate queue) requires the guest to track pages, rather than just faulting them in.
> >> 5) The config is little-endian by mistake (may not matter).
> >
> > The current design is weird: the host tells the guest the offset by
> > which to inflate or deflate the balloon.  Instead, the host should let
> > the guest know how much in absolute terms the memory should be
> > adjusted to, and the guest will take the decision on whether to
> > inflate, or deflate, or not take any action at all.
> I see your point.  I wonder how east it is define how much memory the
> guest has (from a guest perspective).  Things like memory holes, device
> memory maps and I'm sure there is other platform-specific weirdness I'm
> sure I don't understand.

Right now the driver directly grabs pages from the RAM area.  It's a
crude approach, but one that we use and works right now.  We can
continue doing the same...

However, I see your point, too.  So far, these questions you raise
don't get asked by the host either, and the guests just comply with
whatever the hosts have asked for (even if it means processes within
the guest start to OOM).


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]