On Thu, Feb 9, 2012 at 7:08 PM, Peter Lieven p...@dlh.net wrote:
Hi,
is anyone aware if there are still problems when enabling the threaded vnc
server?
I saw some VMs crashing when using a qemu-kvm build with
--enable-vnc-thread.
qemu-kvm-1.0[22646]: segfault at 0 ip 7fec1ca7ea0b sp
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka jan.kis...@siemens.com wrote:
As we have thread-local cpu_single_env now and KVM uses exactly one
thread per VCPU, we can drop the cpu_single_env updates from the loop
and initialize this variable only once during setup.
I don't think this is correct.
On 2012-02-11 11:02, Blue Swirl wrote:
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka jan.kis...@siemens.com wrote:
As we have thread-local cpu_single_env now and KVM uses exactly one
thread per VCPU, we can drop the cpu_single_env updates from the loop
and initialize this variable only once during
https://bugzilla.kernel.org/show_bug.cgi?id=42755
--- Comment #4 from Rosen sandik...@yandex.ru 2012-02-11 10:50:46 ---
Still no response there ..
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are watching
On Sat, Feb 11, 2012 at 10:06, Jan Kiszka jan.kis...@web.de wrote:
On 2012-02-11 11:02, Blue Swirl wrote:
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka jan.kis...@siemens.com wrote:
As we have thread-local cpu_single_env now and KVM uses exactly one
thread per VCPU, we can drop the cpu_single_env
Am 10.02.2012 19:31, schrieb Jan Kiszka:
Always add a byte before the final 512-bytes alignment to reserve the
space for the ROM checksum.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
pc-bios/optionrom/optionrom.h |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
Am 11.02.2012 12:25, schrieb Blue Swirl:
I think using cpu_single_env is an indication of a problem, like poor
code, layering violation or poor API (vmport). What is your use case?
I couldn't spot any in this series. Jan, note that any new use of env or
cpu_single_env will need to be redone
On 2012-02-11 12:25, Blue Swirl wrote:
On Sat, Feb 11, 2012 at 10:06, Jan Kiszka jan.kis...@web.de wrote:
On 2012-02-11 11:02, Blue Swirl wrote:
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka jan.kis...@siemens.com wrote:
As we have thread-local cpu_single_env now and KVM uses exactly one
thread
On 2012-02-11 12:49, Andreas Färber wrote:
Am 11.02.2012 12:25, schrieb Blue Swirl:
I think using cpu_single_env is an indication of a problem, like poor
code, layering violation or poor API (vmport). What is your use case?
I couldn't spot any in this series. Jan, note that any new use of
On 2012-02-11 12:46, Andreas Färber wrote:
Am 10.02.2012 19:31, schrieb Jan Kiszka:
Always add a byte before the final 512-bytes alignment to reserve the
space for the ROM checksum.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
pc-bios/optionrom/optionrom.h |3 ++-
1 files
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 11.02.2012 13:45, schrieb Jan Kiszka:
On 2012-02-11 12:46, Andreas Färber wrote:
Am 10.02.2012 19:31, schrieb Jan Kiszka:
Always add a byte before the final 512-bytes alignment to
reserve the space for the ROM checksum.
Signed-off-by: Jan
On 2012-02-11 13:51, Andreas Färber wrote:
Am 11.02.2012 13:45, schrieb Jan Kiszka:
On 2012-02-11 12:46, Andreas Färber wrote:
Am 10.02.2012 19:31, schrieb Jan Kiszka:
Always add a byte before the final 512-bytes alignment to
reserve the space for the ROM checksum.
Signed-off-by: Jan Kiszka
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 11.02.2012 13:43, schrieb Jan Kiszka:
On 2012-02-11 12:49, Andreas Färber wrote:
Am 11.02.2012 12:25, schrieb Blue Swirl:
I think using cpu_single_env is an indication of a problem,
like poor code, layering violation or poor API (vmport). What
On 2012-02-11 14:06, Andreas Färber wrote:
Am 11.02.2012 13:43, schrieb Jan Kiszka:
On 2012-02-11 12:49, Andreas Färber wrote:
Am 11.02.2012 12:25, schrieb Blue Swirl:
I think using cpu_single_env is an indication of a problem,
like poor code, layering violation or poor API (vmport). What
is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 11.02.2012 14:07, schrieb Jan Kiszka:
On 2012-02-11 14:06, Andreas Färber wrote:
Am 11.02.2012 13:43, schrieb Jan Kiszka:
On 2012-02-11 12:49, Andreas Färber wrote:
Am 11.02.2012 12:25, schrieb Blue Swirl:
I think using cpu_single_env is an
On 2012-02-11 14:21, Andreas Färber wrote:
Am 11.02.2012 14:07, schrieb Jan Kiszka:
On 2012-02-11 14:06, Andreas Färber wrote:
Am 11.02.2012 13:43, schrieb Jan Kiszka:
On 2012-02-11 12:49, Andreas Färber wrote:
Am 11.02.2012 12:25, schrieb Blue Swirl:
I think using cpu_single_env is an
On Sat, Feb 11, 2012 at 12:43, Jan Kiszka jan.kis...@web.de wrote:
On 2012-02-11 12:49, Andreas Färber wrote:
Am 11.02.2012 12:25, schrieb Blue Swirl:
I think using cpu_single_env is an indication of a problem, like poor
code, layering violation or poor API (vmport). What is your use case?
I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 11.02.2012 14:35, schrieb Jan Kiszka:
On 2012-02-11 14:21, Andreas Färber wrote:
CPU base class v3: http://patchwork.ozlabs.org/patch/139284/ (v4
coming up)
That doesn't prevent target-specific devices. Although Paolo does
want that to
On 2012-02-11 14:54, Blue Swirl wrote:
On Sat, Feb 11, 2012 at 12:43, Jan Kiszka jan.kis...@web.de wrote:
On 2012-02-11 12:49, Andreas Färber wrote:
Am 11.02.2012 12:25, schrieb Blue Swirl:
I think using cpu_single_env is an indication of a problem, like poor
code, layering violation or poor
On 2012-02-11 14:59, Andreas Färber wrote:
Am 11.02.2012 14:35, schrieb Jan Kiszka:
On 2012-02-11 14:21, Andreas Färber wrote:
CPU base class v3: http://patchwork.ozlabs.org/patch/139284/ (v4
coming up)
That doesn't prevent target-specific devices. Although Paolo does
want that to change
On Sat, Feb 11, 2012 at 14:00, Jan Kiszka jan.kis...@web.de wrote:
On 2012-02-11 14:54, Blue Swirl wrote:
On Sat, Feb 11, 2012 at 12:43, Jan Kiszka jan.kis...@web.de wrote:
On 2012-02-11 12:49, Andreas Färber wrote:
Am 11.02.2012 12:25, schrieb Blue Swirl:
I think using cpu_single_env is an
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 11.02.2012 15:02, schrieb Jan Kiszka:
On 2012-02-11 14:59, Andreas Färber wrote:
Am 11.02.2012 14:35, schrieb Jan Kiszka:
On 2012-02-11 14:21, Andreas Färber wrote:
CPU base class v3: http://patchwork.ozlabs.org/patch/139284/
(v4 coming up)
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka jan.kis...@siemens.com wrote:
In order to perform critical manipulations on the VM state in the
context of a VCPU, specifically code patching, stopping and resuming of
all VCPUs may be necessary. resume_all_vcpus is already compatible, now
enable
On 2012-02-11 15:11, Blue Swirl wrote:
On Sat, Feb 11, 2012 at 14:00, Jan Kiszka jan.kis...@web.de wrote:
On 2012-02-11 14:54, Blue Swirl wrote:
On Sat, Feb 11, 2012 at 12:43, Jan Kiszka jan.kis...@web.de wrote:
On 2012-02-11 12:49, Andreas Färber wrote:
Am 11.02.2012 12:25, schrieb Blue
On 2012-02-11 15:12, Andreas Färber wrote:
Am 11.02.2012 15:02, schrieb Jan Kiszka:
On 2012-02-11 14:59, Andreas Färber wrote:
Am 11.02.2012 14:35, schrieb Jan Kiszka:
On 2012-02-11 14:21, Andreas Färber wrote:
CPU base class v3: http://patchwork.ozlabs.org/patch/139284/
(v4 coming up)
On 2012-02-11 15:16, Blue Swirl wrote:
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka jan.kis...@siemens.com wrote:
In order to perform critical manipulations on the VM state in the
context of a VCPU, specifically code patching, stopping and resuming of
all VCPUs may be necessary. resume_all_vcpus
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka jan.kis...@siemens.com wrote:
This will allow the APIC core to file a TPR access report. Depending on
the accelerator and kernel irqchip mode, it will either be delivered
right away or queued for later reporting.
In TCG mode, we can restart the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 11.02.2012 15:24, schrieb Jan Kiszka:
On 2012-02-11 15:12, Andreas Färber wrote:
Am 11.02.2012 15:02, schrieb Jan Kiszka:
On 2012-02-11 14:59, Andreas Färber wrote:
Am 11.02.2012 14:35, schrieb Jan Kiszka:
On 2012-02-11 14:21, Andreas Färber
On 02/10/2012 11:22 PM, Marc Zyngier wrote:
+ENTRY(__kvm_tlb_flush_vmid)
+ hvc #0 @ Switch to Hyp mode
+ push{r2, r3}
+ ldrdr2, r3, [r0, #KVM_VTTBR]
+ mcrrp15, 6, r2, r3, c2 @ Write VTTBR
+ isb
+ mcr p15, 0, r0,
On Fri, Feb 10, 2012 at 18:31, Jan Kiszka jan.kis...@siemens.com wrote:
This enables acceleration for MMIO-based TPR registers accesses of
32-bit Windows guest systems. It is mostly useful with KVM enabled,
either on older Intel CPUs (without flexpriority feature, can also be
manually disabled
On Sat, Feb 11, 2012 at 7:00 AM, Antonios Motakis
a.mota...@virtualopensystems.com wrote:
On 02/10/2012 11:22 PM, Marc Zyngier wrote:
+ENTRY(__kvm_tlb_flush_vmid)
+ hvc #0 @ Switch to Hyp mode
+ push {r2, r3}
+ ldrd r2, r3, [r0, #KVM_VTTBR]
On 02/11/2012 06:35 PM, Christoffer Dall wrote:
On Sat, Feb 11, 2012 at 7:00 AM, Antonios Motakis
a.mota...@virtualopensystems.com wrote:
On 02/10/2012 11:22 PM, Marc Zyngier wrote:
+ENTRY(__kvm_tlb_flush_vmid)
+ hvc #0 @ Switch to Hyp mode
+ push{r2,
On Fri, Feb 10, 2012 at 03:28:31PM +0900, Takuya Yoshikawa wrote:
Other threads may process the same page in that small window and skip
TLB flush and then return before these functions do flush.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
virt/kvm/kvm_main.c | 19
On Sat, Feb 11, 2012 at 10:33 AM, Antonios Motakis
a.mota...@virtualopensystems.com wrote:
On 02/11/2012 06:35 PM, Christoffer Dall wrote:
On Sat, Feb 11, 2012 at 7:00 AM, Antonios Motakis
a.mota...@virtualopensystems.com wrote:
On 02/10/2012 11:22 PM, Marc Zyngier wrote:
Avi Kivity a...@redhat.com wrote:
Slot searching is quite fast since there's a small number of slots, and
we sort the larger ones to be in the front, so positive lookups are fast.
We cache negative lookups in the shadow page tables (an spte can be
either not mapped, mapped to
Avi Kivity a...@redhat.com wrote:
Slot searching is quite fast since there's a small number of slots, and
we sort the larger ones to be in the front, so positive lookups are fast.
We cache negative lookups in the shadow page tables (an spte can be
either not mapped, mapped to
36 matches
Mail list logo
