mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: David Vrabel <dvrabel@cantab.net>,
	Shannon Zhao <shannon.zhao@linaro.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	xen-devel <xen-devel@lists.xenproject.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Xen-devel] [GIT PULL] xen: features and fixes for 4.8-rc0
Date: Thu, 28 Jul 2016 01:03:33 +0100	[thread overview]
Message-ID: <3406d772-4a5e-2cf8-a234-d3f3ff73a589@citrix.com> (raw)
In-Reply-To: <2152986.NBIGJLcTzZ@vostro.rjw.lan>

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 <rjw@rjwysocki.net> 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

      reply	other threads:[~2016-07-28  0:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-27 13:45 David Vrabel
2016-07-27 18:42 ` Linus Torvalds
2016-07-27 18:57   ` [Xen-devel] " Andrew Cooper
2016-07-27 23:09     ` Rafael J. Wysocki
2016-07-27 23:18       ` Linus Torvalds
2016-07-27 23:46         ` Rafael J. Wysocki
2016-07-28  0:03           ` Andrew Cooper [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3406d772-4a5e-2cf8-a234-d3f3ff73a589@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=dvrabel@cantab.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rjw@rjwysocki.net \
    --cc=shannon.zhao@linaro.org \
    --cc=torvalds@linux-foundation.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®