[Qemu-devel] Re: [PATCH v9 8/8] x3130/downstream: support aer.

[Isaku Yamahata]

On Tue, Nov 16, 2010 at 10:57:59AM -0800, Etienne Martineau wrote:
> 
> On Tue, 2010-11-16 at 17:26 +0900, Isaku Yamahata wrote:
> > add aer support.
> > 
> > Signed-off-by: Isaku Yamahata <address@hidden>
> 
> I'm actually working on a scheme to provide support to handle PCI 
> errors related to assigned devices. The goal is to notify the 
> coresponding driver so that all his I/O access are stop quickly and to 
> provide that same driver a chance to get back in sync with the device.
> 
> I'm just wondering how can I make use of your aer support in Q35?
> 
> As you already know, error detection and error recovery phases are driven 
> by a state machine where the next state depends on the returned value from 
> the current callback. Also only the host can performed the link recovery 
> sequence for assigned devices.
> 
> Because of such it seems like the only way to maintain consistency between 
> the assigned device and it's corresponding driver is to perform the error 
> detection/recovery phase in lockstep with the host?

Maybe. At least at the first implementation, I suppose.
Then we would learn from its experience, then move on to next generation
implementation.

To be honest, what I have in my mind very vaguely is
- something like pcie aer fd driver.
  or enhancement to vfio
  qemu polls the fd.

- error recovery in host will be directed by qemu
  in concert with guest recovery action.
 
  For latency necessary information would be shared by
  qemu and host kernel, so that the aer driver in host kernel
  could take responsibility to eliminate the latency caused by
  qemu process.

I suppose there is no single right way for recovery action
in host/guest. So there should be room for recovery policies.
-- 
yamahata