From mboxrd@z Thu Jan 1 00:00:00 1970 From: Cao jin Subject: Re: [PATCH] vfio/pci: Support error recovery Date: Sun, 4 Dec 2016 20:16:42 +0800 Message-ID: <5844092A.30204@cn.fujitsu.com> References: <1480246457-10368-1-git-send-email-caoj.fnst@cn.fujitsu.com> <20161130210413.5161aab1@t450s.home> <58402830.3060606@cn.fujitsu.com> <20161201075541.756f6332@t450s.home> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Cc: , , , To: Alex Williamson Return-path: In-Reply-To: <20161201075541.756f6332@t450s.home> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On 12/01/2016 10:55 PM, Alex Williamson wrote: > On Thu, 1 Dec 2016 21:40:00 +0800 >>> If an AER fault occurs and the user doesn't do a reset, what >>> happens when that device is released and a host driver tries to make >>> use of it? The user makes no commitment to do a reset and there are >>> only limited configurations where we even allow the user to perform a >>> reset. >>> >> >> Limited? Do you mean the things __pci_dev_reset() can do? > > I mean that there are significant device and guest configuration > restrictions in order to support AER. For instance, all the functions > of the slot need to appear in a PCI-e topology in the guest with all > the functions in the right place such that a guest bus reset translates > into a host bus reset. The physical functions cannot be split between > guests even if IOMMU isolation would otherwise allow it. The user > needs to explicitly enable AER support for the devices. A VM need to > be specifically configured for AER support in order to set any sort of > expectations of a guest directed bus reset, let alone a guarantee that > it will happen. So all the existing VMs, where functions are split > between guests, or the topology isn't exactly right, or AER isn't > enabled see a regression from the above change as the device is no > longer reset. > I am not clear why set these restrictions in the current design. I take a glance at older versions of qemu's patchset, their thoughts is: translate a guest bus reset into a host bus reset(Which is unreasonable[*] to me). And I guess, that's the *cause* of these restrictions? Is there any other stories behind these restrictions? [*] In physical world, set bridge's secondary bus reset would send hot-reset TLP to all functions below, trigger every device's reset separately. Emulated device should behave the same, means just using each device's DeviceClass->reset method. -- Sincerely, Cao jin