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

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 05/08/2014 23:30, Mukesh Rathor wrote:
> On Tue, 05 Aug 2014 14:00:25 +0100
> Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>
>> On 05/08/2014 13:11, Jan Beulich wrote:
>>>>>> On 05.08.14 at 13:16, <andrew.cooper3@citrix.com> 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.

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.

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.

~Andrew