From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752620AbbKPVEt (ORCPT ); Mon, 16 Nov 2015 16:04:49 -0500 Received: from mail-ob0-f171.google.com ([209.85.214.171]:34309 "EHLO mail-ob0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751824AbbKPVEs (ORCPT ); Mon, 16 Nov 2015 16:04:48 -0500 MIME-Version: 1.0 In-Reply-To: <20151116210314.GA10307@char.us.oracle.com> References: <56468D24.8030801@oracle.com> <564A0371.2040104@oracle.com> <20151116195906.GB20137@pd.tnic> <20151116202232.GC20137@pd.tnic> <564A4125.8000603@oracle.com> <20151116210314.GA10307@char.us.oracle.com> From: Andy Lutomirski Date: Mon, 16 Nov 2015 13:04:28 -0800 Message-ID: Subject: Re: [PATCH] xen/x86: Adjust stack pointer in xen_sysexit To: Konrad Rzeszutek Wilk Cc: Joao Martins , Boris Ostrovsky , Borislav Petkov , "H. Peter Anvin" , "linux-kernel@vger.kernel.org" , xen-devel , David Vrabel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 16, 2015 at 1:03 PM, Konrad Rzeszutek Wilk wrote: > On Mon, Nov 16, 2015 at 12:50:19PM -0800, Andy Lutomirski wrote: >> On Mon, Nov 16, 2015 at 12:48 PM, Boris Ostrovsky >> wrote: >> > On 11/16/2015 03:22 PM, Borislav Petkov wrote: >> >> >> >> On Mon, Nov 16, 2015 at 12:11:11PM -0800, Andy Lutomirski wrote: >> >> >> >>> Are there really multiple feature bits for this stuff? I'd like to >> >>> imagine that the entry code is all either Xen PV or native/PVH/PVHVM >> >>> -- i.e. I assumed that PVH works like native for all entries. >> > >> > >> > >> > Almost. For PVH we will have a small stub to set up bootparams and such but >> > then we jump to startup_{32|64} code. >> > >> > >> >> I just reacted to Boris' statement: >> >> >> >> "We don't currently have a Xen-specific CPU feature. We could, in >> >> principle, add it but we can't replace all of current paravirt patching >> >> with a single feature since PVH guests use a subset of existing pv ops >> >> (and in the future it may become even more fine-grained)." >> > >> > >> > Actually, nevermind this --- I was thinking about APIC ops and they are not >> > pv ops. >> > >> > Note though that there are other users of pv ops --- lguest and looks like >> > KVM (for one op) use them too. >> > >> >> Honestly, I think we should just delete lguest some time soon. And >> KVM uses this stuff so lightly that we shouldn't need all of the pvop >> stuff. (In fact, I'm slowly working on removing KVM_GUEST's >> dependency on PARAVIRT.) > > Even for the pvclock? > > (sorry for stealing this thread on this subject). I don't think that pvclock uses any of the paravirt infrastructure. It's just another clock source AFAIK. --Andy -- Andy Lutomirski AMA Capital Management, LLC