Xen 4.5 development update (September update). Feature freeze slip by two weeks.

Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[konrad.wilk]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 15056 bytes --]

The feature freeze has moved by two weeks. That means it is scheduled
to be on September 24th.

If you think you will need a feature freeze exception, read below.

In terms of Linux I am keeping the 'fair' ones as by the Xen 4.6 release
it could be v3.19, which means there is still an upcoming merge window
for those.

The "prognosis" is now the likelihood of completion in the 4.5 timeframe.
A bunch of items had moved to the completed phase which is fantastic.

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

For items involving code hosted on the Xen.org site (including qemu-xen),
that means a likelihood of having the feature code-complete and mostly
working by the feature freeze.  (It's OK if there are still bugs to be
worked out.)  For items in Linux, it would mean having items on track
to make it into the kernel released just after the scheduled 4.5 time frame.

In terms of libvirt it has monthly releases. As such not going to track
every release - but closer to when RCs are out.

= Timeline =

We are planning on a 9-month release cycle.  Based on that, below are
our estimated dates:


* Feature Freeze: 24th September 2014
* First RC: 15th October
* Release: 10th December 2014

The RCs and release will of course depend on stability and bugs, and
will therefore be fairly unpredictable.  The feature freeze may be
slipped for especially important features which are near completion.

If you think your patchset MUST go in Xen 4.5 I will post the procedure
for requesting an exception to get them in past the feature freeze next
week.

= Prognosis =

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

= Feature freeze exception =

When we get to September 24th, the code "freezing point" will commence;
which means that starting on that day non-bug fixes need a freeze exception
to be included.

Remember our goal for the release:
  1. A bug-free release
  2. An awesome release
  3. An on-time release

