Xen 4.9 Development Update

Xen 4.9 Development Update

[Julien Grall]

This email only tracks big items for xen.git tree. Please reply for items you
woulk like to see in 4.9 so that people have an idea what is going on and
prioritise accordingly.

You're welcome to provide description and use cases of the feature you're
working on.

= Timeline =

We now adopt a fixed cut-off date scheme. We will release twice a
year. The upcoming 4.9 timeline are as followed:

* Last posting date: March 17th, 2017
* Hard code freeze: March 31th, 2017
* RC1: TBD
* Release: June 2, 2017

Note that we don't have freeze exception scheme anymore. All patches
that wish to go into 4.9 must be posted no later than the last posting
date. All patches posted after that date will be automatically queued
into next release.

RCs will be arranged immediately after freeze.

= Projects =

== Hypervisor == 

*  Boot Xen on EFI platforms using GRUB2 (multiboot2 protocol)
  -  Daniel Kiper

*  Per-cpu tasklet
  -  Konrad Rzeszutek Wilk

=== x86 === 

*  Allow ioreq server interface to support XenGT
  -  Yu Zhang
  -  Paul Durrant

*  PVHv2 support
  -  Roger Pau Monne

*  vNVDIMM support
  -  Haozhong Zhang

*  Completion of the x86 insn emulator (as far as possible)
  -  Jan Beulich

*  Getting guest CPUID handling into a better shape
  -  Andrew Cooper

*  Enable L2 Cache Allocation Technology
  -  Yi Sun

*  Enable Memory Bandwidth Allocation
  -  Yi Sun

=== ARM === 

*  ITS emulation (Dom0 only)
  -  Andre Przywara

*  Altp2m for ARM
  -  Sergej Proskurin

*  Support Tegra SoCs
  -  Kyle Temkin

== Toolstack == 

*  Libxl PVSCSI support
  -  Olaf Hering

*  Libxl depriv QEMU
  -  Ian Jackson

*  Remove blktap2
  -  Wei Liu

== Mini-OS == 

== PV Drivers == 

*  Xen transport for 9pfs
  -  Stefano Stabellini

*  PV calls
  -  Stefano Stabellini

== GRUB == 

*  Support booting Xen ARM
  -  Fu Wei

== Testing == 

*  Continuous fuzzing of Xen code using Google oss-fuzz
  -  Wei Liu

== Blocker == 

*  Fix issues with zero-length records in migration v2
  Link: https://bugs.xenproject.org/xen/bug/56
  -  Andrew Cooper

== Completed == 

*  Rework gcov support in hypervisor
  -  Wei Liu

*  XenStore XS_DIRECTORY_PART extension
  -  Juergen Gross


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

Re: Xen 4.9 Development Update

[Oleksandr Tyshchenko]

Hi, all

On Tue, Mar 28, 2017 at 5:20 PM, Julien Grall <julien.grall@arm.com> wrote:
> This email only tracks big items for xen.git tree. Please reply for items you
> woulk like to see in 4.9 so that people have an idea what is going on and
> prioritise accordingly.
>
> You're welcome to provide description and use cases of the feature you're
> working on.
>
> = Timeline =
>
> We now adopt a fixed cut-off date scheme. We will release twice a
> year. The upcoming 4.9 timeline are as followed:
>
> * Last posting date: March 24th, 2017
> * Hard code freeze: April 7th, 2017
> * RC1: TBD
> * Release: June 2, 2017
>
> Note that we don't have freeze exception scheme anymore. All patches
> that wish to go into 4.9 must be posted no later than the last posting
> date. All patches posted after that date will be automatically queued
> into next release.
>
> RCs will be arranged immediately after freeze.
>
> We recently introduced a jira instance to track all the tasks (not only big)
> for the project. See: https://xenproject.atlassian.net/projects/XEN/issues.
>
> Most of the tasks tracked by this e-mail also have a corresponding jira task
> referred by XEN-N.
>
> = Projects =
>
> == Hypervisor ==
>
> *  Per-cpu tasklet
>   -  XEN-28
>   -  Konrad Rzeszutek Wilk
>
> *  Add support of rcu_idle_{enter,exit}
>   -  XEN-27
>   -  Dario Faggioli
>
> === x86 ===
>
> *  Boot Xen on EFI platforms using GRUB2 (multiboot2 protocol) (v16)
>   -  XEN-42
>   -  Daniel Kiper
>
> *  Allow ioreq server interface to support XenGT (v7)
>   -  XEN-43
>   -  Yu Zhang
>   -  Paul Durrant
>
> *  PVHv2 support
>   -  XEN-44
>   -  Roger Pau Monne
>
> *  vNVDIMM support for HVM (RFC)
>   -  XEN-45
>   -  Haozhong Zhang
>
> *  Completion of the x86 insn emulator (as far as possible)
>   -  XEN-46
>   -  Jan Beulich
>
> *  Getting guest CPUID handling into a better shape
>   -  XEN-47
>   -  Andrew Cooper
>
> *  Enable L2 Cache Allocation Technology (v8)
>   -  XEN-37
>   -  Yi Sun
>
> *  Enable Memory Bandwidth Allocation (RFC)
>   -  XEN-48
>   -  Yi Sun
>
> *  Intel LMCE support: (v2)
>   -  XEN-68
>   -  Haozhon Zhang
>
> === ARM ===
>
> *  ITS emulation (Dom0 only) (v1)
>   -  XEN-2
>   -  Andre Przywara
>
> *  Support Tegra SoCs (RFC)
>   -  XEN-49
>   -  Kyle Temkin
>
> == Toolstack ==
>
> *  Libxl PVSCSI support (v13)
>   -  XEN-50
>   -  Olaf Hering
>
> *  Libxl depriv QEMU
>   -  Ian Jackson
>
> *  Remove blktap2
>   -  XEN-8
>   -  Wei Liu
>
> == Mini-OS ==
>
> == PV Drivers ==
>
> *  Xen transport for 9pfs
>   -  XEN-51
>   -  Stefano Stabellini
>
> *  PV calls
>   -  XEN-63
>   -  Stefano Stabellini
>
> *  Multi-touch
>   -  Oleksandr Andrushchenko
>   -  Oleksanr Grytsov
>
> *  Sound
>   -  Oleksandr Andrushchenko
>   -  Oleksanr Grytsov
>
> *  Display
>   -  Oleksandr Andrushchenko
>   -  Oleksanr Grytsov
>
> == GRUB ==
>
> *  Support booting Xen ARM
>   -  XEN-67
>   -  Fu Wei
>
> == Testing ==
>
> *  Continuous fuzzing of Xen code using Google oss-fuzz
>   -  Wei Liu
>
> == Blocker ==
>
> *  Fix issues with zero-length records in migration v2
>   -  XEN-5
>   -  Andrew Cooper
>
> == Completed ==
>
> *  Rework gcov support in hypervisor
>   -  Wei Liu
>
> *  XenStore XS_DIRECTORY_PART extension
>   -  Juergen Gross
>
> == Deferred ==
>
> *  Altp2m for ARM
>   -  Sergej Proskurin
>
>
> = Notes =
>
> * Revert commit 997382b771 or surround the code with NDEBUG before the
>   release (see e-mail <58A2EF4E02000078001399F9@prv-mh.provo.novell.com>)
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel

Hi, all.

I am working on both non-shared IOMMU support on ARM and IPMMU-VMSA driver.
Now they are RFC patches [1]. Want to see them in Xen 4.10).

[1] https://lists.xen.org/archives/html/xen-devel/2017-03/msg01905.html

-- 
Regards,

Oleksandr Tyshchenko

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

Xen 4.9 Development Update

[Julien Grall]

This email only tracks big items for xen.git tree. Please reply for items you
woulk like to see in 4.9 so that people have an idea what is going on and
prioritise accordingly.

You're welcome to provide description and use cases of the feature you're
working on.

= Timeline =

We now adopt a fixed cut-off date scheme. We will release twice a
year. The upcoming 4.9 timeline are as followed:

