Re: [Qemu-devel] [PATCH 0/4] AER-KVM: Error containment of PCI pass-thru devices assigned to KVM guests

[Pandarathil, Vijaymohan R]

> -----Original Message-----
> From: Stefan Hajnoczi [mailto:address@hidden
> Sent: Tuesday, November 20, 2012 5:41 AM
> To: Pandarathil, Vijaymohan R
> Cc: address@hidden; address@hidden; address@hidden;
> address@hidden
> Subject: Re: [PATCH 0/4] AER-KVM: Error containment of PCI pass-thru
> devices assigned to KVM guests
> 
> On Tue, Nov 20, 2012 at 06:31:48AM +0000, Pandarathil, Vijaymohan R wrote:
> > Add support for error containment when a PCI pass-thru device assigned to
> a KVM
> > guest encounters an error. This is for PCIe devices/drivers that support
> AER
> > functionality. When the OS is notified of an error in a device either
> > through the firmware first approach or through an interrupt handled by
> the AER
> > root port driver, concerned subsystems are notified by invoking callbacks
> > registered by these subsystems. The device is also marked as tainted till
> the
> > corresponding driver recovery routines are successful.
> >
> > KVM module registers for a notification of such errors. In the KVM
> callback
> > routine, a global counter is incremented to keep track of the error
> > notification. Before each CPU enters guest mode to execute guest code,
> > appropriate checks are done to see if the impacted device belongs to the
> guest
> > or not. If the device belongs to the guest, qemu hypervisor for the guest
> is
> > informed and the guest is immediately brought down, thus preventing or
> > minimizing chances of any bad data being written out by the guest driver
> > after the device has encountered an error.
> 
> I'm surprised that the hypervisor would shut down the guest when PCIe
> AER kicks in for a pass-through device.  Shouldn't we pass the AER event
> into the guest and deal with it there?

Agreed. That would be the ideal behavior and is planned in a future patch.
Lack of control over the capabilities/type of the OS/drivers running in 
the guest is also a concern in passing along the event to the guest.

My understanding is that in the current implementation of Linux/KVM, these 
errors are not handled at all and can potentially cause a guest hang or 
crash or even data corruption depending on the implementation of the guest
driver for the device. As a first step, these patches make the behavior 
better by doing error containment with a predictable behavior when such
errors occur. 

> 
> The equivalent to this policy on physical hardware would be that the CPU
> is reset or the machine is powered down on AER.  That doesn't sound
> right.
> 
> Stefan