Accepting a new feature may make Xen more awesome; but it also
introduces a risk that it will introduce more bugs.  That bug may be
found before the release (threatening #3), or it may not be found
until after the release (threatening #1).  Each freeze exception
request will attempt to balance the benefits (how awesome the
exception is) vs the risks (will it cause the release to slip, or
worse, cause a bug which goes un-noticed into the final release).

The idea is that today we will be pretty permissive, but that we will
become progressively more conservative until the first RC, which is
scheduled for 3 weeks' time (October 15).  After that, we will only
accept bug fixes.

Bug fixes can be checked in without a freeze exception throughout the
code freeze, unless the maintainer thinks they are particularly high
risk.  In later RC's, we may even begin rejecting bug fixes if the
broken functionality is small and the risk to other functionality is
high.

Features which are currently marked "experimental" or do not at the
moment work at all cannot be broken really; so changes to code only
used by those features should be able to get a freeze exception
easily.

Features which change or add new interfaces which will need to be
supported in a backwards-compatible way (for instance, vNUMA) will
need freeze exceptions to make sure that the interface itself has
enough time to be considered stable.

These are guidelines and principles to give you an idea where we're
coming from; if you think there's a good reason why making an
exception for you will help us achieve goals 1-3 above better than not
doing so, feel free to make your case.

= Open =

== ARM ==

*  ARM Xen UEFI booting on ARM (fair/ok)
   v4
  -  Roy Franz

*  ARM GICv3 support (ok)
   v10 posted
  -  Vijay Kilari

*  ARM - VGIC emulation (ok)
   Reposted as gic and vgic fixes and improvements
   v12
  -  Stefano Stabellini

*  ARM - Add Odroid-XU (Exynos5410) support (ok)
   v6
  -  Suriyan Ramasami

*  ARM implement mem_access (ok)
   v5
   https://github.com/tklengyel/xen/tree/arm_memaccess5
  -  Tamas K Lengyel

== x86 ==

*  xc_reserved_device_memory_map in hvmloader to avoid conflicting MMIO/RAM (good)
   v6
  -  Tiejun Chen

*  New Migration (v2). (good)
   v6 posted, going on the 'good' side!
  -  Andrew Cooper & David Vrabel

*  PVH - AMD hardware support. (fair)
   Posted.
  -  Mukesh Rathor

*  VMware backdoor (hypercall) (ok)
   v2 posted.
  -  Don Slutz

*  VPMU - 'perf' support in Xen (good)
   v10 posted
   Need perf aware person to review for final ack.
  -  Boris Ostrovsky

*  Cache QoS Monitoring - hypercalls (ok)
   Just hypercalls - no toolstack changes.
   v15
   Hit a snag with rdmsr/IPI/wrmsr/IPI, possible redesign
  -  Chao Peng, Dongxiao Xu, and Shantong Kang

*  XenRT (Preemptive Global Earliest Deadline First) (good)
   v2
  -  Meng Xu

*  Introspection of HVM guests (ok)
   v6
  -  Razvan Cojocaru

*  Xen Boot Information (xbi) (fair)
   Dependency for GRUB2 + EFI work
   See http://lists.xen.org/archives/html/xen-devel/2013-05/msg02281.html
  -  Daniel Kiper

== lib{xc,xl} and toolstack ==

*  vNUMA in Xen toolstack (ok)
   v11 posted
   Hypervisor part in
   git://gitorious.org/vnuma/xen_vnuma.git:v11
  -  Elena Ufimtseva

*  Remus in Xen (libxl) (good)
   v19
   url:  https://github.com/macrosheep/xen/tree/remus-v19
  -  Gui Jianfeng
  -  Yang Hongyang
  -  Dong, Eddie

== Linux ==

*  Linux block multiqueue (fair)
  -  Arianna Avanzini

*  Netback grant table manipulations (ok)
  -  Zoltan Kiss

*  VPMU - 'perf' support in Linux (ok)
   Depends on Xen patches
  -  Boris Ostrovsky

*  vNUMA in Linux (ok)
   v6 posted
   git://gitorious.org/vnuma/linux_vnuma.git
  -  Elena Ufimtseva

*  vsyscall in Linux (fair)
  -  Konrad Rzeszutek Wilk

*  COLO Agent in Linux (fair)
  -  Gui Jianfeng
  -  Yang Hongyang
  -  Dong, Eddie

*  vAPIC in PVHVM guests (Linux side) (none)
  -  Boris Ostrovsky

*  ARM - Device assigment usage in Linux code (arch/arm) (none)
  -  Julien Grall

*  Fix PAT in Linux kernel (aka Full support for PAT) (ok)
  -  Juergen Gross

*  Linux ARM - Device assigment (fair)
  -  Julien Grall

== FreeBSD ==

*  PVH FreeBSD dom0 (ok)
   FreeBSD 11 goal. Toolstack side done in Xen 4.5
  -  Roger Pau Monné

== Other OSes (MiniOS, QNX) ==

*  PV drivers for automotive kernels (fair)
  -  Artem Mygaiev

*  mini-os: xenbus changes for rump kernels (ok)
   git://xenbits.xen.org/people/iwj/rumpuser-xen.git
   branch: base.dev-xen-xenbus.v1..dev-xen-xenbus.v1
   v2 posted
  -  Ian Jackson

== GRUB2 ==

*  GRUB2 multiboot2 (fair)
  -  Daniel Kiper

== OSSTEST ==

*  OSSTest: libvirt (good)
  -  Ian Campbell

== Deferred to QEMU v2.next ==

*  Using qemu-upstream in a stubdomain (fair)
   Will use rump kernels.
  -  Ian Jackson

*  AMD Radeon PCI GPU passthrough (none)
   Focusing on Xen 4.2 and qemu-traditional
  -  Kelly Zytaruk

*  Intel IGD PCI GPU passthrough (ok)
   v5 posted
  -  Chen, Tiejun

*  Xen PV block driver in OVMF (UEFI in guest) (ok)
   v1
  -  Anthony PERARD

== Deferred to Xen hypervisor 4.6 ==

*  extending mem_access support to PV domain (fair)
   RFC v2
  -  Aravindh Puthiyaparambil (aravindp)

*  Repurpose SEDF Scheduler for Real-time (fair)
   RFC patch posted (v2)
  -  Joshua Whitehead, Robert VanVossen

*  ARM remote processor iommu module (GPUs + IPUs) (fair)
   v3 posted
  -  Andrii Tseglytskyi

*  dirty vram / IOMMU bug (fair)
   http://bugs.xenproject.org/xen/bug/38
  -  Zhang, Yang Z

*  Xen multiboot2-EFI support (fair)
   Needed for GrUB2
   Depends on Xen Boot info (rework multiboot and other structs)
   See http://lists.xen.org/archives/html/xen-devel/2013-05/msg02281.html
   RFC posted
  -  Daniel Kiper

*  Support controlling the max C-state sub-state (ok)
   v3 posted
  -  Ross Lagerwall

*  IOMMU ABI for guests to map their DMA regions (fair)
  -  Malcolm Crossley

*  Default to credit2 (none)
   cpu pinning, numa affinity and cpu reservation
  -  George Dunlap

*  Convert tasklet to per-cpu tasklets (fair)
   RFC posted
  -  Konrad Rzeszutek Wilk

*  Further tmem cleanups/fixes (16TB etc) (fair)
  -  Bob Liu

*  1TB slow destruction (ok)
  -  Bob Liu

*  ARM VM save/restore/live migration (none)
   Need to rebased against migrationv2 - no code posted.
  -  Junghyun Yoo

*  ARM GICv2m support (none)
  -  Linaro (unknown)

== Deferred to Xen toolstack 4.6 ==

*  pvscsi in libxl (fair)
  -  Juergen Gross and Olaf

*  COarse-grain LOck-stepping Virtual Machines in Xen (fair)
   RFC v3 posted, based on remus-v19
  -  Wen Congyang
  -  Gui Jianfeng
  -  Yang Hongyang
  -  Dong, Eddie

*  extend the xenstore ring with a 'closing' signal (fair)
   RFC patch posted
  -  David Scott

*  libxl migrationv2 patches. (none)
  -  Andrew Cooper & David Vrabel

*  tmem migrationv2 patches. (none)
  -  Bob Liu & Andrew Cooper & David Vrabel

*  Remus using migration-v2 (fair)
   RFC posted - depends on v6 of 'New Migration'
  -  Yang Hongyang

*  snapshot API extension (checkpointing disk) (ok)
   v5
   His email bounces.
  -  Bamvor Jian Zhang

*  Rearrange and cleanup installation destination directories (/var -> var/lib/xen) (fair)
  -  Daniel Kiper

*  libxl/xl - xm compatibility mode for mem-max and mem-set; (ok)
  -  Daniel Kiper

*  xl list --long (and some related xl commands) have some bugs (none)
  -  Zhigang Wang

*  Xen HPET interrupt fixes (fair)
   behind migration v2
  -  Andrew Cooper

*  cpuid leveling (none)
   http://xenbits.xen.org/people/andrewcoop/feature-levelling/feature-levelling-D.pdf
  -  Andrew Cooper

*  live migration knobs, there is no suitable code yet, just ideas (none)
    http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg00785.html
  -  Olaf Hering

*  xl does not handle migrate interruption gracefully (none)
   If you start a localhost migrate, and press "Ctrl-C" in the middle, you get two hung domains
  -  Ian Jackson

*  IO-NUMA - hwloc and xl (none)
   Andrew Cooper had an RFC patch for hwloc
   add restrictions  as to which devices cannot safely/functionally be split apart.
  -  Boris Ostrovsky

*  HVM guest NUMA (none)
  -  Matt Wilson

*  PVH - Migration of PVH DomUs. (none)
   Depends on migration2 code
  -  Roger Pau Monné

*  PVH - Migration of guests from a PVH dom0  (none)
   Depends on migration2 code
  -  Roger Pau Monné

*  "Short" grant copy (just header) of packets. (none)
  -  Zoltan Kiss

== Up for grabs ==

*  OSSTest - also test Linux PVH guests

*  PoD fixes
   if you boot with memory <= maxmem we have a size estimation bug

*  TLB flushing without locks in Xen

*  xl does not support specifying virtual function for passthrough device
   http://bugs.xenproject.org/xen/bug/22

*  PCI hole resize support hvmloader/qemu-traditional/qemu-upstream with PCI/GPU passthrough
   http://bugs.xenproject.org/xen/bug/28

*  libx{c,l} error handling cleanup

*  Adding missing 'xend' features in libxl

*  xl list -l on a dom0-only system

*  xl list -l doesn't contain tty console port

*  xl: passing more defaults in configuration in xl.conf
   There are a number of options for which it might be useful to pass a default in xl.conf.  For example, if we could have a default "backend" parameter for vifs, then it would be easy to switch back and forth between a backend in a driver domain and a backend in dom0.

*  PVH - PVH working with shadow.
   Based on Tim's work

*  PVH - PCI passthrough for DomU.

*  AMD performance regressions

*  Performance due to hypercall preemption. More preemptions - slower. (none)

== Completed ==

*  ARM - MiniOS (done)
   v7 posted
  -  Thomas Leonard

*  ARM XEN_DOMCTL_memory_mapping hypercall for ARM (done)
   v12 posted.
  -  Arianna Avanzini

*  libxl work - JSON to keep track of guest configs (done)
  -  Wei Liu

*  ARM - XENFEAT_grant_map_11 (aka map grants refs at pfn = mfn) (done)
   Provide kernels an grant->MFN lookup
   v4
  -  Stefano Stabellini

*  ARM PSCI v0.2 (done)
   v11 posted
  -  Parth Dixit

*  pvSCSI in Linux (fronted and backend) (done)
   v6
  -  Juergen Gross

*  alternative_asm in Xen (done)
  -  Feng Wu

*  SMAP (done)
  -  Feng Wu

*  Re-write of vHPET (done)
   aka hvm/hpet: Detect comparator values in the past
  -  Don Slutz

*  vAPIC in PVHVM guests (Xen side) (done)
  -  Boris Ostrovsky

*  libvirt and xl discard support, so that libvirt can start using it (done)
  -  Olaf Hering

*  Xen PVH dom0 (done)
  -  Mukesh Rathor

*  Linux PVH dom0 (done)
  -  Mukesh Rathor

*  OSSTest: upstream QEMU (done)
  -  Ian Campbell

*  amd_ucode cleanups, verify patch size(enhancement) (mostly in master except one patch)

*  Data breakpoint Extension support (new-feat) (in master)

*  Feature masking MSR support (enhancement) (in master)

*  Support BRCM TruManage chip (Serial over LAN support) (new-feat) (in master)

*  fix vmce_amd* functions, unify mce_amd mcheck initialization (fixes/cleanups)

*  multiple AMD container files appended together in initrd (early initramfs)
  -  Aravind and Suravee

*  NUMA memory scrubbing (done)
  -  Konrad Rzeszutek Wilk

*  ARM  - IOMMU support (done)
  -  Julien Grall

*  ioreq-server, aka secondary emulators (done)
  -  Paul Durrant

*  Netback multiqueue (good)
  -  Wei Liu

*  ARM Interrupt latency reduction (no maintenance interrupts) (good)
  -  Stefano Stabellini

*  Bigger PCI hole in QEMU (done)
   Needs to be rebased
  -  Don Slutz

*  ARM DRA7 support (done)
   v3 posted
   v3 with comments applied
  -  Andrii Tseglytskyi

*  rework VM Generation ID (done)
   v7 posted
  -  David Vrabel

*  Soft affinity for vcpus (was NUMA affinity for vcpus) (good)
   v11 posted
  -  Dario Faggioli

*  Linux pvops of Xen EFI hypercall support (done)
  -  Daniel Kiper

*  ARM: Use super pages in p2m (done)
   v5 posted
  -  Ian Campbell

*  QEMU 2.0 branch for qemu-upstream (done)
   It is v2.0 with 2.1 Xen backports.
  -  Stefano Stabellini

*  systemd support (done)
   v11
  -  Luis R. Rodriguez

*  Soft affinity for vcpus libxl/xl changes (done)
   v13 posted
  -  Dario Faggioli

*  HT enabled, virtualization overhead is high (Xen 4.4) (done)
   kernbench demonstrated it
   Looking and tracing
   http://www.gossamer-threads.com/lists/xen/devel/339409
   False alarm.
  -  Dario Faggioli



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

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

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Wei Liu]

On Wed, Sep 10, 2014 at 01:05:15PM -0400, konrad.wilk@oracle.com wrote:
[...]
> 
> *  libxl work - JSON to keep track of guest configs (done)
>   -  Wei Liu
> 

Not yet completed. Some patches (~9) are being reworked and will be
posted soon. Should be able to get them merged in time.

Wei.

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Razvan Cojocaru]

On 09/10/14 20:05, konrad.wilk@oracle.com wrote:
> *  Introspection of HVM guests (ok)
>    v6
>   -  Razvan Cojocaru

Will post a new series tomorrow. Three out of 5 patches seem to be Acked
and haven't had any comments in a while (the first three), and I hope to
be able to do away completely with patch 4/5 (per-domain page fault
injection) for now, and just use the existing HVMOP_inject_trap
interface - but this needs a bit more testing to make sure.

