KVM is due to receive support for multiple architectures (ppc, ia64, and
s390, in addition to the existing x86), hopefully in time for the 2.6.25
merge window. It is awkward to place the new arch support in
drivers/kvm/, so I'd like to propose the following new layout:
virt/
Zhang, Xiantao wrote:
Hi, Avi
This series of patches are used to make kvm/ia64 userspace work
in a clean way. In these patches, we have very few code for current
source, except some necessary changes for ia64 target. Current ia64
support doesn't include processor and memory emulation
Avi Kivity wrote:
Zhang, Xiantao wrote:
Hi, Avi
This series of patches are used to make kvm/ia64 userspace work
in a clean way. In these patches, we have very few code for current
source, except some necessary changes for ia64 target. Current ia64
support doesn't include processor and
From: Zhang Xiantao [EMAIL PROTECTED]
Date: Tue, 11 Dec 2007 18:54:27 +0800
Subject: [PATCH] kvm: qemu: Check page size at initialization time.
Currently, we assume Qemu target page size = HOST page
size, this patch check them. if not equal, print error
info and exit.
Signed-off-by: Zhang Xiantao
Hello Rusty,
this is a small fix for virtio_net.
virtnet_probe already calls alloc_etherdev, which calls ether_setup.
There is no need to do that again.
Signed-off-by: Christian Borntraeger [EMAIL PROTECTED]
---
drivers/net/virtio_net.c |1 -
1 file changed, 1 deletion(-)
Index:
Hello Rusty,
while implementing and testing virtio on s390 I found a problem in
virtio_net: The current virtio_net driver has a startup race, which
prevents any incoming traffic:
If try_fill_recv submits buffers to the host system data might be
filled in and an interrupt is sent, before
Zhang, Xiantao wrote:
From: Zhang Xiantao [EMAIL PROTECTED]
Date: Tue, 11 Dec 2007 18:54:27 +0800
Subject: [PATCH] kvm: qemu: Check page size at initialization time.
Currently, we assume Qemu target page size = HOST page
size, this patch check them. if not equal, print error
info and exit.
Christian Borntraeger wrote:
Hello Rusty,
while implementing and testing virtio on s390 I found a problem in
virtio_net: The current virtio_net driver has a startup race, which
prevents any incoming traffic:
If try_fill_recv submits buffers to the host system data might be
filled in and an
This time I send in text so netdev list won't reject it; sorry.
Dor Laor wrote:
Christian Borntraeger wrote:
Hello Rusty,
while implementing and testing virtio on s390 I found a problem in
virtio_net: The current virtio_net driver has a startup race, which
prevents any incoming traffic:
Avi Kivity wrote:
Christian Ehrhardt wrote:
Background:
In our ppc code for the demo we only needed a call to
cpu_physical_memory_rw to handle all kind of mmio we needed. Looking
at all the callback pointers for read/write mmio in kvm_callbacks I
wondered if this can be simplified with
Subject: [PATCH] [1/1] simplify mmio read/write callback structure
From: Christian Ehrhardt [EMAIL PROTECTED]
Merging the read[bwlq]/write[bwlq] callback callback pointers to
mmio_read/write functions simplifies the callback interface.
On the qemu side it now uses the cpu_physical_memory_rw
Hi Ingo, Thomas,
In the latest kernel (2.6.24-rc3) I noticed a drastic performance
decrease for KVM networking.
The reason is many vmexit (exit reason is cpuid instruction) caused by
calls to gettimeofday that uses tsc sourceclock.
read_tsc calls get_cycles_sync which might call cpuid in order
Dor Laor wrote:
Christian Borntraeger wrote:
Hello Rusty,
while implementing and testing virtio on s390 I found a problem in
virtio_net: The current virtio_net driver has a startup race, which
prevents any incoming traffic:
If try_fill_recv submits buffers to the host system data might be
2nd try. I somehow enable html on the last post
Dor Laor wrote:
Christian Borntraeger wrote:
Hello Rusty,
while implementing and testing virtio on s390 I found a problem in
virtio_net: The current virtio_net driver has a startup race, which
prevents any incoming traffic:
If try_fill_recv
Hi, Avi
This series patches are to split kvm structuure. As current
kvm_vcpu does, we also define common fields as a macro, although this
approach is not so elegant. But the advantage is also explict, because
we don't need to change current source code. Anyway, this is not the
best method,
From: Zhang Xiantao [EMAIL PROTECTED]
Date: Tue, 11 Dec 2007 20:45:48 +0800
Subject: [PATCH] kvm: Moving memslot_id to x86.h
Since it is not called in kvm_main.c, and it also will block
kvm structure split, so moved it out.
Signed-off-by: Zhang Xiantao [EMAIL PROTECTED]
---
drivers/kvm/kvm.h |
From: Zhang Xiantao [EMAIL PROTECTED]
Date: Tue, 11 Dec 2007 20:36:00 +0800
Subject: [PATCH] kvm: Moving kvm{pic, ioapic} getting method out.
Since it block kvm split, and it doesn't belong to common code,
so move them out. Meanwhile, kvm_{get, has}_interrupts should
moved to kvm.h
From: Zhang Xiantao [EMAIL PROTECTED]
Date: Tue, 11 Dec 2007 20:47:56 +0800
Subject: [PATCH] kvm: kvm structure split.
Using macro KVM_COMM to hold kvm common fields
as kvm_vcpu does. And, every arch defines its kvm structure
separately.
Signed-off-by: Zhang Xiantao [EMAIL PROTECTED]
---
* Dor Laor [EMAIL PROTECTED] wrote:
Hi Ingo, Thomas,
In the latest kernel (2.6.24-rc3) I noticed a drastic performance
decrease for KVM networking. The reason is many vmexit (exit reason is
cpuid instruction) caused by calls to gettimeofday that uses tsc
sourceclock. read_tsc calls
Am Dienstag, 11. Dezember 2007 schrieb Avi Kivity:
KVM is due to receive support for multiple architectures (ppc, ia64, and
s390, in addition to the existing x86), hopefully in time for the 2.6.25
merge window. It is awkward to place the new arch support in
drivers/kvm/, so I'd like to
Christian Borntraeger wrote:
Am Dienstag, 11. Dezember 2007 schrieb Avi Kivity:
KVM is due to receive support for multiple architectures (ppc, ia64, and
s390, in addition to the existing x86), hopefully in time for the 2.6.25
merge window. It is awkward to place the new arch support in
From: Zhang Xiantao [EMAIL PROTECTED]
Date: Tue, 11 Dec 2007 20:58:41 +0800
Subject: [PATCH] kvm: moving kvm_vm_stat to x86 arch.
Moving kvm_vm_stat to x86.h, since it is x86-specific.
Signed-off-by: Zhang Xiantao [EMAIL PROTECTED]
---
drivers/kvm/kvm.h | 10 --
drivers/kvm/x86.h |
From: Zhang Xiantao [EMAIL PROTECTED]
Date: Tue, 11 Dec 2007 20:56:08 +0800
Subject: [PATCH] kvm: Moving structures wrt mmu to x86.h
Since mmu structure is arch-specific, moving to x86.h
Signed-off-by: Zhang Xiantao [EMAIL PROTECTED]
---
drivers/kvm/kvm.h | 69
From: Zhang Xiantao [EMAIL PROTECTED]
Date: Tue, 11 Dec 2007 21:03:55 +0800
Subject: [PATCH] kvm: Moving some macros to x86.h
Moving macros wrt mmu to x86.h.
Signed-off-by: Zhang Xiantao [EMAIL PROTECTED]
---
drivers/kvm/kvm.h | 20
drivers/kvm/x86.h | 21
Ingo Molnar wrote:
* Dor Laor [EMAIL PROTECTED] wrote:
Hi Ingo, Thomas,
In the latest kernel (2.6.24-rc3) I noticed a drastic performance
decrease for KVM networking. The reason is many vmexit (exit reason is
cpuid instruction) caused by calls to gettimeofday that uses tsc
sourceclock.
Ingo Molnar wrote:
* Dor Laor [EMAIL PROTECTED] wrote:
Hi Ingo, Thomas,
In the latest kernel (2.6.24-rc3) I noticed a drastic performance
decrease for KVM networking. The reason is many vmexit (exit reason is
cpuid instruction) caused by calls to gettimeofday that uses tsc
* Dor Laor [EMAIL PROTECTED] wrote:
Here [include/asm-x86/tsc.h]:
/* Like get_cycles, but make sure the CPU is synchronized. */
static __always_inline cycles_t get_cycles_sync(void)
{
unsigned long long ret;
unsigned eax, edx;
/*
* Use RDTSCP if possible; it is
Joerg Roedel wrote:
This patch is a slightly improved version of a previously submitted patch. It
lets SVM ignore writes of the value 0 to the performance counter control
registers. Thus enabling them will still fail in the guest. This is required
to boot Windows Vista 64bit.
This patch is a slightly improved version of a previously submitted patch. It
lets SVM ignore writes of the value 0 to the performance counter control
registers. Thus enabling them will still fail in the guest. This is required
to boot Windows Vista 64bit.
Signed-off-by: Joerg Roedel [EMAIL
Joerg Roedel wrote:
This patch is a slightly improved version of a previously submitted patch. It
lets SVM ignore writes of the value 0 to the performance counter control
registers. Thus enabling them will still fail in the guest. This is required
to boot Windows Vista 64bit.
Applied,
Ingo Molnar wrote:
* Dor Laor [EMAIL PROTECTED] wrote:
Here [include/asm-x86/tsc.h]:
/* Like get_cycles, but make sure the CPU is synchronized. */
static __always_inline cycles_t get_cycles_sync(void)
{
unsigned long long ret;
unsigned eax, edx;
/*
* Use RDTSCP if
On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
KVM is due to receive support for multiple architectures (ppc, ia64, and
s390, in addition to the existing x86), hopefully in time for the 2.6.25
merge window. It is awkward to place the new arch support in drivers/kvm/,
so I'd
Am Dienstag, 11. Dezember 2007 schrieb Christian Borntraeger:
The way other physical NICs doing it is by dis/en/abling interrupt
using registers (look at e1000).
I suggest we can export add_status and use the original code but
before enabling napi add a call to add_status(dev,
Heiko Carstens wrote:
On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
KVM is due to receive support for multiple architectures (ppc, ia64, and
s390, in addition to the existing x86), hopefully in time for the 2.6.25
merge window. It is awkward to place the new arch support
On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
KVM is due to receive support for multiple architectures (ppc, ia64, and
s390, in addition to the existing x86), hopefully in time for the 2.6.25
merge window. It is awkward to place the new arch support in
drivers/kvm/, so I'd
Sam Ravnborg wrote:
On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
KVM is due to receive support for multiple architectures (ppc, ia64, and
s390, in addition to the existing x86), hopefully in time for the 2.6.25
merge window. It is awkward to place the new arch support in
On Tue, 11 Dec 2007 15:27:17 +0100
Ingo Molnar [EMAIL PROTECTED] wrote:
* Dor Laor [EMAIL PROTECTED] wrote:
The patch below should resolve this - could you please test and Ack
it? But this CPUID was present in v2.6.23 too, so why did it only
show up in 2.6.24-rc for you?
isn't this
* Arjan van de Ven [EMAIL PROTECTED] wrote:
* Dor Laor [EMAIL PROTECTED] wrote:
The patch below should resolve this - could you please test and Ack
it? But this CPUID was present in v2.6.23 too, so why did it only
show up in 2.6.24-rc for you?
isn't this probably wrong since this
On Tue, Dec 11, 2007 at 06:15:40PM +0200, Avi Kivity wrote:
Sam Ravnborg wrote:
On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
KVM is due to receive support for multiple architectures (ppc, ia64, and
s390, in addition to the existing x86), hopefully in time for the 2.6.25
Sam Ravnborg wrote:
So use arch/*/virt/kvm/ if kvm really requires
a subdirectory of it own. Preferably not.
A handful of files named kvm* does not warrant their own
subdirectory IMO.
We'll have 5-6 x86 specific files.
Where do you suggest we place them?
/arch/x86/virt/
On Tue, 2007-12-11 at 19:42 +0200, Avi Kivity wrote:
Are there any dependencies between the arch and non-arch files
such as they are combined in a single module?
Yes, they are combined into a single module.
In the case of x86, some of arch/x86/... will be combined with
virt/kvm/ to
This patch changes the order in which interrupts are injected when the
in-kernel APIC is disabled. Now the IRQ with the highest priority is injected
first.
Signed-off-by: Joerg Roedel [EMAIL PROTECTED]
Signed-off-by: Markus Rechberger [EMAIL PROTECTED]
---
drivers/kvm/svm.c |4 ++--
1 files
3 files changed, 61 insertions(+), 6 deletions(-)
smbios.c | 58 --
sysemu.h |1 +
vl.c |8
# HG changeset patch
# User Ryan Harper [EMAIL PROTECTED]
# Date 1197402122 21600
# Node ID
3 files changed, 38 insertions(+), 2 deletions(-)
Makefile.target |5 -
configure | 26 ++
smbios.c|9 -
# HG changeset patch
# User Ryan Harper [EMAIL PROTECTED]
# Date 1197402122 21600
# Node ID 115f40a4994be1d5b44ef193b3ccbe8e26410eef
#
5 files changed, 749 insertions(+), 3 deletions(-)
Makefile.target |4
hw/pc.c | 45
smbios.c| 517 +++
smbios_types.h | 182 +++
sysemu.h|4
# HG changeset patch
# User Ryan Harper [EMAIL
This patchset introduces SMBIOS/DMI table generation to qemu for PC machines.
The intial patch includes all changes needed to create the tables and load
them into memory. This patch depends on libuuid. The subsequent patches
detect for libuuid and optionally link to the library if present. The
* Ingo Molnar [EMAIL PROTECTED] wrote:
Which is not on core2 which was the question about. And if it was
turned off it wouldn't use get_cycles_sync() at all.
it is turned off on core2 too:
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
acpi_pm
but you are
On Tue, Dec 11, 2007 at 03:27:17PM +0100, Ingo Molnar wrote:
* Dor Laor [EMAIL PROTECTED] wrote:
Here [include/asm-x86/tsc.h]:
/* Like get_cycles, but make sure the CPU is synchronized. */
static __always_inline cycles_t get_cycles_sync(void)
{
unsigned long long ret;
On Tuesday 11 December 2007, Avi Kivity wrote:
Heiko Carstens wrote:
On Tue, Dec 11, 2007 at 11:47:39AM +0200, Avi Kivity wrote:
arch/*/kvm/ arch dependent kvm code
Maybe arch/*/virt/ ? No need to add an own directory for each hypervisor.
There will be several kvm files in
Christian Borntraeger wrote:
Am Dienstag, 11. Dezember 2007 schrieb Christian Borntraeger:
The way other physical NICs doing it is by dis/en/abling interrupt
using registers (look at e1000).
I suggest we can export add_status and use the original code but
before enabling napi add a call
On Mon, Dec 10, 2007 at 07:07:54PM +0200, Avi Kivity wrote:
Marcelo Tosatti wrote:
There is a race where VCPU0 is shadowing a pagetable entry while VCPU1
is updating it, which results in a stale shadow copy.
Fix that by comparing the contents of the cached guest pte with the
current guest
-* Don't do an additional sync on CPUs where we know
-* RDTSC is already synchronous:
+* Use RDTSC on other CPUs. This might not be fully synchronous,
+* but it's not a problem: the only coherency we care about is
+* the GTOD output to user-space, and
On Tuesday 11 December 2007 22:38:53 Christian Borntraeger wrote:
Hello Rusty,
this is a small fix for virtio_net.
virtnet_probe already calls alloc_etherdev, which calls ether_setup.
There is no need to do that again.
Signed-off-by: Christian Borntraeger [EMAIL PROTECTED]
Acked-by: Rusty
On Wednesday 12 December 2007 00:16:12 Christian Borntraeger wrote:
That would also work. We already have VRING_AVAIL_F_NO_INTERRUPT in
virtio_ring.c - maybe we can use that. Its hidden in callback and
restart handling, what about adding an explicit startup?
Yes, I debated whether to make this
G'day folks.
Apologies if this is a FAQ. Is there any way to get Windbg working between
two Windows guests? I have recently switched from QEMU+KQEMU to QEMU/KVM
(better speed and a Vista-ready BIOS got me interested). I never did get
Windbg working at all with QEMU+KQEMU. Now I am rather closer
Am Mittwoch, 12. Dezember 2007 schrieb Rusty Russell:
Can you send straight to akpm or davem? I'm supposed to be on vacation at
this is a small fix for virtio_net.
virtnet_probe already calls alloc_etherdev, which calls ether_setup.
There is no need to do that again.
Signed-off-by: Christian
56 matches
Mail list logo
