Document:
02813: Resolve VIRTIO-143: balloon: allow transitional devices

Draft (A preliminary unapproved sketch, outline, or version.)

Details

Submitted By Mr. Michael S. Tsirkin on 2015-05-18 5:02 am UTC

Publication Type

None at this time.

Group / Folder

OASIS Virtual I/O Device (VIRTIO) TC / System Ballot Results

Modified by

Not modified.

Copy

This document is not a copy.

Technical Contact

None at this time.

Download Count

390

Download Agreement

None at this time.

Description

Please vote Yes if you agree with all of the following. If you disagree, please vote No. If you don't have an opinion, please vote Abstain. I move that: The TC agrees to resolve the following specification issue: VIRTIO-143: balloon: allow transitional devices -------------------------------------- Virtio 1.0 cs02 doesn't include a modern balloon device. At some point we'll likely define an incompatible interface with a different ID and different semantics. But for now, it's not a big effort to support a transitional balloon device: this has the advantage of supporting existing drivers, transparently, as well as transports that don't allow mixing virtio 0 and virtio 1 devices. And balloon is an easy device to test, so it's also useful for people to test virtio core handling of transitional devices. -------------------------------------- The TC accepts the following proposed changes to the specification: -------------------------------------- mid.gmane.org/1430235439-3812-1-git-send-email-mst@redhat.com [PATCH v3] balloon: transitional device support Support a transitional balloon device: this has the advantage of supporting existing drivers, transparently, as well as transports that don't allow mixing virtio 0 and virtio 1 devices. And balloon is an easy device to test, so it's also useful for people to test virtio core handling of transitional devices. Three issues with legacy hypervisors have been identified: 1. Actual value is actually used, and is necessary for management to work. Luckily 4 byte config space writes are now atomic. When using old guests, hypervisors can detect access to the last byte. When using old hypervisors, drivers can use atomic 4-byte accesses. 2. Hypervisors actually didn't ignore the stats from the first buffer supplied. This means the values there would be incorrect until hypervisor resends the request. Add a note suggesting hypervisors ignore the 1st buffer. 3. QEMU simply over-writes stats from each buffer it gets. Thus if driver supplies a different subset of stats on each request, stale values will be there. Require drivers to supply the same subset on each request. This also gives us a simple way to figure out which stats are supported. Additionally, this fixes a typo: - the driver SHOULD omit unsupported statistics. should be: + devices omit unsupported statistics. Note that we have a normative statement with this requirement already, this is just general high-level description. -------------------------------------- The TC agrees to include the above change(s) in specification version(s) "virtio 1.0 cs03", and future versions of the specification. -------------------------------------- Reminder: A Voting Member must be active in a TC to maintain voting rights. As the Virtio TC has adopted a standing rule to conduct business only by electronic ballot, without Meetings, a Voting Member who fails to cast a ballot in two consecutive Work Product Ballots loses his or her voting rights at the close of the second ballot missed. --------------------------------------