Patch 5/5 has been discussed today, and I'll address the comments
tomorrow in the new series. There are no major changes.


Thanks,
Razvan Cojocaru

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Roy Franz]

On Wed, Sep 10, 2014 at 10:05 AM,  <konrad.wilk@oracle.com> wrote:
> *  ARM Xen UEFI booting on ARM (fair/ok)
>    v4
>   -  Roy Franz
This is in good shape now.  v4 patches include major rework based on
earlier feedback,
so this should be very close to merg-able.

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Tamas K Lengyel]

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

> *  ARM implement mem_access (ok)
>    v5
>    https://github.com/tklengyel/xen/tree/arm_memaccess5
>   -  Tamas K Lengyel
>

Status is still ok. First half (relocation+cleanup part) is in good shape.
v5 was just posted today so waiting on ARM review. Expecting to submit at
least one more iteration next week.

Tamas

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

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

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

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Jan Beulich]

>>> On 10.09.14 at 21:26, <rcojocaru@bitdefender.com> wrote:
> On 09/10/14 20:05, konrad.wilk@oracle.com wrote:
>> *  Introspection of HVM guests (ok)
>>    v6
>>   -  Razvan Cojocaru
> 
> Will post a new series tomorrow. Three out of 5 patches seem to be Acked
> and haven't had any comments in a while (the first three), and I hope to
> be able to do away completely with patch 4/5 (per-domain page fault
> injection) for now, and just use the existing HVMOP_inject_trap
> interface - but this needs a bit more testing to make sure.

To be honest, despite considering patches 1-3 in acceptable shape
for being committed from a purely mechanical standpoint, I'm still
struggling with general reservations towards them: The whole series
continues to be very focused on special purpose behavior you want
for your product; recent comments from George emphasize that.

As I said before, it would be helpful if you adjusted your thinking to
take general usability of added functionality at least in mind, and if
you made absolutely certain that code changes you do have no
adverse effect on other users. This includes you not rushing out
updates to your series which then you need to supersede within
hours due to oversights or further adjustments. Take your time to
think through as many possibilities as you can (namely including
scenarios that your product does _not_ care about, but others
may), at once taking a certain level of burden off those
subsequently reviewing your patches.

Jan

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Razvan Cojocaru]

On 09/11/2014 10:37 AM, Jan Beulich wrote:
>>>> On 10.09.14 at 21:26, <rcojocaru@bitdefender.com> wrote:
>> On 09/10/14 20:05, konrad.wilk@oracle.com wrote:
>>> *  Introspection of HVM guests (ok)
>>>    v6
>>>   -  Razvan Cojocaru
>>
>> Will post a new series tomorrow. Three out of 5 patches seem to be Acked
>> and haven't had any comments in a while (the first three), and I hope to
>> be able to do away completely with patch 4/5 (per-domain page fault
>> injection) for now, and just use the existing HVMOP_inject_trap
>> interface - but this needs a bit more testing to make sure.
> 
> To be honest, despite considering patches 1-3 in acceptable shape
> for being committed from a purely mechanical standpoint, I'm still
> struggling with general reservations towards them: The whole series
> continues to be very focused on special purpose behavior you want
> for your product; recent comments from George emphasize that.
> 
> As I said before, it would be helpful if you adjusted your thinking to
> take general usability of added functionality at least in mind, and if
> you made absolutely certain that code changes you do have no
> adverse effect on other users. This includes you not rushing out
> updates to your series which then you need to supersede within
> hours due to oversights or further adjustments. Take your time to
> think through as many possibilities as you can (namely including
> scenarios that your product does _not_ care about, but others
> may), at once taking a certain level of burden off those
> subsequently reviewing your patches.

Thank you for your comments. Hopefully I can address at least some of
them here:

1. About patches 1-3, for mem_event clients that don't hook into
mem_access using xc_mem_access_enable_introspection() rather than
xc_mem_access_enable() there is no impact and no overhead. MSR
interception will be disabled at the correct time, no calls to the
"emulate with no writes" code will be made, and the additional
information in mem_events will be simply disregarded by non-interested
parties.

2. About George's comments on patch 5/5: they are spot-on, but again,
with just moving an if() to make the code clearer, and gating the GLA
event filter on introspection being enabled there is again absolutely no
impact or behaviour change for non-introspection clients. I can further
add a bool_t parameter to xc_mem_access_enable_introspection(), called,
for example, filter_gla_events, and make sure that even for clients who
do use xc_mem_access_enable_introspection() all mem_events will be
received if desired.

3. About thinking about the code in specific terms: I try my best not
to, and I hope our discussion so far proves that we're working together
with a common goal to be as generic and with little impact on
non-introspection clients as possible. Speaking of that, thanks to
George and Tim's suggestion I'm investigating the possibility of letting
go of patch 4/5 (which was the biggest problem), in the interest of
easing the review load and making the least modifications possible to Xen.

4. And finally, about the frequent series updates: the simple fact is
that this is the first time I've posted a series on xen-devel, and I'm
getting acquainted with the process and the community as we speak. I do
take responsability for previously posting two reviews in a day, and I
understand in hindsight that it put more stress on reviewers, for which
I apologize. At the time I just thought that moving fast is desirable
(and practical) for everyone.


Thanks,
Razvan Cojocaru

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Tamas K Lengyel]

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

On Thu, Sep 11, 2014 at 9:37 AM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 10.09.14 at 21:26, <rcojocaru@bitdefender.com> wrote:
> > On 09/10/14 20:05, konrad.wilk@oracle.com wrote:
> >> *  Introspection of HVM guests (ok)
> >>    v6
> >>   -  Razvan Cojocaru
> >
> > Will post a new series tomorrow. Three out of 5 patches seem to be Acked
> > and haven't had any comments in a while (the first three), and I hope to
> > be able to do away completely with patch 4/5 (per-domain page fault
> > injection) for now, and just use the existing HVMOP_inject_trap
> > interface - but this needs a bit more testing to make sure.
>
> To be honest, despite considering patches 1-3 in acceptable shape
> for being committed from a purely mechanical standpoint, I'm still
> struggling with general reservations towards them: The whole series
> continues to be very focused on special purpose behavior you want
> for your product; recent comments from George emphasize that.
>

I can say for sure that patch 2 would be of immediate interest to us as
well. The other patches in the series do also touch on areas that we care
about (msr events, bringing back paged out memory). It might be worth
considering splitting the series as to consider individual patches rather
than the series as a whole.

Tamas

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

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

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

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Ian Campbell]

On Wed, 2014-09-10 at 13:05 -0400, konrad.wilk@oracle.com wrote:
> completion in the 4.5 timeframe.

It would be useful if patch submitters could be encouraged to indicate
whether or not they are targeting 4.5 with a series, e.g. in the "[PATCH
for-4.5 0/N]" or in the metacommentary which follows the "---" in the
changelog.

That will help focus review bandwidth to where it is most urgently
needed.

Ian.

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Stefano Stabellini]

