All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Kyle Huey <me@kylehuey.com>
Cc: "Robert O'Callahan" <robert@ocallahan.org>,
	"Andy Lutomirski" <luto@kernel.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, "Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Jeff Dike" <jdike@addtoit.com>,
	"Richard Weinberger" <richard@nod.at>,
	"Alexander Viro" <viro@zeniv.linux.org.uk>,
	"Shuah Khan" <shuah@kernel.org>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"Borislav Petkov" <bp@suse.de>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Len Brown" <len.brown@intel.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	"Dmitry Safonov" <dsafonov@virtuozzo.com>,
	"David Matlack" <dmatlack@google.com>,
	linux-kernel@vger.kernel.org,
	user-mode-linux-devel@lists.sourceforge.net,
	user-mode-linux-user@lists.sourceforge.net,
	linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	kvm@vger.kernel.org
Subject: Re: [PATCH v10 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID
Date: Tue, 8 Nov 2016 21:06:31 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1611082007010.3501@nanos> (raw)
In-Reply-To: <20161108183956.4521-7-khuey@kylehuey.com>

On Tue, 8 Nov 2016, Kyle Huey wrote:
> Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
> When enabled, the processor will fault on attempts to execute the CPUID
> instruction with CPL>0. Exposing this feature to userspace will allow a
> ptracer to trap and emulate the CPUID instruction.
> 
> When supported, this feature is controlled by toggling bit 0 of
> MSR_MISC_FEATURES_ENABLES. It is documented in detail in Section 2.3.2 of
> http://www.intel.com/content/dam/www/public/us/en/documents/application-notes/virtualization-technology-flexmigration-application-note.pdf

See previous mail.

> +DECLARE_PER_CPU(u64, msr_misc_features_enables_shadow);
> +
> diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
> index 97a340d..7d364e4 100644
> --- a/arch/x86/kernel/cpu/scattered.c
> +++ b/arch/x86/kernel/cpu/scattered.c
> @@ -71,9 +71,14 @@ void init_scattered_cpuid_features(struct cpuinfo_x86 *c)
>  	}
>  
>  	for (mb = msr_bits; mb->feature; mb++) {
>  		if (rdmsrl_safe(mb->msr, &msrval))
>  			continue;
>  		if (msrval & (1ULL << mb->bit))
>  			set_cpu_cap(c, mb->feature);
>  	}
> +
> +	if (cpu_has(c, X86_FEATURE_CPUID_FAULT)) {
> +		rdmsrl(MSR_MISC_FEATURES_ENABLES, msrval);
> +		this_cpu_write(msr_misc_features_enables_shadow, msrval);
> +	}

I'm not really happy about this placement. There is more stuff coming up
which affects that MSR, so we should have a central place to handle it.

The most obvious is here:

> +DEFINE_PER_CPU(u64, msr_misc_features_enables_shadow);

void msr_misc_features_enable_init(struct cpuinfo_x86 *c)
{
	u64 val;

	if (rdmsrl_safe(MSR_MISC_FEATURES_ENABLES, val))
		return;

	this_cpu_write(msr_misc_features_enables_shadow, val);
}

The upcoming ring3 mwait stuff can add its magic to tweak that MSR into
this function.

Stick the call at the end of init_scattered_cpuid_features() for now. I
still need to figure out a proper place for it.

