[PATCH] kvm: fix wrong position of clean cscope
From: Sheng Yang [EMAIL PROTECTED] Signed-off-by: Sheng Yang [EMAIL PROTECTED] Signed-off-by: Avi Kivity [EMAIL PROTECTED] diff --git a/Makefile b/Makefile index 6581679..64e296d 100644 --- a/Makefile +++ b/Makefile @@ -110,8 +110,8 @@ srpm: clean: for i in $(if $(WANT_MODULE), kernel) user libkvm qemu libfdt; do \ make -C $$i clean; \ - rm -f ./cscope.* done + rm -f ./cscope.* distclean: clean rm -f config.mak user/config.mak -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm: qemu: regenerate bios for firmware uuid interface
From: Avi Kivity [EMAIL PROTECTED] Signed-off-by: Avi Kivity [EMAIL PROTECTED] diff --git a/qemu/pc-bios/bios.bin b/qemu/pc-bios/bios.bin index cde8e18..1a90b6d 100644 Binary files a/qemu/pc-bios/bios.bin and b/qemu/pc-bios/bios.bin differ -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm: bios: read UUID from firmware interface
From: Gleb Natapov [EMAIL PROTECTED]
Add support for new firmware configuration channel to the BIOS.
Read UUID from firmware using this channel.
Signed-off-by: Gleb Natapov [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/bios/rombios32.c b/bios/rombios32.c
index 921e202..a91b155 100755
--- a/bios/rombios32.c
+++ b/bios/rombios32.c
@@ -444,31 +444,51 @@ void wrmsr_smp(uint32_t index, uint64_t val)
p-ecx = 0;
}
-void uuid_probe(void)
-{
#ifdef BX_QEMU
-uint32_t eax, ebx, ecx, edx;
+#define QEMU_CFG_CTL_PORT 0x510
+#define QEMU_CFG_DATA_PORT 0x511
+#define QEMU_CFG_SIGNATURE 0x00
+#define QEMU_CFG_ID 0x01
+#define QEMU_CFG_UUID 0x02
+
+int qemu_cfg_port;
+
+void qemu_cfg_select(int f)
+{
+outw(QEMU_CFG_CTL_PORT, f);
+}
-// check if backdoor port exists
-asm volatile (outl %%eax, %%dx
-: =a (eax), =b (ebx), =c (ecx), =d (edx)
-: a (0x564d5868), b (0), c (0xa), d (0x5658));
-if (ebx == 0x564d5868) {
-uint32_t *uuid_ptr = (uint32_t *)bios_uuid;
-// get uuid
-asm volatile (outl %%eax, %%dx
-: =a (eax), =b (ebx), =c (ecx), =d (edx)
-: a (0x564d5868), c (0x13), d (0x5658));
-uuid_ptr[0] = eax;
-uuid_ptr[1] = ebx;
-uuid_ptr[2] = ecx;
-uuid_ptr[3] = edx;
-} else
+int qemu_cfg_port_probe()
+{
+char *sig = QEMU;
+int i;
+
+qemu_cfg_select(QEMU_CFG_SIGNATURE);
+
+for (i = 0; i 4; i++)
+if (inb(QEMU_CFG_DATA_PORT) != sig[i])
+return 0;
+
+return 1;
+}
+
+void qemu_cfg_read(uint8_t *buf, int len)
+{
+while (len--)
+*(buf++) = inb(QEMU_CFG_DATA_PORT);
+}
#endif
-{
-// UUID not set
-memset(bios_uuid, 0, 16);
+
+void uuid_probe(void)
+{
+#ifdef BX_QEMU
+if(qemu_cfg_port) {
+qemu_cfg_select(QEMU_CFG_UUID);
+qemu_cfg_read(bios_uuid, 16);
+return;
}
+#endif
+memset(bios_uuid, 0, 16);
}
void cpu_probe(void)
@@ -2085,6 +2105,10 @@ void rombios32_init(void)
init_smp_msrs();
+#ifdef BX_QEMU
+qemu_cfg_port = qemu_cfg_port_probe();
+#endif
+
ram_probe();
cpu_probe();
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: ia64: Makefile fix for forcing to re-generate asm-offsets.h
From: Xiantao Zhang [EMAIL PROTECTED] To avoid using stale asm-offsets.h. Signed-off-by: Xiantao Zhang [EMAIL PROTECTED] Signed-off-by: Avi Kivity [EMAIL PROTECTED] diff --git a/arch/ia64/kvm/Makefile b/arch/ia64/kvm/Makefile index cf37f8f..53c7a48 100644 --- a/arch/ia64/kvm/Makefile +++ b/arch/ia64/kvm/Makefile @@ -30,7 +30,7 @@ define cmd_offsets echo #endif ) $@ endef # We use internal rules to avoid the is up to date message from make -arch/ia64/kvm/asm-offsets.s: arch/ia64/kvm/asm-offsets.c +arch/ia64/kvm/asm-offsets.s: arch/ia64/kvm/asm-offsets.c FORCE $(call if_changed_dep,cc_s_c) $(obj)/$(offsets-file): arch/ia64/kvm/asm-offsets.s @@ -53,7 +53,6 @@ endif kvm-objs := $(common-objs) kvm-ia64.o kvm_fw.o obj-$(CONFIG_KVM) += kvm.o -FORCE : $(obj)/$(offsets-file) EXTRA_CFLAGS_vcpu.o += -mfixed-range=f2-f5,f12-f127 kvm-intel-objs = vmm.o vmm_ivt.o trampoline.o vcpu.o optvfault.o mmio.o \ vtlb.o process.o diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 1658228..bb92be2 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -37,7 +37,7 @@ #define KVM_REQ_UNHALT 6 #define KVM_REQ_MMU_SYNC 7 -#define KVM_USERSPACE_IRQ_SOURCE_ID(1 0) +#define KVM_USERSPACE_IRQ_SOURCE_ID0 struct kvm_vcpu; extern struct kmem_cache *kvm_vcpu_cache; -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: Fix guest shared interrupt with in-kernel irqchip
From: Sheng Yang [EMAIL PROTECTED]
Every call of kvm_set_irq() should offer an irq_source_id, which is
allocated by kvm_request_irq_source_id(). Based on irq_source_id, we
identify the irq source and implement logical OR for shared level
interrupts.
The allocated irq_source_id can be freed by kvm_free_irq_source_id().
Currently, we support at most sizeof(unsigned long) different irq sources.
[Amit: - rebase to kvm.git HEAD
- move definition of KVM_USERSPACE_IRQ_SOURCE_ID to common file
- move kvm_request_irq_source_id to the update_irq ioctl]
[Xiantao: - Add kvm/ia64 stuff and make it work for kvm/ia64 guests]
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
Signed-off-by: Amit Shah [EMAIL PROTECTED]
Signed-off-by: Xiantao Zhang [EMAIL PROTECTED]
Signed-off-by: Avi Kivity [EMAIL PROTECTED]
diff --git a/arch/ia64/include/asm/kvm_host.h b/arch/ia64/include/asm/kvm_host.h
index 85db124..04c0b88 100644
--- a/arch/ia64/include/asm/kvm_host.h
+++ b/arch/ia64/include/asm/kvm_host.h
@@ -417,6 +417,9 @@ struct kvm_arch {
struct list_head assigned_dev_head;
struct dmar_domain *intel_iommu_domain;
struct hlist_head irq_ack_notifier_list;
+
+ unsigned long irq_sources_bitmap;
+ unsigned long irq_states[KVM_IOAPIC_NUM_PINS];
};
union cpuid3_t {
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index c0699f0..d21fb67 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -778,6 +778,9 @@ static void kvm_init_vm(struct kvm *kvm)
kvm_build_io_pmt(kvm);
INIT_LIST_HEAD(kvm-arch.assigned_dev_head);
+
+ /* Reserve bit 0 of irq_sources_bitmap for userspace irq source */
+ kvm-arch.irq_sources_bitmap = 1;
}
struct kvm *kvm_arch_create_vm(void)
@@ -941,9 +944,8 @@ long kvm_arch_vm_ioctl(struct file *filp,
goto out;
if (irqchip_in_kernel(kvm)) {
mutex_lock(kvm-lock);
- kvm_ioapic_set_irq(kvm-arch.vioapic,
- irq_event.irq,
- irq_event.level);
+ kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID,
+ irq_event.irq, irq_event.level);
mutex_unlock(kvm-lock);
r = 0;
}
diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
index 6144d3f..da06919 100644
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -545,6 +545,12 @@ struct kvm_pit *kvm_create_pit(struct kvm *kvm)
if (!pit)
return NULL;
+ mutex_lock(kvm-lock);
+ pit-irq_source_id = kvm_request_irq_source_id(kvm);
+ mutex_unlock(kvm-lock);
+ if (pit-irq_source_id 0)
+ return NULL;
+
mutex_init(pit-pit_state.lock);
mutex_lock(pit-pit_state.lock);
spin_lock_init(pit-pit_state.inject_lock);
@@ -587,6 +593,7 @@ void kvm_free_pit(struct kvm *kvm)
mutex_lock(kvm-arch.vpit-pit_state.lock);
timer = kvm-arch.vpit-pit_state.pit_timer.timer;
hrtimer_cancel(timer);
+ kvm_free_irq_source_id(kvm, kvm-arch.vpit-irq_source_id);
mutex_unlock(kvm-arch.vpit-pit_state.lock);
kfree(kvm-arch.vpit);
}
@@ -598,8 +605,8 @@ static void __inject_pit_timer_intr(struct kvm *kvm)
int i;
mutex_lock(kvm-lock);
- kvm_set_irq(kvm, 0, 1);
- kvm_set_irq(kvm, 0, 0);
+ kvm_set_irq(kvm, kvm-arch.vpit-irq_source_id, 0, 1);
+ kvm_set_irq(kvm, kvm-arch.vpit-irq_source_id, 0, 0);
mutex_unlock(kvm-lock);
/*
diff --git a/arch/x86/kvm/i8254.h b/arch/x86/kvm/i8254.h
index e436d49..4178022 100644
--- a/arch/x86/kvm/i8254.h
+++ b/arch/x86/kvm/i8254.h
@@ -44,6 +44,7 @@ struct kvm_pit {
struct kvm_io_device speaker_dev;
struct kvm *kvm;
struct kvm_kpit_state pit_state;
+ int irq_source_id;
};
#define KVM_PIT_BASE_ADDRESS 0x40
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index dda478e..5d29c50 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1816,7 +1816,8 @@ long kvm_arch_vm_ioctl(struct file *filp,
goto out;
if (irqchip_in_kernel(kvm)) {
mutex_lock(kvm-lock);
- kvm_set_irq(kvm, irq_event.irq, irq_event.level);
+ kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID,
+ irq_event.irq, irq_event.level);
mutex_unlock(kvm-lock);
r = 0;
}
@@ -4115,6 +4116,9 @@ struct kvm *kvm_arch_create_vm(void)
INIT_LIST_HEAD(kvm-arch.active_mmu_pages);
INIT_LIST_HEAD(kvm-arch.assigned_dev_head);
+ /* Reserve bit 0 of irq_sources_bitmap for userspace irq source */
+ kvm-arch.irq_sources_bitmap = 1;
+
Re: [PATCH] qemu: qemu_fopen_fd: differentiate between reader and writer user
Anthony Liguori wrote: Uri Lublin wrote: Anthony Liguori wrote: I have already cut your text, but I don't understand the comment about not being full duplex. Is there a reason why migration needs to be bidirectional? I don't think there's a fundamental reason it needs to be and I think there are some advantages to it being unidirectional. Weren't there some acks flowing back on the old protocol to let the source now things are fine? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qemu: qemu_fopen_fd: differentiate between reader and writer user
Anthony Liguori wrote: Yeah, I tried to implement the read/write mode buffer and it ends up not to work very nicely. I don't remember the precise issue, but I hit some sort of wall that I thought was a fundamental limitation. I ended up forcing the QEMUFile to be in either read or write mode similar to your original patch without introducing a new option as an argument. It really depends on whether the file descriptor is a file or a socket. With files, the read and write streams are backed by the same storage, so they can intersect. With sockets, the read and write streams are completely independent. Everything is a file, except when it isn't. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2] Shared guest irq support
Zhang, Xiantao wrote: Forget to modify the from item generated automatically by git. Modified to Sheng Yang [EMAIL PROTECTED] :) Xiantao From c0d1ad6327c01ba0584922022bef48c971bbf18a Mon Sep 17 00:00:00 2001 From: Sheng Yang [EMAIL PROTECTED] Date: Wed, 15 Oct 2008 20:15:06 +0800 Subject: [PATCH] KVM: Fix guest shared interrupt with in-kernel irqchip Every call of kvm_set_irq() should offer an irq_source_id, which is allocated by kvm_request_irq_source_id(). Based on irq_source_id, we identify the irq source and implement logical OR for shared level interrupts. The allocated irq_source_id can be freed by kvm_free_irq_source_id(). Currently, we support at most sizeof(unsigned long) different irq sources. +#define KVM_USERSPACE_IRQ_SOURCE_ID 1 0 + This is dangerous, if used in an expression together with a higher precedence operator. I fixed it and applied. Thanks to all involved. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: VMX: Move private memory slot position
Yang, Sheng wrote: I've found the reason... It's because that kvm_mmu_page-slot_bitmap is unsigned long, and if use KVM_MEMORY_SLOTS + xxx, it would beyond 32 in pae, then memory corrupted. But reduce supported memory slot number to 28 or extend slot_bitmap, or other methods? Slot_bitmap have bitops, so keep unsigned long would be better... Now reduce supported memory slot number seems reasonable to me. We could change it to DECLARE_BITMAP, and thus support = 32 slots even on i386. But I agree that 28 slots would be sufficient. (I also want to have this fix into 2.6.28, for some device would easily overlapped with current private memory slot) I've been thinking that we can get rid of internal slots, by placing the TSS, real mode identity map, and APIC access page in the bios. Of course we would need a new ioctl to let the kernel know where the scratch memory is located and how much of it is available. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] kvm/ia64: Makefile fix for forcing to re-generate asm-offsets.h
Zhang, Xiantao wrote: Hi, Avi Please apply this urgent fix for 2.6.28 merge. Thanks! Applied, and will queue for 2.6.28. Is it needed for 2.6.26 and .27? If not, why not? -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2] Shared guest irq support
On Thursday 16 October 2008 16:21:38 Avi Kivity wrote: Zhang, Xiantao wrote: Forget to modify the from item generated automatically by git. Modified to Sheng Yang [EMAIL PROTECTED] :) Xiantao From c0d1ad6327c01ba0584922022bef48c971bbf18a Mon Sep 17 00:00:00 2001 From: Sheng Yang [EMAIL PROTECTED] Date: Wed, 15 Oct 2008 20:15:06 +0800 Subject: [PATCH] KVM: Fix guest shared interrupt with in-kernel irqchip Every call of kvm_set_irq() should offer an irq_source_id, which is allocated by kvm_request_irq_source_id(). Based on irq_source_id, we identify the irq source and implement logical OR for shared level interrupts. The allocated irq_source_id can be freed by kvm_free_irq_source_id(). Currently, we support at most sizeof(unsigned long) different irq sources. +#define KVM_USERSPACE_IRQ_SOURCE_ID1 0 + This is dangerous, if used in an expression together with a higher precedence operator. I fixed it and applied. Thanks to all involved. Wait a minute I think I reserved source id 0 to userspace, rather than 10=1... It's strange... + kvm-arch.irq_sources_bitmap = 1; What really should be addressed is here... I will post a patch to fix it as soon as I saw the commit... -- regards Yang, Sheng -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] kvm/ia64: Makefile fix for forcing to re-generate asm-offsets.h
Avi Kivity wrote: Zhang, Xiantao wrote: Hi, Avi Please apply this urgent fix for 2.6.28 merge. Thanks! Applied, and will queue for 2.6.28. Is it needed for 2.6.26 and .27? If not, why not? It should be an issue here, and also needs for 2.6.26 and 27. For end-users, it shouldn't have no problem, because they rarely to modify vcpu's structure defition. But for developers, it may leads to weird issues! Xiantao -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2] Shared guest irq support
* On Thursday 16 Oct 2008 13:51:38 Avi Kivity wrote: Zhang, Xiantao wrote: Forget to modify the from item generated automatically by git. Modified to Sheng Yang [EMAIL PROTECTED] :) Xiantao From c0d1ad6327c01ba0584922022bef48c971bbf18a Mon Sep 17 00:00:00 2001 From: Sheng Yang [EMAIL PROTECTED] Date: Wed, 15 Oct 2008 20:15:06 +0800 Subject: [PATCH] KVM: Fix guest shared interrupt with in-kernel irqchip Every call of kvm_set_irq() should offer an irq_source_id, which is allocated by kvm_request_irq_source_id(). Based on irq_source_id, we identify the irq source and implement logical OR for shared level interrupts. The allocated irq_source_id can be freed by kvm_free_irq_source_id(). Currently, we support at most sizeof(unsigned long) different irq sources. +#define KVM_USERSPACE_IRQ_SOURCE_ID1 0 + This is dangerous, if used in an expression together with a higher precedence operator. I fixed it and applied. Thanks to all involved. Thanks; however, Sheng suggested we should use set_bit to set the corresponding bit since we're operating on bitfields in a bitmap. Amit -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] vmchannel a data channel between host and guest.
On Wed, Oct 15, 2008 at 09:02:30AM -0500, Anthony Liguori wrote: like struct sockaddr_un. As long as the strings were unique, they could be in whatever format people wanted. So basically what you are saying is that you want to use string IDs instead of numerical IDs in a hope that the chance of colliding IDs will be smaller? (in the current implementation ID length is 32 bit, so the chances for two services to pick the same ID is small). But people don't choose random 32-bit integers and since your implementation only supports channels 0..4 obviously, the intention isn't to choose random integers. When using integers, it would be You can configure only four channels in qemu with my implementation, but you can give arbitrary ID to each one of them. To configure vmchannel with ID 42 you add -vmchannel di:42,unix:/tmp/kvm-mouse,server to qemu command line (di means Device Id). necessary to have some sort of authority that assigns out the integers to avoid conflict. A protocol like this scales better if such an authority isn't necessary. But why pick constant ID for a service at all? Management software can assign unique IDs for each service during image preparation. First, not everyone has management software. Even so, it's not the If you run qemu without management software as most of us do, you became management software. If you want Linux console to be on a serial port you have to configure qemu and Linux properly. center of the world. If I want to add a new feature to QEMU that makes use of one of these channels (say Unity/Coherence), does that mean I now have to tell every management tool (libvirt et al) about this interface so they can assign an ID to it? How does the guest software know what With proposed solution yes, you have to tell it to a management tool. Not only because of ID assigning issues, but also because you have no direct control on a command line, so management tool should know how to create a channel for you. Of cause management tool can have an option to add channels on user request. channel to use? You basically assume yet another host=guest communication mechanism to tell the guest software what channel to use. That seems to defeat the purpose. This happens when disk image is prepared and various agents are installed into it. Just as if you want to redirect Linux console to serial port you have to add kernel option once after installation. So one management software will use channel 42 for DnD and 22 for CIM and another will use 13 for DnD and 42 for CIM. All is need is to not hard code channel IDs into agents. You will not be able to move such images from one management software to another easily of cause, but this task is not so easy today too. It's so much simpler to just use unique identifiers for each service. Be it UUID, a string in the form of a reverse fqdn or URL, or whatever. It is easy to do with name resolution service on channel 0. If you like string IDs better than numerical IDs and you are OK with lookup by name way of doing things in VMCI I can easily add channel 0 (will be implemented by qemu itself and thus always present) that will do name to ID mapping. It's not a bad idea to have a bootstrap channel. Do channel exist during the entirely life time of the guest? Yes. Can disconnects/reconnects happen on a channel? Can a guest listen on a channel? Netlink implements datagram semantic, so there is not disconnects/reconnects or listen. Any process can send/receive data to/from any channel. Certainly, sockets are a pretty well established model so it makes a certain amount of sense to have these things behave like traditional sockets. I use socket! Existing one, not new one. I think there should be a very good reason to add yet another address family. I thought about adding new address family initially, but then I recalled that we already have one that is used for kernel-userspace communication. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: VMX: Move private memory slot position
On Thursday 16 October 2008 16:26:07 Avi Kivity wrote: Yang, Sheng wrote: I've found the reason... It's because that kvm_mmu_page-slot_bitmap is unsigned long, and if use KVM_MEMORY_SLOTS + xxx, it would beyond 32 in pae, then memory corrupted. But reduce supported memory slot number to 28 or extend slot_bitmap, or other methods? Slot_bitmap have bitops, so keep unsigned long would be better... Now reduce supported memory slot number seems reasonable to me. We could change it to DECLARE_BITMAP, and thus support = 32 slots even on i386. But I agree that 28 slots would be sufficient. DECLARE_BITMAP looks like a flexible solution, I forgot it...(and I also don't like to change a lot of macro in kernel and userspace). I will post the patch soon. (I also want to have this fix into 2.6.28, for some device would easily overlapped with current private memory slot) I've been thinking that we can get rid of internal slots, by placing the TSS, real mode identity map, and APIC access page in the bios. Of course we would need a new ioctl to let the kernel know where the scratch memory is located and how much of it is available. How about put into userspace e.g. pc_init()? I think more easy than keeping bios sync with KVM. Anyway, vmx specific thing would become generic. I'd like to keep it as what it is at least for now... -- regards Yang, Sheng -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2] Shared guest irq support
Sheng Yang wrote: +#define KVM_USERSPACE_IRQ_SOURCE_ID1 0 + This is dangerous, if used in an expression together with a higher precedence operator. I fixed it and applied. Thanks to all involved. Wait a minute I think I reserved source id 0 to userspace, rather than 10=1... It's strange... + kvm-arch.irq_sources_bitmap = 1; What really should be addressed is here... Oh right. I changed it to 0. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2] Shared guest irq support
Amit Shah wrote: +#define KVM_USERSPACE_IRQ_SOURCE_ID1 0 + This is dangerous, if used in an expression together with a higher precedence operator. I fixed it and applied. Thanks to all involved. Thanks; however, Sheng suggested we should use set_bit to set the corresponding bit since we're operating on bitfields in a bitmap. We are actually using set_bit, so the value should be zero. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm/ia64: Fix halt emulation logic.
Zhang, Xiantao wrote: smp_call_function_single() will call the function on the current cpu if instructed, so this change is unneeded. Aha, Thanks for pointing this. Yes, it is unnecessary. Could you help to remove it directly ? or need me have a resend. Please resend, since I can't test (or even compile) it. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: kvm/ia64: Fix halt emulation logic.
Avi Kivity wrote:
Zhang, Xiantao wrote:
Hi, Avi
This is the key fix for 2.6.28 merge. Without this patch, guest
may hang once configured with more than 2 vcpus, it is because x86
side changed the halt handling's common logic, but it misses to
change ia64 side.
@@ -398,8 +400,11 @@ static int handle_global_purge(struct kvm_vcpu
*vcpu, struct kvm_run *kvm_run)
if (kvm-vcpus[i]-cpu != -1) {
call_data.vcpu = kvm-vcpus[i];
-smp_call_function_single(kvm-vcpus[i]-cpu,
+if (kvm-vcpus[i]-cpu != smp_processor_id())
+
smp_call_function_single(kvm-vcpus[i]-cpu,
vcpu_global_purge, call_data,
1);
+else
+vcpu_global_purge(call_data);
smp_call_function_single() will call the function on the current cpu
if instructed, so this change is unneeded.
Aha, Thanks for pointing this. Yes, it is unnecessary. Could you help to
remove it directly ? or need me have a resend.
Xiantao
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: commit 641fb03992b20aa640781a245f6b7136f0b845e4 broke MMU
Alexander Graf wrote:
Hi,
while trying to run the current openSUSE on git KVM I found that the
installation doesn't even boot properly. I bisected the problem down
to commit 641fb03992b20aa640781a245f6b7136f0b845e4, as of which udev
shows strange errors.
I reproduced the incorrect behavior reliably on an AMD machine with
npt=0, but since the mmu code is generic I assume that everyone
suffers from this.
To reproduce the problem, do the following:
wget
http://download.opensuse.org/factory/repo/oss/boot/x86_64/loader/{linux,initrd}
qemu-system-x86_64 -m 512 /dev/null -kernel linux -initrd initrd
Since I'm not too much into mmu code, I hope someone else will take a
deeper look at this.
I think this was fixed by e74bb3fa8e55284dc6fdd68aa9da833ce07a4295
(KVM: MMU: sync root on paravirt TLB flush).
(update your address book entries for kvm-devel and for me...)
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] read UUID from qemu
Gleb Natapov wrote: Similar patch was sent to bochs devel list, but I propose to apply this patch now rather than waiting for bochs developers to apply it and then merger. --- Add support for new FW configuration channel to the BIOS. Read UUID from QEMU using this channel. Applied, thanks. btw, '---' works the other way around (confusingly). -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: How can I tell KVM is actually using AMD-V virtualization extensions?
Veiko Kukk wrote: Hi! My desktop machine is HP dc5750 SFF, CPU is AMD Athlon(tm) 64 X2 Dual Core Processor 4600+, /proc/cpuinfo lists svm flag. I'm using 2.6.27 kernel on FC9, qemu-system-x86_64 info version 0.9.1. How can I be absolutely sure, that my kvm virtual machines are using AMD-V? You can /sbin/lsmod | grep kvm_amd and check for ref count 0. You can also use dmesg to check kvm messages. Alternatively, check kvm_stat tool or run /usr/sbin/lsof -p `pgrep qemu` | grep /dev/kvm Dor -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [patch] kvm-userland - raise max vcpus to 256 for ia64
It needs the kernel patch I sent to mailing list yesterday. Avi, Could you check-in attached patch and queue it for 2.6.28? Thanks! Xiantao Jes Sorensen wrote: Hi, We can now boot upto 60 vcpus on ia64, but thats just the beginning. Would you please add this one to the kvm-userland tree. Thanks, Jes 0002-kvm-ia64-Code-cleanup-for-Linux-2.6.28.patch Description: 0002-kvm-ia64-Code-cleanup-for-Linux-2.6.28.patch
Re: How can I tell KVM is actually using AMD-V virtualization extensions?
Veiko Kukk wrote: Hi! My desktop machine is HP dc5750 SFF, CPU is AMD Athlon(tm) 64 X2 Dual Core Processor 4600+, /proc/cpuinfo lists svm flag. I'm using 2.6.27 kernel on FC9, qemu-system-x86_64 info version 0.9.1. How can I be absolutely sure, that my kvm virtual machines are using AMD-V? 'info kvm' -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: commit 641fb03992b20aa640781a245f6b7136f0b845e4 broke MMU
On 16.10.2008, at 10:58, Avi Kivity wrote: I think this was fixed by e74bb3fa8e55284dc6fdd68aa9da833ce07a4295 (KVM: MMU: sync root on paravirt TLB flush). Eh, yes. Sorry for the fuss - it works now. Alex -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/10] Add CPUID feature flag for SVM v4
On 15.10.2008, at 21:31, Alexander Graf wrote: This patch adds the CPUID feature flag for SVM in the x86 Linux headers. Looks like the full leaf 0x8001 found its way into mainline, so this patch is not necessary anymore. Alex Signed-off-by: Alexander Graf [EMAIL PROTECTED] --- include/asm-x86/cpufeature.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/asm-x86/cpufeature.h b/include/asm-x86/ cpufeature.h index cfcfb0a..28217de 100644 --- a/include/asm-x86/cpufeature.h +++ b/include/asm-x86/cpufeature.h @@ -110,6 +110,7 @@ /* More extended AMD flags: CPUID level 0x8001, ecx, word 6 */ #define X86_FEATURE_LAHF_LM (6*32+ 0) /* LAHF/SAHF in long mode */ #define X86_FEATURE_CMP_LEGACY (6*32+ 1) /* If yes HyperThreading not valid */ +#define X86_FEATURE_SVM(6*32+ 2) /* Secure Virtual Machine */ #define X86_FEATURE_IBS (6*32+ 10) /* Instruction Based Sampling */ /* -- 1.5.6 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] KVM: VMX: Move private memory slot position
PCI device assignment would map guest MMIO spaces as separate slot, so it is
possible that the device has more than 2 MMIO spaces and overwrite current
private memslot.
The patch move private memory slot to the top of userspace visible memory slots.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
arch/x86/kvm/vmx.c |2 +-
arch/x86/kvm/vmx.h |5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 3d56554..64e2439 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2513,7 +2513,7 @@ static int vmx_set_tss_addr(struct kvm *kvm, unsigned int
addr)
{
int ret;
struct kvm_userspace_memory_region tss_mem = {
- .slot = 8,
+ .slot = TSS_PRIVATE_MEMSLOT,
.guest_phys_addr = addr,
.memory_size = PAGE_SIZE * 3,
.flags = 0,
diff --git a/arch/x86/kvm/vmx.h b/arch/x86/kvm/vmx.h
index 3ad61dc..e2341d8 100644
--- a/arch/x86/kvm/vmx.h
+++ b/arch/x86/kvm/vmx.h
@@ -338,8 +338,9 @@ enum vmcs_field {
#define AR_RESERVD_MASK 0xfffe0f00
-#define APIC_ACCESS_PAGE_PRIVATE_MEMSLOT 9
-#define IDENTITY_PAGETABLE_PRIVATE_MEMSLOT 10
+#define TSS_PRIVATE_MEMSLOT(KVM_MEMORY_SLOTS + 0)
+#define APIC_ACCESS_PAGE_PRIVATE_MEMSLOT (KVM_MEMORY_SLOTS + 1)
+#define IDENTITY_PAGETABLE_PRIVATE_MEMSLOT (KVM_MEMORY_SLOTS + 2)
#define VMX_NR_VPIDS (1 16)
#define VMX_VPID_EXTENT_SINGLE_CONTEXT 1
--
1.5.4.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qemu: qemu_fopen_fd: differentiate between reader and writer user
Avi Kivity wrote: Anthony Liguori wrote: Uri Lublin wrote: Anthony Liguori wrote: I have already cut your text, but I don't understand the comment about not being full duplex. Is there a reason why migration needs to be bidirectional? I don't think there's a fundamental reason it needs to be and I think there are some advantages to it being unidirectional. Weren't there some acks flowing back on the old protocol to let the source now things are fine? There were, but there aren't now. They don't improve reliability. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] vmchannel a data channel between host and guest.
On Wed, Oct 15, 2008 at 10:56:02AM -0500, Anthony Liguori wrote: Gleb Natapov wrote: Andrew, On Wed, Oct 15, 2008 at 07:18:52AM -0700, Andrew Biggadike wrote: Gleb Natapov [EMAIL PROTECTED] wrote: Of course, you should also take a look at VMware's VMCI. If we're going to have a socket interface, if we can have a compatible userspace interface, that would probably be a good thing. I looked at what I could find about VMCI (http://pubs.vmware.com/vmci-sdk/index.html). I believe Anthony intended for you to look at the sockets interface to VMCI: http://www.vmware.com/pdf/ws65_s2_vmci_sockets.pdf. Using VMCI socket requires loading kernel module in a guest and in a host. Is this correct? Note that their addressing scheme uses a CID/port pair. I think it's interesting and somewhat safe because it basically mirrors an IP/port pair. That makes it relatively safe because that addressing mechanism is well known (with it's advantages and flaws). For instance, you need some sort of authority to assign out ports. It doesn't really help with discovery either. I fails to see how this is more safe that what I propose. Same problem exactly: which ID/port to use for my service? But I also don't want to compare proposed vmchannel and VMCI socket. They try to solve different problems as far as I can see. VMCI tries to address intra host communication performance problem (what about migration of a guest using it BTW? Or security? Firewalls know nothing about it). vmchannel goal is to provide management tools a way to communicate with in guest agents. -- Gleb. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qemu: qemu_fopen_fd: differentiate between reader and writer user
Anthony Liguori wrote: Avi Kivity wrote: Anthony Liguori wrote: Uri Lublin wrote: Anthony Liguori wrote: I have already cut your text, but I don't understand the comment about not being full duplex. Is there a reason why migration needs to be bidirectional? I don't think there's a fundamental reason it needs to be and I think there are some advantages to it being unidirectional. Weren't there some acks flowing back on the old protocol to let the source now things are fine? There were, but there aren't now. They don't improve reliability. Why do you think they don't improve reliability ? The Ack/Go messages catch the scenario where SRC finishes sending all its state, and DST have a problem loading that state. In that case SRC thinks migration was completed successfully (and stay in stopped mode), while DST exists. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qemu: qemu_fopen_fd: differentiate between reader and writer user
Uri Lublin wrote: Weren't there some acks flowing back on the old protocol to let the source now things are fine? There were, but there aren't now. They don't improve reliability. Why do you think they don't improve reliability ? The Ack/Go messages catch the scenario where SRC finishes sending all its state, and DST have a problem loading that state. In that case SRC thinks migration was completed successfully (and stay in stopped mode), while DST exists. The management tool is in contact with both, and can arbitrate. Once it thinks both source and destination are in a good state, it can continue the destination and quit the source. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] KVM: MMU: Extend kvm_mmu_page-slot_bitmap size
Otherwise set_bit() for private memory slot(above KVM_MEMORY_SLOTS) would
corrupted memory in 32bit host.
Signed-off-by: Sheng Yang [EMAIL PROTECTED]
---
arch/x86/kvm/mmu.c |6 +++---
include/asm-x86/kvm_host.h |8 +---
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 7e70e97..23610b5 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -789,7 +789,7 @@ static struct kvm_mmu_page *kvm_mmu_alloc_page(struct
kvm_vcpu *vcpu,
set_page_private(virt_to_page(sp-spt), (unsigned long)sp);
list_add(sp-link, vcpu-kvm-arch.active_mmu_pages);
ASSERT(is_empty_shadow_page(sp-spt));
- sp-slot_bitmap = 0;
+ bitmap_zero(sp-slot_bitmap, KVM_MEMORY_SLOTS + KVM_PRIVATE_MEM_SLOTS);
sp-multimapped = 0;
sp-parent_pte = parent_pte;
--vcpu-kvm-arch.n_free_mmu_pages;
@@ -1364,7 +1364,7 @@ static void page_header_update_slot(struct kvm *kvm, void
*pte, gfn_t gfn)
int slot = memslot_id(kvm, gfn_to_memslot(kvm, gfn));
struct kvm_mmu_page *sp = page_header(__pa(pte));
- __set_bit(slot, sp-slot_bitmap);
+ __set_bit(slot, sp-slot_bitmap);
}
static void mmu_convert_notrap(struct kvm_mmu_page *sp)
@@ -2564,7 +2564,7 @@ void kvm_mmu_slot_remove_write_access(struct kvm *kvm,
int slot)
int i;
u64 *pt;
- if (!test_bit(slot, sp-slot_bitmap))
+ if (!test_bit(slot, sp-slot_bitmap))
continue;
pt = sp-spt;
diff --git a/include/asm-x86/kvm_host.h b/include/asm-x86/kvm_host.h
index 4546535..a38f4a3 100644
--- a/include/asm-x86/kvm_host.h
+++ b/include/asm-x86/kvm_host.h
@@ -192,9 +192,11 @@ struct kvm_mmu_page {
u64 *spt;
/* hold the gfn of each spte inside spt */
gfn_t *gfns;
- unsigned long slot_bitmap; /* One bit set per slot which has memory
- * in this shadow page.
- */
+ /*
+* One bit set per slot which has memory
+* in this shadow page.
+*/
+ DECLARE_BITMAP(slot_bitmap, KVM_MEMORY_SLOTS + KVM_PRIVATE_MEM_SLOTS);
int multimapped; /* More than one parent_pte? */
int root_count; /* Currently serving as active root */
bool unsync;
--
1.5.4.5
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm/ia64: Fix halt emulation logic.
Zhang, Xiantao wrote: Attached the updated one. Thanks! Xiantao From 8d827b19ba03dee74edeb5e2bcc23bed7b9f38ea Mon Sep 17 00:00:00 2001 From: Xiantao Zhang [EMAIL PROTECTED] Date: Thu, 16 Oct 2008 15:58:15 +0800 Subject: [PATCH] kvm/ia64: Fix halt emulation logic. Common halt halding logic is changed by x86 side, this patch fix it for ia64 side. Otherwise, guest may hang once configured more than 2 vcpus. Applied, and will queue for 2.6.28. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] kvm: fix wrong position of clean cscope
My fault... Signed-off-by: Sheng Yang [EMAIL PROTECTED] --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index 6581679..64e296d 100644 --- a/Makefile +++ b/Makefile @@ -110,8 +110,8 @@ srpm: clean: for i in $(if $(WANT_MODULE), kernel) user libkvm qemu libfdt; do \ make -C $$i clean; \ - rm -f ./cscope.* done + rm -f ./cscope.* distclean: clean rm -f config.mak user/config.mak -- 1.5.4.5 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] kvm: fix wrong position of clean cscope
Sheng Yang wrote: My fault... Applied, thanks. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: kvm/ia64: Fix halt emulation logic.
Attached the updated one. Thanks!
Xiantao
From 8d827b19ba03dee74edeb5e2bcc23bed7b9f38ea Mon Sep 17 00:00:00 2001
From: Xiantao Zhang [EMAIL PROTECTED]
Date: Thu, 16 Oct 2008 15:58:15 +0800
Subject: [PATCH] kvm/ia64: Fix halt emulation logic.
Common halt halding logic is changed by x86 side, this patch
fix it for ia64 side. Otherwise, guest may hang once configured
more than 2 vcpus.
Signed-off-by: Xiantao Zhang [EMAIL PROTECTED]
---
arch/ia64/include/asm/kvm_host.h |3 +-
arch/ia64/kvm/kvm-ia64.c | 72
+++---
arch/ia64/kvm/kvm_fw.c |9 -
arch/ia64/kvm/process.c |2 +-
4 files changed, 46 insertions(+), 40 deletions(-)
diff --git a/arch/ia64/include/asm/kvm_host.h
b/arch/ia64/include/asm/kvm_host.h
index 85db124..b9e3c7f 100644
--- a/arch/ia64/include/asm/kvm_host.h
+++ b/arch/ia64/include/asm/kvm_host.h
@@ -365,7 +365,8 @@ struct kvm_vcpu_arch {
long itc_offset;
unsigned long itc_check;
unsigned long timer_check;
- unsigned long timer_pending;
+ unsigned int timer_pending;
+ unsigned int timer_fired;
unsigned long vrr[8];
unsigned long ibr[8];
diff --git a/arch/ia64/kvm/kvm-ia64.c b/arch/ia64/kvm/kvm-ia64.c
index c0699f0..e66a3db 100644
--- a/arch/ia64/kvm/kvm-ia64.c
+++ b/arch/ia64/kvm/kvm-ia64.c
@@ -385,6 +385,7 @@ static int handle_global_purge(struct kvm_vcpu
*vcpu, struct kvm_run *kvm_run)
struct kvm *kvm = vcpu-kvm;
struct call_data call_data;
int i;
+
call_data.ptc_g_data = p-u.ptc_g_data;
for (i = 0; i KVM_MAX_VCPUS; i++) {
@@ -418,33 +419,41 @@ int kvm_emulate_halt(struct kvm_vcpu *vcpu)
ktime_t kt;
long itc_diff;
unsigned long vcpu_now_itc;
-
unsigned long expires;
struct hrtimer *p_ht = vcpu-arch.hlt_timer;
unsigned long cyc_per_usec = local_cpu_data-cyc_per_usec;
struct vpd *vpd = to_host(vcpu-kvm, vcpu-arch.vpd);
- vcpu_now_itc = ia64_getreg(_IA64_REG_AR_ITC) +
vcpu-arch.itc_offset;
+ if (irqchip_in_kernel(vcpu-kvm)) {
- if (time_after(vcpu_now_itc, vpd-itm)) {
- vcpu-arch.timer_check = 1;
- return 1;
- }
- itc_diff = vpd-itm - vcpu_now_itc;
- if (itc_diff 0)
- itc_diff = -itc_diff;
+ vcpu_now_itc = ia64_getreg(_IA64_REG_AR_ITC) +
vcpu-arch.itc_offset;
- expires = div64_u64(itc_diff, cyc_per_usec);
- kt = ktime_set(0, 1000 * expires);
- vcpu-arch.ht_active = 1;
- hrtimer_start(p_ht, kt, HRTIMER_MODE_ABS);
+ if (time_after(vcpu_now_itc, vpd-itm)) {
+ vcpu-arch.timer_check = 1;
+ return 1;
+ }
+ itc_diff = vpd-itm - vcpu_now_itc;
+ if (itc_diff 0)
+ itc_diff = -itc_diff;
+
+ expires = div64_u64(itc_diff, cyc_per_usec);
+ kt = ktime_set(0, 1000 * expires);
+
+ down_read(vcpu-kvm-slots_lock);
+ vcpu-arch.ht_active = 1;
+ hrtimer_start(p_ht, kt, HRTIMER_MODE_ABS);
- if (irqchip_in_kernel(vcpu-kvm)) {
vcpu-arch.mp_state = KVM_MP_STATE_HALTED;
kvm_vcpu_block(vcpu);
hrtimer_cancel(p_ht);
vcpu-arch.ht_active = 0;
+ if (test_and_clear_bit(KVM_REQ_UNHALT, vcpu-requests))
+ if (vcpu-arch.mp_state == KVM_MP_STATE_HALTED)
+ vcpu-arch.mp_state =
+ KVM_MP_STATE_RUNNABLE;
+ up_read(vcpu-kvm-slots_lock);
+
if (vcpu-arch.mp_state != KVM_MP_STATE_RUNNABLE)
return -EINTR;
return 1;
@@ -484,10 +493,6 @@ static int (*kvm_vti_exit_handlers[])(struct
kvm_vcpu *vcpu,
static const int kvm_vti_max_exit_handlers =
sizeof(kvm_vti_exit_handlers)/sizeof(*kvm_vti_exit_handlers);
-static void kvm_prepare_guest_switch(struct kvm_vcpu *vcpu)
-{
-}
-
static uint32_t kvm_get_exit_reason(struct kvm_vcpu *vcpu)
{
struct exit_ctl_data *p_exit_data;
@@ -600,8 +605,6 @@ static int __vcpu_run(struct kvm_vcpu *vcpu, struct
kvm_run *kvm_run)
again:
preempt_disable();
-
- kvm_prepare_guest_switch(vcpu);
local_irq_disable();
if (signal_pending(current)) {
@@ -614,7 +617,7 @@ again:
vcpu-guest_mode = 1;
kvm_guest_enter();
-
+ down_read(vcpu-kvm-slots_lock);
r = vti_vcpu_run(vcpu, kvm_run);
if (r 0) {
local_irq_enable();
@@ -634,9 +637,8 @@ again:
* But we need to prevent reordering, hence this barrier():
*/
barrier();
-
kvm_guest_exit();
-
+ up_read(vcpu-kvm-slots_lock);
preempt_enable();
r = kvm_handle_exit(kvm_run, vcpu);
@@ -673,6 +675,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu
Re: [PATCH] qemu: qemu_fopen_fd: differentiate between reader and writer user
Avi Kivity wrote: Uri Lublin wrote: Weren't there some acks flowing back on the old protocol to let the source now things are fine? There were, but there aren't now. They don't improve reliability. Why do you think they don't improve reliability ? The Ack/Go messages catch the scenario where SRC finishes sending all its state, and DST have a problem loading that state. In that case SRC thinks migration was completed successfully (and stay in stopped mode), while DST exists. The management tool is in contact with both, and can arbitrate. Once it thinks both source and destination are in a good state, it can continue the destination and quit the source. That is true, but in the case I mentioned above it would take the management tool some time (guest down time) to realize what happens, and to send cont to the SRC. With end-of-migration messages SRC discovers DST fails and immediately continues. I agree those messages add some complexity, and slow things a bit for the good/average case. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm/ia64: Fix halt emulation logic.
Zhang, Xiantao wrote:
Hi, Avi
This is the key fix for 2.6.28 merge. Without this patch, guest
may hang once configured with more than 2 vcpus, it is because x86 side
changed the halt handling's common logic, but it misses to change ia64
side.
@@ -398,8 +400,11 @@ static int handle_global_purge(struct kvm_vcpu
*vcpu, struct kvm_run *kvm_run)
if (kvm-vcpus[i]-cpu != -1) {
call_data.vcpu = kvm-vcpus[i];
- smp_call_function_single(kvm-vcpus[i]-cpu,
+ if (kvm-vcpus[i]-cpu != smp_processor_id())
+
smp_call_function_single(kvm-vcpus[i]-cpu,
vcpu_global_purge, call_data,
1);
+ else
+ vcpu_global_purge(call_data);
smp_call_function_single() will call the function on the current cpu if
instructed, so this change is unneeded.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2171940 ] SCSI: Windows (XP) Full Format fails to complete on SCSI
Bugs item #2171940, was opened at 2008-10-16 16:59 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2171940group_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: Technologov (technologov) Assigned to: Nobody/Anonymous (nobody) Summary: SCSI: Windows (XP) Full Format fails to complete on SCSI Initial Comment: Basically Full Format fails on SCSI disk. Tested on: KVM 60-x series up to KVM-77 Host: F7/x64, Intel CPU KVM: KVM-77 Guest OS: Windows XP, 32-bit Quick format succeeds and OS can be installed only that way. Since Linux uses quick format, and does not have Full Format capability AFAIK, Linux guests can be installed successfully. Qemu command: /usr/local/bin/qemu-system-x86_64 -m 256 -cdrom /isos/windows/WindowsXP-sp2-vlk.iso -boot d -drive file=/vm/xp-scsi-test.qcow2,if=scsi,boot=on -name WindowsXP-scsi-test -Alexey Technologov, 16.10.2008. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2171940group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2088475 ] OpenSuse10.2 can not be installed
Bugs item #2088475, was opened at 2008-09-02 11:37 Message generated for change (Comment added) made by technologov You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2088475group_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: Jiajun Xu (jiajun) Assigned to: Nobody/Anonymous (nobody) Summary: OpenSuse10.2 can not be installed Initial Comment: OpenSuse10.2 can not be installed on KVM. Installer will stop after loading ISOLinux. It is against latest kvm comit, kvm.git :5b9207ec01681337786c7898ffc0165ec4e7c2e4 userspace.git :5f2a9719f105e29fbde4529cf919a5351b05da9a. -- Comment By: Technologov (technologov) Date: 2008-10-16 17:04 Message: Known issue: https://sourceforge.net/tracker/index.php?func=detailaid=1760424group_id=180599atid=893831 This bug is duplicate. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2088475group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch] kvm-userland - raise max vcpus to 256 for ia64
Hi, We can now boot upto 60 vcpus on ia64, but thats just the beginning. Would you please add this one to the kvm-userland tree. Thanks, Jes Raise max number of vcpus for ia64 to 256. Signed-off-by: Jes Sorensen [EMAIL PROTECTED] --- libkvm/kvm-common.h | 11 +++ qemu/vl.c |2 +- 2 files changed, 8 insertions(+), 5 deletions(-) Index: kvm-userspace.git/libkvm/kvm-common.h === --- kvm-userspace.git.orig/libkvm/kvm-common.h +++ kvm-userspace.git/libkvm/kvm-common.h @@ -18,13 +18,16 @@ /* FIXME: share this number with kvm */ /* FIXME: or dynamically alloc/realloc regions */ -#ifndef __s390__ -#define KVM_MAX_NUM_MEM_REGIONS 32u -#define MAX_VCPUS 16 -#else +#ifdef __s390__ #define KVM_MAX_NUM_MEM_REGIONS 1u #define MAX_VCPUS 64 #define LIBKVM_S390_ORIGIN (0UL) +#elif __ia64__ +#define KVM_MAX_NUM_MEM_REGIONS 32u +#define MAX_VCPUS 256 +#else +#define KVM_MAX_NUM_MEM_REGIONS 32u +#define MAX_VCPUS 16 #endif Index: kvm-userspace.git/qemu/vl.c === --- kvm-userspace.git.orig/qemu/vl.c +++ kvm-userspace.git/qemu/vl.c @@ -224,7 +224,7 @@ #elif defined(TARGET_I386) #define MAX_CPUS 255 #elif defined(TARGET_IA64) -#define MAX_CPUS 4 +#define MAX_CPUS 256 #else #define MAX_CPUS 1 #endif
Re: [PATCH] qemu: qemu_fopen_fd: differentiate between reader and writer user
Anthony Liguori wrote: Uri Lublin wrote: Anthony Liguori wrote: I have already cut your text, but I don't understand the comment about not being full duplex. Is there a reason why migration needs to be bidirectional? I don't think there's a fundamental reason it needs to be and I think there are some advantages to it being unidirectional. Avi was concerned that my patch makes QEMUFile uni-directional, so I assumed you are trying to fix that too. Unidirectional-only usage of QEMUFile was working. The problem was that the fd implementation registered both get_buffer and put_buffer. If you never register both non-NULL get_buffer and put_buffer (unidirectional), then you do not need the is_write field. Adding the error checking is valuable. Thanks, Uri. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][RFC] Prepare virtio for upstream QEMU merging
Anthony Liguori wrote: But that will require refactoring a lot of these optimizations. In order to do that right, they need to be presented on qemu-devel. It's a whole lot easier to do that incrementally so that people can digest it all instead of blasting a big series. Can you elaborate? Which interfaces will need rework, and why? Last time I tried, virtio-net doesn't work with slirp. I believe it's either because of the GSO changes (unlikely) or because of the can_receive changes (more likely). The can_receive changes probably need some refactoring to be more slirp friendly. The GSO changes are a bit vlan unfriendly. Right now, you could construct something like -net tap -net nic,model=virtio -net model=e1000. e1000 doesn't support GSO and bad things will happen from this. It's very centric to the single-nic, single-host driver model. Also, exposing something like tap_has_vnet_hdr() to the actual network cards violates the layering. The network cards shouldn't have any knowledge of what types of host drivers there are, just what features a particular VLAN supports. It's also unclear how you handle things like NIC hot-plug. What if you add a nic that doesn't support GSO to a VLAN that is using GSO? What about migration? What if you migrate from a host that has GSO support to a host that doesn't support GSO? This later problem is hard and would require either a feature renegotiation mechanism in virtio or software implementation of GSO within QEMU. Okay, we can go along with mangling the current virtio implementation like you proposed. -- error compiling committee.c: too many arguments to function -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Handle INIT before SIPI.
Handle INIT before SIPI.
If SIPI was issued before CPU handled INIT signal the CPU is not reseted.
Signed-off-by: Gleb Natapov [EMAIL PROTECTED]
diff --git a/qemu/qemu-kvm.c b/qemu/qemu-kvm.c
index 577f2b2..dae05b0 100644
--- a/qemu/qemu-kvm.c
+++ b/qemu/qemu-kvm.c
@@ -349,13 +349,20 @@ static void update_regs_for_sipi(CPUState *env)
{
kvm_arch_update_regs_for_sipi(env);
vcpu_info[env-cpu_index].sipi_needed = 0;
-vcpu_info[env-cpu_index].init = 0;
}
static void update_regs_for_init(CPUState *env)
{
+SegmentCache cs = env-segs[R_CS];
+
cpu_reset(env);
+
+/* restore SIPI vector */
+if(vcpu_info[env-cpu_index].sipi_needed)
+env-segs[R_CS] = cs;
+
kvm_arch_load_regs(env);
+vcpu_info[env-cpu_index].init = 0;
}
static void setup_kernel_sigmask(CPUState *env)
@@ -411,10 +418,12 @@ static int kvm_main_loop_cpu(CPUState *env)
kvm_main_loop_wait(env, 1000);
if (env-interrupt_request (CPU_INTERRUPT_HARD | CPU_INTERRUPT_NMI))
env-halted = 0;
- if (!kvm_irqchip_in_kernel(kvm_context) info-sipi_needed)
- update_regs_for_sipi(env);
- if (!kvm_irqchip_in_kernel(kvm_context) info-init)
- update_regs_for_init(env);
+if (!kvm_irqchip_in_kernel(kvm_context)) {
+ if (info-init)
+ update_regs_for_init(env);
+ if (info-sipi_needed)
+ update_regs_for_sipi(env);
+}
if (!env-halted !info-init)
kvm_cpu_exec(env);
env-interrupt_request = ~CPU_INTERRUPT_EXIT;
--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2088475 ] OpenSuse10.2 can not be installed
Bugs item #2088475, was opened at 2008-09-02 01:37 Message generated for change (Comment added) made by jiajun You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2088475group_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: Jiajun Xu (jiajun) Assigned to: Nobody/Anonymous (nobody) Summary: OpenSuse10.2 can not be installed Initial Comment: OpenSuse10.2 can not be installed on KVM. Installer will stop after loading ISOLinux. It is against latest kvm comit, kvm.git :5b9207ec01681337786c7898ffc0165ec4e7c2e4 userspace.git :5f2a9719f105e29fbde4529cf919a5351b05da9a. -- Comment By: Jiajun Xu (jiajun) Date: 2008-10-16 08:23 Message: From the bug description, opensuse11.0 should work? And we did not meet guest crash when installation, guest hangs when loading grub and no any error messages printed. -- Comment By: Technologov (technologov) Date: 2008-10-16 08:04 Message: Known issue: https://sourceforge.net/tracker/index.php?func=detailaid=1760424group_id=180599atid=893831 This bug is duplicate. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2088475group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: problem with pxe boot off private bridge
Stephen Dennis wrote: Hello My aim is to have a VM with 2 network interfaces, one bridged to the outside world and the other bridged on a private network. From the private interface this VM runs DHCP and PXE services to start and install VM's which have one network interface tapped on the private bridge. All machines are centos or ubuntu guests. I confirm that simply starting a linux guest that used the private bridge to get a dhcp address works fine. However, using a pxe capable boot rom, dhcp fails. I have confirmed the dhcp request and offer appear on both tap interfaces and the intervening bridge interface. Make sure no checksum offload optimizations are causing trouble. We had a similar problem on Xen where checksums were only generated when packets left through the real NIC. Check the PXE server setup, to make sure the DHCP/PXE packets are being checksummed properly on the private network. Steve I also confirm that the pxe capable boot rom works if its using the bridge to the external network. I have tried all the pxe boot roms available with the exact same result. This could be a networking configuration problem or perhaps a bug somewhere in the nic emulation or boot rom. Any ideas for further diagnostics or solutions appreciated. More config information below. Thanks Stephen kvm -no-reboot -m 1000 -boot c \ -hda ux-head.img \ -net nic,vlan=0,macaddr=DE:AD:BE:EF:7d:e4 -net tap,vlan=0,ifname=tap0 \ -net nic,vlan=1,macaddr=DE:AD:BE:EF:7d:e5 -net tap,vlan=1,ifname=tap1 kvm -no-reboot -m 1000 -boot n \ -hda ux-node-1.img \ -net nic,vlan=1,macaddr=DE:AD:BE:EF:7d:e6,model=ne2k_pci \ -net tap,vlan=1,ifname=tap2 QEMU PC emulator version 0.9.1 (kvm-62), Copyright (c) 2003-2008 Fabrice Bellard On Ubuntu 8.04 Linux x2 2.6.24-19-generic #1 SMP Wed Aug 20 17:53:40 UTC 2008 x86_64 GNU/Linux br0 Link encap:Ethernet HWaddr 00:22:15:1e:7d:e4 inet addr:172.16.198.251 Bcast:172.16.198.255 Mask:255.255.255.0 inet6 addr: fe80::222:15ff:fe1e:7de4/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:61406 errors:0 dropped:0 overruns:0 frame:0 TX packets:373150 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3677008 (3.5 MB) TX bytes:536494463 (511.6 MB) br1 Link encap:Ethernet HWaddr 00:ff:1e:0d:da:5d inet6 addr: fe80::2ff:1eff:fe0d:da5d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:110 errors:0 dropped:0 overruns:0 frame:0 TX packets:493 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:27599 (26.9 KB) TX bytes:119935 (117.1 KB) br1:avahi Link encap:Ethernet HWaddr 00:ff:1e:0d:da:5d inet addr:169.254.6.156 Bcast:169.254.255.255 Mask:255.255.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 eth0 Link encap:Ethernet HWaddr 00:22:15:1e:7d:e4 inet6 addr: fe80::222:15ff:fe1e:7de4/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:61512 errors:0 dropped:0 overruns:0 frame:0 TX packets:373396 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4803323 (4.5 MB) TX bytes:538013422 (513.0 MB) Interrupt:16 eth1 Link encap:Ethernet HWaddr 00:22:15:1e:7e:d4 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:17 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:39299 errors:0 dropped:0 overruns:0 frame:0 TX packets:39299 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:512377716 (488.6 MB) TX bytes:512377716 (488.6 MB) tap0 Link encap:Ethernet HWaddr 00:ff:82:b4:0a:dc inet6 addr: fe80::2ff:82ff:feb4:adc/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:249 errors:0 dropped:0 overruns:0 frame:0 TX packets:223 errors:0 dropped:289 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:23823 (23.2 KB) TX bytes:33914 (33.1 KB) tap1 Link encap:Ethernet HWaddr 00:ff:77:d3:db:4b inet6 addr: fe80::2ff:77ff:fed3:db4b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:90 errors:0 dropped:0 overruns:0 frame:0 TX packets:80 errors:0 dropped:436 overruns:0 carrier:0
[ kvm-Bugs-2171940 ] SCSI: Windows (XP) Full Format fails to complete on SCSI
Bugs item #2171940, was opened at 2008-10-16 16:59 Message generated for change (Comment added) made by lvivier You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2171940group_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: Technologov (technologov) Assigned to: Nobody/Anonymous (nobody) Summary: SCSI: Windows (XP) Full Format fails to complete on SCSI Initial Comment: Basically Full Format fails on SCSI disk. Tested on: KVM 60-x series up to KVM-77 Host: F7/x64, Intel CPU KVM: KVM-77 Guest OS: Windows XP, 32-bit Quick format succeeds and OS can be installed only that way. Since Linux uses quick format, and does not have Full Format capability AFAIK, Linux guests can be installed successfully. Qemu command: /usr/local/bin/qemu-system-x86_64 -m 256 -cdrom /isos/windows/WindowsXP-sp2-vlk.iso -boot d -drive file=/vm/xp-scsi-test.qcow2,if=scsi,boot=on -name WindowsXP-scsi-test -Alexey Technologov, 16.10.2008. -- Comment By: Laurent Vivier (lvivier) Date: 2008-10-16 17:36 Message: latest KVM introduces latest qemu. In this release of qemu SCSI commandz return status has been corrected, so unimplemented commands were silently ignored whereas now they return errors. The solution is easy: modify the code to ignore the faulty SCSI command, I did this for instance for VERIFY. Could you activate debug in hw/scsi-disk.c and send me logs ? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=893831aid=2171940group_id=180599 -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kvm hangs when rebooting a guest VM
Bernhard Schmidt [EMAIL PROTECTED] wrote: I have a small but annoying issue. Host: * AMD Athlon64 * Debian Lenny, Kernel 2.6.26-1-amd64 * kvm-72 (Debian package) or kvm-76 (self-built) Guest: * monolithic vanilla 2.6.26, KVM_GUEST and KVM_CLOCK, VIRTIO for both block device and NIC * various Debian and Ubuntu versions I don't use any libvirt or similar things, I start the VMs by directly calling kvm in a script. I directly specify the kernel and it's options with the -kernel and -append parameters. Problem: Shutting down a VM from inside it (shutdown -h now) works just fine. Will now halt. [171368.812319] ACPI: Preparing to enter system sleep state S5 [171368.816964] Power down. [171368.820177] acpi_power_off called then the kvm process exits. However, restarting the VM (reboot) does not work ... Will now restart. [ 37.088270] Restarting system. [ 37.089775] machine restart this is where the KVM process hangs in a loop and uses 100% CPU on the host. I can still kill it (Ctrl-A x) or change to it's console, but system_restart doesn't seem to work there either. iggy suggested to use an extboot.bin from an earlier kvm version (I used kvm-60), didn't change. Any idea what could be wrong here? Noone with an idea here? I've upgraded to kvm-77 and Linux 2.6.27 for both host and guest in the meantime (and moved from an AMD AM2-box to an Intel Dualcore Xeon platform), still no change. Bernhard -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM can't install Windows
I need a Win98SE VM to do some software testing and support. Unfortunately KVM seems to not be able to run 98SE, although it runs a bunch of more recent Windows versions I can't use for this. I really don't want to support multiple VM servers, and there is pressure to go to VISTA and VMware. Base is a small server with Intel quad core 2.66GHz CPU, 8GB memory, and 2TB SATA. FC9, fully patched, 32 bit PATA kernel. Running some FC4, CentOS, and DragonFly machines for various services. Someone have a pointer to some docs or something? -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM can't install Windows
Bill Davidsen wrote: I need a Win98SE VM to do some software testing and support. Unfortunately KVM seems to not be able to run 98SE, although it runs a bunch of more recent Windows versions I can't use for this. I really don't want to support multiple VM servers, and there is pressure to go to VISTA and VMware. Lots of folks here have used KVM with recent Windows guests successfully, myself included. Could you be more explicit about what is going wrong, other than it dosen't work? Knowing which KVM release you're using (and which kernel) would be a Good Thing as well. See whether your guest/version combination is expected to work at http://kvm.qumranet.com/kvmwiki/Guest_Support_Status -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] qemu: qemu_fopen_fd: differentiate between reader and writer user
Uri Lublin wrote: That is true, but in the case I mentioned above it would take the management tool some time (guest down time) to realize what happens, and to send cont to the SRC. With end-of-migration messages SRC discovers DST fails and immediately continues. I agree those messages add some complexity, and slow things a bit for the good/average case. It's the classic general's dilemma. If SRC waits for DST to send an ACK, DST still doesn't know whether SRC received the ACK so it doesn't know whether it's truly safe to continue. This is why migration doesn't quit SRC immediately, and leaves SRC in the stopped state. It's because the only safe way to handle this is with a third party that is reliable. Regards, Anthony Liguori -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