On Wed, 10 Sep 2014, konrad.wilk@oracle.com wrote:
> The feature freeze has moved by two weeks. That means it is scheduled
> to be on September 24th.
> 
> If you think you will need a feature freeze exception, read below.
> 
> In terms of Linux I am keeping the 'fair' ones as by the Xen 4.6 release
> it could be v3.19, which means there is still an upcoming merge window
> for those.
> 
> The "prognosis" is now the likelihood of completion in the 4.5 timeframe.
> A bunch of items had moved to the completed phase which is fantastic.
> 
> 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
> 
> For items involving code hosted on the Xen.org site (including qemu-xen),
> that means a likelihood of having the feature code-complete and mostly
> working by the feature freeze.  (It's OK if there are still bugs to be
> worked out.)  For items in Linux, it would mean having items on track
> to make it into the kernel released just after the scheduled 4.5 time frame.
> 
> In terms of libvirt it has monthly releases. As such not going to track
> every release - but closer to when RCs are out.
> 
> = Timeline =
> 
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
> 
> 
> * Feature Freeze: 24th September 2014
> * First RC: 15th October
> * Release: 10th December 2014
> 
> The RCs and release will of course depend on stability and bugs, and
> will therefore be fairly unpredictable.  The feature freeze may be
> slipped for especially important features which are near completion.
> 
> If you think your patchset MUST go in Xen 4.5 I will post the procedure
> for requesting an exception to get them in past the feature freeze next
> week.
> 
> = Prognosis =
> 
> 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
> 
> = Feature freeze exception =
> 
> When we get to September 24th, the code "freezing point" will commence;
> which means that starting on that day non-bug fixes need a freeze exception
> to be included.
> 
> Remember our goal for the release:
>   1. A bug-free release
>   2. An awesome release
>   3. An on-time release
> 
> Accepting a new feature may make Xen more awesome; but it also
> introduces a risk that it will introduce more bugs.  That bug may be
> found before the release (threatening #3), or it may not be found
> until after the release (threatening #1).  Each freeze exception
> request will attempt to balance the benefits (how awesome the
> exception is) vs the risks (will it cause the release to slip, or
> worse, cause a bug which goes un-noticed into the final release).
> 
> The idea is that today we will be pretty permissive, but that we will
> become progressively more conservative until the first RC, which is
> scheduled for 3 weeks' time (October 15).  After that, we will only
> accept bug fixes.
> 
> Bug fixes can be checked in without a freeze exception throughout the
> code freeze, unless the maintainer thinks they are particularly high
> risk.  In later RC's, we may even begin rejecting bug fixes if the
> broken functionality is small and the risk to other functionality is
> high.
> 
> Features which are currently marked "experimental" or do not at the
> moment work at all cannot be broken really; so changes to code only
> used by those features should be able to get a freeze exception
> easily.
> 
> Features which change or add new interfaces which will need to be
> supported in a backwards-compatible way (for instance, vNUMA) will
> need freeze exceptions to make sure that the interface itself has
> enough time to be considered stable.
> 
> These are guidelines and principles to give you an idea where we're
> coming from; if you think there's a good reason why making an
> exception for you will help us achieve goals 1-3 above better than not
> doing so, feel free to make your case.
> 
> = Open =
> 
> == ARM == 
> 
> *  ARM Xen UEFI booting on ARM (fair/ok)
>    v4
>   -  Roy Franz
> 
> *  ARM GICv3 support (ok)
>    v10 posted
>   -  Vijay Kilari
> 
> *  ARM - VGIC emulation (ok)
>    Reposted as gic and vgic fixes and improvements
>    v12
>   -  Stefano Stabellini
> 
> *  ARM - Add Odroid-XU (Exynos5410) support (ok)
>    v6
>   -  Suriyan Ramasami
> 
> *  ARM implement mem_access (ok)
>    v5
>    https://github.com/tklengyel/xen/tree/arm_memaccess5
>   -  Tamas K Lengyel

QEMU userspace PV backends on ARM fell off the list:

http://marc.info/?l=xen-devel&m=140690717224942

I think it is still good for 4.5. IanJ what do you think?

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[manish jaggi]

What about PCI passthrough, is it targeted for 4.6 ?

On 11 September 2014 23:17, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
> On Wed, 10 Sep 2014, konrad.wilk@oracle.com wrote:
>> The feature freeze has moved by two weeks. That means it is scheduled
>> to be on September 24th.
>>
>> If you think you will need a feature freeze exception, read below.
>>
>> In terms of Linux I am keeping the 'fair' ones as by the Xen 4.6 release
>> it could be v3.19, which means there is still an upcoming merge window
>> for those.
>>
>> The "prognosis" is now the likelihood of completion in the 4.5 timeframe.
>> A bunch of items had moved to the completed phase which is fantastic.
>>
>> 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
>>
>> For items involving code hosted on the Xen.org site (including qemu-xen),
>> that means a likelihood of having the feature code-complete and mostly
>> working by the feature freeze.  (It's OK if there are still bugs to be
>> worked out.)  For items in Linux, it would mean having items on track
>> to make it into the kernel released just after the scheduled 4.5 time frame.
>>
>> In terms of libvirt it has monthly releases. As such not going to track
>> every release - but closer to when RCs are out.
>>
>> = Timeline =
>>
>> We are planning on a 9-month release cycle.  Based on that, below are
>> our estimated dates:
>>
>>
>> * Feature Freeze: 24th September 2014
>> * First RC: 15th October
>> * Release: 10th December 2014
>>
>> The RCs and release will of course depend on stability and bugs, and
>> will therefore be fairly unpredictable.  The feature freeze may be
>> slipped for especially important features which are near completion.
>>
>> If you think your patchset MUST go in Xen 4.5 I will post the procedure
>> for requesting an exception to get them in past the feature freeze next
>> week.
>>
>> = Prognosis =
>>
>> 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
>>
>> = Feature freeze exception =
>>
>> When we get to September 24th, the code "freezing point" will commence;
>> which means that starting on that day non-bug fixes need a freeze exception
>> to be included.
>>
>> Remember our goal for the release:
>>   1. A bug-free release
>>   2. An awesome release
>>   3. An on-time release
>>
>> Accepting a new feature may make Xen more awesome; but it also
>> introduces a risk that it will introduce more bugs.  That bug may be
>> found before the release (threatening #3), or it may not be found
>> until after the release (threatening #1).  Each freeze exception
>> request will attempt to balance the benefits (how awesome the
>> exception is) vs the risks (will it cause the release to slip, or
>> worse, cause a bug which goes un-noticed into the final release).
>>
>> The idea is that today we will be pretty permissive, but that we will
>> become progressively more conservative until the first RC, which is
>> scheduled for 3 weeks' time (October 15).  After that, we will only
>> accept bug fixes.
>>
>> Bug fixes can be checked in without a freeze exception throughout the
>> code freeze, unless the maintainer thinks they are particularly high
>> risk.  In later RC's, we may even begin rejecting bug fixes if the
>> broken functionality is small and the risk to other functionality is
>> high.
>>
>> Features which are currently marked "experimental" or do not at the
>> moment work at all cannot be broken really; so changes to code only
>> used by those features should be able to get a freeze exception
>> easily.
>>
>> Features which change or add new interfaces which will need to be
>> supported in a backwards-compatible way (for instance, vNUMA) will
>> need freeze exceptions to make sure that the interface itself has
>> enough time to be considered stable.
>>
>> These are guidelines and principles to give you an idea where we're
>> coming from; if you think there's a good reason why making an
>> exception for you will help us achieve goals 1-3 above better than not
>> doing so, feel free to make your case.
>>
>> = Open =
>>
>> == ARM ==
>>
>> *  ARM Xen UEFI booting on ARM (fair/ok)
>>    v4
>>   -  Roy Franz
>>
>> *  ARM GICv3 support (ok)
>>    v10 posted
>>   -  Vijay Kilari
>>
>> *  ARM - VGIC emulation (ok)
>>    Reposted as gic and vgic fixes and improvements
>>    v12
>>   -  Stefano Stabellini
>>
>> *  ARM - Add Odroid-XU (Exynos5410) support (ok)
>>    v6
>>   -  Suriyan Ramasami
>>
>> *  ARM implement mem_access (ok)
>>    v5
>>    https://github.com/tklengyel/xen/tree/arm_memaccess5
>>   -  Tamas K Lengyel
>
> QEMU userspace PV backends on ARM fell off the list:
>
> http://marc.info/?l=xen-devel&m=140690717224942
>
> I think it is still good for 4.5. IanJ what do you think?
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Ian Campbell]

On Fri, 2014-09-12 at 12:05 +0530, manish jaggi wrote:
> What about PCI passthrough, is it targeted for 4.6 ?

Yes. For 4.5 we hope to get at least the mechanics of platform device
passthrough working, which provides a good baseline for PCI passthrough
for 4.6.

Ian.

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[manish jaggi]

I am working on the same  on cavium thunder, and have patches which
are based on platform device passthrough.
There are also patches in linux kernel as well.
What is the timeframe for 4.6 ?


On 12 September 2014 15:05, Ian Campbell <Ian.Campbell@citrix.com> wrote:
> On Fri, 2014-09-12 at 12:05 +0530, manish jaggi wrote:
>> What about PCI passthrough, is it targeted for 4.6 ?
>
> Yes. For 4.5 we hope to get at least the mechanics of platform device
> passthrough working, which provides a good baseline for PCI passthrough
> for 4.6.
>
> Ian.
>
>

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Ian Campbell]

(please don't top post)
On Fri, 2014-09-12 at 15:40 +0530, manish jaggi wrote:
> I am working on the same  on cavium thunder, and have patches which
> are based on platform device passthrough.
> There are also patches in linux kernel as well.
> What is the timeframe for 4.6 ?

We have been aiming for a 6 month release cycle, so 2015H1 seems likely.

Ian.

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Elena Ufimtseva]

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

On Wed, Sep 10, 2014 at 1:05 PM, <konrad.wilk@oracle.com> wrote:

> The feature freeze has moved by two weeks. That means it is scheduled
> to be on September 24th.
>
> If you think you will need a feature freeze exception, read below.
>
> In terms of Linux I am keeping the 'fair' ones as by the Xen 4.6 release
> it could be v3.19, which means there is still an upcoming merge window
> for those.
>
> The "prognosis" is now the likelihood of completion in the 4.5 timeframe.
> A bunch of items had moved to the completed phase which is fantastic.
>
> 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
>
> For items involving code hosted on the Xen.org site (including qemu-xen),
> that means a likelihood of having the feature code-complete and mostly
> working by the feature freeze.  (It's OK if there are still bugs to be
> worked out.)  For items in Linux, it would mean having items on track
> to make it into the kernel released just after the scheduled 4.5 time
> frame.
>
> In terms of libvirt it has monthly releases. As such not going to track
> every release - but closer to when RCs are out.
>
> = Timeline =
>
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
>
>
> * Feature Freeze: 24th September 2014
> * First RC: 15th October
> * Release: 10th December 2014
>
> The RCs and release will of course depend on stability and bugs, and
> will therefore be fairly unpredictable.  The feature freeze may be
> slipped for especially important features which are near completion.
>
> If you think your patchset MUST go in Xen 4.5 I will post the procedure
> for requesting an exception to get them in past the feature freeze next
> week.
>
> = Prognosis =
>
> 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
>
> = Feature freeze exception =
>
> When we get to September 24th, the code "freezing point" will commence;
> which means that starting on that day non-bug fixes need a freeze exception
> to be included.
>
> Remember our goal for the release:
>   1. A bug-free release
>   2. An awesome release
>   3. An on-time release
>
> Accepting a new feature may make Xen more awesome; but it also
> introduces a risk that it will introduce more bugs.  That bug may be
> found before the release (threatening #3), or it may not be found
> until after the release (threatening #1).  Each freeze exception
> request will attempt to balance the benefits (how awesome the
> exception is) vs the risks (will it cause the release to slip, or
> worse, cause a bug which goes un-noticed into the final release).
>
> The idea is that today we will be pretty permissive, but that we will
> become progressively more conservative until the first RC, which is
> scheduled for 3 weeks' time (October 15).  After that, we will only
> accept bug fixes.
>
> Bug fixes can be checked in without a freeze exception throughout the
> code freeze, unless the maintainer thinks they are particularly high
> risk.  In later RC's, we may even begin rejecting bug fixes if the
> broken functionality is small and the risk to other functionality is
> high.
>
> Features which are currently marked "experimental" or do not at the
> moment work at all cannot be broken really; so changes to code only
> used by those features should be able to get a freeze exception
> easily.
>
> Features which change or add new interfaces which will need to be
> supported in a backwards-compatible way (for instance, vNUMA) will
> need freeze exceptions to make sure that the interface itself has
> enough time to be considered stable.
>

Hello Konrad

I am working on toolstack patches for vNUMA and looks like I will
need to request exception for these. Hopefully, by today I will have the
patches out, but
I am sure they will need some modifications.
As we discussed, I will email to maintainers to discuss this.

Elena



>
> These are guidelines and principles to give you an idea where we're
> coming from; if you think there's a good reason why making an
> exception for you will help us achieve goals 1-3 above better than not
> doing so, feel free to make your case.
>
> = Open =
>
> == ARM ==
>
> *  ARM Xen UEFI booting on ARM (fair/ok)
>    v4
>   -  Roy Franz
>
> *  ARM GICv3 support (ok)
>    v10 posted
>   -  Vijay Kilari
>
> *  ARM - VGIC emulation (ok)
>    Reposted as gic and vgic fixes and improvements
>    v12
>   -  Stefano Stabellini
>
> *  ARM - Add Odroid-XU (Exynos5410) support (ok)
>    v6
>   -  Suriyan Ramasami
>
> *  ARM implement mem_access (ok)
>    v5
>    https://github.com/tklengyel/xen/tree/arm_memaccess5
>   -  Tamas K Lengyel
>
> == x86 ==
>
> *  xc_reserved_device_memory_map in hvmloader to avoid conflicting
> MMIO/RAM (good)
>    v6
>   -  Tiejun Chen
>
> *  New Migration (v2). (good)
>    v6 posted, going on the 'good' side!
>   -  Andrew Cooper & David Vrabel
>
> *  PVH - AMD hardware support. (fair)
>    Posted.
>   -  Mukesh Rathor
>
> *  VMware backdoor (hypercall) (ok)
>    v2 posted.
>   -  Don Slutz
>
> *  VPMU - 'perf' support in Xen (good)
>    v10 posted
>    Need perf aware person to review for final ack.
>   -  Boris Ostrovsky
>
> *  Cache QoS Monitoring - hypercalls (ok)
>    Just hypercalls - no toolstack changes.
>    v15
>    Hit a snag with rdmsr/IPI/wrmsr/IPI, possible redesign
>   -  Chao Peng, Dongxiao Xu, and Shantong Kang
>
> *  XenRT (Preemptive Global Earliest Deadline First) (good)
>    v2
>   -  Meng Xu
>
> *  Introspection of HVM guests (ok)
>    v6
>   -  Razvan Cojocaru
>
> *  Xen Boot Information (xbi) (fair)
>    Dependency for GRUB2 + EFI work
>    See http://lists.xen.org/archives/html/xen-devel/2013-05/msg02281.html
>   -  Daniel Kiper
>
> == lib{xc,xl} and toolstack ==
>
> *  vNUMA in Xen toolstack (ok)
>    v11 posted
>    Hypervisor part in
>    git://gitorious.org/vnuma/xen_vnuma.git:v11
>   -  Elena Ufimtseva
>
> *  Remus in Xen (libxl) (good)
>    v19
>    url:  https://github.com/macrosheep/xen/tree/remus-v19
>   -  Gui Jianfeng
>   -  Yang Hongyang
>   -  Dong, Eddie
>
> == Linux ==
>
> *  Linux block multiqueue (fair)
>   -  Arianna Avanzini
>
> *  Netback grant table manipulations (ok)
>   -  Zoltan Kiss
>
> *  VPMU - 'perf' support in Linux (ok)
>    Depends on Xen patches
>   -  Boris Ostrovsky
>
> *  vNUMA in Linux (ok)
>    v6 posted
>    git://gitorious.org/vnuma/linux_vnuma.git
>   -  Elena Ufimtseva
>
> *  vsyscall in Linux (fair)
>   -  Konrad Rzeszutek Wilk
>
> *  COLO Agent in Linux (fair)
>   -  Gui Jianfeng
>   -  Yang Hongyang
>   -  Dong, Eddie
>
> *  vAPIC in PVHVM guests (Linux side) (none)
>   -  Boris Ostrovsky
>
> *  ARM - Device assigment usage in Linux code (arch/arm) (none)
>   -  Julien Grall
>
> *  Fix PAT in Linux kernel (aka Full support for PAT) (ok)
>   -  Juergen Gross
>
> *  Linux ARM - Device assigment (fair)
>   -  Julien Grall
>
> == FreeBSD ==
>
> *  PVH FreeBSD dom0 (ok)
>    FreeBSD 11 goal. Toolstack side done in Xen 4.5
>   -  Roger Pau Monné
>
> == Other OSes (MiniOS, QNX) ==
>
> *  PV drivers for automotive kernels (fair)
>   -  Artem Mygaiev
>
> *  mini-os: xenbus changes for rump kernels (ok)
>    git://xenbits.xen.org/people/iwj/rumpuser-xen.git
>    branch: base.dev-xen-xenbus.v1..dev-xen-xenbus.v1
>    v2 posted
>   -  Ian Jackson
>
> == GRUB2 ==
>
> *  GRUB2 multiboot2 (fair)
>   -  Daniel Kiper
>
> == OSSTEST ==
>
> *  OSSTest: libvirt (good)
>   -  Ian Campbell
>
> == Deferred to QEMU v2.next ==
>
> *  Using qemu-upstream in a stubdomain (fair)
>    Will use rump kernels.
>   -  Ian Jackson
>
> *  AMD Radeon PCI GPU passthrough (none)
>    Focusing on Xen 4.2 and qemu-traditional
>   -  Kelly Zytaruk
>
> *  Intel IGD PCI GPU passthrough (ok)
>    v5 posted
>   -  Chen, Tiejun
>
> *  Xen PV block driver in OVMF (UEFI in guest) (ok)
>    v1
>   -  Anthony PERARD
>
> == Deferred to Xen hypervisor 4.6 ==
>
> *  extending mem_access support to PV domain (fair)
>    RFC v2
>   -  Aravindh Puthiyaparambil (aravindp)
>
> *  Repurpose SEDF Scheduler for Real-time (fair)
>    RFC patch posted (v2)
>   -  Joshua Whitehead, Robert VanVossen
>
> *  ARM remote processor iommu module (GPUs + IPUs) (fair)
>    v3 posted
>   -  Andrii Tseglytskyi
>
> *  dirty vram / IOMMU bug (fair)
>    http://bugs.xenproject.org/xen/bug/38
>   -  Zhang, Yang Z
>
> *  Xen multiboot2-EFI support (fair)
>    Needed for GrUB2
>    Depends on Xen Boot info (rework multiboot and other structs)
>    See http://lists.xen.org/archives/html/xen-devel/2013-05/msg02281.html
>    RFC posted
>   -  Daniel Kiper
>
> *  Support controlling the max C-state sub-state (ok)
>    v3 posted
>   -  Ross Lagerwall
>
> *  IOMMU ABI for guests to map their DMA regions (fair)
>   -  Malcolm Crossley
>
> *  Default to credit2 (none)
>    cpu pinning, numa affinity and cpu reservation
>   -  George Dunlap
>
> *  Convert tasklet to per-cpu tasklets (fair)
>    RFC posted
>   -  Konrad Rzeszutek Wilk
>
> *  Further tmem cleanups/fixes (16TB etc) (fair)
>   -  Bob Liu
>
> *  1TB slow destruction (ok)
>   -  Bob Liu
>
> *  ARM VM save/restore/live migration (none)
>    Need to rebased against migrationv2 - no code posted.
>   -  Junghyun Yoo
>
> *  ARM GICv2m support (none)
>   -  Linaro (unknown)
>
> == Deferred to Xen toolstack 4.6 ==
>
> *  pvscsi in libxl (fair)
>   -  Juergen Gross and Olaf
>
> *  COarse-grain LOck-stepping Virtual Machines in Xen (fair)
>    RFC v3 posted, based on remus-v19
>   -  Wen Congyang
>   -  Gui Jianfeng
>   -  Yang Hongyang
>   -  Dong, Eddie
>
> *  extend the xenstore ring with a 'closing' signal (fair)
>    RFC patch posted
>   -  David Scott
>
> *  libxl migrationv2 patches. (none)
>   -  Andrew Cooper & David Vrabel
>
> *  tmem migrationv2 patches. (none)
>   -  Bob Liu & Andrew Cooper & David Vrabel
>
> *  Remus using migration-v2 (fair)
>    RFC posted - depends on v6 of 'New Migration'
>   -  Yang Hongyang
>
> *  snapshot API extension (checkpointing disk) (ok)
>    v5
>    His email bounces.
>   -  Bamvor Jian Zhang
>
> *  Rearrange and cleanup installation destination directories (/var ->
> var/lib/xen) (fair)
>   -  Daniel Kiper
>
> *  libxl/xl - xm compatibility mode for mem-max and mem-set; (ok)
>   -  Daniel Kiper
>
> *  xl list --long (and some related xl commands) have some bugs (none)
>   -  Zhigang Wang
>
> *  Xen HPET interrupt fixes (fair)
>    behind migration v2
>   -  Andrew Cooper
>
> *  cpuid leveling (none)
>
> http://xenbits.xen.org/people/andrewcoop/feature-levelling/feature-levelling-D.pdf
>   -  Andrew Cooper
>
> *  live migration knobs, there is no suitable code yet, just ideas (none)
>
> http://lists.xenproject.org/archives/html/xen-devel/2014-03/msg00785.html
>   -  Olaf Hering
>
> *  xl does not handle migrate interruption gracefully (none)
>    If you start a localhost migrate, and press "Ctrl-C" in the middle, you
> get two hung domains
>   -  Ian Jackson
>
> *  IO-NUMA - hwloc and xl (none)
>    Andrew Cooper had an RFC patch for hwloc
>    add restrictions  as to which devices cannot safely/functionally be
> split apart.
>   -  Boris Ostrovsky
>
> *  HVM guest NUMA (none)
>   -  Matt Wilson
>
> *  PVH - Migration of PVH DomUs. (none)
>    Depends on migration2 code
>   -  Roger Pau Monné
>
> *  PVH - Migration of guests from a PVH dom0  (none)
>    Depends on migration2 code
>   -  Roger Pau Monné
>
> *  "Short" grant copy (just header) of packets. (none)
>   -  Zoltan Kiss
>
> == Up for grabs ==
>
> *  OSSTest - also test Linux PVH guests
>
> *  PoD fixes
>    if you boot with memory <= maxmem we have a size estimation bug
>
> *  TLB flushing without locks in Xen
>
> *  xl does not support specifying virtual function for passthrough device
>    http://bugs.xenproject.org/xen/bug/22
>
> *  PCI hole resize support hvmloader/qemu-traditional/qemu-upstream with
> PCI/GPU passthrough
>    http://bugs.xenproject.org/xen/bug/28
>
> *  libx{c,l} error handling cleanup
>
> *  Adding missing 'xend' features in libxl
>
> *  xl list -l on a dom0-only system
>
> *  xl list -l doesn't contain tty console port
>
> *  xl: passing more defaults in configuration in xl.conf
>    There are a number of options for which it might be useful to pass a
> default in xl.conf.  For example, if we could have a default "backend"
> parameter for vifs, then it would be easy to switch back and forth between
> a backend in a driver domain and a backend in dom0.
>
> *  PVH - PVH working with shadow.
>    Based on Tim's work
>
> *  PVH - PCI passthrough for DomU.
>
> *  AMD performance regressions
>
> *  Performance due to hypercall preemption. More preemptions - slower.
> (none)
>
> == Completed ==
>
> *  ARM - MiniOS (done)
>    v7 posted
>   -  Thomas Leonard
>
> *  ARM XEN_DOMCTL_memory_mapping hypercall for ARM (done)
>    v12 posted.
>   -  Arianna Avanzini
>
> *  libxl work - JSON to keep track of guest configs (done)
>   -  Wei Liu
>
> *  ARM - XENFEAT_grant_map_11 (aka map grants refs at pfn = mfn) (done)
>    Provide kernels an grant->MFN lookup
>    v4
>   -  Stefano Stabellini
>
> *  ARM PSCI v0.2 (done)
>    v11 posted
>   -  Parth Dixit
>
> *  pvSCSI in Linux (fronted and backend) (done)
>    v6
>   -  Juergen Gross
>
> *  alternative_asm in Xen (done)
>   -  Feng Wu
>
> *  SMAP (done)
>   -  Feng Wu
>
> *  Re-write of vHPET (done)
>    aka hvm/hpet: Detect comparator values in the past
>   -  Don Slutz
>
> *  vAPIC in PVHVM guests (Xen side) (done)
>   -  Boris Ostrovsky
>
> *  libvirt and xl discard support, so that libvirt can start using it
> (done)
>   -  Olaf Hering
>
> *  Xen PVH dom0 (done)
>   -  Mukesh Rathor
>
> *  Linux PVH dom0 (done)
>   -  Mukesh Rathor
>
> *  OSSTest: upstream QEMU (done)
>   -  Ian Campbell
>
> *  amd_ucode cleanups, verify patch size(enhancement) (mostly in master
> except one patch)
>
> *  Data breakpoint Extension support (new-feat) (in master)
>
> *  Feature masking MSR support (enhancement) (in master)
>
> *  Support BRCM TruManage chip (Serial over LAN support) (new-feat) (in
> master)
>
> *  fix vmce_amd* functions, unify mce_amd mcheck initialization
> (fixes/cleanups)
>
> *  multiple AMD container files appended together in initrd (early
> initramfs)
>   -  Aravind and Suravee
>
> *  NUMA memory scrubbing (done)
>   -  Konrad Rzeszutek Wilk
>
> *  ARM  - IOMMU support (done)
>   -  Julien Grall
>
> *  ioreq-server, aka secondary emulators (done)
>   -  Paul Durrant
>
> *  Netback multiqueue (good)
>   -  Wei Liu
>
> *  ARM Interrupt latency reduction (no maintenance interrupts) (good)
>   -  Stefano Stabellini
>
> *  Bigger PCI hole in QEMU (done)
>    Needs to be rebased
>   -  Don Slutz
>
> *  ARM DRA7 support (done)
>    v3 posted
>    v3 with comments applied
>   -  Andrii Tseglytskyi
>
> *  rework VM Generation ID (done)
>    v7 posted
>   -  David Vrabel
>
> *  Soft affinity for vcpus (was NUMA affinity for vcpus) (good)
>    v11 posted
>   -  Dario Faggioli
>
> *  Linux pvops of Xen EFI hypercall support (done)
>   -  Daniel Kiper
>
> *  ARM: Use super pages in p2m (done)
>    v5 posted
>   -  Ian Campbell
>
> *  QEMU 2.0 branch for qemu-upstream (done)
>    It is v2.0 with 2.1 Xen backports.
>   -  Stefano Stabellini
>
> *  systemd support (done)
>    v11
>   -  Luis R. Rodriguez
>
> *  Soft affinity for vcpus libxl/xl changes (done)
>    v13 posted
>   -  Dario Faggioli
>
> *  HT enabled, virtualization overhead is high (Xen 4.4) (done)
>    kernbench demonstrated it
>    Looking and tracing
>    http://www.gossamer-threads.com/lists/xen/devel/339409
>    False alarm.
>   -  Dario Faggioli
>
>


-- 
Elena

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

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

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

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Tamas K Lengyel]

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

Hi Konrad,
I would like to ask for an exception for this feature:

*  ARM implement mem_access (ok)
>    v5
>    https://github.com/tklengyel/xen/tree/arm_memaccess5
>   -  Tamas K Lengyel
>

The version 9 of the series will be posted tomorrow. The first half of the
series (cleanup and relocation) is mostly acked and mergeable and there had
been some discussion that it might be merged before the second half
(ARM-specific bits) are finished with the review process (which are IMHO
also very close to the finish line).

Thanks,
Tamas

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

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

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

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Boris Ostrovsky]

On 09/10/2014 01:05 PM, konrad.wilk@oracle.com wrote:
>
> *  VPMU - 'perf' support in Xen (good)
>     v10 posted
>     Need perf aware person to review for final ack.
>    -  Boris Ostrovsky
>

I have v12 that addresses Konrad's comments (which were mostly fairly 
minor), except for XSM support. I will need a few days to get it working 
--- I am having a bit of difficulty getting it right.

I can post v12 tomorrow or wait until XSM is finished.

Given that today is the deadline for posting and the fact that AFAIK 
there are no major issues with the series (save for XSM) I think it 
makes sense for me to ask for an exception. I still need reviews from 
Dietmar and Jan (at least for interface changes that he requested).

-boris

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Dave Scott]

