[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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 <lars.kurth@xxxxxxxxxx> 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@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |