[PATCH v4 0/3] KVM: perf: kvm events analysis tool

2012-02-09 Thread Xiao Guangrong
Changlog: There are some changes from David Ahern's review: - let the tool to be off-box analysis by getting cpu isa from HEADER_CPUID feature and removing max-vcpu related code. - attach per vcpu record structure to the thread by adding a void pointer in struct thread. - remove unnecessary

[PATCH 1/3] KVM: x86: export svm/vmx exit code and vector code to userspace

2012-02-09 Thread Xiao Guangrong
They will be needed by 'perf kvm-events' Signed-off-by: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com --- arch/x86/include/asm/kvm_host.h | 36 --- arch/x86/include/asm/svm.h | 205 +-- arch/x86/include/asm/vmx.h | 125

[PATCH 2/3] KVM: x86: add tracepoints to trace mmio begin and complete

2012-02-09 Thread Xiao Guangrong
'perf kvm-events' will use kvm_exit and kvm_mmio(read...) to calculate mmio read emulated time for the old kernel, in order to trace mmio read event more exactly, we add kvm_mmio_begin to trace the time when mmio read begins Also, add kvm_mmio_done to trace the time when mmio/pio is completed

[PATCH 3/3] KVM: perf: kvm events analysis tool

2012-02-09 Thread Xiao Guangrong
Add 'perf kvm-events' support to analyze kvm vmexit/mmio/ioport smartly Usage: - trace kvm events: perf kvm-events record, or, if other tracepoints are also interesting, we can append the events like this: perf kvm-events record -e timer:* - show the result: perf

Re: Pe: [PATCH v5 1/3] virtio-scsi: first version

2012-02-09 Thread Paolo Bonzini
On 02/08/2012 02:37 PM, Christian Hoff wrote: Again, I have already done much testing with virtio-scsi and can confirm that the code is working flawlessly. In my opinion, virtio-scsi is a worthwhile addition to virtio-block and should be considered for inclusion into mainline kernel code.

KVM Memory overcomittment vs VMware

2012-02-09 Thread Jonathan Petersson
Hi all, I've emailed about some related issues lately with some good feedback. About a year ago we decided to migrate off VMware to KVM. With some mixed result we're fairly happy but we're somewhat stuck as far as RAM utilization is concerned. We've managed to gain some RAM space with KSM and

Re: [PATCH 1/3] Device isolation group infrastructure (v3)

2012-02-09 Thread Joerg Roedel
On Thu, Feb 09, 2012 at 08:39:28AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2012-02-08 at 16:27 +0100, Joerg Roedel wrote: Again, device grouping is done by the IOMMU drivers, so this all belongs into the generic iommu-code rather than the driver core. Except that there isn't really

Re: Pe: [PATCH v5 1/3] virtio-scsi: first version

2012-02-09 Thread Christian Hoff
Paolo Bonzini wrote: James, will you include virtio-scsi in 3.4? The key arguments from my side for inclusion of virtio-scsi are: - Support for SCSI multipathing, which can optionally be done on the host operating system. - We can now use other SCSI(non-block) devices and make them accessible

Re: x86: kvmclock: abstract save/restore sched_clock_state

2012-02-09 Thread Amit Shah
On (Tue) 07 Feb 2012 [19:05:42], Marcelo Tosatti wrote: Upon resume from hibernation, CPU 0's hvclock area contains the old values for system_time and tsc_timestamp. It is necessary for the hypervisor to update these values with uptodate ones before the CPU uses them. Abstract TSC's

Re: [PATCH] kvm tool: rewrite kvm__init

2012-02-09 Thread Pekka Enberg
On Thu, Feb 9, 2012 at 7:40 AM, Yang Bai hamo...@gmail.com wrote: Since the different issues have been handled in the internal of kvm__init, it can only return NULL if error happened. Signed-off-by: Yang Bai hamo...@gmail.com Sorry, I don't understand what this patch is attempting to fix?

Re: [PATCH] kvm tool: rewrite kvm__init

2012-02-09 Thread Cyrill Gorcunov
On Thu, Feb 09, 2012 at 03:01:26PM +0200, Pekka Enberg wrote: On Thu, Feb 9, 2012 at 7:40 AM, Yang Bai hamo...@gmail.com wrote: Since the different issues have been handled in the internal of kvm__init, it can only return NULL if error happened. Signed-off-by: Yang Bai hamo...@gmail.com

Re: [RFC] need to improve slot creation/destruction? -- Re: [RFC][PATCH] srcu: Implement call_srcu()

2012-02-09 Thread Takuya Yoshikawa
On Wed, 8 Feb 2012 16:45:31 -0200 Marcelo Tosatti mtosa...@redhat.com wrote: For 3: I think doing both write protection and shadow flush is unnecessary. If you enable dirty logging on a slot, certainly you have to write protect? When we enable dirty logging, yes. BTW do we really

