From mboxrd@z Thu Jan 1 00:00:00 1970 From: Boris Ostrovsky Subject: Re: [PATCH v2 08/11] xen/hvmlite: Extend APIC operations for HVMlite guests Date: Thu, 4 Feb 2016 09:01:09 -0500 Message-ID: <56B359A5.40202__14948.3134541244$1454594553$gmane$org@oracle.com> References: <1454341137-14110-1-git-send-email-boris.ostrovsky@oracle.com> <1454341137-14110-9-git-send-email-boris.ostrovsky@oracle.com> <56B32220.4040505@citrix.com> <56B340B4.3050406@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aRKTA-0000IO-KR for xen-devel@lists.xenproject.org; Thu, 04 Feb 2016 14:01:12 +0000 In-Reply-To: <56B340B4.3050406@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , David Vrabel , konrad.wilk@oracle.com Cc: xen-devel@lists.xenproject.org, mcgrof@suse.com, linux-kernel@vger.kernel.org List-Id: xen-devel@lists.xenproject.org On 02/04/2016 07:14 AM, Roger Pau Monn=E9 wrote: > El 4/2/16 a les 11:04, David Vrabel ha escrit: >> On 01/02/16 15:38, Boris Ostrovsky wrote: >>> HVMlite guests need to be viewed as having APIC, otherwise smpboot code, >>> for example, will complain. >> I think we should consider always giving HVMlite guests an emulated >> APIC. I think this eliminates one of the biggest differences between >> HVMlite and native/KVM guests and will reduce the risk of future >> breakage in this area. > Right, I'm not opposed to that, but I think we should keep the hypercall > interface in order to bring up vCPUs. IMHO it's useful for unikernels > for example (do those support SMP?), and in general allows for > easier/faster CPU-bringup as compared to bare metal. As I mentioned in another reply, we can manage without emulated apic by = slightly extending PV APIC. However, it is rather fragile and I think = not having to do this would be a great improvement from code reliability = POV. And with Intel's vAPIC (and AMD's equivalent eventually, I suppose) = we should get performance improvement as well. What was the reason for not providing it? ACPI? > > Then if we indeed decide to provide and emulated lapic, should we also > at least provide the ACPI MADT table in order to enumerate them? This brings another question that I was going to ask. In the NVDIMM = thread there is a discussion about where to implement ACPI tables and I = think people are leaning toward doing in it qemu. With HVMlite we can = only (??) implement MADT (and whatever we add later) in the toolstack = and so we will have 3 places (qemu, hvmloader, toolstack) that build = ACPI tables. Can we have all this done in one place? Perhaps keep this code as a library? -boris