Hi Konrad,

On 10 Sep 2014, at 18:05, <konrad.wilk@oracle.com> <konrad.wilk@oracle.com> wrote:

> *  extend the xenstore ring with a 'closing' signal (fair)
>   RFC patch posted
>  -  David Scott

I’d like to propose an exception for this one. The title is perhaps underselling it: although it is a protocol extension (and hence a new feature) the main motivation is to fix a bug in hvmloader which causes HVM guests to hang during booting on a busy machine. The bug is fairly easy to reproduce with ~200 VMs: you’ll probably find at least one failed to boot.

The patch set has got to a v4 but needs a little bit of work to clarify the relationship between the closing signal and the existing RESET_WATCHES xenstore protocol request.

I may be pushing my luck here :-) but I’d like to propose an additional exception for a feature not on your list:

* xl, libxl: add support for ‘channels'

This has got to a v6 and I believe the API and implementation is stable. It mainly needs some review of the xl config file parsing changes. This is definitely a new feature and not a bug fix. I’d mainly like to make the API official so that I can depend upon it in libvirt.

Thanks for your consideration!

Dave Scott

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[George Dunlap]

On 09/25/2014 10:22 AM, Dave Scott wrote:
> Hi Konrad,
>
> On 10 Sep 2014, at 18:05, <konrad.wilk@oracle.com> <konrad.wilk@oracle.com> wrote:
>
>> *  extend the xenstore ring with a 'closing' signal (fair)
>>    RFC patch posted
>>   -  David Scott
> I’d like to propose an exception for this one. The title is perhaps underselling it: although it is a protocol extension (and hence a new feature) the main motivation is to fix a bug in hvmloader which causes HVM guests to hang during booting on a busy machine. The bug is fairly easy to reproduce with ~200 VMs: you’ll probably find at least one failed to boot.
>
> The patch set has got to a v4 but needs a little bit of work to clarify the relationship between the closing signal and the existing RESET_WATCHES xenstore protocol request.
>
> I may be pushing my luck here :-) but I’d like to propose an additional exception for a feature not on your list:
>
> * xl, libxl: add support for ‘channels'
>
> This has got to a v6 and I believe the API and implementation is stable. It mainly needs some review of the xl config file parsing changes. This is definitely a new feature and not a bug fix. I’d mainly like to make the API official so that I can depend upon it in libvirt.
>
> Thanks for your consideration!

