Re: [Xen-devel] [For 4.9] Updating https://wiki.xenproject.org/wiki/Xen_Project_Release_Features to reflect support status of new features
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 the next version? >
Re: [Xen-devel] [For 4.9] Updating https://wiki.xenproject.org/wiki/Xen_Project_Release_Features to reflect support status of new features
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 Functional
Re: [Xen-devel] [For 4.9] Updating https://wiki.xenproject.org/wiki/Xen_Project_Release_Features to reflect support status of new features
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
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
>>> 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
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
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&D 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 stab