Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934758Ab3FSMn6 (ORCPT ); Wed, 19 Jun 2013 08:43:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:11245 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934599Ab3FSMn4 (ORCPT ); Wed, 19 Jun 2013 08:43:56 -0400 Message-ID: <51C1A78A.3090904@redhat.com> Date: Wed, 19 Jun 2013 08:43:54 -0400 From: Don Dutile User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130108 Thunderbird/10.0.12 MIME-Version: 1.0 To: Bjorn Helgaas CC: Alex Williamson , "linux-pci@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" Subject: Re: [PATCH] pci: Enable overrides for missing ACS capabilities References: <20130530183955.14686.89444.stgit@bling.home> <20130618172819.GA16134@google.com> <1371579648.22681.209.camel@ul30vt.home> <1371594159.22659.34.camel@ul30vt.home> <51C0E73F.1060708@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3617 Lines: 77 On 06/18/2013 10:52 PM, Bjorn Helgaas wrote: > On Tue, Jun 18, 2013 at 5:03 PM, Don Dutile wrote: >> On 06/18/2013 06:22 PM, Alex Williamson wrote: >>> >>> On Tue, 2013-06-18 at 15:31 -0600, Bjorn Helgaas wrote: >>>> >>>> On Tue, Jun 18, 2013 at 12:20 PM, Alex Williamson >>>> wrote: >>>>> >>>>> On Tue, 2013-06-18 at 11:28 -0600, Bjorn Helgaas wrote: >>>>>> >>>>>> On Thu, May 30, 2013 at 12:40:19PM -0600, Alex Williamson wrote: >> ... >>>>>> Who do you expect to decide whether to use this option? I think it >>>>>> requires intimate knowledge of how the device works. >>>>>> >>>>>> I think the benefit of using the option is that it makes assignment of >>>>>> devices to guests more flexible, which will make it attractive to >>>>>> users. >>>>>> But most users have no way of knowing whether it's actually *safe* to >>>>>> use this. So I worry that you're adding an easy way to pretend >>>>>> isolation >>>>>> exists when there's no good way of being confident that it actually >>>>>> does. > >> ... > >>>> I wonder if we should taint the kernel if this option is used (but not >>>> for specific devices added to pci_dev_acs_enabled[]). It would also >>>> be nice if pci_dev_specific_acs_enabled() gave some indication in >>>> dmesg for the specific devices you're hoping to add to >>>> pci_dev_acs_enabled[]. It's not an enumeration-time quirk right now, >>>> so I'm not sure how we'd limit it to one message per device. >>> >>> Right, setup vs use and getting single prints is a lot of extra code. >>> Tainting is troublesome for support, Don had some objections when I >>> suggested the same to him. >>> >> For RH GSS (Global Support Services), a 'taint' in the kernel printk means >> RH doesn't support that system. The 'non-support' due to 'taint' being >> printed >> out in this case may be incorrect -- RH may support that use, at least until >> a more sufficient patched kernel is provided. >> Thus my dissension that 'taint' be output. WARN is ok. 'driver beware', >> 'unleashed dog afoot'.... sure... > > So ... that's really a RH-specific support issue, and easily worked > around by RH adding a patch that turns off tainting. > sure. what's another patch to the thousands... :-/ > It still sounds like a good idea to me for upstream, where use of this > option can very possibly lead to corruption or information leakage > between devices the user claimed were isolated, but in fact were not. > > Bjorn Did I miss something? This patch provides a user-level/chosen override; like all other overrides, (pci=realloc, etc.), it can lead to a failing system. IMO, this patch is no different. If you want to tag this patch with taint, then let's audit all the (PCI) overrides and taint them appropriately. Taint should be reserved to changes to the kernel that were done outside the development of the kernel, or with the explicit intent to circumvent the normal operation of the kernel. This patch provides a way to enable ACS checking to succeed when the devices have not provided sufficiently complete ACS information. i.e., it's a growth path for PCIe-ACS and its need for proper support. > -- > To unsubscribe from this list: send the line "unsubscribe linux-pci" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/