[COMMIT master] Remove merge conflict markers left in target-i386/kvm.c.
From: Avi Kivity a...@redhat.com Signed-off-by: Avi Kivity a...@redhat.com diff --git a/target-i386/kvm.c b/target-i386/kvm.c index 123dcc8..3e71158 100644 --- a/target-i386/kvm.c +++ b/target-i386/kvm.c @@ -564,10 +564,7 @@ static int kvm_put_msrs(CPUState *env, int level) kvm_msr_entry_set(msrs[n++], MSR_IA32_SYSENTER_EIP, env-sysenter_eip); if (kvm_has_msr_star(env)) kvm_msr_entry_set(msrs[n++], MSR_STAR, env-star); - HEAD kvm_msr_entry_set(msrs[n++], MSR_VM_HSAVE_PA, env-vm_hsave); -=== - 6cb2996cef5e273ef370e690e84b5e1403f5c391 #ifdef TARGET_X86_64 /* FIXME if lm capable */ kvm_msr_entry_set(msrs[n++], MSR_CSTAR, env-cstar); -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] Use qemu-cfg to provide the BIOS with an optional table of e820 entries
From: Jes Sorensen jes.soren...@redhat.com
The missing bits for qemu-kvm.git to match what qemu does.
Signed-off-by: Jes Sorensen jes.soren...@redhat.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index 0160fe9..ad58d87 100644
--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -37,6 +37,13 @@ int kvm_set_tss_addr(kvm_context_t kvm, unsigned long addr)
{
#ifdef KVM_CAP_SET_TSS_ADDR
int r;
+/*
+ * Tell fw_cfg to notify the BIOS to reserve the range.
+ */
+if (e820_add_entry(addr, 0x4000, E820_RESERVED) 0) {
+perror(e820_add_entry() table is full);
+exit(1);
+}
r = kvm_ioctl(kvm_state, KVM_CHECK_EXTENSION, KVM_CAP_SET_TSS_ADDR);
if (r 0) {
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: cleanup kvm trace
From: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
This patch does:
- no need call tracepoint_synchronize_unregister() when kvm module
is unloaded since ftrace can handle it
- cleanup ftrace's macro
Signed-off-by: Xiao Guangrong xiaoguangr...@cn.fujitsu.com
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 741373e..d0f5e11 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -147,7 +147,6 @@ module_param(oos_shadow, bool, 0644);
#include trace/events/kvm.h
-#undef TRACE_INCLUDE_FILE
#define CREATE_TRACE_POINTS
#include mmutrace.h
diff --git a/arch/x86/kvm/mmutrace.h b/arch/x86/kvm/mmutrace.h
index 3e4a5c6..1fe956a 100644
--- a/arch/x86/kvm/mmutrace.h
+++ b/arch/x86/kvm/mmutrace.h
@@ -6,8 +6,6 @@
#undef TRACE_SYSTEM
#define TRACE_SYSTEM kvmmmu
-#define TRACE_INCLUDE_PATH .
-#define TRACE_INCLUDE_FILE mmutrace
#define KVM_MMU_PAGE_FIELDS \
__field(__u64, gfn) \
@@ -216,5 +214,10 @@ TRACE_EVENT(
#endif /* _TRACE_KVMMMU_H */
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH .
+#undef TRACE_INCLUDE_FILE
+#define TRACE_INCLUDE_FILE mmutrace
+
/* This part must be outside protection */
#include trace/define_trace.h
diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index 17b52cc..b75efef 100644
--- a/arch/x86/kvm/trace.h
+++ b/arch/x86/kvm/trace.h
@@ -5,8 +5,6 @@
#undef TRACE_SYSTEM
#define TRACE_SYSTEM kvm
-#define TRACE_INCLUDE_PATH arch/x86/kvm
-#define TRACE_INCLUDE_FILE trace
/*
* Tracepoint for guest mode entry.
@@ -575,5 +573,10 @@ TRACE_EVENT(kvm_skinit,
#endif /* _TRACE_KVM_H */
+#undef TRACE_INCLUDE_PATH
+#define TRACE_INCLUDE_PATH arch/x86/kvm
+#undef TRACE_INCLUDE_FILE
+#define TRACE_INCLUDE_FILE trace
+
/* This part must be outside protection */
#include trace/define_trace.h
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 3753c11..169b1b3 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -40,7 +40,7 @@
#include linux/user-return-notifier.h
#include linux/srcu.h
#include trace/events/kvm.h
-#undef TRACE_INCLUDE_FILE
+
#define CREATE_TRACE_POINTS
#include trace.h
diff --git a/include/trace/events/kvm.h b/include/trace/events/kvm.h
index b17d49d..6dd3a51 100644
--- a/include/trace/events/kvm.h
+++ b/include/trace/events/kvm.h
@@ -5,7 +5,6 @@
#undef TRACE_SYSTEM
#define TRACE_SYSTEM kvm
-#define TRACE_INCLUDE_FILE kvm
#if defined(__KVM_HAVE_IOAPIC)
TRACE_EVENT(kvm_set_irq,
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index e758ef7..bcd08b8 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -2272,7 +2272,6 @@ EXPORT_SYMBOL_GPL(kvm_init);
void kvm_exit(void)
{
- tracepoint_synchronize_unregister();
kvm_exit_debug();
misc_deregister(kvm_dev);
kmem_cache_destroy(kvm_vcpu_cache);
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: Trace exception injection
From: Avi Kivity a...@redhat.com
Often an exception can help point out where things start to go wrong.
Signed-off-by: Avi Kivity a...@redhat.com
diff --git a/arch/x86/kvm/trace.h b/arch/x86/kvm/trace.h
index d10b359..32c912c 100644
--- a/arch/x86/kvm/trace.h
+++ b/arch/x86/kvm/trace.h
@@ -219,6 +219,38 @@ TRACE_EVENT(kvm_inj_virq,
TP_printk(irq %u, __entry-irq)
);
+#define EXS(x) { x##_VECTOR, # #x }
+
+#define kvm_trace_sym_exc \
+ EXS(DE), EXS(DB), EXS(BP), EXS(OF), EXS(BR), EXS(UD), EXS(NM), \
+ EXS(DF), EXS(TS), EXS(NP), EXS(SS), EXS(GP), EXS(PF), \
+ EXS(MF), EXS(MC)
+
+/*
+ * Tracepoint for kvm interrupt injection:
+ */
+TRACE_EVENT(kvm_inj_exception,
+ TP_PROTO(unsigned exception, bool has_error, unsigned error_code),
+ TP_ARGS(exception, has_error, error_code),
+
+ TP_STRUCT__entry(
+ __field(u8, exception )
+ __field(u8, has_error )
+ __field(u32,error_code )
+ ),
+
+ TP_fast_assign(
+ __entry-exception = exception;
+ __entry-has_error = has_error;
+ __entry-error_code = error_code;
+ ),
+
+ TP_printk(%s (0x%x),
+ __print_symbolic(__entry-exception, kvm_trace_sym_exc),
+ /* FIXME: don't print error_code if not present */
+ __entry-has_error ? __entry-error_code : 0)
+);
+
/*
* Tracepoint for page fault.
*/
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 66609f6..bcf52d1 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -4231,6 +4231,9 @@ static void inject_pending_event(struct kvm_vcpu *vcpu)
{
/* try to reinject previous events if any */
if (vcpu-arch.exception.pending) {
+ trace_kvm_inj_exception(vcpu-arch.exception.nr,
+ vcpu-arch.exception.has_error_code,
+ vcpu-arch.exception.error_code);
kvm_x86_ops-queue_exception(vcpu, vcpu-arch.exception.nr,
vcpu-arch.exception.has_error_code,
vcpu-arch.exception.error_code);
--
To unsubscribe from this list: send the line unsubscribe kvm-commits in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[COMMIT master] KVM: remove redundant initialization of page-private
From: Minchan Kim minchan@gmail.com The prep_new_page() in page allocator calls set_page_private(page, 0). So we don't need to reinitialize private of page. Signed-off-by: Minchan Kim minchan@gmail.com Cc: Avi Kivitya...@redhat.com Signed-off-by: Avi Kivity a...@redhat.com diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c index d0f5e11..b137515 100644 --- a/arch/x86/kvm/mmu.c +++ b/arch/x86/kvm/mmu.c @@ -325,7 +325,6 @@ static int mmu_topup_memory_cache_page(struct kvm_mmu_memory_cache *cache, page = alloc_page(GFP_KERNEL); if (!page) return -ENOMEM; - set_page_private(page, 0); cache-objects[cache-nobjs++] = page_address(page); } return 0; -- To unsubscribe from this list: send the line unsubscribe kvm-commits in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] x86/kvm: Show guest system/user cputime in cpustat
On Thu, 2010-03-11 at 17:17 +0800, Sheng Yang wrote:
On Thursday 11 March 2010 15:50:54 Avi Kivity wrote:
On 03/11/2010 09:46 AM, Sheng Yang wrote:
On Thursday 11 March 2010 15:36:01 Avi Kivity wrote:
On 03/11/2010 09:20 AM, Sheng Yang wrote:
Currently we can only get the cpu_stat of whole guest as one. This
patch enhanced cpu_stat with more detail, has guest_system and
guest_user cpu time statistics with a little overhead.
Signed-off-by: Sheng Yangsh...@linux.intel.com
---
This draft patch based on KVM upstream to show the idea. I would split
it into more kernel friendly version later.
The overhead is, the cost of get_cpl() after each exit from guest.
This can be very expensive in the nested virtualization case, so I
wouldn't like this to be in normal paths. I think detailed profiling
like that can be left to 'perf kvm', which only has overhead if enabled
at runtime.
Yes, that's my concern too(though nested vmcs/vmcb read already too
expensive, they should be optimized...).
Any ideas on how to do that? Perhaps use paravirt_ops to covert the
vmread into a memory read? We store the vmwrites in the vmcs anyway.
When Qing(CCed) was working on nested VMX in the past, he found PV
vmread/vmwrite indeed works well(it would write to the virtual vmcs so
vmwrite
can also benefit). Though compared to old machine(one our internal patch
shows
improve more than 5%), NHM get less benefit due to the reduced vmexit cost.
One of the hurdles to PVize vmread/vmwrite is the fact that the memory
layout of physical vmcs remains unknown. Of course it can use the custom
vmcs layout utilized by nested virtualization, but that looks a little weird,
since different nested virtualization implementation may create different
custom layout.
I once used another approach to partially accelerate the vmread/vmwrite
in nested virtualization case, which also gives good performance gain (around
7% on pre-nehalem, based on this, PV vmread/vmwrite had another 7%). That
is to make a shortcut to handle EXIT_REASON_VM{READ,WRITE}, without
even turning on the IF.
Thanks,
Qing
--
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] Re: Ideas wiki for GSoC 2010
On 03/11/2010 11:59 PM, Jamie Lokier wrote: Avi Kivity wrote: On 03/10/2010 11:30 PM, Luiz Capitulino wrote: 2. Do we have kvm-specific projects? Can they be part of the QEMU project or do we need a different mentoring organization for it? Something really interesting is kvm-assisted tcg. I'm afraid it's a bit too complicated to GSoC. Is this simpler: kvm-assisted user-mode emulation (no TCG involved)? Or running TCG-compiled code as a guest so that for example KVM takes care of the softmmu (with hardware-assisted paging possibly, yoohoo). But I have no idea if that is what Avi meant. :-) Paolo -- 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 -v3 1/2] KVM: introduce kvm_uninit_mmu_notifier()
We have kvm_init_mmu_notifier() for registering mmu notifier.
This patch makes the counterpart for unregister.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
virt/kvm/kvm_main.c | 16 +++-
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index e758ef7..64b792c 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -359,6 +359,11 @@ static int kvm_init_mmu_notifier(struct kvm *kvm)
return mmu_notifier_register(kvm-mmu_notifier, current-mm);
}
+static void kvm_uninit_mmu_notifier(struct kvm *kvm)
+{
+ mmu_notifier_unregister(kvm-mmu_notifier, kvm-mm);
+}
+
#else /* !(CONFIG_MMU_NOTIFIER KVM_ARCH_WANT_MMU_NOTIFIER) */
static int kvm_init_mmu_notifier(struct kvm *kvm)
@@ -366,6 +371,11 @@ static int kvm_init_mmu_notifier(struct kvm *kvm)
return 0;
}
+static void kvm_uninit_mmu_notifier(struct kvm *kvm)
+{
+ kvm_arch_flush_shadow(kvm);
+}
+
#endif /* CONFIG_MMU_NOTIFIER KVM_ARCH_WANT_MMU_NOTIFIER */
static struct kvm *kvm_create_vm(void)
@@ -485,11 +495,7 @@ static void kvm_destroy_vm(struct kvm *kvm)
for (i = 0; i KVM_NR_BUSES; i++)
kvm_io_bus_destroy(kvm-buses[i]);
kvm_coalesced_mmio_free(kvm);
-#if defined(CONFIG_MMU_NOTIFIER) defined(KVM_ARCH_WANT_MMU_NOTIFIER)
- mmu_notifier_unregister(kvm-mmu_notifier, kvm-mm);
-#else
- kvm_arch_flush_shadow(kvm);
-#endif
+ kvm_uninit_mmu_notifier(kvm);
kvm_arch_destroy_vm(kvm);
hardware_disable_all();
mmdrop(mm);
--
1.6.3.3
--
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] Re: Ideas wiki for GSoC 2010
On Fri, Mar 12, 2010 at 10:48:51AM +0100, Paolo Bonzini wrote: On 03/11/2010 11:59 PM, Jamie Lokier wrote: Avi Kivity wrote: On 03/10/2010 11:30 PM, Luiz Capitulino wrote: 2. Do we have kvm-specific projects? Can they be part of the QEMU project or do we need a different mentoring organization for it? Something really interesting is kvm-assisted tcg. I'm afraid it's a bit too complicated to GSoC. Is this simpler: kvm-assisted user-mode emulation (no TCG involved)? Or running TCG-compiled code as a guest so that for example KVM takes care of the softmmu (with hardware-assisted paging possibly, yoohoo). But I have no idea if that is what Avi meant. :-) I think it is. -- 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 -v3 1/2] KVM: introduce kvm_uninit_mmu_notifier()
I made this patch for the coalesced mmio's error handling work.
Though, I wanted to finish this work, I have no time this week any more.
I'll do the remaining part next week, sorry.
Takuya Yoshikawa wrote:
We have kvm_init_mmu_notifier() for registering mmu notifier.
This patch makes the counterpart for unregister.
Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp
---
virt/kvm/kvm_main.c | 16 +++-
1 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
index e758ef7..64b792c 100644
--- a/virt/kvm/kvm_main.c
+++ b/virt/kvm/kvm_main.c
@@ -359,6 +359,11 @@ static int kvm_init_mmu_notifier(struct kvm *kvm)
return mmu_notifier_register(kvm-mmu_notifier, current-mm);
}
+static void kvm_uninit_mmu_notifier(struct kvm *kvm)
+{
+ mmu_notifier_unregister(kvm-mmu_notifier, kvm-mm);
+}
+
#else /* !(CONFIG_MMU_NOTIFIER KVM_ARCH_WANT_MMU_NOTIFIER) */
static int kvm_init_mmu_notifier(struct kvm *kvm)
@@ -366,6 +371,11 @@ static int kvm_init_mmu_notifier(struct kvm *kvm)
return 0;
}
+static void kvm_uninit_mmu_notifier(struct kvm *kvm)
+{
+ kvm_arch_flush_shadow(kvm);
+}
+
#endif /* CONFIG_MMU_NOTIFIER KVM_ARCH_WANT_MMU_NOTIFIER */
static struct kvm *kvm_create_vm(void)
@@ -485,11 +495,7 @@ static void kvm_destroy_vm(struct kvm *kvm)
for (i = 0; i KVM_NR_BUSES; i++)
kvm_io_bus_destroy(kvm-buses[i]);
kvm_coalesced_mmio_free(kvm);
-#if defined(CONFIG_MMU_NOTIFIER) defined(KVM_ARCH_WANT_MMU_NOTIFIER)
- mmu_notifier_unregister(kvm-mmu_notifier, kvm-mm);
-#else
- kvm_arch_flush_shadow(kvm);
-#endif
+ kvm_uninit_mmu_notifier(kvm);
kvm_arch_destroy_vm(kvm);
hardware_disable_all();
mmdrop(mm);
--
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] Re: Ideas wiki for GSoC 2010
On 03/11/10 12:25, Alexander Graf wrote: The list is also still missing a lot of potential mentors for the listed ideas. Let me propose some here :) == Shared memory transport between guest(s) and host == Sounds like Avi would be a good fit. I'm pretty unknowledgeable when it comes to shm. Actually this one sounds a lot like SGI's XPMEM. Not sure if it would make sense to try and use that infrastructure for that, but it might be a good starting point Cheers, Jes -- 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: [Android-virt] Ideas wiki for GSoC 2010
On Thu, Mar 11, 2010 at 1:15 PM, Avi Kivity a...@redhat.com wrote: On 03/11/2010 02:03 PM, Alexander Graf wrote: Another idea I'd have would be upstream integration (and cleanup) of the ARM KVM port: https://wiki.ncl.cs.columbia.edu/wiki/index.php/AndroidVirt:MainPage Huh, didn't even know this thing existed. Definitely something to merge. I have been wanted to announce this work for some time, but always thought my patches were too unpolished. However, now is as good a time as any. In addition to the link provided by Alex, the sources can be viewed on http://git.ncl.cs.columbia.edu/git and I'm hoping to have something mature enough for upstream some time around the summer. I'm unsure how this relates to GSoC, but let me me know how I could/should be involved. -- error compiling committee.c: too many arguments to function ___ Android-virt mailing list android-v...@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/android-virt -- 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: Windows Driver for -vga std
erik.r...@rdsoftware.de wrote: Hi all, using the Default VGA settings Windows XP detects an unknown VGA Device, but everything is fine, Display settings are ok. But how can I setup my XP to detect this virtual graphics board correctly? I just want to continue using this setting but with no complaints in the system/hardware settings. In windows 2000 and before there was a driver for that, called Standard VGA adaptor or something like that. In XP it is used by default too, but XP thinks that it's not appropriate driver for _any_ hardware. So basically the driver is here but it's XP who dislikes it. /mjt -- 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: [Android-virt] Ideas wiki for GSoC 2010
On Fri, 12 Mar 2010 11:49:48 +0100 Christoffer Dall christofferd...@christofferdall.dk wrote: On Thu, Mar 11, 2010 at 1:15 PM, Avi Kivity a...@redhat.com wrote: On 03/11/2010 02:03 PM, Alexander Graf wrote: Another idea I'd have would be upstream integration (and cleanup) of the ARM KVM port: https://wiki.ncl.cs.columbia.edu/wiki/index.php/AndroidVirt:MainPage Huh, didn't even know this thing existed. Definitely something to merge. I have been wanted to announce this work for some time, but always thought my patches were too unpolished. However, now is as good a time as any. In addition to the link provided by Alex, the sources can be viewed on http://git.ncl.cs.columbia.edu/git and I'm hoping to have something mature enough for upstream some time around the summer. I'd send RFCs early, just to be sure everything is going in the right direction. It's okay to have unpolished code in RFCs. I'm unsure how this relates to GSoC, but let me me know how I could/should be involved. I'm not sure either, but doesn't seem a good project if it's only polishing. On the other hand, if there's anything missing that should be implemented you can be involved by suggesting the project and becoming the mentor for it. Here is our ideas page: http://wiki.qemu.org/Google_Summer_of_Code_2010 -- 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
BUG: soft lockup - CPU#1 stuck for 61s ! [qemu-kvm... (and server hang)
I was using kvm with much success, until I decided to enable radeon KMS on a multiseat station. After some time, machine just hanged (well, it was still replying to ping) and kernel said what I pasted below. Not sure if it's kvm to blame, or radeon KMS, or... [ 923.418469] BUG: soft lockup - CPU#1 stuck for 61s! [qemu-kvm:3442] [ 923.418471] Modules linked in: radeon ttm drm_kms_helper drm i2c_algo_bit tun bridge stp af_packet coretemp ipv6 binfmt_misc loop dm_mod cpufreq_ondemand cpufreq_conservative cpufreq_powersave acpi_cpufreq freq_table kvm_intel kvm snd_hda_codec_atihdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_pcm snd_timer snd_mixer_oss snd soundcore snd_page_alloc serio_raw e1000e pcspkr i2c_i801 joydev iTCO_wdt thermal i2c_core iTCO_vendor_support processor button evdev sr_mod wmi sg ata_piix ahci libata sd_mod scsi_mod crc_t10dif raid1 ext4 jbd2 crc16 uhci_hcd ohci_hcd ehci_hcd usbhid hid usbcore [last unloaded: scsi_wait_scan] [ 923.418501] CPU 1 [ 923.418504] Pid: 3442, comm: qemu-kvm Not tainted 2.6.33-desktop-1mnb #1 DX58SO/ [ 923.418505] RIP: 0010:[8108c412] [8108c412] generic_exec_single+0x82/0xb0 [ 923.418511] RSP: 0018:880237911a88 EFLAGS: 0202 [ 923.418512] RAX: 0010 RBX: 880237911ac8 RCX: 0020 [ 923.418514] RDX: 0020 RSI: 0020 RDI: 0296 [ 923.418515] RBP: 8100aa0e R08: 813cff98 R09: [ 923.418517] R10: R11: 0400 R12: 8107b02e [ 923.418518] R13: 880237911a88 R14: 0286 R15: 880237871710 [ 923.418520] FS: 7f0cb46fd710() GS:880008c2() knlGS: [ 923.418521] CS: 0010 DS: 002b ES: 002b CR0: 8005003b [ 923.418523] CR2: 7f09d8114870 CR3: 00023cd1 CR4: 26e0 [ 923.418524] DR0: DR1: DR2: [ 923.418526] DR3: DR6: 0ff0 DR7: 0400 [ 923.418528] Process qemu-kvm (pid: 3442, threadinfo 88023791, task 88023dfb4350) [ 923.418529] Stack: [ 923.418530] 880237911a98 880008c503a0 37911ab8 0002 [ 923.418532] 0 a0383eb0 0001 816c3548 880008c35780 [ 923.418534] 0 880237911b38 8108c642 00204fd0 00015780 [ 923.418537] Call Trace: [ 923.418542] [a0383eb0] ? __vcpu_clear+0x0/0xd0 [kvm_intel] [ 923.418545] [8108c642] ? smp_call_function_single+0x152/0x160 [ 923.418548] [a0383eb0] ? __vcpu_clear+0x0/0xd0 [kvm_intel] [ 923.418551] [a03851cb] ? vmx_vcpu_load+0x4b/0x180 [kvm_intel] [ 923.418562] [a032e89a] ? kvm_arch_vcpu_load+0x3a/0xa0 [kvm] [ 923.418567] [a0321af2] ? kvm_sched_in+0x12/0x20 [kvm] [ 923.418570] [81046c89] ? finish_task_switch+0x79/0xd0 [ 923.418573] [813b612f] ? schedule+0x3ef/0xac0 [ 923.418580] [a032cf58] ? kvm_set_rflags+0x38/0xa0 [kvm] [ 923.418588] [a03487c8] ? kvm_apic_has_interrupt+0x48/0x90 [kvm] [ 923.418594] [a0321ced] ? kvm_vcpu_block+0x6d/0xb0 [kvm] [ 923.418599] [81077000] ? autoremove_wake_function+0x0/0x40 [ 923.418607] [a0337647] ? kvm_arch_vcpu_ioctl_run+0x427/0xc50 [kvm] [ 923.418613] [a0324345] ? kvm_vcpu_ioctl+0x485/0x5d0 [kvm] [ 923.418616] [8107b02e] ? __hrtimer_start_range_ns+0x19e/0x470 [ 923.418619] [8113802d] ? vfs_ioctl+0x3d/0xd0 [ 923.418622] [811385ba] ? do_vfs_ioctl+0x8a/0x5a0 [ 923.418629] [a032d543] ? kvm_on_user_return+0x73/0x80 [kvm] [ 923.418631] [81138b51] ? sys_ioctl+0x81/0xa0 [ 923.418634] [8100a042] ? system_call_fastpath+0x16/0x1b [ 923.418636] Code: 8b 55 08 49 89 5d 08 4c 89 2b 48 89 53 08 48 89 1a e8 c3 c6 32 00 4c 3b 6d c8 74 2b 45 85 ff 75 0a eb 0e 66 0f 1f 44 00 00 f3 90 f6 43 20 01 75 f8 48 8b 5d d8 4c 8b 65 e0 4c 8b 6d e8 4c 8b 75 [ 923.418653] Call Trace: [ 923.418655] [8108c437] ? generic_exec_single+0xa7/0xb0 [ 923.418658] [a0383eb0] ? __vcpu_clear+0x0/0xd0 [kvm_intel] [ 923.418661] [8108c642] ? smp_call_function_single+0x152/0x160 [ 923.418664] [a0383eb0] ? __vcpu_clear+0x0/0xd0 [kvm_intel] [ 923.418666] [a03851cb] ? vmx_vcpu_load+0x4b/0x180 [kvm_intel] [ 923.418673] [a032e89a] ? kvm_arch_vcpu_load+0x3a/0xa0 [kvm] [ 923.418679] [a0321af2] ? kvm_sched_in+0x12/0x20 [kvm] [ 923.418681] [81046c89] ? finish_task_switch+0x79/0xd0 [ 923.418683] [813b612f] ? schedule+0x3ef/0xac0 [ 923.418690] [a032cf58] ? kvm_set_rflags+0x38/0xa0 [kvm] [ 923.418697] [a03487c8] ? kvm_apic_has_interrupt+0x48/0x90 [kvm] [ 923.418703] [a0321ced] ? kvm_vcpu_block+0x6d/0xb0
[PATCH v4 2/2] qemu-kvm: x86: Add support for savingrestoring debug registers
Corresponding support for qemu-kvm.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
qemu-kvm-x86.c|2 ++
qemu-kvm.c|5 +
qemu-kvm.h|1 +
target-i386/kvm.c |2 +-
4 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c
index 0160fe9..65a3cfc 100644
--- a/qemu-kvm-x86.c
+++ b/qemu-kvm-x86.c
@@ -1012,6 +1012,7 @@ void kvm_arch_load_regs(CPUState *env, int level)
}
kvm_put_vcpu_events(env, level);
+kvm_put_debugregs(env);
/* must be last */
kvm_guest_debug_workarounds(env);
@@ -1185,6 +1186,7 @@ void kvm_arch_save_regs(CPUState *env)
kvm_arch_save_mpstate(env);
kvm_save_lapic(env);
kvm_get_vcpu_events(env);
+kvm_get_debugregs(env);
}
static void do_cpuid_ent(struct kvm_cpuid_entry2 *e, uint32_t function,
diff --git a/qemu-kvm.c b/qemu-kvm.c
index e417f21..0e7d594 100644
--- a/qemu-kvm.c
+++ b/qemu-kvm.c
@@ -2115,6 +2115,11 @@ static int kvm_create_context(void)
kvm_state-vcpu_events = kvm_check_extension(kvm_state,
KVM_CAP_VCPU_EVENTS);
#endif
+kvm_state-debugregs = 0;
+#ifdef KVM_CAP_DEBUGREGS
+kvm_state-debugregs = kvm_check_extension(kvm_state, KVM_CAP_DEBUGREGS);
+#endif
+
kvm_init_ap();
if (kvm_irqchip) {
if (!qemu_kvm_has_gsi_routing()) {
diff --git a/qemu-kvm.h b/qemu-kvm.h
index f5db9e6..0cbc6f7 100644
--- a/qemu-kvm.h
+++ b/qemu-kvm.h
@@ -970,6 +970,7 @@ struct KVMState {
int migration_log;
int vcpu_events;
int robust_singlestep;
+int debugregs;
#ifdef KVM_CAP_SET_GUEST_DEBUG
QTAILQ_HEAD(, kvm_sw_breakpoint) kvm_sw_breakpoints;
#endif
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index b5c3c27..8d00774 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -902,7 +902,6 @@ static int kvm_guest_debug_workarounds(CPUState *env)
return ret;
}
-#ifdef KVM_UPSTREAM
static int kvm_put_debugregs(CPUState *env)
{
#ifdef KVM_CAP_DEBUGREGS
@@ -950,6 +949,7 @@ static int kvm_get_debugregs(CPUState *env)
return 0;
}
+#ifdef KVM_UPSTREAM
int kvm_arch_put_registers(CPUState *env, int level)
{
int ret;
--
1.6.0.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 v4 0/2] qemu-kvm: Saverestore debug registers
Patch 1 is for upstream and should be applied to uq/master as well, patch 2 is for qemu-kvm only. Jan Kiszka (2): KVM: x86: Add debug register saving and restoring qemu-kvm: x86: Add support for savingrestoring debug registers kvm-all.c | 11 ++ kvm.h |1 + qemu-kvm-x86.c|2 + qemu-kvm.c|5 qemu-kvm.h|1 + target-i386/kvm.c | 55 + 6 files changed, 75 insertions(+), 0 deletions(-) -- 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 v4 1/2] KVM: x86: Add debug register saving and restoring
Make use of the new KVM_GET/SET_DEBUGREGS to save/restore the x86 debug
registers.
Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
kvm-all.c | 11 ++
kvm.h |1 +
target-i386/kvm.c | 55 +
3 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/kvm-all.c b/kvm-all.c
index 8ca480d..c469b6a 100644
--- a/kvm-all.c
+++ b/kvm-all.c
@@ -67,6 +67,7 @@ struct KVMState
int migration_log;
int vcpu_events;
int robust_singlestep;
+int debugregs;
#ifdef KVM_CAP_SET_GUEST_DEBUG
struct kvm_sw_breakpoint_head kvm_sw_breakpoints;
#endif
@@ -676,6 +677,11 @@ int kvm_init(int smp_cpus)
kvm_check_extension(s, KVM_CAP_X86_ROBUST_SINGLESTEP);
#endif
+s-debugregs = 0;
+#ifdef KVM_CAP_DEBUGREGS
+s-debugregs = kvm_check_extension(s, KVM_CAP_DEBUGREGS);
+#endif
+
ret = kvm_arch_init(s, smp_cpus);
if (ret 0)
goto err;
@@ -955,6 +961,11 @@ int kvm_has_robust_singlestep(void)
return kvm_state-robust_singlestep;
}
+int kvm_has_debugregs(void)
+{
+return kvm_state-debugregs;
+}
+
void kvm_setup_guest_memory(void *start, size_t size)
{
if (!kvm_has_sync_mmu()) {
diff --git a/kvm.h b/kvm.h
index b0d07c8..c6faf20 100644
--- a/kvm.h
+++ b/kvm.h
@@ -44,6 +44,7 @@ int kvm_log_stop(target_phys_addr_t phys_addr, ram_addr_t
size);
int kvm_has_sync_mmu(void);
int kvm_has_vcpu_events(void);
int kvm_has_robust_singlestep(void);
+int kvm_has_debugregs(void);
void kvm_cpu_register_phys_memory_client(void);
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 123dcc8..b5c3c27 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -903,6 +903,53 @@ static int kvm_guest_debug_workarounds(CPUState *env)
}
#ifdef KVM_UPSTREAM
+static int kvm_put_debugregs(CPUState *env)
+{
+#ifdef KVM_CAP_DEBUGREGS
+struct kvm_debugregs dbgregs;
+int i;
+
+if (!kvm_has_debugregs()) {
+return 0;
+}
+
+for (i = 0; i 4; i++) {
+dbgregs.db[i] = env-dr[i];
+}
+dbgregs.dr6 = env-dr[6];
+dbgregs.dr7 = env-dr[7];
+dbgregs.flags = 0;
+
+return kvm_vcpu_ioctl(env, KVM_SET_DEBUGREGS, dbgregs);
+#else
+return 0;
+#endif
+}
+
+static int kvm_get_debugregs(CPUState *env)
+{
+#ifdef KVM_CAP_DEBUGREGS
+struct kvm_debugregs dbgregs;
+int i, ret;
+
+if (!kvm_has_debugregs()) {
+return 0;
+}
+
+ret = kvm_vcpu_ioctl(env, KVM_GET_DEBUGREGS, dbgregs);
+if (ret 0) {
+ return ret;
+}
+for (i = 0; i 4; i++) {
+env-dr[i] = dbgregs.db[i];
+}
+env-dr[4] = env-dr[6] = dbgregs.dr6;
+env-dr[5] = env-dr[7] = dbgregs.dr7;
+#endif
+
+return 0;
+}
+
int kvm_arch_put_registers(CPUState *env, int level)
{
int ret;
@@ -938,6 +985,10 @@ int kvm_arch_put_registers(CPUState *env, int level)
if (ret 0)
return ret;
+ret = kvm_put_debugregs(env);
+if (ret 0)
+return ret;
+
return 0;
}
@@ -969,6 +1020,10 @@ int kvm_arch_get_registers(CPUState *env)
if (ret 0)
return ret;
+ret = kvm_get_debugregs(env);
+if (ret 0)
+return ret;
+
return 0;
}
--
1.6.0.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
Re: PCI capabilities support for assigned devices
On Wed, Mar 10, 2010 at 02:52:30PM +0100, Sebastian Hetze wrote: Hi *, in qemu-kvm/hw/device-assignment.c assigned_device_pci_cap_init() appearently only PCI_CAP_ID_MSI and PCI_CAP_ID_MSIX are exposed to the guest. Linux Broadcom bnx2 and tg3 drivers expect PCI_CAP_ID_PM to be present. Are there any plans to implement this and possibly other PCI capability features for assigned devices? If not, is there a list of network cards known to work with PCI assignment in KVM? Answering my own mail, I can contribute experience with direct assignment of two network cards. I was able to test Intel 82571EB (e1000e) and 82575EB (igb). Both drivers work with IOMMU assigned devices in a SMP guest running 2.6.31-16-generic-pae ubuntu kernel with 4 CPUs. However, the e1000e driver hangs reproduceable on NFS load after 10 to 20 minutes [ 1312.989127] :00:05.0: eth0: Detected Tx Unit Hang: [ 1312.989130] TDH b8 [ 1312.989131] TDT f4 [ 1312.989132] next_to_use f4 [ 1312.989133] next_to_clean b5 [ 1312.989134] buffer_info[next_to_clean]: [ 1312.989135] time_stamp 3d3dc [ 1312.989136] next_to_watch b8 [ 1312.989137] jiffies 3dd3f [ 1312.989138] next_to_watch.status 0 [ 1313.988199] [ cut here ] [ 1313.988237] WARNING: at /build/buildd/linux-2.6.31/net/sched/sch_generic.c:246 dev_watchdog+0x1f6/0x210() [ 1313.988247] Hardware name: [ 1313.988249] NETDEV WATCHDOG: eth0 (e1000e): transmit queue 0 timed out [ 1313.988251] Modules linked in: ppdev lp parport autofs4 video output nfsd exportfs nfs lockd nfs_acl auth_rpcgss sunrpc e100 via_rhine 3c59x 8139too mii snd_ens1370 gameport snd_rawmidi snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc pcspkr psmouse virtio_net i2c_piix4 serio_raw joydev virtio_pci virtio_ring virtio usbhid floppy fbcon tileblit font bitblit softcursor e1000e [ 1313.988294] Pid: 0, comm: swapper Not tainted 2.6.31-16-generic-pae #53-Ubuntu [ 1313.988297] Call Trace: [ 1313.988323] [c0146a1d] warn_slowpath_common+0x6d/0xa0 [ 1313.988327] [c04b6746] ? dev_watchdog+0x1f6/0x210 [ 1313.988331] [c04b6746] ? dev_watchdog+0x1f6/0x210 [ 1313.988334] [c0146a96] warn_slowpath_fmt+0x26/0x30 [ 1313.988337] [c04b6746] dev_watchdog+0x1f6/0x210 [ 1313.988350] [c0159efb] ? insert_work+0x5b/0xa0 [ 1313.988361] [c0128098] ? default_spin_lock_flags+0x8/0x10 [ 1313.988375] [c0576bda] ? _spin_lock_irqsave+0x2a/0x40 [ 1313.988379] [c015a291] ? __queue_work+0x31/0x40 [ 1313.988383] [c01520d7] run_timer_softirq+0x117/0x200 [ 1313.988390] [c016c045] ? tick_dev_program_event+0x45/0xe0 [ 1313.988393] [c04b6550] ? dev_watchdog+0x0/0x210 [ 1313.988399] [c014cc40] __do_softirq+0x90/0x1a0 [ 1313.988402] [c0161e83] ? hrtimer_interrupt+0x183/0x210 [ 1313.988406] [c016c488] ? tick_do_update_jiffies64+0x118/0x160 [ 1313.988410] [c014cd8d] do_softirq+0x3d/0x40 [ 1313.988414] [c014cecd] irq_exit+0x5d/0x70 [ 1313.988425] [c011ddc7] smp_apic_timer_interrupt+0x57/0x90 [ 1313.988433] [c0103d71] apic_timer_interrupt+0x31/0x40 [ 1313.988437] [c0127365] ? native_safe_halt+0x5/0x10 [ 1313.988441] [c010a5b6] default_idle+0x46/0xd0 [ 1313.988444] [c010202c] cpu_idle+0x8c/0xd0 [ 1313.988454] [c0572498] start_secondary+0xc6/0xc8 [ 1313.988457] ---[ end trace c5b28b21ada19e1d ]--- I also tried the 1.1.2-NAPI driver from Intel without success. The 82575EB device works fine. To get an impression of the performance improvement you win from an directly assigned NIC, take a look at the following numbers taken from sysstat in a real live production system. Both tables show the same guest on two subsequent days with similar every day workloads. virtio-net 00:00:01 IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s 06:05:01 eth0 577,01582,57 141,83 211,79 0,000,000,00 06:15:01 eth0 169,70181,93 70,04 90,490,000,000,00 06:25:01 eth0 135,22138,81 60,94 56,010,000,000,00 06:35:01 eth0 787,44879,40 183,05 498,02 0,000,000,00 06:45:01 eth0 1430,22 1660,49 323,80 1163,14 0,000,000,00 06:55:01 eth0 1524,15 1730,98 400,70 1112,32 0,000,000,00 07:05:02 eth0 1300,95 1414,48 307,40 741,41 0,000,000,00 07:15:01 eth0 380,77435,28 141,65 289,76 0,000,000,00 07:25:01 eth0 312,16365,33 112,46 230,35 0,000,000,00 07:35:01 eth0 758,51801,66 169,99 375,84 0,000,000,00 07:45:01 eth0 1685,90 1922,92 301,87 1408,62 0,000,000,00 07:55:02 eth0 2531,08 3205,48 579,60 3033,27 0,000,000,00 08:05:02 eth0 2011,90 2180,31 426,22 1041,64 0,000,000,00 08:15:01 eth0 1054,10 1252,39 267,30 648,87 0,000,000,00 08:25:02 eth0 613,17761,34 170,96 551,79 0,000,000,00 08:35:02 eth0 858,47921,50 205,33 440,02 0,000,000,00 08:45:02 eth0 1426,27 1465,96 336,28 635,85 0,000,000,00 08:55:02 eth0 1539,78 1600,87 361,98 716,52 0,000,000,00 09:05:01
Re: [Qemu-devel] Ideas wiki for GSoC 2010
Hi Luiz. Around the time when I introduced the new Asynchronous monitor command API we had talked about converting all commands to use this new API so that we can cut down on duplicate code paths and confusing code. I would like to propose this as a GSoC project idea. Do you think it should stand as its own project or should we merge it into your Convert Monitor commands to the QObject API project? -- Thanks, Adam -- 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] Ideas wiki for GSoC 2010
On Fri, 12 Mar 2010 09:11:31 -0600 Adam Litke a...@us.ibm.com wrote: Hi Luiz. Around the time when I introduced the new Asynchronous monitor command API we had talked about converting all commands to use this new API so that we can cut down on duplicate code paths and confusing code. I would like to propose this as a GSoC project idea. Do you think it should stand as its own project or should we merge it into your Convert Monitor commands to the QObject API project? I think it's a project by itself, but I wonder if it's too easy/short for GSoC. An experienced programmer can do the conversion plus testing in a day or two. There are probably a number of cleanups and adaptions that can take more, but still seems too short. -- 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] Ideas wiki for GSoC 2010
On Fri, 2010-03-12 at 12:22 -0300, Luiz Capitulino wrote: On Fri, 12 Mar 2010 09:11:31 -0600 Adam Litke a...@us.ibm.com wrote: Hi Luiz. Around the time when I introduced the new Asynchronous monitor command API we had talked about converting all commands to use this new API so that we can cut down on duplicate code paths and confusing code. I would like to propose this as a GSoC project idea. Do you think it should stand as its own project or should we merge it into your Convert Monitor commands to the QObject API project? I think it's a project by itself, but I wonder if it's too easy/short for GSoC. An experienced programmer can do the conversion plus testing in a day or two. There are probably a number of cleanups and adaptions that can take more, but still seems too short. So given the relatively small scope of this additional work, maybe it should be an additional stretch goal to be added to your project. Once the student(s) have gone through the trouble to familiarize themselves with the monitor code, they would be well-positioned to complete this extra bit. How difficult do you imagine it will be to convert the remaining commands over to QObject? -- Thanks, Adam -- 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: ioeventfd usage in KVM
On Fri, Mar 12, 2010 at 12:43 AM, Avi Kivity a...@redhat.com wrote: On 03/12/2010 07:08 AM, Cam Macdonell wrote: + s-ivshmem_mmio_io_addr = cpu_register_io_memory(ivshmem_mmio_read, + ivshmem_mmio_write, s); + /* region for registers*/ + pci_register_bar(d-dev, 0, 0x100, + PCI_BASE_ADDRESS_SPACE_MEMORY, ivshmem_mmio_map); You've selected the memory address space here. my basic attempt looks like this: struct kvm_ioeventfd ked; ked.addr = s-otheraddr + Doorbell; ked.len = 4; ked.flags = KVM_IOEVENTFD_FLAG_PIO; ked.fd = an_eventfd; ret = kvm_vm_ioctl(kvm_state, KVM_IOEVENTFD,ked); But the PIO address space here. but when the guest writes to the offset of Doorbell, I cannot see any action (via a select on the fd). Is there something obviously wrong that I'm doing? Yes - they must match. Not PIO is faster on x86 but nonexistant elsewhere. Does it matter that PIO is slower since with ioeventfd Qemu is being bypassed all together? Can I use the memory space with ioeventfds? There doesn't seem to be a flag (KVM_IOEVENTFD_FLAG_MMIO) for it. Cam -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- 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] Ideas wiki for GSoC 2010
On Fri, 12 Mar 2010 09:38:47 -0600 Adam Litke a...@us.ibm.com wrote: On Fri, 2010-03-12 at 12:22 -0300, Luiz Capitulino wrote: On Fri, 12 Mar 2010 09:11:31 -0600 Adam Litke a...@us.ibm.com wrote: Hi Luiz. Around the time when I introduced the new Asynchronous monitor command API we had talked about converting all commands to use this new API so that we can cut down on duplicate code paths and confusing code. I would like to propose this as a GSoC project idea. Do you think it should stand as its own project or should we merge it into your Convert Monitor commands to the QObject API project? I think it's a project by itself, but I wonder if it's too easy/short for GSoC. An experienced programmer can do the conversion plus testing in a day or two. There are probably a number of cleanups and adaptions that can take more, but still seems too short. So given the relatively small scope of this additional work, maybe it should be an additional stretch goal to be added to your project. It could be, our we could try to come up with something additional. Once the student(s) have gone through the trouble to familiarize themselves with the monitor code, they would be well-positioned to complete this extra bit. How difficult do you imagine it will be to convert the remaining commands over to QObject? Well, I won't set the goal to convert all of them, because seems too much work and Anthony has said that we may not want all the handlers available under QMP. So, this has to be discussed (preferably before GSoC starts for students). Also, I have two other projects that could related to the async conversion: - Simplify/Improve the QObject API - Improve error handling (QError conversion involved) -- 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] Ideas wiki for GSoC 2010
On 03/12/2010 09:56 AM, Luiz Capitulino wrote: Once the student(s) have gone through the trouble to familiarize themselves with the monitor code, they would be well-positioned to complete this extra bit. How difficult do you imagine it will be to convert the remaining commands over to QObject? Well, I won't set the goal to convert all of them, because seems too much work and Anthony has said that we may not want all the handlers available under QMP. So, this has to be discussed (preferably before GSoC starts for students). What I would like to see is a clean break between the human monitor and QMP whereas the human monitor is implemented in terms of QMP. For instance, the x and xp commands are not very useful for QMP. However, a generic memory read/write API would be pretty useful. The x/xp commands would be implemented in terms of the memory QMP API. Likewise, the sum command can be implemented in terms of the above API. Regards, Anthony Liguori Also, I have two other projects that could related to the async conversion: - Simplify/Improve the QObject API - Improve error handling (QError conversion involved) -- 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: ioeventfd usage in KVM
On 03/12/2010 05:50 PM, Cam Macdonell wrote: Yes - they must match. Not PIO is faster on x86 but nonexistant elsewhere. s/Not/Note/. Does it matter that PIO is slower since with ioeventfd Qemu is being bypassed all together? mmio is slower in kvm, not qemu; mmio must go through the emulator, fetch the instruction, decode and execute it, while pio decoding is done by the processor microcode. Can I use the memory space with ioeventfds? Yes. There doesn't seem to be a flag (KVM_IOEVENTFD_FLAG_MMIO) for it. If you don't specify _PIO, _MMIO is the default, as Documentation/kvm/api.txt doesn't say. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. -- 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] Ideas wiki for GSoC 2010
On Fri, 12 Mar 2010 10:36:53 -0600 Anthony Liguori aligu...@linux.vnet.ibm.com wrote: On 03/12/2010 09:56 AM, Luiz Capitulino wrote: Once the student(s) have gone through the trouble to familiarize themselves with the monitor code, they would be well-positioned to complete this extra bit. How difficult do you imagine it will be to convert the remaining commands over to QObject? Well, I won't set the goal to convert all of them, because seems too much work and Anthony has said that we may not want all the handlers available under QMP. So, this has to be discussed (preferably before GSoC starts for students). What I would like to see is a clean break between the human monitor and QMP whereas the human monitor is implemented in terms of QMP. For instance, the x and xp commands are not very useful for QMP. However, a generic memory read/write API would be pretty useful. The x/xp commands would be implemented in terms of the memory QMP API. Likewise, the sum command can be implemented in terms of the above API. Right, makes sense. So, we need to convert them all but maybe not make all of them available under QMP. -- 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: Question on stopping KVM start at boot
On Wed, Mar 10, 2010 at 9:59 PM, sati...@pacific.net.hk wrote: $ cat /etc/init.d/qemu-kvm | grep modprobe if modprobe $module . if modprobe $module then log_end_msg 0 else log_end_msg 1 exit 1 fi ;; Where shall I add -b option? Thanks modprobe -b says respect the blacklists. See: * http://manpages.ubuntu.com/manpages/lucid/en/man8/modprobe.8.html -b --use-blacklist This option causes modprobe to apply the blacklist commands in the configuration files (if any) to module names as well. It is usually used by udev(7). So you would change the lines that say if modprobe ... to if modprobe -b ... :-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: [Qemu-devel] Re: Ideas wiki for GSoC 2010
IMO one of the biggest parts of infrastructure QEMU is missing for embedded stuff is a common (qdev) way of modeling DMA backchannels. Or devide to device channels or whatever you want to call it. Would be nice if someone could bring this to qemu. Cheers -- 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: clean up assigned_device_enable_host_msix
From: Jing Zhang zj.ba...@gmail.com Date: Sat Mar 13 14:05:27 2010 Cc: Avi Kivity a...@redhat.com Signed-off-by: Jing Zhang zj.ba...@gmail.com --- --- a/virt/kvm/assigned-dev.c 2010-03-02 20:10:18.0 +0800 +++ b/virt/kvm/assigned-dev.c 2010-03-02 20:26:18.0 +0800 @@ -315,12 +315,16 @@ static int assigned_device_enable_host_m kvm_assigned_dev_intr, 0, kvm_assigned_msix_device, (void *)dev); -/* FIXME: free requested_irq's on failure */ if (r) -return r; +goto err; } return 0; +err: + for (i -= 1; i = 0; i--) + free_irq(dev-host_msix_entries[i].vector, (void *)dev); + pci_disable_msix(dev-dev); + return r; } #endif -- 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
