Potential race between shutting down a domain and handling I/O

[Julien Grall <julien@xxxxxxx>]

Hi all,

While looking at the I/O handling code, I noticed that hvmemul_do_io() 
contains the following code:
 333             rc = ioreq_send(s, &p, 0);
 334             if ( rc != X86EMUL_RETRY || currd->is_shutting_down )
 335                 vio->req.state = STATE_IOREQ_NONE;

Looking at history [1], it looks like the second part was added to cover 
the case the I/O was not handled because the domain is shutdown down 
(i.e. vcpu_start_shutdown_deferral() returned false).
However, I think, it would be possible that the request to shutdown 
happens *after* vcpu_start_shutdown_deferral() returns true. In which 
case, we would set the state of the I/O to NONE. It is not clear to me 
what could go wrong, but from the commit message it looks like this 
wasn't the intended behavior as the I/O would have been sent to the IOREQ.
For completeness, I think a similar issue would happen in handle_pio(). 
We would end up to re-emulate the I/O which may have side-effect (?).
Note that the race is tiny and I haven't been able to reproduce it so 
far. Can someone confirm my understanding?
If there are a bug, then I am thinking to extend hvm_vcpu_io to indicate 
whether the I/O handling was deferred. Any other suggestion?
Cheers,

[1] 
https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=0c0cbf72cf9f28070cc5d49955b0a00df5c1d114;hp=d1370961810d3b1630e0ad5e28e5cfc8dcfe2b9b
--
Julien Grall