Xen devel - Nov 2013 - Xen 4.4 development update: Feature freeze has started

This information will be mirrored on the Xen 4.4 Roadmap wiki page:
 http://wiki.xen.org/wiki/Xen_Roadmap/4.4

It''s been over a month since the last mail, so I expect there are a
number of updates -- please take a look through.

I''ve tried to put the "big-ticket" items I think close to
being done
before the code freeze near the top.  I''ve moved "clean-ups"
and
big-ticket items which have missed the feature freeze lower, to be a
bit out of the way.  This is not meant to be a declaratory judgement
-- if you think your feature is in the wrong place (for example,
because you in fact posted a series before the feature freeze on 18
October), then please let me know.

= Timeline 
Here is our current timeline based on a 6-month release:

* Feature freeze: 18 October 2013 <== WE ARE HERE
* Code freezing point: 18 November 2013 (Note date change)
* First RC: 6 December 2013
* Release: 21 January 2014

Last updated: 11 November 2016

== Completed  =
* Multi-vector PCI MSI (Hypervisor side)

* Improved Spice support on libxl
 - Added Spice vdagent support
 - Added Spice clipboard sharing support

* Event channel scalability (FIFO event channels)

* Update to SeaBIOS 1.7.3.1

* pvgrub2 checked into grub upstream

* Guest EFI booting (tianocore)

== Open =
* qemu-upstream not freeing pirq
 > http://www.gossamer-threads.com/lists/xen/devel/281498
 status: patches posted, tested-and-acked

* Race in PV shutdown between tool detection and shutdown watch
 > http://www.gossamer-threads.com/lists/xen/devel/282467
 > Nothing to do with ACPI
 status: Patches posted

* credit scheduler doesn''t update other fields when tslice updated from
sysctl
 > Reported by Luwei Cheng <lwcheng@cs.hku.hk>
 > http://bugs.xenproject.org/xen/bug/16

