From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162891AbcG1AXU (ORCPT ); Wed, 27 Jul 2016 20:23:20 -0400 Received: from ppsw-40.csi.cam.ac.uk ([131.111.8.140]:43229 "EHLO ppsw-40.csi.cam.ac.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1162468AbcG1AXL (ORCPT ); Wed, 27 Jul 2016 20:23:11 -0400 X-Greylist: delayed 1173 seconds by postgrey-1.27 at vger.kernel.org; Wed, 27 Jul 2016 20:23:11 EDT X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Subject: Re: [Xen-devel] [GIT PULL] xen: features and fixes for 4.8-rc0 To: "Rafael J. Wysocki" , Linus Torvalds References: <5798BB14.9090606@cantab.net> <4745197.6nnjR21Chc@vostro.rjw.lan> <2152986.NBIGJLcTzZ@vostro.rjw.lan> Cc: David Vrabel , Shannon Zhao , "Rafael J. Wysocki" , xen-devel , "linux-kernel@vger.kernel.org" From: Andrew Cooper Message-ID: <3406d772-4a5e-2cf8-a234-d3f3ff73a589@citrix.com> Date: Thu, 28 Jul 2016 01:03:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <2152986.NBIGJLcTzZ@vostro.rjw.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 28/07/2016 00:46, Rafael J. Wysocki wrote: > On Wednesday, July 27, 2016 04:18:32 PM Linus Torvalds wrote: >> On Wed, Jul 27, 2016 at 4:09 PM, Rafael J. Wysocki wrote: >>> The STAO definition document: >>> >>> http://wiki.xenproject.org/mediawiki/images/0/02/Status-override-table.pdf >>> >>> requires as to "operate as if that device does not exist", quite literally. >> Well, first off, documentation is one thing, actually changing >> behavior is something entirely different. >> >> Theory and practice are *not* the same. > Well, the STAO thing is totally new, so we have the documentation only ATM. > >> The other worry I have is that I'd be happier if it's still visible in >> /sys/bus/acpi/ etc. Again, it's one thing to not react to it >> programmatically, and another thing entirely to actually hide the >> information from the rest of the system. >> >> If I read that patch right, it will be hidden from sysfs too. But >> Maybe I'm mistaken. > You're right. > > Avoiding to enumerate it entirely is somewhat simpler, because it allows > us to avoid some special casing in a few places IIRC. > > I guess we can ask the author of the commit in question to come up with a > patch to unhide that device and we'll see how that looks like. Well - the entire purpose of STAO is to list system resources which are genuinely in use by the hypervisor, and genuinely can't be mapped or used by the kernel (these latter two frequently resulting in crashes or hangs at early boot). Identifying that such devices exist is reasonable (it is certainly possibly by dumping the raw acpi tables), but any sysfs tweakable is going to end in misery. ~Andrew