lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 11 Nov 2009 10:12:23 +0000
From:	"Daniel P. Berrange" <>
To:	Jamie Lokier <>
Cc:	Anthony Liguori <>,,, Rusty Russell <>,,,
	Avi Kivity <>
Subject: Re: [Qemu-devel] Re: virtio: Add memory statistics reporting to the balloon driver

On Wed, Nov 11, 2009 at 09:24:09AM +0000, Jamie Lokier wrote:
> Anthony Liguori wrote:
> > Avi Kivity wrote:
> > >On 11/10/2009 04:36 PM, Anthony Liguori wrote:
> > >>
> > >>>A stats vq might solve this more cleanly?
> > >>
> > >>actual and target are both really just stats.  Had we implemented 
> > >>those with a vq, I'd be inclined to agree with you but since they're 
> > >>implemented in the config space, it seems natural to extend the 
> > >>config space with other stats.
> > >>
> > >
> > >There is in fact a difference; actual and target are very rarely 
> > >updated, while the stats are updated very often.  Using a vq means a 
> > >constant number of exits per batch instead of one exit per statistic.  
> > >If the vq is host-driven, it also allows the host to control the 
> > >update frequency dynamically (i.e. stop polling when there is no 
> > >memory pressure).
> > 
> > I'm not terribly opposed to using a vq for this.  I would expect the 
> > stat update interval to be rather long (10s probably) but a vq works 
> > just as well.
> If there's no memory pressure and no guest activity, you probably want
> the stat update to be as rare as possible to avoid wakeups.  Save
> power on laptops, that sort of thing.
> If there's a host user interested in the state ("qemutop?"), you may
> want updates more often than 10s.

This all suggests that we should only update the stats from the guest
when something on the host actually asks for them by issuing the QEMU
monitor command. We don't want any kind of continuous polling of stats
at any frequency, if nothing is using these stats on the host.

|: Red Hat, Engineering, London   -o- :|
|:  -o-  -o- :|
|:       -o- :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists