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
Paolo Bonzini wrote:
> Il 11/09/2014 19:03, Chris Webb ha scritto:
>> Paolo Bonzini wrote:
>>
>>> This is a hypercall that should have kicked VCPU 3 (see rcx).
>>>
>>> Can you please apply this patch and gather a trace of the host
>>> (u
xb0
[] ? SyS_exit_group+0xb/0x10
[] ? system_call_fastpath+0x1a/0x1f
Best wishes,
Chris.--
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
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
ut no extra information was
reported. These kernels are built with frame pointers and -O2 rather than
-Os to try to maximise useful debug info.
Any help would be extremely gratefully received: I'm at a complete loss as
to what to do next to debug this so I can start using less ancient kern
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
that doesn't seem
to have ever made it in to the mainline kernel...why not?
Thanks,
Chris
--
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/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
On 07/30/2014 09:42 AM, Paolo Bonzini wrote:
Il 30/07/2014 09:41, Chris Friesen ha scritto:
I found a document at
"http://ftp.software-sources.co.il/Processor_Architecture_Update-Bob_Valentine.pdf";
which talks about the benefits of Haswell. One of the items reads:
"New Acc
On 07/30/2014 12:09 AM, Xiao Guangrong wrote:
On 07/30/2014 06:12 AM, Chris Friesen wrote:
Hi,
I've got an issue where we're hitting major performance penalties while doing
live migration, and it seems like it might
be due to page faults triggering hypervisor exits, and then we
but might only be available on Haswell or later CPUs--is
that correct? Is it supported in kvm? If so, when was support added?
Thanks,
Chris
P.S. Please CC me on reply, I'm not subscribed to the list.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body o
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
u64, or compiling the guest kernel
without paravirtualised spinlock support does remove the panic, albeit at the
cost of performance.
Best wishes,
Chris.
--
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
ht be going on here?
Cheers,
Chris.
divide error: [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 1013 Comm: mkdir Not tainted 3.14.4-guest #21
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Bochs 01/01/2011
task: 88007c8cf400 ti: 88007c7c6000 task.ti: 88007c7c6000
RIP:
Paolo Bonzini wrote:
> Il 29/05/2014 19:45, Chris Webb ha scritto:
>> Chris Webb wrote:
>>
>>> My CPU flags inside the crashing guest look like this:
>>>
>>> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
>>>
Chris Webb wrote:
> My CPU flags inside the crashing guest look like this:
>
> fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
> clflush
> mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb lm rep_good nopl
> extd_apicid pni pclmulqdq ssse3 fma
t help track down what's going
on here.
Best wishes,
Chris.
--
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
I'm not sure that this is the right place to raise this issue, so
apologies in advance.
I have an RHEL6 system with two qemu/kvm guests, one running RHEL5
(x64) and one running Windows 7 (x64). These variously provide local
and remote access net services in a small office environment. I have
confi
First, sorry for the slow response to your thoughtful review comments.
Things have been busy for me with a new major release of the Tilera
software environment and the usual customer bug firefighting.
On 9/10/2013 6:53 AM, Gleb Natapov wrote:
> On Wed, Aug 28, 2013 at 03:45:50PM -0400, Ch
As I said to Gleb in the previous email - sorry for the delay in
replying to your thoughtful comments!
On 9/10/2013 8:47 AM, Paolo Bonzini wrote:
> Il 28/08/2013 22:58, Chris Metcalf ha scritto:
>> This change enables support for a virtio-based console,
>> network support, a
We remove some debug code in relocate_kernel_64.S that made raw
calls to the hv_console_putc Tilera hypervisor API, since everything
should funnel through the early_hv_write() API.
Signed-off-by: Chris Metcalf
---
arch/tile/kernel/relocate_kernel_64.S | 9 +++--
1 file changed, 7 insertions
nt PLs in tilepro, only tilegx.
Signed-off-by: Chris Metcalf
---
arch/tile/include/asm/page.h | 52 +++---
arch/tile/include/asm/pgtable_32.h | 2 +-
arch/tile/include/asm/pgtable_64.h | 3 +--
arch/tile/include/asm/processor.h | 2 +-
arch/tile/kernel/he
e they are essentially internal rework within the
tile architecture. This will also simplify ongoing three-way merges.
I will defer the pull request for linux-tile for a few days in case
anyone has comments on this batch of changes.
Chris Metcalf (3):
tile: clean up relocate_kernel_64 debug code
t
Technically, user privilege is anything less than kernel
privilege. We modify the existing user_mode() macro to have
this semantic (and use it in a couple of places it wasn't being
used before), and add an IS_KERNEL_EX1() macro to the assembly
code as well.
Signed-off-by: Chris Me
On 9/3/2013 1:39 PM, Gleb Natapov wrote:
> On Tue, Sep 03, 2013 at 01:32:22PM -0400, Chris Metcalf wrote:
>> Ping! I'd like to ask Linus to pull the tile tree now that 3.12 is open.
>> Let me know if this would be problematic for you.
>>
> That was sent to close to
On 8/26/2013 8:04 AM, Gleb Natapov wrote:
> On Sun, Aug 25, 2013 at 09:26:47PM -0400, Chris Metcalf wrote:
>> On 8/25/2013 7:39 AM, Gleb Natapov wrote:
>>> On Mon, Aug 12, 2013 at 04:24:11PM -0400, Chris Metcalf wrote:
>>>> This change provides the initial frame
-by: Chris Metcalf
---
arch/tile/Kconfig | 3 +
arch/tile/include/asm/kvm_para.h| 20 ++
arch/tile/include/asm/kvm_virtio.h | 26 ++
arch/tile/include/uapi/asm/Kbuild | 1 +
arch/tile/include/uapi/asm/kvm.h| 5 +
arch/tile/include/uapi/asm
ulator notifications within the guest kernel.
The timer interrupt for the guest uses the AUX_TILE_TIMER hardware,
leaving the regular TILE_TIMER for the host.
Signed-off-by: Chris Metcalf
---
arch/tile/Kconfig | 14 +++--
arch/tile/include/asm/module.h | 10 --
arch/til
On 8/26/2013 8:04 AM, Gleb Natapov wrote:
> On Sun, Aug 25, 2013 at 09:26:47PM -0400, Chris Metcalf wrote:
>> On 8/25/2013 7:39 AM, Gleb Natapov wrote:
>>> On Mon, Aug 12, 2013 at 04:24:11PM -0400, Chris Metcalf wrote:
>>>> This change provides the initial frame
> -Original Message-
> From: Gleb Natapov [mailto:g...@redhat.com]
> Sent: Sunday, August 25, 2013 1:52 AM
> To: Chris Leduc
> Cc: kvm@vger.kernel.org
> Subject: Re: Partial huge page backing with KVM/qemu
>
> On Sat, Aug 24, 2013 at 12:32:07AM +, Chris Le
On 8/25/2013 7:39 AM, Gleb Natapov wrote:
> On Mon, Aug 12, 2013 at 04:24:11PM -0400, Chris Metcalf wrote:
>> This change provides the initial framework support for KVM on tilegx.
>> Basic virtual disk and networking is supported.
>>
> This needs to be broken down to mor
line.
Thanks
Chris
--
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 5/16/2013 7:15 AM, Michael S. Tsirkin wrote:
> The only reason uaccess routines might sleep
> is if they fault. Make this explicit.
>
> Signed-off-by: Michael S. Tsirkin
> ---
> arch/tile/include/asm/uaccess.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
cess level virtualization, flexible kernels (e.g. rump anykernel,
view-os, ...)
- virt management (e.g. ganeti, libvirt, ovirt, XCP, ...)"
thanks,
-chris
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info a
resulting in a crash, it seems to me to be a good candidate. The
commit in mainline is aa67f6096c19bcdb1951ef88be3cf3d2118809dc.
Thanks.
Original Message
Subject: Re: [PATCH master/3.5.y] KVM: VMX: Fix ds/es corruption on i386
with preemption
Date: Wed, 01 Aug 2012 15:36:
ightweight exit path.
Reported-by: Chris Clayron
Signed-off-by: Avi Kivity
I've just had 15 successful runs of qemu-kvm-1.1.1 with kernel 3.5.0
plus this patch, so:
Tested-by: Chris Clayton
I assume this will be forwarded to stable once it has been applied to
mainline.
---
arc
On 07/30/12 15:03, Avi Kivity wrote:
On 07/30/2012 05:00 PM, Chris Clayton wrote:
On 07/29/12 20:10, Chris Clayton wrote:
Possible culprit: b2da15ac26a0c00.
That commit isn't in qermu-kvm-1.1.1.
It is in kernel.
Sorry, so it is.
With kernel 3.5.0 with b2da15ac26a0c00 reverted, I
On 07/29/12 20:10, Chris Clayton wrote:
Possible culprit: b2da15ac26a0c00.
That commit isn't in qermu-kvm-1.1.1.
It is in kernel.
Sorry, so it is.
With kernel 3.5.0 with b2da15ac26a0c00 reverted, I have just had 15
clean invocations of vanilla qemu-kvm-1.1.1. So that commit would
On 07/29/12 18:54, Gleb Natapov wrote:
On Sun, Jul 29, 2012 at 06:50:09PM +0100, Chris Clayton wrote:
On 07/29/12 17:34, Avi Kivity wrote:
On 07/29/2012 06:47 PM, Avi Kivity wrote:
What might have happened is that the movdqu instruction faulted (as it's
an fpu instruction), and on th
On 07/29/12 17:34, Avi Kivity wrote:
On 07/29/2012 06:47 PM, Avi Kivity wrote:
What might have happened is that the movdqu instruction faulted (as it's
an fpu instruction), and on the way back from the fault, ds and es
didn't get restored correctly.
You can test this by writing a trivial versio
On 07/29/12 15:48, Avi Kivity wrote:
On 07/29/2012 05:18 PM, Avi Kivity wrote:
I think you are saying that the problem isn't in kvm, so where would you
recommend I continue investigations. I'm not seeing a crash with any
other applications.
What might have happened is that the movdqu instruct
On 07/29/12 13:42, Avi Kivity wrote:
On 07/27/2012 10:04 PM, Chris Clayton wrote:
On 07/27/12 19:08, Eric Northup wrote:
Could you include the output of "info registers" at the point where it
crashed?
Here you go:
Program received signal SIGSEGV, Segmentation fault.
[Switching
82 "apic-common") at qom/object.c:478
#8 0x08192c1b in cpu_set_apic_tpr (d=0x8a313e0, val=13 '\r')
at /home/chris/rpm/BUILD/qemu-kvm-1.1.1/hw/apic_common.c:60
#9 0x081cb86c in kvm_arch_post_run (env=env@entry=0x8a29370,
run=run@entry=0xb6274000)
at /home/chris/rpm/B
On 07/27/12 00:22, Chris Clayton wrote:
On 07/26/12 13:07, Avi Kivity wrote:
On 07/26/2012 02:58 PM, Chris Clayton wrote:
It looks like general memory corruption. Is this repeatable? What's
the guest uptime when it happens (i.e. is it immediate?)
I've just done 10 runs of WinXP
On 07/26/12 13:07, Avi Kivity wrote:
On 07/26/2012 02:58 PM, Chris Clayton wrote:
It looks like general memory corruption. Is this repeatable? What's
the guest uptime when it happens (i.e. is it immediate?)
I've just done 10 runs of WinXP SP3 and 5 of them crashed. Three crashe
On 07/26/12 12:10, Xiao Guangrong wrote:
Hi Chris,
Could you please try this patch?
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commit;h=ccebf448daf7964ee2aff7947c0bbe4c7962d059
Sorry, that patch does not fix the crashes.
On 07/26/2012 05:52 PM, Chris Clayton wrote:
On
On 07/26/12 11:01, Avi Kivity wrote:
On 07/26/2012 12:52 PM, Chris Clayton wrote:
On 07/19/12 19:23, Chris Clayton wrote:
On 07/19/12 13:17, Avi Kivity wrote:
On 07/19/2012 03:14 PM, Chris Clayton wrote:
Change of diagnostics, unfortunately. qemu-kvm-1.0.1 can, in fact,
crash
on 3.5.0-rc6
On 07/19/12 19:23, Chris Clayton wrote:
On 07/19/12 13:17, Avi Kivity wrote:
On 07/19/2012 03:14 PM, Chris Clayton wrote:
Change of diagnostics, unfortunately. qemu-kvm-1.0.1 can, in fact,
crash
on 3.5.0-rc6 (and rc7). I didn't get it earlier because it takes many
times more invoca
On 07/19/12 13:17, Avi Kivity wrote:
On 07/19/2012 03:14 PM, Chris Clayton wrote:
Change of diagnostics, unfortunately. qemu-kvm-1.0.1 can, in fact, crash
on 3.5.0-rc6 (and rc7). I didn't get it earlier because it takes many
times more invocations before the crash occurs with 1.0.1
On 07/15/12 20:52, Chris Clayton wrote:
On 07/11/12 08:22, Gleb Natapov wrote:
On Wed, Jul 11, 2012 at 08:18:17AM +0100, Chris Clayton wrote:
On 07/11/12 08:12, Gleb Natapov wrote:
On Wed, Jul 11, 2012 at 08:09:42AM +0100, Chris Clayton wrote:
Ping.
Have I committed a bug-reporting sin in
On 07/11/12 08:22, Gleb Natapov wrote:
On Wed, Jul 11, 2012 at 08:18:17AM +0100, Chris Clayton wrote:
On 07/11/12 08:12, Gleb Natapov wrote:
On Wed, Jul 11, 2012 at 08:09:42AM +0100, Chris Clayton wrote:
Ping.
Have I committed a bug-reporting sin in the mail below or is
everyone simply too
On 07/11/2012 02:06 PM, Alex Williamson wrote:
On Wed, 2012-07-11 at 13:56 -0600, Chris Friesen wrote:
On 07/11/2012 01:34 PM, Alex Williamson wrote:
The limiting factor to increasing memory slots was searching the array.
That's since been fixed by caching mmio page table entries.
Thank
great.
Chris
--
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
to mainline though.
Is this likely the source of my problem? Why didn't it ever get
submitted to mainline.
What's the proper method of supporting 8 VFs per VM, with possibly
several VMs?
Thanks,
Chris
--
To unsubscribe from this list: send the line "unsubscribe
On 07/11/12 08:12, Gleb Natapov wrote:
On Wed, Jul 11, 2012 at 08:09:42AM +0100, Chris Clayton wrote:
Ping.
Have I committed a bug-reporting sin in the mail below or is
everyone simply too busy to look at this kvm-related crash?
Since you have good and bad points can you bisect the problem
Ping.
Have I committed a bug-reporting sin in the mail below or is everyone
simply too busy to look at this kvm-related crash?
On 07/09/12 11:57, Chris Clayton wrote:
Hi,
When I run WinXP SP3 through qemu-kvm-1.1.0 on linux kernel 3.5.0-rc6, I
get a segmentation fault within 3 or 4 minutes
e not from the same crash
instance.
I'm not subscribed,so please cc me on any reply.
Happy to provide any additional diagnostics (but may need help on how to
get them) or test patches, etc
Thanks
Chris Clayton
--
To unsubscribe from this list: send the line "unsubscribe kvm&qu
ompression Inc iTVC15
MPEG-2 Encoder (rev 01)
Thanks,
Chris
--
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
vice using mplayer, so
> it doesn't seem to get in the way. Stay tuned for vfio upstream.
> Thanks,
>
> Alex
>
What would be the best way to stay up to date on the status of vfio?
Subscribe to this mailing list, or something else?
Chris
--
To unsubscribe from this list: send t
rt command but I'm very close to where I need to be now.
Once I get a few more configurations finished I'll record some shows
for a final test of functionality.
Thank you for your time in assisting me, the vfio drivers are working
exactly as expected so far.
Chris
--
To unsubscribe from
* Natalia Portillo (clau...@claunia.com) wrote:
> QEMU hosted on Haiku would be interesting.
The fun of Haiku
especially when it is
hosting QEMU
--
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://vg
ace, IIUC, so I think it's possible for QEMU
> (or whatever the userspace is) to set the label for the VM while it's
> creating it. I think this is how most of the labeling for X and things of
> that nature works.
For X, the policy enforcement is done in the X server. There is
* Chris Wright (chr...@sous-sol.org) wrote:
> * Hao, Xudong (xudong@intel.com) wrote:
> > Yes, Chris, thanks your comments.
> > How about this one?
>
> Yes, it gets the locking right.
Sorry, I missed one other problem on the error path. You need to also
update pdev-&
* Hao, Xudong (xudong@intel.com) wrote:
> Yes, Chris, thanks your comments.
> How about this one?
Yes, it gets the locking right.
Also makes host device and guest assigned device go through the same order:
alloc_devinfo and init
lock; place info on lists; unlock
domain_context_m
* Hao, Xudong (xudong@intel.com) wrote:
> @@ -2282,6 +2276,14 @@ static int domain_add_dev_info(struct dmar_domain
> *domain,
> pdev->dev.archdata.iommu = info;
> spin_unlock_irqrestore(&device_domain_lock, flags);
>
> + ret = domain_context_mapping(domain, pdev, translation)
* Sridhar Samudrala (s...@us.ibm.com) wrote:
> On 11/30/2011 3:00 PM, Chris Wright wrote:
> >physical port
> > |
> >+++
> >| +-+
* Ben Hutchings (bhutchi...@solarflare.com) wrote:
> On Wed, 2011-11-30 at 13:04 -0800, Chris Wright wrote:
> > I agree that it's confusing. Couldn't you simplify your ascii art
> > (hopefully removing hw assumptions about receive processing, and
> > completely ig
ay not be allowed (setting MAC+port if the VF is owned
by a guest is likely not allowed), but would expect an implicit VF N.
5) VF ndo_set_rx_mode
Same as 4) above.
6) PF or VF? ndo_set_rx_filter_addr
The new proposal, which has an explicit VF, although when it's VF_SELF
I'm not clear
* Peter Zijlstra (a.p.zijls...@chello.nl) wrote:
> On Wed, 2011-11-30 at 21:52 +0530, Dipankar Sarma wrote:
> >
> > Also, if at all topology changes due to migration or host kernel decisions,
> > we can make use of something like VPHN (virtual processor home node)
> > capability on Power systems t
1 - 100 of 695 matches
Mail list logo
