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

[Lars Kurth]

Julien,
we are waiting for George to come back from holiday to post the proposal for 
review, after Ian and I had done the prep work
This was then discussed at the summit, and there were a couple off-line 
responses on ARM support, etc.
Lars

On 17/08/2017, 15:48, "Julien Grall"  wrote:

Hi,

I wanted to bump this thread. I saw that the page still contain "Note 
that we will add complete information related to Xen Project 4.9, in the 
week after the 4.9 release.".

It looks like to me we added some features, but I am not sure if we 
added all of them.

Cheers,

On 27/06/17 09:53, Lars Kurth wrote:
> Hi all, (I think I CCed all stake-holders)
>
> to finish off the release documentation for 4.9, I need to add an extra
> column
> to https://wiki.xenproject.org/wiki/Xen_Project_Release_Features –
> because I was travelling, this dropped of my radar. There several
> decisions to be made:
> A) Decide which "features" to add
> B) Decide on the status of the feature
> C) Deal with status changes of any past features
>
> The first goal would be to decide on A and any new "features" under C.
> For B, I am OK to add "???" for now and point to this thread, until we
> have concluded the discussion
>
> Note that I tracked some of this as preparation for getting CNA status.
>  Items marked with * are not yet in the discussion document that I
> created for the security team and which we intend to discuss at the 
summit.
>
> For all of these, the naming convention is "Section in document" >
> "Feature" : "Support status". The definition of support status is added
> at the end of the mail: note that the text has not yet been fully
> agreed, but seems to reflect fairly well how we handled stuff in the past.
>
> == On A / B: I think we should add ==
> - Resource Management > Null Scheduler : tech preview or experimental
> - Virtual Firmware or PV Bootloader Support (not sure which) >  x86/Boot
> Xen on EFI platforms using GRUB2*  : ???
> - Hardware > ARM/Alternative Runtime Patching (ARM32 and ARM64): ???
> [note that this should probably have been added for 4.8, but I didn't
> add it]
> - Hardware > ARM/System Error Protection* : ???
> - Hardware > ARM/Wait for Virtual Interrupt* : ???
> - Hardware > x86/AVX512/Neural Network Instructions AVX512_4VNNIW* : ???
> - Hardware > x86/AVX512/Multiply Accumulation Single precision
> AVX512_4FMAPS* : ???
> - Device Models > DMOP (Device Model Operation Hypercall)  : ???
>
> New Heading:  PV Protocols and Drivers
> - PV Protocols and Drivers > pvcalls : tech preview or experimental
> - PV Protocols and Drivers > 9pfs : tech preview or experimental
> - PV Protocols and Drivers* > sndif (sound device) : tech preview or
> experimental
> - PV Protocols and Drivers* > displif (PV display) : tech preview or
> experimental
>
> Did I miss anything?
>
> == On C ==
> - Security > Live Patching -
> see 
https://lists.xenproject.org/archives/html/xen-devel/2017-06/threads.html#03039
> - Security > Alternative 2pm : Supported – I think we should split this
> out – it is currently implicitly covered under "Virtual Machine
> Introspection"
>
> If we introduce a new heading "PV Protocols and Drivers" we should
> probably list all the common ones as supported in this heading, e.g.
> - PV Protocols and Drivers* > default (net, block, console, keyboard,
> mouse) : supported
>
> There are also USB and framebuffer, which I am not sure whether they
> should be supported and if not, what their status is
> - PV Protocols and Drivers* > USB : ???
> - PV Protocols and Drivers* > framebuffer : ???
>
> Suggestions are welcome
>
> Best Regards
> Lars
>
> 
>
> ## Definitions
>
> ### User-facing Support Criteria
>
>  * **Functionally complete:** Does it behave like a fully functional
>feature?  Does it work on all expected platforms, or does it only work
>for a very specific sub-case?  Does it have a sensible UI, or do you
>have to have a deep understanding of the internals to get it to work
>properly?
>
>  * **Functional stability:** What is the risk of it exhibiting bugs?
>
>General answers to the above:
>
>- *Here be dragons*: Pretty likely to still crash / fail to work.  Not
>  recommended unless you like life on the bleeding edge.
>- *Quirky*: Mostly works but may have odd behavior here and there.
>  Recommended for playing around or for non-production use cases.
>- *Normal*: Ready for production use
>
> *  **Interface stability:**  If I build a system based on the current
>interfaces, will they still work when I upgrade to 

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

[Julien Grall]

Hi,

