Xen devel - Dec 2013 - Xen 4.4 development update: Is PVH a blocker?

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

Our timeline had us start the code freeze last Friday.  However, we
have not released an RC0 because we have been waiting for PVH dom0
support.  Adding bug fixes during RCs makes sense, but RC0 should
contain all of the functionality we expect to be in the final release.

PVH dom0 support is making progress, however it''s not that clear when
it will actually be ready to be checked in.  The current discussion is
about refcounting the new p2m type, which is a tricky and delicate
operation (though luckily one which should be limited to domains which
use that type -- at the moment, exclusively PVH dom0s).

If we continue to wait, it is likely that the release will slip.  The question
then is, how long should we continue to wait before we cut our losses and
say we''ll wait for PVH dom0 until 4.5?

It would be very nice to have an RC out before Christmas, so
enthusiasts can play around with it over the holidays.  One option
would be to set a date to cut the first RC -- say, next Friday 20
December -- and just use the most recent changeset to pass the
push-gate, whether it has dom0 PVH or not.

Or we can just wait, and take stock of the situation again in January.

Thoughts?

In other news, I will be on holiday and / or travelling for
conferences until 20 January; during that time, Ian Campbell has
agreed to take over my role as Release Coordinator.

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

* Feature freeze: 18 October 2013
* Code freezing point: 18 November 2013
* First RCs: 6 December 2013  <== WE ARE HERE
* Release: 21 January 2014

Last updated: 13 December 2013

== Completed =
* Event channel scalability (FIFO event channels)

* Non-udev scripts for driver domains (non-Linux driver domains)

* Multi-vector PCI MSI (Hypervisor side)

* Improved Spice support on libxl
 - Added Spice vdagent support
 - Added Spice clipboard sharing support
 - Spice usbredirection support for upstream qemu

* PHV domU (experimental only)

* pvgrub2 checked into grub upstream

* ARM64 guest

* Guest EFI booting (tianocore)

* kexec

* Testing: Xen on ARM

* Update to SeaBIOS 1.7.3.1

* Update to qemu 1.6

* SWIOTLB (in Linux 3.13)

* Disk: indirect descriptors (in 3.11)

* Reworked ocaml bindings

== Resolved since last update =
* Supposed regression from a3513737 ("x86: allow guest to set/clear

* qemu-traditional mis-parses host bus 8 as 0
  - Invalid: parses "08" as octal, as qemu-xen does.
  - Just needs documenting (see below)

== Open =
* xl support for vnc and vnclisten options with PV guests
 > http://bugs.xenproject.org/xen/bug/25
 Blocker?

* 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

* xl needs to disallow PoD with PCI passthrough
  >see
http://xen.1045712.n5.nabble.com/PATCH-VT-d-Dis-allow-PCI-device-assignment-if-PoD-is-enabled-td2547788.html

* qemu-upstream not freeing pirq
 > http://www.gossamer-threads.com/lists/xen/devel/281498
 > http://marc.info/?l=xen-devel&m=137265766424502
 status: patches posted; latest patches need testing
 Not a blocker.

* 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
 Not a blocker.

* xl does not support specifying virtual function for passthrough device
 > http://bugs.xenproject.org/xen/bug/22
 Too much work to be a blocker.

* 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

* Win2k3 SP2 RTC infinite loops
   > Regression introduced late in Xen-4.3 development
   owner: andrew.cooper@citrix
   status: patches posted, undergoing review. ( v2 ID
1386241748-9617-1-git-send-email-andrew.cooper3@citrix.com )

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

* PCI hole resize support hvmloader/qemu-traditional/qemu-upstream
with PCI/GPU passthrough
  > http://lists.xen.org/archives/html/xen-devel/2013-05/msg02813.html
  > Where Stefano writes:
  > 2) for Xen 4.4 rework the two patches above and improve
  > i440fx_update_pci_mem_hole: resizing the pci_hole subregion is not
  > enough, it also needs to be able to resize the system memory region
  > (xen.ram) to make room for the bigger pci_hole

* qemu memory leak?
  > http://lists.xen.org/archives/html/xen-users/2013-03/msg00276.html

* qemu-* parses "008" as octal in USB bus.addr format
  > http://bugs.xenproject.org/xen/bug/15
  > just needs documenting

=== Big ticket items ==
* PVH dom0 (w/ Linux)
  blocker
  owner: mukesh@oracle, george@citrix
  status (Linux): Acked, waiting for ABI to be nailed down
  status (Xen): v6 posted; considered a blocker

* 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

On Fri, Dec 13, 2013 at 07:21:07PM +0000, George Dunlap
wrote:
> This information will be mirrored on the Xen 4.4 Roadmap wiki page:
>  http://wiki.xen.org/wiki/Xen_Roadmap/4.4
> 
> Our timeline had us start the code freeze last Friday.  However, we
> have not released an RC0 because we have been waiting for PVH dom0
> support.  Adding bug fixes during RCs makes sense, but RC0 should
> contain all of the functionality we expect to be in the final release.
> 
> PVH dom0 support is making progress, however it''s not that clear
when
> it will actually be ready to be checked in.  The current discussion is
> about refcounting the new p2m type, which is a tricky and delicate
> operation (though luckily one which should be limited to domains which
> use that type -- at the moment, exclusively PVH dom0s).
> 
> If we continue to wait, it is likely that the release will slip.  The
question
> then is, how long should we continue to wait before we cut our losses and
> say we''ll wait for PVH dom0 until 4.5?
> 
> It would be very nice to have an RC out before Christmas, so
> enthusiasts can play around with it over the holidays.  One option
> would be to set a date to cut the first RC -- say, next Friday 20
> December -- and just use the most recent changeset to pass the
> push-gate, whether it has dom0 PVH or not.
> 
> Or we can just wait, and take stock of the situation again in January.
I would of course want to see PVH dom0 in it. I am right now re-working
Mukesh''s patches to be applicable for Linux and I hope to get all of
this
done by next week.

