Re: [Xen-devel] [For 4.9] Updating https://wiki.xenproject.org/wiki/Xen_Project_Release_Features to reflect support status of new features

[Razvan Cojocaru <rcojocaru@xxxxxxxxxxxxxxx>]

Hello,

> - Security > Alternative 2pm : Supported – I think we should split this
> out – it is currently implicitly covered under "Virtual Machine
> Introspection"

I agree that altp2m deserves its own space. While we're interested in
it, our current solution makes no use of it, so it's certainly possible
to do introspection without any help from altp2m.

From my, albeit limited, experience, altp2m probably fits under "Tech
preview".

If we subtract altp2m from the general "Virtual Machine Introspection"
category, I'd say that the upstream support is between "Tech Preview"
and "Supported". I'll explain.

The interface is largely stable, but we may need to add optimizations
which might change it - so while we don't want this to be happening a
lot, it will happen.

There's also functional stability with the XenServer patches (which
bypass the emulator (single-step) when it can't emulate, and has a
version of the old smp_lock() emulator race-condition patch).
Unfortunately, upstream Xen still has race condition issues when
emulating LOCKed instructions in SMP scenarios - this will be addressed
ASAP with a proper CMPXCHG patch that currently depends on a patch from
Andrew and will require rework of a patch from Jan that adds a specific
emulation return code for CMPXCHG failures.

There's also an issue with #UD injections which is covered by the
emulator bypass patch in XenServer but can cause IPIs to get lost with
the upstream code - that will also require some more thinking.

So there are still (emulation-related) quirks upstream. We'd very much
like to get them ironed out.

I hope this answers the question.


Thanks,
Razvan

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