On 02/09/2015 07:26 AM, Paolo Bonzini wrote:
>
>
> On 06/02/2015 21:08, Chris J Arges wrote:
>> Is there a architecture and machine type independent way to detect that
>> one is running inside a KVM guest? I've noticed the following systemd
>> code which does t
work on a patch, but initial feedback would be helpful.
Thanks,
--chris j arges
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
The last patch moves the ifdef in a way that causes a compiler warning.
Here fix the ifdefs to isloate x86_64 functions and variables for the test.
Signed-off-by: Chris J Arges
---
x86/hypercall.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/x86/hypercall.c b/x86
There is a failure to build on 32-bit hosts:
x86/hypercall.c: In function ‘test_edge’:
x86/hypercall.c:42:2: error: ‘test_rip’ undeclared (first use in this function)
test_rip = 0;
^
This patch fixes this issue.
Signed-off-by: Chris J Arges
---
x86/hypercall.c | 2 +-
1 file changed, 1
In emulator.c/tests_smsw, smsw (3) fails because h_mem isn't being set correctly
before smsw is called. By using the + constraint modifier for memory we can
ensure the compiler no longer optimizes out the assignment before smsw.
Signed-off-by: Chris J Arges
---
x86/emulator.c | 2 +-
1
In emulator.c/tests_smsw, smsw (3) fails because h_mem isn't being set correctly
before smsw is called. By declaring the h_mem function parameter as volatile,
the compiler no longer optimizes out the assignment before smsw.
Signed-off-by: Chris J Arges
---
x86/emulator.c | 2 +-
1 file ch
the WARN_ON to trigger only if __scale_tsc will actually be
called from svm_adjust_tsc_offset. In addition make adj in kvm_set_msr_common
s64 since this can have signed values.
Signed-off-by: Chris J Arges
---
arch/x86/kvm/svm.c | 8 +---
arch/x86/kvm/x86.c | 2 +-
2 files changed, 6
ore_one that is similar to
how kvm_rtc_eoi_tracking_restore_all checks this condition.
Signed-off-by: Chris J Arges
---
virt/kvm/ioapic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c
index e8ce34c..859f5b8 100644
--- a/virt/kvm/ioapic.c
+++ b/virt/kvm/i
anks, I'll test yours then next
> week.
>
> Paolo
>
Paolo, Thomas,
Thanks again. I can confirm that Thomas' "timekeeping: Update timekeeper
before updating vsyscall and pvclock" indeed allows the kvmclock test to
pass on my machine.
--chris j arges
--
To unsubscri
On 09/04/2014 03:40 PM, Paolo Bonzini wrote:
> Il 04/09/2014 22:37, Chris J Arges ha scritto:
>>>> - boot_ns = ktime_to_ns(ktime_add(tk->tkr.base_mono, tk->offs_boot));
>>>> + boot_ns = ktime_to_ns(ktime_sub(tk->offs_real, tk->offs_boot));
>>
On 09/04/2014 02:42 PM, Paolo Bonzini wrote:
> Il 04/09/2014 21:15, Paolo Bonzini ha scritto:
>> Il 04/09/2014 20:16, Chris J Arges ha scritto:
>>>> + boot_ns = timespec_to_ns(&tk->total_sleep_time)
>>>> + + tk->wall_to_monotonic.tv_s
On 09/04/2014 12:14 PM, Paolo Bonzini wrote:
> Il 04/09/2014 18:00, Chris J Arges ha scritto:
>> Uptime:
>> 15:58:02 up 1:00, 1 user, load average: 0.59, 0.60, 0.31
>>
>> Here is the output:
>>
>> ./x86-run x86/kvmclock_test.flat -smp 2 --append &quo
is not anymore related to the host boot-based clock, rename boot_ns->nsec_base
> and the existing nsec_base->snsec_base.
>
> Cc: Thomas Gleixner
> Cc: John Stultz
> Reported-by: Chris J Arges
> Signed-off-by: Paolo Bonzini
> ---
> arch/x86/kvm/x86.c | 11
> I'm not sure about the reason for the warp, but indeed the offset and
> uptime match (I'll check them against the trace tomorrow) so it's "just"
> that the VM's TSC base is not taken into account correctly.
>
> Can you gather another trace with the problematic patch reverted?
>
> Paolo
>
Her
On 09/03/2014 09:59 AM, Paolo Bonzini wrote:
> Il 02/09/2014 21:57, Chris J Arges ha scritto:
>> Seconds get from host: 1409687073
>> Seconds get from kvmclock: 1409333034
>> Offset:-354039
>> offset too large!
>> Check the stabili
On 09/03/2014 09:47 AM, Paolo Bonzini wrote:
> Il 02/09/2014 21:57, Chris J Arges ha scritto:
>>>> Can you please trace the test using trace-cmd
>>>> (http://www.linux-kvm.org/page/Tracing) and send the output?
>>>>
>>>> Paolo
>>>
On 08/31/2014 11:05 AM, Paolo Bonzini wrote:
> Il 29/08/2014 23:05, Chris J Arges ha scritto:
>> And indeed there is a condition where matched && already_matched are
>> both true. In this case we don't zero or increment nr_vcpus_matched_tsc.
>> Incrementing nr_v
On 08/29/2014 04:08 PM, Paolo Bonzini wrote:
> Il 29/08/2014 19:36, Chris J Arges ha scritto:
>> I still get failures with the following test, I actually tested on
>> multiple machines with identical hardware and the same failure occurred.
>> In v3.13/v3.16 series kernels t
On 08/29/2014 12:36 PM, Chris J Arges wrote:
> On 08/27/2014 05:05 PM, Paolo Bonzini wrote:
>>
>>
>> - Messaggio originale -----
>>> Da: "Chris J Arges"
>>> A: "Paolo Bonzini" , kvm@vger.kernel.org
>>> Inviato: Mercole
On 08/27/2014 05:05 PM, Paolo Bonzini wrote:
>
>
> - Messaggio originale -
>> Da: "Chris J Arges"
>> A: "Paolo Bonzini" , kvm@vger.kernel.org
>> Inviato: Mercoledì, 27 agosto 2014 23:24:14
>> Oggetto: kvm-unit-test failures (was
of raw cycle ...
Total vcpus: 2
Test loops: 1000
TSC cycles: 1065145046
Measure the performance of adjusted cycle ...
Total vcpus: 2
Test loops: 1000
TSC cycles: 1126981511
Return value from qemu: 3
Let me know if anything comes to mind. I can also look more deeply into
these fai
In unittests.cfg one can add a line like the following:
check = /proc/sys/kernel/nmi_watchdog=0 /proc/sys/kernel/ostype=Linux
run_tests.sh will now check for those values (if defined) and only run
the test if all conditions are true.
Signed-off-by: Chris J Arges
---
run_tests.sh | 21
In unittests.cfg one can add a line like the following:
check = /proc/sys/kernel/nmi_watchdog=0 /proc/sys/kernel/ostype=Linux
run_tests.sh will now check for those values (if defined) and only run
the test if all conditions are true.
Signed-off-by: Chris J Arges
---
run_tests.sh | 21
If nmi_watchdog is enabled, it will take up a PMU counter causing the
all_counters testcase to fail. This additional check will error out if
nmi_watchdog is enabled and provide feedback for the user to configure the
host machine correctly.
Signed-off-by: Chris J Arges
---
x86/unittests.cfg | 1
In unittests.cfg one can add a line like the following:
check = /proc/sys/kernel/nmi_watchdog=0 /proc/sys/kernel/ostype=Linux
run_tests.sh will now check for those values (if defined) and only run
the test if all conditions are true.
Signed-off-by: Chris J Arges
---
run_tests.sh | 21
These two patches add the ability to check for host machine conditions
before running a particular test. This allows the configuration file to have
a mechanism to skip false negatives.
Chris J Arges (2):
add check parameter to run_tests configuration
x86/unittests.cfg: the pmu testcase
s disabling NMI watchdog via:
echo 0 | sudo tee /proc/sys/kernel/nmi_watchdog
Allows this test to pass.
Would it make sense to have a check if nmi_watchdog is enabled in this
test case, and skip the all counters test?
--chris j arges
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/25/2014 11:45 AM, Paolo Bonzini wrote:
> Il 14/08/2014 22:58, Chris J Arges ha scritto:
>> In the check_counters_many function measure was only being called on the last
>> counter, causing the pmu test to fail.
>
> I don't understand. measure loops o
In the check_counters_many function measure was only being called on the last
counter, causing the pmu test to fail. This ensures that measure is called for
each counter in the array before calling verify_counter.
Signed-off-by: Chris J Arges
---
x86/pmu.c | 6 +++---
1 file changed, 3
In the check_counters_many function measure was only being called on the last
counter, causing the pmu test to fail. This ensures that measure is called for
each counter in the array before calling verify_counter.
Signed-off-by: Chris J Arges
---
x86/pmu.c | 6 +++---
1 file changed, 3
On 08/05/2014 05:26 AM, Paolo Bonzini wrote:
> Il 04/08/2014 19:02, Chris J Arges ha scritto:
>> All tests below are done with the kvm tip (fresh as of today) merged
>> with 3.16-rc4.
>
Updated information with the three new kvm-unit-tests patches you've posted.
> So
On 08/04/2014 01:40 PM, Paolo Bonzini wrote:
> Il 04/08/2014 20:37, Chris J Arges ha scritto:
>> Paolo,
>> Yes this is how I initially ran the script:
>> ./configure && make
>> sudo ./run_tests.sh -v
>>
>> Then if any commands that failed, I re-ran
On 08/04/2014 01:20 PM, Paolo Bonzini wrote:
> Il 04/08/2014 19:02, Chris J Arges ha scritto:
>> Paulo,
>> Hopefully this is enough to get started; I can file this as a bug if its
>> easier to track. Let me know if there is additional information that is
>> neede
On 08/02/2014 01:35 AM, Paolo Bonzini wrote:
> Il 01/08/2014 23:09, Chris J Arges ha scritto:
>> Hi,
>>
>> We are planning on running kvm-unit-tests as part of our test suite; but
>> I've noticed that many tests fail (even running the latest kvm tip).
>> A
rack these issues? Should I be reporting new bugs with failures in the
unit tests? Where is the appropriate place to file bugs against
kvm-unit-tests and discuss issues?
Thanks,
--chris j arges
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of
Remove a function which was added by both 93c4adc7afe and 36be0b9deb2.
Signed-off-by: Chris J Arges
---
arch/x86/kvm/vmx.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 801332e..c4ea039 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
36 matches
Mail list logo
