eventfd: EFD_STATE flag

This implements a new EFD_STATE flag for eventfd.
When set, this flag changes eventfd behaviour in the following way:
- write simply stores the value written, and is always non-blocking
- read unblocks when the value written changes, and returns the value written

Motivation: we'd like to use eventfd in qemu to pass interrupts from (emulated or assigned) devices to guest. For level interrupts, the counter supported currently by eventfd is not a good match: we really need to set interrupt to a level, typically 0 or 1, and give the guest ability to see the last value written.

fs/eventfd.c +0 -0

@@ -31,37 +31,59 @@ struct eventfd_ctx {
  	 * issue a wakeup.
  	 */

Quoted 13 lines · Michael S. Tsirkin

This implements a new EFD_STATE flag for eventfd.
When set, this flag changes eventfd behaviour in the following way:
- write simply stores the value written, and is always non-blocking
- read unblocks when the value written changes, and returns the value written

Motivation: we'd like to use eventfd in qemu to pass interrupts from (emulated or assigned) devices to guest. For level interrupts, the counter supported currently by eventfd is not a good match: we really need to set interrupt to a level, typically 0 or 1, and give the guest ability to see the last value written.

fs/eventfd.c struct eventfd_ctx { · line 42

Quoted 13 lines

fs/eventfd.c +6 -0

@@ -31,37 +31,59 @@ struct eventfd_ctx {
  	 * issue a wakeup.
  	 */
  	__u64 count;
+	/*
+	 * When EF_STATE flag is set, eventfd behaves differently:
+	 * value written gets stored in "count", read will copy
+	 * "count" to "state".
+	 */
+	__u64 state;
  	unsigned int flags;
  };
 

Why not write the new value into ->count directly?

Signature · 1 line

error compiling committee.c: too many arguments to function

Quoted 15 lines · Avi Kivity

Quoted 13 lines · Michael S. Tsirkin

This implements a new EFD_STATE flag for eventfd.
When set, this flag changes eventfd behaviour in the following way:
- write simply stores the value written, and is always non-blocking
- read unblocks when the value written changes, and returns the value written

Motivation: we'd like to use eventfd in qemu to pass interrupts from (emulated or assigned) devices to guest. For level interrupts, the counter supported currently by eventfd is not a good match: we really need to set interrupt to a level, typically 0 or 1, and give the guest ability to see the last value written.

Quoted 16 lines

Quoted 4 lines

fs/eventfd.c +0 -0

@@ -31,37 +31,59 @@ struct eventfd_ctx {
   	 * issue a wakeup.
   	 */
   	__u64 count;

fs/eventfd.c struct eventfd_ctx { · line 43

Quoted 10 lines

fs/eventfd.c +6 -0

+	/*
+	 * When EF_STATE flag is set, eventfd behaves differently:
+	 * value written gets stored in "count", read will copy
+	 * "count" to "state".
+	 */
+	__u64 state;
   	unsigned int flags;
   };
 
 

Why not write the new value into ->count directly?

That's what it says. state is ther to detect that value was changed after last read. Makes sense?

Quoted 34 lines · Michael S. Tsirkin

Quoted 15 lines · Avi Kivity

Quoted 13 lines · Michael S. Tsirkin

This implements a new EFD_STATE flag for eventfd.
When set, this flag changes eventfd behaviour in the following way:
- write simply stores the value written, and is always non-blocking
- read unblocks when the value written changes, and returns the value written

Motivation: we'd like to use eventfd in qemu to pass interrupts from (emulated or assigned) devices to guest. For level interrupts, the counter supported currently by eventfd is not a good match: we really need to set interrupt to a level, typically 0 or 1, and give the guest ability to see the last value written.

Quoted 16 lines

Quoted 4 lines

fs/eventfd.c +0 -0

@@ -31,37 +31,59 @@ struct eventfd_ctx {
   	 * issue a wakeup.
   	 */
   	__u64 count;

fs/eventfd.c struct eventfd_ctx { · line 43

Quoted 10 lines

fs/eventfd.c +6 -0

+	/*
+	 * When EF_STATE flag is set, eventfd behaves differently:
+	 * value written gets stored in "count", read will copy
+	 * "count" to "state".
+	 */
+	__u64 state;
   	unsigned int flags;
   };
 
 

Why not write the new value into ->count directly?

Quoted 3 lines

That's what it says. state is ther to detect that value was changed after last read. Makes sense?

Why not do it at the point of the write?

    if (value != ctx->count) {
        ctx->count = value;
        wake_things_up();
    }

Signature · 1 line

error compiling committee.c: too many arguments to function

Quoted 7 lines

Why not do it at the point of the write?

     if (value != ctx->count) {
         ctx->count = value;
         wake_things_up();
     }

What if write comes before read?

Quoted 8 lines · Michael S. Tsirkin

Quoted 7 lines

Why not do it at the point of the write?

     if (value != ctx->count) {
         ctx->count = value;
         wake_things_up();
     }

Quoted 2 lines

What if write comes before read?

The read will get the new value.

Signature · 1 line

error compiling committee.c: too many arguments to function

Quoted 10 lines · Avi Kivity

Quoted 8 lines · Michael S. Tsirkin

Quoted 8 lines

Why not do it at the point of the write?

      if (value != ctx->count) {
          ctx->count = value;
          wake_things_up();
      }

Quoted 5 lines

Quoted 3 lines

What if write comes before read?

The read will get the new value.

Yes :) But how does read know it should not block?

Quoted 18 lines · Michael S. Tsirkin

Quoted 15 lines · Avi Kivity

Quoted 11 lines · Michael S. Tsirkin

Quoted 8 lines

Why not do it at the point of the write?

      if (value != ctx->count) {
          ctx->count = value;
          wake_things_up();
      }

What if write comes before read?

The read will get the new value.

Quoted 2 lines

Yes :) But how does read know it should not block?

If a different read comes after the write but after our read, it will have transferred the value, resulting in the same situation.

I think reads should never block with a state based mechanism.

Quoted 6 lines

If a different read comes after the write but after our read, it will have transferred the value, resulting in the same situation.

I think reads should never block with a state based mechanism.

Reader may want to poll for the status change.

Quoted 3 lines · Gleb Natapov

Quoted 3 lines

If a different read comes after the write but after our read, it will have transferred the value, resulting in the same situation.

Quoted 5 lines

Quoted 3 lines

I think reads should never block with a state based mechanism.

Reader may want to poll for the status change.

Without epoll(), it's inherently racy since reads from other processes can clear the status.

The "last read value" needs to be maintained for each reader, which is not possible with read().

Quoted 12 lines · Avi Kivity

Quoted 10 lines · Gleb Natapov

Quoted 7 lines

If a different read comes after the write but after our read, it will have transferred the value, resulting in the same situation.

I think reads should never block with a state based mechanism.

Reader may want to poll for the status change.

Quoted 4 lines

Without epoll(), it's inherently racy since reads from other processes can clear the status.

This is correct for any file descriptor. Multiple readers shouldn't simultaneously read from the same files descriptor if they expect to make any sense from a result.

Quoted 18 lines · Gleb Natapov

Quoted 16 lines · Avi Kivity

Quoted 10 lines · Gleb Natapov

Quoted 7 lines

If a different read comes after the write but after our read, it will have transferred the value, resulting in the same situation.

I think reads should never block with a state based mechanism.

Reader may want to poll for the status change.

Without epoll(), it's inherently racy since reads from other processes can clear the status.

Quoted 4 lines

This is correct for any file descriptor. Multiple readers shouldn't simultaneously read from the same files descriptor if they expect to make any sense from a result.

I think counting eventfd is an exception, but in general you are right.

Signature · 1 line

error compiling committee.c: too many arguments to function

Quoted 15 lines · Michael S. Tsirkin

Quoted 13 lines · Avi Kivity

Quoted 11 lines · Michael S. Tsirkin

Quoted 8 lines

Why not do it at the point of the write?

      if (value != ctx->count) {
          ctx->count = value;
          wake_things_up();
      }

What if write comes before read?

Quoted 5 lines

Quoted 2 lines

The read will get the new value.

Yes :) But how does read know it should not block?

If a different read comes after the write but after our read, it will have transferred the value, resulting in the same situation.

I think reads should never block with a state based mechanism.

Signature · 1 line

error compiling committee.c: too many arguments to function

How is it an exception? It seems that one reader get the counter, others will block until the next write.