Re: [Xen-devel] [PATCH RFC] Add SUPPORT.md

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 31.08.17 at 12:27, <george.dunlap@xxxxxxxxxx> wrote:
> vMCE: Is MCE an x86-only thing, or could this conceivably by extended
> to ARM?

I think this can't be reasonably extended beyond x86 (and,
considering their similar origin, ia64).

> +## Tooling
> +
> +### gdbsx
> +
> +    Status, x86: Supported
> +
> +Debugger to debug ELF guests
> +
> +### vPMU
> +
> +    Status, x86: Supported, Not security supported
> +
> +Virtual Performance Management Unit for HVM guests

Why is this under Tooling?

> +## Scalability
> +
> +### 1GB/2MB super page support
> +
> +    Status: Supported

Is this a host, guest, CPU, and/or IOMMU capability? Do the same
superpage sizes apply to 16k/64k-page-size ARM? If host, here as
well as ...

> +### Fair locks (ticket-locks)
> +
> +    Status: Supported

... here I wonder whether these are legitimately on this list in the
first place. Admins have no way to avoid their use.

> +### Live Patching
> +
> +    Status: Supported, x86 only
> +
> +Compile time disabled

Bu we're settled to change that, aren't we? It was even meant to be
so in 4.9, but then didn't make it.

> +### Virtual Machine Introspection
> +
> +    Status: Supported, x86 only

Including security support?

> +### x86/PCI Passthrough PV
> +
> +    Status: Supported, Not security supported
> +
> +PV passthrough cannot be done safely.
> +
> +[XXX Not even with an IOMMU?]

It depends who you ask. I think it would be okay to use ...

> +### x86/PCI Passthrough HVM
> +
> +    Status: Supported, with caveats
> +
> +Many hardware device and motherboard combinations are not possible to use 
> safely.
> +The XenProject will support bugs in PCI passthrough for Xen,
> +but the user is responsible to ensure that the hardware combination they use
> +is sufficiently secure for their needs,
> +and should assume that any combination is insecure
> +unless they have reason to believe otherwise.

... this for PV+IOMMU too.

> +### x86/Advanced Vector eXtension
> +
> +    Status: Supported

How fine-grained do we want this document to be? If this one is a
valid entry, then many other CPUID bits will need to have entries
too.

Having reached the end of the list I further wonder whether we
shouldn't add information on various hypercalls and their subops.
I.e. a full walk through include/public/ may be needed to see
what additional entries may be necessary or desirable.

> +# Format and definitions
> +
> +This file contains prose, and machine-readable fragments.
> +The data in a machine-readable fragment relate to
> +the section and subection in which it is fine.

"subsection" and s/fine/found/ ?

> +## Definition of Status labels
> +
> +Each Status value corresponds to levels of security support,
> +testing, stability, etc., as follows:
> +
> +### Experimental
> +
> +    Functional completeness: No
> +    Functional stability: Here be dragons
> +    Interface stability: Not stable
> +    Security supported: No
> +
> +### Tech Preview

I think most if not all entries using this say just "Preview" - I think
the terms would better fully match.

Jan


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