* Last posting date: March 24th, 2017
* Hard code freeze: April 7th, 2017
* RC1: TBD
* Release: June 2, 2017

Note that we don't have freeze exception scheme anymore. All patches
that wish to go into 4.9 must be posted no later than the last posting
date. All patches posted after that date will be automatically queued
into next release.

RCs will be arranged immediately after freeze.

We recently introduced a jira instance to track all the tasks (not only big)
for the project. See: https://xenproject.atlassian.net/projects/XEN/issues.

Most of the tasks tracked by this e-mail also have a corresponding jira task
referred by XEN-N.

= Projects =

== Hypervisor == 

*  Per-cpu tasklet
  -  XEN-28
  -  Konrad Rzeszutek Wilk

*  Add support of rcu_idle_{enter,exit}
  -  XEN-27
  -  Dario Faggioli

=== x86 === 

*  Boot Xen on EFI platforms using GRUB2 (multiboot2 protocol) (v16)
  -  XEN-42
  -  Daniel Kiper

*  Allow ioreq server interface to support XenGT (v7)
  -  XEN-43
  -  Yu Zhang
  -  Paul Durrant

*  PVHv2 support
  -  XEN-44
  -  Roger Pau Monne

*  vNVDIMM support for HVM (RFC)
  -  XEN-45
  -  Haozhong Zhang

*  Completion of the x86 insn emulator (as far as possible)
  -  XEN-46
  -  Jan Beulich

*  Getting guest CPUID handling into a better shape
  -  XEN-47
  -  Andrew Cooper

*  Enable L2 Cache Allocation Technology (v8)
  -  XEN-37
  -  Yi Sun

*  Enable Memory Bandwidth Allocation (RFC)
  -  XEN-48
  -  Yi Sun

*  Intel LMCE support: (v2)
  -  XEN-68
  -  Haozhon Zhang

=== ARM === 

*  ITS emulation (Dom0 only) (v1)
  -  XEN-2
  -  Andre Przywara

*  Support Tegra SoCs (RFC)
  -  XEN-49
  -  Kyle Temkin

== Toolstack == 

*  Libxl PVSCSI support (v13)
  -  XEN-50
  -  Olaf Hering

*  Libxl depriv QEMU
  -  Ian Jackson

*  Remove blktap2
  -  XEN-8
  -  Wei Liu

== Mini-OS == 

== PV Drivers == 

*  Xen transport for 9pfs
  -  XEN-51
  -  Stefano Stabellini

*  PV calls
  -  XEN-63
  -  Stefano Stabellini

*  Multi-touch
  -  Oleksandr Andrushchenko
  -  Oleksanr Grytsov

*  Sound
  -  Oleksandr Andrushchenko
  -  Oleksanr Grytsov

*  Display
  -  Oleksandr Andrushchenko
  -  Oleksanr Grytsov

== GRUB == 

*  Support booting Xen ARM
  -  XEN-67
  -  Fu Wei

== Testing == 

*  Continuous fuzzing of Xen code using Google oss-fuzz
  -  Wei Liu

== Blocker == 

*  Fix issues with zero-length records in migration v2
  -  XEN-5
  -  Andrew Cooper

== Completed == 

*  Rework gcov support in hypervisor
  -  Wei Liu

*  XenStore XS_DIRECTORY_PART extension
  -  Juergen Gross

== Deferred == 

*  Altp2m for ARM
  -  Sergej Proskurin


= Notes =

* Revert commit 997382b771 or surround the code with NDEBUG before the
  release (see e-mail <58A2EF4E02000078001399F9@prv-mh.provo.novell.com>)


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

Re: Xen 4.9 Development Update

[Oleksandr Andrushchenko]

On 01/30/2017 05:33 PM, Julien Grall wrote:
> This email only tracks big items for xen.git tree. Please reply for items you
> woulk like to see in 4.9 so that people have an idea what is going on and
> prioritise accordingly.
> == PV Drivers ==
>
> *  Xen transport for 9pfs
>    -  Stefano Stabellini
>
> *  PV calls
>    -  Stefano Stabellini
>
Are you considering other PV protocols for this drop? E.g.
multi-touch support, sound and display?

Thank you,
Oleksandr


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

Re: Xen 4.9 Development Update

[Julien Grall]

(CC Konrad)

Hi Oleksandr,

On 31/01/17 13:51, Oleksandr Andrushchenko wrote:
>
> On 01/30/2017 05:33 PM, Julien Grall wrote:
>> This email only tracks big items for xen.git tree. Please reply for
>> items you
>> woulk like to see in 4.9 so that people have an idea what is going on and
>> prioritise accordingly.
>> == PV Drivers ==
>>
>> *  Xen transport for 9pfs
>>    -  Stefano Stabellini
>>
>> *  PV calls
>>    -  Stefano Stabellini
>>
> Are you considering other PV protocols for this drop? E.g.
> multi-touch support, sound and display?

That would be up to you and Konrad :).

Anyway, I am going to track any big inflight items even those not 
planned for next release. This will give us an overview of what's going on.

What is the list of PV protocols you have in mind? And do you know who 
will work on it?

Also, I should probably track separately the backend/frontend support if 
you plan to upstream them later.

Cheers,

-- 
Julien Grall

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

Re: Xen 4.9 Development Update

[Konrad Rzeszutek Wilk]

On Wed, Feb 08, 2017 at 06:03:00PM +0000, Julien Grall wrote:
> (CC Konrad)
> 
> Hi Oleksandr,
> 
> On 31/01/17 13:51, Oleksandr Andrushchenko wrote:
> > 
> > On 01/30/2017 05:33 PM, Julien Grall wrote:
> > > This email only tracks big items for xen.git tree. Please reply for
> > > items you
> > > woulk like to see in 4.9 so that people have an idea what is going on and
> > > prioritise accordingly.
> > > == PV Drivers ==
> > > 
> > > *  Xen transport for 9pfs
> > >    -  Stefano Stabellini
> > > 
> > > *  PV calls
> > >    -  Stefano Stabellini
> > > 
> > Are you considering other PV protocols for this drop? E.g.
> > multi-touch support, sound and display?
> 
> That would be up to you and Konrad :).

I think we only have one left from Oleksandr. Two of them have been
reviewed by me today.
> 
> Anyway, I am going to track any big inflight items even those not planned
> for next release. This will give us an overview of what's going on.
> 
> What is the list of PV protocols you have in mind? And do you know who will
> work on it?
> 
> Also, I should probably track separately the backend/frontend support if you
> plan to upstream them later.
> 
> Cheers,
> 
> -- 
> Julien Grall

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

Re: Xen 4.9 Development Update

[Oleksandr Andrushchenko]

On 02/08/2017 08:17 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Feb 08, 2017 at 06:03:00PM +0000, Julien Grall wrote:
>> (CC Konrad)
>>
>> Hi Oleksandr,
>>
>> On 31/01/17 13:51, Oleksandr Andrushchenko wrote:
>>> On 01/30/2017 05:33 PM, Julien Grall wrote:
>>>> This email only tracks big items for xen.git tree. Please reply for
>>>> items you
>>>> woulk like to see in 4.9 so that people have an idea what is going on and
>>>> prioritise accordingly.
>>>> == PV Drivers ==
>>>>
>>>> *  Xen transport for 9pfs
>>>>     -  Stefano Stabellini
>>>>
>>>> *  PV calls
>>>>     -  Stefano Stabellini
>>>>
>>> Are you considering other PV protocols for this drop? E.g.
>>> multi-touch support, sound and display?
>> That would be up to you and Konrad :).
> I think we only have one left from Oleksandr.
That is correct (namely displif is on my list)
> Two of them have been
> reviewed by me today.
>> Anyway, I am going to track any big inflight items even those not planned
>> for next release. This will give us an overview of what's going on.
>>
>> What is the list of PV protocols you have in mind? And do you know who will
>> work on it?
>>
>> Also, I should probably track separately the backend/frontend support if you
>> plan to upstream them later.
We do. We only miss the corresponding protocols in the trees (both Xen and
the kernel), so we can start updating *existing* backs/fronts/libs for
sndif/displif/DRM zero-copy/multi-touch and get those ready for upstreaming
>>
>> Cheers,
>>
>> -- 
>> Julien Grall


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