I think a release exception is like an Acked-by or a Reviewed-by: it 
applies to a specific version of a patch series, not the general idea of 
the patch series.  There's no point arguing for a release exception 
until you actually have an otherwise fully-Acked patch series.

  -George

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Konrad Rzeszutek Wilk]

On Thu, Sep 25, 2014 at 10:25:42AM +0100, George Dunlap wrote:
> On 09/25/2014 10:22 AM, Dave Scott wrote:
> >Hi Konrad,
> >
> >On 10 Sep 2014, at 18:05, <konrad.wilk@oracle.com> <konrad.wilk@oracle.com> wrote:
> >
> >>*  extend the xenstore ring with a 'closing' signal (fair)
> >>   RFC patch posted
> >>  -  David Scott
> >I’d like to propose an exception for this one. The title is perhaps underselling it: although it is a protocol extension (and hence a new feature) the main motivation is to fix a bug in hvmloader which causes HVM guests to hang during booting on a busy machine. The bug is fairly easy to reproduce with ~200 VMs: you’ll probably find at least one failed to boot.
> >
> >The patch set has got to a v4 but needs a little bit of work to clarify the relationship between the closing signal and the existing RESET_WATCHES xenstore protocol request.

It looked (from a brief look) as it has OCaml and I have no experience
with that. Is there somebody who can review it?