I wanted to bump this thread. I saw that the page still contain "Note 
that we will add complete information related to Xen Project 4.9, in the 
week after the 4.9 release.".


It looks like to me we added some features, but I am not sure if we 
added all of them.


Cheers,

On 27/06/17 09:53, Lars Kurth wrote:

Hi all, (I think I CCed all stake-holders)

to finish off the release documentation for 4.9, I need to add an extra
column
to https://wiki.xenproject.org/wiki/Xen_Project_Release_Features –
because I was travelling, this dropped of my radar. There several
decisions to be made:
A) Decide which "features" to add
B) Decide on the status of the feature
C) Deal with status changes of any past features

The first goal would be to decide on A and any new "features" under C.
For B, I am OK to add "???" for now and point to this thread, until we
have concluded the discussion

Note that I tracked some of this as preparation for getting CNA status.
 Items marked with * are not yet in the discussion document that I
created for the security team and which we intend to discuss at the summit.

For all of these, the naming convention is "Section in document" >
"Feature" : "Support status". The definition of support status is added
at the end of the mail: note that the text has not yet been fully
agreed, but seems to reflect fairly well how we handled stuff in the past.

== On A / B: I think we should add ==
- Resource Management > Null Scheduler : tech preview or experimental
- Virtual Firmware or PV Bootloader Support (not sure which) >  x86/Boot
Xen on EFI platforms using GRUB2*  : ???
- Hardware > ARM/Alternative Runtime Patching (ARM32 and ARM64): ???
[note that this should probably have been added for 4.8, but I didn't
add it]
- Hardware > ARM/System Error Protection* : ???
- Hardware > ARM/Wait for Virtual Interrupt* : ???
- Hardware > x86/AVX512/Neural Network Instructions AVX512_4VNNIW* : ???
- Hardware > x86/AVX512/Multiply Accumulation Single precision
AVX512_4FMAPS* : ???
- Device Models > DMOP (Device Model Operation Hypercall)  : ???

New Heading:  PV Protocols and Drivers
- PV Protocols and Drivers > pvcalls : tech preview or experimental
- PV Protocols and Drivers > 9pfs : tech preview or experimental
- PV Protocols and Drivers* > sndif (sound device) : tech preview or
experimental
- PV Protocols and Drivers* > displif (PV display) : tech preview or
experimental

Did I miss anything?

== On C ==
- Security > Live Patching -
see 
https://lists.xenproject.org/archives/html/xen-devel/2017-06/threads.html#03039
- Security > Alternative 2pm : Supported – I think we should split this
out – it is currently implicitly covered under "Virtual Machine
Introspection"

If we introduce a new heading "PV Protocols and Drivers" we should
probably list all the common ones as supported in this heading, e.g.
- PV Protocols and Drivers* > default (net, block, console, keyboard,
mouse) : supported

There are also USB and framebuffer, which I am not sure whether they
should be supported and if not, what their status is
- PV Protocols and Drivers* > USB : ???
- PV Protocols and Drivers* > framebuffer : ???

Suggestions are welcome

Best Regards
Lars



## Definitions

### User-facing Support Criteria

 * **Functionally complete:** Does it behave like a fully functional
   feature?  Does it work on all expected platforms, or does it only work
   for a very specific sub-case?  Does it have a sensible UI, or do you
   have to have a deep understanding of the internals to get it to work
   properly?

 * **Functional stability:** What is the risk of it exhibiting bugs?

   General answers to the above:

   - *Here be dragons*: Pretty likely to still crash / fail to work.  Not
 recommended unless you like life on the bleeding edge.
   - *Quirky*: Mostly works but may have odd behavior here and there.
 Recommended for playing around or for non-production use cases.
   - *Normal*: Ready for production use

*  **Interface stability:**  If I build a system based on the current
   interfaces, will they still work when I upgrade to the next version?

   - *Not stable*: Interface is still in the early stages and still fairly
 likely to be broken in future updates.
   - *Provisionally stable*: We're not yet promising backwards
 compatibility, but we think this is probably the final form of the
 interface.  It may still require some tweaks.
   - *Stable*: We will try very hard to avoid breaking backwards
 compatibility, and to fix any regressions that are reported.

*  **Security supported:** Will XSAs be issued if security-related bugs are
   discovered in the functionality?

### Definition of Support Labels

Rather than specify each level above, we have some short-hand labels
that we use to denote general answer to the above questions.

# Experimental
 Functional completeness: No
 Functional stability: Here be dragons
 Interface stability: Not stable
 Security supported: No