Re: Xen 4.9 Development Update

[Julien Grall]

Hi Oleksandr,

On 08/02/17 18:56, Oleksandr Andrushchenko wrote:
> On 02/08/2017 08:17 PM, Konrad Rzeszutek Wilk wrote:
>> On Wed, Feb 08, 2017 at 06:03:00PM +0000, Julien Grall wrote:
>>> (CC Konrad)
>>>
>>> Hi Oleksandr,
>>>
>>> On 31/01/17 13:51, Oleksandr Andrushchenko wrote:
>>>> On 01/30/2017 05:33 PM, Julien Grall wrote:
>>>>> This email only tracks big items for xen.git tree. Please reply for
>>>>> items you
>>>>> woulk like to see in 4.9 so that people have an idea what is going
>>>>> on and
>>>>> prioritise accordingly.
>>>>> == PV Drivers ==
>>>>>
>>>>> *  Xen transport for 9pfs
>>>>>     -  Stefano Stabellini
>>>>>
>>>>> *  PV calls
>>>>>     -  Stefano Stabellini
>>>>>
>>>> Are you considering other PV protocols for this drop? E.g.
>>>> multi-touch support, sound and display?
>>> That would be up to you and Konrad :).
>> I think we only have one left from Oleksandr.
> That is correct (namely displif is on my list)
>> Two of them have been
>> reviewed by me today.
>>> Anyway, I am going to track any big inflight items even those not
>>> planned
>>> for next release. This will give us an overview of what's going on.
>>>
>>> What is the list of PV protocols you have in mind? And do you know
>>> who will
>>> work on it?
>>>
>>> Also, I should probably track separately the backend/frontend support
>>> if you
>>> plan to upstream them later.
> We do. We only miss the corresponding protocols in the trees (both Xen and
> the kernel), so we can start updating *existing* backs/fronts/libs for
> sndif/displif/DRM zero-copy/multi-touch and get those ready for upstreaming

Ok, I will add separate items for the backend/frontend of each PV 
drivers. Shall I put your name under them?

Cheers,

-- 
Julien Grall

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

Re: Xen 4.9 Development Update

[Oleksandr Andrushchenko]

On 02/08/2017 09:29 PM, Julien Grall wrote:
> Hi Oleksandr,
>
> On 08/02/17 18:56, Oleksandr Andrushchenko wrote:
>> On 02/08/2017 08:17 PM, Konrad Rzeszutek Wilk wrote:
>>> On Wed, Feb 08, 2017 at 06:03:00PM +0000, Julien Grall wrote:
>>>> (CC Konrad)
>>>>
>>>> Hi Oleksandr,
>>>>
>>>> On 31/01/17 13:51, Oleksandr Andrushchenko wrote:
>>>>> On 01/30/2017 05:33 PM, Julien Grall wrote:
>>>>>> This email only tracks big items for xen.git tree. Please reply for
>>>>>> items you
>>>>>> woulk like to see in 4.9 so that people have an idea what is going
>>>>>> on and
>>>>>> prioritise accordingly.
>>>>>> == PV Drivers ==
>>>>>>
>>>>>> *  Xen transport for 9pfs
>>>>>>     -  Stefano Stabellini
>>>>>>
>>>>>> *  PV calls
>>>>>>     -  Stefano Stabellini
>>>>>>
>>>>> Are you considering other PV protocols for this drop? E.g.
>>>>> multi-touch support, sound and display?
>>>> That would be up to you and Konrad :).
>>> I think we only have one left from Oleksandr.
>> That is correct (namely displif is on my list)
>>> Two of them have been
>>> reviewed by me today.
>>>> Anyway, I am going to track any big inflight items even those not
>>>> planned
>>>> for next release. This will give us an overview of what's going on.
>>>>
>>>> What is the list of PV protocols you have in mind? And do you know
>>>> who will
>>>> work on it?
>>>>
>>>> Also, I should probably track separately the backend/frontend support
>>>> if you
>>>> plan to upstream them later.
>> We do. We only miss the corresponding protocols in the trees (both 
>> Xen and
>> the kernel), so we can start updating *existing* backs/fronts/libs for
>> sndif/displif/DRM zero-copy/multi-touch and get those ready for 
>> upstreaming
>
> Ok, I will add separate items for the backend/frontend of each PV 
> drivers. Shall I put your name under them?
I mostly work on protocol/kernel side, so for the frontends/protocols - 
yes, please
For the backends and backend helper library - Oleksandr Grytsov will be 
the right guy
>
> Cheers,
>
Thank you

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

Re: Xen 4.9 Development Update

[Julien Grall]

On 08/02/17 18:17, Konrad Rzeszutek Wilk wrote:
> On Wed, Feb 08, 2017 at 06:03:00PM +0000, Julien Grall wrote:
>> (CC Konrad)
>>
>> Hi Oleksandr,
>>
>> On 31/01/17 13:51, Oleksandr Andrushchenko wrote:
>>>
>>> On 01/30/2017 05:33 PM, Julien Grall wrote:
>>>> This email only tracks big items for xen.git tree. Please reply for
>>>> items you
>>>> woulk like to see in 4.9 so that people have an idea what is going on and
>>>> prioritise accordingly.
>>>> == PV Drivers ==
>>>>
>>>> *  Xen transport for 9pfs
>>>>    -  Stefano Stabellini
>>>>
>>>> *  PV calls
>>>>    -  Stefano Stabellini
>>>>
>>> Are you considering other PV protocols for this drop? E.g.
>>> multi-touch support, sound and display?
>>
>> That would be up to you and Konrad :).
>
> I think we only have one left from Oleksandr. Two of them have been
> reviewed by me today.

2 more cool new features for next release! I will move them in the 
completed category when merged.

Cheers,

-- 
Julien Grall

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

Re: Xen 4.9 Development Update

[Tamas K Lengyel]

