From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joao Martins Subject: Re: [PATCH] xen/x86: Adjust stack pointer in xen_sysexit Date: Tue, 17 Nov 2015 10:53:58 +0000 Message-ID: <564B0746.8090505__20845.6339933493$1447757770$gmane$org@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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andy Lutomirski Cc: "linux-kernel@vger.kernel.org" , xen-devel , Borislav Petkov , David Vrabel , "H. Peter Anvin" , Boris Ostrovsky List-Id: xen-devel@lists.xenproject.org On 11/16/2015 09:04 PM, Andy Lutomirski wrote: > 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. > Yeah, but pv_time_ops is still used on both Xen and KVM. Even though it looks that on KVM some of it's used only when pvclock isn't marked as stable (i.e. no PVCLOCK_TSC_STABLE_BIT). Joao > --Andy >