From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43631) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDyDH-0006Yr-Ic for qemu-devel@nongnu.org; Wed, 21 Jan 2015 11:33:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YDyDD-0000ii-9C for qemu-devel@nongnu.org; Wed, 21 Jan 2015 11:33:03 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41452) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YDyDD-0000gE-2r for qemu-devel@nongnu.org; Wed, 21 Jan 2015 11:32:59 -0500 Message-ID: <54BFD4B2.5010402@redhat.com> Date: Wed, 21 Jan 2015 18:32:50 +0200 From: Marcel Apfelbaum MIME-Version: 1.0 References: <54B3D280.90205@gmail.com> <54B8C416.5050701@cn.fujitsu.com> <54BF77DF.9030307@cn.fujitsu.com> In-Reply-To: <54BF77DF.9030307@cn.fujitsu.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 2/4] pcie-aer: Fix command pcie_aer_inject_error is invalid List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Chen Fan , qemu-devel@nongnu.org Cc: Alex Williamson On 01/21/2015 11:56 AM, Chen Fan wrote: > > On 01/16/2015 03:56 PM, Chen Fan wrote: >> >> On 01/12/2015 09:56 PM, Marcel Apfelbaum wrote: >>> On 01/12/2015 05:04 AM, Chen Fan wrote: >>>> in spec "PCI Express 3.0" section 6.2.6 Figure 6-3 virtual bridge part, >>>> the flowchart showing tell us SERR# enable at Bridge Control register >>>> associate with system error at Secondary Status register can send error >>>> message. but bridge_control from dev->config is NULL, and SERR# was set >>>> in dev->wmask in pcie_aer_init() >>> wmask denotes the register bits that can be written by the guest. >>> >>> If you are referring to: >>> pci_word_test_and_set_mask(dev->wmask + PCI_BRIDGE_CONTROL, >>> PCI_BRIDGE_CTL_SERR); >>> that means that the OS *is able* to turn on/off SERR forwarding. >> Hi marcel, >> >> I saw the OS that turn on SERR# is to via evaluate _HPP (Hot Plug Parameters) method in ACPI. >> it the only way to turn on SERR#? This is strange, I don't see how it is connected. > > I saw there was one option do it, called*//*PCI SERR# Generation **searched from web pages in firmware on hardware****. > Do it turn on the SERR#? if so, we can enable it in seabios. Indeed, OS/firmware are in charge of setting this bit. We *could* do it in BIOS, but not before checking how the OS is handling it I suggest checking the pci(e) bridge initialization code in Linux Kernel and only then decide how to proceed. You can also look(grep) for this ...CTL_ERR in the kernel code and try to figure that out. Thanks, Marcel > Thanks, > Chen > [...]