[-- Attachment #1.1: Type: text/plain, Size: 248 bytes --]

>
>
> *  Altp2m for ARM
>   -  Sergej Proskurin
>

This was a GSoC project last summer that unfortunately didn't make the
merge window. I'll probably pick it up sometime in the future and get it
rebased but it is unlikely to happen for 4.9.

Tamas

[-- Attachment #1.2: Type: text/html, Size: 531 bytes --]

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

Re: Xen 4.9 Development Update

[Sergej Proskurin]

Hi all,

Unfortunately, I have been quite busy over the last few months and did
not manage to finish the patch series, yet. I will continue working in
the next few weeks, however, it is rather unlikely to make the patch
series ready for 4.9.

Cheers
~Sergej

On 02/08/2017 07:59 PM, Tamas K Lengyel wrote:
> 
>     *  Altp2m for ARM
>       -  Sergej Proskurin
> 
> 
> This was a GSoC project last summer that unfortunately didn't make the
> merge window. I'll probably pick it up sometime in the future and get it
> rebased but it is unlikely to happen for 4.9.
> 
> Tamas
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel
> 


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

Re: Xen 4.9 Development Update

[Haozhong Zhang]

On 01/30/17 15:33 +0000, Julien Grall wrote:
> This email only tracks big items for xen.git tree. Please reply for items you
> woulk like to see in 4.9 so that people have an idea what is going on and
> prioritise accordingly.
> 
> You're welcome to provide description and use cases of the feature you're
> working on.
> 
> = Timeline =
> 
> We now adopt a fixed cut-off date scheme. We will release twice a
> year. The upcoming 4.9 timeline are as followed:
> 
> * Last posting date: March 17th, 2017
> * Hard code freeze: March 31th, 2017
> * RC1: TBD
> * Release: June 2, 2017
> 
> Note that we don't have freeze exception scheme anymore. All patches
> that wish to go into 4.9 must be posted no later than the last posting
> date. All patches posted after that date will be automatically queued
> into next release.
> 
> RCs will be arranged immediately after freeze.
> 
> = Projects =
> 
> === x86 === 

Add Intel LMCE support:

* Intel LMCE support
 -  Haozhong Zhang

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

Re: Xen 4.9 Development Update

[Wei Liu]

On Mon, Jan 30, 2017 at 03:33:19PM +0000, Julien Grall wrote:
> 
> == Testing == 
> 
> *  Continuous fuzzing of Xen code using Google oss-fuzz
>   -  Wei Liu
> 

Stuck as we need someone to write the code to integrate things into
oss-fuzz.

Wei.

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

Re: Xen 4.9 Development Update

[Jan Beulich]

>>> On 08.12.16 at 16:12, <julien.grall@arm.com> wrote:
> = Projects =
> 
> == Hypervisor == 
> 
> *  Boot Xen on EFI platforms using GRUB2 (multiboot2 protocol)
>   -  Daniel Kiper
> 
> *  Per-cpu tasklet
>   -  Konrad Rzeszutek Wilk
> 
> === x86 === 
> 
> *  Allow ioreq server interface to support XenGT
>   -  Yu Zhang
>   -  Paul Durrant
> 
> *  PVHv2 support
>   -  Roger Pau Monne
> 
> *  vNVDIMM support
>   -  Haozhong Zhang

* Completion of the x86 insn emulator (as far as possible; me)

* Getting guest CPUID handling into better shape (Andrew)

Jan


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

Re: Xen 4.9 Development Update

[Wei Liu]

On Thu, Dec 08, 2016 at 03:12:12PM +0000, Julien Grall wrote:
[...]
> == Toolstack == 
> 
> *  Logging solution for Xen system
>   -  Wei Liu
> 

Not enough interest, please drop this for now.

> *  Remove blktap2
>   -  Wei Liu
> 

Under discussion with user.

> == Mini-OS == 
> 
> == GRUB == 
> 
> *  Support booting Xen ARM
>   -  Fu Wei
> 
> == Testing == 
> 

Continuous fuzzing of Xen code using Google oss-fuzz (Wei)

> == Completed == 
> 

Rework gcov support in hypervisor (Wei)

Xenstore XS_DIRECTORY_PART extension (Juergen)

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

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

Re: Xen 4.9 Development Update

[Jan Beulich]

>>> On 08.12.16 at 16:36, <wei.liu2@citrix.com> wrote:
> On Thu, Dec 08, 2016 at 03:12:12PM +0000, Julien Grall wrote:
> [...]
>> == Toolstack == 
>> 
>> *  Logging solution for Xen system
>>   -  Wei Liu
>> 
> 
> Not enough interest, please drop this for now.

Possibly slightly related: What's the situation with the runtime log
level adjustments? My old series predating the whole 4.8 cycle I
wonder whether I shouldn't strip off the sysctl and tool stack
parts and at least try to get the serial console based stuff in.

Jan


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

Re: Xen 4.9 Development Update

[Wei Liu]

On Thu, Dec 08, 2016 at 08:57:21AM -0700, Jan Beulich wrote:
> >>> On 08.12.16 at 16:36, <wei.liu2@citrix.com> wrote:
> > On Thu, Dec 08, 2016 at 03:12:12PM +0000, Julien Grall wrote:
> > [...]
> >> == Toolstack == 
> >> 
> >> *  Logging solution for Xen system
> >>   -  Wei Liu
> >> 
> > 
> > Not enough interest, please drop this for now.
> 
> Possibly slightly related: What's the situation with the runtime log
> level adjustments? My old series predating the whole 4.8 cycle I
> wonder whether I shouldn't strip off the sysctl and tool stack
> parts and at least try to get the serial console based stuff in.

Sure. I think that's a good idea. I won't be working on that any time
soon.

Wei.

> 
> Jan
> 

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

Xen 4.9 Development Update

[Julien Grall]

This email only tracks big items for xen.git tree. Please reply for items you
woulk like to see in 4.9 so that people have an idea what is going on and
prioritise accordingly.

You're welcome to provide description and use cases of the feature you're
working on.

= Timeline =

We now adopt a fixed cut-off date scheme. We will release twice a
year. The upcoming 4.9 timeline are as followed:

* Last posting date: March 17th, 2017
* Hard code freeze: March 31th, 2017
* RC1: TBD
* Release: June 2, 2017

Note that we don't have freeze exception scheme anymore. All patches
that wish to go into 4.9 must be posted no later than the last posting
date. All patches posted after that date will be automatically queued
into next release.

RCs will be arranged immediately after freeze.

= Projects =

== Hypervisor == 

*  Boot Xen on EFI platforms using GRUB2 (multiboot2 protocol)
  -  Daniel Kiper

*  Per-cpu tasklet
  -  Konrad Rzeszutek Wilk

=== x86 === 

*  Allow ioreq server interface to support XenGT
  -  Yu Zhang
  -  Paul Durrant

*  PVHv2 support
  -  Roger Pau Monne

*  vNVDIMM support
  -  Haozhong Zhang

=== ARM === 

*  ITS emulation (Dom0 only)
  -  Andre Przywara

*  Altp2m for ARM
  -  Sergej Proskurin

*  Support Tegra SoCs
  -  Kyle Temkin

== Toolstack == 

*  Libxl PVSCSI support
  -  Olaf Hering

*  Libxl depriv QEMU
  -  Ian Jackson

*  Logging solution for Xen system
  -  Wei Liu

*  Remove blktap2
  -  Wei Liu

== Mini-OS == 

== GRUB == 

*  Support booting Xen ARM
  -  Fu Wei

== Testing == 

== Completed == 


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

Re: Xen 4.9 Development Update

[Stefano Stabellini]

On Thu, 8 Dec 2016, Julien Grall wrote:
> This email only tracks big items for xen.git tree. Please reply for items you
> woulk like to see in 4.9 so that people have an idea what is going on and
> prioritise accordingly.
> 
> You're welcome to provide description and use cases of the feature you're
> working on.
> 
> = Timeline =
> 
> We now adopt a fixed cut-off date scheme. We will release twice a
> year. The upcoming 4.9 timeline are as followed:
> 
> * Last posting date: March 17th, 2017
> * Hard code freeze: March 31th, 2017
> * RC1: TBD
> * Release: June 2, 2017
> 
> Note that we don't have freeze exception scheme anymore. All patches
> that wish to go into 4.9 must be posted no later than the last posting
> date. All patches posted after that date will be automatically queued
> into next release.
> 
> RCs will be arranged immediately after freeze.
> 
> = Projects =
> 
> == Hypervisor == 
> 
> *  Boot Xen on EFI platforms using GRUB2 (multiboot2 protocol)
>   -  Daniel Kiper
> 
> *  Per-cpu tasklet
>   -  Konrad Rzeszutek Wilk
> 
> === x86 === 
> 
> *  Allow ioreq server interface to support XenGT
>   -  Yu Zhang
>   -  Paul Durrant
> 
> *  PVHv2 support
>   -  Roger Pau Monne
> 
> *  vNVDIMM support
>   -  Haozhong Zhang
> 
> === ARM === 
> 
> *  ITS emulation (Dom0 only)
>   -  Andre Przywara
> 
> *  Altp2m for ARM
>   -  Sergej Proskurin
> 
> *  Support Tegra SoCs
>   -  Kyle Temkin
> 
> == Toolstack == 
> 
> *  Libxl PVSCSI support
>   -  Olaf Hering
> 
> *  Libxl depriv QEMU
>   -  Ian Jackson
> 
> *  Logging solution for Xen system
>   -  Wei Liu
> 
> *  Remove blktap2
>   -  Wei Liu
> 
> == Mini-OS == 
> 
> == GRUB == 
> 
> *  Support booting Xen ARM
>   -  Fu Wei
> 

Should we have a section on new PV drivers? If so, I suggest to add:
- Xen transport for 9pfs
- PV Calls


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

Re: Xen 4.9 Development Update

[Julien Grall]

Hi Stefano,

On 08/12/16 22:00, Stefano Stabellini wrote:
> On Thu, 8 Dec 2016, Julien Grall wrote:
>> This email only tracks big items for xen.git tree. Please reply for items you
>> woulk like to see in 4.9 so that people have an idea what is going on and
>> prioritise accordingly.
>>
>> You're welcome to provide description and use cases of the feature you're
>> working on.
>>
>> = Timeline =
>>
>> We now adopt a fixed cut-off date scheme. We will release twice a
>> year. The upcoming 4.9 timeline are as followed:
>>
>> * Last posting date: March 17th, 2017
>> * Hard code freeze: March 31th, 2017
>> * RC1: TBD
>> * Release: June 2, 2017
>>
>> Note that we don't have freeze exception scheme anymore. All patches
>> that wish to go into 4.9 must be posted no later than the last posting
>> date. All patches posted after that date will be automatically queued
>> into next release.
>>
>> RCs will be arranged immediately after freeze.
>>
>> = Projects =
>>
>> == Hypervisor ==
>>
>> *  Boot Xen on EFI platforms using GRUB2 (multiboot2 protocol)
>>   -  Daniel Kiper
>>
>> *  Per-cpu tasklet
>>   -  Konrad Rzeszutek Wilk
>>
>> === x86 ===
>>
>> *  Allow ioreq server interface to support XenGT
>>   -  Yu Zhang
>>   -  Paul Durrant
>>
>> *  PVHv2 support
>>   -  Roger Pau Monne
>>
>> *  vNVDIMM support
>>   -  Haozhong Zhang
>>
>> === ARM ===
>>
>> *  ITS emulation (Dom0 only)
>>   -  Andre Przywara
>>
>> *  Altp2m for ARM
>>   -  Sergej Proskurin
>>
>> *  Support Tegra SoCs
>>   -  Kyle Temkin
>>
>> == Toolstack ==
>>
>> *  Libxl PVSCSI support
>>   -  Olaf Hering
>>
>> *  Libxl depriv QEMU
>>   -  Ian Jackson
>>
>> *  Logging solution for Xen system
>>   -  Wei Liu
>>
>> *  Remove blktap2
>>   -  Wei Liu
>>
>> == Mini-OS ==
>>
>> == GRUB ==
>>
>> *  Support booting Xen ARM
>>   -  Fu Wei
>>
>
> Should we have a section on new PV drivers? If so, I suggest to add:
> - Xen transport for 9pfs
> - PV Calls

Good idea. We could also include DRM and PV Sound (CC Oleksandr).

Cheers,

-- 
Julien Grall

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

Re: Xen 4.9 Development Update

[Oleksandr Andrushchenko]

Hi, all!

On 12/09/2016 12:18 PM, Julien Grall wrote:
> Hi Stefano,
>
> On 08/12/16 22:00, Stefano Stabellini wrote:
>> On Thu, 8 Dec 2016, Julien Grall wrote:
>>> This email only tracks big items for xen.git tree. Please reply for 
>>> items you
>>> woulk like to see in 4.9 so that people have an idea what is going 
>>> on and
>>> prioritise accordingly.
>>>
>>> You're welcome to provide description and use cases of the feature 
>>> you're
>>> working on.
>>>
>>> = Timeline =
>>>
>>> We now adopt a fixed cut-off date scheme. We will release twice a
>>> year. The upcoming 4.9 timeline are as followed:
>>>
>>> * Last posting date: March 17th, 2017
>>> * Hard code freeze: March 31th, 2017
>>> * RC1: TBD
>>> * Release: June 2, 2017
>>>
>>> Note that we don't have freeze exception scheme anymore. All patches
>>> that wish to go into 4.9 must be posted no later than the last posting
>>> date. All patches posted after that date will be automatically queued
>>> into next release.
>>>
>>> RCs will be arranged immediately after freeze.
>>>
>>> = Projects =
>>>
>>> == Hypervisor ==
>>>
>>> *  Boot Xen on EFI platforms using GRUB2 (multiboot2 protocol)
>>>   -  Daniel Kiper
>>>
>>> *  Per-cpu tasklet
>>>   -  Konrad Rzeszutek Wilk
>>>
>>> === x86 ===
>>>
>>> *  Allow ioreq server interface to support XenGT
>>>   -  Yu Zhang
>>>   -  Paul Durrant
>>>
>>> *  PVHv2 support
>>>   -  Roger Pau Monne
>>>
>>> *  vNVDIMM support
>>>   -  Haozhong Zhang
>>>
>>> === ARM ===
>>>
>>> *  ITS emulation (Dom0 only)
>>>   -  Andre Przywara
>>>
>>> *  Altp2m for ARM
>>>   -  Sergej Proskurin
>>>
>>> *  Support Tegra SoCs
>>>   -  Kyle Temkin
>>>
>>> == Toolstack ==
>>>
>>> *  Libxl PVSCSI support
>>>   -  Olaf Hering
>>>
>>> *  Libxl depriv QEMU
>>>   -  Ian Jackson
>>>
>>> *  Logging solution for Xen system
>>>   -  Wei Liu
>>>
>>> *  Remove blktap2
>>>   -  Wei Liu
>>>
>>> == Mini-OS ==
>>>
>>> == GRUB ==
>>>
>>> *  Support booting Xen ARM
>>>   -  Fu Wei
>>>
>>
>> Should we have a section on new PV drivers? If so, I suggest to add:
>> - Xen transport for 9pfs
>> - PV Calls
>
> Good idea. We could also include DRM and PV Sound (CC Oleksandr).
>
This is a great idea. Let me explain what we have and what the direction is:
1. Frontends which we already have, working, but need to refactor/cleanup:
1.1. PV sound
1.2. PV DRM
1.3. DISPL protocol, I will push v1 for review right after sndif done
1.3. PV DRM mapper (Dom0 generic DRM driver to implement DRM zero copy
via DRM Prime buffer sharing)
1.4. PV events not done, but we are considering [1]. If it fits and is 
maintained,
then we'll probably stick to it, otherwise new PV will be created

2. Backends, for the above frontends already implemented:
2.1. A unified library for Xen backends (libxenbe)
2.2. DRM + Wayland
2.3. ALSA
2.4. Events not implemented yet

All the above sources are available on *public* Github repos
(I can provide links on request) and the intention is to
upstream.

3. We are interested in extending xl + libxl to support new PV drivers

Thank you,
Oleksandr

[1] https://github.com/xenbedded/openxt_kbdfront

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

Re: Xen 4.9 Development Update

[Pasi Kärkkäinen]

On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko wrote:
> >>
> >>Should we have a section on new PV drivers? If so, I suggest to add:
> >>- Xen transport for 9pfs
> >>- PV Calls
> >
> >Good idea. We could also include DRM and PV Sound (CC Oleksandr).
> >
> This is a great idea. Let me explain what we have and what the direction is:
> 1. Frontends which we already have, working, but need to refactor/cleanup:
> 1.1. PV sound
> 1.2. PV DRM
> 1.3. DISPL protocol, I will push v1 for review right after sndif done
> 1.3. PV DRM mapper (Dom0 generic DRM driver to implement DRM zero copy
> via DRM Prime buffer sharing)
> 1.4. PV events not done, but we are considering [1]. If it fits and
> is maintained,
> then we'll probably stick to it, otherwise new PV will be created
> 
> 2. Backends, for the above frontends already implemented:
> 2.1. A unified library for Xen backends (libxenbe)
> 2.2. DRM + Wayland
> 2.3. ALSA
> 2.4. Events not implemented yet
> 
> All the above sources are available on *public* Github repos
> (I can provide links on request) and the intention is to
> upstream.
>

Please do post the links.. 


Thanks,

-- Pasi
 
> 3. We are interested in extending xl + libxl to support new PV drivers
> 
> Thank you,
> Oleksandr
> 


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

Re: Xen 4.9 Development Update

[Oleksandr Andrushchenko]

On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote:
> On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko wrote:
>>>> Should we have a section on new PV drivers? If so, I suggest to add:
>>>> - Xen transport for 9pfs
>>>> - PV Calls
>>> Good idea. We could also include DRM and PV Sound (CC Oleksandr).
>>>
>> This is a great idea. Let me explain what we have and what the direction is:
>> 1. Frontends which we already have, working, but need to refactor/cleanup:
>> 1.1. PV sound
>> 1.2. PV DRM
>> 1.3. DISPL protocol, I will push v1 for review right after sndif done
>> 1.3. PV DRM mapper (Dom0 generic DRM driver to implement DRM zero copy
>> via DRM Prime buffer sharing)
>> 1.4. PV events not done, but we are considering [1]. If it fits and
>> is maintained,
>> then we'll probably stick to it, otherwise new PV will be created
>>
>> 2. Backends, for the above frontends already implemented:
>> 2.1. A unified library for Xen backends (libxenbe)
>> 2.2. DRM + Wayland
>> 2.3. ALSA
>> 2.4. Events not implemented yet
>>
>> All the above sources are available on *public* Github repos
>> (I can provide links on request) and the intention is to
>> upstream.
>>
> Please do post the links..
Please note these are all WIP:
1. Frontends
https://github.com/andr2000?tab=repositories
2. Backends
https://github.com/al1img?tab=repositories
>
> Thanks,
>
> -- Pasi
>   
>> 3. We are interested in extending xl + libxl to support new PV drivers
>>
>> Thank you,
>> Oleksandr
>>


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

Re: Xen 4.9 Development Update

[Stefano Stabellini]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1807 bytes --]

On Fri, 9 Dec 2016, Oleksandr Andrushchenko wrote:
> On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote:
> > On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko wrote:
> > > > > Should we have a section on new PV drivers? If so, I suggest to add:
> > > > > - Xen transport for 9pfs
> > > > > - PV Calls
> > > > Good idea. We could also include DRM and PV Sound (CC Oleksandr).
> > > > 
> > > This is a great idea. Let me explain what we have and what the direction
> > > is:
> > > 1. Frontends which we already have, working, but need to refactor/cleanup:
> > > 1.1. PV sound
> > > 1.2. PV DRM
> > > 1.3. DISPL protocol, I will push v1 for review right after sndif done
> > > 1.3. PV DRM mapper (Dom0 generic DRM driver to implement DRM zero copy
> > > via DRM Prime buffer sharing)
> > > 1.4. PV events not done, but we are considering [1]. If it fits and
> > > is maintained,
> > > then we'll probably stick to it, otherwise new PV will be created
> > > 
> > > 2. Backends, for the above frontends already implemented:
> > > 2.1. A unified library for Xen backends (libxenbe)
> > > 2.2. DRM + Wayland
> > > 2.3. ALSA
> > > 2.4. Events not implemented yet
> > > 
> > > All the above sources are available on *public* Github repos
> > > (I can provide links on request) and the intention is to
> > > upstream.
> > > 
> > Please do post the links..
> Please note these are all WIP:
> 1. Frontends
> https://github.com/andr2000?tab=repositories
> 2. Backends
> https://github.com/al1img?tab=repositories

Now, I don't want to sound pessimistic, but I thought I was being
audacious when I wrote both PV Calls and 9pfs for 4.9 - do you really
think it is feasable to complete upstreaming of PV sound, PV DRM, DISPL,
PV DRM frontends and backends, all by April? I would probably reduce the
list a bit.

[-- Attachment #2: Type: text/plain, Size: 127 bytes --]

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

Re: Xen 4.9 Development Update

[Andrew Cooper]

On 09/12/16 19:01, Stefano Stabellini wrote:
> On Fri, 9 Dec 2016, Oleksandr Andrushchenko wrote:
>> On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote:
>>> On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko wrote:
>>>>>> Should we have a section on new PV drivers? If so, I suggest to add:
>>>>>> - Xen transport for 9pfs
>>>>>> - PV Calls
>>>>> Good idea. We could also include DRM and PV Sound (CC Oleksandr).
>>>>>
>>>> This is a great idea. Let me explain what we have and what the direction
>>>> is:
>>>> 1. Frontends which we already have, working, but need to refactor/cleanup:
>>>> 1.1. PV sound
>>>> 1.2. PV DRM
>>>> 1.3. DISPL protocol, I will push v1 for review right after sndif done
>>>> 1.3. PV DRM mapper (Dom0 generic DRM driver to implement DRM zero copy
>>>> via DRM Prime buffer sharing)
>>>> 1.4. PV events not done, but we are considering [1]. If it fits and
>>>> is maintained,
>>>> then we'll probably stick to it, otherwise new PV will be created
>>>>
>>>> 2. Backends, for the above frontends already implemented:
>>>> 2.1. A unified library for Xen backends (libxenbe)
>>>> 2.2. DRM + Wayland
>>>> 2.3. ALSA
>>>> 2.4. Events not implemented yet
>>>>
>>>> All the above sources are available on *public* Github repos
>>>> (I can provide links on request) and the intention is to
>>>> upstream.
>>>>
>>> Please do post the links..
>> Please note these are all WIP:
>> 1. Frontends
>> https://github.com/andr2000?tab=repositories
>> 2. Backends
>> https://github.com/al1img?tab=repositories
> Now, I don't want to sound pessimistic, but I thought I was being
> audacious when I wrote both PV Calls and 9pfs for 4.9 - do you really
> think it is feasable to complete upstreaming of PV sound, PV DRM, DISPL,
> PV DRM frontends and backends, all by April? I would probably reduce the
> list a bit.

I think it would be good to main two lists.  One of "the stuff people
are working on overall", and "the subset of it intended/expected for the
forthcoming release".

Stuff will invariably slip, but even if the work isn't intended for the
forthcoming release, it it still useful to see if anyone in the
community is working on a related topic.

~Andrew

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

Re: Xen 4.9 Development Update

[Julien Grall]

Hi,

On 09/12/2016 19:09, Andrew Cooper wrote:
> On 09/12/16 19:01, Stefano Stabellini wrote:
>> On Fri, 9 Dec 2016, Oleksandr Andrushchenko wrote:
>>> On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote:
>>>> On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko wrote:
>>>>>>> Should we have a section on new PV drivers? If so, I suggest to add:
>>>>>>> - Xen transport for 9pfs
>>>>>>> - PV Calls
>>>>>> Good idea. We could also include DRM and PV Sound (CC Oleksandr).
>>>>>>
>>>>> This is a great idea. Let me explain what we have and what the direction
>>>>> is:
>>>>> 1. Frontends which we already have, working, but need to refactor/cleanup:
>>>>> 1.1. PV sound
>>>>> 1.2. PV DRM
>>>>> 1.3. DISPL protocol, I will push v1 for review right after sndif done
>>>>> 1.3. PV DRM mapper (Dom0 generic DRM driver to implement DRM zero copy
>>>>> via DRM Prime buffer sharing)
>>>>> 1.4. PV events not done, but we are considering [1]. If it fits and
>>>>> is maintained,
>>>>> then we'll probably stick to it, otherwise new PV will be created
>>>>>
>>>>> 2. Backends, for the above frontends already implemented:
>>>>> 2.1. A unified library for Xen backends (libxenbe)
>>>>> 2.2. DRM + Wayland
>>>>> 2.3. ALSA
>>>>> 2.4. Events not implemented yet
>>>>>
>>>>> All the above sources are available on *public* Github repos
>>>>> (I can provide links on request) and the intention is to
>>>>> upstream.
>>>>>
>>>> Please do post the links..
>>> Please note these are all WIP:
>>> 1. Frontends
>>> https://github.com/andr2000?tab=repositories
>>> 2. Backends
>>> https://github.com/al1img?tab=repositories
>> Now, I don't want to sound pessimistic, but I thought I was being
>> audacious when I wrote both PV Calls and 9pfs for 4.9 - do you really
>> think it is feasable to complete upstreaming of PV sound, PV DRM, DISPL,
>> PV DRM frontends and backends, all by April? I would probably reduce the
>> list a bit.
>
> I think it would be good to main two lists.  One of "the stuff people
> are working on overall", and "the subset of it intended/expected for the
> forthcoming release".
>
> Stuff will invariably slip, but even if the work isn't intended for the
> forthcoming release, it it still useful to see if anyone in the
> community is working on a related topic.

I am thinking to re-introduce the state of a series (none, fair, ok, 
good, done) as it was done in the past [1].

"The states are: none -> fair -> ok -> good -> done

none - nothing yet
fair - still working on it, patches are prototypes or RFC
ok   - patches posted, acting on review
good - some last minute pieces
done - all done, might have bugs"

Also, rather than having two separate lists as you suggested, I would 
combine the two and differentiate the items planned for next release 
with a tag (let's say [next]).

Any opinions?

[1] 
https://lists.xenproject.org/archives/html/xen-devel/2015-02/msg01816.html

-- 
Julien Grall

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

Re: Xen 4.9 Development Update

[Wei Liu]

On Thu, Jan 26, 2017 at 12:27:15PM +0000, Julien Grall wrote:
> Hi,
> 
> On 09/12/2016 19:09, Andrew Cooper wrote:
> > On 09/12/16 19:01, Stefano Stabellini wrote:
> > > On Fri, 9 Dec 2016, Oleksandr Andrushchenko wrote:
> > > > On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote:
> > > > > On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko wrote:
> > > > > > > > Should we have a section on new PV drivers? If so, I suggest to add:
> > > > > > > > - Xen transport for 9pfs
> > > > > > > > - PV Calls
> > > > > > > Good idea. We could also include DRM and PV Sound (CC Oleksandr).
> > > > > > > 
> > > > > > This is a great idea. Let me explain what we have and what the direction
> > > > > > is:
> > > > > > 1. Frontends which we already have, working, but need to refactor/cleanup:
> > > > > > 1.1. PV sound
> > > > > > 1.2. PV DRM
> > > > > > 1.3. DISPL protocol, I will push v1 for review right after sndif done
> > > > > > 1.3. PV DRM mapper (Dom0 generic DRM driver to implement DRM zero copy
> > > > > > via DRM Prime buffer sharing)
> > > > > > 1.4. PV events not done, but we are considering [1]. If it fits and
> > > > > > is maintained,
> > > > > > then we'll probably stick to it, otherwise new PV will be created
> > > > > > 
> > > > > > 2. Backends, for the above frontends already implemented:
> > > > > > 2.1. A unified library for Xen backends (libxenbe)
> > > > > > 2.2. DRM + Wayland
> > > > > > 2.3. ALSA
> > > > > > 2.4. Events not implemented yet
> > > > > > 
> > > > > > All the above sources are available on *public* Github repos
> > > > > > (I can provide links on request) and the intention is to
> > > > > > upstream.
> > > > > > 
> > > > > Please do post the links..
> > > > Please note these are all WIP:
> > > > 1. Frontends
> > > > https://github.com/andr2000?tab=repositories
> > > > 2. Backends
> > > > https://github.com/al1img?tab=repositories
> > > Now, I don't want to sound pessimistic, but I thought I was being
> > > audacious when I wrote both PV Calls and 9pfs for 4.9 - do you really
> > > think it is feasable to complete upstreaming of PV sound, PV DRM, DISPL,
> > > PV DRM frontends and backends, all by April? I would probably reduce the
> > > list a bit.
> > 
> > I think it would be good to main two lists.  One of "the stuff people
> > are working on overall", and "the subset of it intended/expected for the
> > forthcoming release".
> > 
> > Stuff will invariably slip, but even if the work isn't intended for the
> > forthcoming release, it it still useful to see if anyone in the
> > community is working on a related topic.
> 
> I am thinking to re-introduce the state of a series (none, fair, ok, good,
> done) as it was done in the past [1].
> 
> "The states are: none -> fair -> ok -> good -> done
> 
> none - nothing yet
> fair - still working on it, patches are prototypes or RFC
> ok   - patches posted, acting on review
> good - some last minute pieces
> done - all done, might have bugs"
> 

We (I?) ditched them because they weren't that useful.  "None" is just
signalling of intent, which doesn't carry enough of meaningful
information.  "Fair", "ok" and "good" are all subjective -- we've seen
"good" series slipped due to last minute issues.

If we really want status, I would suggest more concrete status:

  design / design.vX -> rfc / rfc.vX -> wip / wip.vX -> committed

These are more tangible and objective.

> Also, rather than having two separate lists as you suggested, I would
> combine the two and differentiate the items planned for next release with a
> tag (let's say [next]).
> 

No opinion on this.

Wei.

> Any opinions?
> 
> [1]
> https://lists.xenproject.org/archives/html/xen-devel/2015-02/msg01816.html
> 
> -- 
> Julien Grall

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

Re: Xen 4.9 Development Update

[Julien Grall]

Hi,

On 26/01/17 17:06, Wei Liu wrote:
> On Thu, Jan 26, 2017 at 12:27:15PM +0000, Julien Grall wrote:
>> Hi,
>>
>> On 09/12/2016 19:09, Andrew Cooper wrote:
>>> On 09/12/16 19:01, Stefano Stabellini wrote:
>>>> On Fri, 9 Dec 2016, Oleksandr Andrushchenko wrote:
>>>>> On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote:
>>>>>> On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko wrote:
>>>>>>>>> Should we have a section on new PV drivers? If so, I suggest to add:
>>>>>>>>> - Xen transport for 9pfs
>>>>>>>>> - PV Calls
>>>>>>>> Good idea. We could also include DRM and PV Sound (CC Oleksandr).
>>>>>>>>
>>>>>>> This is a great idea. Let me explain what we have and what the direction
>>>>>>> is:
>>>>>>> 1. Frontends which we already have, working, but need to refactor/cleanup:
>>>>>>> 1.1. PV sound
>>>>>>> 1.2. PV DRM
>>>>>>> 1.3. DISPL protocol, I will push v1 for review right after sndif done
>>>>>>> 1.3. PV DRM mapper (Dom0 generic DRM driver to implement DRM zero copy
>>>>>>> via DRM Prime buffer sharing)
>>>>>>> 1.4. PV events not done, but we are considering [1]. If it fits and
>>>>>>> is maintained,
>>>>>>> then we'll probably stick to it, otherwise new PV will be created
>>>>>>>
>>>>>>> 2. Backends, for the above frontends already implemented:
>>>>>>> 2.1. A unified library for Xen backends (libxenbe)
>>>>>>> 2.2. DRM + Wayland
>>>>>>> 2.3. ALSA
>>>>>>> 2.4. Events not implemented yet
>>>>>>>
>>>>>>> All the above sources are available on *public* Github repos
>>>>>>> (I can provide links on request) and the intention is to
>>>>>>> upstream.
>>>>>>>
>>>>>> Please do post the links..
>>>>> Please note these are all WIP:
>>>>> 1. Frontends
>>>>> https://github.com/andr2000?tab=repositories
>>>>> 2. Backends
>>>>> https://github.com/al1img?tab=repositories
>>>> Now, I don't want to sound pessimistic, but I thought I was being
>>>> audacious when I wrote both PV Calls and 9pfs for 4.9 - do you really
>>>> think it is feasable to complete upstreaming of PV sound, PV DRM, DISPL,
>>>> PV DRM frontends and backends, all by April? I would probably reduce the
>>>> list a bit.
>>>
>>> I think it would be good to main two lists.  One of "the stuff people
>>> are working on overall", and "the subset of it intended/expected for the
>>> forthcoming release".
>>>
>>> Stuff will invariably slip, but even if the work isn't intended for the
>>> forthcoming release, it it still useful to see if anyone in the
>>> community is working on a related topic.
>>
>> I am thinking to re-introduce the state of a series (none, fair, ok, good,
>> done) as it was done in the past [1].
>>
>> "The states are: none -> fair -> ok -> good -> done
>>
>> none - nothing yet
>> fair - still working on it, patches are prototypes or RFC
>> ok   - patches posted, acting on review
>> good - some last minute pieces
>> done - all done, might have bugs"
>>
>
> We (I?) ditched them because they weren't that useful.  "None" is just
> signalling of intent, which doesn't carry enough of meaningful
> information.  "Fair", "ok" and "good" are all subjective -- we've seen
> "good" series slipped due to last minute issues.
>
> If we really want status, I would suggest more concrete status:
>
>   design / design.vX -> rfc / rfc.vX -> wip / wip.vX -> committed
>
> These are more tangible and objective.

I agree this is more objective but we loose the time estimation. The 
number of revisions sent depends a lot on the contributor, complexity of 
the series... So a series tagged wip.v5 might be in better shape of one 
tagged wip.v10.

Although, I don't have better idea so far.

Cheers,

-- 
Julien Grall

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

Re: Xen 4.9 Development Update

[Wei Liu]

On Mon, Jan 30, 2017 at 03:32:49PM +0000, Julien Grall wrote:
[...]
> > > > 
> > > > I think it would be good to main two lists.  One of "the stuff people
> > > > are working on overall", and "the subset of it intended/expected for the
> > > > forthcoming release".
> > > > 
> > > > Stuff will invariably slip, but even if the work isn't intended for the
> > > > forthcoming release, it it still useful to see if anyone in the
> > > > community is working on a related topic.
> > > 
> > > I am thinking to re-introduce the state of a series (none, fair, ok, good,
> > > done) as it was done in the past [1].
> > > 
> > > "The states are: none -> fair -> ok -> good -> done
> > > 
> > > none - nothing yet
> > > fair - still working on it, patches are prototypes or RFC
> > > ok   - patches posted, acting on review
> > > good - some last minute pieces
> > > done - all done, might have bugs"
> > > 
> > 
> > We (I?) ditched them because they weren't that useful.  "None" is just
> > signalling of intent, which doesn't carry enough of meaningful
> > information.  "Fair", "ok" and "good" are all subjective -- we've seen
> > "good" series slipped due to last minute issues.
> > 
> > If we really want status, I would suggest more concrete status:
> > 
> >   design / design.vX -> rfc / rfc.vX -> wip / wip.vX -> committed
> > 
> > These are more tangible and objective.
> 
> I agree this is more objective but we loose the time estimation. The number
> of revisions sent depends a lot on the contributor, complexity of the
> series... So a series tagged wip.v5 might be in better shape of one tagged
> wip.v10.

Yes, that's true. I've given up on hoping a certain thing manage to get
in a certain release. This is just how open source software development
works -- upstream has no very limited leverage on what people do. :-)

The value of revision number, imo, is that it objectively indicate if a
project is going on well or not. Say, a project in rfc.v10 or wip.v25 is
definitely alarming -- we (RM and committers) probably need to do
something process-wise to get it back on track.  That probably includes
understanding the issues / disputes between parties, provide
suggestions, mediate and sometimes make difficult decisions on various
issues.

Wei.

> 
> Although, I don't have better idea so far.
> 
> Cheers,
> 
> -- 
> Julien Grall

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

Re: Xen 4.9 Development Update

[Julien Grall]

Hi Wei,

On 30/01/17 15:45, Wei Liu wrote:
> On Mon, Jan 30, 2017 at 03:32:49PM +0000, Julien Grall wrote:
> [...]
>>>>>
>>>>> I think it would be good to main two lists.  One of "the stuff people
>>>>> are working on overall", and "the subset of it intended/expected for the
>>>>> forthcoming release".
>>>>>
>>>>> Stuff will invariably slip, but even if the work isn't intended for the
>>>>> forthcoming release, it it still useful to see if anyone in the
>>>>> community is working on a related topic.
>>>>
>>>> I am thinking to re-introduce the state of a series (none, fair, ok, good,
>>>> done) as it was done in the past [1].
>>>>
>>>> "The states are: none -> fair -> ok -> good -> done
>>>>
>>>> none - nothing yet
>>>> fair - still working on it, patches are prototypes or RFC
>>>> ok   - patches posted, acting on review
>>>> good - some last minute pieces
>>>> done - all done, might have bugs"
>>>>
>>>
>>> We (I?) ditched them because they weren't that useful.  "None" is just
>>> signalling of intent, which doesn't carry enough of meaningful
>>> information.  "Fair", "ok" and "good" are all subjective -- we've seen
>>> "good" series slipped due to last minute issues.
>>>
>>> If we really want status, I would suggest more concrete status:
>>>
>>>   design / design.vX -> rfc / rfc.vX -> wip / wip.vX -> committed
>>>
>>> These are more tangible and objective.
>>
>> I agree this is more objective but we loose the time estimation. The number
>> of revisions sent depends a lot on the contributor, complexity of the
>> series... So a series tagged wip.v5 might be in better shape of one tagged
>> wip.v10.
>
> Yes, that's true. I've given up on hoping a certain thing manage to get
> in a certain release. This is just how open source software development
> works -- upstream has no very limited leverage on what people do. :-)
>
> The value of revision number, imo, is that it objectively indicate if a
> project is going on well or not. Say, a project in rfc.v10 or wip.v25 is
> definitely alarming -- we (RM and committers) probably need to do
> something process-wise to get it back on track.  That probably includes
> understanding the issues / disputes between parties, provide
> suggestions, mediate and sometimes make difficult decisions on various
> issues.

Sounds good to me. I will have a try implementing this on the next 
iteration.

Cheers,

-- 
Julien Grall

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

Re: Xen 4.9 Development Update

[Artem Mygaiev]

Hi Stefano


On 09.12.16 21:01, Stefano Stabellini wrote:
> On Fri, 9 Dec 2016, Oleksandr Andrushchenko wrote:
>> On 12/09/2016 03:57 PM, Pasi Kärkkäinen wrote:
>>> On Fri, Dec 09, 2016 at 02:57:04PM +0200, Oleksandr Andrushchenko wrote:
>>>>>> Should we have a section on new PV drivers? If so, I suggest to add:
>>>>>> - Xen transport for 9pfs
>>>>>> - PV Calls
>>>>> Good idea. We could also include DRM and PV Sound (CC Oleksandr).
>>>>>
>>>> This is a great idea. Let me explain what we have and what the direction
>>>> is:
>>>> 1. Frontends which we already have, working, but need to refactor/cleanup:
>>>> 1.1. PV sound
>>>> 1.2. PV DRM
>>>> 1.3. DISPL protocol, I will push v1 for review right after sndif done
>>>> 1.3. PV DRM mapper (Dom0 generic DRM driver to implement DRM zero copy
>>>> via DRM Prime buffer sharing)
>>>> 1.4. PV events not done, but we are considering [1]. If it fits and
>>>> is maintained,
>>>> then we'll probably stick to it, otherwise new PV will be created
>>>>
>>>> 2. Backends, for the above frontends already implemented:
>>>> 2.1. A unified library for Xen backends (libxenbe)
>>>> 2.2. DRM + Wayland
>>>> 2.3. ALSA
>>>> 2.4. Events not implemented yet
>>>>
>>>> All the above sources are available on *public* Github repos
>>>> (I can provide links on request) and the intention is to
>>>> upstream.
>>>>
>>> Please do post the links..
>> Please note these are all WIP:
>> 1. Frontends
>> https://github.com/andr2000?tab=repositories
>> 2. Backends
>> https://github.com/al1img?tab=repositories
> Now, I don't want to sound pessimistic, but I thought I was being
> audacious when I wrote both PV Calls and 9pfs for 4.9 - do you really
> think it is feasable to complete upstreaming of PV sound, PV DRM, DISPL,
> PV DRM frontends and backends, all by April? I would probably reduce the
> list a bit.
I am pretty sure we can finish sound and displ. DRM is a "stretch goal" I believe :)
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> https://lists.xen.org/xen-devel


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