# Tech Preview
 

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

[Lars Kurth]

On 27/06/2017, 17:16, "Jan Beulich"  wrote:

 Lars Kurth  06/27/17 10:54 AM >>>
>>- Hardware > x86/AVX512/Neural Network Instructions AVX512_4VNNIW* : ???
>>- Hardware > x86/AVX512/Multiply Accumulation Single precision
>>AVX512_4FMAPS* : ???
>
>For one I think mentioning enabling of individual instructions (rather
>than larger
>sets) isn't really worthwhile. Furthermore, as will all AVX512
>sub-features, what
>we have for now is really only partial enablement, as the insn emulator
>doesn't
>support any of it yet.

Fine with me. I wanted to ask the question
Lars
>

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

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]

On Tue, Jun 27, 2017 at 3:48 AM, Razvan Cojocaru
 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@lists.xen.org
https://lists.xen.org/xen-devel

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

[Jan Beulich]

>>> Lars Kurth  06/27/17 10:54 AM >>>
>- Hardware > x86/AVX512/Neural Network Instructions AVX512_4VNNIW* : ???
>- Hardware > x86/AVX512/Multiply Accumulation Single precision AVX512_4FMAPS* 
>: ???

For one I think mentioning enabling of individual instructions (rather than 
larger
sets) isn't really worthwhile. Furthermore, as will all AVX512 sub-features, 
what
we have for now is really only partial enablement, as the insn emulator doesn't
support any of it yet.

Jan


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

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

[Julien Grall]

On 27/06/17 09:53, Lars Kurth wrote:

Hi all, (I think I CCed all stake-holders)


Hi Lars,



to finish off the release documentation for 4.9, I need to add an extra
column
to https://wiki.xenproject.org/wiki/Xen_Project_Release_Features –
because I was travelling, this dropped of my radar. There several
decisions to be made:
A) Decide which "features" to add
B) Decide on the status of the feature
C) Deal with status changes of any past features

The first goal would be to decide on A and any new "features" under C.
For B, I am OK to add "???" for now and point to this thread, until we
have concluded the discussion

Note that I tracked some of this as preparation for getting CNA status.
 Items marked with * are not yet in the discussion document that I
created for the security team and which we intend to discuss at the summit.

For all of these, the naming convention is "Section in document" >
"Feature" : "Support status". The definition of support status is added
at the end of the mail: note that the text has not yet been fully
agreed, but seems to reflect fairly well how we handled stuff in the past.

== On A / B: I think we should add ==
- Resource Management > Null Scheduler : tech preview or experimental
- Virtual Firmware or PV Bootloader Support (not sure which) >  x86/Boot
Xen on EFI platforms using GRUB2*  : ???
- Hardware > ARM/Alternative Runtime Patching (ARM32 and ARM64): ???
[note that this should probably have been added for 4.8, but I didn't
add it]


I don't think this is worth mentioning it. It is more an enabler for 
implementing errata and new hardware feature than a feature in itself.



- Hardware > ARM/System Error Protection* : ???


I would not mention it. We added an option to allow the administrator to 
limit the overhead of system error check protection. But any 
configuration that the default one should be used on trusted environment 
as hypervisor fault will leak to guest. So I don't think we can consider 
this as supported by the security team.



- Hardware > ARM/Wait for Virtual Interrupt* : ???


Supported. But I would name "Configure behavior of WFI instruction 
executed by guest" or something similar.



New Heading:  PV Protocols and Drivers
- PV Protocols and Drivers > pvcalls : tech preview or experimental
- PV Protocols and Drivers > 9pfs : tech preview or experimental
- PV Protocols and Drivers* > sndif (sound device) : tech preview or
experimental
- PV Protocols and Drivers* > displif (PV display) : tech preview or
experimental

Did I miss anything?

== On C ==
- Security > Live Patching -
see 
https://lists.xenproject.org/archives/html/xen-devel/2017-06/threads.html#03039
- Security > Alternative 2pm : Supported – I think we should split this
out – it is currently implicitly covered under "Virtual Machine
Introspection"


FWIW, this is not supported on ARM yet.

Cheers,

--
Julien Grall

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

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

[Dario Faggioli]