> +static int set_cpuid_mode(struct task_struct *task, unsigned long val)
> +{
> +	/* Only disable_cpuid() if it is supported on this hardware. */

That comment makes no sense.

> +	if (!static_cpu_has(X86_FEATURE_CPUID_FAULT))
> +		return -ENODEV;

Thanks,

	tglx


WARNING: multiple messages have this Message-ID (diff)
From: Thomas Gleixner <tglx@linutronix.de>
To: Kyle Huey <me@kylehuey.com>
Cc: "Robert O'Callahan" <robert@ocallahan.org>,
	"Andy Lutomirski" <luto@kernel.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, "Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Jeff Dike" <jdike@addtoit.com>,
	"Richard Weinberger" <richard@nod.at>,
	"Alexander Viro" <viro@zeniv.linux.org.uk>,
	"Shuah Khan" <shuah@kernel.org>,
	"Dave Hansen" <dave.hansen@linux.intel.com>,
	"Borislav Petkov" <bp@suse.de>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Len Brown" <len.brown@intel.com>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	"Dmitry Safonov" <dsafonov@virtuozzo.com>,
	"David Matlack" <dmatlack@google.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v10 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID
Date: Tue, 8 Nov 2016 21:06:31 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1611082007010.3501@nanos> (raw)
In-Reply-To: <20161108183956.4521-7-khuey@kylehuey.com>

On Tue, 8 Nov 2016, Kyle Huey wrote:
> Intel supports faulting on the CPUID instruction beginning with Ivy Bridge.
> When enabled, the processor will fault on attempts to execute the CPUID
> instruction with CPL>0. Exposing this feature to userspace will allow a
> ptracer to trap and emulate the CPUID instruction.
> 
> When supported, this feature is controlled by toggling bit 0 of
> MSR_MISC_FEATURES_ENABLES. It is documented in detail in Section 2.3.2 of
> http://www.intel.com/content/dam/www/public/us/en/documents/application-notes/virtualization-technology-flexmigration-application-note.pdf

See previous mail.

> +DECLARE_PER_CPU(u64, msr_misc_features_enables_shadow);
> +
> diff --git a/arch/x86/kernel/cpu/scattered.c b/arch/x86/kernel/cpu/scattered.c
> index 97a340d..7d364e4 100644
> --- a/arch/x86/kernel/cpu/scattered.c
> +++ b/arch/x86/kernel/cpu/scattered.c
> @@ -71,9 +71,14 @@ void init_scattered_cpuid_features(struct cpuinfo_x86 *c)
>  	}
>  
>  	for (mb = msr_bits; mb->feature; mb++) {
>  		if (rdmsrl_safe(mb->msr, &msrval))
>  			continue;
>  		if (msrval & (1ULL << mb->bit))
>  			set_cpu_cap(c, mb->feature);
>  	}
> +
> +	if (cpu_has(c, X86_FEATURE_CPUID_FAULT)) {
> +		rdmsrl(MSR_MISC_FEATURES_ENABLES, msrval);
> +		this_cpu_write(msr_misc_features_enables_shadow, msrval);
> +	}

I'm not really happy about this placement. There is more stuff coming up
which affects that MSR, so we should have a central place to handle it.

The most obvious is here:

> +DEFINE_PER_CPU(u64, msr_misc_features_enables_shadow);

void msr_misc_features_enable_init(struct cpuinfo_x86 *c)
{
	u64 val;

	if (rdmsrl_safe(MSR_MISC_FEATURES_ENABLES, val))
		return;

	this_cpu_write(msr_misc_features_enables_shadow, val);
}

The upcoming ring3 mwait stuff can add its magic to tweak that MSR into
this function.

Stick the call at the end of init_scattered_cpuid_features() for now. I
still need to figure out a proper place for it.