I hadn't dug in it to give it yet an opinion (sorry).

> >
> >I may be pushing my luck here :-) but I’d like to propose an additional exception for a feature not on your list:
> >
> >* xl, libxl: add support for ‘channels'
> >
> >This has got to a v6 and I believe the API and implementation is stable. It mainly needs some review of the xl config file parsing changes. This is definitely a new feature and not a bug fix. I’d mainly like to make the API official so that I can depend upon it in libvirt.
> >
> >Thanks for your consideration!
> 
> I think a release exception is like an Acked-by or a Reviewed-by: it applies
> to a specific version of a patch series, not the general idea of the patch
> series.  There's no point arguing for a release exception until you actually
> have an otherwise fully-Acked patch series.

This is going to hard decision. I looked over the patches and while I had minor
comments - the toolstack maintainers MUST also Ack it.

I am not yet sure whether to give it an exception or not so please don't
treat my comments as endorsment - I just needed to understand the code
and think about the ramifications along with the maintainers opionions.

> 
>  -George

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

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Konrad Rzeszutek Wilk]

On Wed, Sep 24, 2014 at 06:53:14PM -0400, Boris Ostrovsky wrote:
> On 09/10/2014 01:05 PM, konrad.wilk@oracle.com wrote:
> >
> >*  VPMU - 'perf' support in Xen (good)
> >    v10 posted
> >    Need perf aware person to review for final ack.
> >   -  Boris Ostrovsky
> >
> 
> I have v12 that addresses Konrad's comments (which were mostly fairly
> minor), except for XSM support. I will need a few days to get it working ---
> I am having a bit of difficulty getting it right.
> 
> I can post v12 tomorrow or wait until XSM is finished.

Thank you!
> 
> Given that today is the deadline for posting and the fact that AFAIK there
> are no major issues with the series (save for XSM) I think it makes sense
> for me to ask for an exception. I still need reviews from Dietmar and Jan
> (at least for interface changes that he requested).

See http://lists.xen.org/archives/html/xen-devel/2014-09/msg04332.html for
full details.

The summary is yes - with the provision that the different maintainers are OK
with the patches (Daniel, Dietmar, and Jan).

> 
> -boris

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Konrad Rzeszutek Wilk]

On Wed, Sep 24, 2014 at 07:23:57PM +0200, Tamas K Lengyel wrote:
> Hi Konrad,
> I would like to ask for an exception for this feature:
> 
> *  ARM implement mem_access (ok)
> >    v5
> >    https://github.com/tklengyel/xen/tree/arm_memaccess5
> >   -  Tamas K Lengyel
> >
> 
> The version 9 of the series will be posted tomorrow. The first half of the
> series (cleanup and relocation) is mostly acked and mergeable and there had
> been some discussion that it might be merged before the second half
> (ARM-specific bits) are finished with the review process (which are IMHO
> also very close to the finish line).

