All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars Kurth <lars.kurth@citrix.com>
To: "Juergen Groß" <jgross@suse.com>,
	"George Dunlap" <George.Dunlap@citrix.com>
Cc: Dario Faggioli <dario.faggioli@citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	"committers@xenproject.org" <committers@xenproject.org>
Subject: Re: [For 4.9] Updating https://wiki.xenproject.org/wiki/Xen_Project_Release_Features to reflect support status of new features
Date: Tue, 27 Jun 2017 11:04:15 +0000	[thread overview]
Message-ID: <D577F949.38A61%lars.kurth@citrix.com> (raw)
In-Reply-To: <82c05e28-18ce-4c9e-f0f4-589d7617e831@suse.com>



On 27/06/2017, 11:57, "Juergen Groß" <jgross@suse.com> wrote:

>On 06/27/2017 12:33 PM, George Dunlap wrote:
>> On Tue, Jun 27, 2017 at 9:53 AM, Lars Kurth <lars.kurth@citrix.com>
>>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

  reply	other threads:[~2017-06-27 11:04 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-27  8:53 [For 4.9] Updating https://wiki.xenproject.org/wiki/Xen_Project_Release_Features to reflect support status of new features Lars Kurth
2017-06-27  9:48 ` Razvan Cojocaru
2017-06-27 10:41   ` Lars Kurth
2017-06-27 17:47   ` Tamas K Lengyel
2017-06-27 10:33 ` George Dunlap
2017-06-27 10:54   ` Lars Kurth
2017-06-27 10:57   ` Juergen Groß
2017-06-27 11:04     ` Lars Kurth [this message]
2017-06-27 15:23       ` Wei Liu
2017-06-27 15:44       ` Dario Faggioli
2017-06-27 11:02 ` George Dunlap
2017-06-27 11:06   ` Lars Kurth
2017-06-27 13:25 ` Oleksandr Andrushchenko
2017-06-27 13:28 ` Oleksandr Andrushchenko
2017-06-27 13:30   ` Lars Kurth
2017-06-27 13:32     ` Oleksandr Andrushchenko
2017-06-27 16:00 ` Julien Grall
2017-06-27 16:16 ` Jan Beulich
2017-06-27 21:02   ` Lars Kurth
2017-08-17 14:48 ` Julien Grall
2017-08-17 14:51   ` Lars Kurth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D577F949.38A61%lars.kurth@citrix.com \
    --to=lars.kurth@citrix.com \
    --cc=George.Dunlap@citrix.com \
    --cc=committers@xenproject.org \
    --cc=dario.faggioli@citrix.com \
    --cc=jgross@suse.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.