On Tue, 2017-06-27 at 13:04 +0200, Lars Kurth wrote:
> > On 06/27/2017 12:33 PM, George Dunlap wrote:
> > > > == On A / B: I think we should add ==
> > > > - Resource Management > Null Scheduler : tech preview or
> > > > experimental
> > > 
> > > I think that the interface is probably in a final form, the code
> > > is
> > > complete, and there are no known bugs or issues; so I'd say tech
> > > preview.
> > > 
I agree. There's potential for new features and improvement, like
supporting soft-affinity (not for scheduling, as all is static, but for
NUMA placement reasons) and/or introducing tracing in there.

But all are the kind of improvement that happens even for supported
features.

> > > Dario, any opinions?
>
I think Tech Preview is ok.

Dario
-- 
<> (Raistlin Majere)
-
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R Ltd., Cambridge (UK)

signature.asc
Description: This is a digitally signed message part
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Wei Liu]

On Tue, Jun 27, 2017 at 11:04:15AM +, Lars Kurth wrote:
> Alright: as we seem to have consensus, I will add
> 
> PV Protocols and Drivers* > default (net, block, console, keyboard, mouse,
> USB, framebuffer) : supported
> 
> 
> And I am going to backdate this up to 4.5 (and put ? before), as these
> seem to have been around forever
> 

Not for PVUSB.

> Lars
> 

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

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

[Oleksandr Andrushchenko]

On 06/27/2017 04:30 PM, Lars Kurth wrote:

Removing security@

On 27/06/2017, 14:28, "Oleksandr Andrushchenko"  wrote:


Did I miss anything?


Please consider adding new topics:
1. Shared coprocessor framework
2. Native applications, e.g. EL0 app, stubdoms

I am only adding committed stuff: these are 4.10 items
Lars

Ah, sorry about messing things up

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

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

[Lars Kurth]

Removing security@

On 27/06/2017, 14:28, "Oleksandr Andrushchenko"  wrote:

>
>> Did I miss anything?
>>
>Please consider adding new topics:
>1. Shared coprocessor framework
>2. Native applications, e.g. EL0 app, stubdoms

I am only adding committed stuff: these are 4.10 items
Lars
>

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

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

[Oleksandr Andrushchenko]

Did I miss anything?


Please consider adding new topics:
1. Shared coprocessor framework
2. Native applications, e.g. EL0 app, stubdoms

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

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

[Oleksandr Andrushchenko]

Hi, all


New Heading:  PV Protocols and Drivers
- PV Protocols and Drivers > pvcalls : tech preview or experimental
- PV Protocols and Drivers > 9pfs : tech preview or experimental
- PV Protocols and Drivers* > sndif (sound device) : tech preview or 
experimental
- PV Protocols and Drivers* > displif (PV display) : tech preview or 
experimental



Let me update on PV development EPAM does (everything is
publicly available at the links below, primary source is [1]):

1. Multi-touch:
1.1. Protocol changes are already in both Kernel and Xen
1.2. Front-end support for multi-touch is on review, hope
it will be merged soon [2]
1.3. Backend support is part of our user-space display backend [3]

2. Sound
2.1. Protocol is already in both Kernel and Xen
2.2. We have a user-space backend [4], need to get it ready for upstreaming
2.3. Frontend is available at [6], need to get it ready for upstreaming

3. Display
2.1. Protocol is already in both Kernel and Xen
2.2. We have a user-space backend [3], need to get it ready for upstreaming
2.3. Frontend is available at [6], need to get it ready for upstreaming
2.4. DRM zero copy driver is available at [6], need to get it ready
for upstreaming

4. libxl/xl changes
We are working on adding support for mtouch/display/sound into libxl/xl
4.1. Display changes, patches on review [5]
4.2. Mtouch and sound are in progress, no patches yet

[1] https://github.com/xen-troops
[2] https://patchwork.kernel.org/patch/9805741/
[3] https://github.com/xen-troops/displ_be
[4] https://github.com/al1img/snd_be
[5] https://www.mail-archive.com/xen-devel@lists.xen.org/msg112690.html
[6] https://github.com/xen-troops/linux/tree/vgpu-dev

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

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

[Lars Kurth]

On 27/06/2017, 12:02, "George Dunlap"  wrote:

>On Tue, Jun 27, 2017 at 9:53 AM, Lars Kurth  wrote:
>> Hi all, (I think I CCed all stake-holders)
>>
>> to finish off the release documentation for 4.9, I need to add an extra
>> column to https://wiki.xenproject.org/wiki/Xen_Project_Release_Features
>>–
>
>Also -- the table is getting awfully large, and half of it is out of
>security support now.  Would it make sense to start trimming some
>releases off the left-hand side?
>
>I think 8 outstanding releases should really be an upper limit.
>
Agreed, I was already thinking about this. I am going to make an archived
copy and delete everything before 4.4
Lars
>

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

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

[Lars Kurth]

On 27/06/2017, 11:57, "Juergen Groß"  wrote:

>On 06/27/2017 12:33 PM, George Dunlap wrote:
>> On Tue, Jun 27, 2017 at 9:53 AM, Lars Kurth 
>>wrote:
>>> Hi all, (I think I CCed all stake-holders)
>>>
>>> to finish off the release documentation for 4.9, I need to add an extra
>>> column to 
>>>https://wiki.xenproject.org/wiki/Xen_Project_Release_Features –
>>> because I was travelling, this dropped of my radar. There several
>>>decisions
>>> to be made:
>>> A) Decide which "features" to add
>>> B) Decide on the status of the feature
>>> C) Deal with status changes of any past features
>>>
>>> The first goal would be to decide on A and any new "features" under C.
>>>For
>>> B, I am OK to add "???" for now and point to this thread, until we have
>>> concluded the discussion
>>>
>>> Note that I tracked some of this as preparation for getting CNA status.
>>> Items marked with * are not yet in the discussion document that I
>>>created
>>> for the security team and which we intend to discuss at the summit.
>>>
>>> For all of these, the naming convention is "Section in document" >
>>>"Feature"
>>> : "Support status". The definition of support status is added at the
>>>end of
>>> the mail: note that the text has not yet been fully agreed, but seems
>>>to
>>> reflect fairly well how we handled stuff in the past.
>>>
>>> == On A / B: I think we should add ==
>>> - Resource Management > Null Scheduler : tech preview or experimental
>> 
>> I think that the interface is probably in a final form, the code is
>> complete, and there are no known bugs or issues; so I'd say tech
>> preview.
>> 
>> Dario, any opinions?
>> 
>>> - Virtual Firmware or PV Bootloader Support (not sure which) >
>>>x86/Boot Xen
>>> on EFI platforms using GRUB2*  : ???
>> 
>> If I'm interpreting your phrase correctly, this probably goes under
>> "interoperability / hardware support"
>> 
>>> - Hardware > ARM/Alternative Runtime Patching (ARM32 and ARM64): ???
>>>[note
>>> that this should probably have been added for 4.8, but I didn't add it]
>>> - Hardware > ARM/System Error Protection* : ???
>>> - Hardware > ARM/Wait for Virtual Interrupt* : ???
>>> - Hardware > x86/AVX512/Neural Network Instructions AVX512_4VNNIW* :
>>>???
>>> - Hardware > x86/AVX512/Multiply Accumulation Single precision
>>> AVX512_4FMAPS* : ???
>>> - Device Models > DMOP (Device Model Operation Hypercall)  : ???
>> 
>> This is already used by default in the version of qemu released in
>> 4.9, right?  I think I'd call that "supported".
>> 
>>> == On C ==
>>> - Security > Live Patching - see
>>> 
>>>https://lists.xenproject.org/archives/html/xen-devel/2017-06/threads.htm
>>>l#03039
>>> - Security > Alternative 2pm : Supported – I think we should split
>>>this out
>>> – it is currently implicitly covered under "Virtual Machine
>>>Introspection"
>>>
>>> If we introduce a new heading "PV Protocols and Drivers" we should
>>>probably
>>> list all the common ones as supported in this heading, e.g.
>>> - PV Protocols and Drivers* > default (net, block, console, keyboard,
>>>mouse)
>>> : supported
>> 
>> I don't think there are keyboard and mouse PV protocols.  On the other
>> hand, I just realized that I have no idea how one uses PV guests with
>> a framebuffer but no mouse.
>
>xen/include/public/io/kbdif.h does exist it it is being used.
>
>>> There are also USB and framebuffer, which I am not sure whether they
>>>should
>>> be supported and if not, what their status is
>>> - PV Protocols and Drivers* > USB : ???
>> 
>> This one has been around a long time, then languished for a bit, but
>> it seems has been picked up by SuSE again.
>> 
>> I don't *think* we're doing USB testing in osstest yet (either HVM or
>>PVUSB).
>> 
>> Juergen, are you guys actively doing internal testing of PVUSB?  If so
>> we could probably label that as 'supported' anyway.
>
>Yes, we do.

Alright: as we seem to have consensus, I will add

PV Protocols and Drivers* > default (net, block, console, keyboard, mouse,
USB, framebuffer) : supported


And I am going to backdate this up to 4.5 (and put ? before), as these
seem to have been around forever

Lars

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

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

[George Dunlap]

On Tue, Jun 27, 2017 at 9:53 AM, Lars Kurth  wrote:
> Hi all, (I think I CCed all stake-holders)
>
> to finish off the release documentation for 4.9, I need to add an extra
> column to https://wiki.xenproject.org/wiki/Xen_Project_Release_Features –

Also -- the table is getting awfully large, and half of it is out of
security support now.  Would it make sense to start trimming some
releases off the left-hand side?

I think 8 outstanding releases should really be an upper limit.

 -George

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

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

[Juergen Groß]

On 06/27/2017 12:33 PM, George Dunlap wrote:

On Tue, Jun 27, 2017 at 9:53 AM, Lars Kurth  wrote:

Hi all, (I think I CCed all stake-holders)

to finish off the release documentation for 4.9, I need to add an extra
column to https://wiki.xenproject.org/wiki/Xen_Project_Release_Features –
because I was travelling, this dropped of my radar. There several decisions
to be made:
A) Decide which "features" to add
B) Decide on the status of the feature
C) Deal with status changes of any past features

