Re: [Xen-devel] [RFH]: AMD CR intercept for lmsw/clts

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

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 <andrew.cooper3@xxxxxxxxxx> wrote:
> >
> >> On 05/08/2014 13:11, Jan Beulich wrote:
> >>>>>> On 05.08.14 at 13:16, <andrew.cooper3@xxxxxxxxxx> 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?

> 
> ~Andrew
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel