Re: [Xen-devel] [PATCH 18/18] PVH xen: introduce vmx_pvh.c

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.06.13 at 03:28, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx> wrote:
> On Thu, 27 Jun 2013 08:41:34 +0100 "Jan Beulich" <JBeulich@xxxxxxxx> wrote:
>> >>> On 27.06.13 at 05:30, Mukesh Rathor <mukesh.rathor@xxxxxxxxxx>
>> > No, pvh kernel has been changed to just do cpuid natively.
>> > Hopefully, over time, looong time, emulate_forced_invalid_op can
>> > just be removed.
>> 
>> While I don't disagree with a decision like this, the way you present
>> this still makes me want to comment: What you do or don't do in
>> Linux doesn't matter. What matters is a clear ABI description - what
>> are the requirements to a PVH kernel implementation, and in
>> particular what are the differences to a PV one? In the case here, a
>> requirement would now be to _not_ use the PV form of CPUID (or
>> more generally any operation that would result in #UD with the
>> expectation that the hypervisor emulates the instruction).
>> 
>> I don't think I've seen such a formalized list of differences, which
>> would make it somewhat difficult for someone else to convert their
>> favorite OS to support PVH too.
> 
> Correct, I don't think we are at a point where we can create such a
> list. It's been six months almost that the patches have been out, and 
> right now I'd like to focus on getting them in.

So in the end this means you're making and revisiting decisions on what
a PVH guest is or is not permitted to do as you go, with no clear model
spelled out up front. That's rather worrying to me.

>> > HVM should do this for debug intercepts, otherwise it is wrongly 
>> > intercepting user level debuggers like gdb.
>> 
>> And why would intercepting kernel debuggers like kdb or kgdb be
>> correct?
> 
> The last I checked there were no kernel debuggers supported in domU, so
> I wrote gdbsx. If that has changed, then there's some work to do for
> gdbsx for both hvm and pvh.

In a HVM guest, a kernel debugger should work, or else the
emulation is incomplete (which then is a plain bug).

Jan


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