The first goal would be to decide on A and any new "features" under C. For
B, I am OK to add "???" for now and point to this thread, until we have
concluded the discussion

Note that I tracked some of this as preparation for getting CNA status.
Items marked with * are not yet in the discussion document that I created
for the security team and which we intend to discuss at the summit.

For all of these, the naming convention is "Section in document" > "Feature"
: "Support status". The definition of support status is added at the end of
the mail: note that the text has not yet been fully agreed, but seems to
reflect fairly well how we handled stuff in the past.

== On A / B: I think we should add ==
- Resource Management > Null Scheduler : tech preview or experimental


I think that the interface is probably in a final form, the code is
complete, and there are no known bugs or issues; so I'd say tech
preview.

Dario, any opinions?


- Virtual Firmware or PV Bootloader Support (not sure which) >  x86/Boot Xen
on EFI platforms using GRUB2*  : ???


If I'm interpreting your phrase correctly, this probably goes under
"interoperability / hardware support"


- Hardware > ARM/Alternative Runtime Patching (ARM32 and ARM64): ??? [note
that this should probably have been added for 4.8, but I didn't add it]
- Hardware > ARM/System Error Protection* : ???
- Hardware > ARM/Wait for Virtual Interrupt* : ???
- Hardware > x86/AVX512/Neural Network Instructions AVX512_4VNNIW* : ???
- Hardware > x86/AVX512/Multiply Accumulation Single precision
AVX512_4FMAPS* : ???
- Device Models > DMOP (Device Model Operation Hypercall)  : ???


This is already used by default in the version of qemu released in
4.9, right?  I think I'd call that "supported".


== On C ==
- Security > Live Patching - see
https://lists.xenproject.org/archives/html/xen-devel/2017-06/threads.html#03039
- Security > Alternative 2pm : Supported – I think we should split this out
– it is currently implicitly covered under "Virtual Machine Introspection"

If we introduce a new heading "PV Protocols and Drivers" we should probably
list all the common ones as supported in this heading, e.g.
- PV Protocols and Drivers* > default (net, block, console, keyboard, mouse)
: supported


I don't think there are keyboard and mouse PV protocols.  On the other
hand, I just realized that I have no idea how one uses PV guests with
a framebuffer but no mouse.


xen/include/public/io/kbdif.h does exist it it is being used.


There are also USB and framebuffer, which I am not sure whether they should
be supported and if not, what their status is
- PV Protocols and Drivers* > USB : ???


This one has been around a long time, then languished for a bit, but
it seems has been picked up by SuSE again.

I don't *think* we're doing USB testing in osstest yet (either HVM or PVUSB).

Juergen, are you guys actively doing internal testing of PVUSB?  If so
we could probably label that as 'supported' anyway.


Yes, we do.


Juergen

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

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

[Lars Kurth]

On 27/06/2017, 11:33, "George Dunlap"  wrote:

>On Tue, Jun 27, 2017 at 9:53 AM, Lars Kurth  wrote:
>>
>> - Virtual Firmware or PV Bootloader Support (not sure which) >
>>x86/Boot Xen
>> on EFI platforms using GRUB2*  : ???
>
>If I'm interpreting your phrase correctly, this probably goes under
>"interoperability / hardware support"

I wasn't quite sure whether it should go into
A) 
https://wiki.xenproject.org/wiki/Xen_Project_Release_Features#Interoperabil
ity_.2F_Hardware_Support (Interoperability / Hardware Support) or
B) 
https://wiki.xenproject.org/wiki/Xen_Project_Release_Features#Device_Models
_and_Virtual_Firmware (Device Models and Virtual Firmware)