Re: [PATCH for 3.3] KVM: Fix write protection race during dirty logging

2012-02-09 Thread Takuya Yoshikawa
On Wed, 8 Feb 2012 14:38:07 -0200 Marcelo Tosatti mtosa...@redhat.com wrote: Please don't forget the invalidate_page fix. I will send in a few days. Takuya -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More

Re: [RFC] need to improve slot creation/destruction? -- Re: [RFC][PATCH] srcu: Implement call_srcu()

2012-02-09 Thread Avi Kivity
On 02/08/2012 05:43 PM, Takuya Yoshikawa wrote: [Dropped non-kvm members from cc] Marcelo Tosatti mtosa...@redhat.com wrote: VGABIOS mode constantly destroys and creates 0xa slot, so performance is required for KVM_SET_MEM too (it can probably be fixed in qemu, but older qemu's must

Re: [RFC] need to improve slot creation/destruction? -- Re: [RFC][PATCH] srcu: Implement call_srcu()

2012-02-09 Thread Avi Kivity
On 02/09/2012 04:23 PM, Avi Kivity wrote: BTW do we really need fast slot creation/destruction? Not really, but it's good to have infrastructure that copes with different workloads. If the patches keep the code simple I think it's a good thing to have. To qualify - taking several tens of

Re: [RFC] need to improve slot creation/destruction? -- Re: [RFC][PATCH] srcu: Implement call_srcu()

2012-02-09 Thread Avi Kivity
On 02/08/2012 08:45 PM, Marcelo Tosatti wrote: BTW do we really need fast slot creation/destruction? At the moment yes. Boot a RHEL/Fedora installation disk (or any other guest which uses SYSLINUX splash screen) and you will see. Another workload that suffers is Windows XP clearing the

Re: [patch 7/8] Dont mark TSC unstable due to S4 suspend

2012-02-09 Thread Joerg Roedel
On Wed, Feb 08, 2012 at 01:56:46PM -0200, Marcelo Tosatti wrote: On Wed, Feb 08, 2012 at 04:18:48PM +0100, Joerg Roedel wrote: This is not going to work when tsc-scaling is enabled. The adjust_tsc_offset_host() function just scales the offset the same way the tsc is scaled. But that is

Re: x86: kvmclock: abstract save/restore sched_clock_state

2012-02-09 Thread Igor Mammedov
On 02/09/2012 01:27 PM, Amit Shah wrote: On (Tue) 07 Feb 2012 [19:05:42], Marcelo Tosatti wrote: Upon resume from hibernation, CPU 0's hvclock area contains the old values for system_time and tsc_timestamp. It is necessary for the hypervisor to update these values with uptodate ones before the

Re: [PATCH 3/6] kvmvapic: Introduce TPR access optimization for Windows guests

2012-02-09 Thread Avi Kivity
On 02/05/2012 02:39 PM, Jan Kiszka wrote: From: Jan Kiszka jan.kis...@siemens.com This enables acceleration for MMIO-based TPR registers accesses of 32-bit Windows guest systems. It is mostly useful with KVM enabled, either on older Intel CPUs (without flexpriority feature, can also be

Re: [PATCH 3/6] kvmvapic: Introduce TPR access optimization for Windows guests

2012-02-09 Thread Jan Kiszka
On 2012-02-09 16:18, Avi Kivity wrote: On 02/05/2012 02:39 PM, Jan Kiszka wrote: From: Jan Kiszka jan.kis...@siemens.com This enables acceleration for MMIO-based TPR registers accesses of 32-bit Windows guest systems. It is mostly useful with KVM enabled, either on older Intel CPUs (without

Re: [PATCH 3/6] kvmvapic: Introduce TPR access optimization for Windows guests

2012-02-09 Thread Avi Kivity
On 02/09/2012 05:39 PM, Jan Kiszka wrote: On 2012-02-09 16:18, Avi Kivity wrote: On 02/05/2012 02:39 PM, Jan Kiszka wrote: From: Jan Kiszka jan.kis...@siemens.com This enables acceleration for MMIO-based TPR registers accesses of 32-bit Windows guest systems. It is mostly useful with

Re: [PATCH 0/9] pci-assign: 64bit MMIO + better MSI-X table support

2012-02-09 Thread Shashidhar Patil
Hi Alex, I tested your code changes for two problems 1. MSIX vectors allocation for FreeBSD Guest Tested the allocation of MSI-X allocation happening for both FreeBSD-9.0 (also tested 8.2) and Linux guest. Also tried multiple restart of the guests to see if the hosts still maintains

Re: [PATCH 3/6] kvmvapic: Introduce TPR access optimization for Windows guests

2012-02-09 Thread Jan Kiszka
On 2012-02-09 17:00, Avi Kivity wrote: On 02/09/2012 05:39 PM, Jan Kiszka wrote: On 2012-02-09 16:18, Avi Kivity wrote: On 02/05/2012 02:39 PM, Jan Kiszka wrote: From: Jan Kiszka jan.kis...@siemens.com This enables acceleration for MMIO-based TPR registers accesses of 32-bit Windows guest

Re: [PATCH 3/6] kvmvapic: Introduce TPR access optimization for Windows guests

2012-02-09 Thread Avi Kivity
On 02/09/2012 06:32 PM, Jan Kiszka wrote: We need to patch the causing instruction, so we have to know where it starts. Or what do you mean? Just don't deal with this at all, no one runs on kernels without kernel irqchip. Not true for upstream, It was introduced in 2.6.24? Is

Re: [PATCH 3/6] kvmvapic: Introduce TPR access optimization for Windows guests

2012-02-09 Thread Paolo Bonzini
On 02/09/2012 05:32 PM, Jan Kiszka wrote: I mean just check kpcr.self. Yes, clear, but that means that Windows must have initialized FS.base to point to the KPCR also in UP mode. Is that really the case? E.g. when ACPI is off?! I wonder if that explains the reported bug of qemu-kvm with

Re: [PATCH 0/9] pci-assign: 64bit MMIO + better MSI-X table support

2012-02-09 Thread Alex Williamson
On Thu, 2012-02-09 at 21:53 +0530, Shashidhar Patil wrote: Hi Alex, I tested your code changes for two problems 1. MSIX vectors allocation for FreeBSD Guest Tested the allocation of MSI-X allocation happening for both FreeBSD-9.0 (also tested 8.2) and Linux guest. Also tried

Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

2012-02-09 Thread John Fastabend
On 2/8/2012 8:36 PM, Stephen Hemminger wrote: On Wed, 08 Feb 2012 19:22:06 -0800 John Fastabend john.r.fastab...@intel.com wrote: Propagate software FDB table into hardware uc, mc lists when the NETIF_F_HW_FDB is set. This resolves the case below where an embedded switch is used in

Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

2012-02-09 Thread Stephen Hemminger
On Thu, 09 Feb 2012 09:36:47 -0800 John Fastabend john.r.fastab...@intel.com wrote: But the device features makes it easy for user space to learn that the device supports this sort of offload. Now if all SR-IOV devices support this then it doesn't matter but I thought there were SR-IOV devices

Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

2012-02-09 Thread John Fastabend
On 2/9/2012 9:40 AM, Stephen Hemminger wrote: On Thu, 09 Feb 2012 09:36:47 -0800 John Fastabend john.r.fastab...@intel.com wrote: But the device features makes it easy for user space to learn that the device supports this sort of offload. Now if all SR-IOV devices support this then it

Re: [PATCH 3/6] kvmvapic: Introduce TPR access optimization for Windows guests

2012-02-09 Thread Jan Kiszka
On 2012-02-09 18:20, Paolo Bonzini wrote: On 02/09/2012 05:32 PM, Jan Kiszka wrote: I mean just check kpcr.self. Yes, clear, but that means that Windows must have initialized FS.base to point to the KPCR also in UP mode. Is that really the case? E.g. when ACPI is off?! I wonder if that

Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

2012-02-09 Thread Sridhar Samudrala
On Wed, 2012-02-08 at 19:22 -0800, John Fastabend wrote: Propagate software FDB table into hardware uc, mc lists when the NETIF_F_HW_FDB is set. This resolves the case below where an embedded switch is used in hardware to do inter-VF or VF-PF switching. This patch pushes the FDB entry

qemu-kvm-1.0 crashes with threaded vnc server?

2012-02-09 Thread Peter Lieven
Hi, is anyone aware if there are still problems when enabling the threaded vnc server? I saw some VMs crashing when using a qemu-kvm build with --enable-vnc-thread. qemu-kvm-1.0[22646]: segfault at 0 ip 7fec1ca7ea0b sp 7fec19d056d0 error 6 in libz.so.1.2.3.3[7fec1ca75000+16000]

qemu-kvm-1.0 regression with usb tablet after live migration

2012-02-09 Thread Peter Lieven
Hi, i recently started updating our VMs to qemu-kvm 1.0. Since that I see that the usb tablet device (used for as pointer device for accurate mouse positioning) becomes unavailable after live migrating. If I migrate a few times a Windows 7 VM reliable stops using the USB tablet and fails back

Re: WARNING: at arch/x86/kernel/smp.c:119 native_smp_send_reschedule+0x25/0x43()

2012-02-09 Thread Sasha Levin
On Wed, Feb 8, 2012 at 7:59 PM, Josh Boyer jwbo...@gmail.com wrote: On Wed, Feb 8, 2012 at 8:31 PM, Sasha Levin levinsasha...@gmail.com wrote: Hi all, I got the following warning when shutting down a KVM guest with a whole bunch of cores (254 in this case). It's actually pretty easy to

Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

2012-02-09 Thread John Fastabend
On 2/9/2012 10:14 AM, Sridhar Samudrala wrote: On Wed, 2012-02-08 at 19:22 -0800, John Fastabend wrote: Propagate software FDB table into hardware uc, mc lists when the NETIF_F_HW_FDB is set. This resolves the case below where an embedded switch is used in hardware to do inter-VF or VF-PF

[PATCH] KVM: Cleanup the kvm_print functions and introduce pr_XX wrappers

2012-02-09 Thread Christoffer Dall
From: Christoffer Dall c.d...@virtualopensystems.com Introduces a couple of print functions, which are essentially wrappers around standard printk functions, with a KVM: prefix. Functions introduced or modified are: - kvm_err(fmt, ...) - kvm_info(fmt, ...) - kvm_debug(fmt, ...) -

Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

2012-02-09 Thread jamal
On Thu, 2012-02-09 at 09:52 -0800, John Fastabend wrote: By netlink_notifier do you mean adding a notifier_block and using atomic_notifier_call_chain() probably in rtnl_notify()? Then drivers could register with the notifier chain with atomic_notifier_chain_register() and receive the

Re: [Qemu-devel] KVM call agenda for tuesday 31

2012-02-09 Thread Peter Maydell
Ping re the VMState and variable sized arrays issue. I don't see any consensus in this discussion for a different approach, so should we just commit Mitsyanko's patchset? - PMM On 31 January 2012 13:15, Andreas Färber afaer...@suse.de wrote: Am 31.01.2012 00:53, schrieb Anthony Liguori: On

[PATCH v3] KVM: Factor out kvm_vcpu_kick to arch-generic code

2012-02-09 Thread Christoffer Dall
From: Christoffer Dall c.d...@virtualopensystems.com The kvm_vcpu_kick function performs roughly the same funcitonality on most all architectures, so we shouldn't have separate copies. PowerPC keeps a pointer to interchanging waitqueues on the vcpu_arch structure and to accomodate this special

Re: [Qemu-devel] KVM call agenda for tuesday 31

2012-02-09 Thread Anthony Liguori
On 02/09/2012 04:23 PM, Peter Maydell wrote: Ping re the VMState and variable sized arrays issue. I don't see any consensus in this discussion for a different approach, so should we just commit Mitsyanko's patchset? I don't know if I mentioned this, but do we really need variable sizes? Can

Re: [Qemu-devel] KVM call agenda for tuesday 31

2012-02-09 Thread Peter Maydell
On 9 February 2012 22:37, Anthony Liguori anth...@codemonkey.ws wrote: I don't know if I mentioned this, but do we really need variable sizes? Can we just use a fixed size (pre-allocated) array and then use a VMSTATE_SUB_ARRAY? If it's truly variable size with no upper bound, then that's

Re: [Android-virt] [PATCH v3] KVM: Factor out kvm_vcpu_kick to arch-generic code

2012-02-09 Thread Alexander Graf
On 09.02.2012, at 23:33, Christoffer Dall wrote: From: Christoffer Dall c.d...@virtualopensystems.com The kvm_vcpu_kick function performs roughly the same funcitonality on most all architectures, so we shouldn't have separate copies. PowerPC keeps a pointer to interchanging waitqueues on

Re: [Android-virt] [PATCH] Fix Cross-compiling with KVM support for ARM

2012-02-09 Thread Alexander Graf
On 10.02.2012, at 00:11, Christoffer Dall wrote: sorry about missing reply-all before On Thu, Feb 9, 2012 at 3:07 PM, Alexander Graf ag...@suse.de wrote: On 10.02.2012, at 00:04, Christoffer Dall wrote: becuase KVM_CAP_IRQ_ROUTING is only defined when __KVM_HAVE_IOAPIC. kvm/arm does not

Re: [Qemu-devel] KVM call agenda for tuesday 31

2012-02-09 Thread Andreas Färber
Am 09.02.2012 23:37, schrieb Anthony Liguori: On 02/09/2012 04:23 PM, Peter Maydell wrote: Ping re the VMState and variable sized arrays issue. I don't see any consensus in this discussion for a different approach, so should we just commit Mitsyanko's patchset? I don't know if I mentioned

Re: [Android-virt] [PATCH v3] KVM: Factor out kvm_vcpu_kick to arch-generic code

2012-02-09 Thread Christoffer Dall
On Thu, Feb 9, 2012 at 3:02 PM, Alexander Graf ag...@suse.de wrote: On 09.02.2012, at 23:33, Christoffer Dall wrote: From: Christoffer Dall c.d...@virtualopensystems.com The kvm_vcpu_kick function performs roughly the same funcitonality on most all architectures, so we shouldn't have

Re: [Qemu-devel] KVM call agenda for tuesday 31

2012-02-09 Thread Alexander Graf
On 10.02.2012, at 00:17, Andreas Färber wrote: Am 09.02.2012 23:37, schrieb Anthony Liguori: On 02/09/2012 04:23 PM, Peter Maydell wrote: Ping re the VMState and variable sized arrays issue. I don't see any consensus in this discussion for a different approach, so should we just commit

Re: [Android-virt] [PATCH v3] KVM: Factor out kvm_vcpu_kick to arch-generic code

2012-02-09 Thread Alexander Graf
On 10.02.2012, at 00:18, Christoffer Dall wrote: On Thu, Feb 9, 2012 at 3:02 PM, Alexander Graf ag...@suse.de wrote: On 09.02.2012, at 23:33, Christoffer Dall wrote: From: Christoffer Dall c.d...@virtualopensystems.com The kvm_vcpu_kick function performs roughly the same funcitonality

Re: [Android-virt] [PATCH v3] KVM: Factor out kvm_vcpu_kick to arch-generic code

2012-02-09 Thread Scott Wood
On 02/09/2012 05:23 PM, Alexander Graf wrote: How about we return 1 for kvm_arch_vcpu_in_guest_mode() on !x86 always, just like it's done today basically? Then we can worry about needless IPIs later and don't regress from the respective current kick implementations. And perhaps call the

Re: [Android-virt] [PATCH v3] KVM: Factor out kvm_vcpu_kick to arch-generic code

2012-02-09 Thread Alexander Graf
On 10.02.2012, at 00:43, Scott Wood wrote: On 02/09/2012 05:23 PM, Alexander Graf wrote: How about we return 1 for kvm_arch_vcpu_in_guest_mode() on !x86 always, just like it's done today basically? Then we can worry about needless IPIs later and don't regress from the respective current

Re: [PATCH 1/3] Device isolation group infrastructure (v3)

2012-02-09 Thread David Gibson
On Thu, Feb 09, 2012 at 12:28:05PM +0100, Joerg Roedel wrote: On Thu, Feb 09, 2012 at 08:39:28AM +1100, Benjamin Herrenschmidt wrote: On Wed, 2012-02-08 at 16:27 +0100, Joerg Roedel wrote: Again, device grouping is done by the IOMMU drivers, so this all belongs into the generic

Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

2012-02-09 Thread Sridhar Samudrala
On Thu, 2012-02-09 at 12:30 -0800, John Fastabend wrote: On 2/9/2012 10:14 AM, Sridhar Samudrala wrote: On Wed, 2012-02-08 at 19:22 -0800, John Fastabend wrote: Propagate software FDB table into hardware uc, mc lists when the NETIF_F_HW_FDB is set. This resolves the case below where an

Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

2012-02-09 Thread John Fastabend
On 2/9/2012 4:39 PM, Sridhar Samudrala wrote: On Thu, 2012-02-09 at 12:30 -0800, John Fastabend wrote: On 2/9/2012 10:14 AM, Sridhar Samudrala wrote: On Wed, 2012-02-08 at 19:22 -0800, John Fastabend wrote: Propagate software FDB table into hardware uc, mc lists when the NETIF_F_HW_FDB is

Re: [Android-virt] [PATCH RFC 2/2] ARM: KVM: Add support for MMU notifiers

2012-02-09 Thread Alexander Graf
On 10.02.2012, at 02:13, Marc Zyngier wrote: Add the necessary infrastructure to handle MMU notifiers on KVM/ARM. As we don't have shadow page tables, the implementation is actually very simple. The only supported operation is kvm_unmap_hva(), where we remove the HVA from the 2nd stage

[PATCH RFC 2/2] ARM: KVM: Add support for MMU notifiers

2012-02-09 Thread Marc Zyngier
Add the necessary infrastructure to handle MMU notifiers on KVM/ARM. As we don't have shadow page tables, the implementation is actually very simple. The only supported operation is kvm_unmap_hva(), where we remove the HVA from the 2nd stage translation. All other hooks are NOPs. Signed-off-by:

[PATCH RFC 1/2] KVM: Guard mmu_notifier specific code with CONFIG_MMU_NOTIFIER

2012-02-09 Thread Marc Zyngier
In order to avoid compilation failure when KVM is not compiled in, guard the mmu_notifier specific sections with both CONFIG_MMU_NOTIFIER and KVM_ARCH_WANT_MMU_NOTIFIER, like it is being done in the rest of the KVM code. Signed-off-by: Marc Zyngier marc.zyng...@arm.com ---

[PATCH v4] KVM: Factor out kvm_vcpu_kick to arch-generic code

2012-02-09 Thread Christoffer Dall
The kvm_vcpu_kick function performs roughly the same funcitonality on most all architectures, so we shouldn't have separate copies. PowerPC keeps a pointer to interchanging waitqueues on the vcpu_arch structure and to accomodate this special need a __KVM_HAVE_ARCH_VCPU_GET_WQ define and

Re: [PATCH v4] KVM: Factor out kvm_vcpu_kick to arch-generic code

2012-02-09 Thread Alexander Graf
On 10.02.2012, at 02:40, Christoffer Dall wrote: The kvm_vcpu_kick function performs roughly the same funcitonality on most all architectures, so we shouldn't have separate copies. PowerPC keeps a pointer to interchanging waitqueues on the vcpu_arch structure and to accomodate this special

Re: [PATCH v4] KVM: Factor out kvm_vcpu_kick to arch-generic code

2012-02-09 Thread Christoffer Dall
@@ -601,6 +591,7 @@ int kvm_vcpu_ioctl_interrupt(struct kvm_vcpu *vcpu, struct kvm_interrupt *irq)       }       kvmppc_core_queue_external(vcpu, irq); + Apart from this little glitch the patch looks fine to me. But I'd like to have Scott and Paul ack it too. damn, can't believe that

Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

2012-02-09 Thread John Fastabend
On 2/9/2012 1:11 PM, jamal wrote: On Thu, 2012-02-09 at 09:52 -0800, John Fastabend wrote: By netlink_notifier do you mean adding a notifier_block and using atomic_notifier_call_chain() probably in rtnl_notify()? Then drivers could register with the notifier chain with

Re: [PATCH] kvm tool: rewrite kvm__init

2012-02-09 Thread Yang Bai
On Thu, Feb 9, 2012 at 9:07 PM, Cyrill Gorcunov gorcu...@openvz.org wrote: On Thu, Feb 09, 2012 at 03:01:26PM +0200, Pekka Enberg wrote: On Thu, Feb 9, 2012 at 7:40 AM, Yang Bai hamo...@gmail.com wrote: Since the different issues have been handled in the internal of kvm__init, it can only

Re: [PATCH] kvm tool: rewrite kvm__init

2012-02-09 Thread Sasha Levin
On Fri, 2012-02-10 at 10:34 +0800, Yang Bai wrote: On Thu, Feb 9, 2012 at 9:07 PM, Cyrill Gorcunov gorcu...@openvz.org wrote: On Thu, Feb 09, 2012 at 03:01:26PM +0200, Pekka Enberg wrote: On Thu, Feb 9, 2012 at 7:40 AM, Yang Bai hamo...@gmail.com wrote: Since the different issues have been

Re: [PATCH] kvm tool: rewrite kvm__init

2012-02-09 Thread Yang Bai
On Fri, Feb 10, 2012 at 12:53 PM, Sasha Levin levinsasha...@gmail.com wrote: On Fri, 2012-02-10 at 10:34 +0800, Yang Bai wrote: On Thu, Feb 9, 2012 at 9:07 PM, Cyrill Gorcunov gorcu...@openvz.org wrote: On Thu, Feb 09, 2012 at 03:01:26PM +0200, Pekka Enberg wrote: On Thu, Feb 9, 2012 at 7:40

Re: [Qemu-devel] [RFC] Next gen kvm api

2012-02-09 Thread Jamie Lokier
Anthony Liguori wrote: The new API will do away with the IOAPIC/PIC/PIT emulation and defer them to userspace. I'm a big fan of this. I agree with getting rid of unnecessary emulations. (Why were those things emulated in the first place?) But it would be good to retain some way to plugin

Re: [RFC PATCH v0 1/2] net: bridge: propagate FDB table into hardware

2012-02-09 Thread John Fastabend
On 2/9/2012 6:14 PM, John Fastabend wrote: On 2/9/2012 1:11 PM, jamal wrote: On Thu, 2012-02-09 at 09:52 -0800, John Fastabend wrote: By netlink_notifier do you mean adding a notifier_block and using atomic_notifier_call_chain() probably in rtnl_notify()? Then drivers could register with

Re: [PATCH] kvm tool: rewrite kvm__init

2012-02-09 Thread Sasha Levin
On Fri, 2012-02-10 at 11:03 +0800, Yang Bai wrote: On Fri, Feb 10, 2012 at 12:53 PM, Sasha Levin levinsasha...@gmail.com wrote: On Fri, 2012-02-10 at 10:34 +0800, Yang Bai wrote: On Thu, Feb 9, 2012 at 9:07 PM, Cyrill Gorcunov gorcu...@openvz.org wrote: On Thu, Feb 09, 2012 at

Re: [PATCH] kvm tool: rewrite kvm__init

2012-02-09 Thread Yang Bai
On Fri, Feb 10, 2012 at 12:17 PM, Sasha Levin levinsasha...@gmail.com wrote: On Fri, 2012-02-10 at 11:03 +0800, Yang Bai wrote: On Fri, Feb 10, 2012 at 12:53 PM, Sasha Levin levinsasha...@gmail.com wrote: On Fri, 2012-02-10 at 10:34 +0800, Yang Bai wrote: On Thu, Feb 9, 2012 at 9:07 PM,

[PATCH 05/60] powerpc: remove the second argument of k[un]map_atomic()

2012-02-09 Thread Cong Wang
Signed-off-by: Cong Wang amw...@redhat.com --- arch/powerpc/kvm/book3s_pr.c |4 ++-- arch/powerpc/mm/dma-noncoherent.c |5 ++--- arch/powerpc/mm/hugetlbpage.c |4 ++-- arch/powerpc/mm/mem.c |4 ++-- 4 files changed, 8 insertions(+), 9 deletions(-) diff --git

[PATCH 08/60] x86: remove the second argument of k[un]map_atomic()

2012-02-09 Thread Cong Wang
Acked-by: Avi Kivity a...@redhat.com Acked-by: Herbert Xu herb...@gondor.apana.org.au Signed-off-by: Cong Wang amw...@redhat.com --- arch/x86/crypto/aesni-intel_glue.c | 24 arch/x86/kernel/crash_dump_32.c|6 +++--- arch/x86/kvm/lapic.c |8

[PATCH 26/60] vhost: remove the second argument of k[un]map_atomic()

2012-02-09 Thread Cong Wang
Signed-off-by: Cong Wang amw...@redhat.com --- drivers/vhost/vhost.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index c14c42b..bdb2d64 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -937,9 +937,9 @@

[PATCH 1/2] KVM: mmu_notifier: Flush TLBs before releasing mmu_lock

2012-02-09 Thread Takuya Yoshikawa
Other threads may process the same page in that small window and skip TLB flush and then return before these functions do flush. Signed-off-by: Takuya Yoshikawa yoshikawa.tak...@oss.ntt.co.jp --- virt/kvm/kvm_main.c | 19 ++- 1 files changed, 10 insertions(+), 9 deletions(-)

[PATCH 2/2] KVM: MMU: Flush TLBs only once in invlpg() before releasing mmu_lock

2012-02-09 Thread Takuya Yoshikawa
This function's TLB flush was moved sometimes in the past: 1. commit 4539b35881ae9664b0e2953438dd83f5ee02c0b4 KVM: Fix missing smp tlb flush in invlpg inserted it in the critical section. 2. commit 505aef8f30a95f7e4abf2c07e54ded1521587ba0 KVM: MMU: cleanup FNAME(invlpg) moved it inside

[PATCH 0/4] support to migrate with IPv6 address

2012-02-09 Thread Amos Kong
Those four patches make migration of IPv6 address work. Use getaddrinfo() to socket addresses infomation. --- Amos Kong (4): Use getaddrinfo for migration net/socket: allow ipv6 for net_socket_listen_init and socket_connect_init net: split hostname and service by last colon

[PATCH 1/4] Use getaddrinfo for migration

2012-02-09 Thread Amos Kong
This allows us to use ipv4/ipv6 for migration addresses. Once there, it also uses /etc/services names (it came free). Signed-off-by: Juan Quintela quint...@redhat.com Signed-off-by: Amos Kong ak...@redhat.com --- migration-tcp.c | 60 --- net.c | 108

[PATCH 2/4] net/socket: allow ipv6 for net_socket_listen_init and socket_connect_init

2012-02-09 Thread Amos Kong
Remove use of parse_host_port. More SO_SOCKADDR changes. Signed-off-by: Juan Quintela quint...@redhat.com Signed-off-by: Amos Kong ak...@redhat.com --- net/socket.c | 60 +++--- 1 files changed, 11 insertions(+), 49 deletions(-) diff --git

[PATCH 3/4] net: split hostname and service by last colon

2012-02-09 Thread Amos Kong
IPv6 address contains colons, parse will be wrong. [2312::8274]:5200 Signed-off-by: Amos Kong ak...@redhat.com --- net.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net.c b/net.c index f63014c..9e1ef9e 100644 --- a/net.c +++ b/net.c @@ -84,7 +84,7 @@ static int

[PATCH 4/4] net: support to include ipv6 address by brackets

2012-02-09 Thread Amos Kong
That method of representing an IPv6 address with a port is discouraged because of its ambiguity. Referencing to RFC5952, the recommended format is: [2312::8274]:5200 test status: Successed listen side: qemu-kvm -incoming tcp:[2312::8274]:5200 client side: qemu-kvm ...

Re: [PATCH 2/2] KVM: MMU: Flush TLBs only once in invlpg() before releasing mmu_lock

2012-02-09 Thread Xiao Guangrong
On 02/10/2012 02:29 PM, Takuya Yoshikawa wrote: diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h index 1561028..69d06f5 100644 --- a/arch/x86/kvm/paging_tmpl.h +++ b/arch/x86/kvm/paging_tmpl.h @@ -682,6 +682,7 @@ static void FNAME(invlpg)(struct kvm_vcpu *vcpu, gva_t

Re: [PATCH 2/2] KVM: MMU: Flush TLBs only once in invlpg() before releasing mmu_lock

2012-02-09 Thread Takuya Yoshikawa
(2012/02/10 15:55), Xiao Guangrong wrote: On 02/10/2012 02:29 PM, Takuya Yoshikawa wrote: diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h index 1561028..69d06f5 100644 --- a/arch/x86/kvm/paging_tmpl.h +++ b/arch/x86/kvm/paging_tmpl.h @@ -682,6 +682,7 @@ static void

Re: [PATCH 2/2] KVM: MMU: Flush TLBs only once in invlpg() before releasing mmu_lock

2012-02-09 Thread Xiao Guangrong
On 02/10/2012 03:21 PM, Takuya Yoshikawa wrote: (2012/02/10 15:55), Xiao Guangrong wrote: On 02/10/2012 02:29 PM, Takuya Yoshikawa wrote: diff --git a/arch/x86/kvm/paging_tmpl.h b/arch/x86/kvm/paging_tmpl.h index 1561028..69d06f5 100644 --- a/arch/x86/kvm/paging_tmpl.h +++

Re: [PATCH 1/2] KVM: mmu_notifier: Flush TLBs before releasing mmu_lock

2012-02-09 Thread Xiao Guangrong
On 02/10/2012 02:28 PM, Takuya Yoshikawa wrote: Other threads may process the same page in that small window and skip TLB flush and then return before these functions do flush. It is possible that flush tlb in mmu lock only when writeable spte is invalided? Sometimes, kvm_flush_remote_tlbs

[PATCH v3] KVM: Factor out kvm_vcpu_kick to arch-generic code

2012-02-09 Thread Christoffer Dall
From: Christoffer Dall c.d...@virtualopensystems.com The kvm_vcpu_kick function performs roughly the same funcitonality on most all architectures, so we shouldn't have separate copies. PowerPC keeps a pointer to interchanging waitqueues on the vcpu_arch structure and to accomodate this special

Re: [Android-virt] [PATCH v3] KVM: Factor out kvm_vcpu_kick to arch-generic code

2012-02-09 Thread Alexander Graf
On 09.02.2012, at 23:33, Christoffer Dall wrote: From: Christoffer Dall c.d...@virtualopensystems.com The kvm_vcpu_kick function performs roughly the same funcitonality on most all architectures, so we shouldn't have separate copies. PowerPC keeps a pointer to interchanging waitqueues on

Re: [Android-virt] [PATCH v3] KVM: Factor out kvm_vcpu_kick to arch-generic code

2012-02-09 Thread Christoffer Dall
On Thu, Feb 9, 2012 at 3:02 PM, Alexander Graf ag...@suse.de wrote: On 09.02.2012, at 23:33, Christoffer Dall wrote: From: Christoffer Dall c.d...@virtualopensystems.com The kvm_vcpu_kick function performs roughly the same funcitonality on most all architectures, so we shouldn't have

Re: [Android-virt] [PATCH v3] KVM: Factor out kvm_vcpu_kick to arch-generic code

2012-02-09 Thread Alexander Graf
On 10.02.2012, at 00:18, Christoffer Dall wrote: On Thu, Feb 9, 2012 at 3:02 PM, Alexander Graf ag...@suse.de wrote: On 09.02.2012, at 23:33, Christoffer Dall wrote: From: Christoffer Dall c.d...@virtualopensystems.com The kvm_vcpu_kick function performs roughly the same funcitonality

Re: [Android-virt] [PATCH v3] KVM: Factor out kvm_vcpu_kick to arch-generic code

2012-02-09 Thread Scott Wood
On 02/09/2012 05:23 PM, Alexander Graf wrote: How about we return 1 for kvm_arch_vcpu_in_guest_mode() on !x86 always, just like it's done today basically? Then we can worry about needless IPIs later and don't regress from the respective current kick implementations. And perhaps call the

[PATCH v4] KVM: Factor out kvm_vcpu_kick to arch-generic code

2012-02-09 Thread Christoffer Dall
The kvm_vcpu_kick function performs roughly the same funcitonality on most all architectures, so we shouldn't have separate copies. PowerPC keeps a pointer to interchanging waitqueues on the vcpu_arch structure and to accomodate this special need a __KVM_HAVE_ARCH_VCPU_GET_WQ define and

Re: [PATCH v4] KVM: Factor out kvm_vcpu_kick to arch-generic code

2012-02-09 Thread Alexander Graf
On 10.02.2012, at 02:40, Christoffer Dall wrote: The kvm_vcpu_kick function performs roughly the same funcitonality on most all architectures, so we shouldn't have separate copies. PowerPC keeps a pointer to interchanging waitqueues on the vcpu_arch structure and to accomodate this special

[PATCH 05/60] powerpc: remove the second argument of k[un]map_atomic()

2012-02-09 Thread Cong Wang
Signed-off-by: Cong Wang amw...@redhat.com --- arch/powerpc/kvm/book3s_pr.c |4 ++-- arch/powerpc/mm/dma-noncoherent.c |5 ++--- arch/powerpc/mm/hugetlbpage.c |4 ++-- arch/powerpc/mm/mem.c |4 ++-- 4 files changed, 8 insertions(+), 9 deletions(-) diff --git