Re: [Xen-devel] Xen 4.9 Development Update
Hi, all
On Tue, Mar 28, 2017 at 5:20 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.
>
> 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 <58a2ef4e027800139...@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-devel] Xen 4.9 Development Update
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 <58a2ef4e027800139...@prv-mh.provo.novell.com>)
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] Xen 4.9 Development update : last posting date
Hello, The last posting date and hard code freeze for Xen 4.9 will be extended by a week. I still expect Xen 4.9 released on time. The new schedule for Xen 4.9 is: * 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 dates. All patches posted after will be automatically queued into next release. Cheers, -- Julien Grall ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.9 Development Update
On 01/30/17 15:33 +, 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-devel] Xen 4.9 Development Update
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-devel] Xen 4.9 Development Update
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 +, 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-devel] Xen 4.9 Development Update
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 +, 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-devel] Xen 4.9 Development Update
On 08/02/17 18:17, Konrad Rzeszutek Wilk wrote: On Wed, Feb 08, 2017 at 06:03:00PM +, 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-devel] Xen 4.9 Development Update
> > > * 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
Re: [Xen-devel] Xen 4.9 Development Update
On 02/08/2017 08:17 PM, Konrad Rzeszutek Wilk wrote: On Wed, Feb 08, 2017 at 06:03:00PM +, 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-devel] Xen 4.9 Development Update
On Wed, Feb 08, 2017 at 06:03:00PM +, 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-devel] Xen 4.9 Development Update
(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-devel] Xen 4.9 Development Update
Hi Wei, On 30/01/17 15:45, Wei Liu wrote: On Mon, Jan 30, 2017 at 03:32:49PM +, 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-devel] Xen 4.9 Development Update
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-devel] Xen 4.9 Development Update
On Mon, Jan 30, 2017 at 03:33:19PM +, 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-devel] Xen 4.9 Development Update
On Mon, Jan 30, 2017 at 03:32:49PM +, 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
[Xen-devel] Xen 4.9 Development Update
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-devel] Xen 4.9 Development Update
Hi, On 26/01/17 17:06, Wei Liu wrote: On Thu, Jan 26, 2017 at 12:27:15PM +, 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-devel] Xen 4.9 Development Update
On Thu, Jan 26, 2017 at 12:27:15PM +, 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-devel] Xen 4.9 Development Update
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-devel] Xen 4.9 Development Update
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
Re: [Xen-devel] Xen 4.9 Development Update
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-devel] Xen 4.9 Development Update
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.___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] Xen 4.9 Development Update
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-devel] Xen 4.9 Development Update
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-devel] Xen 4.9 Development Update
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-devel] Xen 4.9 Development Update
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-devel] Xen 4.9 Development Update
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-devel] Xen 4.9 Development Update
On Thu, Dec 08, 2016 at 08:57:21AM -0700, Jan Beulich wrote: > >>> On 08.12.16 at 16:36, wrote: > > On Thu, Dec 08, 2016 at 03:12:12PM +, 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
Re: [Xen-devel] Xen 4.9 Development Update
>>> On 08.12.16 at 16:36, wrote: > On Thu, Dec 08, 2016 at 03:12:12PM +, 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-devel] Xen 4.9 Development Update
On Thu, Dec 08, 2016 at 03:12:12PM +, 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-devel] Xen 4.9 Development Update
>>> On 08.12.16 at 16:12, 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
[Xen-devel] Xen 4.9 Development Update
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
