> -----Original Message----- > From: Jan Beulich <jbeul...@suse.com> > Sent: 01 October 2020 09:49 > To: Julien Grall <jul...@xen.org> > Cc: Oleksandr <olekst...@gmail.com>; xen-devel@lists.xenproject.org; > p...@xen.org; 'Oleksandr > Tyshchenko' <oleksandr_tyshche...@epam.com>; 'Andrew Cooper' > <andrew.coop...@citrix.com>; 'George > Dunlap' <george.dun...@citrix.com>; 'Ian Jackson' > <ian.jack...@eu.citrix.com>; 'Stefano Stabellini' > <sstabell...@kernel.org>; 'Wei Liu' <w...@xen.org>; 'Roger Pau Monné' > <roger....@citrix.com>; 'Jun > Nakajima' <jun.nakaj...@intel.com>; 'Kevin Tian' <kevin.t...@intel.com>; 'Tim > Deegan' <t...@xen.org>; > 'Julien Grall' <julien.gr...@arm.com> > 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
