qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Adam Litke <agl@us.ibm.com>
Cc: Anthony Liguori <aliguori@us.ibm.com>, qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: virtio: Report new guest memory statistics pertinent to memory ballooning (V4)
Date: Thu, 19 Nov 2009 18:02:31 +0200	[thread overview]
Message-ID: <4B056C17.1020003@redhat.com> (raw)
In-Reply-To: <1258646191.3464.16.camel@aglitke>

On 11/19/2009 05:56 PM, Adam Litke wrote:
> On Thu, 2009-11-19 at 17:19 +0200, Avi Kivity wrote:
>    
>> On 11/19/2009 05:06 PM, Adam Litke wrote:
>>      
>>> Avi and Anthony,
>>> If you agree that I've addressed all outstanding issues, please consider this
>>> patch for inclusion.  Thanks.
>>>
>>>
>>>        
>> I'd like to see this (and all other virtio-ABI-modifying patches) first
>> go into the virtio pci spec, then propagated to guest and host.
>>      
> Where can I find information on the procedure for updating the virtio
> pci spec?
>
>    

Send a patch to Rusty (same copy list).

http://ozlabs.org/~rusty/virtio-spec/

>>> Changes since V3:
>>>    - Increase stat field size to 64 bits
>>>    - Report all sizes in kb (not pages)
>>>
>>>        
>> Why not bytes?  It's the most natural unit.
>>      
> The precision for most of these stats (except major and minor faults)
> is 4kb (at least for Linux guests on the platforms I can think of).  I
> chose kb units to avoid wasting bits.  I suppose the 64bit fields are
> "Bigger than we could ever possibly need (tm)".  Others have suggested
> bytes as well so I will be happy to make the change.
>    

It's my engineering backgrounds.  I'd actually prefer them in a kg/m/s 
combo but it doesn't really work out.

>>> -static ram_addr_t virtio_balloon_to_target(void *opaque, ram_addr_t target)
>>> +static void request_stats(VirtIOBalloon *vb)
>>> +{
>>> +    vb->stats_requested = 1;
>>> +    reset_stats(vb);
>>> +    monitor_suspend(cur_mon);
>>>
>>>        
>> You allow the guest to kill a monitor here.
>>      
> Is there a better way to handle asynchronous communication with the
> guest?
>    

With the current monitor, the only option I can think of it a command to 
request stats and a command to report stats (with a version number so we 
can see if it actually worked).

The new monitor will support async command completion but even then I 
don't think we should allow a guest to stop command execution 
indefinitely (it would tie up resources at the client).

>>> +typedef struct VirtIOBalloonStat {
>>> +    uint16_t tag;
>>> +    uint64_t val;
>>> +} VirtIOBalloonStat;
>>>
>>>        
>> Alignment here depends on word size.  This needs to be padded to be
>> aligned the same way on 32 and 64 bit hosts and guests.
>>      
> ok.  I assume that means the structure size must be a multiple of 64
> bits in size

Yes, and all values must be naturally aligned.

-- 
error compiling committee.c: too many arguments to function

  reply	other threads:[~2009-11-19 16:02 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-19 15:06 [Qemu-devel] virtio: Report new guest memory statistics pertinent to memory ballooning (V4) Adam Litke
2009-11-19 15:19 ` [Qemu-devel] virtio: Add memory statistics reporting to the balloon driver (V3) Adam Litke
2009-11-19 15:22   ` [Qemu-devel] " Avi Kivity
2009-11-19 15:58     ` Adam Litke
2009-11-19 16:13       ` Avi Kivity
2009-11-19 16:29         ` Adam Litke
2009-11-19 23:53   ` Rusty Russell
2009-11-23  9:44   ` Michael S. Tsirkin
2009-11-23 11:00     ` Dor Laor
2009-11-23 11:31       ` Vadim Rozenfeld
2009-11-19 15:19 ` [Qemu-devel] Re: virtio: Report new guest memory statistics pertinent to memory ballooning (V4) Avi Kivity
2009-11-19 15:56   ` Adam Litke
2009-11-19 16:02     ` Avi Kivity [this message]
2009-11-23 18:47       ` Anthony Liguori
2009-11-20  1:24     ` Jamie Lokier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B056C17.1020003@redhat.com \
    --to=avi@redhat.com \
    --cc=agl@us.ibm.com \
    --cc=aliguori@us.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).