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

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

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 <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.
> 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