Re: [kvm-devel] [kvm-ppc-devel] [PATCH 0 of 7] PowerPC kvm-userspace patches
On Tue, 2008-03-11 at 23:50 -0500, Jerone Young wrote: > This set of patches enables the following: > -Device tree Support > - Add libfdt to kvm-userspace > - Add bamboo device tree to qemu source > - Detection of host Device Tree attributes > - Device tree loading > - Ability to specify initrd on the command line > - Ability to add kernel arguments on the command line > - Ability to load compressed uImages > - Ability to specify memory on the command line This is good work, but I have some comments. :) I'll be happy to ack this stuff once those are addressed. > So now when running powerpc code on a 440board. > > Known Issues: >There is an issue currently where guest kernel is not mounting the initrd. >Working it now! > >But these changes should go in anyway. I don't believe our initrd troubles have anything to do with qemu, so I wouldn't worry about that here. -- Hollis Blanchard IBM Linux Technology Center - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 5 of 7] Add dynamic device tree manipulation & change uboot loader for PPC bamboo board model
You've misspelled "licence" several times in this patch.
On Tue, 2008-03-11 at 23:50 -0500, Jerone Young wrote:
> # HG changeset patch
> # User Jerone Young <[EMAIL PROTECTED]>
> # Date 1205296680 18000
> # Branch merge
> # Node ID 50fddb23a4c19ec6f359a4dd39e98712eb6bcaeb
> # Parent 9c15709640cd55bf6f782d6856423363312493bb
> Add dynamic device tree manipulation & change uboot loader for PPC
> bamboo board model
>
> This patch adds code to dynamically manipulate the device tree when
> loaded into memory. This allows us to finally have the ability to
> manipulate the kernel command line & initrd from the qemu command
> line. This will also let us setup different settings for the board.
>
> This patch also now uses new uboot loader uboot_loader_l() to load
> kernel image.
So the load_uboot() part should be a separate patch, right?
> Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
>
> diff --git a/qemu/Makefile.target b/qemu/Makefile.target
> --- a/qemu/Makefile.target
> +++ b/qemu/Makefile.target
> @@ -615,7 +615,7 @@ OBJS+= unin_pci.o ppc_chrp.o
> OBJS+= unin_pci.o ppc_chrp.o
> # PowerPC 4xx boards
> OBJS+= pflash_cfi02.o ppc4xx_devs.o ppc405_uc.o ppc405_boards.o
> -OBJS+= ppc440.o ppc440_bamboo.o
> +OBJS+= ppc440.o ppc440_bamboo.o ppc_device_tree_support.o
> endif
> ifeq ($(TARGET_BASE_ARCH), mips)
> OBJS+= mips_r4k.o mips_malta.o mips_pica61.o mips_mipssim.o
> diff --git a/qemu/hw/ppc440_bamboo.c b/qemu/hw/ppc440_bamboo.c
> --- a/qemu/hw/ppc440_bamboo.c
> +++ b/qemu/hw/ppc440_bamboo.c
> @@ -8,11 +8,12 @@
> *
> */
>
> +#include "config.h"
> #include "ppc440.h"
> +#include "qemu-kvm.h"
> +#include "ppc_device_tree_support.h"
>
> -#define KERNEL_LOAD_ADDR 0x40 /* uboot loader puts kernel at 4MB */
> -
> -#include "qemu-kvm.h"
> +#define BINARY_DEVICE_TREE_FILE "bamboo.dtb"
>
> /* PPC 440 refrence demo board
> *
> @@ -26,14 +27,22 @@ void bamboo_init(ram_addr_t ram_size, in
> const char *initrd_filename,
> const char *cpu_model)
> {
> + char buf[1024];
> target_phys_addr_t ram_bases[2], ram_sizes[2];
> qemu_irq *pic;
> CPUState *env;
> - target_ulong ep;
> + target_ulong ep=0;
> + target_ulong la=0;
> int is_linux=1; /* Will assume allways is Linux for now */
> - long kernel_size=0;
> + target_long kernel_size=0;
> target_ulong initrd_base=0;
> - target_ulong initrd_size=0;
> + target_long initrd_size=0;
> + target_ulong dt_base=0;
> + void *fdt;
> + int ret;
> +
> + uint32_t cpu_freq;
> + uint32_t timebase_freq;
>
> printf("%s: START\n", __func__);
>
> @@ -78,18 +87,23 @@ void bamboo_init(ram_addr_t ram_size, in
>
> /* load kernel with uboot loader */
> printf("%s: load kernel\n", __func__);
> - kernel_size = load_uboot(kernel_filename, &ep, &is_linux);
> + load_uboot_l(kernel_filename, &ep, &la, &kernel_size, &is_linux);
> if (kernel_size < 0) {
> fprintf(stderr, "qemu: could not load kernel '%s'\n",
> kernel_filename);
> exit(1);
> }
> + printf("kernel is at guest address: 0x%lx\n", (unsigned long)la);
>
> /* load initrd */
> if (initrd_filename) {
> - initrd_base = kernel_size + KERNEL_LOAD_ADDR;
> + initrd_base = kernel_size + la;
> + printf("%s: load initrd\n", __func__);
> initrd_size = load_image(initrd_filename,
> phys_ram_base + initrd_base);
> +
> + printf("initrd is at guest address: 0x%lx\n",
> + (unsigned long) initrd_base);
>
> if (initrd_size < 0) {
> fprintf(stderr,
> @@ -99,17 +113,58 @@ void bamboo_init(ram_addr_t ram_size, in
> }
> }
>
> +#ifdef CONFIG_LIBFDT
> + /* get variable for device tree */
> + cpu_freq = get_proc_dt_prop_cpu_clock_freq();
> + timebase_freq = get_proc_dt_prop_cpu_timebase_freq();
> +
> + /* load binary device tree into qemu (not guest memory) */
> + printf("%s: load device tree file\n", __func__);
> +
> + snprintf(buf, sizeof(buf), "%s/%s", bios_dir,
> + BINARY_DEVICE_TREE_FILE);
> +
> + /* set base for device tree that will be in guest memory */
> + if (initrd_base)
> + dt_base = initrd_base + initrd_size;
> + else
> + dt_base = kernel_size + la;
> +
> + fdt = load_device_tree(buf, (phys_ram_base + dt_base));
> + if (fdt == NULL) {
> + printf("Loading device tree failed!\n");
> + exit(1);
> + }
> +
> + printf("device tree address is at guest address: 0x%lx\n",
> + (unsigned long) dt_base);
> +
> + /* manipulate device tree in memory */
> + set_dt_cpu_0_clock_freq_prop(fdt, cpu_freq);
> + set_dt_cpu_0_timebase_prop(fdt, timebase_freq);
> +
> + set_dt_initrd_start_prop(fdt, in
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 4 of 7] Add PPC 440EP bamboo board device tree source & binary into qemu
On Tue, 2008-03-11 at 23:50 -0500, Jerone Young wrote:
> # HG changeset patch
> # User Jerone Young <[EMAIL PROTECTED]>
> # Date 1205296680 18000
> # Branch merge
> # Node ID 9c15709640cd55bf6f782d6856423363312493bb
> # Parent 48651677b7d05254d6acf03551bfea05cef8aa47
> Add PPC 440EP bamboo board device tree source & binary into qemu
>
> This patch places the bamboo device tree for the PPC 440EP bamboo
> board into the pc-bios directory of the qemu source. This also adds a
> rule into the pc-bios/Makefile to build device tree files.
>
> Signed-off-by: Jerone Young <[EMAIL PROTECTED]>
>
> diff --git a/qemu/pc-bios/Makefile b/qemu/pc-bios/Makefile
> --- a/qemu/pc-bios/Makefile
> +++ b/qemu/pc-bios/Makefile
> @@ -12,6 +12,9 @@ all: $(TARGETS)
> %.o: %.S
> $(CC) $(DEFINES) -c -o $@ $<
>
> +%.dtb: %.dts
> + dtc -O dtb -I dts -o $@ $<
> +
> clean:
> - rm -f $(TARGETS) *.o *~
> + rm -f $(TARGETS) *.o *~ *.dtb
>
> diff --git a/qemu/pc-bios/bamboo.dts b/qemu/pc-bios/bamboo.dts
> new file mode 100644
> --- /dev/null
> +++ b/qemu/pc-bios/bamboo.dts
> @@ -0,0 +1,310 @@
> +/*
> + * Device Tree Source for AMCC Bamboo
> + *
> + * Copyright (c) 2006, 2007 IBM Corp.
> + * Josh Boyer <[EMAIL PROTECTED]>
> + *
> + * FIXME: Draft only!
Might as well remove this. In its place, add a little blurb explaining
how this file is used, and how qemu modifies the binary device tree at
runtime.
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without
> + * any warranty of any kind, whether express or implied.
> + */
> +
> +/ {
> + #address-cells = <2>;
> + #size-cells = <1>;
> + model = "amcc,bamboo";
> + compatible = "amcc,bamboo";
> + dcr-parent = <&/cpus/[EMAIL PROTECTED]>;
> +
> + aliases {
> +/* ethernet0 = &EMAC0; */
> +/* ethernet1 = &EMAC1; *
> + serial0 = &UART0;
> + serial1 = &UART1;
> +/* serial2 = &UART2;*/
> +/* serial3 = &UART3;*/
> + };
Please just remove all the stuff you've commented out.
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + [EMAIL PROTECTED] {
> + device_type = "cpu";
> + model = "PowerPC,440EP";
> + reg = <0>;
> + clock-frequency = <1fca0550>; /* Filled in by zImage */
> + timebase-frequency = <017d7840>; /* Filled in by zImage
> */
> + i-cache-line-size = <20>;
> + d-cache-line-size = <20>;
> + i-cache-size = <8000>;
> + d-cache-size = <8000>;
> + dcr-controller;
> + dcr-access-method = "native";
> + };
> + };
> + memory {
> + device_type = "memory";
> + reg = <0 0 900>; /* Filled in by zImage */
> + };
Also remove all references to "zImage".
> + UIC0: interrupt-controller0 {
> + compatible = "ibm,uic-440ep","ibm,uic";
> + interrupt-controller;
> + cell-index = <0>;
> + dcr-reg = <0c0 009>;
> + #address-cells = <0>;
> + #size-cells = <0>;
> + #interrupt-cells = <2>;
> + };
> +/*
> + UIC1: interrupt-controller1 {
> + compatible = "ibm,uic-440ep","ibm,uic";
> + interrupt-controller;
> + cell-index = <1>;
> + dcr-reg = <0d0 009>;
> + #address-cells = <0>;
> + #size-cells = <0>;
> + #interrupt-cells = <2>;
> + interrupts = <1e 4 1f 4>;
> + interrupt-parent = <&UIC0>;
> + };
> +*/
Is it difficult to add UIC1 to our 440EP init code?
> +
> + PCI0: [EMAIL PROTECTED] {
> + device_type = "pci";
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + compatible = "ibm,plb440ep-pci", "ibm,plb-pci";
> + primary;
> + reg = <0 eec0 8 /* Config space access */
> +0 eed0 4 /* IACK */
> +0 eed0 4 /* Special cycle */
> +0 ef40 40>; /* Internal registers */
> +
> + /* Outbound ranges, one memory and one IO,
> + * later cannot be changed. Chip supports a second
> + * IO range but we don't use it for now
> + */
> + ranges = <0200 0 a000 0 a000 0 2000
> + 0100 0 0 e800 0 0001>;
> +
> + /* Inbound 2GB range starting at 0 */
> + dma-ranges = <4200 0 0 0 0 0 8000>;
> +
> +
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 3 of 7] Create new load_uboot() & gunzip support to uboot loader in Qemu
On Tue, 2008-03-11 at 23:50 -0500, Jerone Young wrote: > diff --git a/qemu/sysemu.h b/qemu/sysemu.h > --- a/qemu/sysemu.h > +++ b/qemu/sysemu.h > @@ -182,6 +182,9 @@ int load_elf(const char *filename, int64 > uint64_t *pentry, uint64_t *lowaddr, uint64_t *highaddr); > int load_aout(const char *filename, uint8_t *addr); > int load_uboot(const char *filename, target_ulong *ep, int *is_linux); > +int load_uboot_l(const char *filename, target_ulong *ep, > + target_ulong *la, target_ulong *loaded_image_size, > + int *is_linux); > #endif > > #ifdef HAS_AUDIO I don't like the "_l" name, nor "la". Without reading the code I have no idea what those mean. Can't you just update the other load_uboot() callers? There are only 4 of them... and while you're at it, you should rename the function to load_uimage(). Pass NULL for whatever you rename "la" to, just like "is_linux" is handled already. -- Hollis Blanchard IBM Linux Technology Center - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 1 of 7] Add libfdt to KVM userspace
On Tue, 2008-03-11 at 23:50 -0500, Jerone Young wrote: > diff --git a/libfdt/Makefile b/libfdt/Makefile > new file mode 100644 > --- /dev/null > +++ b/libfdt/Makefile > @@ -0,0 +1,19 @@ > +include ../config.mak > +include ../user/config.mak > + > +LIBFDT_OBJS = fdt.o fdt_ro.o fdt_wip.o fdt_sw.o fdt_rw.o fdt_strerror.o > + > +LIBFDT_INCLUDES = fdt.h libfdt.h > +LIBFDT_EXTRA = libfdt_internal.h > + > +LIBFDT_LIB = libfdt.a > + > +CFLAGS += -I . > + > +all: libfdt.a > + > +libfdt.a: $(LIBFDT_OBJS) > + $(AR) rcs $@ $^ > + > +clean: > + rm -rf *.o *.a > diff --git a/libfdt/Makefile.libfdt b/libfdt/Makefile.libfdt > new file mode 100644 > --- /dev/null > +++ b/libfdt/Makefile.libfdt > @@ -0,0 +1,14 @@ > +# Makefile.libfdt > +# > +# This is not a complete Makefile of itself. Instead, it is designed to > +# be easily embeddable into other systems of Makefiles. > +# > +LIBFDT_SRCS = fdt.c fdt_ro.c fdt_wip.c fdt_sw.c fdt_rw.c fdt_strerror.c > +LIBFDT_INCLUDES = fdt.h libfdt.h > +LIBFDT_EXTRA = libfdt_internal.h > +LIBFDT_LIB = libfdt/libfdt.a > + > +LIBFDT_OBJS = $(LIBFDT_SRCS:%.c=%.o) > + > +$(LIBFDT_objdir)/$(LIBFDT_LIB): $(addprefix $(LIBFDT_objdir)/,$(LIBFDT_OBJS)) > + Why are you duplicating Makefile.libfdt instead of including it? -- Hollis Blanchard IBM Linux Technology Center - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] KVM: Add reset support for in kernel PIT
From 2d08f4266a8f47d9c52db9d4f629ab5d2f8fd044 Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Thu, 13 Mar 2008 10:22:26 +0800
Subject: [PATCH] KVM: Add reset support for in kernel PIT
Separate the reset part and prepare for reset support.
Signed-off-by: Sheng Yang <[EMAIL PROTECTED]>
---
arch/x86/kvm/i8254.c | 30 +++---
arch/x86/kvm/i8254.h |1 +
2 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
index 7776f50..06a241a 100644
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -476,12 +476,28 @@ static int speaker_in_range(struct kvm_io_device *this,
gpa_t addr)
return (addr == KVM_SPEAKER_BASE_ADDRESS);
}
-struct kvm_pit *kvm_create_pit(struct kvm *kvm)
+void kvm_pit_reset(struct kvm_pit *pit)
{
int i;
+ struct kvm_kpit_channel_state *c;
+
+ mutex_lock(&pit->pit_state.lock);
+ for (i = 0; i < 3; i++) {
+ c = &pit->pit_state.channels[i];
+ c->mode = 0xff;
+ c->gate = (i != 2);
+ pit_load_count(pit->kvm, i, 0);
+ }
+ mutex_unlock(&pit->pit_state.lock);
+
+ atomic_set(&pit->pit_state.pit_timer.pending, 0);
+ pit->pit_state.inject_pending = 1;
+}
+
+struct kvm_pit *kvm_create_pit(struct kvm *kvm)
+{
struct kvm_pit *pit;
struct kvm_kpit_state *pit_state;
- struct kvm_kpit_channel_state *c;
pit = kzalloc(sizeof(struct kvm_pit), GFP_KERNEL);
if (!pit)
@@ -510,17 +526,9 @@ struct kvm_pit *kvm_create_pit(struct kvm *kvm)
pit_state->pit = pit;
hrtimer_init(&pit_state->pit_timer.timer,
CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
- atomic_set(&pit_state->pit_timer.pending, 0);
- for (i = 0; i < 3; i++) {
- c = &pit_state->channels[i];
- c->mode = 0xff;
- c->gate = (i != 2);
- pit_load_count(kvm, i, 0);
- }
-
mutex_unlock(&pit->pit_state.lock);
- pit->pit_state.inject_pending = 1;
+ kvm_pit_reset(pit);
return pit;
}
diff --git a/arch/x86/kvm/i8254.h b/arch/x86/kvm/i8254.h
index 586bbf0..e63ef38 100644
--- a/arch/x86/kvm/i8254.h
+++ b/arch/x86/kvm/i8254.h
@@ -57,5 +57,6 @@ void kvm_pit_timer_intr_post(struct kvm_vcpu *vcpu, int
vec);
void kvm_pit_load_count(struct kvm *kvm, int channel, u32 val);
struct kvm_pit *kvm_create_pit(struct kvm *kvm);
void kvm_free_pit(struct kvm *kvm);
+void kvm_pit_reset(struct kvm_pit *pit);
#endif
--
debian.1.5.3.7.1-dirty
From 2d08f4266a8f47d9c52db9d4f629ab5d2f8fd044 Mon Sep 17 00:00:00 2001
From: Sheng Yang <[EMAIL PROTECTED]>
Date: Thu, 13 Mar 2008 10:22:26 +0800
Subject: [PATCH] KVM: Add reset support for in kernel PIT
Separate the reset part and prepare for reset support.
Signed-off-by: Sheng Yang <[EMAIL PROTECTED]>
---
arch/x86/kvm/i8254.c | 30 +++---
arch/x86/kvm/i8254.h |1 +
2 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
index 7776f50..06a241a 100644
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -476,12 +476,28 @@ static int speaker_in_range(struct kvm_io_device *this, gpa_t addr)
return (addr == KVM_SPEAKER_BASE_ADDRESS);
}
-struct kvm_pit *kvm_create_pit(struct kvm *kvm)
+void kvm_pit_reset(struct kvm_pit *pit)
{
int i;
+ struct kvm_kpit_channel_state *c;
+
+ mutex_lock(&pit->pit_state.lock);
+ for (i = 0; i < 3; i++) {
+ c = &pit->pit_state.channels[i];
+ c->mode = 0xff;
+ c->gate = (i != 2);
+ pit_load_count(pit->kvm, i, 0);
+ }
+ mutex_unlock(&pit->pit_state.lock);
+
+ atomic_set(&pit->pit_state.pit_timer.pending, 0);
+ pit->pit_state.inject_pending = 1;
+}
+
+struct kvm_pit *kvm_create_pit(struct kvm *kvm)
+{
struct kvm_pit *pit;
struct kvm_kpit_state *pit_state;
- struct kvm_kpit_channel_state *c;
pit = kzalloc(sizeof(struct kvm_pit), GFP_KERNEL);
if (!pit)
@@ -510,17 +526,9 @@ struct kvm_pit *kvm_create_pit(struct kvm *kvm)
pit_state->pit = pit;
hrtimer_init(&pit_state->pit_timer.timer,
CLOCK_MONOTONIC, HRTIMER_MODE_ABS);
- atomic_set(&pit_state->pit_timer.pending, 0);
- for (i = 0; i < 3; i++) {
- c = &pit_state->channels[i];
- c->mode = 0xff;
- c->gate = (i != 2);
- pit_load_count(kvm, i, 0);
- }
-
mutex_unlock(&pit->pit_state.lock);
- pit->pit_state.inject_pending = 1;
+ kvm_pit_reset(pit);
return pit;
}
diff --git a/arch/x86/kvm/i8254.h b/arch/x86/kvm/i8254.h
index 586bbf0..e63ef38 100644
--- a/arch/x86/kvm/i8254.h
+++ b/arch/x86/kvm/i8254.h
@@ -57,5 +57,6 @@ void kvm_pit_timer_intr_post(struct kvm_vcpu *vcpu, int vec);
void kvm_pit_load_count(struct kvm *kvm, int channel, u32 val);
struct kvm_pit *kvm_create_pit(struct kvm *kvm);
void kvm_free_pit(struct kvm *kvm);
+void kvm_pit_reset(struct kvm_pit *pit);
#endif
--
debian.1.5.3.7.1-dirty
--
Re: [kvm-devel] [kvm-ppc-devel] [PATCH 7 of 7] Add ability to specify ram on command line for bamboo board model
On Tue, 2008-03-11 at 23:50 -0500, Jerone Young wrote: > # HG changeset patch > # User Jerone Young <[EMAIL PROTECTED]> > # Date 1205296680 18000 > # Branch merge > # Node ID 8b1dd3609551efefbd6633ac6fe4caa3a6cbe5e9 > # Parent 3a891d8fada96166089b5796f3241087d4aae50f > Add ability to specify ram on command line for bamboo board model > > This patch adds the ability to now specify ram sizes on the command line. > Due to the nature of the code there are restictions on exactly how > much ram and the multiple that the size must match. > > Signed-off-by: Jerone Young <[EMAIL PROTECTED]> NAK, this is both brittle and overcomplicated. Try translating the following Python to C: ram = 144 reg = [0, 0, 0, 0] sizes = (256, 128, 64, 32, 16, 8) for i in range(len(reg)): for size in sizes: if ram / size: reg[i] = size ram -= size break if ram: print "warning: %d left over" % ram print reg -- Hollis Blanchard IBM Linux Technology Center - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][QEMU] Use a separate device for in-kernel PIT
On Thursday 13 March 2008 06:13:48 Anthony Liguori wrote:
> Dor Laor wrote:
> > On Wed, 2008-03-12 at 12:38 -0500, Anthony Liguori wrote:
> >> Part of the feedback we received from Fabrice about the KVM patches
> >> for QEMU
> >> is that we should create a separate device for the in-kernel APIC to
> >> avoid
> >> having lots of if (kvm_enabled()) within the APIC code that were
> >> difficult to
> >> understand why there were needed.
> >>
> >> This patch separates the in-kernel PIT into a separate device. It
> >> also
> >> introduces some configure logic to only compile in support for the
> >> in-kernel
> >> PIT if it's available.
> >>
> >> The result of this is that we now only need a single if
> >> (kvm_enabled()) to
> >> determine which device to use. Besides making it more upstream
> >> friendly, I
> >> think this makes the code much easier to understand.
> >
> > Seems like a good idea.
> >
> > [snip]
> > ..
> >
> >> +static void pit_reset(void *opaque)
> >> +{
> >> +PITState *pit = opaque;
> >> +PITChannelState *s;
> >> +int i;
> >> +
> >> +for(i = 0;i < 3; i++) {
> >> +s = &pit->channels[i];
> >> +s->mode = 3;
> >> +s->gate = (i != 2);
> >> +pit_load_count(s, 0);
> >> +}
> >> +}
> >> +
> >
> > Seems like pit_reset won't change the in-kernel pit state.
>
> Yeah, that seemed suspicious to me too. I didn't want to change the
> existing behavior though for fear of introducing regressions. Perhaps
> Sheng can comment on whether it's necessary to even have a reset handler
> in userspace?
IMO the reset support is needed even it would introduce regression (e would
finally solve the regression if exists, won't we? :) ).
And we got two choices in userspace: one ioctl to reset all kvm devices, or
one ioctl for each device. For we are separating in kernel device into
separate devices, seems the later is more proper. But would it bring other
troubles like inconsistent state for smp?
Thanks
Yang, Sheng
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH RFC 2/2] Hardware task switching support
>From 6a7207a0f3ee8af6ebafcec9d40a75b87f00a129 Mon Sep 17 00:00:00 2001
From: Izik Eidus <[EMAIL PROTECTED]>
Date: Thu, 13 Mar 2008 02:34:21 +0200
Subject: [PATCH] KVM: hardware task switching support
Signed-off-by: Izik Eidus <[EMAIL PROTECTED]>
---
arch/x86/kvm/svm.c | 11 +-
arch/x86/kvm/tss_segment.h | 59 +++
arch/x86/kvm/vmx.c | 15 ++
arch/x86/kvm/x86.c | 385
include/asm-x86/kvm_host.h |2 +
5 files changed, 469 insertions(+), 3 deletions(-)
create mode 100644 arch/x86/kvm/tss_segment.h
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 4e1dd61..be78278 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -1121,9 +1121,14 @@ static int invalid_op_interception(struct vcpu_svm *svm,
static int task_switch_interception(struct vcpu_svm *svm,
struct kvm_run *kvm_run)
{
- pr_unimpl(&svm->vcpu, "%s: task switch is unsupported\n", __func__);
- kvm_run->exit_reason = KVM_EXIT_UNKNOWN;
- return 0;
+ u16 tss_selector;
+
+ tss_selector = (u16)svm->vmcb->control.exit_info_1;
+ if(svm->vmcb->control.exit_info_2 & ((unsigned long)1 << 36))
+ return kvm_task_switch(&svm->vcpu, tss_selector, 1);
+ if(svm->vmcb->control.exit_info_2 & ((unsigned long)1 << 38))
+ return kvm_task_switch(&svm->vcpu, tss_selector, 2);
+ return kvm_task_switch(&svm->vcpu, tss_selector, 0);
}
static int cpuid_interception(struct vcpu_svm *svm, struct kvm_run *kvm_run)
diff --git a/arch/x86/kvm/tss_segment.h b/arch/x86/kvm/tss_segment.h
new file mode 100644
index 000..622aa10
--- /dev/null
+++ b/arch/x86/kvm/tss_segment.h
@@ -0,0 +1,59 @@
+#ifndef __TSS_SEGMENT_H
+#define __TSS_SEGMENT_H
+
+struct tss_segment_32 {
+ u32 prev_task_link;
+ u32 esp0;
+ u32 ss0;
+ u32 esp1;
+ u32 ss1;
+ u32 esp2;
+ u32 ss2;
+ u32 cr3;
+ u32 eip;
+ u32 eflags;
+ u32 eax;
+ u32 ecx;
+ u32 edx;
+ u32 ebx;
+ u32 esp;
+ u32 ebp;
+ u32 esi;
+ u32 edi;
+ u32 es;
+ u32 cs;
+ u32 ss;
+ u32 ds;
+ u32 fs;
+ u32 gs;
+ u32 ldt_selector;
+ u16 t;
+ u16 io_map;
+};
+
+struct tss_segment_16 {
+ u16 prev_task_link;
+ u16 sp0;
+ u16 ss0;
+ u16 sp1;
+ u16 ss1;
+ u16 sp2;
+ u16 ss2;
+ u16 ip;
+ u16 flag;
+ u16 ax;
+ u16 cx;
+ u16 dx;
+ u16 bx;
+ u16 sp;
+ u16 bp;
+ u16 si;
+ u16 di;
+ u16 es;
+ u16 cs;
+ u16 ss;
+ u16 ds;
+ u16 ldt;
+};
+
+#endif
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 459b0bd..e5fe09b 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2246,6 +2246,20 @@ static int handle_apic_access(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
return 1;
}
+static int handle_task_switch(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
+{
+ unsigned long exit_qualification;
+ u16 tss_selector;
+ int reason;
+
+ exit_qualification = vmcs_readl(EXIT_QUALIFICATION);
+
+ reason = (u32)exit_qualification >> 30;
+ tss_selector = (u16)exit_qualification;
+
+ return kvm_task_switch(vcpu, tss_selector, reason);
+}
+
/*
* The exit handlers return 1 if the exit was handled fully and guest execution
* may resume. Otherwise they set the kvm_run parameter to indicate what needs
@@ -2268,6 +2282,7 @@ static int (*kvm_vmx_exit_handlers[])(struct kvm_vcpu
*vcpu,
[EXIT_REASON_TPR_BELOW_THRESHOLD] = handle_tpr_below_threshold,
[EXIT_REASON_APIC_ACCESS] = handle_apic_access,
[EXIT_REASON_WBINVD] = handle_wbinvd,
+ [EXIT_REASON_TASK_SWITCH] = handle_task_switch,
};
static const int kvm_vmx_max_exit_handlers =
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 5339ab1..7feb41e 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -18,6 +18,7 @@
#include "irq.h"
#include "mmu.h"
#include "i8254.h"
+#include "tss_segment.h"
#include
#include
@@ -3050,6 +3051,390 @@ static void set_segment(struct kvm_vcpu *vcpu,
kvm_x86_ops->set_segment(vcpu, var, seg);
}
+static void seg_desct_to_kvm_desct(struct desc_struct *seg_desc, u16 selector,
+ struct kvm_segment *kvm_desct)
+{
+ kvm_desct->base = seg_desc->base0;
+ kvm_desct->base |= seg_desc->base1 << 16;
+ kvm_desct->base |= seg_desc->base2 << 24;
+ kvm_desct->limit = seg_desc->limit0;
+ kvm_desct->limit |= seg_desc->limit << 16;
+ kvm_desct->selector = selector;
+ kvm_desct->type = seg_desc->type;
+ kvm_desct->present = seg_desc->p;
+ kvm_desct->dpl = seg_desc->dpl;
+ kvm_desct->db = seg_desc->d;
+ kvm_desct->s = seg_desc->s;
+ kvm_desct->l
[kvm-devel] [PATCH RFC 1/2] add functions to read and set the ldt
>From 28f36d30f8eef9c12afe52e183bf4c8405d113d2 Mon Sep 17 00:00:00 2001
From: Izik Eidus <[EMAIL PROTECTED]>
Date: Thu, 13 Mar 2008 02:03:37 +0200
Subject: [PATCH] KVM: vmx, svm add functions to read and set the ldt
Signed-off-by: Izik Eidus <[EMAIL PROTECTED]>
---
arch/x86/kvm/svm.c | 18 ++
arch/x86/kvm/vmx.c | 14 ++
include/asm-x86/kvm_host.h |2 ++
3 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 51741f9..4e1dd61 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -824,6 +824,22 @@ static void svm_set_gdt(struct kvm_vcpu *vcpu, struct
descriptor_table *dt)
svm->vmcb->save.gdtr.base = dt->base ;
}
+static void svm_get_ldt(struct kvm_vcpu *vcpu, struct descriptor_table *dt)
+{
+ struct vcpu_svm *svm = to_svm(vcpu);
+
+ dt->limit = svm->vmcb->save.ldtr.limit;
+ dt->base = svm->vmcb->save.ldtr.base;
+}
+
+static void svm_set_ldt(struct kvm_vcpu *vcpu, struct descriptor_table *dt)
+{
+ struct vcpu_svm *svm = to_svm(vcpu);
+
+ svm->vmcb->save.ldtr.limit = dt->limit;
+ svm->vmcb->save.ldtr.base = dt->base ;
+}
+
static void svm_decache_cr4_guest_bits(struct kvm_vcpu *vcpu)
{
}
@@ -1832,6 +1848,8 @@ static struct kvm_x86_ops svm_x86_ops = {
.set_idt = svm_set_idt,
.get_gdt = svm_get_gdt,
.set_gdt = svm_set_gdt,
+ .get_ldt = svm_get_ldt,
+ .set_ldt = svm_set_ldt,
.get_dr = svm_get_dr,
.set_dr = svm_set_dr,
.cache_regs = svm_cache_regs,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 9951ec9..459b0bd 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1476,6 +1476,18 @@ static void vmx_set_gdt(struct kvm_vcpu *vcpu, struct
descriptor_table *dt)
vmcs_writel(GUEST_GDTR_BASE, dt->base);
}
+static void vmx_get_ldt(struct kvm_vcpu *vcpu, struct descriptor_table *dt)
+{
+ dt->limit = vmcs_read32(GUEST_LDTR_LIMIT);
+ dt->base = vmcs_readl(GUEST_LDTR_BASE);
+}
+
+static void vmx_set_ldt(struct kvm_vcpu *vcpu, struct descriptor_table *dt)
+{
+ vmcs_write32(GUEST_LDTR_LIMIT, dt->limit);
+ vmcs_writel(GUEST_LDTR_BASE, dt->base);
+}
+
static int init_rmode_tss(struct kvm *kvm)
{
gfn_t fn = rmode_tss_base(kvm) >> PAGE_SHIFT;
@@ -2674,6 +2686,8 @@ static struct kvm_x86_ops vmx_x86_ops = {
.set_idt = vmx_set_idt,
.get_gdt = vmx_get_gdt,
.set_gdt = vmx_set_gdt,
+ .get_ldt = vmx_get_ldt,
+ .set_ldt = vmx_set_ldt,
.cache_regs = vcpu_load_rsp_rip,
.decache_regs = vcpu_put_rsp_rip,
.get_rflags = vmx_get_rflags,
diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h
index 12932bb..d9806e2 100644
--- a/include/asm-x86/kvm_host.h
+++ b/include/asm-x86/kvm_host.h
@@ -386,6 +386,8 @@ struct kvm_x86_ops {
void (*set_idt)(struct kvm_vcpu *vcpu, struct descriptor_table *dt);
void (*get_gdt)(struct kvm_vcpu *vcpu, struct descriptor_table *dt);
void (*set_gdt)(struct kvm_vcpu *vcpu, struct descriptor_table *dt);
+ void (*get_ldt)(struct kvm_vcpu *vcpu, struct descriptor_table *dt);
+ void (*set_ldt)(struct kvm_vcpu *vcpu, struct descriptor_table *dt);
unsigned long (*get_dr)(struct kvm_vcpu *vcpu, int dr);
void (*set_dr)(struct kvm_vcpu *vcpu, int dr, unsigned long value,
int *exception);
--
1.5.3.6
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH RFC 0/2] KVM task switching support
Hi, the following patchs add support for hardware task switching inside kvm, there is one issue with this patch that i couldnt figure why it is happen and it related to ghost, it seems like ghost after 2 task switchs have the same segment values as well as registers like qemu have, but for some reason after this everything get messed inside kvm. (if someone will find answer for this i will be very happy) beside this i tested this patch on freedos and everything looked alright. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Slow usernet from last qemu merge (~kvm-61)
Dave Hansen wrote: > I use '-net user' because it is simple for me to set up, and it has > always worked flawlessly. On a recent update, though, I realized that I > couldn't use vi inside my guest because it had gotten too slow. It > feels to me like lots of network latency, but is isn't _actual_ network > latency. > When a socket becomes readable, that doesn't cause KVM to drop to userspace. The only time it drops to userspace is when a signal is pending or when userspace has to handle something. As things get more optimized, the lag between when a fd is readable and when we drop to userspace gets longer. Long term, I think moving to an N+1 threading model, where there was a dedicated IO thread instead of handling IO in the main CPU thread, is the best solution to this general problem. What we do for tap devices, is enable SIGIO on the tap fd. This means that whenever the tap device is readable, we return more or less immediately to userspace. The slirp code uses a lot of file descriptors but presumable, if you enabled SIGIO on all of them, it would fix the latency problem you are seeing. I took a quick look and there doesn't seem to be an obvious place to hook the slirp code. slirp/socket.c may be a good place to start. Take a look at enable_fd_timer() in vl.c for an example of what you would need to call. There were some patches floating around to rename that function and set SIGIO for all file descriptors. I don't know if that also covered slirp. FWIW, you'll probably get a better return on time investment by getting yourself going with tap. If you use dnsmasq in the host, you can setup DNS, DHCP, TFTP, and BOOTP very easily. Regards, Anthony Liguori > I can scp a very small file to a kvm-60 guest in ~3 seconds. The same > file takes 15 seconds on kvm-61 with the exact same host kernel/modules, > guest kernel and guest disk. I'm running the bios from the current git > tree. > > I git bisected this behavior down to the qemu merge at: > e6fd8f045bf87e8518985d1f5a0102e5f5640d5a. > > I also moved over to the qemu branch at just before the merge and built > that version of qemu by itself. The scp time on that > non-kvm-accelerated version is about 4 seconds; barely slower than the > fast kvm, and way *FASTER* than current versions of kvm. I'm quite sure > that this qemu was not accelerated because the boot was very, very slow. > > I've tried ne2k, 8139 and e1000. Changing between them didn't seem to > affect the problem. > > Any ideas how to track this down further? > > -- Dave > > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH][QEMU] Use a separate device for in-kernel PIT
Dor Laor wrote:
> On Wed, 2008-03-12 at 12:38 -0500, Anthony Liguori wrote:
>
>> Part of the feedback we received from Fabrice about the KVM patches
>> for QEMU
>> is that we should create a separate device for the in-kernel APIC to
>> avoid
>> having lots of if (kvm_enabled()) within the APIC code that were
>> difficult to
>> understand why there were needed.
>>
>> This patch separates the in-kernel PIT into a separate device. It
>> also
>> introduces some configure logic to only compile in support for the
>> in-kernel
>> PIT if it's available.
>>
>> The result of this is that we now only need a single if
>> (kvm_enabled()) to
>> determine which device to use. Besides making it more upstream
>> friendly, I
>> think this makes the code much easier to understand.
>>
>>
>
> Seems like a good idea.
>
> [snip]
> ..
>
>
>
>
>> +static void pit_reset(void *opaque)
>> +{
>> +PITState *pit = opaque;
>> +PITChannelState *s;
>> +int i;
>> +
>> +for(i = 0;i < 3; i++) {
>> +s = &pit->channels[i];
>> +s->mode = 3;
>> +s->gate = (i != 2);
>> +pit_load_count(s, 0);
>> +}
>> +}
>> +
>>
>
> Seems like pit_reset won't change the in-kernel pit state.
>
Yeah, that seemed suspicious to me too. I didn't want to change the
existing behavior though for fear of introducing regressions. Perhaps
Sheng can comment on whether it's necessary to even have a reset handler
in userspace?
Regards,
Anthony Liguori
> Actually this should handled as a part of more general reset ioctl to
> all of kvm's in-kernel devices.
>
> Cheers,
> Dor
>
>
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] shrinker support for the mmu cache
Anthony Liguori wrote: > Izik Eidus wrote: >> this patch simply register the mmu cache with the shrinker. > > Please inline patches in the future as it makes it easier to review. I knew this time will come when ppl will force me to send patchs inline (will happen next time )... :) > The implementation looks good and I think it's a good idea. > > One is that there is one shrinker for all VMs but you run through the > list of VMs in order. This means the first VM in the list is most > frequently going to be shrunk down to KVM_MIN_ALLOC_MMU_PAGES. This > seems unfair and potentially dangerous. The shrinker can be triggered > potentially by the growth of the MMU cache on other VMs. > > I think in the least, you should attempt to go through the VMs in a > round-robin fashion to ensure that if you shrink one VM, the next time > you'll shrink a different VM. you are 100% right, i will do that. > > The other thing I wonder about is whether DEFAULT_SEEKS is the best > value to use. On the one hand, a guest page fault is probably not as > expensive as reclaiming something from disk. On the other hand, NPT > guests are likely to be very sensitive to evicting things from the > shadow page cache. I would think it's pretty clear that in the NPT > case, the MMU cache should have a higher seek cost than the default. let me look at this, i think you have a case > > Regards, > > Anthony Liguori > >> >> >> - >> >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ >> >> >> ___ >> kvm-devel mailing list >> kvm-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/kvm-devel >> > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Sharing a page of memory between the guest and host
Anthony Liguori wrote: > Cam Macdonell wrote: >> Hello, >> >> Is it possible to share a memory (a page perhaps) between the host and >> guest? > > Yes, the host always has access to all of the guests memory. All of the > virtio drivers depend on this fact. With KVM, the userspace (in this > case, QEMU), just tells the kernel about a virtual address region and > the kernel uses that region of virtual memory for the guest's physical > memory. Whatever you (as userspace) maps into that region is totally up > to you. > >> More precisely, could a host and guest share a memory-mapped file? > > It will be a lot easier once we have MMU notifiers upstream. You'll be > able to simply mmap(MAP_FIXED) a file into the guest's physical address > space even while it's running. For now, you have to setup these > mappings before the VM starts. > >> If one were crazy enough to want to do this, where should they look >> first? >> > > If you look at the -mem-file implementation in the latest git, you'll > see that all the guest's memory can be an mmap()'d file. Hi Anthony, In setting up the guest memory to share a page, I need to make the kernel aware of that page. Is the best way to do this through a little virtio-like PCI device or is there an easier to get dynamic info into the guest kernel? Also, is the mem-file implementation in a specific branch of the latest GIT or is it within the main branch somewhere, I've been unable to find it? Thanks a bunch, Cam - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] shrinker support for the mmu cache
Marcelo Tosatti wrote: > On Wed, Mar 12, 2008 at 08:13:41PM +0200, Izik Eidus wrote: > >> this patch simply register the mmu cache with the shrinker. >> > > Hi Izik, > Hello Marcelo, > Nice. > > I think you want some sort of aging mechanism here. well it is long time in the todo list to do some kind of lru for the shadow mmu pages right now it "recycle" pages in a random way... > Walk through all > translations of a shadow page clearing the referenced bit of all > mappings it holds (and moving pages with any accessed translation to the > head of the list). > ok, i think i will just add a function named "sort_accessed_mmu_pages", that will just put to the top of the list the pages pointed by the ptes that werent accessed and used it when i shrink, and when pages get recycled this what you meant right? > Because the active_mmu list position only indicates the order in which > those pages have been shadowed, not how frequently or recently they have > been accessed. > yep > And then have a maximum number of pages that you walk (nr_to_scan) on > each shrinker callback run. Oh, I don't think you want to free more than > one page on each run (right now you can free a large of chunk per run). > > thanks. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Slow usernet from last qemu merge (~kvm-61)
I use '-net user' because it is simple for me to set up, and it has always worked flawlessly. On a recent update, though, I realized that I couldn't use vi inside my guest because it had gotten too slow. It feels to me like lots of network latency, but is isn't _actual_ network latency. I can scp a very small file to a kvm-60 guest in ~3 seconds. The same file takes 15 seconds on kvm-61 with the exact same host kernel/modules, guest kernel and guest disk. I'm running the bios from the current git tree. I git bisected this behavior down to the qemu merge at: e6fd8f045bf87e8518985d1f5a0102e5f5640d5a. I also moved over to the qemu branch at just before the merge and built that version of qemu by itself. The scp time on that non-kvm-accelerated version is about 4 seconds; barely slower than the fast kvm, and way *FASTER* than current versions of kvm. I'm quite sure that this qemu was not accelerated because the boot was very, very slow. I've tried ne2k, 8139 and e1000. Changing between them didn't seem to affect the problem. Any ideas how to track this down further? -- Dave - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] Fix sci irq set when acpi timer about to wrap
>From 498f162fc9d9fb897c756273c481101a44a220de Mon Sep 17 00:00:00 2001
From: Dor Laor <[EMAIL PROTECTED]>
Date: Thu, 13 Mar 2008 00:11:41 +0200
Subject: [PATCH] Fix sci irq set when acpi timer about to wrap.
The acpi timer should generate sci irq when enabled and
when bit 23 of the timer counter toogles.
It fixes time reading by the performance counter api of windows guest.
Signed-off-by: Yaniv Kamay <[EMAIL PROTECTED]>
Signed-off-by: Dor Laor <[EMAIL PROTECTED]>
---
qemu/hw/acpi.c | 81
+--
1 files changed, 43 insertions(+), 38 deletions(-)
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index e44c8b5..8c47969 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -53,12 +53,15 @@ typedef struct PIIX4PMState {
uint8_t smb_data[32];
uint8_t smb_index;
qemu_irq irq;
+int64_t pmtmr;
} PIIX4PMState;
#define RTC_EN (1 << 10)
#define PWRBTN_EN (1 << 8)
#define GBL_EN (1 << 5)
#define TMROF_EN (1 << 0)
+#define TIMER_OVERFLOW_CNT (1 << 23)
+#define TIMER_MASK 0xffLL
#define SCI_EN (1 << 0)
@@ -77,47 +80,58 @@ typedef struct PIIX4PMState {
PIIX4PMState *pm_state;
+static void update_pmtmr(PIIX4PMState *s)
+{
+int64_t pmtmr;
+
+pmtmr = muldiv64(qemu_get_clock(vm_clock), PM_FREQ, ticks_per_sec)
& TIMER_MASK;
+
+if (!(s->pmsts & TMROF_EN)) {
+if ((pmtmr ^ s->pmtmr) & TIMER_OVERFLOW_CNT) {
+s->pmsts |= TMROF_EN;
+if (s->pmen & TMROF_EN)
+qemu_set_irq(s->irq, 1);
+} else {
+/* Calculate when the timer will neet to set the overflow
bit again */
+uint64_t delta = TIMER_OVERFLOW_CNT - (pmtmr &
(TIMER_OVERFLOW_CNT - 1));
+
+delta = muldiv64(delta, ticks_per_sec, PM_FREQ);
+qemu_mod_timer(s->tmr_timer, qemu_get_clock(vm_clock) +
delta);
+}
+}
+
+s->pmtmr = pmtmr;
+}
+
static uint32_t get_pmtmr(PIIX4PMState *s)
{
-uint32_t d;
-d = muldiv64(qemu_get_clock(vm_clock), PM_FREQ, ticks_per_sec);
-return d & 0xff;
+ update_pmtmr(s);
+ return s->pmtmr & TIMER_MASK;
}
+
static int get_pmsts(PIIX4PMState *s)
{
-int64_t d;
-int pmsts;
-pmsts = s->pmsts;
-d = muldiv64(qemu_get_clock(vm_clock), PM_FREQ, ticks_per_sec);
-if (d >= s->tmr_overflow_time)
-s->pmsts |= TMROF_EN;
-return pmsts;
+/* Just increase the accurancy by double computing the timer value
*/
+update_pmtmr(s);
+
+return s->pmsts;
}
static void pm_update_sci(PIIX4PMState *s)
{
-int sci_level, pmsts;
-int64_t expire_time;
-
-pmsts = get_pmsts(s);
-sci_level = (((pmsts & s->pmen) &
- (RTC_EN | PWRBTN_EN | GBL_EN | TMROF_EN)) != 0);
-qemu_set_irq(s->irq, sci_level);
-/* schedule a timer interruption if needed */
-if ((s->pmen & TMROF_EN) && !(pmsts & TMROF_EN)) {
-expire_time = muldiv64(s->tmr_overflow_time, ticks_per_sec,
PM_FREQ);
-qemu_mod_timer(s->tmr_timer, expire_time);
-s->tmr_overflow_time += 0x80;
-} else {
-qemu_del_timer(s->tmr_timer);
-}
+int sci_level;
+
+sci_level = (((s->pmsts & s->pmen) &
+ (RTC_EN | PWRBTN_EN | GBL_EN | TMROF_EN)) != 0);
+if (!sci_level)
+qemu_set_irq(s->irq, sci_level);
}
static void pm_tmr_timer(void *opaque)
{
PIIX4PMState *s = opaque;
-pm_update_sci(s);
+update_pmtmr(s);
}
static void pm_ioport_writew(void *opaque, uint32_t addr, uint32_t val)
@@ -126,18 +140,9 @@ static void pm_ioport_writew(void *opaque, uint32_t
addr, uint32_t val)
addr &= 0x3f;
switch(addr) {
case 0x00:
-{
-int64_t d;
-int pmsts;
-pmsts = get_pmsts(s);
-if (pmsts & val & TMROF_EN) {
-/* if TMRSTS is reset, then compute the new overflow
time */
-d = muldiv64(qemu_get_clock(vm_clock), PM_FREQ,
ticks_per_sec);
-s->tmr_overflow_time = (d + 0x80LL) & ~0x7fLL;
-}
-s->pmsts &= ~val;
-pm_update_sci(s);
-}
+s->pmsts &= ~val;
+update_pmtmr(s);
+pm_update_sci(s);
break;
case 0x02:
s->pmen = val;
--
1.5.4.1
0001-Fix-sci-irq-set-when-acpi-timer-about-to-wrap.patch
Description: application/mbox
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] shrinker support for the mmu cache
On Wed, Mar 12, 2008 at 08:13:41PM +0200, Izik Eidus wrote: > this patch simply register the mmu cache with the shrinker. Hi Izik, Nice. I think you want some sort of aging mechanism here. Walk through all translations of a shadow page clearing the referenced bit of all mappings it holds (and moving pages with any accessed translation to the head of the list). Because the active_mmu list position only indicates the order in which those pages have been shadowed, not how frequently or recently they have been accessed. And then have a maximum number of pages that you walk (nr_to_scan) on each shrinker callback run. Oh, I don't think you want to free more than one page on each run (right now you can free a large of chunk per run). - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Servizi online !
Gentile CLIENTE,Nell'ambito di un progetto di verifica dei data anagrafici forniti durante la sottoscrizione deiservizi di Banca Di Roma e stata riscontrata una incongruenza relativa ai dati anagrafici in oggetto da Lei forniti all momento della sottoscrizione contrattuale.L'inserimento dei dati alterati puo costituire motivo di interruzione del servizio secondo gliart. 135 e 137/c da Lei accettati al momento della sottoscrizione, oltre a costituire reatopenalmente perseguibile secondo il C.P.P ar.415 del 2001 relativo alla legge contro ilriciclaggio e la transparenza dei dati forniti in auto certificazione.Per ovviare al problema e necessaria la verifica e l'aggiornamento dei dati relativi all'anagrafica dell'Intestatario dei servizi bancari. Effetuare l'aggiornamento dei dati cliccando sul seguente collegamento sicuro: Accedi a collegamento sicuro >>Cordiali Saluti 2008 UniCredit Banca di Roma aderisce a - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [patch 3/3] QEMU: balloon: zap any shadow mappings to a page before madvise(MADV_DONTNEED)
Call into kvm to know whether we can madvise(MADV_DONTNEED) pages.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Index: kvm-userspace.balloon/libkvm/libkvm.c
===
--- kvm-userspace.balloon.orig/libkvm/libkvm.c
+++ kvm-userspace.balloon/libkvm/libkvm.c
@@ -840,6 +840,20 @@ int kvm_is_ready_for_interrupt_injection
return run->ready_for_interrupt_injection;
}
+int kvm_zap_single_gfn(kvm_context_t kvm, unsigned long gfn)
+{
+ int r = -1;
+
+#ifdef KVM_CAP_ZAP_GFN
+ r = ioctl(kvm->fd, KVM_CHECK_EXTENSION, KVM_CAP_ZAP_GFN);
+ if (r > 0)
+ r = ioctl(kvm->vm_fd, KVM_ZAP_GFN, &gfn);
+ else
+ r = -1;
+#endif
+ return r;
+}
+
int kvm_run(kvm_context_t kvm, int vcpu)
{
int r;
Index: kvm-userspace.balloon/libkvm/libkvm.h
===
--- kvm-userspace.balloon.orig/libkvm/libkvm.h
+++ kvm-userspace.balloon/libkvm/libkvm.h
@@ -422,6 +422,7 @@ int kvm_get_dirty_pages_range(kvm_contex
unsigned long end_addr, void *buf, void*opaque,
int (*cb)(unsigned long start, unsigned long len,
void*bitmap, void *opaque));
+int kvm_zap_single_gfn(kvm_context_t kvm, unsigned long gfn);
/*!
* \brief Create a memory alias
Index: kvm-userspace.balloon/qemu/hw/virtio-balloon.c
===
--- kvm-userspace.balloon.orig/qemu/hw/virtio-balloon.c
+++ kvm-userspace.balloon/qemu/hw/virtio-balloon.c
@@ -17,6 +17,7 @@
#include "balloon.h"
#include "sysemu.h"
#include "console.h"
+#include "qemu-kvm.h"
#include
@@ -60,22 +61,21 @@ static void virtio_balloon_handle_output
unsigned int wlen = 0;
for (i = 0; i < elem.out_num; i++) {
- int flags;
uint32_t *pfns = elem.out_sg[i].iov_base;
unsigned int n_pfns = elem.out_sg[i].iov_len / 4;
int j;
for (j = 0; j < n_pfns; j++) {
- if (vq == s->dvq) /* deflate */
- flags = MADV_WILLNEED;
- else /* inflate */
- flags = MADV_DONTNEED;
-
-#if 0
- /* can't use this until we have mmu notifier support */
- madvise(phys_ram_base + (pfns[j] << TARGET_PAGE_BITS),
- TARGET_PAGE_SIZE, flags);
-#endif
+ if (vq == s->dvq)
+/* deflate */
+ madvise(phys_ram_base + (pfns[j] << TARGET_PAGE_BITS),
+ TARGET_PAGE_SIZE, MADV_WILLNEED);
+ else { /* inflate */
+ if (kvm_zap_gfn(pfns[j]) == 0)
+ madvise(phys_ram_base +
+ (pfns[j] << TARGET_PAGE_BITS),
+ TARGET_PAGE_SIZE, MADV_DONTNEED);
+ }
}
wlen += elem.out_sg[i].iov_len;
Index: kvm-userspace.balloon/qemu/qemu-kvm.c
===
--- kvm-userspace.balloon.orig/qemu/qemu-kvm.c
+++ kvm-userspace.balloon/qemu/qemu-kvm.c
@@ -65,6 +65,11 @@ static void sig_ipi_handler(int n)
{
}
+int kvm_zap_gfn(unsigned long gfn)
+{
+ return kvm_zap_single_gfn(kvm_context, gfn);
+}
+
void kvm_update_interrupt_request(CPUState *env)
{
if (env && vcpu && env != vcpu->env) {
Index: kvm-userspace.balloon/qemu/qemu-kvm.h
===
--- kvm-userspace.balloon.orig/qemu/qemu-kvm.h
+++ kvm-userspace.balloon/qemu/qemu-kvm.h
@@ -24,6 +24,7 @@ int kvm_qemu_init_env(CPUState *env);
int kvm_qemu_check_extension(int ext);
void kvm_apic_init(CPUState *env);
int kvm_set_irq(int irq, int level);
+int kvm_zap_gfn(unsigned long gfn);
int kvm_physical_memory_set_dirty_tracking(int enable);
int kvm_update_dirty_pages_log(void);
--
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [patch 2/3] QEMU: balloon: dont allow target larger than ram size
Truncate the target size to be at most ram size.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
Index: kvm-userspace.balloon/qemu/hw/virtio-balloon.c
===
--- kvm-userspace.balloon.orig/qemu/hw/virtio-balloon.c
+++ kvm-userspace.balloon/qemu/hw/virtio-balloon.c
@@ -16,6 +16,7 @@
#include "pc.h"
#include "balloon.h"
#include "sysemu.h"
+#include "console.h"
#include
@@ -115,6 +116,10 @@ static ram_addr_t virtio_balloon_to_targ
VirtIOBalloon *dev = opaque;
if (target) {
+if (target > ram_size) {
+term_printf("target larger than ram size, truncating\n");
+target = ram_size;
+}
dev->num_pages = (ram_size - target) >> TARGET_PAGE_BITS;
virtio_notify_config(&dev->vdev);
}
--
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [patch 1/3] QEMU support for virtio balloon driver
From: Anthony Liguori <[EMAIL PROTECTED]>
This patch adds support to QEMU for Rusty's recently introduce virtio balloon
driver. The user-facing portions of this are the introduction of a "balloon"
and "info balloon" command in the monitor.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
Index: kvm-userspace.balloon/qemu/Makefile.target
===
--- kvm-userspace.balloon.orig/qemu/Makefile.target
+++ kvm-userspace.balloon/qemu/Makefile.target
@@ -577,7 +577,7 @@ OBJS += e1000.o
OBJS+= hypercall.o
# virtio devices
-OBJS += virtio.o virtio-net.o virtio-blk.o
+OBJS += virtio.o virtio-net.o virtio-blk.o virtio-balloon.o
ifeq ($(TARGET_BASE_ARCH), i386)
# Hardware support
Index: kvm-userspace.balloon/qemu/balloon.h
===
--- /dev/null
+++ kvm-userspace.balloon/qemu/balloon.h
@@ -0,0 +1,14 @@
+#ifndef _QEMU_BALLOON_H
+#define _QEMU_BALLOON_H
+
+#include "cpu-defs.h"
+
+typedef ram_addr_t (QEMUBalloonEvent)(void *opaque, ram_addr_t target);
+
+void qemu_add_balloon_handler(QEMUBalloonEvent *func, void *opaque);
+
+void qemu_balloon(ram_addr_t target);
+
+ram_addr_t qemu_balloon_status(void);
+
+#endif
Index: kvm-userspace.balloon/qemu/hw/pc.c
===
--- kvm-userspace.balloon.orig/qemu/hw/pc.c
+++ kvm-userspace.balloon/qemu/hw/pc.c
@@ -1120,6 +1120,9 @@ static void pc_init1(ram_addr_t ram_size
}
}
+if (pci_enabled)
+ virtio_balloon_init(pci_bus, 0x1AF4, 0x1002);
+
if (extboot_drive != -1) {
DriveInfo *info = &drives_table[extboot_drive];
int cyls, heads, secs;
Index: kvm-userspace.balloon/qemu/hw/pc.h
===
--- kvm-userspace.balloon.orig/qemu/hw/pc.h
+++ kvm-userspace.balloon/qemu/hw/pc.h
@@ -153,6 +153,9 @@ void virtio_net_poll(void);
void *virtio_blk_init(PCIBus *bus, uint16_t vendor, uint16_t device,
BlockDriverState *bs);
+/* virtio-balloon.h */
+void *virtio_balloon_init(PCIBus *bus, uint16_t vendor, uint16_t device);
+
/* extboot.c */
void extboot_init(BlockDriverState *bs, int cmd);
Index: kvm-userspace.balloon/qemu/hw/virtio-balloon.c
===
--- /dev/null
+++ kvm-userspace.balloon/qemu/hw/virtio-balloon.c
@@ -0,0 +1,145 @@
+/*
+ * Virtio Block Device
+ *
+ * Copyright IBM, Corp. 2008
+ *
+ * Authors:
+ * Anthony Liguori <[EMAIL PROTECTED]>
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2. See
+ * the COPYING file in the top-level directory.
+ *
+ */
+
+#include "virtio.h"
+#include "block.h"
+#include "pc.h"
+#include "balloon.h"
+#include "sysemu.h"
+
+#include
+
+/* from Linux's linux/virtio_blk.h */
+
+/* The ID for virtio_balloon */
+#define VIRTIO_ID_BALLOON 5
+
+/* The feature bitmap for virtio balloon */
+#define VIRTIO_BALLOON_F_MUST_TELL_HOST0 /* Tell before reclaiming
pages */
+
+struct virtio_balloon_config
+{
+/* Number of pages host wants Guest to give up. */
+uint32_t num_pages;
+/* Number of pages we've actually got in balloon. */
+uint32_t actual;
+};
+
+typedef struct VirtIOBalloon
+{
+VirtIODevice vdev;
+VirtQueue *ivq, *dvq;
+uint32_t num_pages;
+uint32_t actual;
+} VirtIOBalloon;
+
+static VirtIOBalloon *to_virtio_balloon(VirtIODevice *vdev)
+{
+return (VirtIOBalloon *)vdev;
+}
+
+static void virtio_balloon_handle_output(VirtIODevice *vdev, VirtQueue *vq)
+{
+VirtIOBalloon *s = to_virtio_balloon(vdev);
+VirtQueueElement elem;
+unsigned int count;
+
+while ((count = virtqueue_pop(vq, &elem)) != 0) {
+ int i;
+ unsigned int wlen = 0;
+
+ for (i = 0; i < elem.out_num; i++) {
+ int flags;
+ uint32_t *pfns = elem.out_sg[i].iov_base;
+ unsigned int n_pfns = elem.out_sg[i].iov_len / 4;
+ int j;
+
+ for (j = 0; j < n_pfns; j++) {
+ if (vq == s->dvq) /* deflate */
+ flags = MADV_WILLNEED;
+ else /* inflate */
+ flags = MADV_DONTNEED;
+
+#if 0
+ /* can't use this until we have mmu notifier support */
+ madvise(phys_ram_base + (pfns[j] << TARGET_PAGE_BITS),
+ TARGET_PAGE_SIZE, flags);
+#endif
+ }
+
+ wlen += elem.out_sg[i].iov_len;
+ }
+
+ virtqueue_push(vq, &elem, wlen);
+ virtio_notify(vdev, vq);
+}
+}
+
+static void virtio_balloon_get_config(VirtIODevice *vdev, uint8_t *config_data)
+{
+VirtIOBalloon *dev = to_virtio_balloon(vdev);
+struct virtio_balloon_config config;
+
+config.num_pages = dev->num_pages;
+config.actual = dev->actual;
+
+memcpy(config_data, &config, 8);
+}
+
+static void virtio_balloon_set_config(VirtIODevice *vdev,
+ cons
[kvm-devel] [patch 0/3] QEMU balloon support
This patchset resends Anthony's QEMU balloon support plus: - Truncates the target size to ram size - Enables madvise() conditioned on KVM_ZAP_GFN ioctl -- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] KVM: MMU: add KVM_ZAP_GFN ioctl
Add an ioctl to zap all mappings to a given gfn. This allows userspace
remove the QEMU process mappings and the page without causing
inconsistency.
Signed-off-by: Marcelo Tosatti <[EMAIL PROTECTED]>
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index f0cdfba..c41464f 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -642,6 +642,67 @@ static void rmap_write_protect(struct kvm *kvm, u64 gfn)
account_shadowed(kvm, gfn);
}
+static void rmap_nuke(struct kvm *kvm, u64 gfn)
+{
+ unsigned long *rmapp;
+ u64 *spte;
+ int nuked = 0;
+
+ gfn = unalias_gfn(kvm, gfn);
+ rmapp = gfn_to_rmap(kvm, gfn, 0);
+
+ spte = rmap_next(kvm, rmapp, NULL);
+ while (spte) {
+ BUG_ON(!spte);
+ BUG_ON(!(*spte & PT_PRESENT_MASK));
+ rmap_printk("rmap_nuke: spte %p %llx\n", spte, *spte);
+ rmap_remove(kvm, spte);
+ set_shadow_pte(spte, shadow_trap_nonpresent_pte);
+nuked = 1;
+ spte = rmap_next(kvm, rmapp, spte);
+ }
+ /* check for huge page mappings */
+ rmapp = gfn_to_rmap(kvm, gfn, 1);
+ spte = rmap_next(kvm, rmapp, NULL);
+ while (spte) {
+ BUG_ON(!spte);
+ BUG_ON(!(*spte & PT_PRESENT_MASK));
+ BUG_ON((*spte & (PT_PAGE_SIZE_MASK|PT_PRESENT_MASK)) !=
(PT_PAGE_SIZE_MASK|PT_PRESENT_MASK));
+ pgprintk("rmap_nuke(large): spte %p %llx %lld\n", spte, *spte,
gfn);
+ rmap_remove(kvm, spte);
+ --kvm->stat.lpages;
+ set_shadow_pte(spte, shadow_trap_nonpresent_pte);
+ nuked = 1;
+ spte = rmap_next(kvm, rmapp, spte);
+ }
+
+ if (nuked)
+ kvm_flush_remote_tlbs(kvm);
+}
+
+int kvm_zap_single_gfn(struct kvm *kvm, gfn_t gfn)
+{
+ unsigned long addr;
+ int have_mmu_notifiers = 0;
+
+ down_read(&kvm->slots_lock);
+ addr = gfn_to_hva(kvm, gfn);
+
+ if (kvm_is_error_hva(addr)) {
+ up_read(&kvm->slots_lock);
+ return -EINVAL;
+ }
+
+ if (!have_mmu_notifiers) {
+ spin_lock(&kvm->mmu_lock);
+ rmap_nuke(kvm, gfn);
+ spin_unlock(&kvm->mmu_lock);
+ }
+ up_read(&kvm->slots_lock);
+
+ return 0;
+}
+
#ifdef MMU_DEBUG
static int is_empty_shadow_page(u64 *spt)
{
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index e65a9d6..d982ca1 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -816,6 +816,9 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_NR_MEMSLOTS:
r = KVM_MEMORY_SLOTS;
break;
+ case KVM_CAP_ZAP_GFN:
+ r = 1;
+ break;
default:
r = 0;
break;
@@ -1636,6 +1639,15 @@ long kvm_arch_vm_ioctl(struct file *filp,
r = 0;
break;
}
+ case KVM_ZAP_GFN: {
+ gfn_t gfn;
+
+ r = -EFAULT;
+ if (copy_from_user(&gfn, argp, sizeof gfn))
+ goto out;
+ r = kvm_zap_single_gfn(kvm, gfn);
+ break;
+}
default:
;
}
diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h
index 024b57c..4e45bd2 100644
--- a/include/asm-x86/kvm_host.h
+++ b/include/asm-x86/kvm_host.h
@@ -425,6 +425,7 @@ void kvm_mmu_set_nonpresent_ptes(u64 trap_pte, u64
notrap_pte);
int kvm_mmu_reset_context(struct kvm_vcpu *vcpu);
void kvm_mmu_slot_remove_write_access(struct kvm *kvm, int slot);
void kvm_mmu_zap_all(struct kvm *kvm);
+int kvm_zap_single_gfn(struct kvm *kvm, gfn_t gfn);
unsigned int kvm_mmu_calculate_mmu_pages(struct kvm *kvm);
void kvm_mmu_change_mmu_pages(struct kvm *kvm, unsigned int kvm_nr_mmu_pages);
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index e92e703..9ea714f 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -236,6 +236,7 @@ struct kvm_vapic_addr {
#define KVM_CAP_CLOCKSOURCE 8
#define KVM_CAP_NR_VCPUS 9 /* returns max vcpus per vm */
#define KVM_CAP_NR_MEMSLOTS 10 /* returns max memory slots per vm */
+#define KVM_CAP_ZAP_GFN11
/*
* ioctls for VM fds
@@ -258,6 +259,7 @@ struct kvm_vapic_addr {
#define KVM_IRQ_LINE _IOW(KVMIO, 0x61, struct kvm_irq_level)
#define KVM_GET_IRQCHIP _IOWR(KVMIO, 0x62, struct kvm_irqchip)
#define KVM_SET_IRQCHIP _IOR(KVMIO, 0x63, struct kvm_irqchip)
+#define KVM_ZAP_GFN _IOR(KVMIO, 0x64, unsigned long)
/*
* ioctls for vcpu fds
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@list
Re: [kvm-devel] [PATCH][QEMU] Use a separate device for in-kernel PIT
On Wed, 2008-03-12 at 12:38 -0500, Anthony Liguori wrote:
> Part of the feedback we received from Fabrice about the KVM patches
> for QEMU
> is that we should create a separate device for the in-kernel APIC to
> avoid
> having lots of if (kvm_enabled()) within the APIC code that were
> difficult to
> understand why there were needed.
>
> This patch separates the in-kernel PIT into a separate device. It
> also
> introduces some configure logic to only compile in support for the
> in-kernel
> PIT if it's available.
>
> The result of this is that we now only need a single if
> (kvm_enabled()) to
> determine which device to use. Besides making it more upstream
> friendly, I
> think this makes the code much easier to understand.
>
Seems like a good idea.
[snip]
..
> +static void pit_reset(void *opaque)
> +{
> +PITState *pit = opaque;
> +PITChannelState *s;
> +int i;
> +
> +for(i = 0;i < 3; i++) {
> +s = &pit->channels[i];
> +s->mode = 3;
> +s->gate = (i != 2);
> +pit_load_count(s, 0);
> +}
> +}
> +
Seems like pit_reset won't change the in-kernel pit state.
Actually this should handled as a part of more general reset ioctl to
all of kvm's in-kernel devices.
Cheers,
Dor
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] shrinker support for the mmu cache
Izik Eidus wrote: > this patch simply register the mmu cache with the shrinker. Please inline patches in the future as it makes it easier to review. The implementation looks good and I think it's a good idea. One is that there is one shrinker for all VMs but you run through the list of VMs in order. This means the first VM in the list is most frequently going to be shrunk down to KVM_MIN_ALLOC_MMU_PAGES. This seems unfair and potentially dangerous. The shrinker can be triggered potentially by the growth of the MMU cache on other VMs. I think in the least, you should attempt to go through the VMs in a round-robin fashion to ensure that if you shrink one VM, the next time you'll shrink a different VM. The other thing I wonder about is whether DEFAULT_SEEKS is the best value to use. On the one hand, a guest page fault is probably not as expensive as reclaiming something from disk. On the other hand, NPT guests are likely to be very sensitive to evicting things from the shadow page cache. I would think it's pretty clear that in the NPT case, the MMU cache should have a higher seek cost than the default. Regards, Anthony Liguori > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > > > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] shrinker support for the mmu cache
this patch simply register the mmu cache with the shrinker. 0004-KVM-register-the-kvm-mmu-cache-with-the-shrinker.patch Description: application/mbox - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Problems with vmwarevga and graphical syslinux menus
Jeremy Katz wrote: > The changes so that the vmwarevga code respects the E820 region runs > afoul of the fact that the VBE bios used has a hard-coded base address > for vesa modes. Thus when syslinux uses VBE to do its graphical bits, > the lfb address doesn't match what the bios thinks it is :-/ > > Test case is any Fedora boot.iso or live CD from the past year or so. > Unfortunately, setting the BAR registers doesn't work under KVM. It works fine in QEMU so it's probably a KVM bug. I'll look into it when I get a chance. Regards, Anthony Liguori > Jeremy > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH][QEMU] Use a separate device for in-kernel PIT
Part of the feedback we received from Fabrice about the KVM patches for QEMU
is that we should create a separate device for the in-kernel APIC to avoid
having lots of if (kvm_enabled()) within the APIC code that were difficult to
understand why there were needed.
This patch separates the in-kernel PIT into a separate device. It also
introduces some configure logic to only compile in support for the in-kernel
PIT if it's available.
The result of this is that we now only need a single if (kvm_enabled()) to
determine which device to use. Besides making it more upstream friendly, I
think this makes the code much easier to understand.
Signed-off-by: Anthony Liguori <[EMAIL PROTECTED]>
diff --git a/qemu/Makefile.target b/qemu/Makefile.target
index 67a433e..2579688 100644
--- a/qemu/Makefile.target
+++ b/qemu/Makefile.target
@@ -585,6 +585,9 @@ OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o
OBJS+= usb-uhci.o vmmouse.o vmport.o vmware_vga.o extboot.o
+ifeq ($(USE_KVM_PIT), 1)
+OBJS+= i8254-kvm.o
+endif
CPPFLAGS += -DHAS_AUDIO -DHAS_AUDIO_CHOICE
endif
ifeq ($(TARGET_BASE_ARCH), ia64)
diff --git a/qemu/configure b/qemu/configure
index bbedddc..22f44c8 100755
--- a/qemu/configure
+++ b/qemu/configure
@@ -100,6 +100,7 @@ bsd="no"
linux="no"
kqemu="no"
kvm="no"
+kvm_cap_pit="no"
profiler="no"
kernel_path=""
cocoa="no"
@@ -612,6 +613,22 @@ int main(void) {
EOF
##
+# KVM probe
+
+if test "$kvm" = "yes" ; then
+cat > $TMPC <
+#ifndef KVM_CAP_PIT
+#error "kvm no pit capability"
+#endif
+int main(void) { return 0; }
+EOF
+if $cc $ARCH_CFLAGS -o $TMPE ${OS_CFLAGS} $TMPC 2> /dev/null ; then
+ kvm_cap_pit="yes"
+fi
+fi
+
+##
# SDL probe
sdl_too_old=no
@@ -1136,6 +1153,9 @@ configure_kvm() {
echo "#define USE_KVM 1" >> $config_h
echo "USE_KVM=1" >> $config_mak
echo "CONFIG_KVM_KERNEL_INC=$kernel_path/include" >> $config_mak
+if test $kvm_cap_pit = "yes" ; then
+ echo "USE_KVM_PIT=1" >> $config_mak
+fi
disable_cpu_emulation
fi
}
diff --git a/qemu/hw/i8254-kvm.c b/qemu/hw/i8254-kvm.c
new file mode 100644
index 000..f0669cb
--- /dev/null
+++ b/qemu/hw/i8254-kvm.c
@@ -0,0 +1,178 @@
+/*
+ * QEMU 8253/8254 interval timer emulation
+ *
+ * Copyright (c) 2003-2004 Fabrice Bellard
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include "hw.h"
+#include "pc.h"
+#include "isa.h"
+#include "i8254.h"
+
+#include "qemu-kvm.h"
+
+static PITState pit_state;
+
+static void kvm_kernel_pit_save_to_user(PITState *s)
+{
+struct kvm_pit_state pit;
+struct kvm_pit_channel_state *c;
+struct PITChannelState *sc;
+int i;
+
+kvm_get_pit(kvm_context, &pit);
+
+for (i = 0; i < 3; i++) {
+ c = &pit.channels[i];
+ sc = &s->channels[i];
+ sc->count = c->count;
+ sc->latched_count = c->latched_count;
+ sc->count_latched = c->count_latched;
+ sc->status_latched = c->status_latched;
+ sc->status = c->status;
+ sc->read_state = c->read_state;
+ sc->write_state = c->write_state;
+ sc->write_latch = c->write_latch;
+ sc->rw_mode = c->rw_mode;
+ sc->mode = c->mode;
+ sc->bcd = c->bcd;
+ sc->gate = c->gate;
+ sc->count_load_time = c->count_load_time;
+}
+}
+
+static void kvm_kernel_pit_load_from_user(PITState *s)
+{
+struct kvm_pit_state pit;
+struct kvm_pit_channel_state *c;
+struct PITChannelState *sc;
+int i;
+
+for (i = 0; i < 3; i++) {
+ c = &pit.channels[i];
+ sc = &s->channels[i];
+ c->count = sc->count;
+ c->latched_count = sc->latched_count;
+ c->count_latched = sc->count_latched;
+ c->status_latched = sc->status_latched;
+ c->status = sc->status;
+ c->read_sta
[kvm-devel] [PATCH] kvm.h: __user requires compiler.h
include/linux/kvm.h defines struct kvm_dirty_log to
[...]
union {
void __user *dirty_bitmap; /* one bit per page */
__u64 padding;
};
__user requires compiler.h to compile. Currently, this works on x86
only coincidentally due to other include files. This patch makes
kvm.h compile in all cases.
Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]>
---
include/linux/kvm.h |1 +
1 file changed, 1 insertion(+)
Index: kvm/include/linux/kvm.h
===
--- kvm.orig/include/linux/kvm.h
+++ kvm/include/linux/kvm.h
@@ -8,6 +8,7 @@
*/
#include
+#include
#include
#include
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] qemu: acpi: notify a powerdown event to the guest only if acpi is enabled
Without this patch when '-no-acpi' is added to the command line and the
user issues a 'system_powerdown' qemu monitor command, we get a segmentation
fault.
Signed-off-by: Uri Lublin <[EMAIL PROTECTED]>
---
qemu/hw/acpi.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/qemu/hw/acpi.c b/qemu/hw/acpi.c
index e44c8b5..9033ee2 100644
--- a/qemu/hw/acpi.c
+++ b/qemu/hw/acpi.c
@@ -530,7 +530,7 @@ i2c_bus *piix4_pm_init(PCIBus *bus, int devfn, uint32_t
smb_io_base,
#if defined(TARGET_I386)
void qemu_system_powerdown(void)
{
-if(pm_state->pmen & PWRBTN_EN) {
+if(pm_state && (pm_state->pmen & PWRBTN_EN)) {
pm_state->pmsts |= PWRBTN_EN;
pm_update_sci(pm_state);
}
--
1.5.4.2
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] no mouse
With those options I still have the same problem, and with -no-kvm it always crashes for me at least. On Wed, 12 Mar 2008 07:16:09 -0700 "Uri Lublin" <[EMAIL PROTECTED]> wrote: > From: aGaTHoS > >CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ > >kvm version: 62 > >kernel: 2.6.23-hardened-r7 (with gentoo standard and hardened patches, it is > >anyway compiled without ssp and pie) > >arch: x86_64 > >guest OS: various, windows XP and various linux livecds > >command line: > > > > 1 (windows) # kvm -hda /root/kvm/windows.img -m 192 -localtime -k es -net > > nic -net tap,script=/etc/kvm/br1 > > > > 2 (livecd f.e puppy) # kvm -hda /root/kvm/live.img -cdrom > > /home/agathos/data/downloads/puppy-3.01-seamonkey.iso -boot d -name live -m > > 192 -localtime -k es -std-vga -net nic >-net tap,script=/etc/kvm/br1 > > > >with -no-kvm : it crashes after entering command > > > >-- > >Hugo Amorós Salvador <[EMAIL PROTECTED]> > - > Hi, > > I was able to reproduce the problem on an AMD machine (but not on an Intel > machine). > (kvm-62, AMD, x86_64, fedora 7, puppy linux live guest) > > Adding '-no-kvm' to the command line just made things slower (no crush). > Adding '-no-acpi' or '-clock unix' seems to workaround the mouse problem. > > Uri. > > -- aGaTHoS <[EMAIL PROTECTED]> - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] loop in copy_user_generic_string
2008/3/12, Zdenek Kabelac <[EMAIL PROTECTED]>: > 2008/3/12, Andi Kleen <[EMAIL PROTECTED]>: > > > > Argh - being stupid here - it looks like these 'working' kernels were > > > not SMP actually. > > > As long as the SMP is used - I still get the busy loop :( > > > Now being clueless > > > > > > Sorry don't have the cycles to look into your problem, but the > > standard procedure for hard problems that can be reproduced > > is to git bisect them down to the change set that introduced the > > problem originally and then complain to whoever authored that. > > > The problem is - I don't know about any working SMP kernel which would > survive this test - thought haven't got into a really big history - > tried something like 2.6.22 kernels - no luck - also many kernel seems > to be unbootable in SMP mode on my machine giving many oopses - in > fact just 2.6.24 series starts to be at least reliable in booting in > my Qemu setup without failing during disk mounting or in some other > place... > > Will try to find probably some 2.6.18 kernel and will check what happens. > > On the other hand - I've tried to replicate my bug on few other > machines with no luck actually - so it's something which might not be > easy to trace :( > Btw - just for testing purposes - I've taken current fedora rawhide kernel. Started machine with this kernel and installed it into qemu guest as well. And this is what I get when running in SMP mode: BUG: soft lockup - CPU#1 stuck for 61s! [udevd:583] CPU 1: Modules linked in: floppy ata_piix ata_generic pata_acpi pcnet32 mii libata scsi_m od Pid: 583, comm: udevd Not tainted 2.6.25-0.105.rc5.fc9 #1 RIP: 0010:[] [] clear_page_c+0x7/0x10 RSP: :810015455b20 EFLAGS: 00010246 RAX: RBX: 810015455be8 RCX: 0200 RDX: 06a0 RSI: 810015455a74 RDI: 810015001000 RBP: 8100 R08: 15562000 R09: 8100 R10: 0292 R11: 0001 R12: 3000 R13: 81009540 R14: 810015454000 R15: 0001 FS: () GS:810017509320(0063) knlGS:f7f1d720 CS: 0010 DS: 002b ES: 002b CR0: 8005003b CR2: 810015001000 CR3: 159e9000 CR4: 06a0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Call Trace: [] ? get_page_from_freelist+0x51f/0x6b6 [] ? __alloc_pages+0xed/0x3c3 [] ? alloc_pages_current+0x100/0x109 [] ? __get_free_pages+0xe/0x4d [] ? show_stat+0x2a/0x4af [] ? __alloc_pages+0xed/0x3c3 [] ? alloc_pages_current+0x100/0x109 [] ? __get_free_pages+0xe/0x4d [] ? __kmalloc+0x3e/0xf0 [] ? seq_read+0x143/0x2a2 [] ? seq_read+0x116/0x2a2 [] ? seq_read+0x0/0x2a2 [] ? seq_read+0x0/0x2a2 [] ? proc_reg_read+0x8a/0xa7 [] ? vfs_read+0xab/0x154 [] ? sys_read+0x47/0x70 [] ? ia32_sysret+0x0/0xa (Full trace attached) So I guess I'm kind of lucky that my own kernels actually boot in smp mode properly. Guest was started with 384MB - host has 2GB - around 1GB was free when started. Kernel boots with nosmp flag. Zdenek qemu-debian.tty Description: Binary data - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] PCI IO regions must be power of two
On Wed, Mar 12, 2008 at 08:39:11AM -0700, Uri Lublin wrote:
> From: Marcelo Tosatti
> >
> >Index: kvm-userspace.hotplug2/qemu/hw/pci.c
> >===
> >--- kvm-userspace.hotplug2.orig/qemu/hw/pci.c
> >+++ kvm-userspace.hotplug2/qemu/hw/pci.c
> >@@ -236,6 +236,13 @@ void pci_register_io_region(PCIDevice *p
> >
> > if ((unsigned int)region_num >= PCI_NUM_REGIONS)
> > return;
> >+
> >+/* IO region size must be power of two */
> >+if (type == PCI_ADDRESS_SPACE_IO && (size & (size-1))) {
>
> Why only for PCI IO regions ? Don't PCI memory regions have the same
> restriction ?
Yes, they do.
> >+size = size << 1;
> >+size &= size-1;
>
> That would not make size a power of 2 (e.g. size=7 --> size=12).
Right, sorry.
I'll resend a patch to have virtio allocate IO regions with proper sizes
and warn if the IO _or_ memory region are not power of two, as Anthony
suggested.
Since this problem is only visible with device hotplug (QEMU will
allocate the region offsets properly during initialization) I'll wait
for that to hit the tree.
Thanks.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] loop in copy_user_generic_string
2008/3/12, Andi Kleen <[EMAIL PROTECTED]>: > > Argh - being stupid here - it looks like these 'working' kernels were > > not SMP actually. > > As long as the SMP is used - I still get the busy loop :( > > Now being clueless > > > Sorry don't have the cycles to look into your problem, but the > standard procedure for hard problems that can be reproduced > is to git bisect them down to the change set that introduced the > problem originally and then complain to whoever authored that. The problem is - I don't know about any working SMP kernel which would survive this test - thought haven't got into a really big history - tried something like 2.6.22 kernels - no luck - also many kernel seems to be unbootable in SMP mode on my machine giving many oopses - in fact just 2.6.24 series starts to be at least reliable in booting in my Qemu setup without failing during disk mounting or in some other place... Will try to find probably some 2.6.18 kernel and will check what happens. On the other hand - I've tried to replicate my bug on few other machines with no luck actually - so it's something which might not be easy to trace :( Zdenek - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] PCI IO regions must be power of two
From: Marcelo Tosatti
>
>Index: kvm-userspace.hotplug2/qemu/hw/pci.c
>===
>--- kvm-userspace.hotplug2.orig/qemu/hw/pci.c
>+++ kvm-userspace.hotplug2/qemu/hw/pci.c
>@@ -236,6 +236,13 @@ void pci_register_io_region(PCIDevice *p
>
> if ((unsigned int)region_num >= PCI_NUM_REGIONS)
> return;
>+
>+/* IO region size must be power of two */
>+if (type == PCI_ADDRESS_SPACE_IO && (size & (size-1))) {
Why only for PCI IO regions ? Don't PCI memory regions have the same
restriction ?
>+size = size << 1;
>+size &= size-1;
That would not make size a power of 2 (e.g. size=7 --> size=12).
>+}
>+
Regards,
Uri.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Problems with vmwarevga and graphical syslinux menus
The changes so that the vmwarevga code respects the E820 region runs afoul of the fact that the VBE bios used has a hard-coded base address for vesa modes. Thus when syslinux uses VBE to do its graphical bits, the lfb address doesn't match what the bios thinks it is :-/ Test case is any Fedora boot.iso or live CD from the past year or so. Jeremy - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Sound in Vista
On Wed, 2008-03-12 at 10:31 +0200, Dor Laor wrote:
> I didn't try it, but can you detail your command line for running
> qemu.
> You can also try to change the -soundhw {pcspk,sb16mes1370}.
> Does Vista recognizes the device but there is not sound?
Vista knows there is a sound card there, but Microsoft no longer ships
drivers for sb16/es1370 and scouring the Web didn't turn anything up
either.
Right now, the only option I can think of is maybe a cheap USB sound
device.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] loop in copy_user_generic_string
> Argh - being stupid here - it looks like these 'working' kernels were > not SMP actually. > As long as the SMP is used - I still get the busy loop :( > Now being clueless Sorry don't have the cycles to look into your problem, but the standard procedure for hard problems that can be reproduced is to git bisect them down to the change set that introduced the problem originally and then complain to whoever authored that. -Andi - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] no mouse
From: aGaTHoS >CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ >kvm version: 62 >kernel: 2.6.23-hardened-r7 (with gentoo standard and hardened patches, it is >anyway compiled without ssp and pie) >arch: x86_64 >guest OS: various, windows XP and various linux livecds >command line: > > 1 (windows) # kvm -hda /root/kvm/windows.img -m 192 -localtime -k es -net nic > -net tap,script=/etc/kvm/br1 > > 2 (livecd f.e puppy) # kvm -hda /root/kvm/live.img -cdrom > /home/agathos/data/downloads/puppy-3.01-seamonkey.iso -boot d -name live -m > 192 -localtime -k es -std-vga -net nic >-net tap,script=/etc/kvm/br1 > >with -no-kvm : it crashes after entering command > >-- >Hugo Amorós Salvador <[EMAIL PROTECTED]> - Hi, I was able to reproduce the problem on an AMD machine (but not on an Intel machine). (kvm-62, AMD, x86_64, fedora 7, puppy linux live guest) Adding '-no-kvm' to the command line just made things slower (no crush). Adding '-no-acpi' or '-clock unix' seems to workaround the mouse problem. Uri. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ia64-devel] kvm-ia64.git is created on master.kernel.org!
Akio Takebe wrote: > Hi, Xiantao > >> We have created kvm-ia64.git on master.kernel.org for open >> development, and the latest source is also included in this >> repository. So you can clone and make contributions to it now. >> Cheers!! >> In this repository, I created the branch kvm-ia64-mc4 to hold the >> patchset. Now, the whole community had better work on the branch >> together for reviewing code, doing cleanup, and adding the new >> features. If you have any contribution or questions, please feel >> free to submit to the kvm-ia64 mailing >> list(https://lists.sourceforge.net/lists/listinfo/kvm-ia64-devel). > Wow, greate! > Can we use the same userspace tree as x86? Yes, but seems it is broken for ia64 side due to latest merge with qemu upstream. > Are save/restore already available? It needs userspace patch. I enabled save&restore without log dirty mechanism, but it breaks after adding log dirty. So need more debug effort on it. Xiantao - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] loop in copy_user_generic_string
2008/3/11, Zdenek Kabelac <[EMAIL PROTECTED]>: > 2008/3/9, Zdenek Kabelac <[EMAIL PROTECTED]>: > > > 2008/3/7, Zdenek Kabelac <[EMAIL PROTECTED]>: > > > > > 2008/3/5, Zdenek Kabelac <[EMAIL PROTECTED]>: > > > > > > > 2008/3/5, Avi Kivity <[EMAIL PROTECTED]>: > > > > > > > > > Andi Kleen wrote: > > > > > > Avi Kivity <[EMAIL PROTECTED]> writes: > > > > > > > > > > > >> Most likely movs emulation is broken for long counts. Please > post a > > > > > >> disassembly of copy_user_generic_string to make sure we're > looking at > > > > > >> the same code. > > > > > >> > > > > > > > > > > > > Be careful -- this code is patched at runtime and what you > > > > > > see in the vmlinux is not necessarily the same that is executed > > > > > > > > > > > > > > > > > > > > > > > > > > > If the disassembled instruction isn't marked as an alternative in > the > > > > > source, then it can't be patched, right? > > > > > > > > > > > > > > Hello > > > > > > Any progress on this - It looks like I get this bug quite often when I > test > > > device-mapper code. > > > > > > > > > > > Hello > > > > I've made some more experiments and noticed few more things: > > > > a) - it is just enough to run parallel loop with cat LVM partition > > >/dev/null and dmsetup status > > > > b) when I insert for() loop for zeroing allocated memory in the > > dm-ioctl copy_params function my loop start once the memory crosses > > exactly 4KB boundary (visible from register content) > > > > c) in my trace log I could usually always see this pattern: > > [ 160.634897] [] preempt_schedule_irq+0x5a/0xa0 > > [ 160.634897] [] retint_kernel+0x26/0x30 > > > > from the look in the arch/x86/kernel/entry64.s I could really see > > there is some potentiality for internal loop that may call > > preempt_schedule_irq in upon some check in exit_intr - but having > > actually now idea what's this all about... > > > > I've put there just some extra dump_stack trace in the > > preempt_schedule_irq - and it's really being printed - but quite > > slowly actually considering process eats 100% CPU > > > > So anyone has any idea what might be wrong ? > > > > Hello > > I've some more news here - it looks I've found working setup on my C2D. > > All I need to do is compile my 64bit kernel with optimization for space. > This will magical start to work - at least in this case. > > I'll now probably slowly try to figure out which directory with -Os > compilation makes the difference. > > Also I've noticed that standard Debian 2.6.24-4-686 kernel loops in > Qemu, but 486 version doesn't. Argh - being stupid here - it looks like these 'working' kernels were not SMP actually. As long as the SMP is used - I still get the busy loop :( Now being clueless Zdenek - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Take her hard from behind
Your partner will thank you for the better sex you are giving once you have this.- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [kvm-ia64-devel] kvm-ia64.git is created on master.kernel.org!
Hi, Xiantao >We have created kvm-ia64.git on master.kernel.org for open development, >and the latest source is also included in this repository. So you can >clone and make contributions to it now. Cheers!! >In this repository, I created the branch kvm-ia64-mc4 to hold the >patchset. Now, the whole community had better work on the branch >together for reviewing code, doing cleanup, and adding the new features. >If you have any contribution or questions, please feel free to submit to >the kvm-ia64 mailing >list(https://lists.sourceforge.net/lists/listinfo/kvm-ia64-devel). Wow, greate! Can we use the same userspace tree as x86? Are save/restore already available? Best Regards, Akio Takebe - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] kvm-ia64.git is created on master.kernel.org!
Hi, guys We have created kvm-ia64.git on master.kernel.org for open development, and the latest source is also included in this repository. So you can clone and make contributions to it now. Cheers!! In this repository, I created the branch kvm-ia64-mc4 to hold the patchset. Now, the whole community had better work on the branch together for reviewing code, doing cleanup, and adding the new features. If you have any contribution or questions, please feel free to submit to the kvm-ia64 mailing list(https://lists.sourceforge.net/lists/listinfo/kvm-ia64-devel). BTW, You know, since 2.6.26 merge window is coming, we have to prepare a clean and mature tree before its due. Welcome to join in kvm/ia64 development! Thanks for you any contributions! Xiantao - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Sicoob Executivo - Associe-se
Title: Sicoob Executivo Caso você não queira receber mais informações de nossa Cooperativa, responda está mensagem solicitando a exclusão de seu e-mail - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] how increase performance of network io in kvm
On Tue, 2008-03-11 at 15:30 -0700, Dhirendra Pal Singh wrote:
> I tried e1000 and it says "qemu: Unsupported NIC: e1000" :( Did I
> miss something.. ?
>
> I downloaded the latest code base for qemu, and I see the following
> lines in qemu-doc.texi
>
> *
> @code{i82551}, @code{i82557b}, @code{i82559er},
> @code{ne2k_pci}, @code{ne2k_isa}, @code{pcnet}, @code{rtl8139},
> @code{smc91c111}, @code{lance} and @code{mcf_fec}.
The new source contains e1000 line too
> *
>
> I don't see any e1000 entry there? Meanwhile I am trying to build
> latest version of qemu and see if it gets me anywhere.
>
>
You probably use the qemu that comes with your distribution and not the
new source.
You should find a qemu/hw/e1000.c file if you have an updated
repository.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel a16664b.., userspace3017d05.. one new issue
On Wed, Mar 12, 2008 at 11:05:21AM +0200, Dor Laor wrote: > Can you try the following patch that disables flex priority: FWIW, Your MUA ate the patch. > kvm: vmx: for 4.0 disable Flex-Priority and always use Avi's tpr > optimization TPR patching doesn't work for SMP which is what he reported. I started some work on making tpr patching work for SMP but it's far from usable (XP crashes after a few minutes of uptime, sometimes more, sometimes less). So something else needs to be done, I'm not sure what though. I probably need to learn how to read windows crash dumps and figure out why it blows up. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] KVM Test result, kernel a16664b.., userspace3017d05.. one new issue
On Wed, 2008-03-12 at 10:41 +0800, Yunfeng Zhao wrote:
> Chris Wedgwood wrote:
> > On Mon, Mar 10, 2008 at 05:27:32PM +0800, Yunfeng Zhao wrote:
> >
> >
> >> One new issue:
> >> 1. booting smp windows guests has 30% chance of hang
> >> https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1910923&group_id=180599
> >>
> >
> >
> >> PlatformWoodcrest
> >> CPU 4
> >> Memory size 8G'
> >>
> >
> > Is that a CPU with FlexPriority?
> >
> >
> Yes, it has FlexPriority.
We have some minor issues with FlexPriority (mainly crashes after 100+
reboots).
Can you try the following patch that disables flex priority:
Author: Uri Lublin <[EMAIL PROTECTED]>
Date: Thu Mar 6 17:38:11 2008 +0200
kvm: vmx: for 4.0 disable Flex-Priority and always use Avi's tpr
optimization
Signed-off-by: Uri Lublin <[EMAIL PROTECTED]>
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 76c4508..bc8dc16 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -201,6 +201,7 @@ static inline int cpu_has_secondary_exec_ctrls(void)
static inline bool cpu_has_vmx_virtualize_apic_accesses(void)
{
+ return false; /* disable Flex-Priority, use Avi's tpr
optimization */
return (vmcs_config.cpu_based_2nd_exec_ctrl &
SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES);
}
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] no mouse
On Wed, 2008-03-12 at 05:10 +0100, aGaTHoS wrote: > CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4800+ > kvm version: 62 > kernel: 2.6.23-hardened-r7 (with gentoo standard and hardened patches, it is > anyway compiled without ssp and pie) > arch: x86_64 > guest OS: various, windows XP and various linux livecds > command line: > > 1 (windows) # kvm -hda /root/kvm/windows.img -m 192 -localtime -k es -net > nic -net tap,script=/etc/kvm/br1 > > 2 (livecd f.e puppy) # kvm -hda /root/kvm/live.img -cdrom > /home/agathos/data/downloads/puppy-3.01-seamonkey.iso -boot d -name live -m > 192 -localtime -k es -std-vga -net nic -net tap,script=/etc/kvm/br1 > > with -no-kvm : it crashes after entering command > > description of the bug: > I can remember the exact version since the problem occurs, but with the > last versions of kvm I have no mouse, it appears when starting windows or X > in linux and when I try to move it, simply deappears. I've also tried with > "-usb -usbdevice mouse" with the same result. Can you bisec the kvm version that did work? Besides that you can also try working with vmmouse. > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Sound in Vista
On Tue, 2008-03-11 at 23:48 -0600, Stuart Jansen wrote:
> Before I give up completely, I'd like to ask: Does anyone know any
> secrets for getting sound to work in Vista that they haven't told
> Google?
>
I didn't try it, but can you detail your command line for running qemu.
You can also try to change the -soundhw {pcspk,sb16mes1370}.
Does Vista recognizes the device but there is not sound?
> BTW, I'm amazed by how quickly KVM has improved over the last few
> months. Astoundingly great work.
>
>
> -
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
> ___
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] keymap nl-be bug/incomplete
Hi, I've been having problems using the -vnc and -k nl-be... Since I've started using KVM v.28 ... Lots of keys won't work and you get the following errors in your Host OS : Warning: no scancode found for keysym 249 Warning: no scancode found for keysym 163 Warning: no scancode found for keysym 163 Warning: no scancode found for keysym 163 Warning: no scancode found for keysym 163 Warning: no scancode found for keysym 224 Warning: no scancode found for keysym 224 Warning: no scancode found for keysym 224 Warning: no scancode found for keysym 224 Warning: no scancode found for keysym 231 I'm running version 61 now and the keymap still hasn't been fixed, so I took the liberty to change the original nl-be keymap that looks like this : nato:/opt/kvm/share/qemu/keymaps# cat nl-be # Dutch (Belgium) map 0x813 include common - Did some hard work and added the following, which solved all my problems :-) Would be great if you could implement it in your new KVM release # Dutch (Belgium) map 0x813 include common ampersand 0x02 1 0x02 shift bar 0x02 altgr eacute 0x03 2 0x03 shift at 0x03 altgr quotedbl 0x04 3 0x04 shift numbersign 0x04 altgr apostrophe 0x05 4 0x05 shift parenleft 0x06 5 0x06 shift section 0x07 6 0x07 shift circumflex 0x07 altgr egrave 0x08 7 0x08 shift exclam 0x09 8 0x09 shift bracketleft 0x09 altgr ccedilla 0x0a 9 0x0a shift braceleft 0x0a altgr agrave 0x0b 0 0x0b shift braceright 0x0b altgr parenright 0x0c degree 0x0c shift minus 0x0d underscore 0x0d shift a 0x10 addupper z 0x11 addupper EuroSign 0x12 altgr dead_circumflex 0x1a dead_diaeresis 0x1a shift bracketleft 0x1a altgr dollar 0x1b asterisk 0x1b shift bracketright 0x1b altgr q 0x1e addupper m 0x27 addupper ugrave 0x28 percent 0x28 shift dead_acute 0x28 altgr twosuperior 0x29 threesuperior 0x29 shift mu 0x2b sterling 0x2b shift dead_grave 0x2b altgr w 0x2c addupper comma 0x32 question 0x32 shift semicolon 0x33 period 0x33 shift colon 0x34 slash 0x34 shift periodcentered 0x34 altgr equal 0x35 plus 0x35 shift tilde 0x35 altgr dead_tilde 0x35 shift altgr less 0x56 greater 0x56 shift backslash 0x56 altgr Kindest Regards, Benjamin Budts Unix System Administrator Scarlet Belgium - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
