On Thu, Oct 19, 2017 at 11:20 AM, Meng Xu wrote:
> On Thu, Oct 19, 2017 at 11:40 AM, Andrew Cooper
> wrote:
>>
>> On 19/10/17 16:09, Kyle Huey wrote:
>> > On Wed, Oct 11, 2017 at 7:09 AM, Boris Ostrovsky
>> > wrote:
>> >> On 10/10/2017 12:54 PM, K
On Wed, Oct 11, 2017 at 7:09 AM, Boris Ostrovsky
wrote:
> On 10/10/2017 12:54 PM, Kyle Huey wrote:
>> On Mon, Jul 24, 2017 at 9:54 AM, Kyle Huey wrote:
>>> On Mon, Jul 24, 2017 at 8:07 AM, Boris Ostrovsky
>>> wrote:
>>>>>> One thing I notice
On Mon, Jul 24, 2017 at 9:54 AM, Kyle Huey wrote:
> On Mon, Jul 24, 2017 at 8:07 AM, Boris Ostrovsky
> wrote:
>>
>>>> One thing I noticed is that the workaround doesn't appear to be
>>>> complete: it is only checking PMC0 status and not other counters
On Mon, Jul 24, 2017 at 8:07 AM, Boris Ostrovsky
wrote:
>
>>> One thing I noticed is that the workaround doesn't appear to be
>>> complete: it is only checking PMC0 status and not other counters (fixed
>>> or architectural). Of course, without knowing what the actual problem
>>> was it's hard to s
On Mon, Jul 24, 2017 at 7:13 AM, Andrew Cooper
wrote:
> On 22/07/17 21:16, Kyle Huey wrote:
>> Last year I reported[0] seeing occasional instability in performance
>> counter values when running rr[1], which depends on completely
>> deterministic counts of retired co
On Mon, Jul 24, 2017 at 7:08 AM, Boris Ostrovsky
wrote:
> On 07/22/2017 04:16 PM, Kyle Huey wrote:
>> Last year I reported[0] seeing occasional instability in performance
>> counter values when running rr[1], which depends on completely
>> deterministic counts of retired co
Last year I reported[0] seeing occasional instability in performance
counter values when running rr[1], which depends on completely
deterministic counts of retired conditional branches of userspace
programs.
I recently identified the cause of this problem. Xen's VPMU code
contains a workaround fo
On Mon, Oct 24, 2016 at 8:05 AM, Boris Ostrovsky
wrote:
> On 10/24/2016 12:18 AM, Kyle Huey wrote:
>>
>> The anomalies we see appear to be related to, or at least triggerable
>> by, the performance monitoring interrupt. The following program runs
>> a loop of roughl
On Fri, Oct 21, 2016 at 8:52 AM, Kyle Huey wrote:
> On Thu, Oct 20, 2016 at 7:40 AM, Boris Ostrovsky
> wrote:
>> On 10/20/2016 10:11 AM, Andrew Cooper wrote:
>>> On 20/10/16 14:55, Kyle Huey wrote:
>>>>>> That said, rr currently does not work in Xen guest
On Thu, Oct 20, 2016 at 9:19 AM, Andrew Cooper
wrote:
> On 20/10/16 15:15, Wei Liu wrote:
>> On Thu, Oct 20, 2016 at 06:44:26AM -0700, Kyle Huey wrote:
>>> rr (http://rr-project.org/), a Linux userspace record-and-replay reverse-
>>> execution debugger, would like to
On Thu, Oct 20, 2016 at 7:40 AM, Boris Ostrovsky
wrote:
> On 10/20/2016 10:11 AM, Andrew Cooper wrote:
>> On 20/10/16 14:55, Kyle Huey wrote:
>>>>> That said, rr currently does not work in Xen guests due to some PMU
>>>>> issues that we haven't tracked
On Thu, Oct 20, 2016 at 12:56 AM, Andrew Cooper
wrote:
> On 20/10/2016 06:10, Kyle Huey wrote:
>> On Mon, Oct 17, 2016 at 5:32 AM, Wei Liu wrote:
>>> On Fri, Oct 14, 2016 at 12:47:36PM -0700, Kyle Huey wrote:
>>>> On HVM guests, the cpuid triggers a vm exit
see the comment in intel_ctxt_switch_levelling).
Every PV guest cpuid will trap via a GP(0) to emulate_privileged_op (via
do_general_protection). Once there we simply decline to emulate cpuid if the
CPL > 0 and faulting is enabled, leaving the GP(0) for the guest kernel to
handle.
Signed-off-by
rr (http://rr-project.org/), a Linux userspace record-and-replay reverse-
execution debugger, would like to trap and emulate the CPUID instruction.
This would allow us to a) mask away certain hardware features that rr does
not support (e.g. RDRAND) and b) enable trace portability across machines
by
While we're here, use bool instead of bool_t.
Signed-off-by: Kyle Huey
Reviewed-by: Andrew Cooper
Reviewed-by: Wei Liu
---
xen/arch/x86/cpu/intel.c| 9 +
xen/include/asm-x86/cpuid.h | 3 +++
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/cpu/inte
On Mon, Oct 17, 2016 at 5:32 AM, Wei Liu wrote:
> On Fri, Oct 14, 2016 at 12:47:36PM -0700, Kyle Huey wrote:
>> On HVM guests, the cpuid triggers a vm exit, so we can check the emulated
>> faulting state in vmx_do_cpuid and inject a GP(0) if CPL > 0. Notably no
>> hardware
On Tue, Oct 18, 2016 at 3:09 AM, Andrew Cooper
wrote:
> On 17/10/16 19:51, Kyle Huey wrote:
>> diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c
>> index 6ed7486..a713ff3 100644
>> --- a/xen/arch/x86/hvm/emulate.c
>> +++ b/xen/arch/x86/hvm/emulat
On Tue, Oct 18, 2016 at 1:29 AM, Tian, Kevin wrote:
>> From: Kyle Huey [mailto:m...@kylehuey.com]
>> Sent: Tuesday, October 18, 2016 2:51 AM
>>
>> On HVM guests, the cpuid triggers a vm exit, so we can check the emulated
>> faulting state in vmx_do_cpuid and
mment in intel_ctxt_switch_levelling).
Every PV guest cpuid will trap via a GP(0) to emulate_privileged_op (via
do_general_protection). Once there we simply decline to emulate cpuid if the
CPL > 0 and faulting is enabled, leaving the GP(0) for the guest kernel to
handle.
Signed-off-by: Kyle Hue
rr (http://rr-project.org/), a Linux userspace record-and-replay reverse-
execution debugger, would like to trap and emulate the CPUID instruction.
This would allow us to a) mask away certain hardware features that rr does
not support (e.g. RDRAND) and b) enable trace portability across machines
by
While we're here, use bool instead of bool_t.
Signed-off-by: Kyle Huey
Reviewed-by: Andrew Cooper
Reviewed-by: Wei Liu
---
xen/arch/x86/cpu/intel.c| 9 +
xen/include/asm-x86/cpuid.h | 3 +++
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/cpu/inte
On Mon, Oct 17, 2016 at 9:39 AM, Andrew Cooper
wrote:
> On 17/10/16 17:28, Kyle Huey wrote:
>> On Mon, Oct 17, 2016 at 5:34 AM, Andrew Cooper
>> wrote:
>>> On 14/10/16 20:36, Kyle Huey wrote:
>>>> On Fri, Oct 14, 2016 at 10:18 AM, Andrew Cooper
>>>&g
On Mon, Oct 17, 2016 at 5:34 AM, Andrew Cooper
wrote:
> On 14/10/16 20:36, Kyle Huey wrote:
>> On Fri, Oct 14, 2016 at 10:18 AM, Andrew Cooper
>> wrote:
>>> On a slightly separate note, as you have just been a successful
>>> guinea-pig for XTF, how did you
While we're here, use bool instead of bool_t.
Signed-off-by: Kyle Huey
---
xen/arch/x86/cpu/intel.c| 9 +
xen/include/asm-x86/cpuid.h | 3 +++
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
index 7b60aaa..2e
rr (http://rr-project.org/), a Linux userspace record-and-replay reverse-
execution debugger, would like to trap and emulate the CPUID instruction.
This would allow us to a) mask away certain hardware features that rr does
not support (e.g. RDRAND) and b) enable trace portability across machines
by
decline to emulate cpuid if the
CPL > 0 and faulting is enabled, leaving the GP(0) for the guest kernel to
handle.
Signed-off-by: Kyle Huey
---
xen/arch/x86/hvm/vmx/vmx.c | 24 ++--
xen/arch/x86/traps.c | 34 ++
xen/include/asm-x
On Fri, Oct 14, 2016 at 10:18 AM, Andrew Cooper
wrote:
> On a slightly separate note, as you have just been a successful
> guinea-pig for XTF, how did you find it? It is a very new (still
> somewhat in development) system but the project is looking to try and
> improve regression testing in this
> :) I am now curious as to which bit I missed.
I made these changes.
- Kyle
---
tests/cpuid-faulting/main.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/tests/cpuid-faulting/main.c b/tests/cpuid-faulting/main.c
index 3e782a2..221567d 100644
--- a/tests/cpuid-fau
On Fri, Oct 14, 2016 at 7:46 AM, Andrew Cooper
wrote:
> On 14/10/16 13:04, Jan Beulich wrote:
> On 13.10.16 at 23:09, wrote:
>>> --- a/xen/arch/x86/traps.c
>>> +++ b/xen/arch/x86/traps.c
>>> @@ -1315,16 +1315,20 @@ static int emulate_forced_invalid_op(struct
>>> cpu_user_regs *regs)
>>>
decline to emulate cpuid if the
CPL > 0 and faulting is enabled, leaving the GP(0) for the guest kernel to
handle.
Signed-off-by: Kyle Huey
---
xen/arch/x86/hvm/vmx/vmx.c | 24 ++--
xen/arch/x86/traps.c | 30 ++
xen/include/asm-x86/do
---
xen/arch/x86/cpu/intel.c| 3 ++-
xen/include/asm-x86/cpuid.h | 3 +++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/cpu/intel.c b/xen/arch/x86/cpu/intel.c
index 7b60aaa..95c8e14 100644
--- a/xen/arch/x86/cpu/intel.c
+++ b/xen/arch/x86/cpu/intel.c
@@ -27,19 +27,
rr (http://rr-project.org/), a Linux userspace record-and-replay reverse-
execution debugger, would like to trap and emulate the CPUID instruction.
This would allow us to a) mask away certain hardware features that rr does
not support (e.g. RDRAND) and b) enable trace portability across machines
by
Apologies if this has already been reported.
On x86, xl create no longer works since 38cd0664a6bf. xl create gets
wedges attempting to acquire the domain-userdata-lock a second time.
strace output:
open("/var/lib/xen/userdata-l.0.----.domain-userdata-lock",
O_RDW
el, thus emulating the cpuid faulting behavior.
Signed-off-by: Kyle Huey
---
xen/arch/x86/hvm/vmx/vmx.c | 21 ++---
xen/arch/x86/traps.c | 31 ++-
xen/include/asm-x86/domain.h | 3 +++
3 files changed, 51 insertions(+), 4 deletions(-)
dif
On Tue, Oct 4, 2016 at 12:25 AM, Jan Beulich wrote:
On 04.10.16 at 00:38, wrote:
>> @@ -2701,9 +2706,13 @@ static int vmx_msr_read_intercept(unsigned int msr,
>> uint64_t *msr_content)
>> break;
>>
>> case MSR_INTEL_PLATFORM_INFO:
>> -if ( rdmsr_safe(MSR_INTEL_PLATFORM
Thanks for the reviews!
On Tue, Oct 4, 2016 at 3:31 AM, Andrew Cooper wrote:
> On 03/10/16 23:38, Kyle Huey wrote:
>> rr (http://rr-project.org/), a Linux userspace record-and-replay reverse-
>> execution debugger, would like to trap and emulate the CPUID instruction.
>> Thi
behavior. PV guest kernels enter pv_cpuid via a different
path, so we do not need to check the CPL here.
Signed-off-by: Kyle Huey
---
xen/arch/x86/domain.c| 2 ++
xen/arch/x86/hvm/vmx/vmx.c | 24 +++-
xen/arch/x86/traps.c | 31 ++-
xe
On Fri, Sep 16, 2016 at 12:50 AM, Thomas Gleixner wrote:
> On Thu, 15 Sep 2016, Kyle Huey wrote:
>
> First of all, please add a cover letter [PATCH 0/N] to your patch series
> and send it with something which provides proper mail threading.
> See: git-send-email, quilt
I did ... s
f ever there will be bits we
> can safely expose to guests, let's handle them by white listing.
>
> (As a side note - according to SDM version 059 bit 31 is reserved on
> all known families.)
>
> Reported-by: Kyle Huey
> Signed-off-by: Jan Beulich
>
> --- a/xen/arch/
On Thu, Sep 15, 2016 at 5:07 PM, Andy Lutomirski wrote:
> On Thu, Sep 15, 2016 at 4:33 PM, Kyle Huey wrote:
>> +int get_cpuid_mode(unsigned long adr)
>> +{
>> + unsigned int val;
>> +
>> + if (test_thread_flag(TIF_NOCPUID))
>> + va
On Thu, Sep 15, 2016 at 12:37 PM, Andy Lutomirski wrote:
> On Thu, Sep 15, 2016 at 12:11 PM, Kyle Huey wrote:
>> On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich wrote:
>>>>>> On 15.09.16 at 12:05, wrote:
>>>> On 14/09/16 22:01, Kyle Huey wrote:
>>
rr (http://rr-project.org/), a userspace record-and-replay reverse-
execution debugger, would like to trap and emulate the CPUID instruction.
This would allow us to a) mask away certain hardware features that rr does
not support (e.g. RDRAND) and b) enable trace portability across machines
by provi
-off-by: Kyle Huey
---
arch/x86/include/asm/msr-index.h | 1 +
arch/x86/include/asm/thread_info.h| 5 +-
arch/x86/include/uapi/asm/prctl.h | 6 +
arch/x86/kernel/process.c | 98 -
fs/exec.c | 6 +
tools
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/cpufeatures.h | 1 +
arch/x86/include/asm/msr-index.h | 1 +
arch/x86/kernel/cpu/scattered.c| 14 ++
3 files changed, 16 insertions(+)
diff --git a/arch/x86/include/asm/cpufeatures.h
b/arch/x86/include/asm/cpufeatures.h
arch_prctl is currently 64-bit only. Wire it up for 32-bits, as a no-op for
now. Rename the second arg to a more generic name.
Signed-off-by: Kyle Huey
---
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/include/asm/proto.h | 5 -
arch/x86/kernel/process.c
On Thu, Sep 15, 2016 at 3:25 AM, Jan Beulich wrote:
>>>> On 15.09.16 at 12:05, wrote:
>> On 14/09/16 22:01, Kyle Huey wrote:
>>> Xen advertises the underlying support for CPUID faulting but not does pass
>>> through writes to the relevant MSR, nor does
On Wed, Sep 14, 2016 at 6:17 PM, Andy Lutomirski wrote:
> On Wed, Sep 14, 2016 at 3:03 PM, Kyle Huey wrote:
>> On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen
>> wrote:
>>> On 09/14/2016 02:01 PM, Kyle Huey wrote:
>
>>> Is any of this useful to optimize a
On Wed, Sep 14, 2016 at 2:35 PM, Dave Hansen
wrote:
> On 09/14/2016 02:01 PM, Kyle Huey wrote:
>> Xen advertises the underlying support for CPUID faulting but not does pass
>> through writes to the relevant MSR, nor does it virtualize it, so it does
>> not actually work.
Xen advertises the underlying support for CPUID faulting but not does pass
through writes to the relevant MSR, nor does it virtualize it, so it does
not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/cpufeatures.h | 1
Xen advertises the underlying support for CPUID faulting but not does pass
through writes to the relevant MSR, nor does it virtualize it, so it does
not actually work. For now mask off the relevant bit on MSR_PLATFORM_INFO.
Signed-off-by: Kyle Huey
---
arch/x86/include/asm/cpufeatures.h | 1
50 matches
Mail list logo
