From mboxrd@z Thu Jan 1 00:00:00 1970 From: Suravee Suthikulpanit Subject: Re: [PART1 RFC 0/9] KVM: x86: Introduce SVM AVIC support Date: Sat, 13 Feb 2016 02:55:03 +0700 Message-ID: <56BE3897.5060507@amd.com> References: <1455285574-27892-1-git-send-email-suravee.suthikulpanit@amd.com> <56BE20CF.8030708@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: , , , To: Paolo Bonzini , , , Return-path: In-Reply-To: <56BE20CF.8030708@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org Hi, On 2/13/16 01:13, Paolo Bonzini wrote: > I have a few questions about AVIC. > > On 12/02/2016 14:59, Suravee Suthikulpanit wrote: >> CURRENT UNSUPPORT USE-CASES >> =========================== >> - Nested VM >> - VM Migration > > I'm interested in what you mean with "VM migration". I've noticed that, > because x2APIC is disabled by default, it's possible that a VM on a > non-AVIC host will fail when moved to an AVIC host. I would prefer if > you kept x2APIC working through VMEXITs. Getting the full performance > benefit would require disabling x2APIC of course (or waiting for > improved support in the processor), but at least there would be no surprise. > > Is it just this, or is there anything else? For VM Migration, I meant the process of taking a snapshot of the VM and later on loading it back to resume where it left off, and not necessary to a different type of system. This would require saving off the VAPIC backing page of each vCPU along with the rest of per-VM AVIC data structures. IIUC, this might require changes in the QEmu as well. Moving VM non-AVIC host to AVIC host, and vice versa, would be tricky. I also see you points about supporting x2APIC. Let me look more into it, and then get back to you on this. > > (I'm quite surprised that x2APIC is not supported. MSRs are faster than > memory accesses due to the cost of TLB misses, which can be hefty for VMs). > > I have a few other doubts about the architecture that hopefully you (or > Wei Huang too) can clarify before I can review this patch meaningfully. > I have replied to other patches with these questions. > > Paolo > I'll go through those and get back to you separately. Regards, Suravee