If B), then there is the option to put it under B.1) "Device Models and
Virtual Firmware for HVM guests" or B.2) "PV Bootloader support"

I will put it wherever you guys think is best

Lars

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

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

[Lars Kurth]

Removed security@ to avoid creating unnecessary RT tickets. Please respond
to this mail. I suppose on this specific topic, Tamas and Andy Cooper
should voice an opinion also
Regards
Lars

On 27/06/2017, 10:48, "Razvan Cojocaru"  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.
>
>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@lists.xen.org
https://lists.xen.org/xen-devel

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

[George Dunlap]

On Tue, Jun 27, 2017 at 9:53 AM, Lars Kurth  wrote:
> Hi all, (I think I CCed all stake-holders)
>
> to finish off the release documentation for 4.9, I need to add an extra
> column to https://wiki.xenproject.org/wiki/Xen_Project_Release_Features –
> because I was travelling, this dropped of my radar. There several decisions
> to be made:
> A) Decide which "features" to add
> B) Decide on the status of the feature
> C) Deal with status changes of any past features
>
> The first goal would be to decide on A and any new "features" under C. For
> B, I am OK to add "???" for now and point to this thread, until we have
> concluded the discussion
>
> Note that I tracked some of this as preparation for getting CNA status.
> Items marked with * are not yet in the discussion document that I created
> for the security team and which we intend to discuss at the summit.
>
> For all of these, the naming convention is "Section in document" > "Feature"
> : "Support status". The definition of support status is added at the end of
> the mail: note that the text has not yet been fully agreed, but seems to
> reflect fairly well how we handled stuff in the past.
>
> == On A / B: I think we should add ==
> - Resource Management > Null Scheduler : tech preview or experimental

I think that the interface is probably in a final form, the code is
complete, and there are no known bugs or issues; so I'd say tech
preview.

Dario, any opinions?

> - Virtual Firmware or PV Bootloader Support (not sure which) >  x86/Boot Xen
> on EFI platforms using GRUB2*  : ???

If I'm interpreting your phrase correctly, this probably goes under
"interoperability / hardware support"

> - Hardware > ARM/Alternative Runtime Patching (ARM32 and ARM64): ??? [note
> that this should probably have been added for 4.8, but I didn't add it]
> - Hardware > ARM/System Error Protection* : ???
> - Hardware > ARM/Wait for Virtual Interrupt* : ???
> - Hardware > x86/AVX512/Neural Network Instructions AVX512_4VNNIW* : ???
> - Hardware > x86/AVX512/Multiply Accumulation Single precision
> AVX512_4FMAPS* : ???
> - Device Models > DMOP (Device Model Operation Hypercall)  : ???

This is already used by default in the version of qemu released in
4.9, right?  I think I'd call that "supported".

> == On C ==
> - Security > Live Patching - see
> https://lists.xenproject.org/archives/html/xen-devel/2017-06/threads.html#03039
> - Security > Alternative 2pm : Supported – I think we should split this out
> – it is currently implicitly covered under "Virtual Machine Introspection"
>
> If we introduce a new heading "PV Protocols and Drivers" we should probably
> list all the common ones as supported in this heading, e.g.
> - PV Protocols and Drivers* > default (net, block, console, keyboard, mouse)
> : supported

I don't think there are keyboard and mouse PV protocols.  On the other
hand, I just realized that I have no idea how one uses PV guests with
a framebuffer but no mouse.

> There are also USB and framebuffer, which I am not sure whether they should
> be supported and if not, what their status is
> - PV Protocols and Drivers* > USB : ???

This one has been around a long time, then languished for a bit, but
it seems has been picked up by SuSE again.

I don't *think* we're doing USB testing in osstest yet (either HVM or PVUSB).

Juergen, are you guys actively doing internal testing of PVUSB?  If so
we could probably label that as 'supported' anyway.

> - PV Protocols and Drivers* > framebuffer : ???

This one has also been around forever.  I don't know who might be
using it, but I've never heard any complaints about it.  It should
probably be grandfathered in as "supported", at least for now.

 -George

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

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]

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@lists.xen.org
https://lists.xen.org/xen-devel

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

[Lars Kurth]

Hi all, (I think I CCed all stake-holders)

