Re: [PATCH RFC] Add SUPPORT.md

[George Dunlap <george.dunlap@citrix.com>]

On 08/31/2017 01:46 PM, Jan Beulich wrote:
>>>> On 31.08.17 at 12:27, <george.dunlap@citrix.com> 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).

OK, I'll changet this to "x86/vMCE" then.

>> +## 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?

Perhaps 'tooling' isn't the right name for this section; it includes:

- gdbsx
- vpmu
- guest serial console
- xentrace
- gcov

All of the other features have something to do with looking into the
guest / hypervisor and figuring out what's wrong.

But in any case, vPMU is more about allowing in-guest tools to analyze
the performance of the guest itself; as such it should probably
somewhere else.  I've moved it under "## Hardware".

>> +## 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? 

I'd say the useful thing to talk about is guest support.  Let me think
about how to reword this.

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

I've deleted this item.

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

Change the compile time disabling?  I don't really know. :-)

What gets checked in should ideally be true at the time it's checked in.

>> +### Virtual Machine Introspection
>> +
>> +    Status: Supported, x86 only
> 
> Including security support?

Not sure, actually.  Opinions?

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

Well remember that this list came from the "Feature support matrix",
which was also meant to announce / brag about new features we were
developing.

This is already really long.  Anything that comes accessible to guests
by default (which AVX instructions are) must be supported (including
security support).  I wonder if there's a better way to specify this
sort of thing.

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

Yes, probably useful.

>> +# 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/ ?

Ack.

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

I like 'Tech Preview' better, so unless someone objects I'll change them
all to 'Tech Preview'.

I was originally using only 'Preview' because I thought a single word
would be more easy to parse; but we have "not security supported"
anyway, so might as well go with what sounds better.

Thanks,
 -George

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