Which would be really neat to have it all working when v3.14 merge
windows open and Xen 4.4 RC0 is out.

In regards to having RC before X-Mas. Meeh.

> 
> Thoughts?
> 
> In other news, I will be on holiday and / or travelling for
> conferences until 20 January; during that time, Ian Campbell has
> agreed to take over my role as Release Coordinator.
Woot! Enjoy the travels.
 
> 
> = Timeline > == Open =
> * qemu-upstream not freeing pirq
>  > http://www.gossamer-threads.com/lists/xen/devel/281498
>  > http://marc.info/?l=xen-devel&m=137265766424502
>  status: patches posted; latest patches need testing
>  Not a blocker.
I can''t test it, b/c qemu-upstream does not work with PCI passthrough
anymore.
> 
> * 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
>  Not a blocker.
Need to rework them.
> === Big ticket items ==> 
> * PVH dom0 (w/ Linux)
>   blocker
>   owner: mukesh@oracle, george@citrix
>   status (Linux): Acked, waiting for ABI to be nailed down
That is kind of down. I had reposted the Linux one and I am
reworking them to be easier to grok.

> == Open =>
Also, xl as opposed to xend, allows me to share a disk without
any fanfare.

Meaning I can do this:

xl block-attach phy:/dev/sda latest1 xvda w
xl block-attach phy:/dev/sda latest2 xvda w

while if I had used ''xend'' I had to also append the
''!'' parameter
to denote it as ''shared''.

Friday, December 13, 2013, 8:39:26 PM, you wrote:
> On Fri, Dec 13, 2013 at 07:21:07PM +0000, George Dunlap wrote:
>> This information will be mirrored on the Xen 4.4 Roadmap wiki page:
>>  http://wiki.xen.org/wiki/Xen_Roadmap/4.4
>> 
>> Our timeline had us start the code freeze last Friday.  However, we
>> have not released an RC0 because we have been waiting for PVH dom0
>> support.  Adding bug fixes during RCs makes sense, but RC0 should
>> contain all of the functionality we expect to be in the final release.
>> 
>> PVH dom0 support is making progress, however it''s not that
clear when
>> it will actually be ready to be checked in.  The current discussion is
>> about refcounting the new p2m type, which is a tricky and delicate
>> operation (though luckily one which should be limited to domains which
>> use that type -- at the moment, exclusively PVH dom0s).
>> 
>> If we continue to wait, it is likely that the release will slip.  The
question
>> then is, how long should we continue to wait before we cut our losses
and
>> say we''ll wait for PVH dom0 until 4.5?
>> 
>> It would be very nice to have an RC out before Christmas, so
>> enthusiasts can play around with it over the holidays.  One option
>> would be to set a date to cut the first RC -- say, next Friday 20
>> December -- and just use the most recent changeset to pass the
>> push-gate, whether it has dom0 PVH or not.
>> 
>> Or we can just wait, and take stock of the situation again in January.
> I would of course want to see PVH dom0 in it. I am right now re-working
> Mukesh''s patches to be applicable for Linux and I hope to get all
of this
> done by next week.
> Which would be really neat to have it all working when v3.14 merge
> windows open and Xen 4.4 RC0 is out.
> In regards to having RC before X-Mas. Meeh.
>> 
>> Thoughts?
>> 
>> In other news, I will be on holiday and / or travelling for
>> conferences until 20 January; during that time, Ian Campbell has
>> agreed to take over my role as Release Coordinator.
> Woot! Enjoy the travels.
>  
>> 
>> = Timeline >> == Open =
>> * qemu-upstream not freeing pirq
>>  > http://www.gossamer-threads.com/lists/xen/devel/281498
>>  > http://marc.info/?l=xen-devel&m=137265766424502
>>  status: patches posted; latest patches need testing
>>  Not a blocker.
> I can''t test it, b/c qemu-upstream does not work with PCI
passthrough
> anymore.
Strange, pci passthrough in general works for me on "simple" pci
devices (usb cards, videograbber) with latest qemu-upstream and seabios
upstream.
(if you have no need for pci rombars, no vga passthrough, no need for specifying
funky things about which virtual functions to passthrough)

What are you trying to passthrough ?
What problems do you have / errors do you see ?

>> 
>> * 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
>>  Not a blocker.
> Need to rework them.
>> === Big ticket items ==>> 
>> * PVH dom0 (w/ Linux)
>>   blocker
>>   owner: mukesh@oracle, george@citrix
>>   status (Linux): Acked, waiting for ABI to be nailed down
> That is kind of down. I had reposted the Linux one and I am
> reworking them to be easier to grok.

>>> On 13.12.13 at 20:21, 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 
> 
> Our timeline had us start the code freeze last Friday.  However, we
> have not released an RC0 because we have been waiting for PVH dom0
> support.  Adding bug fixes during RCs makes sense, but RC0 should
> contain all of the functionality we expect to be in the final release.
> 
> PVH dom0 support is making progress, however it''s not that clear
when
> it will actually be ready to be checked in.  The current discussion is
> about refcounting the new p2m type, which is a tricky and delicate
> operation (though luckily one which should be limited to domains which
> use that type -- at the moment, exclusively PVH dom0s).
> 
> If we continue to wait, it is likely that the release will slip.  The 
> question
> then is, how long should we continue to wait before we cut our losses and
> say we''ll wait for PVH dom0 until 4.5?
Even if likely unpopular, given the condition the one critical patch
is in I''d favor not waiting any longer at all, deferring the feature
to 4.5 and cutting RC1 e.g. based on what got pushed over the
weekend.

Jan