to finish off the release documentation for 4.9, I need to add an extra column 
to https://wiki.xenproject.org/wiki/Xen_Project_Release_Features – because I 
was travelling, this dropped of my radar. There several decisions to be made:
A) Decide which "features" to add
B) Decide on the status of the feature
C) Deal with status changes of any past features

The first goal would be to decide on A and any new "features" under C. For B, I 
am OK to add "???" for now and point to this thread, until we have concluded 
the discussion

Note that I tracked some of this as preparation for getting CNA status.  Items 
marked with * are not yet in the discussion document that I created for the 
security team and which we intend to discuss at the summit.

For all of these, the naming convention is "Section in document" > "Feature" : 
"Support status". The definition of support status is added at the end of the 
mail: note that the text has not yet been fully agreed, but seems to reflect 
fairly well how we handled stuff in the past.

== On A / B: I think we should add ==
- Resource Management > Null Scheduler : tech preview or experimental
- Virtual Firmware or PV Bootloader Support (not sure which) >  x86/Boot Xen on 
EFI platforms using GRUB2*  : ???
- Hardware > ARM/Alternative Runtime Patching (ARM32 and ARM64): ??? [note that 
this should probably have been added for 4.8, but I didn't add it]
- Hardware > ARM/System Error Protection* : ???
- Hardware > ARM/Wait for Virtual Interrupt* : ???
- Hardware > x86/AVX512/Neural Network Instructions AVX512_4VNNIW* : ???
- Hardware > x86/AVX512/Multiply Accumulation Single precision AVX512_4FMAPS* : 
???
- Device Models > DMOP (Device Model Operation Hypercall)  : ???

New Heading:  PV Protocols and Drivers
- PV Protocols and Drivers > pvcalls : tech preview or experimental
- PV Protocols and Drivers > 9pfs : tech preview or experimental
- PV Protocols and Drivers* > sndif (sound device) : tech preview or 
experimental
- PV Protocols and Drivers* > displif (PV display) : tech preview or 
experimental

Did I miss anything?

== On C ==
- Security > Live Patching - see 
https://lists.xenproject.org/archives/html/xen-devel/2017-06/threads.html#03039
- Security > Alternative 2pm : Supported – I think we should split this out – 
it is currently implicitly covered under "Virtual Machine Introspection"

If we introduce a new heading "PV Protocols and Drivers" we should probably 
list all the common ones as supported in this heading, e.g.
- PV Protocols and Drivers* > default (net, block, console, keyboard, mouse) : 
supported

There are also USB and framebuffer, which I am not sure whether they should be 
supported and if not, what their status is
- PV Protocols and Drivers* > USB : ???
- PV Protocols and Drivers* > framebuffer : ???

Suggestions are welcome

Best Regards
Lars



## Definitions

### User-facing Support Criteria

 * **Functionally complete:** Does it behave like a fully functional
   feature?  Does it work on all expected platforms, or does it only work
   for a very specific sub-case?  Does it have a sensible UI, or do you
   have to have a deep understanding of the internals to get it to work
   properly?

 * **Functional stability:** What is the risk of it exhibiting bugs?

   General answers to the above:

   - *Here be dragons*: Pretty likely to still crash / fail to work.  Not
 recommended unless you like life on the bleeding edge.
   - *Quirky*: Mostly works but may have odd behavior here and there.
 Recommended for playing around or for non-production use cases.
   - *Normal*: Ready for production use

*  **Interface stability:**  If I build a system based on the current
   interfaces, will they still work when I upgrade to the next version?

   - *Not stable*: Interface is still in the early stages and still fairly
 likely to be broken in future updates.
   - *Provisionally stable*: We're not yet promising backwards
 compatibility, but we think this is probably the final form of the
 interface.  It may still require some tweaks.
   - *Stable*: We will try very hard to avoid breaking backwards
 compatibility, and to fix any regressions that are reported.

*  **Security supported:** Will XSAs be issued if security-related bugs are
   discovered in the functionality?

### Definition of Support Labels

Rather than specify each level above, we have some short-hand labels that we 
use to denote general answer to the above questions.

# Experimental
 Functional completeness: No
 Functional stability: Here be dragons
 Interface stability: Not stable
 Security supported: No

# Tech Preview
 Functional completeness: Yes
 Functional stability: Quirky
 Interface stability: Provisionally stable
 Security supported: No.

# Supported
 Functional completeness: Yes
 Functional stability: Normal
 Interface stability: Yes
 Security supported: Yes

# Deprecated
 Functional completeness: Yes
 Functional