RE: [PATCH V1 02/16] xen/ioreq: Make x86's IOREQ feature common

[Paul Durrant <xadimgnik@xxxxxxxxx>]

> -----Original Message-----
> From: Jan Beulich <jbeulich@xxxxxxxx>
> Sent: 01 October 2020 09:49
> To: Julien Grall <julien@xxxxxxx>
> Cc: Oleksandr <olekstysh@xxxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx; 
> paul@xxxxxxx; 'Oleksandr
> Tyshchenko' <oleksandr_tyshchenko@xxxxxxxx>; 'Andrew Cooper' 
> <andrew.cooper3@xxxxxxxxxx>; 'George
> Dunlap' <george.dunlap@xxxxxxxxxx>; 'Ian Jackson' 
> <ian.jackson@xxxxxxxxxxxxx>; 'Stefano Stabellini'
> <sstabellini@xxxxxxxxxx>; 'Wei Liu' <wl@xxxxxxx>; 'Roger Pau Monné' 
> <roger.pau@xxxxxxxxxx>; 'Jun
> Nakajima' <jun.nakajima@xxxxxxxxx>; 'Kevin Tian' <kevin.tian@xxxxxxxxx>; 'Tim 
> Deegan' <tim@xxxxxxx>;
> 'Julien Grall' <julien.grall@xxxxxxx>
> Subject: Re: [PATCH V1 02/16] xen/ioreq: Make x86's IOREQ feature common
> 
> On 30.09.2020 19:47, Julien Grall wrote:
> > Regarding the fix itself, I am not sure what sort of synchronization we
> > can do. Are you suggesting to wait for the I/O to complete? If so, how
> > do we handle the case the IOREQ server died?
> 
> In simple cases retrying the entire request may be an option. However,
> if the server died after some parts of a multi-part operation were
> done already, I guess the resulting loss of state is bad enough to
> warrant crashing the guest. This shouldn't be much different from e.g.
> a device disappearing from a bare metal system - any partial I/O done
> to/from it will leave the machine in an unpredictable state, which it
> may be too difficult to recover from without rebooting. (Of course,
> staying with this analogue, it may also be okay to simple consider
> the operation "complete", leaving it to the guest to recover. The
> main issue on the hypervisor side then would be to ensure we don't
> expose any uninitialized [due to not having got written to] data to
> the guest.)
> 

I'll try to take a look today and come up with a patch.

  Paul