> +static int set_cpuid_mode(struct task_struct *task, unsigned long val)
> +{
> +	/* Only disable_cpuid() if it is supported on this hardware. */

That comment makes no sense.

> +	if (!static_cpu_has(X86_FEATURE_CPUID_FAULT))
> +		return -ENODEV;

Thanks,

	tglx

  reply	other threads:[~2016-11-08 20:06 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-08 18:39 [PATCH v10 0/7] x86/arch_prctl Add ARCH_[GET|SET]_CPUID for controlling the CPUID instruction Kyle Huey
2016-11-08 18:39 ` Kyle Huey
2016-11-08 18:39 ` [PATCH v10 1/7] x86/arch_prctl/64: Use SYSCALL_DEFINE2 to define sys_arch_prctl Kyle Huey
2016-11-08 18:39   ` Kyle Huey
2016-11-09  9:47   ` Borislav Petkov
2016-11-09  9:47     ` Borislav Petkov
2016-11-10 18:17     ` Kyle Huey
2016-11-10 18:17       ` Kyle Huey
2016-11-08 18:39 ` [PATCH v10 2/7] x86/arch_prctl/64: Rename do_arch_prctl to do_arch_prctl_64 Kyle Huey
2016-11-08 18:39   ` Kyle Huey
2016-11-09  9:58   ` Borislav Petkov
2016-11-09  9:58     ` Borislav Petkov
2016-11-08 18:39 ` [PATCH v10 3/7] x86/arch_prctl: Add do_arch_prctl_common Kyle Huey
2016-11-08 18:39   ` Kyle Huey
2016-11-09 10:31   ` Borislav Petkov
2016-11-09 10:31     ` Borislav Petkov
2016-11-08 18:39 ` [PATCH v10 4/7] x86/syscalls/32: Wire up arch_prctl on x86-32 Kyle Huey
2016-11-08 18:39   ` Kyle Huey
2016-11-09 11:04   ` Borislav Petkov
2016-11-09 11:04     ` Borislav Petkov
2016-11-08 18:39 ` [PATCH v10 5/7] x86/cpufeature: Detect CPUID faulting support Kyle Huey
2016-11-08 18:39   ` Kyle Huey
2016-11-08 19:06   ` Thomas Gleixner
2016-11-08 19:06     ` Thomas Gleixner
2016-11-08 19:38     ` Kyle Huey
2016-11-08 19:38       ` Kyle Huey
2016-11-09 11:14   ` Borislav Petkov
2016-11-09 11:14     ` Borislav Petkov
2016-11-08 18:39 ` [PATCH v10 6/7] x86/arch_prctl: Add ARCH_[GET|SET]_CPUID Kyle Huey
2016-11-08 18:39   ` Kyle Huey
2016-11-08 20:06   ` Thomas Gleixner [this message]
2016-11-08 20:06     ` Thomas Gleixner
2016-11-09 13:21     ` Borislav Petkov
2016-11-09 13:21       ` Borislav Petkov
2016-11-09 13:34       ` Thomas Gleixner
2016-11-09 13:34         ` Thomas Gleixner
2016-11-10 23:38         ` Kyle Huey
2016-11-10 23:38           ` Kyle Huey
2016-11-10 23:26       ` Kyle Huey
2016-11-10 23:26         ` Kyle Huey
2016-11-09 13:12   ` Borislav Petkov
2016-11-09 13:12     ` Borislav Petkov
2017-03-14 19:01   ` H. Peter Anvin
2017-03-14 19:08     ` Kyle Huey
2017-03-14 19:08       ` Kyle Huey
2017-03-14 20:06       ` H. Peter Anvin
2017-03-14 20:06         ` H. Peter Anvin
2017-03-14 19:17     ` H. Peter Anvin
2017-03-14 19:23     ` Andy Lutomirski
2017-03-14 19:23       ` Andy Lutomirski
2017-03-15  9:11       ` H. Peter Anvin
2017-03-15  9:11       ` H. Peter Anvin
2017-03-15  9:11       ` H. Peter Anvin
2016-11-08 18:39 ` [PATCH v10 7/7] KVM: x86: virtualize cpuid faulting Kyle Huey
2016-11-08 18:39   ` Kyle Huey
2016-11-08 22:12   ` David Matlack
2016-11-08 22:12     ` David Matlack

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=alpine.DEB.2.20.1611082007010.3501@nanos \
    --to=tglx@linutronix.de \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@suse.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=dmatlack@google.com \
    --cc=dsafonov@virtuozzo.com \
    --cc=hpa@zytor.com \
    --cc=jdike@addtoit.com \
    --cc=kvm@vger.kernel.org \
    --cc=len.brown@intel.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=me@kylehuey.com \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=richard@nod.at \
    --cc=rkrcmar@redhat.com \
    --cc=robert@ocallahan.org \
    --cc=shuah@kernel.org \
    --cc=user-mode-linux-devel@lists.sourceforge.net \
    --cc=user-mode-linux-user@lists.sourceforge.net \
    --cc=viro@zeniv.linux.org.uk \
    --cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.