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

[George Dunlap <george.dunlap@xxxxxxxxxx>]

On 09/07/2017 10:54 PM, Stefano Stabellini wrote:
> On Thu, 31 Aug 2017, George Dunlap wrote:
>> +### Direct-boot kernel image format
>> +
>> +    Supported, x86: bzImage
>> +    Supported, ARM32: zImage
>> +    Supported, ARM64: Image [XXX - Not sure if this is correct]
> 
> On ARM64 it's called Image.gz.

Ack.


>> +### Alternative p2m
>> +
>> +    Status, x86: Preview
>> +
>> +Allows external monitoring of hypervisor memory using Intel EPT by allowing 
>> to maintain multiple physical memory to machine physical mappings
>> +
>> +[XXX Should this be x86/Alternative p2m?]
> 
> No, the technology could be available on ARM.

Yup, got that change already.

>> +### Null Scheduler
>> +
>> +    Status: Experimental
>> +
>> +A very simple, very static scheduling posicy that always schedules the same 
>> vCPU(s) on the same pCPU(s). It is designed for maximum determinism and 
>> minimum overhead on embedded platforms.
> 
> Can we say more than Experimental? I think it should be at least Tech
> Preview.

I was going to wait for Dario to respond to this (I had just copied what
was already there).  Tech Preview should look like this:

    Functional completeness: Yes
    Functional stability: Quirky
    Interface stability: Provisionally stable
    Security supported: No

I think that's probably accurate.  Dario?

>> +### Xen Framebuffer
> 
> Please write "Xen Framebuffer Frontend" in the title.

It is in a section labelled 'guest side'.  On the other hand, the list
is long, and the headings in markdown aren't actually that easy to scan
in text mode.

Let me give it some thought. (I'll put an XXX to make sure it gets
considered.)

>> +### Netback
>> +
>> +    Status, Linux (netback): Supported
>> +    Status, FreeBSD (netback): Supported
>> +    Status, QEMU (xen_nic): Experimental
> 
> I suggest to Deprecate xen_nic

That's fine with me.  Anthony?

>> +### vTPM Support
>> +
>> +    Status: Supported, x86 only
> 
> This should probably be x86/vTPM. TPM, the way we are discussing it, is
> an x86-only implementation. ARM-based alternatives are not called TPM
> AFAIK.

Someone said that because this was implemented entirely in userspace,
there's no reason the PV TPM couldn't work on ARM.  OTOH I suppose it
would be a lot less valuable if there weren't a physical TPM to back it up.

Any thoughts on that?

>> +### Intel/TXT ???
> 
> Same here

Well unless someone actually says something about this I'm just going go
delete it.

>> +### ARM/ITS
>> +
>> +    Status: experimental
>> +
>> +[XXX What is this?]
> 
> A particularly complex extension to the interrupt controller.

But what people reading this want to know isn't how complicated it is,
but what it would be for.

I could put "An extension to the ARM interrupt controller", but it would
be nice if I could also say, "...that implements $FEATURE" or
"...targeted at $APPLICATION".

Thanks for the feedback,
 -George


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