[kvm-devel] [PATCH 3/5] KVM: SVM: Defer nmi processing until switch to host state is complete
If we stgi() too soon, nmis can reach the processor even though interrupts are disabled, catching it in a half-switched state. Delay the stgi() until we're done switching. Signed-off-by: Avi Kivity <[EMAIL PROTECTED]> --- drivers/kvm/svm.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c index 3910358..7376805 100644 --- a/drivers/kvm/svm.c +++ b/drivers/kvm/svm.c @@ -1585,10 +1585,6 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run) #endif : "cc", "memory" ); - local_irq_disable(); - - stgi(); - if ((svm->vmcb->save.dr7 & 0xff)) load_db_regs(svm->host_db_regs); @@ -1605,6 +1601,10 @@ static void svm_vcpu_run(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run) reload_tss(vcpu); + local_irq_disable(); + + stgi(); + svm->next_rip = 0; } -- 1.5.3 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] IA64 KVM
Caleb Moore wrote: > Is such a merge likely in the near future or should we proceed in > creating our own port? Hi, Caleb We have completed kvm IA64 port until the end of Aug, and showed a demo in kvm forum of Aug. Then, we could successfully boot windows, and Linux guest on open guest firmware, and also got a reasonable performance. Now, we are pushing the code into the upstream. But, the whole community have to be working together to re-frame current kvm source to accomendate new archs first, since current code is not frendly to new archs support. So, the code should be pushing out in very near future. :-) Thanks --Xiantao - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] IA64 KVM
Hi, We are interested in an IA64 port of KVM, either experimenting with someone else's or writing our own. I've tried getting in contact with Yu Fenghua of Intel but it seems that we will be unable to get hold of their source code until it is in the main tree. Is such a merge likely in the near future or should we proceed in creating our own port? Thank you, -- Caleb Moore Research Assistant School of Computer Science and Engineering University of NSW, Sydney Australia <[EMAIL PROTECTED]> - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Patch]1/5 Move some includes to x86, since the related functions have been moved to x86.c
Acked-by: Carsten Otte <[EMAIL PROTECTED]> Zhang, Xiantao wrote: > From fc56bda0f599ccd00d992bf196654101e82d1413 Mon Sep 17 00:00:00 2001 > From: Zhang Xiantao <[EMAIL PROTECTED]> > Date: Wed, 7 Nov 2007 11:39:23 +0800 > Subject: [PATCH] move some header files form kvm_main.c to x86.c, since > the > related functions have been moved to x86.c > Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]> > --- > drivers/kvm/kvm_main.c |2 -- > drivers/kvm/x86.c |2 ++ > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c > index 0b8edca..010f079 100644 > --- a/drivers/kvm/kvm_main.c > +++ b/drivers/kvm/kvm_main.c > @@ -17,7 +17,6 @@ > > #include "kvm.h" > #include "x86.h" > -#include "x86_emulate.h" > #include "irq.h" > > #include > @@ -44,7 +43,6 @@ > #include > > #include > -#include > #include > #include > #include > diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c > index e905d46..7ea470e 100644 > --- a/drivers/kvm/x86.c > +++ b/drivers/kvm/x86.c > @@ -16,6 +16,7 @@ > > #include "kvm.h" > #include "x86.h" > +#include "x86_emulate.h" > #include "segment_descriptor.h" > #include "irq.h" > > @@ -25,6 +26,7 @@ > #include > > #include > +#include > > #define MAX_IO_MSRS 256 > #define CR0_RESERVED_BITS > \ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] 4/5 Combine kvm_init and kvm_init_x86 intoonefunction (Correction V3)
Hi Avi
Seems my mailer has something wrong, and it always reference an
old version. This should be a correct one. Sorry for inconvenience!
Xiantao
>From 959bc19b0e2ca7edcb3389aabdecf99ba9f1794e Mon Sep 17 00:00:00 2001
From: Zhang Xiantao <[EMAIL PROTECTED]>
Date: Thu, 8 Nov 2007 13:19:06 +0800
Subject: [PATCH] Combine kvm_init and kvm_init_x86 into one function,
and
meanwhile remove module_init module_exit function, since they will be
called
once new arch is registered.
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
drivers/kvm/kvm.h |4 +-
drivers/kvm/kvm_main.c | 60
+--
drivers/kvm/svm.c |4 +-
drivers/kvm/vmx.c |4 +-
4 files changed, 28 insertions(+), 44 deletions(-)
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 4b2421a..33b4629 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -494,9 +494,9 @@ void vcpu_load(struct kvm_vcpu *vcpu);
void vcpu_put(struct kvm_vcpu *vcpu);
-int kvm_init_x86(struct kvm_x86_ops *ops, unsigned int vcpu_size,
+int kvm_init(struct kvm_x86_ops *ops, unsigned int vcpu_size,
struct module *module);
-void kvm_exit_x86(void);
+void kvm_exit(void);
int kvm_mmu_module_init(void);
void kvm_mmu_module_exit(void);
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index da7fb22..8f09170 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -1503,12 +1503,27 @@ static void kvm_sched_out(struct
preempt_notifier *pn,
kvm_arch_vcpu_put(vcpu);
}
-int kvm_init_x86(struct kvm_x86_ops *ops, unsigned int vcpu_size,
+int kvm_init(struct kvm_x86_ops *ops, unsigned int vcpu_size,
struct module *module)
{
int r;
int cpu;
+ r = kvm_mmu_module_init();
+ if (r)
+ goto out4;
+
+ kvm_init_debug();
+
+ kvm_arch_init();
+
+ bad_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+
+ if (bad_page == NULL) {
+ r = -ENOMEM;
+ goto out;
+ }
+
if (kvm_x86_ops) {
printk(KERN_ERR "kvm: already loaded the other
module\n");
return -EEXIST;
@@ -1589,11 +1604,14 @@ out_free_0:
kvm_arch_hardware_unsetup();
out:
kvm_x86_ops = NULL;
+ kvm_exit_debug();
+ kvm_mmu_module_exit();
+out4:
return r;
}
-EXPORT_SYMBOL_GPL(kvm_init_x86);
+EXPORT_SYMBOL_GPL(kvm_init);
-void kvm_exit_x86(void)
+void kvm_exit(void)
{
misc_deregister(&kvm_dev);
kmem_cache_destroy(kvm_vcpu_cache);
@@ -1604,43 +1622,9 @@ void kvm_exit_x86(void)
on_each_cpu(hardware_disable, NULL, 0, 1);
kvm_arch_hardware_unsetup();
kvm_x86_ops = NULL;
-}
-EXPORT_SYMBOL_GPL(kvm_exit_x86);
-
-static __init int kvm_init(void)
-{
- int r;
-
- r = kvm_mmu_module_init();
- if (r)
- goto out4;
-
- kvm_init_debug();
-
- kvm_arch_init();
-
- bad_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
-
- if (bad_page == NULL) {
- r = -ENOMEM;
- goto out;
- }
-
- return 0;
-
-out:
- kvm_exit_debug();
- kvm_mmu_module_exit();
-out4:
- return r;
-}
-
-static __exit void kvm_exit(void)
-{
kvm_exit_debug();
__free_page(bad_page);
kvm_mmu_module_exit();
}
+EXPORT_SYMBOL_GPL(kvm_exit);
-module_init(kvm_init)
-module_exit(kvm_exit)
diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
index 95a3489..cc71a07 100644
--- a/drivers/kvm/svm.c
+++ b/drivers/kvm/svm.c
@@ -1716,13 +1716,13 @@ static struct kvm_x86_ops svm_x86_ops = {
static int __init svm_init(void)
{
- return kvm_init_x86(&svm_x86_ops, sizeof(struct vcpu_svm),
+ return kvm_init(&svm_x86_ops, sizeof(struct vcpu_svm),
THIS_MODULE);
}
static void __exit svm_exit(void)
{
- kvm_exit_x86();
+ kvm_exit();
}
module_init(svm_init)
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index da3a339..d5a77bc 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -2657,7 +2657,7 @@ static int __init vmx_init(void)
memset(iova, 0xff, PAGE_SIZE);
kunmap(vmx_io_bitmap_b);
- r = kvm_init_x86(&vmx_x86_ops, sizeof(struct vcpu_vmx),
THIS_MODULE);
+ r = kvm_init(&vmx_x86_ops, sizeof(struct vcpu_vmx),
THIS_MODULE);
if (r)
goto out1;
@@ -2678,7 +2678,7 @@ static void __exit vmx_exit(void)
__free_page(vmx_io_bitmap_b);
__free_page(vmx_io_bitmap_a);
- kvm_exit_x86();
+ kvm_exit();
}
module_init(vmx_init)
--
1.5.1.2
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
[kvm-devel] [PATCH 2/5] KVM: SVM: Fix SMP with kernel apic
AP processor needs to reset to the SIPI vector, not normal INIT.
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
---
drivers/kvm/svm.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
index 729f1cd..3910358 100644
--- a/drivers/kvm/svm.c
+++ b/drivers/kvm/svm.c
@@ -561,6 +561,12 @@ static void svm_vcpu_reset(struct kvm_vcpu *vcpu)
struct vcpu_svm *svm = to_svm(vcpu);
init_vmcb(svm->vmcb);
+
+ if (vcpu->vcpu_id != 0) {
+ svm->vmcb->save.rip = 0;
+ svm->vmcb->save.cs.base = svm->vcpu.sipi_vector << 12;
+ svm->vmcb->save.cs.selector = svm->vcpu.sipi_vector << 8;
+ }
}
static struct kvm_vcpu *svm_create_vcpu(struct kvm *kvm, unsigned int id)
--
1.5.3
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]0/5 Patch to split x86 specific code from kvm_main.c
Zhang, Xiantao wrote: > This series of patches are intended to further split x86 specific code > from kvm_main.c, and make kvm_main.c arch-independent. > For easy review, I splitted them into small patches. With these patches, > we almost finish the first stage work for code split. These patches don't apply on top of my git tree: Wende Patch 01-xiantao.patch an patching file drivers/kvm/kvm_main.c Hunk #1 succeeded at 17 with fuzz 2. Hunk #2 succeeded at 43 with fuzz 2. patching file drivers/kvm/x86.c Hunk #1 succeeded at 16 with fuzz 1. Hunk #2 FAILED at 26. 1 out of 2 hunks FAILED -- rejects in file drivers/kvm/x86.c - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1/5] KVM: x86 emulator: fix 'push imm8' emulation
'push imm8' found itself in the wrong switch somehow, so it is never executed.
This fixes Windows 2003 installation.
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
---
drivers/kvm/x86_emulate.c | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index a6ace30..da0cdd5 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -980,17 +980,6 @@ done_prefixes:
goto cannot_emulate;
dst.val = (s32) src.val;
break;
- case 0x6a: /* push imm8 */
- src.val = 0L;
- src.val = insn_fetch(s8, 1, _eip);
-push:
- dst.type = OP_MEM;
- dst.bytes = op_bytes;
- dst.val = src.val;
- register_address_increment(_regs[VCPU_REGS_RSP], -op_bytes);
- dst.ptr = (void *) register_address(ctxt->ss_base,
- _regs[VCPU_REGS_RSP]);
- break;
case 0x80 ... 0x83: /* Grp1 */
switch (modrm_reg) {
case 0:
@@ -1243,6 +1232,17 @@ special_insn:
register_address_increment(_regs[VCPU_REGS_RSP], op_bytes);
no_wb = 1; /* Disable writeback. */
break;
+ case 0x6a: /* push imm8 */
+ src.val = 0L;
+ src.val = insn_fetch(s8, 1, _eip);
+ push:
+ dst.type = OP_MEM;
+ dst.bytes = op_bytes;
+ dst.val = src.val;
+ register_address_increment(_regs[VCPU_REGS_RSP], -op_bytes);
+ dst.ptr = (void *) register_address(ctxt->ss_base,
+ _regs[VCPU_REGS_RSP]);
+ break;
case 0x6c: /* insb */
case 0x6d: /* insw/insd */
if (kvm_emulate_pio_string(ctxt->vcpu, NULL,
--
1.5.3
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH 1/2] KVM userspace: Add PCI device passthrough support
Hi,
Some remarks:
- rename the option to -pcidevice.
- Remove the directory passthrough and put the file directly in hw/.
Rename the file to something more explicit such as pci_passthrough*
- Suppress the files passthrough.h and neo_pci_tree.h
- pt_init should be called only if there are really devices. Moreover
the code should be disabled for non Linux hosts.
Can this support work if KVM is not used for CPU emulation ? Can it work
for non x86 targets ?
Regards,
Fabrice.
Amit Shah wrote:
> This patch introduces support for device passthrough
> from the host to a paravirtualized guest.
>
> A new command-line option, -passthrough is added.
> For example, to invoke it for an Ethernet device sitting at
> PCI bus:dev.fn 04:08.0 with host IRQ 18, use this:
>
> -passthrough Ethernet/04:08.0-18
>
> The host driver is to be removed before doing the passthrough.
>
> Signed-off-by: Amit Shah <[EMAIL PROTECTED]>
> ---
> qemu/Makefile |6 +-
> qemu/Makefile.target |4 +-
> qemu/exec.c|1 +
> qemu/hw/apic.c |2 +
> qemu/hw/passthrough/neo_pci_tree.h | 44 +++
> qemu/hw/passthrough/passthrough.c | 604
>
> qemu/hw/passthrough/passthrough.h | 64
> qemu/hw/pc.c |3 +
> qemu/hw/pci.c |5 +
> qemu/hw/piix_pci.c |6 +
> qemu/vl.c |6 +
> tools/pci_barsize.c| 53
> tools/pci_mmio.c | 82 +
> 13 files changed, 876 insertions(+), 4 deletions(-)
> create mode 100644 qemu/hw/passthrough/neo_pci_tree.h
> create mode 100644 qemu/hw/passthrough/passthrough.c
> create mode 100644 qemu/hw/passthrough/passthrough.h
> create mode 100644 tools/pci_barsize.c
> create mode 100644 tools/pci_mmio.c
>
> diff --git a/qemu/Makefile b/qemu/Makefile
> index 053c88c..3e599f3 100644
> --- a/qemu/Makefile
> +++ b/qemu/Makefile
> @@ -37,7 +37,7 @@ qemu-img$(EXESUF): qemu-img.c cutils.c block.c block-raw.c
> block-cow.c block-qco
> dyngen$(EXESUF): dyngen.c
> $(HOST_CC) $(CFLAGS) $(CPPFLAGS) $(BASE_CFLAGS) -o $@ $^
>
> -clean:
> +clean:
> # avoid old build problems by removing potentially incorrect old files
> rm -f config.mak config.h op-i386.h opc-i386.h gen-op-i386.h op-arm.h
> opc-arm.h gen-op-arm.h
> rm -f *.o *.a $(TOOLS) dyngen$(EXESUF) TAGS cscope.* *.pod *~ */*~
> @@ -88,8 +88,8 @@ endif
> test speed test2: all
> $(MAKE) -C tests $@
>
> -TAGS:
> - etags *.[ch] tests/*.[ch]
> +TAGS:
> + etags *.[ch] tests/*.[ch] hw/passthrough/*.[ch]
>
> cscope:
> rm -f ./cscope.*
> diff --git a/qemu/Makefile.target b/qemu/Makefile.target
> index 65f449e..9a96011 100644
> --- a/qemu/Makefile.target
> +++ b/qemu/Makefile.target
> @@ -24,7 +24,7 @@ ifeq ($(TARGET_ARCH), sparc64)
> TARGET_BASE_ARCH:=sparc
> endif
> TARGET_PATH=$(SRC_PATH)/target-$(TARGET_BASE_ARCH)
> -VPATH=$(SRC_PATH):$(TARGET_PATH):$(SRC_PATH)/hw:$(SRC_PATH)/audio
> +VPATH=$(SRC_PATH):$(TARGET_PATH):$(SRC_PATH)/hw:$(SRC_PATH)/hw/passthrough:$(SRC_PATH)/audio
> CPPFLAGS=-I. -I.. -I$(TARGET_PATH) -I$(SRC_PATH)
> ifdef CONFIG_DARWIN_USER
> VPATH+=:$(SRC_PATH)/darwin-user
> @@ -454,6 +454,8 @@ VL_OBJS+= ide.o pckbd.o ps2.o vga.o $(SOUND_HW) dma.o
> $(AUDIODRV)
> VL_OBJS+= fdc.o mc146818rtc.o serial.o i8259.o i8254.o pcspk.o pc.o
> VL_OBJS+= cirrus_vga.o apic.o parallel.o acpi.o piix_pci.o
> VL_OBJS+= usb-uhci.o smbus_eeprom.o vmmouse.o vmport.o vmware_vga.o
> +# passthrough support
> +VL_OBJS+= passthrough.o
> CPPFLAGS += -DHAS_AUDIO -DHAS_AUDIO_CHOICE
> endif
> ifeq ($(TARGET_BASE_ARCH), ppc)
> diff --git a/qemu/exec.c b/qemu/exec.c
> index 3e588d5..7a21ca5 100644
> --- a/qemu/exec.c
> +++ b/qemu/exec.c
> @@ -2484,6 +2484,7 @@ int cpu_register_io_memory(int io_index,
> if (io_mem_nb >= IO_MEM_NB_ENTRIES)
> return -1;
> io_index = io_mem_nb++;
> + fprintf(stderr, "iomem index %d out of %d\n", io_index,
> IO_MEM_NB_ENTRIES);
> } else {
> if (io_index >= IO_MEM_NB_ENTRIES)
> return -1;
> diff --git a/qemu/hw/apic.c b/qemu/hw/apic.c
> index 60d31fa..5b1bdf4 100644
> --- a/qemu/hw/apic.c
> +++ b/qemu/hw/apic.c
> @@ -349,6 +349,7 @@ static void apic_eoi(APICState *s)
> /* XXX: send the EOI packet to the APIC bus to allow the I/O APIC to
> set the remote IRR bit for level triggered interrupts. */
> apic_update_irq(s);
> +pt_ack_mirq(isrv);
> }
>
> static void apic_get_delivery_bitmask(uint32_t *deliver_bitmask,
> @@ -1122,6 +1123,7 @@ static void ioapic_mem_writel(void *opaque,
> target_phys_addr_t addr, uint32_t va
> } else {
> s->ioredtbl[index] &= ~0xULL;
> s->ioredtbl[index] |= val;
> +pt_set_vector(index, (val << 24) >> 24);
>
Re: [kvm-devel] [PATCH] 2/5 mov kvm_x86_ops to x86.c
Acked-by: Carsten Otte <[EMAIL PROTECTED]>
Zhang, Xiantao wrote:
> From 7473192cc0c529b8ce35c13d0e83a9b663072831 Mon Sep 17 00:00:00 2001
> From: Zhang Xiantao <[EMAIL PROTECTED]>
> Date: Wed, 7 Nov 2007 11:41:50 +0800
> Subject: [PATCH] mov kvm_x86_ops to x86.c for next step's work
> Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
> ---
> drivers/kvm/kvm_main.c |1 -
> drivers/kvm/x86.c |2 ++
> drivers/kvm/x86.h |2 ++
> 3 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index 010f079..f1cf8f0 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -55,7 +55,6 @@ static LIST_HEAD(vm_list);
>
> static cpumask_t cpus_hardware_enabled;
>
> -struct kvm_x86_ops *kvm_x86_ops;
> struct kmem_cache *kvm_vcpu_cache;
> EXPORT_SYMBOL_GPL(kvm_vcpu_cache);
>
> diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
> index 7ea470e..e26e46a 100644
> --- a/drivers/kvm/x86.c
> +++ b/drivers/kvm/x86.c
> @@ -44,6 +44,8 @@
>
> #define STAT_OFFSET(x) offsetof(struct kvm_vcpu, stat.x)
>
> +struct kvm_x86_ops *kvm_x86_ops;
> +
> struct kvm_stats_debugfs_item debugfs_entries[] = {
> { "pf_fixed", STAT_OFFSET(pf_fixed) },
> { "pf_guest", STAT_OFFSET(pf_guest) },
> diff --git a/drivers/kvm/x86.h b/drivers/kvm/x86.h
> index 663b822..ec32c26 100644
> --- a/drivers/kvm/x86.h
> +++ b/drivers/kvm/x86.h
> @@ -85,6 +85,8 @@ struct kvm_vcpu {
> struct x86_emulate_ctxt emulate_ctxt;
> };
>
> +extern struct kvm_x86_ops *kvm_x86_ops;
> +
> int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva, u32
> error_code);
>
> static inline void kvm_mmu_free_some_pages(struct kvm_vcpu *vcpu)
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] SMP support on AMD64
> 2007/11/8, Avi Kivity <[EMAIL PROTECTED]>: > > Lynn Kerby wrote: [snip] > > I'd assumed (there's *that* word) that core developer types were > > using KVM on all kinds of hardware and that basics like this would > > have been shaken out. > > Well, it is a reasonable assumption, but the sad fact is, we do little > regression testing on smp here, and Intel doesn't test AMD for some > reason. It used to work but regressed. > > That's something we need to improve on, and quickly. I'm counting on > Anthony's plan to flood the known universe with kvm-testing nanobots. Hi, I've noted that there's less posts from the AMD guys lately (Wei Huang, Joerg Roedel, Markus Rechberger), does it means that AMD decided to stop supporting KVM? If not, I think this is time for AMD to step in and use Anthony's tools to provide a regression testing platform the same way Intel does. It would be really sad to see AMD CPUS being a second class citizen in KVM... Just my 2 cents, Gildas - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] make msrs functions public for x86
Carlo Marcelo Arenas Belon wrote: > This patch partially reverts 9105435f46ca4e110237eae57272e4f5deaf8dd6 so that > kvm_msr_list, kvm_get_msrs and kvm_set_msrs are again public and visible in > userspace for x86 as they are used by qemu-kvm > Applied, thanks. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] 4/5 Combine kvm_init and kvm_init_x86 into onefunction (Correction V2)
Hi Avi
Please drop it, and use this one, due to version issue.
thanks
Xiantao
>From 959bc19b0e2ca7edcb3389aabdecf99ba9f1794e Mon Sep 17 00:00:00 2001
From: Zhang Xiantao <[EMAIL PROTECTED]>
Date: Thu, 8 Nov 2007 13:19:06 +0800
Subject: [PATCH] Combine kvm_init and kvm_init_x86 into one function,
and
meanwhile remove module_init module_exit function, since they will be
called
once new arch is registered.
Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
---
drivers/kvm/kvm.h |4 +-
drivers/kvm/kvm_main.c | 60
+--
drivers/kvm/svm.c |4 +-
drivers/kvm/vmx.c |4 +-
4 files changed, 28 insertions(+), 44 deletions(-)
diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
index 4b2421a..33b4629 100644
--- a/drivers/kvm/kvm.h
+++ b/drivers/kvm/kvm.h
@@ -494,9 +494,9 @@ void vcpu_load(struct kvm_vcpu *vcpu);
void vcpu_put(struct kvm_vcpu *vcpu);
-int kvm_init_x86(struct kvm_x86_ops *ops, unsigned int vcpu_size,
+int kvm_init(struct kvm_x86_ops *ops, unsigned int vcpu_size,
struct module *module);
-void kvm_exit_x86(void);
+void kvm_exit(void);
int kvm_mmu_module_init(void);
void kvm_mmu_module_exit(void);
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index da7fb22..8f09170 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -1503,12 +1503,27 @@ static void kvm_sched_out(struct
preempt_notifier *pn,
kvm_arch_vcpu_put(vcpu);
}
-int kvm_init_x86(struct kvm_x86_ops *ops, unsigned int vcpu_size,
+int kvm_init(struct kvm_x86_ops *ops, unsigned int vcpu_size,
struct module *module)
{
int r;
int cpu;
+ r = kvm_mmu_module_init();
+ if (r)
+ goto out4;
+
+ kvm_init_debug();
+
+ kvm_arch_init();
+
+ bad_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
+
+ if (bad_page == NULL) {
+ r = -ENOMEM;
+ goto out;
+ }
+
if (kvm_x86_ops) {
printk(KERN_ERR "kvm: already loaded the other
module\n");
return -EEXIST;
@@ -1589,11 +1604,14 @@ out_free_0:
kvm_arch_hardware_unsetup();
out:
kvm_x86_ops = NULL;
+ kvm_exit_debug();
+ kvm_mmu_module_exit();
+out44:
return r;
}
-EXPORT_SYMBOL_GPL(kvm_init_x86);
+EXPORT_SYMBOL_GPL(kvm_init);
-void kvm_exit_x86(void)
+void kvm_exit(void)
{
misc_deregister(&kvm_dev);
kmem_cache_destroy(kvm_vcpu_cache);
@@ -1604,43 +1622,9 @@ void kvm_exit_x86(void)
on_each_cpu(hardware_disable, NULL, 0, 1);
kvm_arch_hardware_unsetup();
kvm_x86_ops = NULL;
-}
-EXPORT_SYMBOL_GPL(kvm_exit_x86);
-
-static __init int kvm_init(void)
-{
- int r;
-
- r = kvm_mmu_module_init();
- if (r)
- goto out4;
-
- kvm_init_debug();
-
- kvm_arch_init();
-
- bad_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
-
- if (bad_page == NULL) {
- r = -ENOMEM;
- goto out;
- }
-
- return 0;
-
-out:
- kvm_exit_debug();
- kvm_mmu_module_exit();
-out4:
- return r;
-}
-
-static __exit void kvm_exit(void)
-{
kvm_exit_debug();
__free_page(bad_page);
kvm_mmu_module_exit();
}
+EXPORT_SYMBOL_GPL(kvm_exit);
-module_init(kvm_init)
-module_exit(kvm_exit)
diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
index 95a3489..cc71a07 100644
--- a/drivers/kvm/svm.c
+++ b/drivers/kvm/svm.c
@@ -1716,13 +1716,13 @@ static struct kvm_x86_ops svm_x86_ops = {
static int __init svm_init(void)
{
- return kvm_init_x86(&svm_x86_ops, sizeof(struct vcpu_svm),
+ return kvm_init(&svm_x86_ops, sizeof(struct vcpu_svm),
THIS_MODULE);
}
static void __exit svm_exit(void)
{
- kvm_exit_x86();
+ kvm_exit();
}
module_init(svm_init)
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index da3a339..d5a77bc 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -2657,7 +2657,7 @@ static int __init vmx_init(void)
memset(iova, 0xff, PAGE_SIZE);
kunmap(vmx_io_bitmap_b);
- r = kvm_init_x86(&vmx_x86_ops, sizeof(struct vcpu_vmx),
THIS_MODULE);
+ r = kvm_init(&vmx_x86_ops, sizeof(struct vcpu_vmx),
THIS_MODULE);
if (r)
goto out1;
@@ -2678,7 +2678,7 @@ static void __exit vmx_exit(void)
__free_page(vmx_io_bitmap_b);
__free_page(vmx_io_bitmap_a);
- kvm_exit_x86();
+ kvm_exit();
}
module_init(vmx_init)
--
1.5.1.2
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.s
Re: [kvm-devel] FreeBSD image hangs during boot
Avi Kivity a écrit : > Aurelien Jarno wrote: >> Well the IDE code hasn't changed a lot recently, so I checked the CVS >> history and easily (first test) found the commit that causes the problem: >> >> Last AIO patch, by Vladimir N. Oleynik. >> >> http://cvs.savannah.nongnu.org/viewvc/qemu/hw/ide.c?root=qemu&r1=1.64&r2=1.65 >> >> > > Have we learned something about this issue? Should I revert the patch > from kvm? Should qemu? > >From my side, I haven't found time to debug the problem. Instead I am reverting this patch locally each time I install qemu or kvm. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [Qemu-devel] [PATCH 1/2] KVM userspace: Add PCI device passthrough support
Fabrice Bellard wrote: Hi, Some remarks: - rename the option to -pcidevice. - Remove the directory passthrough and put the file directly in hw/. Rename the file to something more explicit such as pci_passthrough* - Suppress the files passthrough.h and neo_pci_tree.h - pt_init should be called only if there are really devices. Moreover the code should be disabled for non Linux hosts. Can this support work if KVM is not used for CPU emulation ? Can it work for non x86 targets ? This patchset can work without kvm (although not tested). It can do so using a kernel module that forwards irqs to userspace. I'm not sure it will make it into Linux kernel since it allows userspace irq handling. We actually try to convert the current patch to our in-kernel apic version that won't forward irqs to userspace and hence won't work without kvm. If you're interested in pass through to qemu/kqemu (seems like a cool feature) we can try to support both. Dor. Regards, Fabrice. Amit Shah wrote: > This patch introduces support for device passthrough > from the host to a paravirtualized guest. > > A new command-line option, -passthrough is added. > For example, to invoke it for an Ethernet device sitting at > PCI bus:dev.fn 04:08.0 with host IRQ 18, use this: > > -passthrough Ethernet/04:08.0-18 > > The host driver is to be removed before doing the passthrough. > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 4/5] KVM: x86 emulator: invd instruction
Emulate the 'invd' instruction (opcode 0f 08).
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
---
drivers/kvm/x86_emulate.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/kvm/x86_emulate.c b/drivers/kvm/x86_emulate.c
index da0cdd5..33b1814 100644
--- a/drivers/kvm/x86_emulate.c
+++ b/drivers/kvm/x86_emulate.c
@@ -167,7 +167,7 @@ static u8 opcode_table[256] = {
static u16 twobyte_table[256] = {
/* 0x00 - 0x0F */
0, SrcMem | ModRM | DstReg, 0, 0, 0, 0, ImplicitOps, 0,
- 0, ImplicitOps, 0, 0, 0, ImplicitOps | ModRM, 0, 0,
+ ImplicitOps, ImplicitOps, 0, 0, 0, ImplicitOps | ModRM, 0, 0,
/* 0x10 - 0x1F */
0, 0, 0, 0, 0, 0, 0, 0, ImplicitOps | ModRM, 0, 0, 0, 0, 0, 0, 0,
/* 0x20 - 0x2F */
@@ -1532,6 +1532,8 @@ twobyte_special_insn:
case 0x06:
emulate_clts(ctxt->vcpu);
break;
+ case 0x08: /* invd */
+ break;
case 0x09: /* wbinvd */
break;
case 0x0d: /* GrpP (prefetch) */
--
1.5.3
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0/5] KVM fixes for 2.6.24-rc2
I intend to submit the following patchset shortly for mainline. All fixes are for fairly serious issues, including host crashes. Several will go into -stable as well. Please review. drivers/kvm/svm.c | 18 ++ drivers/kvm/x86_emulate.c | 26 ++ 2 files changed, 28 insertions(+), 16 deletions(-) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 5/5] KVM: SVM: Intercept the 'invd' and 'wbinvd' instructions
'invd' can destroy host data, and 'wbinvd' allows the guest to induce long (milliseconds) latencies. Noted by Ben Serebrin. Signed-off-by: Avi Kivity <[EMAIL PROTECTED]> --- drivers/kvm/svm.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c index 7376805..7a6eead 100644 --- a/drivers/kvm/svm.c +++ b/drivers/kvm/svm.c @@ -494,6 +494,7 @@ static void init_vmcb(struct vmcb *vmcb) */ /* (1ULL << INTERCEPT_SELECTIVE_CR0) | */ (1ULL << INTERCEPT_CPUID) | + (1ULL << INTERCEPT_INVD) | (1ULL << INTERCEPT_HLT) | (1ULL << INTERCEPT_INVLPGA) | (1ULL << INTERCEPT_IOIO_PROT) | @@ -507,6 +508,7 @@ static void init_vmcb(struct vmcb *vmcb) (1ULL << INTERCEPT_STGI) | (1ULL << INTERCEPT_CLGI) | (1ULL << INTERCEPT_SKINIT) | + (1ULL << INTERCEPT_WBINVD) | (1ULL << INTERCEPT_MONITOR) | (1ULL << INTERCEPT_MWAIT); @@ -1247,6 +1249,7 @@ static int (*svm_exit_handlers[])(struct vcpu_svm *svm, [SVM_EXIT_VINTR]= interrupt_window_interception, /* [SVM_EXIT_CR0_SEL_WRITE] = emulate_on_interception, */ [SVM_EXIT_CPUID]= cpuid_interception, + [SVM_EXIT_INVD] = emulate_on_interception, [SVM_EXIT_HLT] = halt_interception, [SVM_EXIT_INVLPG] = emulate_on_interception, [SVM_EXIT_INVLPGA] = invalid_op_interception, @@ -1261,6 +1264,7 @@ static int (*svm_exit_handlers[])(struct vcpu_svm *svm, [SVM_EXIT_STGI] = invalid_op_interception, [SVM_EXIT_CLGI] = invalid_op_interception, [SVM_EXIT_SKINIT] = invalid_op_interception, + [SVM_EXIT_WBINVD] = emulate_on_interception, [SVM_EXIT_MONITOR] = invalid_op_interception, [SVM_EXIT_MWAIT]= invalid_op_interception, }; -- 1.5.3 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Bug: cpu0 unhandled rdmsr: 0x1900 and inject_general_protection
Trying to run the latest OLPC XO guest image with kvm-intel on 2.6.22 x86_64 (Ubuntu Gutsy) on a T7200 there are critical problems which don't occur if kvm-intel is not loaded/used. The same issue affects kvm-48, kvm-50 and kvm-51. I don't see these problems with Gutsy or Windows guests. The issues are: 1. Start-up of the image into GRUB is _slow_. The cursor can be seen scanning as the GRUB menu is drawn. It is *much* faster when kvm-intel isn't loaded/used. 2. After choosing a boot option the guest freezes and the host kern.log reports: kernel: [88380.014893] kvm: 12666: cpu0 unhandled rdmsr: 0x1900 kernel: [88380.014900] inject_general_protection: rip 0xc07211ab 3. Guest locks up at this point with host CPU being driven 100% and requires killing. I'm guessing they may be related to the OLPC kernel expecting an AMD Geode CPU? ./include/asm-i386/msr.h #define MSR_GEODE_BUSCONT_CONF0 0x1900 The OLPC disk image and configuration instructions are here: http://wiki.laptop.org/go/Emulating_the_XO/Quick_Start The configuration used here is: vdeq kvm -m 256 -hda olpc-redhat-stream-development-devel_ext3.ovl -soundhw es1370 -net nic,model=rtl8139,macaddr=56:44:45:30:32:31,vlan=0 -net vde,vlan=0 Is this a known issue - I couldn't find anything similar in searches of the mailing-list or bug-tracker ? Thanks. TJ. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]0/5 Patch to split x86 specific code from kvm_main.c
Hi,Carste Maybe some new commits block it. I will rebase them to latest commit, and resend :) Thanks for you try. Xiantao -Original Message- From: Carsten Otte [mailto:[EMAIL PROTECTED] Sent: 2007年11月8日 20:06 To: Zhang, Xiantao Cc: Avi Kivity; kvm-devel@lists.sourceforge.net; Hollis Blanchard; [EMAIL PROTECTED] Subject: Re: [PATCH]0/5 Patch to split x86 specific code from kvm_main.c Zhang, Xiantao wrote: > This series of patches are intended to further split x86 specific code > from kvm_main.c, and make kvm_main.c arch-independent. > For easy review, I splitted them into small patches. With these patches, > we almost finish the first stage work for code split. These patches don't apply on top of my git tree: Wende Patch 01-xiantao.patch an patching file drivers/kvm/kvm_main.c Hunk #1 succeeded at 17 with fuzz 2. Hunk #2 succeeded at 43 with fuzz 2. patching file drivers/kvm/x86.c Hunk #1 succeeded at 16 with fuzz 1. Hunk #2 FAILED at 26. 1 out of 2 hunks FAILED -- rejects in file drivers/kvm/x86.c - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] Bug: cpu0 unhandled rdmsr: 0x1900 and inject_general_protection
TJ wrote: Trying to run the latest OLPC XO guest image with kvm-intel on 2.6.22 x86_64 (Ubuntu Gutsy) on a T7200 there are critical problems which don't occur if kvm-intel is not loaded/used. The same issue affects kvm-48, kvm-50 and kvm-51. I don't see these problems with Gutsy or Windows guests. The issues are: 1. Start-up of the image into GRUB is _slow_. The cursor can be seen scanning as the GRUB menu is drawn. It is *much* faster when kvm-intel isn't loaded/used. 2. After choosing a boot option the guest freezes and the host kern.log reports: kernel: [88380.014893] kvm: 12666: cpu0 unhandled rdmsr: 0x1900 kernel: [88380.014900] inject_general_protection: rip 0xc07211ab 3. Guest locks up at this point with host CPU being driven 100% and requires killing. I'm guessing they may be related to the OLPC kernel expecting an AMD Geode CPU? ./include/asm-i386/msr.h #define MSR_GEODE_BUSCONT_CONF0 0x1900 Very likely. Try the attached patch. The guest may hang later with another bad msr; you can simply add more registers as necessary. I think we can add an API to do this from userspace, to avoid the need to patch the kernel for hundreds of no-op msrs. -- error compiling committee.c: too many arguments to function diff --git a/kernel/x86.c b/kernel/x86.c index e905d46..71307cb 100644 --- a/kernel/x86.c +++ b/kernel/x86.c @@ -460,6 +460,7 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata) case MSR_IA32_UCODE_REV: case MSR_IA32_PERF_STATUS: case MSR_IA32_EBL_CR_POWERON: + case MSR_GEODE_BUSCONT_CONF0: /* MTRR registers */ case 0xfe: case 0x200 ... 0x2ff: - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [ANNOUNCE] kvm-51 release
On Nov 8, 2007 12:51 AM, Avi Kivity <[EMAIL PROTECTED]> wrote: > Haydn Solomon wrote: > > First , thank you for new release of kvm. I have a few problems to > > report with kvm-51. > > > > 1. When running an exisiting winxp ACPI multiprocessor HAL with -smp > > 2, sometimes it will hang on boot. > > This isn't new. It isn't reported because few people run smp Windows, > as prior to FlexPriority/tpr-opt it was unbearably slow. > > I'll look unto it. thanks. > > > > 2. This may not be a major problem but cpu usage is a litte higher > > when idle on release 51 than 50. It was very low on 50, the lowest > > I've seen in a long time. > > It shouldn't have changed. What do you see? Can you provide a snapshot > of kvm_stat while Windows is idling (a few minutes after load)? I went back to kvm-50 and tested and realized that load now is about same as on kvm-51 now. However, since running release 50 I upgraded my kernel (Fedora 7) and didn't pay attention to load after the upgrade so I'm pretty sure this cpu usage thing is kernel related. > > > > 3. For me personally, the best performing release to date is release 50. > > kvm-51 shouldn't be all that different; it's mostly AMD stability > improvements and the FlexPriority smp fix. This opinion was really based on cpu usage but explained above. > > > > > > Regards > > > > Haydn > > > > Avi Kivity wrote: > >> If you're having trouble on AMD systems, please try this out. > >> > >> Changes from kvm-50: > >> - fix some x86 emulator one-byte insns (fixes W2K3 installer again) > >> - fix host hangs with NMI watchdog on AMD > >> - fix guest SMP on AMD > >> - fix dirty page tracking when clearing a guest page (Dor Laor) > >> - more portability work (Hollis Blanchard, Jerone Young) > >> - fix FlexPriority with guest smp (Sheng Yang) > >> - improve rpm specfile (Akio Takebe, me) > >> - fix external module vs portability work (Andrea Arcangeli) > >> - remove elpin bios due to license violation > >> - testsuite shutdown pio port > >> - don't advertise svm on the guest > >> - fix reset with kernel apic (Markus Rechberger) > >> > >> > >> Notes: > >> If you use the modules bundled with kvm-51, you can use any > version > >> of Linux from 2.6.9 upwards. > >> If you use the modules bundled with Linux 2.6.20, you need to use > >> kvm-12. > >> If you use the modules bundled with Linux 2.6.21, you need to use > >> kvm-17. > >> Modules from Linux 2.6.22 and up will work with any kvm version > from > >> kvm-22. Some features may only be available in newer releases. > >> For best performance, use Linux 2.6.23-rc2 or later as the host. > >> > >> http://kvm.qumranet.com > >> > >> > >> > - > >> This SF.net email is sponsored by: Splunk Inc. > >> Still grepping through log files to find problems? Stop. > >> Now Search log events and configuration files using AJAX and a browser. > >> Download your FREE copy of Splunk now >> http://get.splunk.com/ > >> ___ > >> kvm-devel mailing list > >> kvm-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/kvm-devel > >> > > adfdf > > > -- > Do not meddle in the internals of kernels, for they are subtle and quick > to panic. > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] SMP support on AMD64
Gildas wrote: > 2007/11/8, Avi Kivity <[EMAIL PROTECTED]>: > > Lynn Kerby wrote: [snip] > > I'd assumed (there's *that* word) that core developer types were > > using KVM on all kinds of hardware and that basics like this would > > have been shaken out. > > Well, it is a reasonable assumption, but the sad fact is, we do little > regression testing on smp here, and Intel doesn't test AMD for some > reason. It used to work but regressed. > > That's something we need to improve on, and quickly. I'm counting on > Anthony's plan to flood the known universe with kvm-testing nanobots. Hi, I've noted that there's less posts from the AMD guys lately (Wei Huang, Joerg Roedel, Markus Rechberger), does it means that AMD decided to stop supporting KVM? If not, I think this is time for AMD to step in and use Anthony's tools to provide a regression testing platform the same way Intel does. It would be really sad to see AMD CPUS being a second class citizen in KVM... Just my 2 cents, Gildas You're right about AMD status not matched Intel's at the moment. There was some time it was a bit neglected. AMD & Qumranet are working actively to fix it. KVM-51 supports XP & 2003 but has some issues with other OSs. We will soon solve all of these issues. There is also work in progress wrt regression testing. Thanks for the feedback, Dor. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [Resend ] [PATCH]0/5 Patch to split x86 specific code fromkvm_main.c, rebase to latest commits
Rebased to latest commits. Thanks Xiantao -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Zhang, Xiantao Sent: 2007年11月8日 21:00 To: [EMAIL PROTECTED] Cc: kvm-devel@lists.sourceforge.net; Hollis Blanchard; Avi Kivity Subject: Re: [kvm-devel] [PATCH]0/5 Patch to split x86 specific code fromkvm_main.c Hi,Carste Maybe some new commits block it. I will rebase them to latest commit, and resend :) Thanks for you try. Xiantao -Original Message- From: Carsten Otte [mailto:[EMAIL PROTECTED] Sent: 2007年11月8日 20:06 To: Zhang, Xiantao Cc: Avi Kivity; kvm-devel@lists.sourceforge.net; Hollis Blanchard; [EMAIL PROTECTED] Subject: Re: [PATCH]0/5 Patch to split x86 specific code from kvm_main.c Zhang, Xiantao wrote: > This series of patches are intended to further split x86 specific code > from kvm_main.c, and make kvm_main.c arch-independent. > For easy review, I splitted them into small patches. With these patches, > we almost finish the first stage work for code split. These patches don't apply on top of my git tree: Wende Patch 01-xiantao.patch an patching file drivers/kvm/kvm_main.c Hunk #1 succeeded at 17 with fuzz 2. Hunk #2 succeeded at 43 with fuzz 2. patching file drivers/kvm/x86.c Hunk #1 succeeded at 16 with fuzz 1. Hunk #2 FAILED at 26. 1 out of 2 hunks FAILED -- rejects in file drivers/kvm/x86.c 0001-Move-some-includes-to-x86.c-from-kvm_main.c-since-t.patch Description: 0001-Move-some-includes-to-x86.c-from-kvm_main.c-since-t.patch 0002-move-kvm_x86_ops-to-x86.c.patch Description: 0002-move-kvm_x86_ops-to-x86.c.patch 0003-Using-kvm_arch-prefix-to-redefine-kvm_x86_ops-ops-i.patch Description: 0003-Using-kvm_arch-prefix-to-redefine-kvm_x86_ops-ops-i.patch 0004-Combine-kvm_init-and-kvm_init_x86-into-one-kvm_init.patch Description: 0004-Combine-kvm_init-and-kvm_init_x86-into-one-kvm_init.patch 0005-Make-kvm_init-as-arch-indepenent-through-defining-a.patch Description: 0005-Make-kvm_init-as-arch-indepenent-through-defining-a.patch - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] virtio PCI device
Anthony Liguori wrote: > Avi Kivity wrote: >> Anthony Liguori wrote: >> >>> This is a PCI device that implements a transport for virtio. It >>> allows virtio >>> devices to be used by QEMU based VMMs like KVM or Xen. >>> >>> >> >> Didn't see support for dma. > > Not sure what you're expecting there. Using dma_ops in virtio_ring? > If a pci device is capable of dma (or issuing interrupts), it will be useless with pv pci. >> I think that with Amit's pvdma patches you >> can support dma-capable devices as well without too much fuss. >> > > What is the use case you're thinking of? A semi-paravirt driver that > does dma directly to a device? No, an unmodified driver that, by using clever tricks with dma_ops, can do dma directly to guest memory. See Amit's patches. In fact, why do a virtio transport at all? It can be done either with trap'n'emulate, or by directly mapping the device mmio space into the guest. (what use case are you considering? devices without interrupts and dma? pci door stoppers?) -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] virtio-blk PCI backend
Anthony Liguori wrote: > Avi Kivity wrote: >> Anthony Liguori wrote: >> >>> +case VIRTIO_PCI_QUEUE_NOTIFY: >>> +if (val < VIRTIO_PCI_QUEUE_MAX) >>> +virtio_ring_kick(vdev, &vdev->vq[val]); >>> +break; >>> >> >> I see you're not using hypercalls for this, presumably for compatibility >> with -no-kvm. > > More than just that. By stick to PIO, we are compatible with just > about any VMM. For instance, we get Xen support for free. If we used > hypercalls, even if we agreed on a way to determine which number to > use and how to make those calls, it would still be difficult to > implement in something like Xen. > But pio through the config space basically means you're committed to handling it in qemu. We want a more flexible mechanism. Detecting how to make hypercalls can be left to paravirt_ops. (for Xen you'd use an event channel; and for kvm the virtio kick hypercall). >> Well I think I have a solution: advertise vmcall, >> vmmcall, pio to some port, and int $some_vector as hypercall feature >> bits in cpuid (for kvm, kvm, qemu, and kvm-lite respectively). Early >> setup code could patch the instruction as appropriate (I hear code >> patching is now taught in second grade). >> > > That ties our device to our particular hypercall implementation. If > we were going to do this, I'd prefer to advertise it in the device I > think. I really would need to look at the performance though of > vmcall and an edge triggered interrupt. It would have to be pretty > compelling to warrant the additional complexity I think. vmcall costs will go down, and we don't want to use different mechanisms for high bandwidth and low bandwidth devices. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] 4/5 Combine kvm_init and kvm_init_x86 intoonefunction (Correction V3)
I agree with the gernal idea of this patch. Just a few minor things to
pick on:
Zhang, Xiantao wrote:
> diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
> index 4b2421a..33b4629 100644
> --- a/drivers/kvm/kvm.h
> +++ b/drivers/kvm/kvm.h
> @@ -494,9 +494,9 @@ void vcpu_load(struct kvm_vcpu *vcpu);
> void vcpu_put(struct kvm_vcpu *vcpu);
>
>
> -int kvm_init_x86(struct kvm_x86_ops *ops, unsigned int vcpu_size,
> +int kvm_init(struct kvm_x86_ops *ops, unsigned int vcpu_size,
> struct module *module);
> -void kvm_exit_x86(void);
> +void kvm_exit(void);
Renaming this makes sense to me.
> + r = kvm_mmu_module_init();
> + if (r)
> + goto out4;
This should go to kvm_arch_init. We don't want the shaddow-mmu module
on s390.
> + bad_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> +
> + if (bad_page == NULL) {
> + r = -ENOMEM;
> + goto out;
> + }
I don't think we need bad_page on s390, maybe I missed something. It's
only useful for mmu code as far as I can tell.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]3/5 Using kvm_arch prefix to define functions, and replace
Zhang, Xiantao wrote: > +void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu); > +void kvm_arch_vcpu_decache(struct kvm_vcpu *vcpu); > +void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu); > +void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu); > +struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm, unsigned int > id); > + > +int kvm_arch_vcpu_reset(struct kvm_vcpu *vcpu); > +void kvm_arch_hardware_enable(void *garbage); > +void kvm_arch_hardware_disable(void *garbage); > +int kvm_arch_hardware_setup(void); > +void kvm_arch_hardware_unsetup(void); > +void kvm_arch_check_processor_compat(void *rtn); I don't like the generic introduction of all x86_ops wrappers into the arch callbacks. I would rather prefer to work out a different split between common and arch specifics - at least in the following cases: - unloading the mmu needs to be moved out of kvm_free_vcpus into the arch part, because we don't have a shaddow mmu on s390 - decache_vcpus_on_cpu should be arch-dependent alltogether, rather than having a per cpu callback. We've got nothing to decache, so the entire thing is a nop for us. - vcpu_reset works very different for our architecture, we'd need an initial processor status word. I'd prefer to keep the existence of this callback arch dependent. - hardware enable/disable/setup/unsetup/check_processor_compat does not make any sense for us: all CPUs that have been sold since the 1970s have proper hardware virtualization, and there's nothing to enable - it just works. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] virtio-blk PCI backend
Avi Kivity wrote: > Anthony Liguori wrote: >> Avi Kivity wrote: >>> Anthony Liguori wrote: >>> +case VIRTIO_PCI_QUEUE_NOTIFY: +if (val < VIRTIO_PCI_QUEUE_MAX) +virtio_ring_kick(vdev, &vdev->vq[val]); +break; >>> >>> I see you're not using hypercalls for this, presumably for >>> compatibility >>> with -no-kvm. >> >> More than just that. By stick to PIO, we are compatible with just >> about any VMM. For instance, we get Xen support for free. If we >> used hypercalls, even if we agreed on a way to determine which number >> to use and how to make those calls, it would still be difficult to >> implement in something like Xen. >> > > But pio through the config space basically means you're committed to > handling it in qemu. We want a more flexible mechanism. There's no reason that the PIO operations couldn't be handled in the kernel. You'll already need some level of cooperation in userspace unless you plan on implementing the PCI bus in kernel space too. It's easy enough in the pci_map function in QEMU to just notify the kernel that it should listen on a particular PIO range. > Detecting how to make hypercalls can be left to paravirt_ops. > > (for Xen you'd use an event channel; and for kvm the virtio kick > hypercall). > >>> Well I think I have a solution: advertise vmcall, >>> vmmcall, pio to some port, and int $some_vector as hypercall feature >>> bits in cpuid (for kvm, kvm, qemu, and kvm-lite respectively). Early >>> setup code could patch the instruction as appropriate (I hear code >>> patching is now taught in second grade). >>> >> >> That ties our device to our particular hypercall implementation. If >> we were going to do this, I'd prefer to advertise it in the device I >> think. I really would need to look at the performance though of >> vmcall and an edge triggered interrupt. It would have to be pretty >> compelling to warrant the additional complexity I think. > > vmcall costs will go down, and we don't want to use different > mechanisms for high bandwidth and low bandwidth devices. vmcalls will certainly get faster but I doubt that the cost difference between vmcall and pio will ever be greater than a few hundred cycles. The only performance sensitive operation here would be the kick and I don't think a few hundred cycles in the kick path is ever going to be that significant for overall performance. So why introduce the extra complexity? Regards, Anthony Liguori > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] virtio PCI device
Avi Kivity wrote: > Anthony Liguori wrote: > >> This is a PCI device that implements a transport for virtio. It allows >> virtio >> devices to be used by QEMU based VMMs like KVM or Xen. >> >> >> > > Didn't see support for dma. Not sure what you're expecting there. Using dma_ops in virtio_ring? > I think that with Amit's pvdma patches you > can support dma-capable devices as well without too much fuss. > What is the use case you're thinking of? A semi-paravirt driver that does dma directly to a device? Regards, Anthony Liguori - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] 5/5 Make kvm_init as arch-indepenent
Acked-by: Carsten Otte <[EMAIL PROTECTED]>
Zhang, Xiantao wrote:
>>From 2d6ee07b96f1a91cef9327f241077af3698ed4dc Mon Sep 17 00:00:00 2001
> From: Zhang Xiantao <[EMAIL PROTECTED]>
> Date: Thu, 8 Nov 2007 13:37:38 +0800
> Subject: [PATCH] Make kvm_init as arch-indepenent, through defining a
> void
> pointer type variable. All archs will register their corresponding arch
> functions
> into kvm module. For example, x86 will use it to register vmx/svm's ops.
> Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
> ---
> drivers/kvm/kvm.h |5 +++--
> drivers/kvm/kvm_main.c | 26 ++
> drivers/kvm/x86.c | 27 ++-
> 3 files changed, 35 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
> index 33b4629..9b6087f 100644
> --- a/drivers/kvm/kvm.h
> +++ b/drivers/kvm/kvm.h
> @@ -494,7 +494,7 @@ void vcpu_load(struct kvm_vcpu *vcpu);
> void vcpu_put(struct kvm_vcpu *vcpu);
>
>
> -int kvm_init(struct kvm_x86_ops *ops, unsigned int vcpu_size,
> +int kvm_init(void *opaque, unsigned int vcpu_size,
> struct module *module);
> void kvm_exit(void);
>
> @@ -647,7 +647,8 @@ int kvm_arch_vcpu_ioctl_debug_guest(struct kvm_vcpu
> *vcpu,
> struct kvm_debug_guest *dbg);
> int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct kvm_run
> *kvm_run);
>
> -__init void kvm_arch_init(void);
> +int kvm_arch_init(void *opaque);
> +void kvm_arch_exit(void);
>
>
> void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu);
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index 8f09170..70bc4d4 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -1503,7 +1503,7 @@ static void kvm_sched_out(struct preempt_notifier
> *pn,
> kvm_arch_vcpu_put(vcpu);
> }
>
> -int kvm_init(struct kvm_x86_ops *ops, unsigned int vcpu_size,
> +int kvm_init(void *opaque, unsigned int vcpu_size,
> struct module *module)
> {
> int r;
> @@ -1515,7 +1515,9 @@ int kvm_init(struct kvm_x86_ops *ops, unsigned int
> vcpu_size,
>
> kvm_init_debug();
>
> - kvm_arch_init();
> + r = kvm_arch_init(opaque);
> + if (r)
> + goto out4;
>
> bad_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
>
> @@ -1524,22 +1526,6 @@ int kvm_init(struct kvm_x86_ops *ops, unsigned
> int vcpu_size,
> goto out;
> }
>
> - if (kvm_x86_ops) {
> - printk(KERN_ERR "kvm: already loaded the other
> module\n");
> - return -EEXIST;
> - }
> -
> - if (!ops->cpu_has_kvm_support()) {
> - printk(KERN_ERR "kvm: no hardware support\n");
> - return -EOPNOTSUPP;
> - }
> - if (ops->disabled_by_bios()) {
> - printk(KERN_ERR "kvm: disabled by bios\n");
> - return -EOPNOTSUPP;
> - }
> -
> - kvm_x86_ops = ops;
> -
> r = kvm_arch_hardware_setup();
> if (r < 0)
> goto out;
> @@ -1603,7 +1589,7 @@ out_free_1:
> out_free_0:
> kvm_arch_hardware_unsetup();
> out:
> - kvm_x86_ops = NULL;
> + kvm_arch_exit();
> kvm_exit_debug();
> kvm_mmu_module_exit();
> out4:
> @@ -1621,7 +1607,7 @@ void kvm_exit(void)
> unregister_cpu_notifier(&kvm_cpu_notifier);
> on_each_cpu(hardware_disable, NULL, 0, 1);
> kvm_arch_hardware_unsetup();
> - kvm_x86_ops = NULL;
> + kvm_arch_exit();
> kvm_exit_debug();
> __free_page(bad_page);
> kvm_mmu_module_exit();
> diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
> index 8aea240..22b3cc6 100644
> --- a/drivers/kvm/x86.c
> +++ b/drivers/kvm/x86.c
> @@ -1611,9 +1611,34 @@ int kvm_emulate_pio_string(struct kvm_vcpu *vcpu,
> struct kvm_run *run, int in,
> }
> EXPORT_SYMBOL_GPL(kvm_emulate_pio_string);
>
> -__init void kvm_arch_init(void)
> +int kvm_arch_init(void *opaque)
> {
> + struct kvm_x86_ops *ops = (struct kvm_x86_ops *)opaque;
> +
> kvm_init_msr_list();
> +
> + if (kvm_x86_ops) {
> + printk(KERN_ERR "kvm: already loaded the other
> module\n");
> + return -EEXIST;
> + }
> +
> + if (!ops->cpu_has_kvm_support()) {
> + printk(KERN_ERR "kvm: no hardware support\n");
> + return -EOPNOTSUPP;
> + }
> + if (ops->disabled_by_bios()) {
> + printk(KERN_ERR "kvm: disabled by bios\n");
> + return -EOPNOTSUPP;
> + }
> +
> + kvm_x86_ops = ops;
> +
> + return 0;
> +}
> +
> +void kvm_arch_exit(void)
> +{
> + kvm_x86_ops = NULL;
> }
>
> int kvm_emulate_halt(struct kvm_vcpu *vcpu)
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
__
Re: [kvm-devel] [RFC] virtio-blk PCI backend
Avi Kivity wrote: > Anthony Liguori wrote: > >> +case VIRTIO_PCI_QUEUE_NOTIFY: >> +if (val < VIRTIO_PCI_QUEUE_MAX) >> +virtio_ring_kick(vdev, &vdev->vq[val]); >> +break; >> >> > > I see you're not using hypercalls for this, presumably for compatibility > with -no-kvm. More than just that. By stick to PIO, we are compatible with just about any VMM. For instance, we get Xen support for free. If we used hypercalls, even if we agreed on a way to determine which number to use and how to make those calls, it would still be difficult to implement in something like Xen. > Well I think I have a solution: advertise vmcall, > vmmcall, pio to some port, and int $some_vector as hypercall feature > bits in cpuid (for kvm, kvm, qemu, and kvm-lite respectively). Early > setup code could patch the instruction as appropriate (I hear code > patching is now taught in second grade). > That ties our device to our particular hypercall implementation. If we were going to do this, I'd prefer to advertise it in the device I think. I really would need to look at the performance though of vmcall and an edge triggered interrupt. It would have to be pretty compelling to warrant the additional complexity I think. Regards, Anthony Liguori > (kvm could advertise all four, or maybe just the first two) > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] virtio PCI device
On Thursday 08 November 2007, Anthony Liguori wrote:
> +/* A PCI device has it's own struct device and so does a virtio device so
> + * we create a place for the virtio devices to show up in sysfs. I think it
> + * would make more sense for virtio to not insist on having it's own device.
> */
> +static struct device virtio_pci_root = {
> + .parent = NULL,
> + .bus_id = "virtio-pci",
> +};
> +
> +/* Unique numbering for devices under the kvm root */
> +static unsigned int dev_index;
> +
...
> +/* the PCI probing function */
> +static int __devinit virtio_pci_probe(struct pci_dev *pci_dev,
> + const struct pci_device_id *id)
> +{
> + struct virtio_pci_device *vp_dev;
> + int err;
> +
> + /* allocate our structure and fill it out */
> + vp_dev = kzalloc(sizeof(struct virtio_pci_device), GFP_KERNEL);
> + if (vp_dev == NULL)
> + return -ENOMEM;
> +
> + vp_dev->pci_dev = pci_dev;
> + vp_dev->vdev.dev.parent = &virtio_pci_root;
If you use
vp_dev->vdev.dev.parent = &pci_dev->dev;
Then there is no need for the special kvm root device, and the actual
virtio device shows up in a more logical place, under where it is
really (virtually) attached.
Arnd <><
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] IA64 KVM
On Thu, 2007-11-08 at 18:21 +0800, Zhang, Xiantao wrote: > Caleb Moore wrote: > > > Is such a merge likely in the near future or should we proceed in > > creating our own port? > > Hi, Caleb > We have completed kvm IA64 port until the end of Aug, and showed a > demo in kvm forum of Aug. Then, we could successfully boot windows, and > Linux guest on open guest firmware, and also got a reasonable > performance. Now, we are pushing the code into the upstream. But, the > whole community have to be working together to re-frame current kvm > source to accomendate new archs first, since current code is not frendly > to new archs support. So, the code should be pushing out in very near > future. :-) Hi Xiantao, Perhaps more people would be able to help restructure the tree to support more architectures if a snapshot of the kvm/ia64 code was made available. We might want to think about a kvm-ia64-devel mailing list too (such as ppc has already). Thanks, Alex -- Alex Williamson HP Open Source & Linux Org. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]3/5 Using kvm_arch prefix to definefunctions, and replace
Carsten Otte wrote: > Zhang, Xiantao wrote: >> +void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu); >> +void kvm_arch_vcpu_decache(struct kvm_vcpu *vcpu); >> +void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu); >> +void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu); >> +struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm, unsigned int >> id); + >> +int kvm_arch_vcpu_reset(struct kvm_vcpu *vcpu); >> +void kvm_arch_hardware_enable(void *garbage); >> +void kvm_arch_hardware_disable(void *garbage); >> +int kvm_arch_hardware_setup(void); >> +void kvm_arch_hardware_unsetup(void); >> +void kvm_arch_check_processor_compat(void *rtn); > I don't like the generic introduction of all x86_ops wrappers into the > arch callbacks. I would rather prefer to work out a different split > between common and arch specifics - at least in the following cases: > - unloading the mmu needs to be moved out of kvm_free_vcpus into the > arch part, because we don't have a shaddow mmu on s390 I think we have an old thread related to mmu code in kvm_main.c. In IA64, we haven't shadow mmu as well, but we still need mmu interfaces, such as mmu load, reload, unload to notify arch-specific VMM module about the memory changes. > - decache_vcpus_on_cpu should be arch-dependent alltogether, rather > than having a per cpu callback. We've got nothing to decache, so the > entire thing is a nop for us. Actually, IA64 doesn't require it. As you said, decache_vcpus_on_cpu is only needed by x86. > - vcpu_reset works very different for our architecture, we'd need an > initial processor status word. I'd prefer to keep the existence of > this callback arch dependent. Yes, I think kvm_arch_vcpu_reset in this patch should meet your requirement. > - hardware enable/disable/setup/unsetup/check_processor_compat does > not make any sense for us: all CPUs that have been sold since the > 1970s have proper hardware virtualization, and there's nothing to > enable - it just works. OK, Maybe we can move them to arch-specific. Avi, How about your ideas? Thanks Xiantao - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] virtio-blk PCI backend
Anthony Liguori wrote: > +case VIRTIO_PCI_QUEUE_NOTIFY: > +if (val < VIRTIO_PCI_QUEUE_MAX) > +virtio_ring_kick(vdev, &vdev->vq[val]); > +break; > I see you're not using hypercalls for this, presumably for compatibility with -no-kvm. >>> >>> More than just that. By stick to PIO, we are compatible with just >>> about any VMM. For instance, we get Xen support for free. If we >>> used hypercalls, even if we agreed on a way to determine which >>> number to use and how to make those calls, it would still be >>> difficult to implement in something like Xen. >>> >> >> But pio through the config space basically means you're committed to >> handling it in qemu. We want a more flexible mechanism. > > There's no reason that the PIO operations couldn't be handled in the > kernel. You'll already need some level of cooperation in userspace > unless you plan on implementing the PCI bus in kernel space too. It's > easy enough in the pci_map function in QEMU to just notify the kernel > that it should listen on a particular PIO range. With my new understanding of what this is all about, I suggest each virtqueue having an ID filled in by the host. This ID is globally unique, and is used as an argument for kick. It would map into a Xen domain id + event channel number, a number to be written into a pio port for kvm-lite or non-hypercall kvm, the argument for a kick hypercall on kvm, or whatever. This is independent of virtio-pci, which is good. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] virtio PCI device
Anthony Liguori wrote: > Avi Kivity wrote: >> If a pci device is capable of dma (or issuing interrupts), it will be >> useless with pv pci. > > Hrm, I think we may be talking about different things. Are you > thinking that the driver I posted allows you to do PCI pass-through > over virtio? That's not what it is. > > The driver I posted is a virtio implementation that uses a PCI > device. This lets you use virtio-blk and virtio-net under KVM. The > alternative to this virtio PCI device would be a virtio transport > built with hypercalls like lguest has. I choose a PCI device because > it ensured that each virtio device showed up like a normal PCI device. > > Am I misunderstanding what you're asking about? > No, I completely misunderstood the patch. Should review complete patches rather than random hunks. Sorry for the noise. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] 4/5 Combine kvm_init and kvm_init_x86 intoonefunction (Correction V3)
Carsten Otte wrote:
>
>> +bad_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
>> +
>> +if (bad_page == NULL) {
>> +r = -ENOMEM;
>> +goto out;
>> +}
> I don't think we need bad_page on s390, maybe I missed something. It's
> only useful for mmu code as far as I can tell.
Determined by the position of code realted to mmu :)
Xiantao
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] virtio-blk PCI backend
Anthony Liguori wrote: > Avi Kivity wrote: > >> Anthony Liguori wrote: >> >>> Avi Kivity wrote: >>> Anthony Liguori wrote: > +case VIRTIO_PCI_QUEUE_NOTIFY: > +if (val < VIRTIO_PCI_QUEUE_MAX) > +virtio_ring_kick(vdev, &vdev->vq[val]); > +break; > > I see you're not using hypercalls for this, presumably for compatibility with -no-kvm. >>> More than just that. By stick to PIO, we are compatible with just >>> about any VMM. For instance, we get Xen support for free. If we >>> used hypercalls, even if we agreed on a way to determine which number >>> to use and how to make those calls, it would still be difficult to >>> implement in something like Xen. >>> >>> >> But pio through the config space basically means you're committed to >> handling it in qemu. We want a more flexible mechanism. >> > > There's no reason that the PIO operations couldn't be handled in the > kernel. You'll already need some level of cooperation in userspace > unless you plan on implementing the PCI bus in kernel space too. It's > easy enough in the pci_map function in QEMU to just notify the kernel > that it should listen on a particular PIO range. > > This is a config space write, right? If so, the range is the regular 0xcf8-0xcff and it has to be very specially handled. >> Detecting how to make hypercalls can be left to paravirt_ops. >> >> (for Xen you'd use an event channel; and for kvm the virtio kick >> hypercall). >> >> Well I think I have a solution: advertise vmcall, vmmcall, pio to some port, and int $some_vector as hypercall feature bits in cpuid (for kvm, kvm, qemu, and kvm-lite respectively). Early setup code could patch the instruction as appropriate (I hear code patching is now taught in second grade). >>> That ties our device to our particular hypercall implementation. If >>> we were going to do this, I'd prefer to advertise it in the device I >>> think. I really would need to look at the performance though of >>> vmcall and an edge triggered interrupt. It would have to be pretty >>> compelling to warrant the additional complexity I think. >>> >> vmcall costs will go down, and we don't want to use different >> mechanisms for high bandwidth and low bandwidth devices. >> > > vmcalls will certainly get faster but I doubt that the cost difference > between vmcall and pio will ever be greater than a few hundred cycles. > The only performance sensitive operation here would be the kick and I > don't think a few hundred cycles in the kick path is ever going to be > that significant for overall performance. > > Why do you think the different will be a few hundred cycles? And if you have a large number of devices, searching the list becomes expensive too. > So why introduce the extra complexity? > Overall I think it reduces comlexity if we have in-kernel devices. Anyway we can add additional signalling methods later. -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] virtio PCI device
Avi Kivity wrote: > If a pci device is capable of dma (or issuing interrupts), it will be > useless with pv pci. Hrm, I think we may be talking about different things. Are you thinking that the driver I posted allows you to do PCI pass-through over virtio? That's not what it is. The driver I posted is a virtio implementation that uses a PCI device. This lets you use virtio-blk and virtio-net under KVM. The alternative to this virtio PCI device would be a virtio transport built with hypercalls like lguest has. I choose a PCI device because it ensured that each virtio device showed up like a normal PCI device. Am I misunderstanding what you're asking about? Regards, Anthony Liguori > >>> I think that with Amit's pvdma patches you >>> can support dma-capable devices as well without too much fuss. >>> >> >> What is the use case you're thinking of? A semi-paravirt driver that >> does dma directly to a device? > > No, an unmodified driver that, by using clever tricks with dma_ops, > can do dma directly to guest memory. See Amit's patches. > > In fact, why do a virtio transport at all? It can be done either with > trap'n'emulate, or by directly mapping the device mmio space into the > guest. > > > (what use case are you considering? devices without interrupts and > dma? pci door stoppers?) > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] virtio-blk PCI backend
Avi Kivity wrote: >> There's no reason that the PIO operations couldn't be handled in the >> kernel. You'll already need some level of cooperation in userspace >> unless you plan on implementing the PCI bus in kernel space too. >> It's easy enough in the pci_map function in QEMU to just notify the >> kernel that it should listen on a particular PIO range. >> >> > > This is a config space write, right? If so, the range is the regular > 0xcf8-0xcff and it has to be very specially handled. This is a per-device IO slot and as best as I can tell, the PCI device advertises the size of the region and the OS then identifies a range of PIO space to use and tells the PCI device about it. So we would just need to implement a generic userspace virtio PCI device in QEMU that did an ioctl to the kernel when this happened to tell the kernel what region to listen on for a particular device. >> vmcalls will certainly get faster but I doubt that the cost >> difference between vmcall and pio will ever be greater than a few >> hundred cycles. The only performance sensitive operation here would >> be the kick and I don't think a few hundred cycles in the kick path >> is ever going to be that significant for overall performance. >> >> > > Why do you think the different will be a few hundred cycles? The only difference in hardware between a PIO exit and a vmcall is that you don't have write out an exit reason in the VMC[SB]. So the performance difference between PIO/vmcall shouldn't be that great (and if it were, the difference would probably be obvious today). That's different from, say, a PF exit because with a PF, you also have to attempt to resolve it by walking the guest page table before determining that you do in fact need to exit. > And if you have a large number of devices, searching the list > becomes expensive too. The PIO address space is relatively small. You could do a radix tree or even a direct array lookup if you are concerned about performance. >> So why introduce the extra complexity? >> > > Overall I think it reduces comlexity if we have in-kernel devices. > Anyway we can add additional signalling methods later. In-kernel virtio backends add quite a lot of complexity. Just the mechanism to setup the device is complicated enough. I suspect that it'll be necessary down the road for performance but I certainly don't think it's a simplification. Regards, Anthony Liguori - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] make msrs functions public for x86
This would be my bad. Things kept changing and I didn't put these back into libkvm.h. On Thu, 2007-11-08 at 00:34 -0600, Carlo Marcelo Arenas Belon wrote: > This patch partially reverts 9105435f46ca4e110237eae57272e4f5deaf8dd6 so that > kvm_msr_list, kvm_get_msrs and kvm_set_msrs are again public and visible in > userspace for x86 as they are used by qemu-kvm > > Signed-off-by: Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> > --- > libkvm/kvm-x86.h |4 > libkvm/libkvm.h |6 ++ > 2 files changed, 6 insertions(+), 4 deletions(-) > > diff --git a/libkvm/kvm-x86.h b/libkvm/kvm-x86.h > index b531a3b..bcc6981 100644 > --- a/libkvm/kvm-x86.h > +++ b/libkvm/kvm-x86.h > @@ -42,8 +42,4 @@ int kvm_run_abi10(kvm_context_t kvm, int vcpu); > > void kvm_show_code(kvm_context_t kvm, int vcpu); > > -struct kvm_msr_list *kvm_get_msr_list(kvm_context_t); > -int kvm_get_msrs(kvm_context_t, int vcpu, struct kvm_msr_entry *msrs, int n); > -int kvm_set_msrs(kvm_context_t, int vcpu, struct kvm_msr_entry *msrs, int n); > - > #endif > diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h > index b00d658..8a41df7 100644 > --- a/libkvm/libkvm.h > +++ b/libkvm/libkvm.h > @@ -19,6 +19,12 @@ struct kvm_context; > > typedef struct kvm_context *kvm_context_t; > > +#if defined(__x86_64__) || defined(__i386__) > +struct kvm_msr_list *kvm_get_msr_list(kvm_context_t); > +int kvm_get_msrs(kvm_context_t, int vcpu, struct kvm_msr_entry *msrs, int n); > +int kvm_set_msrs(kvm_context_t, int vcpu, struct kvm_msr_entry *msrs, int n); > +#endif > + > /*! > * \brief KVM callbacks structure > * - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH] 4/5 Combine kvm_init and kvm_init_x86 intoonefunction (Correction V3)
Your mailer, which I'm guessing is Microsoft Outlook, is wrapping lines
and so this patch does not apply.
You might try using git-send-email or equivalent to avoid this issue.
--
Hollis Blanchard
IBM Linux Technology Center
On Thu, 2007-11-08 at 16:17 +0800, Zhang, Xiantao wrote:
> Hi Avi
> Seems my mailer has something wrong, and it always reference an
> old version. This should be a correct one. Sorry for inconvenience!
> Xiantao
>
> From 959bc19b0e2ca7edcb3389aabdecf99ba9f1794e Mon Sep 17 00:00:00 2001
> From: Zhang Xiantao <[EMAIL PROTECTED]>
> Date: Thu, 8 Nov 2007 13:19:06 +0800
> Subject: [PATCH] Combine kvm_init and kvm_init_x86 into one function,
> and
> meanwhile remove module_init module_exit function, since they will be
> called
> once new arch is registered.
> Signed-off-by: Zhang Xiantao <[EMAIL PROTECTED]>
> ---
> drivers/kvm/kvm.h |4 +-
> drivers/kvm/kvm_main.c | 60
> +--
> drivers/kvm/svm.c |4 +-
> drivers/kvm/vmx.c |4 +-
> 4 files changed, 28 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/kvm/kvm.h b/drivers/kvm/kvm.h
> index 4b2421a..33b4629 100644
> --- a/drivers/kvm/kvm.h
> +++ b/drivers/kvm/kvm.h
> @@ -494,9 +494,9 @@ void vcpu_load(struct kvm_vcpu *vcpu);
> void vcpu_put(struct kvm_vcpu *vcpu);
>
>
> -int kvm_init_x86(struct kvm_x86_ops *ops, unsigned int vcpu_size,
> +int kvm_init(struct kvm_x86_ops *ops, unsigned int vcpu_size,
> struct module *module);
> -void kvm_exit_x86(void);
> +void kvm_exit(void);
>
> int kvm_mmu_module_init(void);
> void kvm_mmu_module_exit(void);
> diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
> index da7fb22..8f09170 100644
> --- a/drivers/kvm/kvm_main.c
> +++ b/drivers/kvm/kvm_main.c
> @@ -1503,12 +1503,27 @@ static void kvm_sched_out(struct
> preempt_notifier *pn,
> kvm_arch_vcpu_put(vcpu);
> }
>
> -int kvm_init_x86(struct kvm_x86_ops *ops, unsigned int vcpu_size,
> +int kvm_init(struct kvm_x86_ops *ops, unsigned int vcpu_size,
> struct module *module)
> {
> int r;
> int cpu;
>
> + r = kvm_mmu_module_init();
> + if (r)
> + goto out4;
> +
> + kvm_init_debug();
> +
> + kvm_arch_init();
> +
> + bad_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> +
> + if (bad_page == NULL) {
> + r = -ENOMEM;
> + goto out;
> + }
> +
> if (kvm_x86_ops) {
> printk(KERN_ERR "kvm: already loaded the other
> module\n");
> return -EEXIST;
> @@ -1589,11 +1604,14 @@ out_free_0:
> kvm_arch_hardware_unsetup();
> out:
> kvm_x86_ops = NULL;
> + kvm_exit_debug();
> + kvm_mmu_module_exit();
> +out4:
> return r;
> }
> -EXPORT_SYMBOL_GPL(kvm_init_x86);
> +EXPORT_SYMBOL_GPL(kvm_init);
>
> -void kvm_exit_x86(void)
> +void kvm_exit(void)
> {
> misc_deregister(&kvm_dev);
> kmem_cache_destroy(kvm_vcpu_cache);
> @@ -1604,43 +1622,9 @@ void kvm_exit_x86(void)
> on_each_cpu(hardware_disable, NULL, 0, 1);
> kvm_arch_hardware_unsetup();
> kvm_x86_ops = NULL;
> -}
> -EXPORT_SYMBOL_GPL(kvm_exit_x86);
> -
> -static __init int kvm_init(void)
> -{
> - int r;
> -
> - r = kvm_mmu_module_init();
> - if (r)
> - goto out4;
> -
> - kvm_init_debug();
> -
> - kvm_arch_init();
> -
> - bad_page = alloc_page(GFP_KERNEL | __GFP_ZERO);
> -
> - if (bad_page == NULL) {
> - r = -ENOMEM;
> - goto out;
> - }
> -
> - return 0;
> -
> -out:
> - kvm_exit_debug();
> - kvm_mmu_module_exit();
> -out4:
> - return r;
> -}
> -
> -static __exit void kvm_exit(void)
> -{
> kvm_exit_debug();
> __free_page(bad_page);
> kvm_mmu_module_exit();
> }
> +EXPORT_SYMBOL_GPL(kvm_exit);
>
> -module_init(kvm_init)
> -module_exit(kvm_exit)
> diff --git a/drivers/kvm/svm.c b/drivers/kvm/svm.c
> index 95a3489..cc71a07 100644
> --- a/drivers/kvm/svm.c
> +++ b/drivers/kvm/svm.c
> @@ -1716,13 +1716,13 @@ static struct kvm_x86_ops svm_x86_ops = {
>
> static int __init svm_init(void)
> {
> - return kvm_init_x86(&svm_x86_ops, sizeof(struct vcpu_svm),
> + return kvm_init(&svm_x86_ops, sizeof(struct vcpu_svm),
> THIS_MODULE);
> }
>
> static void __exit svm_exit(void)
> {
> - kvm_exit_x86();
> + kvm_exit();
> }
>
> module_init(svm_init)
> diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
> index da3a339..d5a77bc 100644
> --- a/drivers/kvm/vmx.c
> +++ b/drivers/kvm/vmx.c
> @@ -2657,7 +2657,7 @@ static int __init vmx_init(void)
> memset(iova, 0xff, PAGE_SIZE);
> kunmap(vmx_io_bitmap_b);
>
> - r = kvm_init_x86(&vmx_x86_ops, sizeof(struct vcpu_vmx),
> THIS_MODULE);
> + r = kvm_init(&vmx_x86_ops, sizeof(struct vcpu_vmx),
> THIS_MODULE);
> if (r)
> goto out1;
>
> @@ -2678,7 +2678,7 @@ static void __exit vmx_exit(void)
> __fr
Re: [kvm-devel] [PATCH 3/3] virtio PCI device
On Thursday 08 November 2007, Anthony Liguori wrote:
> +/* A PCI device has it's own struct device and so does a virtio device so
> + * we create a place for the virtio devices to show up in sysfs. I think it
> + * would make more sense for virtio to not insist on having it's own device.
> */
> +static struct device virtio_pci_root = {
> + .parent = NULL,
> + .bus_id = "virtio-pci",
> +};
> +
> +/* Unique numbering for devices under the kvm root */
> +static unsigned int dev_index;
> +
...
> +/* the PCI probing function */
> +static int __devinit virtio_pci_probe(struct pci_dev *pci_dev,
> + const struct pci_device_id *id)
> +{
> + struct virtio_pci_device *vp_dev;
> + int err;
> +
> + /* allocate our structure and fill it out */
> + vp_dev = kzalloc(sizeof(struct virtio_pci_device), GFP_KERNEL);
> + if (vp_dev == NULL)
> + return -ENOMEM;
> +
> + vp_dev->pci_dev = pci_dev;
> + vp_dev->vdev.dev.parent = &virtio_pci_root;
If you use
vp_dev->vdev.dev.parent = &pci_dev->dev;
Then there is no need for the special kvm root device, and the actual
virtio device shows up in a more logical place, under where it is
really (virtually) attached.
Arnd <><
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] Fix declerations that should be in kvm-common.h & not in kvm-x86.h
# HG changeset patch # User Jerone Young <[EMAIL PROTECTED]> # Date 1194543880 21600 # Node ID f87e6f60ddd69cb0ee4e0bbcaed657d2f12311ce # Parent d6fa0d16fa60ee5083877fec698b69cea840d0b0 Fix declerations that should be in kvm-common.h & not in kvm-x86.h During the first phase of the refactoring these function declerations where not moved over to the kvm-common.h. Function decleartions include: kvm_alloc_kernel_memory kvm_alloc_userspace_memory kvm_create_kernel_phys_mem kvm_show_code kvm_run_abi10 Signed-off-by: Jerone Young <[EMAIL PROTECTED]> diff --git a/libkvm/kvm-common.h b/libkvm/kvm-common.h --- a/libkvm/kvm-common.h +++ b/libkvm/kvm-common.h @@ -55,6 +55,14 @@ int get_free_slot(kvm_context_t kvm); int get_free_slot(kvm_context_t kvm); void register_slot(int slot, unsigned long phys_addr); int get_slot(unsigned long phys_addr); + +int kvm_alloc_kernel_memory(kvm_context_t kvm, unsigned long memory, + void **vm_mem); +int kvm_alloc_userspace_memory(kvm_context_t kvm, unsigned long memory, + void **vm_mem); +void *kvm_create_kernel_phys_mem(kvm_context_t kvm, unsigned long phys_start, + unsigned long len, int log, int writable); + void kvm_memory_region_save_params(kvm_context_t kvm, struct kvm_memory_region *mem); void kvm_userspace_memory_region_save_params(kvm_context_t kvm, @@ -67,6 +75,10 @@ int kvm_arch_create_default_phys_mem(kvm unsigned long phys_mem_bytes, void **vm_mem); +void kvm_show_code(kvm_context_t kvm, int vcpu); +int kvm_run_abi10(kvm_context_t kvm, int vcpu); + + int handle_halt(kvm_context_t kvm, int vcpu); int handle_shutdown(kvm_context_t kvm, int vcpu); void post_kvm_run(kvm_context_t kvm, int vcpu); diff --git a/libkvm/kvm-x86.h b/libkvm/kvm-x86.h --- a/libkvm/kvm-x86.h +++ b/libkvm/kvm-x86.h @@ -20,27 +20,10 @@ #include "kvm-common.h" -#include "kvm-common.h" - #define PAGE_SIZE 4096ul #define PAGE_MASK (~(PAGE_SIZE - 1)) - -int kvm_alloc_kernel_memory(kvm_context_t kvm, unsigned long memory, - void **vm_mem); - -int kvm_alloc_userspace_memory(kvm_context_t kvm, unsigned long memory, - void **vm_mem); - int kvm_set_tss_addr(kvm_context_t kvm, unsigned long addr); - - -void *kvm_create_kernel_phys_mem(kvm_context_t kvm, unsigned long phys_start, - unsigned long len, int log, int writable); - -int kvm_run_abi10(kvm_context_t kvm, int vcpu); - -void kvm_show_code(kvm_context_t kvm, int vcpu); struct kvm_msr_list *kvm_get_msr_list(kvm_context_t); int kvm_get_msrs(kvm_context_t, int vcpu, struct kvm_msr_entry *msrs, int n); - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 11 of 17] Move msrs functions to libkvm-x86.c
On Thu, 2007-11-08 at 07:54 +0200, Avi Kivity wrote: > Carlo Marcelo Arenas Belon wrote: > > On Tue, Nov 06, 2007 at 10:48:52AM -0600, Jerone Young wrote: > > > >> Move msrs functions to libkvm-x86.c > >> > >> This patch moves functions: > >>kvm_msr_list > >>move kvm_get_msrs > >>move kvm_set_msrs > >> > > > > the problem is that with this the definitions were moved as well from > > libkvm.h > > to kvm-x86.h which is private and not meant to be exported outside of libkvm > > but those 3 functions are used by qemu-kvm.c as shown by : > > > > > > They need to be moved back to libkvm.h with a #ifdef. And to the #ifdef > purists I say: deorbit. Re-entry is looking rough; things are much better up here. ;) Anyways, you don't need to ifdef a prototype; just don't call it. Also, naming them kvm_x86_get_msrs() and kvm_x86_set_msrs() would be a much better warning sign for callers. -- Hollis Blanchard IBM Linux Technology Center - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] virtio PCI device
Arnd Bergmann wrote:
> On Thursday 08 November 2007, Anthony Liguori wrote:
>
>> +/* A PCI device has it's own struct device and so does a virtio device so
>> + * we create a place for the virtio devices to show up in sysfs. I think it
>> + * would make more sense for virtio to not insist on having it's own
>> device. */
>> +static struct device virtio_pci_root = {
>> + .parent = NULL,
>> + .bus_id = "virtio-pci",
>> +};
>> +
>> +/* Unique numbering for devices under the kvm root */
>> +static unsigned int dev_index;
>> +
>>
>
> ...
>
>
>> +/* the PCI probing function */
>> +static int __devinit virtio_pci_probe(struct pci_dev *pci_dev,
>> + const struct pci_device_id *id)
>> +{
>> + struct virtio_pci_device *vp_dev;
>> + int err;
>> +
>> + /* allocate our structure and fill it out */
>> + vp_dev = kzalloc(sizeof(struct virtio_pci_device), GFP_KERNEL);
>> + if (vp_dev == NULL)
>> + return -ENOMEM;
>> +
>> + vp_dev->pci_dev = pci_dev;
>> + vp_dev->vdev.dev.parent = &virtio_pci_root;
>>
>
> If you use
>
> vp_dev->vdev.dev.parent = &pci_dev->dev;
>
> Then there is no need for the special kvm root device, and the actual
> virtio device shows up in a more logical place, under where it is
> really (virtually) attached.
>
They already show up underneath of the PCI bus. The issue is that there
are two separate 'struct device's for each virtio device. There's the
PCI device (that's part of the pci_dev structure) and then there's the
virtio_device one. I thought that setting the dev.parent of the
virtio_device struct device would result in having two separate entries
under the PCI bus directory which would be pretty confusing :-)
Regards,
Anthony Liguori
> Arnd <><
>
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] rsyncing to Guest Ubuntu System
I have been testing KVM for eventual use in a production server environment and am running into some trouble when I attempt to rsync my data from the current production system to the test system. Specifically, whenever I hit a large file, the guest freezes and I get the following in the host's system log: Nov 8 16:14:20 vcr1 kernel: [2847590.399951] kvm: 10680: cpu0 unhandled wrmsr: 0xc1 Nov 8 16:14:20 vcr1 kernel: [2847590.399959] inject_general_protection: rip 0xc01162ff I have Googled the error, but can't see anything that leads me to believe that I've made any errors in the configuration. Other things seem to work fine, but I can reproduce this freeze every time. Here's a recap of my environment... CPU Model: Intel Xeon 5130 2.0 Ghz KVM Version: 50 Host Kernel: Linux version 2.6.20-16-generic ([EMAIL PROTECTED]) (gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #2 SMP Sun Sep 23 18:31:23 UTC 2007 Host Kernel Arch: i386 Guest: Ubuntu Gutsy (i386) QEMU Command Line: /opt/kvm/bin/qemu-system-x86_64 -hda /home/kvm/images.d/w5.img -boot c -m 384 -net nic,macaddr=00:14:1C:30:AF:03 -net tap,ifname=tap3,script=no -daemonize -vnc :3 Thanks for any pointers you can provide. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] virtio PCI device
Anthony Liguori wrote: > Avi Kivity wrote: > >> Anthony Liguori wrote: >> >> >>> This is a PCI device that implements a transport for virtio. It allows >>> virtio >>> devices to be used by QEMU based VMMs like KVM or Xen. >>> >>> >>> >>> >> Didn't see support for dma. >> > > Not sure what you're expecting there. Using dma_ops in virtio_ring? > > >> I think that with Amit's pvdma patches you >> can support dma-capable devices as well without too much fuss. >> >> > > What is the use case you're thinking of? A semi-paravirt driver that > does dma directly to a device? > > Regards, > > Anthony Liguori > > You would also lose performance since pv-dma will trigger an exit for each virtio io while virtio kicks the hypervisor after several IOs were queued. > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] rsyncing to Guest Ubuntu System
Clive Stewell wrote: > I have been testing KVM for eventual use in a production server > environment and am running into some trouble when I attempt to rsync my > data from the current production system to the test system. > Specifically, whenever I hit a large file, the guest freezes and I get > the following in the host's system log: > > Nov 8 16:14:20 vcr1 kernel: [2847590.399951] kvm: 10680: cpu0 unhandled > wrmsr: 0xc1 > Nov 8 16:14:20 vcr1 kernel: [2847590.399959] inject_general_protection: > rip 0xc01162ff > > I have Googled the error, but can't see anything that leads me to > believe that I've made any errors in the configuration. Other things > seem to work fine, but I can reproduce this freeze every time. Here's a > recap of my environment... > > CPU Model: Intel Xeon 5130 2.0 Ghz > KVM Version: 50 > Host Kernel: Linux version 2.6.20-16-generic ([EMAIL PROTECTED]) (gcc version > 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #2 SMP Sun Sep 23 18:31:23 UTC 2007 > Host Kernel Arch: i386 > Guest: Ubuntu Gutsy (i386) > QEMU Command Line: /opt/kvm/bin/qemu-system-x86_64 -hda > /home/kvm/images.d/w5.img -boot c -m 384 -net > nic,macaddr=00:14:1C:30:AF:03 -net tap,ifname=tap3,script=no -daemonize > -vnc :3 > > Thanks for any pointers you can provide. > > You can try this [Not tested]: diff --git a/kernel/x86.c b/kernel/x86.c index e905d46..71307cb 100644 --- a/kernel/x86.c +++ b/kernel/x86.c @@ -460,6 +460,7 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata) case MSR_IA32_UCODE_REV: case MSR_IA32_PERF_STATUS: case MSR_IA32_EBL_CR_POWERON: + case 0xc1: /* MTRR registers */ case 0xfe: case 0x200 ... 0x2ff: > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] virtio-blk PCI backend
Anthony Liguori wrote:
> This still needs quite a lot of work but I wanted to post it for reference.
>
> Regards,
>
> Anthony Liguori
>
> diff --git a/qemu/Makefile.target b/qemu/Makefile.target
>
...
Why change Rusty's codding standard? It will be harder to track changes.
> +typedef struct VRingDesc
> +{
> +uint64_t addr;
> +uint32_t len;
> +uint16_t flags;
> +uint16_t next;
> +} VRingDesc;
> +
> +typedef struct VRingAvail
> +{
> +uint16_t flags;
> +uint16_t idx;
> +uint16_t ring[0];
> +} VRingAvail;
> +
> +typedef struct VRingUsedElem
> +{
> +uint32_t id;
> +uint32_t len;
> +} VRingUsedElem;
> +
> +typedef struct VRingUsed
> +{
> +uint16_t flags;
> +uint16_t idx;
> +VRingUsedElem ring[0];
> +} VRingUsed;
> +
> +typedef struct VRing
> +{
> +unsigned int num;
> +VRingDesc *desc;
> +VRingAvail *avail;
> +VRingUsed *used;
> +} VRing;
> +
> +static void virtio_ioport_write(void *opaque, uint32_t addr, uint32_t val)
> +{
> +VirtIODevice *vdev = to_virtio_device(opaque);
> +ram_addr_t pa;
> +
> +addr -= vdev->addr;
> +
> +switch (addr) {
> +case VIRTIO_PCI_GUEST_FEATURES:
> + if (vdev->set_features)
> + vdev->set_features(vdev->opaque, val);
> + vdev->features = val;
> + break;
> +case VIRTIO_PCI_QUEUE_PFN:
> + pa = (ram_addr_t)val << TARGET_PAGE_BITS;
> + vdev->vq[vdev->queue_sel].pfn = val;
>
Some validity checks are missing, you assume you have the queue_sel.
> + if (pa < (ram_size - TARGET_PAGE_SIZE))
> + vring_init(&vdev->vq[vdev->queue_sel], phys_ram_base + pa);
> + break;
> +case VIRTIO_PCI_QUEUE_SEL:
> + if (val < VIRTIO_PCI_QUEUE_MAX)
> + vdev->queue_sel = val;
> + break;
> +case VIRTIO_PCI_QUEUE_NOTIFY:
> + if (val < VIRTIO_PCI_QUEUE_MAX)
> + virtio_ring_kick(vdev, &vdev->vq[val]);
> + break;
> +case VIRTIO_PCI_STATUS:
> + vdev->status = val & 0xFF;
>
we should keep another internal status and it will track the
initialization of all the above fields (
pfn, queue_sel,..) the device will be active once all of them were
initialized by the guest
> + break;
> +default:
> + if (addr >= VIRTIO_PCI_CONFIG && vdev->set_config)
> + vdev->set_config(vdev->opaque, addr - VIRTIO_PCI_CONFIG, val);
> + break;
> +}
> +}
> +
>
What about having block/net/9p.. in separate files? It will grow over time.
> +#include
> +#include
> +
> +#define BLK_MAX_QUEUE_SIZE 127
> +
> +static bool virtio_blk_handle_request(BlockDriverState *bs,
> + VirtIODevice *vdev, VirtQueue *vq)
> +{
> +struct iovec iov[vq->vring.num];
> +unsigned int head, out_num, in_num, wlen;
> +struct virtio_blk_inhdr *in;
> +struct virtio_blk_outhdr *out;
> +
Great job, Dor.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 0/3] Kvm clocksource, new spin
Hi folks, Here's a new spin of the clocksource implementation. In this new version: * followed avi's suggestion of: - letting the cpu itself register its memory area. - using a gfn instead of a phys addr as a parameter, to be sure we can cover the whole memory area - write guest time at exits. Also, I 'm not using an anonymous struct in the kvm_hv_clock union, so the vcpu struct can grab just what it needs, and not the whole padding the guest needs This is it. Have fun - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] 2.6.23 git current compile error on UP
drivers/kvm/kvm_main.c: In function `kvm_flush_remote_tlbs': drivers/kvm/kvm_main.c:220: error: implicit declaration of function `smp_call_function_mask' make[2]: *** [drivers/kvm/kvm_main.o] Error 1 make[1]: *** [drivers/kvm] Error 2 http://sr71.net/~dave/linux/config-kvm-up Looks like that function calls smp_call_function_mask() which is never defined for UP. Nobody else uses it that way, so I'm not sure what the right fix is. I'm not even sure kvm_flush_remote_tlbs() is safe with its raw_smp_processor_id() use. Is there a reason it can't get preempted? -- Dave - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] IA64 KVM
Akio Takebe wrote: > Hi, Alex and Xiantao > >> Perhaps more people would be able to help restructure the tree to >> support more architectures if a snapshot of the kvm/ia64 code was >> made available. We might want to think about a kvm-ia64-devel >> mailing list too (such as ppc has already). Thanks, >> > I also think so. :) H, Alex/Akio Thanks for your suggestions. It is a surely good idea to create a IA64 mailing list to talk about the IA64-KVM. But now we have to rebase them to latest commits before sending out, since the kvm source layout changed much recently. Once the final source layout comes out, we will send out the source code soon. I believe it should happen in very near future. :-) Best wishes Xiantao - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] virtio-blk PCI backend
Dor Laor wrote:
> Anthony Liguori wrote:
>> This still needs quite a lot of work but I wanted to post it for
>> reference.
>>
>> Regards,
>>
>> Anthony Liguori
>>
>> diff --git a/qemu/Makefile.target b/qemu/Makefile.target
>>
> ...
> Why change Rusty's codding standard? It will be harder to track changes.
Because Linux kernel coding standards aren't QEMU coding standards.
Besides, this is supposed to be an ABI so it shouldn't be changing all
that much :-)
I posted the QEMU bits as soon as I got it working. I still have a lot
to do in it however I have addressed some of the things you brought up
already.
>> +case VIRTIO_PCI_QUEUE_PFN:
>> +pa = (ram_addr_t)val << TARGET_PAGE_BITS;
>> +vdev->vq[vdev->queue_sel].pfn = val;
>>
> Some validity checks are missing, you assume you have the queue_sel.
Yes, the code is carefully written so that queue_sel is always valid.
>> +if (pa < (ram_size - TARGET_PAGE_SIZE))
>> +vring_init(&vdev->vq[vdev->queue_sel], phys_ram_base + pa);
>> +break;
>> +case VIRTIO_PCI_QUEUE_SEL:
>> +if (val < VIRTIO_PCI_QUEUE_MAX)
>> +vdev->queue_sel = val;
>> +break;
>> +case VIRTIO_PCI_QUEUE_NOTIFY:
>> +if (val < VIRTIO_PCI_QUEUE_MAX)
>> +virtio_ring_kick(vdev, &vdev->vq[val]);
>> +break;
>> +case VIRTIO_PCI_STATUS:
>> +vdev->status = val & 0xFF;
>>
> we should keep another internal status and it will track the
> initialization of all the above fields (
> pfn, queue_sel,..) the device will be active once all of them were
> initialized by the guest
Hrm, I don't follow. The only thing that has to be written to by the
guest is the PFN which also has the effect of activating the queue.
>> +break;
>> +default:
>> +if (addr >= VIRTIO_PCI_CONFIG && vdev->set_config)
>> +vdev->set_config(vdev->opaque, addr - VIRTIO_PCI_CONFIG, val);
>> +break;
>> +}
>> +}
>> +
>>
>
> What about having block/net/9p.. in separate files? It will grow over
> time.
Yup, already have that in my own queue.
The latest version queue for the kernel side is at
http://hg.codemonkey.ws/virtio-pci (based on the master branch of
Rusty's virtio tree). The latest queue for the QEMU side is at
http://hg.codemonkey.ws/qemu-virtio. I have a functioning block and 9p
transport. I'll continue cleaning up tomorrow and will hopefully post
another set of patches early next week.
Unfortunately, I uncovered a bug in the in-kernel APIC code today so you
need to run with -no-kvm-irqchip if you want to use multiple virtio
devices at once :-/
Regards,
Anthony Liguori
>> +#include
>> +#include
>> +
>> +#define BLK_MAX_QUEUE_SIZE127
>> +
>> +static bool virtio_blk_handle_request(BlockDriverState *bs,
>> + VirtIODevice *vdev, VirtQueue *vq)
>> +{
>> +struct iovec iov[vq->vring.num];
>> +unsigned int head, out_num, in_num, wlen;
>> +struct virtio_blk_inhdr *in;
>> +struct virtio_blk_outhdr *out;
>> +
> Great job, Dor.
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] [v2] Fix declerations that should be in kvm-common.h & not in kvm-x86.h
# HG changeset patch # User Jerone Young <[EMAIL PROTECTED]> # Date 1194560092 21600 # Node ID 10991ad11487e51d327430a1a61e0d63021caf7b # Parent 026c26ab068482aaf17deaf8cd73c1ff1db3806b [v2] Fix declerations that should be in kvm-common.h & not in kvm-x86.h The last version of this patch was based on yesterdays Hg tree. There have been changes today. So this updates them so you don't need to Avi. During the first phase of the refactoring these function declerations where not moved over to the kvm-common.h. Function decleartions include: kvm_alloc_kernel_memory kvm_alloc_userspace_memory kvm_create_kernel_phys_mem kvm_show_code kvm_run_abi10 Signed-off-by: Jerone Young <[EMAIL PROTECTED]> diff --git a/libkvm/kvm-common.h b/libkvm/kvm-common.h --- a/libkvm/kvm-common.h +++ b/libkvm/kvm-common.h @@ -57,11 +57,24 @@ void register_slot(int slot, unsigned lo int user_alloc, unsigned long userspace_addr); void free_slot(int slot); int get_slot(unsigned long phys_addr); + +int kvm_alloc_kernel_memory(kvm_context_t kvm, unsigned long memory, + void **vm_mem); +int kvm_alloc_userspace_memory(kvm_context_t kvm, unsigned long memory, + void **vm_mem); +void *kvm_create_kernel_phys_mem(kvm_context_t kvm, unsigned long phys_start, + unsigned long len, int log, int writable); + + int kvm_arch_create(kvm_context_t kvm, unsigned long phys_mem_bytes, void **vm_mem); int kvm_arch_create_default_phys_mem(kvm_context_t kvm, unsigned long phys_mem_bytes, void **vm_mem); + +void kvm_show_code(kvm_context_t kvm, int vcpu); +int kvm_run_abi10(kvm_context_t kvm, int vcpu); + int handle_halt(kvm_context_t kvm, int vcpu); int handle_shutdown(kvm_context_t kvm, int vcpu); diff --git a/libkvm/kvm-x86.h b/libkvm/kvm-x86.h --- a/libkvm/kvm-x86.h +++ b/libkvm/kvm-x86.h @@ -20,26 +20,9 @@ #include "kvm-common.h" -#include "kvm-common.h" - #define PAGE_SIZE 4096ul #define PAGE_MASK (~(PAGE_SIZE - 1)) - -int kvm_alloc_kernel_memory(kvm_context_t kvm, unsigned long memory, - void **vm_mem); - -int kvm_alloc_userspace_memory(kvm_context_t kvm, unsigned long memory, - void **vm_mem); - int kvm_set_tss_addr(kvm_context_t kvm, unsigned long addr); - -void *kvm_create_kernel_phys_mem(kvm_context_t kvm, unsigned long phys_start, - unsigned long len, int log, int writable); - -int kvm_run_abi10(kvm_context_t kvm, int vcpu); - -void kvm_show_code(kvm_context_t kvm, int vcpu); - #endif - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 2/3] kvmclock - the host part.
This is the host part of kvm clocksource implementation. As it does
not include clockevents, it is a fairly simple implementation. We
only have to register a per-vcpu area, and start writting to it periodically.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
drivers/kvm/kvm_main.c |1 +
drivers/kvm/x86.c | 32
drivers/kvm/x86.h |4
3 files changed, 37 insertions(+), 0 deletions(-)
diff --git a/drivers/kvm/kvm_main.c b/drivers/kvm/kvm_main.c
index d095002..c2c79b8 100644
--- a/drivers/kvm/kvm_main.c
+++ b/drivers/kvm/kvm_main.c
@@ -1243,6 +1243,7 @@ static long kvm_dev_ioctl(struct file *filp,
case KVM_CAP_MMU_SHADOW_CACHE_CONTROL:
case KVM_CAP_USER_MEMORY:
case KVM_CAP_SET_TSS_ADDR:
+ case KVM_CAP_CLOCKSOURCE:
r = 1;
break;
default:
diff --git a/drivers/kvm/x86.c b/drivers/kvm/x86.c
index e905d46..ef31fed 100644
--- a/drivers/kvm/x86.c
+++ b/drivers/kvm/x86.c
@@ -19,6 +19,7 @@
#include "segment_descriptor.h"
#include "irq.h"
+#include
#include
#include
#include
@@ -1628,6 +1629,28 @@ int kvm_emulate_halt(struct kvm_vcpu *vcpu)
}
EXPORT_SYMBOL_GPL(kvm_emulate_halt);
+static void kvm_write_guest_time(struct kvm_vcpu *vcpu)
+{
+ struct timespec ts;
+ int r;
+
+ if (!vcpu->clock_gpa)
+ return;
+
+ /* Updates version to the next odd number, indicating we're writing */
+ vcpu->hv_clock.version++;
+ kvm_write_guest(vcpu->kvm, vcpu->clock_gpa, &vcpu->hv_clock, PAGE_SIZE);
+
+ kvm_get_msr(vcpu, MSR_IA32_TIME_STAMP_COUNTER,
+ &vcpu->hv_clock.last_tsc);
+
+ ktime_get_ts(&ts);
+ vcpu->hv_clock.now_ns = ts.tv_nsec + (NSEC_PER_SEC * (u64)ts.tv_sec);
+ vcpu->hv_clock.wc_sec = get_seconds();
+ vcpu->hv_clock.version++;
+ kvm_write_guest(vcpu->kvm, vcpu->clock_gpa, &vcpu->hv_clock, PAGE_SIZE);
+}
+
int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
{
unsigned long nr, a0, a1, a2, a3, ret;
@@ -1648,7 +1671,15 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
a3 &= 0x;
}
+ ret = 0;
switch (nr) {
+ case KVM_HCALL_REGISTER_CLOCK:
+
+ vcpu->clock_gpa = a0 << PAGE_SHIFT;
+ vcpu->hv_clock.tsc_mult = clocksource_khz2mult(tsc_khz, 22);
+
+ break;
+
default:
ret = -KVM_ENOSYS;
break;
@@ -1924,6 +1955,7 @@ out:
goto preempted;
}
+ kvm_write_guest_time(vcpu);
post_kvm_run_save(vcpu, kvm_run);
return r;
diff --git a/drivers/kvm/x86.h b/drivers/kvm/x86.h
index 663b822..fd77b66 100644
--- a/drivers/kvm/x86.h
+++ b/drivers/kvm/x86.h
@@ -83,6 +83,10 @@ struct kvm_vcpu {
/* emulate context */
struct x86_emulate_ctxt emulate_ctxt;
+
+ struct kvm_hv_clock_s hv_clock;
+ gpa_t clock_gpa; /* guest frame number, physical addr */
+
};
int kvm_mmu_page_fault(struct kvm_vcpu *vcpu, gva_t gva, u32 error_code);
--
1.5.0.6
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 1/3] include files for kvmclock
This patch introduces the include files for kvm clock.
They'll be needed for both guest and host part.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
include/asm-x86/kvm_para.h | 25 +
include/linux/kvm.h|1 +
include/linux/kvm_para.h |2 ++
3 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/include/asm-x86/kvm_para.h b/include/asm-x86/kvm_para.h
index c6f3fd8..0f6b813 100644
--- a/include/asm-x86/kvm_para.h
+++ b/include/asm-x86/kvm_para.h
@@ -10,15 +10,40 @@
* paravirtualization, the appropriate feature bit should be checked.
*/
#define KVM_CPUID_FEATURES 0x4001
+#define KVM_FEATURE_CLOCKSOURCE 0
#ifdef __KERNEL__
#include
+extern void kvmclock_init(void);
+
+/*
+ * Guest has page alignment and padding requirements. At the host, it will
+ * only lead to wasted space at the vcpu struct. For this reason, the struct
+ * is not anonymous
+ */
+union kvm_hv_clock {
+ struct kvm_hv_clock_s {
+ u64 tsc_mult;
+ u64 now_ns;
+ /* That's the wall clock, not the water closet */
+ u64 wc_sec;
+ u64 last_tsc;
+ /* At first, we could use the tsc value as a marker, but Jeremy
+* well noted that it will cause us locking problems in 32-bit
+* sys, so we have a special version field */
+ u32 version;
+ } fields;
+ char page_align[PAGE_SIZE];
+};
+
/* This instruction is vmcall. On non-VT architectures, it will generate a
* trap that we will then rewrite to the appropriate instruction.
*/
#define KVM_HYPERCALL ".byte 0x0f,0x01,0xc1"
+#define KVM_HCALL_REGISTER_CLOCK 1
+
/* For KVM hypercalls, a three-byte sequence of either the vmrun or the vmmrun
* instruction. The hypervisor may replace it with something else but only the
* instructions are guaranteed to be supported.
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 71d33d6..9862241 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -359,6 +359,7 @@ struct kvm_signal_mask {
#define KVM_CAP_MMU_SHADOW_CACHE_CONTROL 2
#define KVM_CAP_USER_MEMORY 3
#define KVM_CAP_SET_TSS_ADDR 4
+#define KVM_CAP_CLOCKSOURCE 5
/*
* ioctls for VM fds
diff --git a/include/linux/kvm_para.h b/include/linux/kvm_para.h
index e4db25f..094efc7 100644
--- a/include/linux/kvm_para.h
+++ b/include/linux/kvm_para.h
@@ -11,6 +11,8 @@
/* Return values for hypercalls */
#define KVM_ENOSYS 1000
+#define KVM_EINVAL 1019
+#define KVM_ENODEV 1022
#ifdef __KERNEL__
/*
--
1.5.0.6
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]3/5 Using kvm_arch prefix to define functions, and replace
On Thu, 2007-11-08 at 14:49 +0100, Carsten Otte wrote: > Zhang, Xiantao wrote: > > +void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu); > > +void kvm_arch_vcpu_decache(struct kvm_vcpu *vcpu); > > +void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu); > > +void kvm_arch_vcpu_put(struct kvm_vcpu *vcpu); > > +struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm, unsigned int > > id); > > + > > +int kvm_arch_vcpu_reset(struct kvm_vcpu *vcpu); > > +void kvm_arch_hardware_enable(void *garbage); > > +void kvm_arch_hardware_disable(void *garbage); > > +int kvm_arch_hardware_setup(void); > > +void kvm_arch_hardware_unsetup(void); > > +void kvm_arch_check_processor_compat(void *rtn); > I don't like the generic introduction of all x86_ops wrappers into the > arch callbacks. I would rather prefer to work out a different split > between common and arch specifics - at least in the following cases: > - unloading the mmu needs to be moved out of kvm_free_vcpus into the > arch part, because we don't have a shaddow mmu on s390 > - decache_vcpus_on_cpu should be arch-dependent alltogether, rather > than having a per cpu callback. We've got nothing to decache, so the > entire thing is a nop for us. > - vcpu_reset works very different for our architecture, we'd need an > initial processor status word. I'd prefer to keep the existence of > this callback arch dependent. > - hardware enable/disable/setup/unsetup/check_processor_compat does not > make any sense for us: all CPUs that have been sold since the 1970s have > proper hardware virtualization, and there's nothing to enable - it just > works. Sounds fine to me: you're just proposing to move the abstraction one level higher in some places. -- Hollis Blanchard IBM Linux Technology Center - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] 2.6.23 git current compile error on UP
Le jeudi 08 novembre 2007 à 11:55 -0800, Dave Hansen a écrit : > drivers/kvm/kvm_main.c: In function `kvm_flush_remote_tlbs': > drivers/kvm/kvm_main.c:220: error: implicit declaration of function > `smp_call_function_mask' > make[2]: *** [drivers/kvm/kvm_main.o] Error 1 > make[1]: *** [drivers/kvm] Error 2 > > http://sr71.net/~dave/linux/config-kvm-up > > Looks like that function calls smp_call_function_mask() which is never > defined for UP. Nobody else uses it that way, so I'm not sure what the > right fix is. I'm not even sure kvm_flush_remote_tlbs() is safe with > its raw_smp_processor_id() use. Is there a reason it can't get > preempted? Avi has already posted a patch to correct this. http://lkml.org/lkml/2007/10/24/95 Laurent signature.asc Description: Ceci est une partie de message numériquement signée - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH] Fix building of kvmctl
# HG changeset patch # User Jerone Young <[EMAIL PROTECTED]> # Date 1194551969 21600 # Node ID c08b2667a95ecd85effb1d5f5d84e235f9e8d6cc # Parent d6fa0d16fa60ee5083877fec698b69cea840d0b0 Fix building of kvmctl This patch creates the make rule needed to for the linker to link libkvm archive and main.o object to compile kvmctl correctly. Also fixes order at which objects are seen when linking, so that they can link correctly. Signed-off-by: Jerone Young <[EMAIL PROTECTED]> diff --git a/user/Makefile b/user/Makefile --- a/user/Makefile +++ b/user/Makefile @@ -31,6 +31,7 @@ kvmctl: LDFLAGS += -pthread -lrt kvmctl: LDFLAGS += -pthread -lrt kvmctl: $(kvmctl_objs) + $(CC) $(LDFLAGS) $^ -o $@ %.flat: %.o $(CC) $(CFLAGS) -nostdlib -o $@ -Wl,-T,flat.lds $^ diff --git a/user/config-x86-common.mak b/user/config-x86-common.mak --- a/user/config-x86-common.mak +++ b/user/config-x86-common.mak @@ -2,7 +2,7 @@ all: kvmctl test_cases -kvmctl_objs=../libkvm/libkvm.a main.o +kvmctl_objs= main.o ../libkvm/libkvm.a balloon_ctl: balloon_ctl.o - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] virtio-blk PCI backend
Avi Kivity wrote: > Anthony Liguori wrote: > >> +case VIRTIO_PCI_QUEUE_NOTIFY: >> +if (val < VIRTIO_PCI_QUEUE_MAX) >> +virtio_ring_kick(vdev, &vdev->vq[val]); >> +break; >> > > I see you're not using hypercalls for this, presumably for > compatibility > with -no-kvm. More than just that. By stick to PIO, we are compatible with just about any VMM. For instance, we get Xen support for free. If we used hypercalls, even if we agreed on a way to determine which number to use and how to make those calls, it would still be difficult to implement in something like Xen. >>> >>> But pio through the config space basically means you're committed to >>> handling it in qemu. We want a more flexible mechanism. >> >> There's no reason that the PIO operations couldn't be handled in the >> kernel. You'll already need some level of cooperation in userspace >> unless you plan on implementing the PCI bus in kernel space too. >> It's easy enough in the pci_map function in QEMU to just notify the >> kernel that it should listen on a particular PIO range. > > With my new understanding of what this is all about, I suggest each > virtqueue having an ID filled in by the host. This ID is globally > unique, and is used as an argument for kick. It would map into a Xen > domain id + event channel number, a number to be written into a pio > port for kvm-lite or non-hypercall kvm, the argument for a kick > hypercall on kvm, or whatever. Yeah, right now, I maintain a virtqueue "selector" within virtio-pci and use that for notification. This index is also exposed in the config->find_vq() within virtio. Changing that to an opaque ID would require introducing another mechanism to enumerate the virtqueues since you couldn't just start from 0 and keep going until you hit an invalid virtqueue. I'm not sure I'm convinced that you couldn't just hide this "id" notion in the virtio-xen implementation if you needed to. Regards, Anthony Liguori > This is independent of virtio-pci, which is good. > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]3/5 Using kvm_arch prefix to define functions, and replace
On Thu, 2007-11-08 at 15:21 +0800, Zhang, Xiantao wrote: > @@ -890,7 +890,7 @@ static int kvm_vm_ioctl_create_vcpu(struct kvm > *kvm, > int n) > if (!valid_vcpu(n)) > return -EINVAL; > > - vcpu = kvm_x86_ops->vcpu_create(kvm, n); > + vcpu = kvm_arch_vcpu_create(kvm, n); > if (IS_ERR(vcpu)) > return PTR_ERR(vcpu); > > @@ -900,7 +900,7 @@ static int kvm_vm_ioctl_create_vcpu(struct kvm > *kvm, > int n) > BUG_ON((unsigned long)&vcpu->host_fx_image & 0xF); > > vcpu_load(vcpu); > - r = kvm_x86_ops->vcpu_reset(vcpu); > + r = kvm_arch_vcpu_reset(vcpu); > if (r == 0) > r = kvm_mmu_setup(vcpu); > vcpu_put(vcpu); > @@ -933,7 +933,7 @@ mmu_unload: > vcpu_put(vcpu); > > free_vcpu: > - kvm_x86_ops->vcpu_free(vcpu); > + kvm_arch_vcpu_free(vcpu); > return r; > } Have a look at the patch I posted on Wednesday: "[PATCH 2 of 2] RFC: Create kvm_arch_vcpu_create()". kvm_arch_vcpu_create() will actually encompass more logic from kvm_vm_ioctl_create_vcpu(), and once you do that, kvm_arch_vcpu_reset() doesn't need to exist (which will also make Carsten happy). -- Hollis Blanchard IBM Linux Technology Center - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [PATCH 3/3] kvmclock implementation, the guest part.
This is the guest part of kvm clock implementation
It does not do tsc-only timing, as tsc can have deltas
between cpus, and it did not seem worthy to me to keep
adjusting them.
We do use it, however, for fine-grained adjustment.
Other than that, time comes from the host.
Signed-off-by: Glauber de Oliveira Costa <[EMAIL PROTECTED]>
---
arch/x86/Kconfig.i386 | 10 +++
arch/x86/kernel/Makefile_32 |1 +
arch/x86/kernel/kvmclock.c | 171 +++
arch/x86/kernel/setup_32.c |5 +
4 files changed, 187 insertions(+), 0 deletions(-)
create mode 100644 arch/x86/kernel/kvmclock.c
diff --git a/arch/x86/Kconfig.i386 b/arch/x86/Kconfig.i386
index 7331efe..5fe4025 100644
--- a/arch/x86/Kconfig.i386
+++ b/arch/x86/Kconfig.i386
@@ -257,6 +257,16 @@ config VMI
at the moment), by linking the kernel to a GPL-ed ROM module
provided by the hypervisor.
+config KVM_CLOCK
+ bool "KVM paravirtualized clock"
+ select PARAVIRT
+ help
+ Turning on this option will allow you to run a paravirtualized clock
+ when running over the KVM hypervisor. Instead of relying on a PIT
+ (or probably other) emulation by the underlying device model, the host
+ provides the guest with timing infrastructure, as time of day, and
+ timer expiration.
+
source "arch/x86/lguest/Kconfig"
endif
diff --git a/arch/x86/kernel/Makefile_32 b/arch/x86/kernel/Makefile_32
index b9d6798..df76d8c 100644
--- a/arch/x86/kernel/Makefile_32
+++ b/arch/x86/kernel/Makefile_32
@@ -43,6 +43,7 @@ obj-$(CONFIG_K8_NB) += k8.o
obj-$(CONFIG_MGEODE_LX)+= geode_32.o mfgpt_32.o
obj-$(CONFIG_VMI) += vmi_32.o vmiclock_32.o
+obj-$(CONFIG_KVM_CLOCK)+= kvmclock.o
obj-$(CONFIG_PARAVIRT) += paravirt_32.o
obj-y += pcspeaker.o
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
new file mode 100644
index 000..df14613
--- /dev/null
+++ b/arch/x86/kernel/kvmclock.c
@@ -0,0 +1,171 @@
+/* KVM paravirtual clock driver. A clocksource implementation
+Copyright (C) 2007 Glauber de Oliveira Costa, Red Hat Inc.
+
+This program is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2 of the License, or
+(at your option) any later version.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with this program; if not, write to the Free Software
+Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#define KVM_SCALE 22
+
+#define get_clock(cpu, field) hv_clock[cpu].fields.field
+
+static int kvmclock = 1;
+
+static int parse_no_kvmclock(char *arg)
+{
+ kvmclock = 0;
+ return 0;
+}
+early_param("no-kvmclock", parse_no_kvmclock);
+
+/* The hypervisor will put information about time periodically here */
+union kvm_hv_clock hv_clock[NR_CPUS] __attribute__((__aligned__(PAGE_SIZE)));
+
+static inline u64 kvm_get_delta(u64 last_tsc)
+{
+ int cpu = smp_processor_id();
+ u64 delta = native_read_tsc() - last_tsc;
+ return (delta * get_clock(cpu, tsc_mult)) >> KVM_SCALE;
+}
+
+/*
+ * The wallclock is the time of day when we booted. Since then, some time may
+ * have elapsed since the hypervisor wrote the data. So we try to account for
+ * that. Even if the tsc is not accurate, it gives us a more accurate timing
+ * than not adjusting at all
+ */
+unsigned long kvm_get_wallclock(void)
+{
+ u64 wc_sec, delta, last_tsc;
+ struct timespec ts;
+ int version, nsec, cpu = smp_processor_id();
+
+ do {
+ version = get_clock(cpu, version);
+ rmb();
+ last_tsc = get_clock(cpu, last_tsc);
+ rmb();
+ wc_sec = get_clock(cpu, wc_sec);
+ rmb();
+ } while ((get_clock(cpu, version) != version) && !(version & 1));
+
+ delta = kvm_get_delta(last_tsc);
+ nsec = do_div(delta, NSEC_PER_SEC);
+ set_normalized_timespec(&ts, wc_sec + delta, nsec);
+
+ /*
+* Of all mechanisms of time adjustment I've tested, this one
+* was the champion!
+*/
+ return ts.tv_sec + 1;
+}
+
+int kvm_set_wallclock(unsigned long now)
+{
+ return 0;
+}
+
+/*
+ * This is our read_clock function. The host puts an tsc timestamp each time
+ * it updates a new time, and then we can use it to derive a slightly more
+ * precise notion of elapsed time, converted to nano
[kvm-devel] git-clone error?
Hi everybody, I'm trying to clone the repository: git-clone http://www.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git kvm Fail on this: error: Couldn't get http://www.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git/refs/heads/kvm-updates for heads/kvm-updates The requested URL returned error: 404 error: Could not interpret heads/kvm-updates as something to pull Anything wrong? Thanks. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] virtio PCI device
Anthony Liguori wrote:
> This is a PCI device that implements a transport for virtio. It allows virtio
> devices to be used by QEMU based VMMs like KVM or Xen.
>
>
>
While it's a little premature, we can start thinking of irq path
improvements.
The current patch acks a private isr and afterwards apic eoi will also
be hit since its
a level trig irq. This means 2 vmexits per irq.
We can start with regular pci irqs and move afterwards to msi.
Some other ugly hack options [we're better use msi]:
- Read the eoi directly from apic and save the first private isr ack
- Convert the specific irq line to edge triggered and dont share it
What do you guys think?
> +/* A small wrapper to also acknowledge the interrupt when it's handled.
> + * I really need an EIO hook for the vring so I can ack the interrupt once we
> + * know that we'll be handling the IRQ but before we invoke the callback
> since
> + * the callback may notify the host which results in the host attempting to
> + * raise an interrupt that we would then mask once we acknowledged the
> + * interrupt. */
> +static irqreturn_t vp_interrupt(int irq, void *opaque)
> +{
> + struct virtio_pci_device *vp_dev = opaque;
> + struct virtio_pci_vq_info *info;
> + irqreturn_t ret = IRQ_NONE;
> + u8 isr;
> +
> + /* reading the ISR has the effect of also clearing it so it's very
> + * important to save off the value. */
> + isr = ioread8(vp_dev->ioaddr + VIRTIO_PCI_ISR);
> +
> + /* It's definitely not us if the ISR was not high */
> + if (!isr)
> + return IRQ_NONE;
> +
> + spin_lock(&vp_dev->lock);
> + list_for_each_entry(info, &vp_dev->virtqueues, node) {
> + if (vring_interrupt(irq, info->vq) == IRQ_HANDLED)
> + ret = IRQ_HANDLED;
> + }
> + spin_unlock(&vp_dev->lock);
> +
> + return ret;
> +}
>
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] IA64 KVM
Hi, Alex and Xiantao > Perhaps more people would be able to help restructure the tree to >support more architectures if a snapshot of the kvm/ia64 code was made >available. We might want to think about a kvm-ia64-devel mailing list >too (such as ppc has already). Thanks, > I also think so. :) Best Regards, Akio Takebe - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [RFC] virtio-blk PCI backend
Anthony Liguori wrote: Avi Kivity wrote: There's no reason that the PIO operations couldn't be handled in the kernel. You'll already need some level of cooperation in userspace unless you plan on implementing the PCI bus in kernel space too. It's easy enough in the pci_map function in QEMU to just notify the kernel that it should listen on a particular PIO range. This is a config space write, right? If so, the range is the regular 0xcf8-0xcff and it has to be very specially handled. This is a per-device IO slot and as best as I can tell, the PCI device advertises the size of the region and the OS then identifies a range of PIO space to use and tells the PCI device about it. So we would just need to implement a generic userspace virtio PCI device in QEMU that did an ioctl to the kernel when this happened to tell the kernel what region to listen on for a particular device. vmcalls will certainly get faster but I doubt that the cost difference between vmcall and pio will ever be greater than a few hundred cycles. The only performance sensitive operation here would be the kick and I don't think a few hundred cycles in the kick path is ever going to be that significant for overall performance. Why do you think the different will be a few hundred cycles? The only difference in hardware between a PIO exit and a vmcall is that you don't have write out an exit reason in the VMC[SB]. So the performance difference between PIO/vmcall shouldn't be that great (and if it were, the difference would probably be obvious today). That's different from, say, a PF exit because with a PF, you also have to attempt to resolve it by walking the guest page table before determining that you do in fact need to exit. And if you have a large number of devices, searching the list becomes expensive too. The PIO address space is relatively small. You could do a radix tree or even a direct array lookup if you are concerned about performance. So why introduce the extra complexity? Overall I think it reduces comlexity if we have in-kernel devices. Anyway we can add additional signalling methods later. In-kernel virtio backends add quite a lot of complexity. Just the mechanism to setup the device is complicated enough. I suspect that it'll be necessary down the road for performance but I certainly don't think it's a simplification. I believe that the network interface will quickly go to the kernel since copy takes most of the cpu time and qemu does not support scatter gather dma at the moment. Nevertheless using pio seems good enough, Anthony's suggestion of notifying the kernel using ioctls is logical. If we'll run into troubles further on we can add a hypercall capability and if exist use hypercalls instead of pios. Regards, Anthony Liguori - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] IA64 KVM
On Thu, 2007-11-08 at 09:00 -0700, Alex Williamson wrote: > Hi Xiantao, > >Perhaps more people would be able to help restructure the tree to > support more architectures if a snapshot of the kvm/ia64 code was made > available. We might want to think about a kvm-ia64-devel mailing list > too (such as ppc has already). Thanks, > > Alex I agree. My branch of the Gelato Federation (http://www.gelato.unsw.edu.au/) wants to invest time and effort into IA64 KVM which could mean helping with a merge, streamlining code, benchmarking, bug hunting or something else along those lines. We've already got an open source Itanium virtualization solution called Linux on Linux (http://www.gelato.unsw.edu.au/IA64wiki/LinuxOnLinux) and we were hoping to apply what knowledge we gained from that project into something different. Currently we can't really do anything to help since there is supposed to be a working port but we can't get to it. Anyway, I'm currently being payed to improve Itanium virtualization under Linux, is there anything useful I can do here or should I just stick with working on LoL? During the last few days I've been attempting to take out the x86 specific stuff from kvm_main.c but I see that Xiantao already submitted that change yesterday. Do you Intel guys have it all under control now? - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] git-clone error?
Chen Xi wrote: > Hi everybody, > > I'm trying to clone the repository: > > git-clone http://www.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git kvm > You should clone with the git URL. Regards, Anthony Liguori > Fail on this: > error: Couldn't get > http://www.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git/refs/heads/kvm-updates > for heads/kvm-updates > The requested URL returned error: 404 > error: Could not interpret heads/kvm-updates as something to pull > > Anything wrong? > > Thanks. > > > - > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > ___ > kvm-devel mailing list > kvm-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kvm-devel > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH 3/3] virtio PCI device
Dor Laor wrote:
> Anthony Liguori wrote:
>> This is a PCI device that implements a transport for virtio. It
>> allows virtio
>> devices to be used by QEMU based VMMs like KVM or Xen.
>>
>>
>>
> While it's a little premature, we can start thinking of irq path
> improvements.
> The current patch acks a private isr and afterwards apic eoi will also
> be hit since its
> a level trig irq. This means 2 vmexits per irq.
> We can start with regular pci irqs and move afterwards to msi.
> Some other ugly hack options [we're better use msi]:
>- Read the eoi directly from apic and save the first private isr ack
I must admit, that I don't know a whole lot about interrupt delivery.
If we can avoid the private ISR ack then that would certainly be a good
thing to do! I think that would involve adding another bit to the
virtqueues to indicate whether or not there is work to be handled. It's
really just moving the ISR to shared memory so that there's no plenty
for accessing it.
Regards,
Anthony Liguori
>- Convert the specific irq line to edge triggered and dont share it
> What do you guys think?
>> +/* A small wrapper to also acknowledge the interrupt when it's handled.
>> + * I really need an EIO hook for the vring so I can ack the
>> interrupt once we
>> + * know that we'll be handling the IRQ but before we invoke the
>> callback since
>> + * the callback may notify the host which results in the host
>> attempting to
>> + * raise an interrupt that we would then mask once we acknowledged the
>> + * interrupt. */
>> +static irqreturn_t vp_interrupt(int irq, void *opaque)
>> +{
>> +struct virtio_pci_device *vp_dev = opaque;
>> +struct virtio_pci_vq_info *info;
>> +irqreturn_t ret = IRQ_NONE;
>> +u8 isr;
>> +
>> +/* reading the ISR has the effect of also clearing it so it's very
>> + * important to save off the value. */
>> +isr = ioread8(vp_dev->ioaddr + VIRTIO_PCI_ISR);
>> +
>> +/* It's definitely not us if the ISR was not high */
>> +if (!isr)
>> +return IRQ_NONE;
>> +
>> +spin_lock(&vp_dev->lock);
>> +list_for_each_entry(info, &vp_dev->virtqueues, node) {
>> +if (vring_interrupt(irq, info->vq) == IRQ_HANDLED)
>> +ret = IRQ_HANDLED;
>> +}
>> +spin_unlock(&vp_dev->lock);
>> +
>> +return ret;
>> +}
>>
>
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] git-clone error?
I tried. It seems that git can not pass through http proxy. Any other hints? Thanks. On Thu, 8 Nov 2007, Anthony Liguori wrote: > Chen Xi wrote: > > Hi everybody, > > > > I'm trying to clone the repository: > > > > git-clone http://www.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git kvm > > > > You should clone with the git URL. > > Regards, > > Anthony Liguori > > > Fail on this: > > error: Couldn't get > > http://www.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git/refs/heads/kvm-updates > > for heads/kvm-updates > > The requested URL returned error: 404 > > error: Could not interpret heads/kvm-updates as something to pull > > > > Anything wrong? > > > > Thanks. > > > > > > - > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > ___ > > kvm-devel mailing list > > kvm-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/kvm-devel > > > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] IA64 KVM
On Fri, 2007-11-09 at 09:29 +0800, Zhang, Xiantao wrote: > H, Alex/Akio >Thanks for your suggestions. It is a surely good idea to create a > IA64 mailing list to talk about the IA64-KVM. But now we have to rebase > them to latest commits before sending out, since the kvm source layout > changed much recently. Once the final source layout comes out, we will > send out the source code soon. I believe it should happen in very near > future. :-) Hi Xiantao, Thanks for your work on KVM/ia64 and efforts to get it into the tree, we definitely appreciate it. If it's not too much work, I think many of us would appreciate looking at any kind of snapshot of your tree, even if it's out of date from what's currently upstream. We're eager to start understanding how it works ;) Thanks, Alex -- Alex Williamson HP Open Source & Linux Org. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] git-clone error?
hi, >I tried. It seems that git can not pass through http proxy. >Any other hints? > Did you use "export http_proxy=" ? Best Regards, Akio Takebe - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] git-clone error?
Yes. It gives this error: git clone git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git Initialized empty Git repository in /home/xichen/ex/kvm/.git/ fatal: exec failed fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/avi/kvm.git' failed. On Fri, 9 Nov 2007, Akio Takebe wrote: > hi, > > > >I tried. It seems that git can not pass through http proxy. > >Any other hints? > > > Did you use "export http_proxy=" ? > > Best Regards, > > Akio Takebe > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Add WBINVD exit support
Add wbinvd VM Exit support to prepare for pass-through
device cache emulation and also enhance real time
responsibility.
Signed-off-by: Yaozu (Eddie) Dong <[EMAIL PROTECTED]>
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index 6fc981d..6d80a41 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -972,7 +972,8 @@ static __init int setup_vmcs_config(struct
vmcs_config *vmcs_conf)
#endif
if (_cpu_based_exec_control &
CPU_BASED_ACTIVATE_SECONDARY_CONTROLS) {
min = 0;
- opt = SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES;
+ opt = SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES |
+ SECONDARY_EXEC_WBINVD_EXITING;
if (adjust_vmx_controls(min, opt,
MSR_IA32_VMX_PROCBASED_CTLS2,
&_cpu_based_2nd_exec_control) <
0)
return -EIO;
@@ -2164,6 +2165,13 @@ static int handle_vmcall(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
return 1;
}
+static int handle_wbinvd(struct kvm_vcpu *vcpu, struct kvm_run
*kvm_run)
+{
+ skip_emulated_instruction(vcpu);
+ /* TODO: Add support for VT-d/pass-through device */
+ return 1;
+}
+
static int handle_apic_access(struct kvm_vcpu *vcpu, struct kvm_run
*kvm_run)
{
u64 exit_qualification;
@@ -2205,6 +2213,7 @@ static int (*kvm_vmx_exit_handlers[])(struct
kvm_vcpu *vcpu,
[EXIT_REASON_VMCALL] = handle_vmcall,
[EXIT_REASON_TPR_BELOW_THRESHOLD] =
handle_tpr_below_threshold,
[EXIT_REASON_APIC_ACCESS] = handle_apic_access,
+ [EXIT_REASON_WBINVD] = handle_wbinvd,
};
static const int kvm_vmx_max_exit_handlers =
diff --git a/drivers/kvm/vmx.h b/drivers/kvm/vmx.h
index 2ea35b9..5159374 100644
--- a/drivers/kvm/vmx.h
+++ b/drivers/kvm/vmx.h
@@ -49,6 +49,7 @@
* Definitions of Secondary Processor-Based VM-Execution Controls.
*/
#define SECONDARY_EXEC_VIRTUALIZE_APIC_ACCESSES 0x0001
+#define SECONDARY_EXEC_WBINVD_EXITING 0x0040
#define PIN_BASED_EXT_INTR_MASK 0x0001
@@ -223,6 +224,7 @@ enum vmcs_field {
#define EXIT_REASON_MWAIT_INSTRUCTION 36
#define EXIT_REASON_TPR_BELOW_THRESHOLD 43
#define EXIT_REASON_APIC_ACCESS 44
+#define EXIT_REASON_WBINVD 54
/*
* Interruption-information format
wbinvd.patch
Description: wbinvd.patch
clean.patch
Description: clean.patch
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] IA64 KVM
> > I agree. > > My branch of the Gelato Federation (http://www.gelato.unsw.edu.au/) > wants to invest time and effort into IA64 KVM which could mean helping > with a merge, streamlining code, benchmarking, bug hunting or > something else along those lines. We've already got an open source > Itanium virtualization solution called Linux on Linux > (http://www.gelato.unsw.edu.au/IA64wiki/LinuxOnLinux) and we > were hoping > to apply what knowledge we gained from that project into something > different. Currently we can't really do anything to help since there > is supposed to be a working port but we can't get to it. > > Anyway, I'm currently being payed to improve Itanium virtualization > under Linux, is there anything useful I can do here or should I just > stick with working on LoL? During the last few days I've been I think paravirt_ops support for IA64 is still blank :-( Nobody are interested in? > attempting to take out the x86 specific stuff from kvm_main.c but I > see that Xiantao already submitted that change yesterday. Do you > Intel guys have it all under control now? > > Eddie - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] [ kvm-Bugs-1828760 ] Cannot boot guest on 32bit host
Bugs item #1828760, was opened at 2007-11-09 12:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1828760&group_id=180599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: yunfeng (yunfeng) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot boot guest on 32bit host Initial Comment: Environment: COMMIT: kernel:1805646bfeeea2365d49c46abcd61f2c0d21e677 Userspace:c79baa60813812e8d0e34d998d609e848c093000 Hardware: woodcrest Bug detailed description: -- Cannot boot guests on pae host. guest will hang and printing following messages on console: [EMAIL PROTECTED] ~]# qemu . -m 256 -net nic,macaddr=00:16:3e:19:88:af,model=rtl8139 -net tap,script=/etc/kvm/qemu-ifup -hda /share/xvs/var/tmp-img_CPL_MEM_02_1194572277_1 exception 13 (0) rax rbx rcx rdx 0600 rsi rdi rsp rbp r8 r9 r10 r11 r12 r13 r14 r15 rip 10710002 rflags 00033046 cs f000 (000f/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs (/ p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr (10c0/2088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt (/ p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt 0/ idt 0/ cr0 6010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 31 c0 --> bf 48 29 04 00 b9 84 29 04 00 29 f9 f3 aa e9 7b 11 00 00 31 c0 8e d8 ff 06 00 f0 f4 eb fd Aborted Host will print following messages: vt-cr2 kernel: [] resched_cpu+0x43/0x52 Message from [EMAIL PROTECTED] at Fri Nov 9 02:33:56 2007 ... vt-cr2 kernel: [] kmap_atomic+0x1c/0x20 Message from [EMAIL PROTECTED] at Fri Nov 9 02:33:56 2007 ... vt-cr2 kernel: [] get_page_from_freelist+0x250/0x2dd Message from [EMAIL PROTECTED] at Fri Nov 9 02:33:56 2007 ... vt-cr2 kernel: [] __alloc_pages+0x59/0x28d Message from [EMAIL PROTECTED] at Fri Nov 9 02:33:56 2007 ... vt-cr2 kernel: [] do_wp_page+0x173/0x400 Message from [EMAIL PROTECTED] at Fri Nov 9 02:33:56 2007 ... vt-cr2 kernel: [https://sourceforge.net/tracker/?func=detail&atid=893831&aid=1828760&group_id=180599 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
[kvm-devel] Medical Doctor Database in America
Here is the package deal we're running for this week Board Certified Medical Doctors in the United States 788,976 in total * 17,413 emails Featuring coverage for more than 30 specialties like Internal Medicine, Family Practice, Opthalmology, Anesthesiologists, Cardiologists and more Can easily be sorted by 16 different fields US Pharmaceutical Company Executives Database Personal email addresses (47,000 in total) and names for top level executives Complete List of Hospitals in the US Full data for all the major positions in more than 7k facilities Extensive Contact List of Dentists in America 597,000 dentists and dental services ( a $350 value!) Chiropractors in the USA Over than 100k chiropractors practicing in the US This week only you pay only: $393 for everything send and email to: [EMAIL PROTECTED] good until Nov 9 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] [PATCH]3/5 Using kvm_arch prefix to define functions, andreplace
Hollis Blanchard wrote: >> - kvm_x86_ops->vcpu_free(vcpu); >> + kvm_arch_vcpu_free(vcpu); >> return r; >> } > > Have a look at the patch I posted on Wednesday: "[PATCH 2 of 2] RFC: > Create kvm_arch_vcpu_create()". kvm_arch_vcpu_create() will actually > encompass more logic from kvm_vm_ioctl_create_vcpu(), and once you do > that, kvm_arch_vcpu_reset() doesn't need to exist (which will also > make Carsten happy). Hi, Hollis Thanks for your response. If we need to move out the code related to mmu, sure to keep more logic in kvm_arch_create_vcpu. But I don't know the decision about the mmu part putting in common or arch. As Avi said before, maybe we need to keep mmu interfaces in common for future possible memory hotplug of guest and so on. Best Wishes Xiantao - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
