Messages in this thread | | | From | "Pandarathil, Vijaymohan R" <> | Subject | RE: [PATCH 0/4] AER-KVM: Error containment of PCI pass-thru devices assigned to KVM guests | Date | Tue, 20 Nov 2012 14:09:46 +0000 |
| |
> -----Original Message----- > From: Stefan Hajnoczi [mailto:stefanha@gmail.com] > Sent: Tuesday, November 20, 2012 5:41 AM > To: Pandarathil, Vijaymohan R > Cc: kvm@vger.kernel.org; linux-pci@vger.kernel.org; qemu-devel@nongnu.org; > linux-kernel@vger.kernel.org > 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
| |