As you saw Jan already merged the mergable patches (up to 10 I believe).
The rest will take some time to review.

I need to discuss this with Tim and also look at the patches to get a feel
for:
 - What is the risk of it introducing regressions for existing use-cases.
 - What is the risk if these features do not make it in Xen 4.5
   (What are the external impacts of this - what are the sub-projects
    that depend on this).
 - What is the awesomes of this. As in, how will this feature make
   Xen more awesome.
 - How easy is it for somebody to set this up and test it out?

Thank you!

> 
> Thanks,
> Tamas

RC slip by a week. Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Konrad Rzeszutek Wilk]

> = Timeline =
> 
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
> 
> 
> * Feature Freeze: 24th September 2014
> * First RC: 15th October
> * Release: 10th December 2014
> 
> The RCs and release will of course depend on stability and bugs, and
> will therefore be fairly unpredictable.  The feature freeze may be
> slipped for especially important features which are near completion.

The schedule for the RC will slip one week. This is primary driven
by the http://lists.xen.org/archives/html/xen-devel/2014-09/msg04277.html
which will require changes to the hypervisor (addition of new hypercalls).

As such to make this easier and without having a tight deadline looming
(well, it is still tight) the first RC is going to slip by one week - that
is it is now the 25th of October, thought since that is a Saturday lets make
it on the 24th (Friday).

Please bear in mind that after the first RCs only bug-fixes are to considered.

With your patches, please add the 'for-xen-4.5' in the title of the
patch to make it easier to figure out.

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Dave Scott]

Hi Konrad,

On 25 Sep 2014, at 22:26, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:

> On Thu, Sep 25, 2014 at 10:25:42AM +0100, George Dunlap wrote:
>> On 09/25/2014 10:22 AM, Dave Scott wrote:
>>> Hi Konrad,
>>> 
>>> On 10 Sep 2014, at 18:05, <konrad.wilk@oracle.com> <konrad.wilk@oracle.com> wrote:
>>> 
>>>> *  extend the xenstore ring with a 'closing' signal (fair)
>>>>  RFC patch posted
>>>> -  David Scott
>>> I’d like to propose an exception for this one. The title is perhaps underselling it: although it is a protocol extension (and hence a new feature) the main motivation is to fix a bug in hvmloader which causes HVM guests to hang during booting on a busy machine. The bug is fairly easy to reproduce with ~200 VMs: you’ll probably find at least one failed to boot.
>>> 
>>> The patch set has got to a v4 but needs a little bit of work to clarify the relationship between the closing signal and the existing RESET_WATCHES xenstore protocol request.
> 
> It looked (from a brief look) as it has OCaml and I have no experience
> with that. Is there somebody who can review it?
> 
> I hadn't dug in it to give it yet an opinion (sorry).

I’ve managed to gather an Acked-by from IanJ (NB without reviewing the OCaml parts):

http://lists.xenproject.org/archives/html/xen-devel/2014-09/msg04255.html

On 26 Sep 2014, at 15:00, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:

> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> I'm happy to take this from you without really reviewing the ocaml
> code.


and I’ve got a positive review from Jon Ludlam (an OCaml expert)[added to cc:] just now on the OCaml parts:

http://lists.xenproject.org/archives/html/xen-devel/2014-10/msg00748.html

On 7 Oct 2014, at 12:26, Jon Ludlam <jonathan.ludlam@eu.citrix.com> wrote:

> Handling the exception higher up looks a fair bit nicer, and my previous
> comment has been addressed, so it looks fine to me.
> 
> Reviewed-by: Jon Ludlam <jonathan.ludlam@citrix.com>

FWIW I think this is still worth taking for 4.5 because

1. it fixes a real bug (HVM VMs occasionally failing to boot because of bad hvmloader/xenstored interaction)

2. the oxenstored changes are quite unobtrusive: the flag is sampled at the bottom, an exception bubbles all the way (almost) to the top and is handled there. If something were to go wrong, that exception would be caught at the main loop allowing the process to continue.

What do you think?

Cheers,
Dave

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Konrad Rzeszutek Wilk]

On Tue, Oct 07, 2014 at 12:48:27PM +0000, Dave Scott wrote:
> Hi Konrad,
> 
> On 25 Sep 2014, at 22:26, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> 
> > On Thu, Sep 25, 2014 at 10:25:42AM +0100, George Dunlap wrote:
> >> On 09/25/2014 10:22 AM, Dave Scott wrote:
> >>> Hi Konrad,
> >>> 
> >>> On 10 Sep 2014, at 18:05, <konrad.wilk@oracle.com> <konrad.wilk@oracle.com> wrote:
> >>> 
> >>>> *  extend the xenstore ring with a 'closing' signal (fair)
> >>>>  RFC patch posted
> >>>> -  David Scott
> >>> I’d like to propose an exception for this one. The title is perhaps underselling it: although it is a protocol extension (and hence a new feature) the main motivation is to fix a bug in hvmloader which causes HVM guests to hang during booting on a busy machine. The bug is fairly easy to reproduce with ~200 VMs: you’ll probably find at least one failed to boot.
> >>> 
> >>> The patch set has got to a v4 but needs a little bit of work to clarify the relationship between the closing signal and the existing RESET_WATCHES xenstore protocol request.
> > 
> > It looked (from a brief look) as it has OCaml and I have no experience
> > with that. Is there somebody who can review it?
> > 
> > I hadn't dug in it to give it yet an opinion (sorry).
> 
> I’ve managed to gather an Acked-by from IanJ (NB without reviewing the OCaml parts):
> 
> http://lists.xenproject.org/archives/html/xen-devel/2014-09/msg04255.html

<nods>
> 
> On 26 Sep 2014, at 15:00, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> 
> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> > 
> > I'm happy to take this from you without really reviewing the ocaml
> > code.
> 
> 
> and I’ve got a positive review from Jon Ludlam (an OCaml expert)[added to cc:] just now on the OCaml parts:
> 
> http://lists.xenproject.org/archives/html/xen-devel/2014-10/msg00748.html
> 
> On 7 Oct 2014, at 12:26, Jon Ludlam <jonathan.ludlam@eu.citrix.com> wrote:
> 
> > Handling the exception higher up looks a fair bit nicer, and my previous
> > comment has been addressed, so it looks fine to me.
> > 
> > Reviewed-by: Jon Ludlam <jonathan.ludlam@citrix.com>
> 
> FWIW I think this is still worth taking for 4.5 because
> 
> 1. it fixes a real bug (HVM VMs occasionally failing to boot because of bad hvmloader/xenstored interaction)
> 
> 2. the oxenstored changes are quite unobtrusive: the flag is sampled at the bottom, an exception bubbles all the way (almost) to the top and is handled there. If something were to go wrong, that exception would be caught at the main loop allowing the process to continue.
> 
> What do you think?

I concur.

Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

> 
> Cheers,
> Dave
> 

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

Re: Xen 4.5 development update (September update). Feature freeze slip by two weeks.

[Ian Campbell]

On Tue, 2014-10-07 at 10:50 -0400, Konrad Rzeszutek Wilk wrote:
> On Tue, Oct 07, 2014 at 12:48:27PM +0000, Dave Scott wrote:
> > Hi Konrad,
> > 
> > On 25 Sep 2014, at 22:26, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> > 
> > > On Thu, Sep 25, 2014 at 10:25:42AM +0100, George Dunlap wrote:
> > >> On 09/25/2014 10:22 AM, Dave Scott wrote:
> > >>> Hi Konrad,
> > >>> 
> > >>> On 10 Sep 2014, at 18:05, <konrad.wilk@oracle.com> <konrad.wilk@oracle.com> wrote:
> > >>> 
> > >>>> *  extend the xenstore ring with a 'closing' signal (fair)
[...]
> > FWIW I think this is still worth taking for 4.5 because
> > 
> > 1. it fixes a real bug (HVM VMs occasionally failing to boot because of bad hvmloader/xenstored interaction)
> > 
> > 2. the oxenstored changes are quite unobtrusive: the flag is sampled at the bottom, an exception bubbles all the way (almost) to the top and is handled there. If something were to go wrong, that exception would be caught at the main loop allowing the process to continue.
> > 
> > What do you think?
> 
> I concur.
> 
> Release-Acked-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Applied this one.