qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] virtio: Report new guest memory statistics pertin


From: Jamie Lokier
Subject: Re: [Qemu-devel] [RFC] virtio: Report new guest memory statistics pertinent to memory ballooning (V2)
Date: Tue, 10 Nov 2009 13:23:36 +0000
User-agent: Mutt/1.5.13 (2006-08-11)

Anthony Liguori wrote:
> Jamie Lokier wrote:
> >Adam Litke wrote:
> >  
> >>+        s->stats.pswapin = has_feature(dev, 
> >>VIRTIO_BALLOON_F_RPT_SWAP_OUT) ?
> >>+                                       dev->stats.pswapin : -1;
> >>    
> >
> >(etc.)
> >
> >Why not simply have the guest fill in the unused fields with -1, and
> >say that's how "no meaningful value" is represented in the ABI?
> >
> >All guests have to know about all those fields anyway, for the
> >structure layout.  Is there any benefit to specifying feature bits in
> >advance over simply storing -1 there?
> >  
> 
> Features are negotiated.  It lets a host advertise the support of a 
> feature and it lets the guest acknowledge it's support of a feature.
> 
> Most importantly, why invent a new mechanism when we already have one?

In this case, the guest already has to have those fields in the
structure.  It's not like something where the guest doesn't know about
a feature at all, and then a later driver adds new capabilities.  That
would require feature bits or an ABI version, I agree.

But the real motivation for my comment was seeing the bulk of the
patch being definitions and tests for lots of feature bits which do
something trivial that the guest can easily do.

The feature bits don't seem to simplify anything in this case.  As for
preparing to be consistent with future additions, presumably if
another 20 fields are added, there won't be sufficient bits in the
feature word anyway, so an "extended feature bits" feature will be
needed.

-- Jamie




reply via email to

[Prev in Thread] Current Thread [Next in Thread]