[ kvm-Bugs-2741742 ] debian-20090117-kfreebsd-i386 installation fails on kvm > 80
Bugs item #2741742, was opened at 2009-04-08 02:07 Message generated for change (Settings changed) made by amitshah You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2741742&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: Pending Resolution: None Priority: 5 Private: No Submitted By: Andreas Jacobsen (scoof) Assigned to: Nobody/Anonymous (nobody) Summary: debian-20090117-kfreebsd-i386 installation fails on kvm > 80 Initial Comment: Machine: Thinkpad T60 with Intel T2400, running 32 bit Debian Linux trillian 2.6.26-1-686 #1 SMP Sat Jan 10 18:29:31 UTC 2009 i686 GNU/Linux ii linux-image-2.6.26-1-686 2.6.26-13 Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4 KVM command-line: kvm -m 1024 -name kfreebsd-debian -hda debian-kfreebsd.img -hdb debian-kfreebsd-swap.img -cdrom debian-20090117-kfreebsd-i386-install.iso -boot d -net nic,macaddr=00:16:3e:49:01:33,vlan=0 -net tap debian-kfreebsd.img is an 8G qcow2 image, debian-kfreebsd-swap.img is a 1G qcow2 image. debian-20090117-kfreebsd-i386-install.iso is available from http://glibc-bsd.alioth.debian.org/install-cd/kfreebsd-i386/20090117/debian-20090117-kfreebsd-i386-install.iso Steps to reproduce: Boot KVM > 80 Select Express Select ad0 Press a, q Select BootMgr Select ad1 Press a, q Select BootMgr Press tab, enter Press c, enter, enter, /, enter Select ad1 Press c, enter, s, enter Press q Select Minimal Select Exit Select CD/DVD Select cd0 Select Yes Press Alt-F3 to select Select Europe Select Copenhagen Installation should now fail Installation fails with kvm > 80 Installation succeeds with qemu without kqemu Installation succeeds with kvm-80 Installation fails with kvm-83 and -no-kvm Installation fails with kvm-83 and -no-kvm-pit Sometimes, it fails with a "duplicate alloc" or "duplicate dealloc" error message -- >Comment By: Amit Shah (amitshah) Date: 2009-04-08 12:19 Message: I just tried this with the kvm git snapshot and it works fine. Can you try with a nightly build or from the git tree? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2741742&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string
On 04/07/09 19:13, Jamie Lokier wrote:
Anthony Liguori wrote:
I still think libvirt should work with versions of QEMU/KVM built from
svn/git though. I think the only way to do that is for libvirt to relax
their version checks to accommodate suffixes in the form
major.minor.stable-foo.
Ok, but try to stick to a well-defined rule about what suffix means
"later" or "earlier". In package managers, "1.2.3-rc1" is typically
seen as a later version than "1.2.3" purely due to syntax.
Fedora typically handles this using a leading zero in the 'release'
component for pre-final versions, like this: app-1.2.3-0.rc1.fc11
(rc/beta) and app-1.2.3-1.fc11 (final). Likewise for snapshots:
app-1.2.3-0.svn${date}.fc11
If you're
consistently meaning "0.11.0-rc1" is earlier than "0.11.0" (final),
that might need to be encoded in libvirt and other wrappers, if they
have any fine-grained version sensistivity such as command line
changes or bug workarounds.
libvirt scans the help text to figure which features are present
(checking for as -drive and -uuid cmd line switches for example).
cheers,
Gerd
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] do not keep interrupt window closed by sti in real mode
Avi Kivity wrote: > > I'm guessing the problem is due to the second instruction. We don't > clear the 'blocked by interrupt shadow' flag when we emulate, which > extends interrupt shadow by one more instruction. If the instruction > sequence is 'sti hlt' we end in an inconsistent state. > Ah, and since we're in real mode, we have to emulate everything (at least on some hardware), right? So we really do need to clear the interrupt shadow bit in the interpreter... I don't see a way around that. Otherwise not just STI but MOV SS shadows will break, and in real mode MOV SS shadow is crucial. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: strange guest slowness after some time
Rusty Russell schrieb: On Tuesday 07 April 2009 00:49:17 Tomasz Chmielewski wrote: Tomasz Chmielewski schrieb: As I mentioned, it was using virtio net. Guests running with e1000 (and virtio_blk) don't have this problem. Also, virtio_console seem to be affected by this "slowness" issue. I'm pretty sure this is different. Older virtio_console code ignored interrupts and polled, and use a heuristic to back off on polling (this was because we used the generic "hvc" infrastructure which hacked support). By "older" you mean guest drivers? I have 2.6.27.x on guests and see this issue. If you meant host, I use kvm-84. You'll find a delay on the first keystroke after idle, but none on the second. I'm not sure. Press "a" seven times fast, and 7 characters will be printed a second later. But: wait one second more, it will be unresponsive again. You won't see the characters "as you type". Also these symptoms are very similar to virtio_net issue: - it happens only on some guest (even if they have the same kernel and userspace) after a random period of time - it used to happen for me _always_ when network got slow with virtio_net driver - it doesn't go away with guest restart initiated from guest's system - it goes away with kvm process stop/start (i.e. new kvm process), but can appear later with no apparent cause -- Tomasz Chmielewski http://wpkg.org -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] do not keep interrupt window closed by sti in real mode
H. Peter Anvin wrote: Glauber Costa wrote: While in real mode, sti does not block interrupts from the subsequent instruction. This is stated at Intel SDM Volume 2b, page 4-432 I don't see how you're getting that idea from the STI documentation -- and I am quite sure that that is not the case. Quite on the contrary. The only differences between protected mode and real mode has to do with the handling of VIF when CPL=3 (this rather naturally falls out if one considers CPL=0 in real mode). I'm guessing the problem is due to the second instruction. We don't clear the 'blocked by interrupt shadow' flag when we emulate, which extends interrupt shadow by one more instruction. If the instruction sequence is 'sti hlt' we end in an inconsistent state. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] do not keep interrupt window closed by sti in real mode
Glauber Costa wrote: > While in real mode, sti does not block interrupts from the subsequent > instruction. This is stated at Intel SDM Volume 2b, page 4-432 I don't see how you're getting that idea from the STI documentation -- and I am quite sure that that is not the case. Quite on the contrary. The only differences between protected mode and real mode has to do with the handling of VIF when CPL=3 (this rather naturally falls out if one considers CPL=0 in real mode). The text is: "If protected-mode virtual interrupts are not enabled, STI sets the interrupt flag (IF) in the EFLAGS register. After the IF flag is set, the processor begins responding to external, maskable interrupts after the next instruction is executed. The delayed effect of this instruction is provided to allow interrupts to be enabled just before returning from a procedure (or subroutine). For instance, if an STI instruction is followed by an RET instruction, the RET instruction is allowed to execute before external interrupts are recognized1. If the STI instruction is followed by a CLI instruction (which clears the IF flag), the effect of the STI instruction is negated." Obviously, in real mode, "protected-mode virtual interrupts" are not enabled, as is also confirmed by Table 4-5. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] do not keep interrupt window closed by sti in real mode
While in real mode, sti does not block interrupts from the subsequent
instruction. This is stated at Intel SDM Volume 2b, page 4-432
Without this patch, I cannot boot gpxe option roms at vmx machines.
This is described at https://bugzilla.redhat.com/show_bug.cgi?id=494469
Signed-off-by: Glauber Costa
---
arch/x86/kvm/vmx.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c6997c0..51e0b8a 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2490,18 +2490,19 @@ static void vmx_inject_nmi(struct kvm_vcpu *vcpu)
static void vmx_update_window_states(struct kvm_vcpu *vcpu)
{
u32 guest_intr = vmcs_read32(GUEST_INTERRUPTIBILITY_INFO);
+ int rmode = vcpu->arch.rmode.active;
vcpu->arch.nmi_window_open =
- !(guest_intr & (GUEST_INTR_STATE_STI |
- GUEST_INTR_STATE_MOV_SS |
+ (rmode || !(guest_intr & GUEST_INTR_STATE_STI)) &&
+ !(guest_intr & (GUEST_INTR_STATE_MOV_SS |
GUEST_INTR_STATE_NMI));
if (!cpu_has_virtual_nmis() && to_vmx(vcpu)->soft_vnmi_blocked)
vcpu->arch.nmi_window_open = 0;
vcpu->arch.interrupt_window_open =
((vmcs_readl(GUEST_RFLAGS) & X86_EFLAGS_IF) &&
-!(guest_intr & (GUEST_INTR_STATE_STI |
-GUEST_INTR_STATE_MOV_SS)));
+ (rmode || !(guest_intr & GUEST_INTR_STATE_STI)) &&
+!(guest_intr & GUEST_INTR_STATE_MOV_SS));
}
static int vmx_interrupt_allowed(struct kvm_vcpu *vcpu)
--
1.6.2
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] kvm: Fix wrong counting of MSI-X table size
The PCI spec said...
System software reads this field to determine the MSI-X Table Size *N*,
which is encoded as *N-1*. For example, a returned value of “011”
indicates a table size of 4.
Signed-off-by: Sheng Yang
---
qemu/hw/device-assignment.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/qemu/hw/device-assignment.c b/qemu/hw/device-assignment.c
index 09e54ae..f33ce3c 100644
--- a/qemu/hw/device-assignment.c
+++ b/qemu/hw/device-assignment.c
@@ -818,6 +818,7 @@ static int assigned_dev_update_msix_mmio(PCIDevice *pci_dev)
entries_max_nr = pci_dev->config[pos + 2];
entries_max_nr &= PCI_MSIX_TABSIZE;
+entries_max_nr += 1;
/* Get the usable entry number for allocating */
for (i = 0; i < entries_max_nr; i++) {
--
1.5.4.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kvm] [PATCH 13/16] kvm: enable MSI-X capabilty for assigned device
On Wednesday 08 April 2009 00:38:10 Alex Williamson wrote: > On Tue, 2009-04-07 at 14:09 +0800, Sheng Yang wrote: > > On Saturday 04 April 2009 05:27:43 Alex Williamson wrote: > > > Do we need some disable logic here? If I toggle a bnx2 NIC in a guest, > > > I get the following when it attempts to come back up: > > > > > > MSI-X entry number is zero! > > > assigned_dev_update_msix_mmio: No such device or address > > > > It seems that driver didn't fill the MMIO with any correct MSIX > > information, or the program fail to intercept it after driver set enable > > bit of MSIX. It's strange... (Have it got something to do with PM and > > some EXP feature you mentioned?) > > My guess was that it filled in the MSIX info, but then can't find a free > slot to reload the MSIX data when it tries to re-enable MSIX. I hacked > the bnx2 driver to not rely on PM and EXP capabilities for this test, it > seems to work, but it's possible that I broke something. My host also > locks up the second time I try to export this device to a guest, maybe a > problem with my bnx2 hacks, MSIX not getting reset, or prototype > hardware. I'll see if I can find another MSIX capable device to export > to a guest. > > > Could you enable DEVICE_ASSSIGNMENT_DEBUG=1 in > > qemu/hw/device-assignment.c and post the output? > > Yup, see below. The error comes after I 'ifdown eth0; ifup eth0' in the > guest. Note bnx2 appears to only turn on MSIX for SMP systems. Thanks, > > Alex Seems your "ifdown/ifup" script reload the module? Oh god, I found one bug after checked the spec: System software reads this field to determine the MSI-X Table Size *N*, which is encoded as *N-1*. For example, a returned value of “011” indicates a table size of 4. But it seems still can't explain the problem...(OK, it may affect the guest in a unknown way as well...) I would post a fix for it soon. > val=0x0008 len=2 assigned_dev_pci_write_config: (4.0): address=0052 > val=0x0008 len=2 assigned_dev_pci_read_config: (4.0): address=0006 > val=0x0010 len=2 assigned_dev_pci_read_config: (4.0): address=0034 > val=0x0040 len=1 assigned_dev_pci_read_config: (4.0): address=0040 > val=0x0005 len=1 assigned_dev_pci_read_config: (4.0): address=0041 > val=0x0050 len=1 assigned_dev_pci_read_config: (4.0): address=0050 > val=0x0011 len=1 assigned_dev_pci_read_config: (4.0): address=0052 > val=0x0008 len=2 assigned_dev_pci_read_config: (4.0): address=0054 > val=0xc000 len=4 msix_mmio_writel: write to MSI-X entry table mmio > offset 0x0, val 0xfeeff00c msix_mmio_writel: write to MSI-X entry table > mmio offset 0x4, val 0x0 msix_mmio_writel: write to MSI-X entry table mmio > offset 0x8, val 0x4191 msix_mmio_writel: write to MSI-X entry table mmio > offset 0x10, val 0xfeeff00c msix_mmio_writel: write to MSI-X entry table > mmio offset 0x14, val 0x0 msix_mmio_writel: write to MSI-X entry table mmio > offset 0x18, val 0x4199 msix_mmio_writel: write to MSI-X entry table mmio > offset 0x20, val 0xfeeff00c msix_mmio_writel: write to MSI-X entry table > mmio offset 0x24, val 0x0 msix_mmio_writel: write to MSI-X entry table mmio > offset 0x28, val 0x41a1 msix_mmio_writel: write to MSI-X entry table mmio > offset 0x30, val 0xfeeff00c msix_mmio_writel: write to MSI-X entry table > mmio offset 0x34, val 0x0 msix_mmio_writel: write to MSI-X entry table mmio > offset 0x38, val 0x41a9 msix_mmio_writel: write to MSI-X entry table mmio > offset 0x40, val 0xfeeff00c msix_mmio_writel: write to MSI-X entry table > mmio offset 0x44, val 0x0 msix_mmio_writel: write to MSI-X entry table mmio > offset 0x48, val 0x41b1 msix_mmio_writel: write to MSI-X entry table mmio > offset 0x50, val 0xfeeff00c msix_mmio_writel: write to MSI-X entry table > mmio offset 0x54, val 0x0 msix_mmio_writel: write to MSI-X entry table mmio > offset 0x58, val 0x41b9 msix_mmio_writel: write to MSI-X entry table mmio > offset 0x60, val 0xfeeff00c msix_mmio_writel: write to MSI-X entry table > mmio offset 0x64, val 0x0 msix_mmio_writel: write to MSI-X entry table mmio > offset 0x68, val 0x41c1 msix_mmio_writel: write to MSI-X entry table mmio > offset 0x70, val 0xfeeff00c msix_mmio_writel: write to MSI-X entry table > mmio offset 0x74, val 0x0 msix_mmio_writel: write to MSI-X entry table mmio > offset 0x78, val 0x41c9 msix_mmio_writel: write to MSI-X entry table mmio > offset 0x80, val 0xfeeff00c msix_mmio_writel: write to MSI-X entry table > mmio offset 0x84, val 0x0 msix_mmio_writel: write to MSI-X entry table mmio > offset 0x88, val 0x41d1 assigned_dev_pci_read_config: (4.0): address=0004 > val=0x0046 len=2 assigned_dev_pci_write_config: (4.0): address=0004 > val=0x0446 len=2 assigned_dev_pci_write_config: NON BAR (4.0): The writing to MMIO have been intercepted, but code fail to count it? Strange... Could you try this debug? diff --git a/qemu/hw/device-assignment.c b/qemu/hw/device-assignment.c index 09e54ae..ba31bed 100644 --- a/qemu/hw/device-assignment.c ++
[PATH 2/2] kvm userspace: Add MCE simulation to kvm
- MCE features is initialized when VCPU is initialized according to CPUID.
- A monitor command "mce" is added to inject a MCE.
Signed-off-by: Huang Ying
---
libkvm/libkvm-x86.c| 10 ++
libkvm/libkvm.h|2 ++
qemu/monitor.c | 26 ++
qemu/qemu-kvm-x86.c| 22 +-
qemu/qemu-kvm.c| 26 ++
qemu/qemu-kvm.h|4
qemu/target-i386/cpu.h |3 +++
7 files changed, 92 insertions(+), 1 deletion(-)
--- a/qemu/monitor.c
+++ b/qemu/monitor.c
@@ -1556,6 +1556,31 @@ static void do_info_status(Monitor *mon)
}
+#if defined(TARGET_I386) || defined(TARGET_X86_64)
+static void do_inject_mce(Monitor *mon,
+ int cpu_index, int bank,
+ unsigned status_hi, unsigned status_lo,
+ unsigned mcg_status_hi, unsigned mcg_status_lo,
+ unsigned addr_hi, unsigned addr_lo,
+ unsigned misc_hi, unsigned misc_lo)
+{
+ CPUState *env;
+ struct kvm_x86_mce mce = {
+ .bank = bank,
+ .status = ((uint64_t)status_hi << 32) | status_lo,
+ .mcg_status = ((uint64_t)mcg_status_hi << 32) | mcg_status_lo,
+ .addr = ((uint64_t)addr_hi << 32) | addr_lo,
+ .misc = ((uint64_t)misc_hi << 32) | misc_lo,
+ };
+
+ for (env = first_cpu; env != NULL; env = env->next_cpu)
+ if (env->cpu_index == cpu_index && env->mcg_cap) {
+ kvm_inject_x86_mce(env, &mce);
+ break;
+ }
+}
+#endif
+
static void do_balloon(Monitor *mon, int value)
{
ram_addr_t target = value;
@@ -1757,6 +1782,7 @@ static const mon_cmd_t mon_cmds[] = {
"[tap,user,socket,vde] options", "add host VLAN client" },
{ "host_net_remove", "is", net_host_device_remove,
"vlan_id name", "remove host VLAN client" },
+{ "mce", "ii", do_inject_mce, "cpu bank status mcgstatus addr misc",
"inject a MCE on the given CPU"},
#endif
{ "balloon", "i", do_balloon,
"target", "request VM to change it's memory allocation (in MB)" },
--- a/libkvm/libkvm-x86.c
+++ b/libkvm/libkvm-x86.c
@@ -379,6 +379,16 @@ int kvm_set_msrs(kvm_context_t kvm, int
return r;
}
+int kvm_setup_mce(kvm_context_t kvm, int vcpu, uint64_t *mcg_cap)
+{
+return ioctl(kvm->vcpu_fd[vcpu], KVM_X86_SETUP_MCE, mcg_cap);
+}
+
+int kvm_set_mce(kvm_context_t kvm, int vcpu, struct kvm_x86_mce *m)
+{
+return ioctl(kvm->vcpu_fd[vcpu], KVM_X86_SET_MCE, m);
+}
+
static void print_seg(FILE *file, const char *name, struct kvm_segment *seg)
{
fprintf(stderr,
--- a/libkvm/libkvm.h
+++ b/libkvm/libkvm.h
@@ -27,6 +27,8 @@ typedef struct kvm_context *kvm_context_
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);
+int kvm_setup_mce(kvm_context_t, int vcpu, uint64_t *mcg_cap);
+int kvm_set_mce(kvm_context_t, int vcpu, struct kvm_x86_mce *mce);
#endif
/*!
--- a/qemu/qemu-kvm-x86.c
+++ b/qemu/qemu-kvm-x86.c
@@ -457,6 +457,15 @@ void kvm_arch_save_regs(CPUState *env)
}
}
+void kvm_arch_inject_x86_mce(CPUState *env, struct kvm_x86_mce *mce)
+{
+int rc;
+
+rc = kvm_set_mce(kvm_context, env->cpu_index, mce);
+if (rc == -1)
+ perror("kvm_set_mce FAILED");
+}
+
static void do_cpuid_ent(struct kvm_cpuid_entry2 *e, uint32_t function,
uint32_t count, CPUState *env)
{
@@ -510,7 +519,7 @@ int kvm_arch_qemu_init_env(CPUState *cen
struct kvm_cpuid_entry2 *pv_ent;
uint32_t signature[3];
#endif
-int cpuid_nent = 0;
+int cpuid_nent = 0, family;
CPUState copy;
uint32_t i, j, limit;
@@ -566,6 +575,17 @@ int kvm_arch_qemu_init_env(CPUState *cen
do_cpuid_ent(&cpuid_ent[cpuid_nent++], i, 0, ©);
kvm_setup_cpuid2(kvm_context, cenv->cpu_index, cpuid_nent, cpuid_ent);
+
+#define MCG_CAP_DEF0x904
+
+if (((cenv->cpuid_version >> 8)&0xF) >= 6 &&
+ (cenv->cpuid_features&(CPUID_MCE|CPUID_MCA)) == (CPUID_MCE|CPUID_MCA)) {
+ uint64_t mcg_cap = MCG_CAP_DEF;
+ if (kvm_setup_mce(kvm_context, cenv->cpu_index, &mcg_cap))
+ perror("kvm_setup_mce FAILED");
+ cenv->mcg_cap = mcg_cap;
+}
+
return 0;
}
--- a/qemu/qemu-kvm.h
+++ b/qemu/qemu-kvm.h
@@ -74,6 +74,8 @@ int kvm_arch_try_push_interrupts(void *o
void kvm_arch_push_nmi(void *opaque);
void kvm_arch_update_regs_for_sipi(CPUState *env);
void kvm_arch_cpu_reset(CPUState *env);
+struct kvm_x86_mce;
+void kvm_arch_inject_x86_mce(CPUState *env, struct kvm_x86_mce *mce);
struct kvm_guest_debug;
struct kvm_debug_exit_arch;
@@ -233,4 +235,6 @@ static inline void cpu_synchronize_state
}
}
+void kvm_inject_x86_mce(CPUState *env, struc
[PATH 1/2] kvm userspace: Add handler_8/9/10 support to monitor
This is needed by MCE simulation. Signed-off-by: Huang Ying --- qemu/monitor.c | 24 1 file changed, 24 insertions(+) --- a/qemu/monitor.c +++ b/qemu/monitor.c @@ -2513,6 +2513,15 @@ static void monitor_handle_command(Monit void *arg3, void *arg4, void *arg5); void (*handler_7)(Monitor *mon, void *arg0, void *arg1, void *arg2, void *arg3, void *arg4, void *arg5, void *arg6); +void (*handler_8)(Monitor *mon, void *arg0, void *arg1, void *arg2, + void *arg3, void *arg4, void *arg5, void *arg6, + void *arg7); +void (*handler_9)(Monitor *mon, void *arg0, void *arg1, void *arg2, + void *arg3, void *arg4, void *arg5, void *arg6, + void *arg7, void *arg8); +void (*handler_10)(Monitor *mon, void *arg0, void *arg1, void *arg2, + void *arg3, void *arg4, void *arg5, void *arg6, + void *arg7, void *arg8, void *arg9); #ifdef DEBUG monitor_printf(mon, "command='%s'\n", cmdline); @@ -2810,6 +2819,21 @@ static void monitor_handle_command(Monit handler_7(mon, args[0], args[1], args[2], args[3], args[4], args[5], args[6]); break; +case 8: +handler_8 = cmd->handler; +handler_8(mon, args[0], args[1], args[2], args[3], args[4], args[5], + args[6], args[7]); +break; +case 9: +handler_9 = cmd->handler; +handler_9(mon, args[0], args[1], args[2], args[3], args[4], args[5], + args[6], args[7], args[8]); +break; +case 10: +handler_10 = cmd->handler; +handler_10(mon, args[0], args[1], args[2], args[3], args[4], args[5], + args[6], args[7], args[8], args[9]); +break; default: monitor_printf(mon, "unsupported number of arguments: %d\n", nb_args); goto fail; signature.asc Description: This is a digitally signed message part
[PATCH] Add MCE support to KVM
Add MCE support to KVM. The related MSRs are emulated. A new vcpu
ioctl command KVM_X86_SETUP_MCE is used to setup MCE emulation such as
the mcg_cap. MCE is injected via vcpu ioctl command
KVM_X86_SET_MCE. Extended machine-check state (MCG_EXT_P) and CMCI are
not implemented.
Signed-off-by: Huang Ying
---
arch/x86/include/asm/kvm_host.h |5
arch/x86/include/asm/mce.h |1
arch/x86/kvm/x86.c | 202 +++-
include/linux/kvm.h | 15 ++
4 files changed, 199 insertions(+), 24 deletions(-)
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#define MAX_IO_MSRS 256
#define CR0_RESERVED_BITS \
@@ -734,23 +735,43 @@ static int set_msr_mtrr(struct kvm_vcpu
return 0;
}
-int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
+static int set_msr_mce(struct kvm_vcpu *vcpu, u32 msr, u64 data)
{
+ u64 mcg_cap = vcpu->arch.mcg_cap;
+ unsigned bank_num = mcg_cap & 0xff;
+
switch (msr) {
- case MSR_EFER:
- set_efer(vcpu, data);
- break;
- case MSR_IA32_MC0_STATUS:
- pr_unimpl(vcpu, "%s: MSR_IA32_MC0_STATUS 0x%llx, nop\n",
- __func__, data);
- break;
case MSR_IA32_MCG_STATUS:
- pr_unimpl(vcpu, "%s: MSR_IA32_MCG_STATUS 0x%llx, nop\n",
- __func__, data);
+ vcpu->arch.mcg_status = data;
break;
case MSR_IA32_MCG_CTL:
- pr_unimpl(vcpu, "%s: MSR_IA32_MCG_CTL 0x%llx, nop\n",
- __func__, data);
+ if (!(mcg_cap & MCG_CTL_P))
+ return 1;
+ if (data != 0 && data != ~(u64)0)
+ return -1;
+ vcpu->arch.mcg_ctl = data;
+ break;
+ default:
+ if (msr >= MSR_IA32_MC0_CTL &&
+ msr < MSR_IA32_MC0_CTL + 4 * bank_num) {
+ u32 offset = msr - MSR_IA32_MC0_CTL;
+ /* only 0 or all 1s can be written to IA32_MCi_CTL */
+ if ((offset & 0x3) == 0 &&
+ data != 0 && data != ~(u64)0)
+ return -1;
+ vcpu->arch.mce_banks[offset] = data;
+ break;
+ }
+ return 1;
+ }
+ return 0;
+}
+
+int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
+{
+ switch (msr) {
+ case MSR_EFER:
+ set_efer(vcpu, data);
break;
case MSR_IA32_DEBUGCTLMSR:
if (!data) {
@@ -807,6 +828,8 @@ int kvm_set_msr_common(struct kvm_vcpu *
break;
}
default:
+ if (!set_msr_mce(vcpu, msr, data))
+ break;
pr_unimpl(vcpu, "unhandled wrmsr: 0x%x data %llx\n", msr, data);
return 1;
}
@@ -861,26 +884,49 @@ static int get_msr_mtrr(struct kvm_vcpu
return 0;
}
-int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata)
+static int get_msr_mce(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata)
{
u64 data;
+ u64 mcg_cap = vcpu->arch.mcg_cap;
+ unsigned bank_num = mcg_cap & 0xff;
switch (msr) {
- case 0xc0010010: /* SYSCFG */
- case 0xc0010015: /* HWCR */
- case MSR_IA32_PLATFORM_ID:
case MSR_IA32_P5_MC_ADDR:
case MSR_IA32_P5_MC_TYPE:
- case MSR_IA32_MC0_CTL:
- case MSR_IA32_MCG_STATUS:
+ data = 0;
+ break;
case MSR_IA32_MCG_CAP:
+ data = vcpu->arch.mcg_cap;
+ break;
case MSR_IA32_MCG_CTL:
- case MSR_IA32_MC0_MISC:
- case MSR_IA32_MC0_MISC+4:
- case MSR_IA32_MC0_MISC+8:
- case MSR_IA32_MC0_MISC+12:
- case MSR_IA32_MC0_MISC+16:
- case MSR_IA32_MC0_MISC+20:
+ if (!(mcg_cap & MCG_CTL_P))
+ return 1;
+ data = vcpu->arch.mcg_ctl;
+ break;
+ case MSR_IA32_MCG_STATUS:
+ data = vcpu->arch.mcg_status;
+ break;
+ default:
+ if (msr >= MSR_IA32_MC0_CTL &&
+ msr < MSR_IA32_MC0_CTL + 4 * bank_num) {
+ u32 offset = msr - MSR_IA32_MC0_CTL;
+ data = vcpu->arch.mce_banks[offset];
+ break;
+ }
+ return 1;
+ }
+ *pdata = data;
+ return 0;
+}
+
+int kvm_get_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 *pdata)
+{
+ u64 data;
+
+ switch (msr) {
+ case 0xc0010010: /* SYSCFG */
+ case 0xc0010015: /* HWCR */
+ case MSR_IA32_PLATFORM_ID:
case MSR_IA32_UCODE_REV:
case MSR_IA32_EBL_CR_POWERON:
case M
Re: The compiling of lastest KVM user space code FAIL on the lastest kernel tree
HI, avi,
The issue is resolved successfully. Thanks for your direction.
Cheers,
Zhiyong Wu
On Tue, Apr 7, 2009 at 6:47 PM, Avi Kivity wrote:
> Zhiyong Wu wrote:
>>
>> HI,
>>
>> when compiling kvm user space on the lastest kernel tree,
>>
>> the compile FAIL; but on 2.6.29, this compile has succeeded.
>>
>> The version of the lastest kernel tree is
>>
>> [r...@fedora9 linux-2.6 {master}]$ git describe
>> v2.6.29-9854-gd508afb
>>
>> [r...@fedora9 kvm-userspace {master}]$ make
>> ...
>> rm -f include/asm include-compat/asm
>> ln -sf asm-x86 include/asm
>> ln -sf asm-x86 include-compat/asm
>> make -C /home/zwu/kernel/linux-2.6/ M=`pwd` \
>> LINUXINCLUDE="-I`pwd`/include -Iinclude \
>> \
>> -Iarch/x86/include -I`pwd`/include-compat \
>> -include include/linux/autoconf.h \
>> -include `pwd`/x86/external-module-compat.h "
>> make[2]: Entering directory `/home/zwu/kernel/linux-2.6'
>> CC [M] /home/zwu/virt/kvm-userspace/kernel/x86/svm.o
>> In file included from /home/zwu/virt/kvm-userspace/kernel/x86/svm.c:57:
>> /home/zwu/virt/kvm-userspace/kernel/include/linux/kvm_host.h:191:
>> error: field \u2018mmu_notifier\u2019 has incomplete type
>> make[4]: *** [/home/zwu/virt/kvm-userspace/kernel/x86/svm.o] Error 1
>> make[3]: *** [/home/zwu/virt/kvm-userspace/kernel/x86] Error 2
>> make[2]: *** [_module_/home/zwu/virt/kvm-userspace/kernel] Error 2
>> make[2]: Leaving directory `/home/zwu/kernel/linux-2.6'
>> make[1]: *** [all] Error 2
>> make[1]: Leaving directory `/home/zwu/virt/kvm-userspace/kernel'
>> make: *** [kernel] Error 2
>>
>> It seems that the macro "CONFIG_MMU_NOTIFIER" is undefined in the
>> lastest kernel tree.
>>
>
> You need to select CONFIG_KVM in your .config; that will enable
> CONFIG_MMU_NOTIFIER.
>
>
> --
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: strange guest slowness after some time
On Tuesday 07 April 2009 00:49:17 Tomasz Chmielewski wrote: > Tomasz Chmielewski schrieb: > > > As I mentioned, it was using virtio net. > > > > Guests running with e1000 (and virtio_blk) don't have this problem. > > Also, virtio_console seem to be affected by this "slowness" issue. I'm pretty sure this is different. Older virtio_console code ignored interrupts and polled, and use a heuristic to back off on polling (this was because we used the generic "hvc" infrastructure which hacked support). You'll find a delay on the first keystroke after idle, but none on the second. Hope that helps, Rusty. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/3] kvm: convert spin-locks to raw_spinlock_t
This patch converts some KVM spin-locks to be of type raw_spinlock_t.
Signed-off-by: Jan Blunck
---
arch/x86/kvm/i8254.h |2 +-
arch/x86/kvm/irq.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: b/arch/x86/kvm/i8254.h
===
--- a/arch/x86/kvm/i8254.h
+++ b/arch/x86/kvm/i8254.h
@@ -33,7 +33,7 @@ struct kvm_kpit_state {
u32speaker_data_on;
struct mutex lock;
struct kvm_pit *pit;
- spinlock_t inject_lock;
+ raw_spinlock_t inject_lock;
unsigned long irq_ack;
struct kvm_irq_ack_notifier irq_ack_notifier;
};
Index: b/arch/x86/kvm/irq.h
===
--- a/arch/x86/kvm/irq.h
+++ b/arch/x86/kvm/irq.h
@@ -60,7 +60,7 @@ struct kvm_kpic_state {
};
struct kvm_pic {
- spinlock_t lock;
+ raw_spinlock_t lock;
bool wakeup_needed;
unsigned pending_acks;
struct kvm *kvm;
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 0/3] Patches for KVM & RT
Here are some patches that are necessary to get KVM running with the -rt4 patchset. Cheers, Jan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 3/3] kvm: wake up waitqueue before calling get_cpu()
This moves the get_cpu() call down to be called after we wake up the
waiters. Therefore the waitqueue locks can savely be rt mutex.
Signed-off-by: Jan Blunck
Signed-off-by: Sven-Thorsten Dietrich
---
arch/x86/kvm/x86.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index: b/arch/x86/kvm/x86.c
===
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4229,7 +4229,7 @@ static void vcpu_kick_intr(void *info)
void kvm_vcpu_kick(struct kvm_vcpu *vcpu)
{
int ipi_pcpu = vcpu->cpu;
- int cpu = get_cpu();
+ int cpu;
if (waitqueue_active(&vcpu->wq)) {
wake_up_interruptible(&vcpu->wq);
@@ -4239,6 +4239,7 @@ void kvm_vcpu_kick(struct kvm_vcpu *vcpu
* We may be called synchronously with irqs disabled in guest mode,
* So need not to call smp_call_function_single() in that case.
*/
+ cpu = get_cpu();
if (vcpu->guest_mode && vcpu->cpu != cpu)
smp_call_function_single(ipi_pcpu, vcpu_kick_intr, vcpu, 0);
put_cpu();
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/3] Make rt_down_read_trylock() behave like down_read_trylock()
This patch removes the stupid "Read locks within the self-held write lock
succeed" behaviour. This is breaking in mm_take_all_locks() since it is quite
common to ensure that a lock is taken with
BUG_ON(down_read_trylock(&mm->mmap_sem)).
Signed-off-by: Jan Blunck
---
kernel/rt.c | 12
1 file changed, 12 deletions(-)
Index: b/kernel/rt.c
===
--- a/kernel/rt.c
+++ b/kernel/rt.c
@@ -381,18 +381,6 @@ int rt_down_read_trylock(struct rw_sema
unsigned long flags;
int ret;
- /*
-* Read locks within the self-held write lock succeed.
-*/
- spin_lock_irqsave(&rwsem->lock.wait_lock, flags);
- if (rt_mutex_real_owner(&rwsem->lock) == current) {
- spin_unlock_irqrestore(&rwsem->lock.wait_lock, flags);
- rwsem_acquire_read(&rwsem->dep_map, 0, 1, _RET_IP_);
- rwsem->read_depth++;
- return 1;
- }
- spin_unlock_irqrestore(&rwsem->lock.wait_lock, flags);
-
ret = rt_mutex_trylock(&rwsem->lock);
if (ret)
rwsem_acquire(&rwsem->dep_map, 0, 1, _RET_IP_);
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Differences in emulation between kvm and kvm -no-kvm
On Tuesday, 7. april 2009 at 21:59 +0200, Milan Plzik wrote: > Hello, > > I somehow managed to produce code which behaves slightly differently > when using software emulation and when using kvm. As fas as I know, the > bug should be related to reading cursor position from VGA registers. > > Basically, the bug should be reproducible by executing: > > #define VGA_CURSOR_LOC_HIGH 0xe > #define VGA_CURSOR_LOC_LOW 0xf > > priv.addr = 0x3d4; > priv.data = 0x3d5; > > outb (priv.addr, VGA_CURSOR_LOC_HIGH); /* Cursor location high */ > priv.cursor = inb (priv.data) << 8; > > outb (priv.addr, VGA_CURSOR_LOC_LOW); /* Cursor location low */ > priv.cursor += inb (priv.data); This is wrong; looks like the problem was in the end in improperly set %esp register. Anyway, the problem is still the same -- kvm without -no-kvm properly handled stack operations which shouldn't be possible... . But sorry for sending incomplete info > > I put a testcase at > http://stashbox.org/manage_file/480477/kvm-bug.tar.gz . It's my school > project, so it's a bit more complicated; if neccessary, I can supply the > sources. In kvm -no-kvm it should cause reboot, in plain kvm it should > print few colored 'A's into the left upper corner of the screen (rest of > the code in binary is unreachable). It uses a bit more complicated setup > -- pxegrub2 and tftp loading, but that should not matter -- run.sh > should execute kvm with proper arguments, when executed from the kvm-bug > directory. > > Best regards, > Milan > > P.S: Please Cc: me as I'm not subscribed to the list; when possible, > I'll be also idling at #kvm (nickname 'mmp'). -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string
On Tuesday 07 April 2009, Daniel Jacobowitz wrote: > On Tue, Apr 07, 2009 at 08:52:46AM -0500, Anthony Liguori wrote: > > I think that's going to lead to even more confusion. While I'm inclined > > to not greatly mind 0.10.99 for the development tree, when we do release > > candidates for the next release, it's going to be 0.11.0-rc1. I don't > > expect RPMs to ever be created from non-release versions of QEMU provided > > we stick to our plan of frequent releases. > > FWIW, GDB uses 6.8.50 (devel branch), 6.8.90 (release branch), 6.8.91 > (rc1). That's worked out well for us. I like this one. I'm extremely sceptical of anything that claims to need a fine grained version number. In practice version numbers for open source projects are fairly arbitrary and meaningless because almost everyone has their own set of patches and backported fixes anyway. Paul -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] boot=on option is missing in qemu-options.hx. Libvirt needs this information.
Libvirt parses qemu-kvm -help output for boot=on. Without this it's not
possible to boot from a virtio block device.
--- kvm-85rc3/qemu/qemu-options.hx.org
+++ kvm-85rc3/qemu/qemu-options.hx
@@ -77,6 +77,7 @@
"-drive [file=file][,if=type][,bus=n][,unit=m][,media=d][,index=i]\n"
" [,cyls=c,heads=h,secs=s[,trans=t]][,snapshot=on|off]\n"
" [,cache=writethrough|writeback|none][,format=f][,serial=s]\n"
+" [,boot=on|off]\n"
"use 'file' as a drive image\n")
STEXI
@item -drive @var{option}[,@var{option}[,@var{option}[,...]]]
@@ -111,6 +112,9 @@
an untrusted format header.
@item seri...@var{serial}
This option specifies the serial number to assign to the device.
+...@item bo...@var{boot}
+...@var{boot} if "on" enables extboot for a given drive so it can be used
+as a boot drive.
@end table
By default, writethrough caching is used for all block device. This means that
@@ -163,6 +167,11 @@
qemu -drive file=file,if=scsi,bus=0,unit=6
@end example
+To boot from as SCSI disk, one would use:
+...@example
+qemu -drive file=file,if=scsi,boot=on
+...@end example
+
Instead of @option{-fda}, @option{-fdb}, you can use:
@example
qemu -drive file=file,index=0,if=floppy
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix crash on resolution change -> screen dump -> vga redraw
Avi Kivity wrote: The vga screen dump function updates last_width and last_height, but does not change the DisplaySurface that these variables describe. A consequent vga_draw_graphic() will therefore fail to resize the surface and crash. Fix by invalidating the display state after a screen dump, forcing vga_draw_graphic() to reallocate the DisplaySurface. Signed-off-by: Avi Kivity Applied. Thanks. Regards, Anthony Liguori --- hw/vga.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/vga.c b/hw/vga.c index b1e4373..4d1049b 100644 --- a/hw/vga.c +++ b/hw/vga.c @@ -2678,4 +2678,5 @@ static void vga_screen_dump(void *opaque, const char *filename) vga_screen_dump_graphic(s, filename); else vga_screen_dump_text(s, filename); +vga_invalidate_display(s); } -- Regards, Anthony Liguori -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ kvm-Bugs-2741742 ] debian-20090117-kfreebsd-i386 installation fails on kvm > 80
Bugs item #2741742, was opened at 2009-04-07 22:37 Message generated for change (Tracker Item Submitted) made by scoof You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2741742&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: Andreas Jacobsen (scoof) Assigned to: Nobody/Anonymous (nobody) Summary: debian-20090117-kfreebsd-i386 installation fails on kvm > 80 Initial Comment: Machine: Thinkpad T60 with Intel T2400, running 32 bit Debian Linux trillian 2.6.26-1-686 #1 SMP Sat Jan 10 18:29:31 UTC 2009 i686 GNU/Linux ii linux-image-2.6.26-1-686 2.6.26-13 Linux 2.6.26 image on PPro/Celeron/PII/PIII/P4 KVM command-line: kvm -m 1024 -name kfreebsd-debian -hda debian-kfreebsd.img -hdb debian-kfreebsd-swap.img -cdrom debian-20090117-kfreebsd-i386-install.iso -boot d -net nic,macaddr=00:16:3e:49:01:33,vlan=0 -net tap debian-kfreebsd.img is an 8G qcow2 image, debian-kfreebsd-swap.img is a 1G qcow2 image. debian-20090117-kfreebsd-i386-install.iso is available from http://glibc-bsd.alioth.debian.org/install-cd/kfreebsd-i386/20090117/debian-20090117-kfreebsd-i386-install.iso Steps to reproduce: Boot KVM > 80 Select Express Select ad0 Press a, q Select BootMgr Select ad1 Press a, q Select BootMgr Press tab, enter Press c, enter, enter, /, enter Select ad1 Press c, enter, s, enter Press q Select Minimal Select Exit Select CD/DVD Select cd0 Select Yes Press Alt-F3 to select Select Europe Select Copenhagen Installation should now fail Installation fails with kvm > 80 Installation succeeds with qemu without kqemu Installation succeeds with kvm-80 Installation fails with kvm-83 and -no-kvm Installation fails with kvm-83 and -no-kvm-pit Sometimes, it fails with a "duplicate alloc" or "duplicate dealloc" error message -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=893831&aid=2741742&group_id=180599 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Differences in emulation between kvm and kvm -no-kvm
Hello, I somehow managed to produce code which behaves slightly differently when using software emulation and when using kvm. As fas as I know, the bug should be related to reading cursor position from VGA registers. Basically, the bug should be reproducible by executing: #define VGA_CURSOR_LOC_HIGH 0xe #define VGA_CURSOR_LOC_LOW 0xf priv.addr = 0x3d4; priv.data = 0x3d5; outb (priv.addr, VGA_CURSOR_LOC_HIGH); /* Cursor location high */ priv.cursor = inb (priv.data) << 8; outb (priv.addr, VGA_CURSOR_LOC_LOW); /* Cursor location low */ priv.cursor += inb (priv.data); I put a testcase at http://stashbox.org/manage_file/480477/kvm-bug.tar.gz . It's my school project, so it's a bit more complicated; if neccessary, I can supply the sources. In kvm -no-kvm it should cause reboot, in plain kvm it should print few colored 'A's into the left upper corner of the screen (rest of the code in binary is unreachable). It uses a bit more complicated setup -- pxegrub2 and tftp loading, but that should not matter -- run.sh should execute kvm with proper arguments, when executed from the kvm-bug directory. Best regards, Milan P.S: Please Cc: me as I'm not subscribed to the list; when possible, I'll be also idling at #kvm (nickname 'mmp'). -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kvm] Re: [PATCH 1/2] qemu: Allow SMBIOS entries to be loaded and provided to the VM BIOS
Alex Williamson wrote:
On Mon, 2009-04-06 at 17:42 -0500, Anthony Liguori wrote:
That helps, but we have the same complexity in getting the data into the
the bios. Adding a new QEMU_CFG_* for each field in every table we want
to specify seems excessive.
Right.
I'm half tempted to generate all the smbios
entries in qemu and push them through a port to the bios. That would
leave a lot of duplicate code in bochs though. Maybe the bios could
read a stream of these through the port:
uint16_t length;
uint8_t type; /* 0: field, 1: table */
union {
struct {
uint8_t type; /* smbios entry type */
uint8_t offset;
uint8_t data[];
} field;
struct {
uint8_t data[]; /* binary blob */
} table;
} entry;
We could convert uuid to use this too.
Yes, this is what I was leaning toward too.
The bios doesn't have a very
effective means to seek through these, but maybe its not an issue as
long as these entries are sparsely used. We could also use the table
generation to enforce mutual exclusion between specifying fields and
tables to avoid the uuid issue in the previous set. Other ideas?
I'm pretty happy with this. The argument against it is that if we pass
higher level information down via the FW interface, other types of FW
(like OpenBIOS) could also use that information in a meaningful way.
The problem is, beyond things like UUID, you start to get into pretty
specific stuff and I'm not convinced it would all generalize very well.
OEM tables are also impossible to represent this way.
So yeah, plumbing the tables directly through to the BIOS seems to make
sense to me.
Thanks,
Alex
--
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kvm] Re: [PATCH 1/2] qemu: Allow SMBIOS entries to be loaded and provided to the VM BIOS
On Mon, 2009-04-06 at 17:42 -0500, Anthony Liguori wrote:
> Alex Williamson wrote:
> > Hi Anthony,
> >
> > On Mon, 2009-04-06 at 14:50 -0500, Anthony Liguori wrote:
> >
> >> Alex Williamson wrote:
> >>
> >> I know we have to support blobs because of OEM specific smbios entries,
> >> but there are a number of common ones that it would probably be good to
> >> specify in a less user-unfriendly way. What do you think?
> >>
> >
> > Yeah, I'll admit this is a pretty unfriendly interface. I get from your
> > comment on the other part of the patch that you'd prefer not to get into
> > the mess of having both binary blobs and command line switches
> > augmenting the blobs. This seems reasonable, but also means that we
> > need a way to fully define the tables we generate from the command line.
> > For a type 0 entry, that might mean the following set of switches:
> >
> > -bios-version, -bios-date, -bios-characteristics, -bios-release
> >
>
> You could go one level higher:
>
> -smbios type=0,bios-version='1.0',bios-date='2009/10/20' etc.
That helps, but we have the same complexity in getting the data into the
the bios. Adding a new QEMU_CFG_* for each field in every table we want
to specify seems excessive. I'm half tempted to generate all the smbios
entries in qemu and push them through a port to the bios. That would
leave a lot of duplicate code in bochs though. Maybe the bios could
read a stream of these through the port:
uint16_t length;
uint8_t type; /* 0: field, 1: table */
union {
struct {
uint8_t type; /* smbios entry type */
uint8_t offset;
uint8_t data[];
} field;
struct {
uint8_t data[]; /* binary blob */
} table;
} entry;
We could convert uuid to use this too. The bios doesn't have a very
effective means to seek through these, but maybe its not an issue as
long as these entries are sparsely used. We could also use the table
generation to enforce mutual exclusion between specifying fields and
tables to avoid the uuid issue in the previous set. Other ideas?
Thanks,
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] The included file "stropts.h" does not exist in the source tree, so this line should be deleted.
Signed-off-by: Zhiyong Wu --- libkvm/libkvm-x86.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/libkvm/libkvm-x86.c b/libkvm/libkvm-x86.c index dcef548..2fc4fce 100644 --- a/libkvm/libkvm-x86.c +++ b/libkvm/libkvm-x86.c @@ -4,7 +4,6 @@ #include #include #include -#include #include #include #include -- 1.6.2.2.446.gfbdc0 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string
On Tue, Apr 07, 2009 at 08:52:46AM -0500, Anthony Liguori wrote: > I think that's going to lead to even more confusion. While I'm inclined > to not greatly mind 0.10.99 for the development tree, when we do release > candidates for the next release, it's going to be 0.11.0-rc1. I don't > expect RPMs to ever be created from non-release versions of QEMU provided > we stick to our plan of frequent releases. FWIW, GDB uses 6.8.50 (devel branch), 6.8.90 (release branch), 6.8.91 (rc1). That's worked out well for us. -- Daniel Jacobowitz CodeSourcery -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cancel the warning in msr.c
From: zwu
Signed-off-by: zwu
---
user/test/x86/msr.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/user/test/x86/msr.c b/user/test/x86/msr.c
index 5010ad0..92102fa 100644
--- a/user/test/x86/msr.c
+++ b/user/test/x86/msr.c
@@ -6,6 +6,7 @@
int nr_passed, nr_tests;
+#ifdef __x86_64__
static void report(const char *name, int passed)
{
++nr_tests;
@@ -27,6 +28,7 @@ static unsigned long long rdmsr(unsigned index)
return value;
}
+#endif
static void test_kernel_gs_base(void)
{
--
1.5.4.5
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AW: AW: KVM performance
BRAUN, Stefanie wrote: 1. Subtest: VLC reads video from local disk and streams it via udp to another pc Host performance: 11% 11% kvm process in host (top): 22% 22% vlc process in vmu (top): 15% 7% While this isn't wonderful, it's not your major bottleneck now. What's the bandwidth generated by the workload? 4. Subtest: Reading video locally, adding a logo to the video stream and then saving the video locally Host performance: 50% 50% kvm process in host (top) : 99% 99% vlc process in vmu (top) : 99% 99% Now this is bad. Please provide the output of 'kvm_stat -1' while this is running. Also, describe the guest. Is it Linux? if so, i386 or x86_64? and is CONFIG_HIGHMEM enabled? UDP performance is a known issue now, and we are working on it. TCP is much better due to segmentation offload. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Make kvm header compile under g++.
> Excellent. One of the things I'm trying hard to do is keep kvm from being a > 'qemu accelerator' and generally useful for other projects. That is, I'm > trying to keep the userspace interface neutral, and not to model exactly the > hardware qemu provides but allow for other configurations. > > One example where we failed to do this is in mapping interrupts, where PIC > IRQ line n was tied to IOAPIC INTI line n. This came back to bite us when > qemu changed its model. > > So if you notice such issues in kvm please bring them up so we can fix them. I certainly will, and I have noticed such things already. They're mostly problems for me in libkvm at this point. I haven't noticed any big problems with KVM itself yet. I'm going back and forth as to whether or not I want to use libkvm at all, though if you're receptive to changes to that interface, I'll definitely keep that in mind. On the other hand, since I'm using C++, I may just write a C++ libkvm and try to give it to you guys. I will try to work with the existing libkvm for now though. > If you're interested in determinism, can't you just warm up the system once > and then save the state? We often do stuff like that. We drop checkpoints and run from the checkpoints, but the problem with that is that we often change things in such a way that you need to boot fresh again. If we change a device model or the kernel there's no getting around it. There are more subtle things though. For example, if you warm up a simulation with a simulated Gigabit ethernet and then decide that you really wanted 10 Gig, you can't just change it when you resume the checkpoint because TCP takes a while to warm up. We could of course warm up further from the checkpoint, but if you were to go in the reverse direction 10G -> 1G, TCP starts dropping packets and it takes a long time in a simulator to deal with that. If I can impose a good enough notion of time, I can deal with those things. Determinism is another issue altogether. Our simulator is deterministic, and we'd love to keep that property, but that's even more difficult, unless we can figure out a way to tell KVM to do something like "execute up to 100 instructions right now". I'm pretty far from really worrying about these problems. I do have lots of ideas and I know that there are a bunch of papers out there that work on this sort of thing. Thanks again, Nate -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kvm crash when I create a Guest
On Tue, Apr 7, 2009 at 2:15 AM, Alessio Rocchi wrote: > I'm Running Ubuntu 8.10, here is the command I use: > kvm -net none -m 192 -no-acpi -hda ./gentoo_cleanvm.img.tar.lzma Ubuntu 8.10 uses kvm-72 by default. You might, perhaps, try kvm-84, which is more current and fixes a number of issues. You can try the pre-built packages available for Ubuntu 8.10 at: * https://launchpad.net/~ubuntu-virt/+archive/ppa You should install both the kvm and the kvm-source package, which would get you kvm-84 userspace and the kernel module. :-Dustin -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string
Anthony Liguori wrote: > I still think libvirt should work with versions of QEMU/KVM built from > svn/git though. I think the only way to do that is for libvirt to relax > their version checks to accommodate suffixes in the form > major.minor.stable-foo. Ok, but try to stick to a well-defined rule about what suffix means "later" or "earlier". In package managers, "1.2.3-rc1" is typically seen as a later version than "1.2.3" purely due to syntax. If you're consistently meaning "0.11.0-rc1" is earlier than "0.11.0" (final), that might need to be encoded in libvirt and other wrappers, if they have any fine-grained version sensistivity such as command line changes or bug workarounds. The Linux kernel was guilty of mixing up later and earlier version suffixes like this. With Linux this is a bit more important because it changes a lot between versions, so some apps do need fine-grained version checks to workaround bugs or avoid buggy features. Maybe that won't even happen with QEMU and libvirt working together. -- Jamie -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Make kvm header compile under g++.
nathan binkert wrote: btw, can you share what you're doing with kvm and g++? I am a researcher at HP Labs studying system architecture. For many years, I have been involved in a simulator project called M5 (m5sim.org). It shares a lot of things in common with qemu/kvm, except instead of performance as our number one goal, measurement is our number one goal. We model many aspects of computer systems in detail trying to understand how to build future systems. We support a number of architectures and are right now trying to finish x86 support. We want M5 to be able to do everything x86 by itself, but I was looking into the feasibility of using KVM as a fast "CPU" model to help us get workloads running at an interesting point quickly at which point we can switch over to a more detailed CPU model. Since M5 does all of the modeling of memory, devices, and interrupts itself, this really would use just the KVM bits and not use QEMU. We can also use KVM in a single stepping mode to validate the correctness of the simulator itself. Excellent. One of the things I'm trying hard to do is keep kvm from being a 'qemu accelerator' and generally useful for other projects. That is, I'm trying to keep the userspace interface neutral, and not to model exactly the hardware qemu provides but allow for other configurations. One example where we failed to do this is in mapping interrupts, where PIC IRQ line n was tied to IOAPIC INTI line n. This came back to bite us when qemu changed its model. So if you notice such issues in kvm please bring them up so we can fix them. My initial playing around with the code looks pretty promising. The only big question mark I have is how to deal with time. I really need the simulator to control what the VCPU understands as the passage of time (think about exactly when interrupts arrive, or exactly how VCPUs advance with respect to each other when they're communicating through shared memory). This has to be done to properly warm up the system. I'm not concerned about whether I can do it at all. I just want to make sure that I maintain the speed of KVM while I do it. If you're interested in determinism, can't you just warm up the system once and then save the state? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: AW: KVM performance
Hello, I think that I've mixed the values in my first email for this topic and actually provided the values without network virtio enabled. So the values for a kvm vmu with enabled virtio are indeed a little better but not as good as Xen. At the moment I'm still working to get the virtio disk vmu setup working as I think it would be interesting how the performance values would improve. All following tests have been executed using a vmu (ram 512 mb, 1 core 2,2 GHz) and the vlc (video player, that can f.e. stream, receive, transcode videos) VMU setup for first performance values (without network virtio) /usr/bin/qemu-kvm -boot c -hda /images/vmu01.raw -m 512 -net nic,vlan=0,macaddr=aa:bb:cc:dd:ee:10 -net tap,ifname=tap0,vlan=0,script=/etc/kvm/qemu-ifup,downscript=/etc/kvm/qemu-ifdown -net nic,vlan=1,macaddr=aa:bb:cc:dd:ee:11 -net tap,ifname=tap1,vlan=1,script=/etc/kvm/qemu-ifup,downscript=/etc/kvm/qemu-ifdown -vnc 127.0.0.1:2 -k de --daemonize VMU setup for second performance values (with network virtio) /usr/bin/qemu-kvm -boot c -hda /images/vmu01.raw -m 512 -net nic,vlan=0,macaddr=aa:bb:cc:dd:ee:10,model=virtio -net tap,ifname=tap0,vlan=0,script=/etc/kvm/qemu-ifup,downscript=/etc/kvm/qemu-ifdown -net nic,vlan=1,macaddr=aa:bb:cc:dd:ee:11,model=virtio -net tap,ifname=tap1,vlan=1,script=/etc/kvm/qemu-ifup,downscript=/etc/kvm/qemu-ifdown -vnc 127.0.0.1:2 -k de --daemonize The first column of performance values show the VMU without virtio network, the second column with virtio network 1. Subtest: VLC reads video from local disk and streams it via udp to another pc Host performance: 11% 11% kvm process in host (top): 22% 22% vlc process in vmu (top): 15% 7% 2. Subtest: Just receiving a video via udp (no displaying as no X11 is installed on the vmu) Host performance: 16% 10% kvm process in host (top) : 30% 17% vlc process in vmu (top) : 3% 3% 3. Subtest: Receiving a video via udp and saving it locally in a file Host performance: 17% 11% kvm process in host (top) : 38% 24% vlc process in vmu (top) : 12% 11% 4. Subtest: Reading video locally, adding a logo to the video stream and then saving the video locally Host performance: 50% 50% kvm process in host (top) : 99% 99% vlc process in vmu (top) : 99% 99% 5. Subtest: Receiving the video from pc 1 and at the same time streaming the received video to pc 2 Host performance: 23% 18% kvm process in host (top) : 22% 35% vlc process in vmu (top) : 48% 10% 6. The originial test: receiving streamed video, adding a logo and the sending it to another pc Host performance: 52% 50% kvm process in host (top) : 77-99% 60-99% (for both most time 99%) vlc process in vmu (top) : 80-99% 50-99% (for both most time 99%) I've have repeated almost all tests with XEN 1. Subtest: VLC reads video from local disk and streams it via udp to another pc Host performance (Domain-0 + vmu)(virt-manager):4% VMU (virt-manager) : 2% vlc process in vmu (top) : 1% 3. Subtest: Receiving a video via udp and saving it locally in a file Host performance (Domain-0 + vmu)(virt-manager):7% VMU (virt-manager) : 4% vlc process in vmu (top) : 3% 4. Subtest: Reading video locally, adding a logo to the video stream and then saving the video locally Host performance (Domain-0 + vmu)(virt-manager):3-55% VMU (virt-manager) : 0-50% vlc process in vmu (top) : 14 -99% varies a lot 5. Subtest: Receiving the video from pc 1 and at the same time streaming the received video to pc 2 Host performance (Domain-0 + vmu)(virt-manager):6% VMU (virt-manager) : 3% vlc process in vmu (top) : 1% 6. The originial test: receiving streamed video, adding a logo and the sending it to another pc Host performance (Domain-0 + vmu)(virt-manager):23% VMU (virt-manager) :
Re: [PATCH] KVM: Make kvm header compile under g++.
> No, I just missed your patch. Applied now. Thanks for pestering, it's the > right thing when I miss something (copying me also helps). Thanks. > btw, can you share what you're doing with kvm and g++? I am a researcher at HP Labs studying system architecture. For many years, I have been involved in a simulator project called M5 (m5sim.org). It shares a lot of things in common with qemu/kvm, except instead of performance as our number one goal, measurement is our number one goal. We model many aspects of computer systems in detail trying to understand how to build future systems. We support a number of architectures and are right now trying to finish x86 support. We want M5 to be able to do everything x86 by itself, but I was looking into the feasibility of using KVM as a fast "CPU" model to help us get workloads running at an interesting point quickly at which point we can switch over to a more detailed CPU model. Since M5 does all of the modeling of memory, devices, and interrupts itself, this really would use just the KVM bits and not use QEMU. We can also use KVM in a single stepping mode to validate the correctness of the simulator itself. My initial playing around with the code looks pretty promising. The only big question mark I have is how to deal with time. I really need the simulator to control what the VCPU understands as the passage of time (think about exactly when interrupts arrive, or exactly how VCPUs advance with respect to each other when they're communicating through shared memory). This has to be done to properly warm up the system. I'm not concerned about whether I can do it at all. I just want to make sure that I maintain the speed of KVM while I do it. Anyway, thanks for your hard work! Nate -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [kvm] [PATCH 13/16] kvm: enable MSI-X capabilty for assigned device
On Tue, 2009-04-07 at 14:09 +0800, Sheng Yang wrote: > On Saturday 04 April 2009 05:27:43 Alex Williamson wrote: > > > > Do we need some disable logic here? If I toggle a bnx2 NIC in a guest, > > I get the following when it attempts to come back up: > > > > MSI-X entry number is zero! > > assigned_dev_update_msix_mmio: No such device or address > > It seems that driver didn't fill the MMIO with any correct MSIX information, > or the program fail to intercept it after driver set enable bit of MSIX. It's > strange... (Have it got something to do with PM and some EXP feature you > mentioned?) My guess was that it filled in the MSIX info, but then can't find a free slot to reload the MSIX data when it tries to re-enable MSIX. I hacked the bnx2 driver to not rely on PM and EXP capabilities for this test, it seems to work, but it's possible that I broke something. My host also locks up the second time I try to export this device to a guest, maybe a problem with my bnx2 hacks, MSIX not getting reset, or prototype hardware. I'll see if I can find another MSIX capable device to export to a guest. > Could you enable DEVICE_ASSSIGNMENT_DEBUG=1 in qemu/hw/device-assignment.c > and > post the output? Yup, see below. The error comes after I 'ifdown eth0; ifup eth0' in the guest. Note bnx2 appears to only turn on MSIX for SMP systems. Thanks, Alex $ sudo qemu-system-x86_64 -hda kvm-vtd.img -m 4096 -net none -vnc :1 -pcidevice host=03:00.0 -boot c -smp 8 init_assigned_device: Registering real physical device 03:00.0 (bus=3 dev=0 func=0) get_real_device: region 0 size 33554432 start 0xf400 type 512 resource_fd 19 assigned_dev_pci_read_config: (4.0): address= val=0x14e4 len=2 assigned_dev_pci_read_config: (4.0): address=0002 val=0x1639 len=2 assigned_dev_pci_read_config: (4.0): address= val=0x14e4 len=2 assigned_dev_pci_read_config: (4.0): address=0002 val=0x1639 len=2 assigned_dev_pci_read_config: (4.0): address= val=0x14e4 len=2 assigned_dev_pci_read_config: (4.0): address=0002 val=0x1639 len=2 assigned_dev_pci_read_config: (4.0): address=000a val=0x0200 len=2 assigned_dev_pci_read_config: (4.0): address= val=0x14e4 len=2 assigned_dev_pci_read_config: (4.0): address=0002 val=0x1639 len=2 assigned_dev_pci_write_config: (4.0): address=0010 val=0x len=4 assigned_dev_pci_read_config: (4.0): address=0010 val=0xfe00 len=4 assigned_dev_pci_read_config: (4.0): address=0010 val=0xfe00 len=4 assigned_dev_pci_write_config: (4.0): address=0010 val=0xf400 len=4 assigned_dev_iomem_map: e_phys=f400 r_virt=0x7f14f4ba type=0 len=0200 region_num=0 assigned_dev_iomem_map: munmap done, virt_base 0x0x7f14f4bac000 assigned_dev_pci_read_config: (4.0): address=0004 val=0x0442 len=2 assigned_dev_pci_write_config: (4.0): address=0004 val=0x0442 len=2 assigned_dev_pci_write_config: NON BAR (4.0): address=0004 val=0x0442 len=2 assigned_dev_pci_write_config: (4.0): address=0014 val=0x len=4 assigned_dev_pci_read_config: (4.0): address=0014 val=0x len=4 assigned_dev_pci_write_config: (4.0): address=0018 val=0x len=4 assigned_dev_pci_read_config: (4.0): address=0018 val=0x len=4 assigned_dev_pci_write_config: (4.0): address=001c val=0x len=4 assigned_dev_pci_read_config: (4.0): address=001c val=0x len=4 assigned_dev_pci_write_config: (4.0): address=0020 val=0x len=4 assigned_dev_pci_read_config: (4.0): address=0020 val=0x len=4 assigned_dev_pci_write_config: (4.0): address=0024 val=0x len=4 assigned_dev_pci_read_config: (4.0): address=0024 val=0x len=4 assigned_dev_pci_write_config: (4.0): address=0030 val=0x len=4 assigned_dev_pci_write_config: NON BAR (4.0): address=0030 val=0x len=4 assigned_dev_pci_read_config: (4.0): address=0030 val=0x0001 len=4 assigned_dev_pci_read_config: (4.0): address=0030 val=0x0001 len=4 assigned_dev_pci_write_config: (4.0): address=0030 val=0x0001 len=4 assigned_dev_pci_write_config: NON BAR (4.0): address=0030 val=0x0001 len=4 assigned_dev_pci_read_config: (4.0): address=0004 val=0x0442 len=2 assigned_dev_pci_write_config: (4.0): address=0004 val=0x0442 len=2 assigned_dev_pci_write_config: NON BAR (4.0): address=0004 val=0x0442 len=2 assigned_dev_pci_read_config: (4.0): address=003d val=0x0001 len=1 assigned_dev_pci_write_config: (4.0): address=003c val=0x000b len=1 assigned_dev_pci_read_config: (4.0): address=000a val=0x0200 len=2 assigned_dev_pci_read_config: (4.0): address= val=0x14e4 len=2 assigned_dev_pci_read_config: (4.0): address=0002 val=0x1639 len=2 assigned_dev_pci_read_config: (4.0): address=000e val=0x0080 len=1 assigned_dev_pci_read_config: (4.0): address= val=0x163914e4 len=4 assigned_dev_pci_read_config: (4.0): address=000e val=0x0080 len=1 assigned_dev_pci_read_config: (4.0): address=0006 val=0x0010 len=2 assigned_dev_pci_r
Re: [RFC PATCH] PCI pass-through fixups
* Alex Williamson (alex.william...@hp.com) wrote: > On Tue, 2009-04-07 at 07:54 -0700, Chris Wright wrote: > > * Sheng Yang (sh...@linux.intel.com) wrote: > > > On Tuesday 07 April 2009 08:02:10 Chris Wright wrote: > > > > * Alex Williamson (alex.william...@hp.com) wrote: > > > > > I'm wondering if we need a spot for device specific fixups for PCI > > > > > pass-through. In the example below, I want to expose a single port of > > > > > an Intel 82571EB quad port copper NIC to a guest. It works great > > > > > until > > > > > I shutdown the guest, at which point the guest e1000e driver knows by > > > > > the device ID that the NIC is a quad port, and blindly attempts to > > > > > twiddle some bits on the bridge above it (that doesn't exist). > > > > > > > > And what happens? > > > > > > And the output of DEVICE_ASSIGNMENT_DEBUG=1 may help. And I don't have > > > trouble > > > here with another dual/quad port card by Intel, but not 82571EB. > > > > Right, it's driver dependent. I too can assign a single port w/out > > trouble. I'm assuming the guest just complains at rmmod? > > No, it's a little more severe than that, see below. This may be rather > unique, I certainly wasn't expecting different device IDs for a quad > port versus a single port. However, you can see in > e1000e/82571.c:e1000_get_variants_82571() we set a flag for quad port > device IDs, apparently for WOL only being supported on the first port. > Then when we shutdown, we hit e1000e/netdev.c:e1000_suspend() where we > take that quad port flag and blindly walk up to bus->self, which is > NULL, and try to get the PCI capabilities on it. That's a form of guest complaint ;-) Yes, I noticed the global wol bit, but didn't see the bus->self...ick > It may be prudent for the driver to check the pointer, but there's > probably also an argument that the device ID indicates something about > the topology that makes that unnecessary, so we may hit the same problem > in drivers we don't have source for. I agree that my rough sketch of a > patch is pretty fragile and static. Maybe an option to override a > device ID on the command line would be more flexible. Something like: > > -pcidevice host=09:00.0,device_id=0x105E > > This puts the burden on the user, but at least allows us an out. Still ugly, esp since there's no real way to know ahead of time -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] PCI pass-through fixups
On Tue, 2009-04-07 at 07:54 -0700, Chris Wright wrote: > * Sheng Yang (sh...@linux.intel.com) wrote: > > On Tuesday 07 April 2009 08:02:10 Chris Wright wrote: > > > * Alex Williamson (alex.william...@hp.com) wrote: > > > > I'm wondering if we need a spot for device specific fixups for PCI > > > > pass-through. In the example below, I want to expose a single port of > > > > an Intel 82571EB quad port copper NIC to a guest. It works great until > > > > I shutdown the guest, at which point the guest e1000e driver knows by > > > > the device ID that the NIC is a quad port, and blindly attempts to > > > > twiddle some bits on the bridge above it (that doesn't exist). > > > > > > And what happens? > > > > And the output of DEVICE_ASSIGNMENT_DEBUG=1 may help. And I don't have > > trouble > > here with another dual/quad port card by Intel, but not 82571EB. > > Right, it's driver dependent. I too can assign a single port w/out > trouble. I'm assuming the guest just complains at rmmod? No, it's a little more severe than that, see below. This may be rather unique, I certainly wasn't expecting different device IDs for a quad port versus a single port. However, you can see in e1000e/82571.c:e1000_get_variants_82571() we set a flag for quad port device IDs, apparently for WOL only being supported on the first port. Then when we shutdown, we hit e1000e/netdev.c:e1000_suspend() where we take that quad port flag and blindly walk up to bus->self, which is NULL, and try to get the PCI capabilities on it. It may be prudent for the driver to check the pointer, but there's probably also an argument that the device ID indicates something about the topology that makes that unnecessary, so we may hit the same problem in drivers we don't have source for. I agree that my rough sketch of a patch is pretty fragile and static. Maybe an option to override a device ID on the command line would be more flexible. Something like: -pcidevice host=09:00.0,device_id=0x105E This puts the burden on the user, but at least allows us an out. Thanks, Alex Sheng - BTW my copies to you bounced with "X-Postfix; Server certificate not verified" [ 26.462952] e1000e :00:04.0: PCI INT B disabled [ 26.464083] BUG: unable to handle kernel NULL pointer dereference at 002d [ 26.465694] IP: [] pci_find_capability+0x9/0x69 [ 26.466837] *pde = [ 26.467485] Oops: [#1] SMP [ 26.468046] last sysfs file: /sys/block/sda/removable [ 26.468046] Modules linked in: ipv6 loop button serio_raw parport_pc snd_pcsp virtio_balloon psmouse parport snd_pcm snd_timer i2c_piix4 i2c_core snd soundcore snd_page_alloc evdev ext3 jbd mbcache sg sr_mod cdrom sd_mod piix ide_pci_generic ide_core ata_piix floppy ata_generic e1000e virtio_pci libata scsi_mod thermal processor fan thermal_sys [ 26.468046] [ 26.468046] Pid: 2365, comm: halt Not tainted (2.6.29-net #1) [ 26.468046] EIP: 0060:[] EFLAGS: 00010286 CPU: 0 [ 26.468046] EIP is at pci_find_capability+0x9/0x69 [ 26.468046] EAX: EBX: ECX: f5c8be3c EDX: 0010 [ 26.468046] ESI: 0010 EDI: f60a3c00 EBP: ESP: f5c8be60 [ 26.468046] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 26.468046] Process halt (pid: 2365, ti=f5c8a000 task=f5e2a2c0 task.ti=f5c8a000) [ 26.468046] Stack: [ 26.468046] 00428360 f60a3c00 f5c08360 f81a2197 0002 c0270cbc [ 26.468046] f60a3c00 4321fedc 28121969 f5c8a000 c020b635 f60a1058 c02614ea [ 26.468046] c013418c c01343bd c0122c31 0021bbc7 0046 f707d900 [ 26.468046] Call Trace: [ 26.468046] [] e1000_suspend+0x1ec/0x269 [e1000e] [ 26.468046] [] cmos_suspend+0x77/0xae [ 26.468046] [] pci_device_shutdown+0x16/0x25 [ 26.468046] [] device_shutdown+0x31/0x63 [ 26.468046] [] kernel_power_off+0xa/0x2f [ 26.468046] [] sys_reboot+0xf6/0x16c [ 26.468046] [] try_to_wake_up+0x1ed/0x1f7 [ 26.468046] [] pvclock_clocksource_read+0x48/0xa7 [ 26.468046] [] __switch_to+0xcd/0x14e [ 26.468046] [] finish_task_switch+0x42/0xc7 [ 26.468046] [] schedule+0x811/0x88b [ 26.468046] [] dput+0x1a/0x108 [ 26.468046] [] mntput_no_expire+0x1a/0xfe [ 26.468046] [] filp_close+0x4e/0x54 [ 26.468046] [] sys_close+0x64/0x9f [ 26.468046] [] syscall_call+0x7/0xb [ 26.468046] Code: 44 24 1c 75 06 0f b6 04 24 eb 10 fe 04 24 8b 17 8d 42 ff 85 d2 89 07 75 ab 31 c0 5b 5e 5b 5e 5f 5d c3 56 89 d6 53 89 c3 83 ec 08 <8a> 40 2d 8d 4c 24 04 88 44 24 03 8b 53 1c 8b 43 08 51 b9 06 00 [ 26.468046] EIP: [] pci_find_capability+0x9/0x69 SS:ESP 0068:f5c8be60 [ 26.529902] ---[ end trace 69f68df891ae55cc ]--- -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] PCI pass-through fixups
* Sheng Yang (sh...@linux.intel.com) wrote: > On Tuesday 07 April 2009 08:02:10 Chris Wright wrote: > > * Alex Williamson (alex.william...@hp.com) wrote: > > > I'm wondering if we need a spot for device specific fixups for PCI > > > pass-through. In the example below, I want to expose a single port of > > > an Intel 82571EB quad port copper NIC to a guest. It works great until > > > I shutdown the guest, at which point the guest e1000e driver knows by > > > the device ID that the NIC is a quad port, and blindly attempts to > > > twiddle some bits on the bridge above it (that doesn't exist). > > > > And what happens? > > And the output of DEVICE_ASSIGNMENT_DEBUG=1 may help. And I don't have > trouble > here with another dual/quad port card by Intel, but not 82571EB. Right, it's driver dependent. I too can assign a single port w/out trouble. I'm assuming the guest just complains at rmmod? thanks, -chris -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] ksm - dynamic page sharing driver for linux v2
On Sat, Apr 04, 2009 at 05:35:18PM +0300, Izik Eidus wrote:
> From v1 to v2:
>
> 1)Fixed security issue found by Chris Wright:
> Ksm was checking if page is a shared page by running !PageAnon.
> Beacuse that Ksm scan only anonymous memory, all !PageAnons
> inside ksm data strctures are shared page, however there might
> be a case for do_wp_page() when the VM_SHARED is used where
> do_wp_page() would instead of copying the page into new anonymos
> page, would reuse the page, it was fixed by adding check for the
> dirty_bit of the virtual addresses pointing into the shared page.
> I was not finding any VM code tha would clear the dirty bit from
> this virtual address (due to the fact that we allocate the page
> using page_alloc() - kernel allocated pages), ~but i still want
> confirmation about this from the vm guys - thanks.~
As far as I can tell this wasn't a bug and this change is
unnecessary. I already checked this bit but I may have missed
something, so I ask here to be sure.
As far as I can tell when VM_SHARED is set, no anonymous page can ever
be allocated by in that vma range, hence no KSM page can ever be
generated in that vma either. MAP_SHARED|MAP_ANONYMOUS is only a
different API for /dev/shm, IPCSHM backing, no anonymous pages can
live there. It surely worked like that in older 2.6, reading latest
code it seems to still work like that, but if something has changed
Hugh will surely correct me in a jiffy ;).
I still see this in the file=null path.
} else if (vm_flags & VM_SHARED) {
error = shmem_zero_setup(vma);
if (error)
goto free_vma;
}
So you can revert your change for now.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
solaris 10 x86 regression due to timer
Marcelo, Alexey found a regression in Solaris 10 x86, I bisected it to commit 46ee278652f4cbd51013471b64c7897ba9bcd1b1 Author: Marcelo Tosatti Date: Mon Feb 23 10:57:40 2009 -0300 KVM: PIT: remove usage of count_load_time for channel 0 We can infer elapsed time from hrtimer_expires_remaining. Signed-off-by: Marcelo Tosatti Signed-off-by: Avi Kivity and indeed, the guest hangs banging on the PIT ports. Can you take a look? -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [libvirt] Re: [Qemu-devel] Changing the QEMU svn VERSION string
Daniel Veillard wrote:
On Tue, Apr 07, 2009 at 10:10:20AM +0200, Gerd Hoffmann wrote:
Hi,
I'd like to update the VERSION string in QEMU's svn tree. Right now,
it's 0.10.0 and since we have a 0.10.2 release, that's somewhat confusing.
I don't want to make it 0.11.0 either because that's not going to be
reliable from a feature detection perspective. What I would like is to
make it 0.11.0-devel or something similar to that.
Maybe 0.10.99 ? Or 0.10.90, leaving the door open to number the 0.11
beta / rc versions (if any) 0.10.9{1,2,3}?
Concur, we have no good way of representing something like 0.11.0-devel
from an rpm Name-Version-Release and be sure it won't break down the
road if we change our mind on the final naming scheme, while something
like 0.10.90 convey the intent while still being compatible with the
existing numbering scheme (plus it eventually forces you to release the
new version ;-)
I think that's going to lead to even more confusion. While I'm inclined
to not greatly mind 0.10.99 for the development tree, when we do release
candidates for the next release, it's going to be 0.11.0-rc1. I don't
expect RPMs to ever be created from non-release versions of QEMU
provided we stick to our plan of frequent releases.
I still think libvirt should work with versions of QEMU/KVM built from
svn/git though. I think the only way to do that is for libvirt to relax
their version checks to accommodate suffixes in the form
major.minor.stable-foo.
Regards,
Anthony Liguori
Daniel
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
AW: KVM performance
Hi, I'm not sure anymore if I really tested your suggested disk virtio setup yesterday, because today the vmu does not start when using the virtio setup. During boot time, the volgroup00 can not be found. At the moment I'm still searching why this error occurs. working: -drive file=/images/vmu01.raw,index=0,media=disk,boot=on not working: -drive file=/images/vmu01.raw,index=0,media=disk,boot=on,if=virtio not working: -drive file=/images/vmu01.raw,boot=on,if=virtio -Ursprüngliche Nachricht- Von: Hauke Hoffmann [mailto:kont...@hauke-hoffmann.net] Gesendet: Montag, 6. April 2009 14:13 An: kvm@vger.kernel.org Cc: BRAUN, Stefanie Betreff: Re: KVM performance On Friday 03 April 2009 13:32:50 you wrote: > Hallo, > > as I want to switch from XEN to KVM I've made some performance tests > to see if KVM is as peformant as XEN. But tests with a VMU that > receives a streamed video, adds a small logo to the video and streams > it to a client have shown that XEN performs much betten than KVM. > In XEN the vlc (videolan client used to receive, process and send the > video) process > within the vmu has a cpuload of 33,8 % whereas in KVM the vlc process > has a cpuload of 99.9 %. > I'am not sure why, does anybody now some settings to improve the KVM > performance? > > Thank you. > Regards, Stefanie. > > > Used hardware and settings: > In the tests I've used the same host hardware for XEN and KVM: > - Dual Core AMD 2.2 GHz, 8 GB RAM > - Tested OSes for KVM Host: Fedora 10, 2.6.27.5-117.fc10.x86_64 with > kvm version 10.fc10 version 74 > also tested in january: compiled kernel > with > kvm-83 > > - KVM Guest settings: OS: Fedora 9 2.6.25-14.fc9.x86_64 (i386 also > tested) > RAM: 256 MB (same for XEN vmu) > CPU: 1 Core with 2,2 GHz (same for XEN vmu) > tested nic models: rtl8139, e1000, virtio > > Tested Scenario: VMU receives a streamed video , adds a logo > (watermark) to the video stream and then streams it to a client > > Results: > > XEN: > Host cpu load (virt-manager): 23% > VMU cpu load (virt-manager): 18 % > VLC process within VMU (top): 33,8% > > KVM: > no virt-manager cpu load as I started the vmu with the kvm command > Host cpu load : 52% > qemu-kvm process (top)77-100% > VLC process within vmu (top): 80 - 99,9% > > KVM command to start vmu > /usr/bin/qemu-kvm -boot c -hda /images/vmu01.raw -m 256 -net > nic,vlan=0,macaddr=aa:bb:cc:dd:ee:10,model=virtio -net > tap,ifname=tap0,vlan=0,script=/etc/kvm/qemu-ifup,downscript=/etc/kvm/q > em u-ifdown -vnc 127.0.0.1:1 -k de --daemonize Hi Stefanie, does vlc perform operations on disc (eg caching, logging, ...)? When it cache you can use virtio also for the disk. Just change -hda /images/vmu01.raw to -drive file=/images/vmu01.raw,if=virtio,boot=on Regards Hauke > > > > > > > > Alcatel-Lucent Deutschland AG > Bell Labs Germany > Service Infrastructure, ZFZ-SI > Stefanie Braun > Phone: +49.711.821-34865 > Fax: +49.711.821-32453 > > Postal address: > Alcatel-Lucent Deutschland AG > Lorenzstrasse 10 > D-70435 STUTTGART > > Mail: stefanie.br...@alcatel-lucent.de > > > > Alcatel-Lucent Deutschland AG > Sitz der Gesellschaft: Stuttgart - Amtsgericht Stuttgart HRB 4026 > Vorsitzender des Aufsichtsrats: Michael Oppenhoff Vorstand: Alf Henryk > Wulf (Vors.), Dr. Rainer Fechner > > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in the > body of a message to majord...@vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html -- hauke hoffmann service and electronic systems Moristeig 60, D-23556 Lübeck Telefon: +49 (0) 451 8896462 Fax: +49 (0) 451 8896461 Mobil: +49 (0) 170 7580491 E-Mail: off...@hauke-hoffmann.net PGP public key: www.hauke-hoffmann.net/static/pgp/kontakt.asc -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Mapping a virtual block device on the guest
The reason I ask this question is because that I don't have any virtio-pci and virtio-blk modules loaded in my guest but still I could access the virtual block device. Thx, Venkat -Original Message- From: kvm-ow...@vger.kernel.org [mailto:kvm-ow...@vger.kernel.org] On Behalf Of Kumar, Venkat Sent: Tuesday, April 07, 2009 3:52 PM To: kvm@vger.kernel.org Subject: Mapping a virtual block device on the guest I understand that the option "-drive file=/dev/path/to/host/device,if=virtio" would map the device given in the file parameter as a virtual block device on the guest. Can somebody explain me the roles of virtio-pci and virtio-blk modules on the guest in accessing the virtual block device. I am unable to understand the design. Thx, Venkat -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: network questions on Qemu
zshan wrote: > hi all: > I am now recently using KVM which use the Qemu to perform network I/O > activities, I use the tun/tap bridging to let the guest os connect to > the Internet , and the detailed network topology is as follows: > Wow, ascii art in an image. > And I am so curious about the interaction between the tap and qemu, > how can packet been passed from tap to qemu, and what is the ingress > path in detail ? Look in qemu/net.c, qemu uses read() and write() to receive and send packets through tap. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: The compiling of lastest KVM user space code FAIL on the lastest kernel tree
Zhiyong Wu wrote:
HI,
when compiling kvm user space on the lastest kernel tree,
the compile FAIL; but on 2.6.29, this compile has succeeded.
The version of the lastest kernel tree is
[r...@fedora9 linux-2.6 {master}]$ git describe
v2.6.29-9854-gd508afb
[r...@fedora9 kvm-userspace {master}]$ make
...
rm -f include/asm include-compat/asm
ln -sf asm-x86 include/asm
ln -sf asm-x86 include-compat/asm
make -C /home/zwu/kernel/linux-2.6/ M=`pwd` \
LINUXINCLUDE="-I`pwd`/include -Iinclude \
\
-Iarch/x86/include -I`pwd`/include-compat \
-include include/linux/autoconf.h \
-include `pwd`/x86/external-module-compat.h "
make[2]: Entering directory `/home/zwu/kernel/linux-2.6'
CC [M] /home/zwu/virt/kvm-userspace/kernel/x86/svm.o
In file included from /home/zwu/virt/kvm-userspace/kernel/x86/svm.c:57:
/home/zwu/virt/kvm-userspace/kernel/include/linux/kvm_host.h:191:
error: field \u2018mmu_notifier\u2019 has incomplete type
make[4]: *** [/home/zwu/virt/kvm-userspace/kernel/x86/svm.o] Error 1
make[3]: *** [/home/zwu/virt/kvm-userspace/kernel/x86] Error 2
make[2]: *** [_module_/home/zwu/virt/kvm-userspace/kernel] Error 2
make[2]: Leaving directory `/home/zwu/kernel/linux-2.6'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/zwu/virt/kvm-userspace/kernel'
make: *** [kernel] Error 2
It seems that the macro "CONFIG_MMU_NOTIFIER" is undefined in the
lastest kernel tree.
You need to select CONFIG_KVM in your .config; that will enable
CONFIG_MMU_NOTIFIER.
--
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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fix the warnings when compiling kvm user space on 2.6.29
Zhiyong Wu wrote: HI, When compiling the lastest the code for kvm user space on 2.6.29 i386, the following warnings has appeared: test/x86/msr.c:10: warning: \u2018report\u2019 defined but not used test/x86/msr.c:18: warning: \u2018wrmsr\u2019 defined but not used test/x86/msr.c:23: warning: \u2018rdmsr\u2019 defined but not used Please send patches with a signoff, like kernel patches. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Mapping a virtual block device on the guest
I understand that the option "-drive file=/dev/path/to/host/device,if=virtio" would map the device given in the file parameter as a virtual block device on the guest. Can somebody explain me the roles of virtio-pci and virtio-blk modules on the guest in accessing the virtual block device. I am unable to understand the design. Thx, Venkat -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] KVM: Make kvm header compile under g++.
nathan binkert wrote: Hi Avi, You said that you'd be willing to include this. I don't want to pester or anything, but I would like it to not fall into the abyss. Would you like me to file it as a bug and assign it to you? Are there any changes that you'd like? No, I just missed your patch. Applied now. Thanks for pestering, it's the right thing when I miss something (copying me also helps). btw, can you share what you're doing with kvm and g++? -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Make kvm_cpu_(has|get)_interrupt() work for userspace irqchip too.
> > * check if there are pending timer events
> > @@ -48,14 +49,17 @@ int kvm_cpu_has_interrupt(struct kvm_vcpu *v)
> > {
> > struct kvm_pic *s;
> >
> > - if (kvm_apic_has_interrupt(v) == -1) { /* LAPIC */
> > - if (kvm_apic_accept_pic_intr(v)) {
> > - s = pic_irqchip(v->kvm);/* PIC */
> > - return s->output;
> > - } else
> > - return 0;
> > + if (irqchip_in_kernel(v->kvm)) {
> > + if (kvm_apic_has_interrupt(v) == -1) { /* LAPIC */
> > + if (kvm_apic_accept_pic_intr(v)) {
> > + s = pic_irqchip(v->kvm);/* PIC */
> > + return s->output;
> > + } else
> > + return 0;
> > + }
> > + return 1;
> > }
> > - return 1;
> > + return v->arch.irq_summary;
> > }
>
> Use if (!irqchip_in_kernel(v->kvm)) for userspace seems more simple(rather
> than a series of indention...).
>
As long as lines are smaller then 80 chars I don't care much :) If new
version of the patch will be needed I'll change this.
> >
> > @@ -2976,8 +2975,9 @@ static int handle_interrupt_window(struct kvm_vcpu
> > *vcpu, * If the user space waits to inject interrupts, exit as soon as *
> > possible
> > */
> > - if (kvm_run->request_interrupt_window &&
> > - !vcpu->arch.irq_summary) {
> > + if (!irqchip_in_kernel(vcpu->kvm) &&
> > + kvm_run->request_interrupt_window &&
>
> I think kvm_run->request_interrupt_window can indicate it's userspace irqchip?
>
You are correct, but this value is directly controlled by userspase, so
I added irqchip_in_kernel() check to protect from buggy userspace.
--
Gleb.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] Make kvm_cpu_(has|get)_interrupt() work for userspace irqchip too.
On Tuesday 07 April 2009 17:08:12 Gleb Natapov wrote:
> Signed-off-by: Gleb Natapov
> ---
>
> arch/x86/kvm/irq.c | 39 +++
> arch/x86/kvm/svm.c | 11 +++
> arch/x86/kvm/vmx.c | 18 +-
> arch/x86/kvm/x86.c |4 ++--
> 4 files changed, 41 insertions(+), 31 deletions(-)
>
> diff --git a/arch/x86/kvm/irq.c b/arch/x86/kvm/irq.c
> index cf17ed5..6974e7c 100644
> --- a/arch/x86/kvm/irq.c
> +++ b/arch/x86/kvm/irq.c
> @@ -24,6 +24,7 @@
>
> #include "irq.h"
> #include "i8254.h"
> +#include "x86.h"
>
> /*
> * check if there are pending timer events
> @@ -48,14 +49,17 @@ int kvm_cpu_has_interrupt(struct kvm_vcpu *v)
> {
> struct kvm_pic *s;
>
> - if (kvm_apic_has_interrupt(v) == -1) { /* LAPIC */
> - if (kvm_apic_accept_pic_intr(v)) {
> - s = pic_irqchip(v->kvm);/* PIC */
> - return s->output;
> - } else
> - return 0;
> + if (irqchip_in_kernel(v->kvm)) {
> + if (kvm_apic_has_interrupt(v) == -1) { /* LAPIC */
> + if (kvm_apic_accept_pic_intr(v)) {
> + s = pic_irqchip(v->kvm);/* PIC */
> + return s->output;
> + } else
> + return 0;
> + }
> + return 1;
> }
> - return 1;
> + return v->arch.irq_summary;
> }
Use if (!irqchip_in_kernel(v->kvm)) for userspace seems more simple(rather
than a series of indention...).
> EXPORT_SYMBOL_GPL(kvm_cpu_has_interrupt);
>
> @@ -64,18 +68,21 @@ EXPORT_SYMBOL_GPL(kvm_cpu_has_interrupt);
> */
> int kvm_cpu_get_interrupt(struct kvm_vcpu *v)
> {
> - struct kvm_pic *s;
> - int vector;
> + if (irqchip_in_kernel(v->kvm)) {
> + struct kvm_pic *s;
> + int vector;
>
> - vector = kvm_get_apic_interrupt(v); /* APIC */
> - if (vector == -1) {
> - if (kvm_apic_accept_pic_intr(v)) {
> - s = pic_irqchip(v->kvm);
> - s->output = 0; /* PIC */
> - vector = kvm_pic_read_irq(v->kvm);
> + vector = kvm_get_apic_interrupt(v); /* APIC */
> + if (vector == -1) {
> + if (kvm_apic_accept_pic_intr(v)) {
> + s = pic_irqchip(v->kvm);
> + s->output = 0; /* PIC */
> + vector = kvm_pic_read_irq(v->kvm);
> + }
> }
> + return vector;
> }
> - return vector;
> + return kvm_pop_irq(v);
> }
> EXPORT_SYMBOL_GPL(kvm_cpu_get_interrupt);
>
> diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
> index 053f3c5..1903c27 100644
> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -2089,8 +2089,9 @@ static int interrupt_window_interception(struct
> vcpu_svm *svm, * If the user space waits to inject interrupts, exit as soon
> as * possible
>*/
> - if (kvm_run->request_interrupt_window &&
> - !svm->vcpu.arch.irq_summary) {
> + if (!irqchip_in_kernel(svm->vcpu.kvm) &&
> + kvm_run->request_interrupt_window &&
> + !kvm_cpu_has_interrupt(&svm->vcpu)) {
> ++svm->vcpu.stat.irq_window_exits;
> kvm_run->exit_reason = KVM_EXIT_IRQ_WINDOW_OPEN;
> return 0;
> @@ -2371,7 +2372,8 @@ static void do_interrupt_requests(struct kvm_vcpu
> *vcpu, (svm->vmcb->save.rflags & X86_EFLAGS_IF) &&
>(svm->vcpu.arch.hflags & HF_GIF_MASK));
>
> - if (svm->vcpu.arch.interrupt_window_open && svm->vcpu.arch.irq_summary)
> + if (svm->vcpu.arch.interrupt_window_open &&
> + kvm_cpu_has_interrupt(&svm->vcpu))
> /*
>* If interrupts enabled, and not blocked by sti or mov ss.
> Good.
>*/
> @@ -2381,7 +2383,8 @@ static void do_interrupt_requests(struct kvm_vcpu
> *vcpu, * Interrupts blocked. Wait for unblock.
>*/
> if (!svm->vcpu.arch.interrupt_window_open &&
> - (svm->vcpu.arch.irq_summary || kvm_run->request_interrupt_window))
> + (kvm_cpu_has_interrupt(&svm->vcpu) ||
> + kvm_run->request_interrupt_window))
> svm_set_vintr(svm);
> else
> svm_clear_vintr(svm);
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index c6997c0..b3292c1 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -2535,21 +2535,20 @@ static void do_interrupt_requests(struct kvm_vcpu
> *vcpu, vmx_inject_nmi(vcpu);
> if (vcpu->arch.nmi_pending)
> enable_nmi_window(vcpu);
> - else if (vcpu->arch.irq_summary
> - || kvm_run->request_interrupt_window)
> + else if (kvm_cpu_has_interrupt(vcpu) ||
> + kvm_run->request_interrupt_window)
> enabl
[PATCH] Fix crash on resolution change -> screen dump -> vga redraw
The vga screen dump function updates last_width and last_height, but does not change the DisplaySurface that these variables describe. A consequent vga_draw_graphic() will therefore fail to resize the surface and crash. Fix by invalidating the display state after a screen dump, forcing vga_draw_graphic() to reallocate the DisplaySurface. Signed-off-by: Avi Kivity --- hw/vga.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/vga.c b/hw/vga.c index b1e4373..4d1049b 100644 --- a/hw/vga.c +++ b/hw/vga.c @@ -2678,4 +2678,5 @@ static void vga_screen_dump(void *opaque, const char *filename) vga_screen_dump_graphic(s, filename); else vga_screen_dump_text(s, filename); +vga_invalidate_display(s); } -- 1.6.0.6 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Kvm crash when I create a Guest
I'm Running Ubuntu 8.10, here is the command I use: kvm -net none -m 192 -no-acpi -hda ./gentoo_cleanvm.img.tar.lzma Dmesg Output: [ 7783.883426] [ cut here ] [ 7783.883440] kernel BUG at /build/buildd/linux-2.6.27/arch/x86/kvm/../../../virt/kvm/kvm_main.c:1528! [ 7783.883446] invalid opcode: [7] SMP [ 7783.883452] CPU 0 [ 7783.883457] Modules linked in: ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp kvm_amd kvm ipv6 af_packet rfcomm sco bridge stp bnep l2cap bluetooth ppdev powernow_k8 cpufreq_conservative cpufreq_ondemand cpufreq_stats cpufreq_powersave freq_table cpufreq_userspace sbs pci_slot container sbshc video output battery iptable_filter ip_tables x_tables ac lp snd_hda_intel snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq psmouse snd_timer evdev snd_seq_device serio_raw snd pcspkr k8temp soundcore snd_page_alloc i2c_piix4 i2c_core fglrx(P) parport_pc parport wmi button shpchp pci_hotplug ext3 jbd mbcache usb_storage libusual ata_generic sd_mod sr_mod crc_t10dif cdrom sg pata_atiixp ehci_hcd pata_acpi ohci_hcd ahci usbcore libata scsi_mod dock tg3 libphy thermal processor fan fbcon tileblit font bitblit softcursor fuse [ 7783.883588] Pid: 13480, comm: kvm Tainted: P D 2.6.27-11-generic #1 [ 7783.883593] RIP: 0010:[] [] kvm_handle_fault_on_reboot+0x12/0x30 [kvm] [ 7783.883634] RSP: 0018:8800735ddbd8 EFLAGS: 00010046 [ 7783.883639] RAX: 8800735e1000 RBX: 88007408bb00 RCX: [ 7783.883644] RDX: 88007408bb00 RSI: 8800735ddc0c RDI: 806e2a80 [ 7783.883648] RBP: 8800735ddbd8 R08: 880072d7a300 R09: [ 7783.883653] R10: 0001 R11: 0246 R12: 88007408bb00 [ 7783.883658] R13: ae80 R14: 8800735d7000 R15: 88007408c310 [ 7783.883663] FS: 44430950(0063) GS:806e2a80() knlGS:f6804b90 [ 7783.883668] CS: 0010 DS: ES: CR0: 8005003b [ 7783.883673] CR2: 7f8a03ee4000 CR3: 734fd000 CR4: 06e0 [ 7783.883678] DR0: DR1: DR2: [ 7783.883682] DR3: DR6: 0ff0 DR7: 0400 [ 7783.883687] Process kvm (pid: 13480, threadinfo 8800735dc000, task 880083034350) [ 7783.883692] Stack: 8800735ddc38 a06a0e19 807a7098 88007408bb00 [ 7783.883702] 0063dc28 803a875f 7408bb00 88007408bb58 [ 7783.883710] 88007408bb00 ae80 8800735d7000 88007408c310 [ 7783.883717] Call Trace: [ 7783.883734] [] svm_vcpu_run+0x1a9/0x3f0 [kvm_amd] [ 7783.883749] [] ? __up_read+0x8f/0xb0 [ 7783.883771] [] __vcpu_run+0x1f0/0x670 [kvm] [ 7783.883780] [] ? recalc_sigpending+0x9/0x70 [ 7783.883800] [] kvm_arch_vcpu_ioctl_run+0x8f/0x1f0 [kvm] [ 7783.883820] [] kvm_vcpu_ioctl+0x2aa/0x490 [kvm] [ 7783.883829] [] ? handle_mm_fault+0x1ee/0x470 [ 7783.883837] [] ? __slab_free+0x10/0x120 [ 7783.883844] [] ? __sigqueue_free+0x3d/0x50 [ 7783.883850] [] ? __sigqueue_free+0x3d/0x50 [ 7783.883857] [] ? __dequeue_signal+0xed/0x210 [ 7783.883863] [] ? recalc_sigpending+0x9/0x70 [ 7783.883869] [] ? dequeue_signal+0x42/0x180 [ 7783.883875] [] ? copy_siginfo_to_user+0x15d/0x210 [ 7783.883883] [] vfs_ioctl+0x36/0xb0 [ 7783.883888] [] do_vfs_ioctl+0x273/0x2f0 [ 7783.883897] [] ? set_normalized_timespec+0x9/0x90 [ 7783.883903] [] sys_ioctl+0xa1/0xb0 [ 7783.883912] [] system_call_fastpath+0x16/0x1b [ 7783.883916] [ 7783.883918] [ 7783.883920] Code: b9 df 31 c0 48 c7 86 80 00 00 00 00 ac 69 a0 c9 c3 0f 1f 84 00 00 00 00 00 55 48 89 e5 e8 57 d5 b9 df 80 3d 78 86 02 00 00 75 0e <0f> 0b eb fe 66 2e 0f 1f 84 00 00 00 00 00 eb fe 66 66 66 66 66 [ 7783.883973] RIP [] kvm_handle_fault_on_reboot+0x12/0x30 [kvm] [ 7783.883994] RSP [ 7783.884010] ---[ end trace 89b86beb3c94c6d1 ]--- This is /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 75 model name : AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ stepping: 2 cpu MHz : 1000.000 cache size : 512 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow rep_good nopl pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy bogomips: 1994.98 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc processor : 1 vendor_id : AuthenticAMD cpu family : 15 model : 75 model name : AMD Athlon(tm) 64
[PATCH] libkvm: fix build with --with-patched-kernel on 2.6.29
Make libkvm build with --with-patched-kernel on 2.6.29.
Reported-by: Michael S. Tsirkin
---
The patch was actually done by Avi.
diff --git a/libkvm/kvm-common.h b/libkvm/kvm-common.h
index 70a95c2..96361e8 100644
--- a/libkvm/kvm-common.h
+++ b/libkvm/kvm-common.h
@@ -66,8 +66,8 @@ struct kvm_context {
#ifdef KVM_CAP_IRQ_ROUTING
struct kvm_irq_routing *irq_routes;
int nr_allocated_irq_routes;
- int max_used_gsi;
#endif
+ int max_used_gsi;
};
int kvm_alloc_kernel_memory(kvm_context_t kvm, unsigned long memory,
diff --git a/libkvm/libkvm.h b/libkvm/libkvm.h
index d3e431a..ce6f054 100644
--- a/libkvm/libkvm.h
+++ b/libkvm/libkvm.h
@@ -815,6 +815,7 @@ int kvm_add_irq_route(kvm_context_t kvm, int gsi, int
irqchip, int pin);
*/
int kvm_del_irq_route(kvm_context_t kvm, int gsi, int irqchip, int pin);
+struct kvm_irq_routing_entry;
/*!
* \brief Adds a routing entry to the temporary irq routing table
*
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] Consolidate userspace and kernel interrupt injection for VMX.
Use the same callback to inject irq/nmi events no matter what irqchip is
in use. Only from VMX for now.
Signed-off-by: Gleb Natapov
---
arch/x86/include/asm/kvm_host.h |2 +
arch/x86/kvm/svm.c |2 +
arch/x86/kvm/vmx.c | 71 +--
arch/x86/kvm/x86.c |2 +
4 files changed, 19 insertions(+), 58 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index e672ca5..4e39c40 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -520,7 +520,7 @@ struct kvm_x86_ops {
void (*queue_exception)(struct kvm_vcpu *vcpu, unsigned nr,
bool has_error_code, u32 error_code);
bool (*exception_injected)(struct kvm_vcpu *vcpu);
- void (*inject_pending_irq)(struct kvm_vcpu *vcpu);
+ void (*inject_pending_irq)(struct kvm_vcpu *vcpu, struct kvm_run *run);
void (*inject_pending_vectors)(struct kvm_vcpu *vcpu,
struct kvm_run *run);
int (*interrupt_allowed)(struct kvm_vcpu *vcpu);
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 1903c27..674a249 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2296,7 +2296,7 @@ static int svm_interrupt_allowed(struct kvm_vcpu *vcpu)
(svm->vcpu.arch.hflags & HF_GIF_MASK);
}
-static void svm_intr_assist(struct kvm_vcpu *vcpu)
+static void svm_intr_assist(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
{
struct vcpu_svm *svm = to_svm(vcpu);
struct vmcb *vmcb = svm->vmcb;
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index b3292c1..06252f7 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2510,48 +2510,6 @@ static int vmx_interrupt_allowed(struct kvm_vcpu *vcpu)
return vcpu->arch.interrupt_window_open;
}
-static void do_interrupt_requests(struct kvm_vcpu *vcpu,
- struct kvm_run *kvm_run)
-{
- vmx_update_window_states(vcpu);
-
- if (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP)
- vmcs_clear_bits(GUEST_INTERRUPTIBILITY_INFO,
- GUEST_INTR_STATE_STI |
- GUEST_INTR_STATE_MOV_SS);
-
- if (vcpu->arch.nmi_pending && !vcpu->arch.nmi_injected) {
- if (vcpu->arch.interrupt.pending) {
- enable_nmi_window(vcpu);
- } else if (vcpu->arch.nmi_window_open) {
- vcpu->arch.nmi_pending = false;
- vcpu->arch.nmi_injected = true;
- } else {
- enable_nmi_window(vcpu);
- return;
- }
- }
- if (vcpu->arch.nmi_injected) {
- vmx_inject_nmi(vcpu);
- if (vcpu->arch.nmi_pending)
- enable_nmi_window(vcpu);
- else if (kvm_cpu_has_interrupt(vcpu) ||
-kvm_run->request_interrupt_window)
- enable_irq_window(vcpu);
- return;
- }
-
- if (vcpu->arch.interrupt_window_open) {
- if (kvm_cpu_has_interrupt(vcpu) &&
!vcpu->arch.interrupt.pending)
- kvm_queue_interrupt(vcpu, kvm_cpu_get_interrupt(vcpu));
-
- if (vcpu->arch.interrupt.pending)
- vmx_inject_irq(vcpu, vcpu->arch.interrupt.nr);
- } else if(kvm_cpu_has_interrupt(vcpu) ||
- kvm_run->request_interrupt_window)
- enable_irq_window(vcpu);
-}
-
static int vmx_set_tss_addr(struct kvm *kvm, unsigned int addr)
{
int ret;
@@ -3351,8 +3309,11 @@ static void vmx_complete_interrupts(struct vcpu_vmx *vmx)
}
}
-static void vmx_intr_assist(struct kvm_vcpu *vcpu)
+static void vmx_intr_assist(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
{
+ bool req_int_win = !irqchip_in_kernel(vcpu->kvm) &&
+ kvm_run->request_interrupt_window;
+
update_tpr_threshold(vcpu);
vmx_update_window_states(vcpu);
@@ -3373,25 +3334,25 @@ static void vmx_intr_assist(struct kvm_vcpu *vcpu)
return;
}
}
+
if (vcpu->arch.nmi_injected) {
vmx_inject_nmi(vcpu);
- if (vcpu->arch.nmi_pending)
- enable_nmi_window(vcpu);
- else if (kvm_cpu_has_interrupt(vcpu))
- enable_irq_window(vcpu);
- return;
+ goto out;
}
+
if (!vcpu->arch.interrupt.pending && kvm_cpu_has_interrupt(vcpu)) {
if (vcpu->arch.interrupt_window_open)
kvm_queue_interrupt(vcpu, kvm_cpu_get_interrupt(vcpu));
- else
- enable_irq_window(vcpu);
}
- if (vcpu->arch.interrupt.pending) {
+
+ if (vcpu->arch.interrupt.pending)
vmx_inject_ir
[PATCH 3/3] Cleanup vmx_intr_assist()
Signed-off-by: Gleb Natapov
---
arch/x86/kvm/vmx.c | 55
1 files changed, 30 insertions(+), 25 deletions(-)
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 06252f7..9eb518f 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -3309,6 +3309,34 @@ static void vmx_complete_interrupts(struct vcpu_vmx *vmx)
}
}
+static void vmx_intr_inject(struct kvm_vcpu *vcpu)
+{
+ /* try to reinject previous events if any */
+ if (vcpu->arch.nmi_injected) {
+ vmx_inject_nmi(vcpu);
+ return;
+ }
+
+ if (vcpu->arch.interrupt.pending) {
+ vmx_inject_irq(vcpu, vcpu->arch.interrupt.nr);
+ return;
+ }
+
+ /* try to inject new event if pending */
+ if (vcpu->arch.nmi_pending) {
+ if (vcpu->arch.nmi_window_open) {
+ vcpu->arch.nmi_pending = false;
+ vcpu->arch.nmi_injected = true;
+ vmx_inject_nmi(vcpu);
+ }
+ } else if (kvm_cpu_has_interrupt(vcpu)) {
+ if (vcpu->arch.interrupt_window_open) {
+ kvm_queue_interrupt(vcpu, kvm_cpu_get_interrupt(vcpu));
+ vmx_inject_irq(vcpu, vcpu->arch.interrupt.nr);
+ }
+ }
+}
+
static void vmx_intr_assist(struct kvm_vcpu *vcpu, struct kvm_run *kvm_run)
{
bool req_int_win = !irqchip_in_kernel(vcpu->kvm) &&
@@ -3323,32 +3351,9 @@ static void vmx_intr_assist(struct kvm_vcpu *vcpu,
struct kvm_run *kvm_run)
GUEST_INTR_STATE_STI |
GUEST_INTR_STATE_MOV_SS);
- if (vcpu->arch.nmi_pending && !vcpu->arch.nmi_injected) {
- if (vcpu->arch.interrupt.pending) {
- enable_nmi_window(vcpu);
- } else if (vcpu->arch.nmi_window_open) {
- vcpu->arch.nmi_pending = false;
- vcpu->arch.nmi_injected = true;
- } else {
- enable_nmi_window(vcpu);
- return;
- }
- }
-
- if (vcpu->arch.nmi_injected) {
- vmx_inject_nmi(vcpu);
- goto out;
- }
-
- if (!vcpu->arch.interrupt.pending && kvm_cpu_has_interrupt(vcpu)) {
- if (vcpu->arch.interrupt_window_open)
- kvm_queue_interrupt(vcpu, kvm_cpu_get_interrupt(vcpu));
- }
-
- if (vcpu->arch.interrupt.pending)
- vmx_inject_irq(vcpu, vcpu->arch.interrupt.nr);
+ vmx_intr_inject(vcpu);
-out:
+ /* enable NMI/IRQ window open exits if needed */
if (vcpu->arch.nmi_pending)
enable_nmi_window(vcpu);
else if (kvm_cpu_has_interrupt(vcpu) || req_int_win)
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] Make kvm_cpu_(has|get)_interrupt() work for userspace irqchip too.
Signed-off-by: Gleb Natapov
---
arch/x86/kvm/irq.c | 39 +++
arch/x86/kvm/svm.c | 11 +++
arch/x86/kvm/vmx.c | 18 +-
arch/x86/kvm/x86.c |4 ++--
4 files changed, 41 insertions(+), 31 deletions(-)
diff --git a/arch/x86/kvm/irq.c b/arch/x86/kvm/irq.c
index cf17ed5..6974e7c 100644
--- a/arch/x86/kvm/irq.c
+++ b/arch/x86/kvm/irq.c
@@ -24,6 +24,7 @@
#include "irq.h"
#include "i8254.h"
+#include "x86.h"
/*
* check if there are pending timer events
@@ -48,14 +49,17 @@ int kvm_cpu_has_interrupt(struct kvm_vcpu *v)
{
struct kvm_pic *s;
- if (kvm_apic_has_interrupt(v) == -1) { /* LAPIC */
- if (kvm_apic_accept_pic_intr(v)) {
- s = pic_irqchip(v->kvm);/* PIC */
- return s->output;
- } else
- return 0;
+ if (irqchip_in_kernel(v->kvm)) {
+ if (kvm_apic_has_interrupt(v) == -1) { /* LAPIC */
+ if (kvm_apic_accept_pic_intr(v)) {
+ s = pic_irqchip(v->kvm);/* PIC */
+ return s->output;
+ } else
+ return 0;
+ }
+ return 1;
}
- return 1;
+ return v->arch.irq_summary;
}
EXPORT_SYMBOL_GPL(kvm_cpu_has_interrupt);
@@ -64,18 +68,21 @@ EXPORT_SYMBOL_GPL(kvm_cpu_has_interrupt);
*/
int kvm_cpu_get_interrupt(struct kvm_vcpu *v)
{
- struct kvm_pic *s;
- int vector;
+ if (irqchip_in_kernel(v->kvm)) {
+ struct kvm_pic *s;
+ int vector;
- vector = kvm_get_apic_interrupt(v); /* APIC */
- if (vector == -1) {
- if (kvm_apic_accept_pic_intr(v)) {
- s = pic_irqchip(v->kvm);
- s->output = 0; /* PIC */
- vector = kvm_pic_read_irq(v->kvm);
+ vector = kvm_get_apic_interrupt(v); /* APIC */
+ if (vector == -1) {
+ if (kvm_apic_accept_pic_intr(v)) {
+ s = pic_irqchip(v->kvm);
+ s->output = 0; /* PIC */
+ vector = kvm_pic_read_irq(v->kvm);
+ }
}
+ return vector;
}
- return vector;
+ return kvm_pop_irq(v);
}
EXPORT_SYMBOL_GPL(kvm_cpu_get_interrupt);
diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c
index 053f3c5..1903c27 100644
--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -2089,8 +2089,9 @@ static int interrupt_window_interception(struct vcpu_svm
*svm,
* If the user space waits to inject interrupts, exit as soon as
* possible
*/
- if (kvm_run->request_interrupt_window &&
- !svm->vcpu.arch.irq_summary) {
+ if (!irqchip_in_kernel(svm->vcpu.kvm) &&
+ kvm_run->request_interrupt_window &&
+ !kvm_cpu_has_interrupt(&svm->vcpu)) {
++svm->vcpu.stat.irq_window_exits;
kvm_run->exit_reason = KVM_EXIT_IRQ_WINDOW_OPEN;
return 0;
@@ -2371,7 +2372,8 @@ static void do_interrupt_requests(struct kvm_vcpu *vcpu,
(svm->vmcb->save.rflags & X86_EFLAGS_IF) &&
(svm->vcpu.arch.hflags & HF_GIF_MASK));
- if (svm->vcpu.arch.interrupt_window_open && svm->vcpu.arch.irq_summary)
+ if (svm->vcpu.arch.interrupt_window_open &&
+ kvm_cpu_has_interrupt(&svm->vcpu))
/*
* If interrupts enabled, and not blocked by sti or mov ss.
Good.
*/
@@ -2381,7 +2383,8 @@ static void do_interrupt_requests(struct kvm_vcpu *vcpu,
* Interrupts blocked. Wait for unblock.
*/
if (!svm->vcpu.arch.interrupt_window_open &&
- (svm->vcpu.arch.irq_summary || kvm_run->request_interrupt_window))
+ (kvm_cpu_has_interrupt(&svm->vcpu) ||
+kvm_run->request_interrupt_window))
svm_set_vintr(svm);
else
svm_clear_vintr(svm);
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index c6997c0..b3292c1 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2535,21 +2535,20 @@ static void do_interrupt_requests(struct kvm_vcpu *vcpu,
vmx_inject_nmi(vcpu);
if (vcpu->arch.nmi_pending)
enable_nmi_window(vcpu);
- else if (vcpu->arch.irq_summary
-|| kvm_run->request_interrupt_window)
+ else if (kvm_cpu_has_interrupt(vcpu) ||
+kvm_run->request_interrupt_window)
enable_irq_window(vcpu);
return;
}
if (vcpu->arch.interrupt_window_open) {
- if (vcpu->arch.irq_summary && !vcpu->arch.interrupt.pending)
-
RE: PCI hotplug and passthrough together supported?
hotplug is supported. You can refer to http://www.linux-kvm.org/page/How_to_assign_devices_with_VT-d_in_KVM. Regards, Weidong Aaron Dailey wrote: > I'm interested in using PCI passthrough on a PCI device that may not > be present at boot time, but is later inserted. Is this possible in > KVM? I believe both passthrough and hotplug are individually > supported, but I couldn't find an answer about hot plugging a device > and then using it via passthrough. > > I'm not subscribed to the mailing list, so please copy me on replies. > > Thanks for your help, > > Aaron Dailey > -- > Aaron Dailey > a...@alumni.virginia.edu -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Changing the QEMU svn VERSION string
On Mon, Apr 06, 2009 at 09:37:55PM -0500, Anthony Liguori wrote: > Hi, > > I'd like to update the VERSION string in QEMU's svn tree. Right now, > it's 0.10.0 and since we have a 0.10.2 release, that's somewhat confusing. > > I don't want to make it 0.11.0 either because that's not going to be > reliable from a feature detection perspective. What I would like is to > make it 0.11.0-devel or something similar to that. > > Being the nice guy I am, I thought I would check that this didn't make > libvirt go bonkers :-) This is the relevant detection code in libvirt: > > > if (sscanf(help, "QEMU PC emulator version %u.%u.%u (kvm-%u)", > &major, &minor, µ, &kvm_version) != 4) > kvm_version = 0; > > if (!kvm_version && sscanf(help, "QEMU PC emulator version u.%u.%u", > &major, &minor, µ) != 3) > goto cleanup2; > > If I change SVN to 0.11.0-devel, that's going to break the KVM string > although the QEMU string will continue to work. Avi could potentially > carry a patch to keep it 0.10.x and since kvm-%u will be used to > identify features, that should keep things working. The only things we use the KVM version for are to decide whether migration and vnet_hdr flag for tun devices is supported. These checks are already outdated since 0.10.0 QEMU now has support for migration, and thus needs updating. So if you choose to go with '0.11.0-devel' it won't cause any huge problems for us, and I'll change this code to make it more forgiving of version number string changes in future. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] Changing the QEMU svn VERSION string
Hi,
I'd like to update the VERSION string in QEMU's svn tree. Right now,
it's 0.10.0 and since we have a 0.10.2 release, that's somewhat confusing.
I don't want to make it 0.11.0 either because that's not going to be
reliable from a feature detection perspective. What I would like is to
make it 0.11.0-devel or something similar to that.
Maybe 0.10.99 ? Or 0.10.90, leaving the door open to number the 0.11
beta / rc versions (if any) 0.10.9{1,2,3}?
cheers,
Gerd
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: PCI passtthrought & intel 82574L can't boot from disk
Hi, Currently, expansion ROM of assigned devices will be loaded into guest and execute. You can just comment out one line code (assigned_dev_load_option_rom() in qemu/hw/pc.c) to let qemu don't load expansion ROM, and then this issue should be gone. I met this issue before, but there was no problem when I assigned the same device to a guest in Xen which also load and execute expansion ROM. I guess it's caused by the difference between Xen guest bios and kvm guest bios. Regards, Weidong Hauke Hoffmann wrote: > On Thursday 02 April 2009 18:58:26 you wrote: >> It is my understanding that you need vt-d/iommu support. I didn't >> think any existing amd chipsets had iommu support. You may want to >> look into that. > > Hi Brian, > > thanks for you response. > > I found a tool [1] from Intel to disable the Boot ROM on the nic. > Thats resolves the boot problem. > > Regards > Hauke > > [1] > http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&ProductID=412&DwnldID=8242 > >> >> --Brian Jackson >> >> On Thursday 02 April 2009 07:00:07 Hauke Hoffmann wrote: >>> Hi, >>> >>> qemu-system-x86_64 runs well and i can boot and run the guest >>> system. Thats works very well. >>> >>> Command: >>> /usr/local/kvm/bin/qemu-system-x86_64 -m >>> 512 -hda /var/VM/roadrunner.local/hda.qcow2 -smp 1 -vnc >>> 192.168.2.30: -net nic,macaddr=DE:AD:BE:EF:90:26 -net >>> tap,ifname=tap0,script=no,downscript=no -boot c >>> >>> Then i tried to add an intel 82574L network adapter to the guest. >>> Just the same command with addtionally "-pcidevice host=07:00.0" >>> >>> Then i connected via VNC and see BIOS startpage and the following >>> lines: Initializing Intel(r) boot agent ge v1.3.21 >>> pxe 2.1 build 086 (WfM 2.0) >>> Press f12 for moot menu >>> >>> You can see a screenshot at http://nxt7.de/download/qemu.png >>> >>> The guests keep on this point and nothing changes. (I have wait >>> hours.) >>> >>> I tried to press F12 in ThightVNC but no action. >>> I must say that ThightVNC has problems with special chars (in my >>> case). >>> >>> At this point, i need your help. >>> >>> >>> Here are some details of my system >>> >>> Kernel: 2.6.29 form kernel.org (self compiled) >>> kvm userspace: kvm-84 (self compiled) >>> OS: Ubuntu 8.04.2 server >>> >>> r...@ls:~# lspci >>> 00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev >>> a2) 00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a3) >>> 00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a3) >>> 00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller >>> (rev a1) 00:02.1 USB Controller: nVidia Corporation MCP55 USB >>> Controller (rev a2) 00:04.0 IDE interface: nVidia Corporation MCP55 >>> IDE (rev a1) 00:05.0 IDE interface: nVidia Corporation MCP55 SATA >>> Controller (rev a3) 00:05.1 IDE interface: nVidia Corporation MCP55 >>> SATA Controller (rev a3) 00:05.2 IDE interface: nVidia Corporation >>> MCP55 SATA Controller (rev a3) 00:06.0 PCI bridge: nVidia >>> Corporation MCP55 PCI bridge (rev a2) 00:08.0 Bridge: nVidia >>> Corporation MCP55 Ethernet (rev a3) 00:09.0 Bridge: nVidia >>> Corporation MCP55 Ethernet (rev a3) 00:0a.0 PCI bridge: nVidia >>> Corporation MCP55 PCI Express bridge (rev a3) 00:0b.0 PCI bridge: >>> nVidia Corporation MCP55 PCI Express bridge (rev a3) 00:0c.0 PCI >>> bridge: nVidia Corporation MCP55 PCI Express bridge (rev a3) >>> 00:0d.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge >>> (rev a3) 00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI Express >>> bridge (rev a3) 00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI >>> Express bridge (rev a3) 00:18.0 Host bridge: Advanced Micro Devices >>> [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration >>> 00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 >>> [Athlon64/Opteron] Address Map 00:18.2 Host bridge: Advanced Micro >>> Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller 00:18.3 Host >>> bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] >>> Miscellaneous Control 01:09.0 Ethernet controller: Lite-On >>> Communications Inc LNE100TX [Linksys EtherFast 10/100] (rev 25) >>> 01:0a.0 VGA compatible controller: XGI Technology Inc. (eXtreme >>> Graphics Innovation) Volari Z7 06:00.0 SATA controller: JMicron >>> Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 03) >>> 06:00.1 IDE interface: JMicron Technologies, Inc. JMicron >>> 20360/20363 AHCI Controller (rev 03) 07:00.0 Ethernet controller: >>> Intel Corporation 82574L Gigabit Network Connection >>> >>> >>> r...@ls:~# lspci -tvvv >>> -[:00]-+-00.0 nVidia Corporation MCP55 Memory Controller >>>+-01.0 nVidia Corporation MCP55 LPC Bridge >>>+-01.1 nVidia Corporation MCP55 SMBus >>>+-02.0 nVidia Corporation MCP55 USB Controller >>>+-02.1 nVidia Corporation MCP55 USB Controller >>>+-04.0 nVidia Corporation MCP55 IDE >>>+-05.0 nVidia Corporation MCP55 SATA Controller >>>
