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

[Tamas K Lengyel <tamas.lengyel@xxxxxxxxxxxx>]

On Tue, Jun 27, 2017 at 3:48 AM, Razvan Cojocaru
<rcojocaru@xxxxxxxxxxxxxxx> wrote:
> 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.

I do use it with introspection but I think there were also use-cases
for it that were not introspection related. So I think splitting it
out is correct.

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

Sounds right to me.

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

IMHO if we consider stuff like the domctl interface stable then the
vm_event interface can be considered stable too. I don't think stable
means that it doesn't change, I think it means that it changes in a
way that users can clearly build with it and/or detect the changes via
interface versioning, which we do have here as well.

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

IMHO the emulator of Xen is not part of introspection. Just as with
altp2m, it can be used in that context, but it is not part of it.

Tamas

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