* Supposed regression from a3513737 ("x86: allow guest to set/clear
 > MSI-X mask bit (try 2)"), as per
 > http://lists.xenproject.org/archives/html/xen-devel/2013-09/msg01589.html.

* qemu-traditional mis-parses host bus 8 as 0
 > http://bugs.xenproject.org/xen/bug/15

* xen_platform_pci=0 doesn''t work with qemu-xen
 > http://bugs.xenproject.org/xen/bug/20

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

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

* libxl / xl does not handle failure of remote qemu gracefully
  > Easiest way to reproduce:
  >  - set "vncunused=0" and do a local migrate
  >  - The "remote" qemu will fail because the vnc port is in use
  > The failure isn''t the problem, but everything being stuck
afterwards is

== Backlog =
=== Testing coverage ==
* new libxl w/ previous versions of xl
 @IanJ

* Host S3 suspend
 @bguthro, @dariof

* Default [example] XSM policy
 @Stefano to ask Daniel D

* Xen on ARM
 # hardware
  @ianc
   emulator: @stefano to think about it

* Storage driver domains
 @roger

* HVM pci passthrough
 @anthony

* PV pci passthrough
 @konrad (or @george if he gets to it first)

* Network driver domains
 @George

* Nested virt?
 @intel (chased by George)

* Fix SRIOV test (chase intel)
 @ianj

* Fix bisector to e-mail blame-worthy parties
 @ianj

* Fix xl shutdown
  @ianj

* stub domains
  @athony

* performance benchmarks
  @dario

=== Big ticket items ==
* Update to qemu 1.6
  owner: Anthonyper
  status: In staging, still working out a bug in the VMX code

* Rationalized backend scripts
  owner: roger@citrix
  status: patches posted

* Scripts for driver domains (depends on backend scripts)
  owner: roger@citrix
  status: Patches posted (?)
  prognosis: good

* PVH mode (w/ Linux)
  owner: mukesh@oracle, george@citrix
  status (Linux): Acked, waiting for ABI to be nailed down
  status (Xen): v15 posted

* ARM stuff: ??

* Meta: PVIO NUMA improvements
 - NUMA affinity for vcpus
    owner: Dario
    status: Patches posted
 - PV guest NUMA interface
    owner: Elena
    status: v2 posted
 - Sensible dom0 NUMA layout
 - Toolstack pinning backend thread / virq to appropraite d0 vcpu
 - NUMA-aware ballooning
    owner: Li Yechen
    status: in progress

* libvirt/libxl integration (external)
 - owner: jfehlig@suse, dario@citrix
 - patches posted (should be released before 4.4)
  - migration
  - PCI pass-through
 - In progress
  - integration w/ libvirt''s lock manager
  - improved concurrency

* xend still in tree (x)
 - xl list -l on a dom0-only system
 - xl list -l doesn''t contain tty console port
 - xl Alternate transport support for migration
 - xl PVSCSI support
 - xl PVUSB support

* NUMA Memory migration
  owner: dario@citrix
  status: In progress

* xl USB pass-through for HVM guests using Qemu USB emulation
  prognosis: Good if extended
  owner: George
  status: v6 patch series posted

* libxl: Spice usbredirection support for upstream qemu
 owner: fabio@M2R
 status: I''ll post new patch version shortly

* libxl: usb2 and usb3 controller support for upstream qemu
 owner: fabio@M2R
 status: patch v5 posted, tested and working, awaiting reviews

== Missed the feature freeze =
* xl migrate transport improvements
 owner: None
 > See discussion here: http://bugs.xenproject.org/xen/bug/19
 - Option to connect over a plain TCP socket rather than ssh
 - xl-migrate-recieve suitable for running in inetd
 - option for above to redirect log output somewhere useful
 - Documentation for setting up alternate transports

* HVM guest NUMA
  owner: Matt Wilson@amazon
  status: in progress (?)

* qemu-upstream stubdom, Linux
   owner: anthony@citrix
   status: in progress
   prognosis: ?
   qemu-upstream needs a more fully-featured libc than exists in
   mini-os.  Either work on a minimalist linux-based stubdom with
   glibc, or port one of the BSD libcs to minios.

* qemu-upstream stubdom, BSD libc
  prognosis: ?
  owner: ianj@citrix

* Network performance improvements
  owner: wei@citrix

* Disk performance improvements

* Xen EFI feature: Xen can boot from grub.efi
 owner: Daniel Kiper
 status: in progress

* Default to credit2
 status: Probably not for 4.4
 - cpu pinning
 - NUMA affinity
 - cpu "reservation"

* xenperf
  prognosis: ?
  Owner: Boris Ostrovsky
  status: v2 patches posted

* Nested virtualization on Intel

* Nested virtualization on AMD

* Multi-vector PCI MSI (upstream Linux)
  owner: konrad@oracle

* xl: passing more defaults in configuration in xl.conf
  owner: ?
  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.

* xl PVUSB pass-through for PV guests
* xl PVUSB pass-through for HVM guests
  owner: George
  status: ?
  xm/xend supports PVUSB pass-through to guests with PVUSB drivers
(both PV and HVM guests).
  - port the xm/xend functionality to xl.
  - this PVUSB feature does not require support or emulation from Qemu.
  - upstream the Linux frontend/backend drivers. Current
work-in-progress versions are in Konrad''s git tree.
  - James Harper''s GPLPV drivers for Windows include PVUSB frontend
drivers.

* Xen EFI feature: pvops dom0 able to make use of EFI run-time
services (external)
 owner: Daniel Kiper
 status: Just begun

* New kexec implementation
  owner: dvrabel@citrix
  status: v7 posted, only minor updates expected

* libxl support for Remus
   @shriram
   status: memory checkpointing - done.
           network buffering - patches posted.
           disk replication support using DRBD - TODO

=== Clean-ups ==
* mac address changes on reboot if not specified in config file
  > Needs a robust way to "add" to the config

* ACPI WAET table vs RTC emulation mode
  owner: jan@suse
  prognosis: ?
 > An overly simplified fix was posted a while ago
 >
(http://lists.xenproject.org/archives/html/xen-devel/2013-07/msg00122.html),
 > but Tim''s objection is rather valid. I can''t, however,
estimate
 > if/when I would find time to learn what tools side changes are
 > necessary to accommodate a new HVM param, and hence this is
 > currently stalled.  The current solution (as of 3fa7fb8b ["x86/HVM:
 > RTC code must be in line with WAET flags passed by hvmloader"])
 > isn''t desirable to be kept for 4.4.

* Polish up xenbugtool
  owner: wei.liu2@citrix.com

* Sort out better memory / ballooning / dom0 autoballooning thing
 > Don''t forget NUMA angle
 - Inaccurate / incomplete info from HV

* Implement Xen hypervisor dmesg log entry timestamps
 >
https://xenorg.uservoice.com/forums/172169-xen-development/suggestions/3924048-implement-xen-hypervisor-dmesg-log-entry-timestamp
 > Request seems to be for a shorter stamp (seconds-only, rather than full
date)

* Make network driver domains easier to set up / more useful
 - Make it easy to make a device assignable (in discussion)
 - Automatically start/shutdown (xendomains?)
 - Pause booting of other domains until network driver domain is up (necessary?)

* libxl: More fine-grained control over when to pass through a device
 > Some IOMMUs are secure; some are merely functional, some are not present.
 > Allow the adminitrator to set the default

* qxl
  > http://bugs.xenproject.org/xen/bug/11
  - Uninitialized struct element in qemu
  - Revert 5479961 to re-enable qxl in xl,libxl
  - Option in Xen top-level to enable qxl support in qemu tree
  - Fix sse2 MMIO issue
   - make word size arbitrary

* libxl config file

* libxl: Don''t use RAW format for "URL"-based qdisks (e.g.,
rbd:rbd/foo.img)
  - Figure out whether to use a generic URL or have a specific type for each one
  - Check existence of disk file for all RAW

* acpi-related xenstore entries not propagated on migrate
 > http://www.gossamer-threads.com/lists/xen/devel/282466
 > Only used by hvmloader; only a clean-up, not a bug.

On 11/11/13 17:18, George Dunlap wrote:
>
> * ACPI WAET table vs RTC emulation mode
>   owner: jan@suse
>   prognosis: ?
>  > An overly simplified fix was posted a while ago
>  >
(http://lists.xenproject.org/archives/html/xen-devel/2013-07/msg00122.html),
>  > but Tim''s objection is rather valid. I can''t,
however, estimate
>  > if/when I would find time to learn what tools side changes are
>  > necessary to accommodate a new HVM param, and hence this is
>  > currently stalled.  The current solution (as of 3fa7fb8b
["x86/HVM:
>  > RTC code must be in line with WAET flags passed by hvmloader"])
>  > isn''t desirable to be kept for 4.4.
It should be further noted that these changes introduced a regression
into Win2003 SP3, resulting in intermittent guest hangs on boot.   That
regression is the next item on my Xen 4.3 regressions list, after
getting the HPET host crash fixed.

Also (I am not really sure which category this resides in)

* HPET interrupt stack overflow (when using hpet_broadcast mode and MSI
capable HPETs)
  status: patches posted, undergoing review iteration.

~Andrew

> == Open => 
> * qemu-upstream not freeing pirq
>  > http://www.gossamer-threads.com/lists/xen/devel/281498
>  status: patches posted, tested-and-acked
.. but not yet committed. Ian Jackson is the person to do it right?
> * PV pci passthrough
>  @konrad (or @george if he gets to it first)
I am been doing this manually .. and hadn''t read the OSStest blog yet.
.. snip..
> == Missed the feature freeze => 
> * Multi-vector PCI MSI (upstream Linux)
>   owner: konrad@oracle
Nothing. But it should be reassigned to Boris.

On 11/11/2013 12:18 PM, George Dunlap wrote:
> == Missed the feature freeze =
...
> * xenperf
>    prognosis: ?
>    Owner: Boris Ostrovsky
>    status: v2 patches posted

Deferred to 4.5

-boris

On Mon, Nov 11, 2013 at 12:18 PM, George Dunlap
<George.Dunlap@eu.citrix.com
> wrote:
*snip*

> * Host S3 suspend
>  @bguthro, @dariof
>
I ran into infrastructure issues:
See: http://lists.xen.org/archives/html/xen-devel/2013-10/msg02298.html

If this is going to be completed for 4.4, I''m going to be looking
toward
Dario for assistance.


Ben


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

>>> On 11.11.13 at 19:03, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
>>  == Open =>> 
>> * qemu-upstream not freeing pirq
>>  > http://www.gossamer-threads.com/lists/xen/devel/281498 
>>  status: patches posted, tested-and-acked
> 
> .. but not yet committed. Ian Jackson is the person to do it right?
No, qemu-upstream is Stefano''s playgound.

Jan

On Mon, 2013-11-11 at 13:03 -0500, Konrad Rzeszutek Wilk
wrote:
> > == Open => > 
> > * qemu-upstream not freeing pirq
> >  > http://www.gossamer-threads.com/lists/xen/devel/281498
> >  status: patches posted, tested-and-acked
> 
> .. but not yet committed. Ian Jackson is the person to do it right?
No. Ian J maintains the qemu-trad fork. Stefano is the maintainer for
qemu-upstream. However, that link includes a kernel patch, which would
mean you -- but then there is quite a large thread following the
tested-and-acked patch which I haven''t read, so perhaps there is a
reason it didn''t go in?

Ian.

On 11/11/13 17:18, George Dunlap wrote:
> 
> * New kexec implementation
>   owner: dvrabel@citrix
>   status: v7 posted, only minor updates expected
This is in staging now.

David

On Mon, 2013-11-11 at 17:18 +0000, George Dunlap wrote:
> * Xen on ARM
>  # hardware
>   @ianc
The testing aspect of this is mostly in place. They aren''t actually
passing due to some missing support in Xen for the platform we actually
have. That''s on going but this item could be marked complete I think.
> === Big ticket items ==
> * ARM stuff: ??
* Live Migration Support
  owner: Jaeyong Yoo <jaeyong.yoo@samsung.com>
  status: v5 posted, looking good for code freeze

* ARM64 guest
  owner: IanC
  status: v3 posted, v4 in progress. looking good.

* SWIOTLB (kernel side thing)
  owner: Stefano
  status: Due this merge kernel window? May already be in?
> * xend still in tree (x)
>  - xl list -l on a dom0-only system
>  - xl list -l doesn''t contain tty console port
>  - xl Alternate transport support for migration
Are some of these (this one in particular) also covered separately
elsewhere in the list?

[...]
> * libxl: Spice usbredirection support for upstream qemu
>  owner: fabio@M2R
>  status: I''ll post new patch version shortly
> 
> * libxl: usb2 and usb3 controller support for upstream qemu
>  owner: fabio@M2R
>  status: patch v5 posted, tested and working, awaiting reviews
I''ve totally lost track of both of these. Both need at least an Ack
from
the qemu side IIRC.

[...]
> * Network performance improvements
>   owner: wei@citrix
Wei, Are these all done and in the kernel?
> * Disk performance improvements
Likewise this from Roger?
> * libxl config file
What is this one?

Ian.

On 12/11/13 12:09, Ian Campbell wrote:
> On Mon, 2013-11-11 at 17:18 +0000, George Dunlap wrote:
>> * Disk performance improvements
> 
> Likewise this from Roger?
We have indirect descriptors in Linux >= 3.11, I just submitted the
blkif.h Xen related patch to add the new interface to the public Xen
headers, I hope it will make it into 4.4.

On Tue, Nov 12, 2013 at 11:09:10AM +0000, Ian Campbell wrote:
[...]
> 
> I''ve totally lost track of both of these. Both need at least an
Ack from
> the qemu side IIRC.
> 
> [...]
> > * Network performance improvements
> >   owner: wei@citrix
> 
> Wei, Are these all done and in the kernel?
Yes. Xen is not involved.
> 
> > * Disk performance improvements
> 
> Likewise this from Roger?
> 
> > * libxl config file
> 
> What is this one?
> 
Generate libxl config with runtime information? If it is then I don''t
think much progress has been made.

Wei.
> Ian.

Il 12/11/2013 12:09, Ian Campbell ha scritto:
> On Mon, 2013-11-11 at 17:18 +0000, George Dunlap wrote:
>
>> * Xen on ARM
>>   # hardware
>>    @ianc
> The testing aspect of this is mostly in place. They aren''t
actually
> passing due to some missing support in Xen for the platform we actually
> have. That''s on going but this item could be marked complete I
think.
>
>> === Big ticket items ==>> * ARM stuff: ??
> * Live Migration Support
>    owner: Jaeyong Yoo <jaeyong.yoo@samsung.com>
>    status: v5 posted, looking good for code freeze
>
> * ARM64 guest
>    owner: IanC
>    status: v3 posted, v4 in progress. looking good.
>
> * SWIOTLB (kernel side thing)
>    owner: Stefano
>    status: Due this merge kernel window? May already be in?
>
>> * xend still in tree (x)
>>   - xl list -l on a dom0-only system
>>   - xl list -l doesn''t contain tty console port
>>   - xl Alternate transport support for migration
> Are some of these (this one in particular) also covered separately
> elsewhere in the list?
>
> [...]
>> * libxl: Spice usbredirection support for upstream qemu
>>   owner: fabio@M2R
>>   status: I''ll post new patch version shortly
>>
>> * libxl: usb2 and usb3 controller support for upstream qemu
>>   owner: fabio@M2R
>>   status: patch v5 posted, tested and working, awaiting reviews
> I''ve totally lost track of both of these. Both need at least an
Ack from
> the qemu side IIRC.
I remade (based on George Dunlap advices and compatible with future usb hot-plug
patches) and posted some times ago usbversion and usbredirection patches:
http://lists.xen.org/archives/html/xen-devel/2013-10/msg00580.html
http://lists.xen.org/archives/html/xen-devel/2013-10/msg00973.html

Unfortunatly no reply for one month :(

They are tested and working also with new usb passtghrough (from dom0) with
hot-plug patches of George Dunlap.

About new usb passthrough with hotplug patches I did only a refresh and one fix
but they are incomplete about some features, probably they will be ready only
for xen 4.5.
Latest post about it:
http://lists.xen.org/archives/html/xen-devel/2013-11/msg00451.html

usbversion and usbredirection seem already complete and fully working, probably
they can be inserted into Xen 4.4 after revision of the maintainers.


Thanks for any reply.
>
> [...]
>> * Network performance improvements
>>    owner: wei@citrix
> Wei, Are these all done and in the kernel?
>
>> * Disk performance improvements
> Likewise this from Roger?
>
>> * libxl config file
> What is this one?
>
> Ian.
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

On Tue, 12 Nov 2013, Jan Beulich wrote:
> >>> On 11.11.13 at 19:03, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> >>  == Open => >> 
> >> * qemu-upstream not freeing pirq
> >>  > http://www.gossamer-threads.com/lists/xen/devel/281498 
> >>  status: patches posted, tested-and-acked
> > 
> > .. but not yet committed. Ian Jackson is the person to do it right?
> 
> No, qemu-upstream is Stefano''s playgound.
Although the patch has been reworked for upstream QEMU
(http://marc.info/?l=xen-devel&m=137265766424502), it was only build
tested. Considering that I don''t have the hardware to test it right now
and that it''s not obviously correct, I was waiting for Zhenzhong to
come
back and let me know if it is actually behaving as expected.

On Tue, 12 Nov 2013, Ian Campbell wrote:
> * SWIOTLB (kernel side thing)
>   owner: Stefano
>   status: Due this merge kernel window? May already be in?
Yesterday Konrad sent a pull request to Linus with the swiotlb stuff in
it.

On Tue, Nov 12, 2013 at 12:04:29PM +0000, Stefano Stabellini
wrote:
> On Tue, 12 Nov 2013, Jan Beulich wrote:
> > >>> On 11.11.13 at 19:03, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
> > >>  == Open => > >> 
> > >> * qemu-upstream not freeing pirq
> > >>  > http://www.gossamer-threads.com/lists/xen/devel/281498 
> > >>  status: patches posted, tested-and-acked
> > > 
> > > .. but not yet committed. Ian Jackson is the person to do it
right?
This is the one I was thinking off:

http://lists.xen.org/archives/html/xen-devel/2013-07/msg00004.html

which ..
> > 
> > No, qemu-upstream is Stefano''s playgound.
> 
> Although the patch has been reworked for upstream QEMU
> (http://marc.info/?l=xen-devel&m=137265766424502), it was only build
> tested. Considering that I don''t have the hardware to test it
right now
> and that it''s not obviously correct, I was waiting for Zhenzhong
to come
> back and let me know if it is actually behaving as expected.
.. I presume is blocked until Stefano has an Tested-by from either
Sucheta (Qlogic) or Duan.

CC-ing them both.

> > * xend still in tree (x)
> >  - xl list -l on a dom0-only system
> >  - xl list -l doesn''t contain tty console port
> >  - xl Alternate transport support for migration
> 
> Are some of these (this one in particular) also covered separately
> elsewhere in the list?
I think not. But this is a good place to have this covered.

I know you posted some patches, I tested them and they seg-faulted, then..
... some time passed and I saw some patches from Wei that looked like
they were addressing some issues and assumed he is working on it?

Ian, are you looking for me or Zhigang to polish up the RFC patches?
Or has some other volunteer showed up?

(Adding Zhigang to the thread)

On Tue, 2013-11-12 at 09:20 -0500, Konrad Rzeszutek Wilk
wrote:
> > > * xend still in tree (x)
> > >  - xl list -l on a dom0-only system
> > >  - xl list -l doesn''t contain tty console port
> > >  - xl Alternate transport support for migration
> > 
> > Are some of these (this one in particular) also covered separately
> > elsewhere in the list?
> 
> I think not. But this is a good place to have this covered.
> 
> I know you posted some patches, I tested them and they seg-faulted, then..
> ... some time passed and I saw some patches from Wei that looked like
> they were addressing some issues and assumed he is working on it?
> 
> Ian, are you looking for me or Zhigang to polish up the RFC patches?
> Or has some other volunteer showed up?
Well, in so far as I''ve not managed to find the time myself I was
hoping
someone else might do it, I don''t mind who.
> 
> (Adding Zhigang to the thread)

On Tue, Nov 12, 2013 at 09:20:44AM -0500, Konrad Rzeszutek Wilk
wrote:
> > > * xend still in tree (x)
> > >  - xl list -l on a dom0-only system
> > >  - xl list -l doesn''t contain tty console port
> > >  - xl Alternate transport support for migration
> > 
> > Are some of these (this one in particular) also covered separately
> > elsewhere in the list?
> 
> I think not. But this is a good place to have this covered.
> 
> I know you posted some patches, I tested them and they seg-faulted, then..
> ... some time passed and I saw some patches from Wei that looked like
> they were addressing some issues and assumed he is working on it?
> 
I worked on them a bit during developer summit, hoping I could finish
one or two. But after I came back to Cambridge I stopped.

Wei.
> Ian, are you looking for me or Zhigang to polish up the RFC patches?
> Or has some other volunteer showed up?
> 
> (Adding Zhigang to the thread)

On Tue, Nov 12, 2013 at 02:26:37PM +0000, Wei Liu wrote:
> On Tue, Nov 12, 2013 at 09:20:44AM -0500, Konrad Rzeszutek Wilk wrote:
> > > > * xend still in tree (x)
> > > >  - xl list -l on a dom0-only system
> > > >  - xl list -l doesn''t contain tty console port
> > > >  - xl Alternate transport support for migration
> > > 
> > > Are some of these (this one in particular) also covered
separately
> > > elsewhere in the list?
> > 
> > I think not. But this is a good place to have this covered.
> > 
> > I know you posted some patches, I tested them and they seg-faulted,
then..
> > ... some time passed and I saw some patches from Wei that looked like
> > they were addressing some issues and assumed he is working on it?
> > 
> 
> I worked on them a bit during developer summit, hoping I could finish
> one or two. But after I came back to Cambridge I stopped.
Any particular reason you stopped? I was looking forward to the
patches!

On Tue, Nov 12, 2013 at 10:07:18AM -0500, Konrad Rzeszutek Wilk
wrote:
> On Tue, Nov 12, 2013 at 02:26:37PM +0000, Wei Liu wrote:
> > On Tue, Nov 12, 2013 at 09:20:44AM -0500, Konrad Rzeszutek Wilk wrote:
> > > > > * xend still in tree (x)
> > > > >  - xl list -l on a dom0-only system
> > > > >  - xl list -l doesn''t contain tty console port
> > > > >  - xl Alternate transport support for migration
> > > > 
> > > > Are some of these (this one in particular) also covered
separately
> > > > elsewhere in the list?
> > > 
> > > I think not. But this is a good place to have this covered.
> > > 
> > > I know you posted some patches, I tested them and they
seg-faulted, then..
> > > ... some time passed and I saw some patches from Wei that looked
like
> > > they were addressing some issues and assumed he is working on it?
> > > 
> > 
> > I worked on them a bit during developer summit, hoping I could finish
> > one or two. But after I came back to Cambridge I stopped.
> 
> Any particular reason you stopped? I was looking forward to the
> patches!
Oh, no particular reason. I often slice my time into two projects, one
is major project the other is side project. Side project contains (what I
think to be) bite-size fixes / features that can be finished when I''m
traveling.

It turned out that libxl problems were not as easy as I thought after
all, and my main project consumes all my time at the moment. :-(

Wei.

On lun, 2013-11-11 at 17:18 +0000, George Dunlap wrote:
> = Timeline > 
> Here is our current timeline based on a 6-month release:
> 
> * Feature freeze: 18 October 2013 <== WE ARE HERE
> * Code freezing point: 18 November 2013 (Note date change)
> * First RC: 6 December 2013
> * Release: 21 January 2014
> 
> == Open =
> * credit scheduler doesn''t update other fields when tslice updated
from sysctl
>  > Reported by Luwei Cheng <lwcheng@cs.hku.hk>
>  > http://bugs.xenproject.org/xen/bug/16
> 
George, are you working on this? If you plan to/already started
(especially considering that now that PVH is in you''re going to have
tons of free time! :-P :-P), then fine.

If not, I''m ok trying to have a look...

Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



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

On lun, 2013-11-11 at 17:18 +0000, George Dunlap wrote:
> = Timeline > 
> Here is our current timeline based on a 6-month release:
> 
> * Feature freeze: 18 October 2013 <== WE ARE HERE
> * Code freezing point: 18 November 2013 (Note date change)
> * First RC: 6 December 2013
> * Release: 21 January 2014
> === Big ticket items ==
> * Meta: PVIO NUMA improvements
>  - NUMA affinity for vcpus
>     owner: Dario
>     status: Patches posted
>
v2 posted, with a new, more general, architecture.
>  - PV guest NUMA interface
>     owner: Elena
>     status: v2 posted
>
v2 posted, right Elena? I''m on it reviewing right now.
>  - Sensible dom0 NUMA layout
>
I did start working on something related to this, but had to stop. I''d
mark this as ''deferred to 4.5'', or something like that.
>  - Toolstack pinning backend thread / virq to appropraite d0 vcpu
>
This has a dependency on all the three above (vcpu soft affinity, vNUMA
and dom0 layout).
>  - NUMA-aware ballooning
>     owner: Li Yechen
>     status: in progress
> 
I think Yechen is still interested/working on this, but this has a
dependency on vNUMA, so at this point it may be worth waiting a bit more
to see how vNUMA end up being.
> * NUMA Memory migration
>   owner: dario@citrix
>   status: In progress
> 
Deferred to 4.5. Honestly, although it is true I posted an RFC a while
back, since nothing more than that hit @xen-devel as of last Oct 18, I
think this should probably be in the section below ("Missed the feature
freeze").
> == Missed the feature freeze =
> * HVM guest NUMA
>   owner: Matt Wilson@amazon
>   status: in progress (?)
> 
This is ''Deferred to 4.5'', right Matt?

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



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

On Thu, Nov 14, 2013 at 4:38 AM, Dario Faggioli
<dario.faggioli@citrix.com> wrote:
> On lun, 2013-11-11 at 17:18 +0000, George Dunlap wrote:
>
>> = Timeline >>
>> Here is our current timeline based on a 6-month release:
>>
>> * Feature freeze: 18 October 2013 <== WE ARE HERE
>> * Code freezing point: 18 November 2013 (Note date change)
>> * First RC: 6 December 2013
>> * Release: 21 January 2014
>
>> === Big ticket items ==>
>> * Meta: PVIO NUMA improvements
>>  - NUMA affinity for vcpus
>>     owner: Dario
>>     status: Patches posted
>>
> v2 posted, with a new, more general, architecture.
>
>>  - PV guest NUMA interface
>>     owner: Elena
>>     status: v2 posted
>>
> v2 posted, right Elena? I''m on it reviewing right now.
Correct, I hope to work on reviewed patches and send them
again.
>
>>  - Sensible dom0 NUMA layout
>>
> I did start working on something related to this, but had to stop.
I''d
> mark this as ''deferred to 4.5'', or something like that.
>
>>  - Toolstack pinning backend thread / virq to appropraite d0 vcpu
>>
> This has a dependency on all the three above (vcpu soft affinity, vNUMA
> and dom0 layout).
>
>>  - NUMA-aware ballooning
>>     owner: Li Yechen
>>     status: in progress
>>
> I think Yechen is still interested/working on this, but this has a
> dependency on vNUMA, so at this point it may be worth waiting a bit more
> to see how vNUMA end up being.
>
>> * NUMA Memory migration
>>   owner: dario@citrix
>>   status: In progress
>>
> Deferred to 4.5. Honestly, although it is true I posted an RFC a while
> back, since nothing more than that hit @xen-devel as of last Oct 18, I
> think this should probably be in the section below ("Missed the
feature
> freeze").
>
>> == Missed the feature freeze =>
>> * HVM guest NUMA
>>   owner: Matt Wilson@amazon
>>   status: in progress (?)
>>
> This is ''Deferred to 4.5'', right Matt?
>
> Regards,
> Dario
>
> --
> <<This happens because I choose it to happen!>> (Raistlin
Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
>


-- 
Elena

On 11/14/2013 4:28 AM, Dario Faggioli wrote:
> On lun, 2013-11-11 at 17:18 +0000, George Dunlap wrote:
> 
>> = Timeline >>
>> Here is our current timeline based on a 6-month release:
>>
>> * Feature freeze: 18 October 2013 <== WE ARE HERE
>> * Code freezing point: 18 November 2013 (Note date change)
>> * First RC: 6 December 2013
>> * Release: 21 January 2014
>>
> 
>> == Open => 
>> * credit scheduler doesn''t update other fields when tslice
updated from sysctl
>>  > Reported by Luwei Cheng <lwcheng@cs.hku.hk>
>>  > http://bugs.xenproject.org/xen/bug/16
>>
> George, are you working on this? If you plan to/already started
> (especially considering that now that PVH is in you''re going to
have
> tons of free time! :-P :-P), then fine.
> 
> If not, I''m ok trying to have a look...
I was playing around with changing the timeslice of the credit scheduler, so I
had fixed this issue in my local repo.  When I saw that it was not fixed yet, I
figured I might as well rebase, make a patch it, and send it in.

http://article.gmane.org/gmane.comp.emulators.xen.devel/178367

If acceptable, it should save George or someone else a couple of minutes of
work.
> 
> Dario
> 
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>

On gio, 2013-11-14 at 09:16 -0500, Nate Studer wrote:
> On 11/14/2013 4:28 AM, Dario Faggioli wrote:
> > On lun, 2013-11-11 at 17:18 +0000, George Dunlap wrote:
> >> * credit scheduler doesn''t update other fields when
tslice updated from sysctl
> >>  > Reported by Luwei Cheng <lwcheng@cs.hku.hk>
> >>  > http://bugs.xenproject.org/xen/bug/16
> >>
> > George, are you working on this? If you plan to/already started
> > (especially considering that now that PVH is in you''re going
to have
> > tons of free time! :-P :-P), then fine.
> > 
> > If not, I''m ok trying to have a look...
> 
> I was playing around with changing the timeslice of the credit scheduler,
so I
> had fixed this issue in my local repo.  When I saw that it was not fixed
yet, I
> figured I might as well rebase, make a patch it, and send it in.
> 
> http://article.gmane.org/gmane.comp.emulators.xen.devel/178367
> 
Oh, wow... Cool! I''m still wondering how I managed to completely miss
it, though. :-O
> If acceptable, it should save George or someone else a couple of minutes of
work.
> 
It looks fine to me. Unfortunately, I double checked and I don''t find
the actual e-mail in my inbox, so I''m saying this here: the patch at
the
above URL can have, FWIW, my

Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



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

>>> On 14.11.13 at 10:28, Dario Faggioli
<dario.faggioli@citrix.com> wrote:
> On lun, 2013-11-11 at 17:18 +0000, George Dunlap wrote:
>> * credit scheduler doesn''t update other fields when tslice
updated from sysctl
>>  > Reported by Luwei Cheng <lwcheng@cs.hku.hk>
>>  > http://bugs.xenproject.org/xen/bug/16 
>> 
> George, are you working on this? If you plan to/already started
> (especially considering that now that PVH is in you''re going to
have
> tons of free time! :-P :-P), then fine.
Isn''t Nathan Studer''s patch

http://lists.xenproject.org/archives/html/xen-devel/2013-11/msg01988.html

doing exactly that?

Jan

>>> On 14.11.13 at 23:20, Dario Faggioli
<dario.faggioli@citrix.com> wrote:
> On gio, 2013-11-14 at 09:16 -0500, Nate Studer wrote:
>> On 11/14/2013 4:28 AM, Dario Faggioli wrote:
>> > On lun, 2013-11-11 at 17:18 +0000, George Dunlap wrote:
>> >> * credit scheduler doesn''t update other fields when
tslice updated from
> sysctl
>> >>  > Reported by Luwei Cheng <lwcheng@cs.hku.hk>
>> >>  > http://bugs.xenproject.org/xen/bug/16 
>> >>
>> > George, are you working on this? If you plan to/already started
>> > (especially considering that now that PVH is in you''re
going to have
>> > tons of free time! :-P :-P), then fine.
>> > 
>> > If not, I''m ok trying to have a look...
>> 
>> I was playing around with changing the timeslice of the credit
scheduler, so
> I
>> had fixed this issue in my local repo.  When I saw that it was not
fixed
> yet, I
>> figured I might as well rebase, make a patch it, and send it in.
>> 
>> http://article.gmane.org/gmane.comp.emulators.xen.devel/178367 
>> 
> Oh, wow... Cool! I''m still wondering how I managed to completely
miss
> it, though. :-O
> 
>> If acceptable, it should save George or someone else a couple of
minutes of
> work.
>> 
> It looks fine to me. Unfortunately, I double checked and I don''t
find
> the actual e-mail in my inbox, so I''m saying this here: the patch
at the
> above URL can have, FWIW, my
> 
> Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
Please, for the future, reply to the patch mail with any reviews
or acks - relying on committers to be collecting them from unrelated
threads is rather unreliable.

Jan

On ven, 2013-11-15 at 09:03 +0000, Jan Beulich wrote:
> >>> On 14.11.13 at 23:20, Dario Faggioli
<dario.faggioli@citrix.com> wrote:
> > It looks fine to me. Unfortunately, I double checked and I
don''t find
> > the actual e-mail in my inbox, so I''m saying this here: the
patch at the
> > above URL can have, FWIW, my
> > 
> > Reviewed-by: Dario Faggioli <dario.faggioli@citrix.com>
> 
> Please, for the future, reply to the patch mail with any reviews
> or acks - relying on committers to be collecting them from unrelated
> threads is rather unreliable.
> 
I know that, and I''m sorry. If you want to ignore the above because it
doesn''t follow the regular procedure, feel free, I know it''s
my fault
and thus I''m fine dealing with the consequences.

Unfortunately, as I said, either the message with the patch did (for
some reason) not hit my inbox, or I accidentally deleted it, so I really
didn''t have a message to reply to, but still I wanted to state that I
reviewed it and find it sound. I think it''s the first time I do that,
and I certainly don''t plan to do it again..

Anyway, sorry again for the noise.
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



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

On 11/11/13 17:32, Andrew Cooper wrote:
> * HPET interrupt stack overflow (when using hpet_broadcast mode and MSI
> capable HPETs)
>    status: patches posted, undergoing review iteration.
Is this a bug?

  -George

>>> On 15.11.13 at 15:36, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> On 11/11/13 17:32, Andrew Cooper wrote:
>> * HPET interrupt stack overflow (when using hpet_broadcast mode and MSI
>> capable HPETs)
>>    status: patches posted, undergoing review iteration.
> 
> Is this a bug?
It clearly is, but I''m nevertheless uncertain whether to take a re-
write of the HPET code at this point in time. I say this though
without having had time to look at the main patch in detail yet.

Jan

On 15/11/13 14:36, George Dunlap wrote:
> On 11/11/13 17:32, Andrew Cooper wrote:
>> * HPET interrupt stack overflow (when using hpet_broadcast mode and MSI
>> capable HPETs)
>>    status: patches posted, undergoing review iteration.
>
> Is this a bug?
>
>  -George
Yes - it causes a double fault in debug builds of Xen.

In non-debug builds, Xen will survive, but the underlying cause is that
interrupts can erroneously stack with lower priority on top of higher
priority.

The patches have been Reviewed-by Tim, and are currently in XenServer
trunk having a good trashing across all our hardware.

~Andrew

On 15/11/13 14:48, Andrew Cooper wrote:
> On 15/11/13 14:36, George Dunlap wrote:
>> On 11/11/13 17:32, Andrew Cooper wrote:
>>> * HPET interrupt stack overflow (when using hpet_broadcast mode and
MSI
>>> capable HPETs)
>>>    status: patches posted, undergoing review iteration.
>> Is this a bug?
>>
>>  -George
> Yes - it causes a double fault in debug builds of Xen.
>
> In non-debug builds, Xen will survive, but the underlying cause is that
> interrupts can erroneously stack with lower priority on top of higher
> priority.
>
> The patches have been Reviewed-by Tim, and are currently in XenServer
> trunk having a good trashing across all our hardware.
I actually meant "thrashing" here. 

("trashing" was v3 which had a bug on Nehalem/Westmere boxes which
broke
1/3rd of our test lab.  XenRT was very unhappy with me for that)

~Andrew

On 12/11/13 11:11, Roger Pau Monné wrote:
> On 12/11/13 12:09, Ian Campbell wrote:
>> On Mon, 2013-11-11 at 17:18 +0000, George Dunlap wrote:
>>> * Disk performance improvements
>> Likewise this from Roger?
> We have indirect descriptors in Linux >= 3.11, I just submitted the
> blkif.h Xen related patch to add the new interface to the public Xen
> headers, I hope it will make it into 4.4.
Sorry, is this blkif.h patch the Xen counterpart to indirect 
descriptors?  Or something else?

  -George

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

On 15/11/13 16:37, George Dunlap wrote:
> On 12/11/13 11:11, Roger Pau Monné wrote:
>> On 12/11/13 12:09, Ian Campbell wrote:
>>> On Mon, 2013-11-11 at 17:18 +0000, George Dunlap wrote:
>>>> * Disk performance improvements
>>> Likewise this from Roger?
>> We have indirect descriptors in Linux >= 3.11, I just submitted the
>> blkif.h Xen related patch to add the new interface to the public Xen
>> headers, I hope it will make it into 4.4.
> 
> Sorry, is this blkif.h patch the Xen counterpart to indirect
> descriptors?  Or something else?
Yes, it's the addition of the interface to the Xen public headers.


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

On 12/11/13 11:09, Ian Campbell wrote:
>> * xend still in tree (x)
>>   - xl list -l on a dom0-only system
>>   - xl list -l doesn''t contain tty console port
>>   - xl Alternate transport support for migration
> Are some of these (this one in particular) also covered separately
> elsewhere in the list?
Yes, this one is also here:

* xl migrate transport improvements
  owner: None
  > See discussion here: http://bugs.xenproject.org/xen/bug/19
  - Option to connect over a plain TCP socket rather than ssh
  - xl-migrate-recieve suitable for running in inetd
  - option for above to redirect log output somewhere useful
  - Documentation for setting up alternate transports

However, after the discussion with Zhigang, I''m not sure this should 
really be a blocker for xend removal anymore.  The putative reason for 
having ssl was because exchanging ssh keys was thought to be a security 
risk, allowing anyone on one host to log into any of the other hosts.  
However:

1) ssh keys can be limited so that they can only execute a specific 
command; so this can be dealt with by configuration
2) There are no permissions checks on resources for incoming domains; so 
given the ability to migrate to a host, you can get a shell on that host 
pretty handily anyway.

  -George

On 12/11/13 11:09, Ian Campbell wrote:
>> * libxl config file
> What is this one?
So at the moment we have a config file for xl, which will tell it how to 
behave.  I seem to recall a discussion at some point about having a 
config file for _libxl_, so that non-xl toolstacks which use libxl could 
specify configuration options for some things.

It wasn''t my idea, however, and it''s been long enough ago now
that I
can''t remember exactly the kinds of things that we had in mind --
things
like locations of binaries come to mind; maybe so that distros could 
package up libxl and say where things were, and other programs could 
like against it?  Does that ring any bells?

  -George

On 14/11/13 09:38, Dario Faggioli wrote:
>>   - Sensible dom0 NUMA layout
> I did start working on something related to this, but had to stop.
I''d
> mark this as ''deferred to 4.5'', or something like that.
Yes; I''m not exactly sure how to do these "meta" features
that are
composed / dependent on a number of components that are full-fledged 
features in their own right.  (xend removal is another example.) Maybe 
I''ll try to make a separate section for them.

  -George

On ven, 2013-11-15 at 16:34 +0000, George Dunlap wrote:
> On 14/11/13 09:38, Dario Faggioli wrote:
> >>   - Sensible dom0 NUMA layout
> > I did start working on something related to this, but had to stop.
I''d
> > mark this as ''deferred to 4.5'', or something like
that.
> 
> Yes; I''m not exactly sure how to do these "meta"
features that are
> composed / dependent on a number of components that are full-fledged 
> features in their own right.  (xend removal is another example.) Maybe 
> I''ll try to make a separate section for them.
> 
Yes, I think having a separate item for each one would be (at least in
this case) preferable. That leaves it open how to express the
dependencies, though.

Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)



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

On Mon, Nov 11, 2013 at 11:18 AM, George Dunlap
<George.Dunlap@eu.citrix.com
> wrote:
> This information will be mirrored on the Xen 4.4 Roadmap wiki page:
>  http://wiki.xen.org/wiki/Xen_Roadmap/4.4
>
> It''s been over a month since the last mail, so I expect there are
a
> number of updates -- please take a look through.
>
> I''ve tried to put the "big-ticket" items I think close
to being done
> before the code freeze near the top.  I''ve moved
"clean-ups" and
> big-ticket items which have missed the feature freeze lower, to be a
> bit out of the way.  This is not meant to be a declaratory judgement
> -- if you think your feature is in the wrong place (for example,
> because you in fact posted a series before the feature freeze on 18
> October), then please let me know.
>
> = Timeline >
> Here is our current timeline based on a 6-month release:
>
> * Feature freeze: 18 October 2013 <== WE ARE HERE
> * Code freezing point: 18 November 2013 (Note date change)
> * First RC: 6 December 2013
> * Release: 21 January 2014
>
> Last updated: 11 November 2016
>
>
> * libxl support for Remus
>    @shriram
>    status: memory checkpointing - done.
>            network buffering - patches posted.
>            disk replication support using DRBD - TODO
>
>
FWIW, I posted the updated patches yesterday.
As well as patches to make the domain suspend call asynchronous.


Thanks
shriram


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

On Fri, 2013-11-15 at 16:28 +0000, George Dunlap wrote:
> On 12/11/13 11:09, Ian Campbell wrote:
> >> * libxl config file
> > What is this one?
> 
> So at the moment we have a config file for xl, which will tell it how to 
> behave.  I seem to recall a discussion at some point about having a 
> config file for _libxl_, so that non-xl toolstacks which use libxl could 
> specify configuration options for some things.
> 
> It wasn''t my idea, however, and it''s been long enough ago
now that I
> can''t remember exactly the kinds of things that we had in mind --
things
> like locations of binaries come to mind; maybe so that distros could 
> package up libxl and say where things were, and other programs could 
> like against it?  Does that ring any bells?
Yes it does.

There also some settings that you''d want to be host wide for any libxl
using toolstacks sharing a host (e.g. xl and xapi). Default vif-scripts
and policy WRT selecting disk backends are two which spring to mind.

Probably a great deal of xl.conf actually belongs in libxl.conf.

Ian.