From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757411AbcBDOBP (ORCPT ); Thu, 4 Feb 2016 09:01:15 -0500 Received: from aserp1040.oracle.com ([141.146.126.69]:39865 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752396AbcBDOBO (ORCPT ); Thu, 4 Feb 2016 09:01:14 -0500 Subject: Re: [Xen-devel] [PATCH v2 08/11] xen/hvmlite: Extend APIC operations for HVMlite guests To: =?UTF-8?Q?Roger_Pau_Monn=c3=a9?= , David Vrabel , konrad.wilk@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> Cc: xen-devel@lists.xenproject.org, mcgrof@suse.com, linux-kernel@vger.kernel.org From: Boris Ostrovsky Message-ID: <56B359A5.40202@oracle.com> Date: Thu, 4 Feb 2016 09:01:09 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <56B340B4.3050406@citrix.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/04/2016 07:14 AM, Roger Pau Monné 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