> -----Original Message----- > From: Jan Beulich <[email protected]> > Sent: 01 October 2020 09:49 > To: Julien Grall <[email protected]> > Cc: Oleksandr <[email protected]>; [email protected]; > [email protected]; 'Oleksandr > Tyshchenko' <[email protected]>; 'Andrew Cooper' > <[email protected]>; 'George > Dunlap' <[email protected]>; 'Ian Jackson' > <[email protected]>; 'Stefano Stabellini' > <[email protected]>; 'Wei Liu' <[email protected]>; 'Roger Pau Monné' > <[email protected]>; 'Jun > Nakajima' <[email protected]>; 'Kevin Tian' <[email protected]>; 'Tim > Deegan' <[email protected]>; > 'Julien Grall' <[email protected]> > 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
