From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [RFH]: AMD CR intercept for lmsw/clts Date: Fri, 15 Aug 2014 22:48:14 +0100 Message-ID: <53EE801E.4000806@citrix.com> References: <20140804183337.2bb1b680@mantra.us.oracle.com> <53E0A7EC02000078000294FF@mail.emea.novell.com> <53E0BD00.8010602@citrix.com> <53E0E61F0200007800029731@mail.emea.novell.com> <53E0D569.2030700@citrix.com> <20140805153025.679dda72@mantra.us.oracle.com> <53E1F69D.800@citrix.com> <20140815210420.GA22144@laptop.dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XIPM6-0000jZ-RO for xen-devel@lists.xenproject.org; Fri, 15 Aug 2014 21:48:14 +0000 In-Reply-To: <20140815210420.GA22144@laptop.dumpdata.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: Konrad Rzeszutek Wilk Cc: suravee.suthikulpanit@amd.com, Aravind.Gopalakrishnan@amd.com, Jan Beulich , xen-devel , boris.ostrovsky@oracle.com List-Id: xen-devel@lists.xenproject.org On 15/08/2014 22:04, Konrad Rzeszutek Wilk wrote: > On Wed, Aug 06, 2014 at 10:34:21AM +0100, Andrew Cooper wrote: >> On 05/08/2014 23:30, Mukesh Rathor wrote: >>> On Tue, 05 Aug 2014 14:00:25 +0100 >>> Andrew Cooper wrote: >>> >>>> On 05/08/2014 13:11, Jan Beulich wrote: >>>>>>>> On 05.08.14 at 13:16, wrote: >>>>>> On 05/08/2014 08:46, Jan Beulich wrote: >>> ... >>> >>>> Despite the current limitations, I firmly believe that PVH should be >>>> HVM >>>> - device model, rather than PV + VMX/SVM. >>> I think that might be a dangerous route to take, classifying upfront >>> whether it's that way or the other. Eg, if we say it's former, then >>> anyone adding any feature would not examine the best approach, but just >>> take hvm approach. >> There are many PV-isms which already exist for HVM. Saying "HVM - >> device model" does not preclude further PVism from being introduced and >> used. It does however means that PV-aware HVM guests get equal >> opportunity at these improvements. Fundamentally, having PVH closer to >> HVM than PV means fewer modifications required to turn a native kernel >> into a PVH kernel, which is a *very* good thing from the point of view >> of the kernel authors. > Right. I would like to stress that the x86 maintainers are excited > about this as it would remove the pvops that don't have clear > semantic. >> But as I said, this is only my opinion. >> >>>> Fundamentally, the end goal of PVH needs deciding ASAP, and >>>> documenting, to help guide decisions like this. >>> I think it's decided somewhat. Evolve to one of three approaches: PV, >>> HVM, or alternate, picking the easiest and fastest. IMO, at the very >>> least, pvh should retain "guest modified" characteristic, that would be >>> good for xen future imho. >> It clearly is not decided, or even semi-certain, by virtue of having >> this conversation. > HA! >> There are currently many opinions (some of which certainly can't >> coexist, many which can), a lot of semi-baked code with many >> restrictions (and repeated breaking of PVH/PVHdom0 by making seemingly >> innocent code changes elsewhere), and no concrete plan of what PVH is or >> what it should be. >> >> What needs to happen urgently is for someone to make a firm decision, >> and prepare a document for /docs/specs/pvh. A document like that is not >> immutable in the future if hindsight shows otherwise, but it will >> provide solid guidance as to how to proceed in matters like this. > That could certainly be done but I think we are all tied in fixing > code and trying to get features in Xen 4.5 before the feature > freeze gates are shut. > > It should be fairly easy as most of it is 'runs like HVM' with > some HVM-ism disabled (so point to Intel SDM and AMD). And then > going through the hypercalls and seeing which are enabled. > > Then there is the business of the startup which is complex, but > fortunatly there is a Wiki page to rip: > http://wiki.xenproject.org/wiki/X86_Paravirtualised_Memory_Management > > Andrew, that nice template you used for the migrationv2 - where can > one find it? For the pdf spec? That is just completely standard pandoc. See http://xenbits.xen.org/gitweb/?p=people/andrewcoop/xen.git;a=commitdiff;h=ba4c1c9072c623ffb795310e538ea6eed81bd658 for how I expect it to be committed when migration v2 is accepted. ~Andrew