Re: [kvm-unit-tests PATCH] x86: hyperv_synic: Hyper-V SynIC test

2015-11-02 Thread Roman Kagan
t; > > Signed-off-by: Andrey Smetanin <asmeta...@virtuozzo.com> > > Reviewed-by: Roman Kagan <rka...@virtuozzo.com> > > Signed-off-by: Denis V. Lunev <d...@openvz.org> > > CC: Vitaly Kuznetsov <vkuzn...@redhat.com> > > CC: "K. Y. Srinivasan&qu

Re: [PATCH 9/9] kvm/x86: Hyper-V kvm exit

2015-10-16 Thread Roman Kagan
On Fri, Oct 16, 2015 at 09:51:58AM +0200, Paolo Bonzini wrote: > The documentation should include the definition of the struct and the > definition of the subtypes (currently KVM_EXIT_HYPERV_SYNIC only). > > Documentation for KVM_CAP_HYPERV_SINIC and KVM_IRQ_ROUTING_HV_SINT is > missing, too. >

Re: [PATCH 1/2] kvm/x86: Hyper-V synthetic interrupt controller

2015-10-12 Thread Roman Kagan
On Fri, Oct 09, 2015 at 04:42:33PM +0200, Paolo Bonzini wrote: > You need to add SYNIC vectors to the EOI exit bitmap, so that APICv > (Xeon E5 or higher, Ivy Bridge or newer) is handled correctly. You also > need to check the auto EOI exit bitmap in __apic_accept_irq, and avoid > going through

Re: [PATCH 1/2] kvm/x86: Hyper-V synthetic interrupt controller

2015-10-12 Thread Roman Kagan
On Mon, Oct 12, 2015 at 10:58:36AM +0200, Paolo Bonzini wrote: > On 12/10/2015 10:48, Cornelia Huck wrote: > > Going back to Paolo's original question, I think changing the check > > to !KVM_IRQ_ROUTING_IRQCHIP makes sense, if I understand the code > > correctly. They seem to be the only special

Re: [PATCH 2/2] kvm/x86: Hyper-V kvm exit

2015-10-12 Thread Roman Kagan
On Fri, Oct 09, 2015 at 04:41:15PM +0200, Paolo Bonzini wrote: > On 09/10/2015 15:39, Denis V. Lunev wrote: > > A new vcpu exit is introduced to notify the userspace of the > > changes in Hyper-V synic configuraion triggered by guest writing to the > > corresponding MSRs. > > Why is this exit

Re: [Qemu-devel] [PATCH 2/2] kvm/x86: Hyper-V kvm exit

2015-10-12 Thread Roman Kagan
On Mon, Oct 12, 2015 at 07:42:42AM -0600, Eric Blake wrote: > On 10/09/2015 07:39 AM, Denis V. Lunev wrote: > > From: Andrey Smetanin > > > > A new vcpu exit is introduced to notify the userspace of the > > changes in Hyper-V synic configuraion triggered by guest writing

Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization

2016-03-09 Thread Roman Kagan
On Wed, Mar 09, 2016 at 05:41:39PM +0200, Michael S. Tsirkin wrote: > On Wed, Mar 09, 2016 at 05:28:54PM +0300, Roman Kagan wrote: > > For (1) I've been trying to make a point that skipping clean pages is > > much more likely to result in noticable benefit than free pages only. &g

Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization

2016-03-10 Thread Roman Kagan
On Wed, Mar 09, 2016 at 07:39:18PM +0200, Michael S. Tsirkin wrote: > On Wed, Mar 09, 2016 at 08:04:39PM +0300, Roman Kagan wrote: > > On Wed, Mar 09, 2016 at 05:41:39PM +0200, Michael S. Tsirkin wrote: > > > On Wed, Mar 09, 2016 at 05:28:54PM +0300, Roman Kagan wrote: > &g

Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization

2016-03-10 Thread Roman Kagan
On Wed, Mar 09, 2016 at 02:38:52PM -0500, Rik van Riel wrote: > On Wed, 2016-03-09 at 20:04 +0300, Roman Kagan wrote: > > On Wed, Mar 09, 2016 at 05:41:39PM +0200, Michael S. Tsirkin wrote: > > > On Wed, Mar 09, 2016 at 05:28:54PM +0300, Roman Kagan wrote: > > > > Fo

Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization

2016-03-09 Thread Roman Kagan
On Fri, Mar 04, 2016 at 06:51:21PM +, Dr. David Alan Gilbert wrote: > * Paolo Bonzini (pbonz...@redhat.com) wrote: > > > > > > On 04/03/2016 15:26, Li, Liang Z wrote: > > >> > > > >> > The memory usage will keep increasing due to ever growing caches, etc, > > >> > so > > >> > you'll be

Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization

2016-03-09 Thread Roman Kagan
On Mon, Mar 07, 2016 at 01:40:06PM +0200, Michael S. Tsirkin wrote: > On Mon, Mar 07, 2016 at 06:49:19AM +, Li, Liang Z wrote: > > > > No. And it's exactly what I mean. The ballooned memory is still > > > > processed during live migration without skipping. The live migration > > > > code is >

Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization

2016-03-04 Thread Roman Kagan
On Fri, Mar 04, 2016 at 01:52:53AM +, Li, Liang Z wrote: > > I wonder if it would be possible to avoid the kernel changes by parsing > > /proc/self/pagemap - if that can be used to detect unmapped/zero mapped > > pages in the guest ram, would it achieve the same result? > > Only detect the

Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization

2016-03-04 Thread Roman Kagan
On Fri, Mar 04, 2016 at 08:23:09AM +, Li, Liang Z wrote: > > On Thu, Mar 03, 2016 at 05:46:15PM +, Dr. David Alan Gilbert wrote: > > > * Liang Li (liang.z...@intel.com) wrote: > > > > The current QEMU live migration implementation mark the all the > > > > guest's RAM pages as dirtied in

Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization

2016-03-03 Thread Roman Kagan
On Thu, Mar 03, 2016 at 05:46:15PM +, Dr. David Alan Gilbert wrote: > * Liang Li (liang.z...@intel.com) wrote: > > The current QEMU live migration implementation mark the all the > > guest's RAM pages as dirtied in the ram bulk stage, all these pages > > will be processed and that takes quit a

Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization

2016-03-04 Thread Roman Kagan
On Fri, Mar 04, 2016 at 09:08:20AM +, Dr. David Alan Gilbert wrote: > * Roman Kagan (rka...@virtuozzo.com) wrote: > > On Fri, Mar 04, 2016 at 08:23:09AM +, Li, Liang Z wrote: > > > The unmapped/zero mapped pages can be detected by parsing > > > /proc/self/pagema

Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization

2016-03-04 Thread Roman Kagan
On Fri, Mar 04, 2016 at 09:08:44AM +, Li, Liang Z wrote: > > On Fri, Mar 04, 2016 at 01:52:53AM +, Li, Liang Z wrote: > > > > I wonder if it would be possible to avoid the kernel changes by > > > > parsing /proc/self/pagemap - if that can be used to detect > > > > unmapped/zero mapped

Re: [Qemu-devel] [RFC qemu 0/4] A PV solution for live migration optimization

2016-03-03 Thread Roman Kagan
On Thu, Mar 03, 2016 at 06:44:24PM +0800, Liang Li wrote: > The current QEMU live migration implementation mark the all the > guest's RAM pages as dirtied in the ram bulk stage, all these pages > will be processed and that takes quit a lot of CPU cycles. > > From guest's point of view, it doesn't