Xen 4.4 development update

Xen 4.4 development update

[George Dunlap]

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

Rather than try to predict precisely what will make it into what
release (which was something of a disaster last release), I'm just
going to borrow a term from the Agile world and call all uncompleted
features the "Backlog".  I'll still track who is doing what, and when
we get close, what state things seem to be in.

As mentioned in another e-mail, we'll also be working on improving the
regression tester.  Feel free to join us.

And as always, if you are working on a feature / bug that you want
tracked, please respond to this e-mail.

= Timeline =

As discussed elsewhere, I am proposing a 6-month release cycle.  Xen
4.3 was released on 9 July.  That would give us a release on 9 January
2014.  This is fairly close after the Christmas season, so I propose
to make the estimated release date later, on 21 January, giving a few
extra weeks for the holiday season:

* Feature freeze: 18 October 2013
* Code freezing point: 8 November 2013
* First RC: 26 November 2013
* Release: 21 January 2014

Feedback on the estimated dates  is welcome.

Last updated: 8 August 2013

== Completed ==

[none]

== Open ==

* xend still in tree

* qemu-upstream not freeing pirq
 > http://www.gossamer-threads.com/lists/xen/devel/281498
 status: patches posted

* __update_vcpu_system_time if system_time comes out negative

* xl pci-detach broken for pv guests?
  > http://bugs.xenproject.org/xen/bug/12
  > kernel doesn't know about moving into states 7 and 8
  status: External

* 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: Probably a bug in Linux xen drivers

== Backlog ==

=== Testing coverage ===

* Network driver domains
 @George

* new libxl w/ previous versions of xl
 @IanJ

* Host S3 suspend
 @bguthro

* 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

* 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

=== Big ticket items ===

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

* Event channel scalability
  owner: david@citrix
  status: RFC v5 submitted
  Increase limit on event channels (currently 1024 for 32-bit guests,
  4096 for 64-bit guests)

* PVH mode (w/ Linux)
  owner: mukesh@oracle
  status (Linux): 3rd draft patches posted.
  status (Xen): v10 posted

* ARM stuff: ??

* Meta: PVIO NUMA improvements
 - NUMA affinity for vcpus
    owner: Dario
 - PV guest NUMA interface
    owner: Elena
 - Sensible dom0 NUMA layout
 - Toolstack pinning backend thread / virq to appropraite d0 vcpu

* qemu-upstream stubdom, Linux
   owner: anthony@citrix
   status: in progress
   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
  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: Just begun
 prognosis: Fair

* libvirt/libxl integration (external)
 > need a status update
 - owner: jfehlig@suse, dario@citrix

* Default to credit2
 - cpu pinning
 - NUMA affinity
 - cpu "reservation"

* xenperf
  Owner: Boris Otovsky

* blktap3
  owner: thanos@citrix
  status: on hold pending XenServer decision

* Nested virtualization on Intel

* Nested virtualization on AMD

* Make storage migration possible
  owner: ?
  status: none
  There needs to be a way, either via command-line or via some hooks,
  that someone can build a "storage migration" feature on top of libxl
  or xl.

* Full-VM snapshotting
  owner: ?
  status: none
  Have a way of coordinating the taking and restoring of VM memory and
  disk snapshots.  This would involve some investigation into the best
  way to accomplish this.

* VM Cloning
  owner: ?
  status: none
  Again, a way of coordinating the memory and disk aspects.  Research
  into the best way to do this would probably go along with the
  snapshotting feature.

* xl vm-{export,import}
  owner: ?
  status: none
  Allow xl to import and export VMs to other formats; particularly
  ovf, perhaps the XenServer format, or more.

* Memory: Replace PoD with paging mechanism
  owner: george@citrix
  status: none

* PV audio (audio for stubdom qemu)
  owner: stefano.panella@citrix
  status: ?

* Wait queues for mm
 > Needed for more advanced paging schemes
  owner: ?
  status: Draft posted Feb 2012; more work to do.

* V4V: Inter-domain communication
  owner (Xen): dominic.curran@citrix.com
  status (Xen): patches submitted
  owner (Linux driver):  stefano.panella@citrix
  status (Linux driver): in progress

=== clean-ups ===

* 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

* Make network driver domains easier to set up / more useful
 - Default backend (submitted)
 - Remove unnecessary restriction wrt dom0 hotplug scripts (submitted)
 - 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

* 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

* 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
  status: Probably not for 4.3

* 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
  status: Probably not for 4.3

* mac address changes on reboot if not specified in config file
  > Needs a robust way to "add" to the config
  status: Too much for 4.3

* qxl
  > http://bugs.xenproject.org/xen/bug/11http://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

* 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

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

* 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.
 status: Not for 4.3

* Remove hardcoded mobprobe's in xencommons
  owner: Wei Liu
  status: still in discussion

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

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

* Scripts for driver domains (depends on backend scripts)
  owner: roger@citrix
  status:

* Multi-vector PCI MSI (support at least for Dom0)
  owner: jan@suse
  status: Patches posted for Intel; AMD not yet done

* 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.

* Guest EFI booting
 - status: tianocore in-tree, some build problems.
   Needs new owner.

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

* Serial console improvements
  owner: ?
  status: Stalled (see below)
  -xHCI debug port (Needs hardware)
  -Firewire (needs hardware)

Re: Xen 4.4 development update

[George Dunlap]

On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> * blktap3
>   owner: thanos@citrix
>   status: on hold pending XenServer decision

Sorry, missed this one -- this is more or less cancelled.

Re: Xen 4.4 development update

[George Dunlap]

> * qxl
>   > http://bugs.xenproject.org/xen/bug/11http://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

qxl has been re-enabled, but we still haven't had anyone step up to
implement >8-byte IO instructions.  Any takers?

 -George

Re: Xen 4.4 development update

[Andrew Cooper]

On 08/08/13 17:14, George Dunlap wrote:
>> * qxl
>>   > http://bugs.xenproject.org/xen/bug/11http://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
> qxl has been re-enabled, but we still haven't had anyone step up to
> implement >8-byte IO instructions.  Any takers?
>
>  -George

Not that I have time to look at this, but can this requirement include
support for 32 byte IO instructions, to allow for AVX emulation as well
as just SSE.

~Andrew

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

Re: Xen 4.4 development update

[Ian Campbell]

On Thu, 2013-08-08 at 17:14 +0100, George Dunlap wrote:
> > * qxl
> >   > http://bugs.xenproject.org/xen/bug/11http://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
> 
> qxl has been re-enabled,

Has it? I can't see a patch with qxl in the title after "libxl: Remove
qxl support for the 4.3 release".

> but we still haven't had anyone step up to implement >8-byte IO
> instructions.  Any takers?

Assuming I'm right and it hasn't been enabled is there any reason this
shouldn't be a prerequisite for enabling qxl?

Ian.

Re: Xen 4.4 development update

[Konrad Rzeszutek Wilk]

On Thu, Aug 08, 2013 at 05:09:35PM +0100, 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
> 
> Rather than try to predict precisely what will make it into what
> release (which was something of a disaster last release), I'm just
> going to borrow a term from the Agile world and call all uncompleted
> features the "Backlog".  I'll still track who is doing what, and when
> we get close, what state things seem to be in.
> 
> As mentioned in another e-mail, we'll also be working on improving the
> regression tester.  Feel free to join us.
> 
> And as always, if you are working on a feature / bug that you want
> tracked, please respond to this e-mail.
> 
> = Timeline =
> 
> As discussed elsewhere, I am proposing a 6-month release cycle.  Xen
> 4.3 was released on 9 July.  That would give us a release on 9 January
> 2014.  This is fairly close after the Christmas season, so I propose
> to make the estimated release date later, on 21 January, giving a few
> extra weeks for the holiday season:
> 
> * Feature freeze: 18 October 2013
> * Code freezing point: 8 November 2013
> * First RC: 26 November 2013
> * Release: 21 January 2014
> 
> Feedback on the estimated dates  is welcome.
> 
> Last updated: 8 August 2013
> 
> == Completed ==
> 
> [none]
> 
> == Open ==
> 
> * xend still in tree
> 
> * qemu-upstream not freeing pirq
>  > http://www.gossamer-threads.com/lists/xen/devel/281498
>  status: patches posted

They did fix the problem Oracle saw and I believe have been
Tested-and-Acked.

> 
> * __update_vcpu_system_time if system_time comes out negative
> 
> * xl pci-detach broken for pv guests?
>   > http://bugs.xenproject.org/xen/bug/12
>   > kernel doesn't know about moving into states 7 and 8
>   status: External

Didn't I post a patch for this on Linux - and it is in Linux kernel
already.
> 
> * 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: Probably a bug in Linux xen drivers
> 
> == Backlog ==
> 
> === Testing coverage ===
> 
> * Network driver domains
>  @George
> 
> * new libxl w/ previous versions of xl
>  @IanJ
> 
> * Host S3 suspend
>  @bguthro
> 
> * 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
> 
> * 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
> 
> === Big ticket items ===
> 
> * NUMA Memory migration
>   owner: dario@citrix
>   status: in progress
> 
> * Event channel scalability
>   owner: david@citrix
>   status: RFC v5 submitted
>   Increase limit on event channels (currently 1024 for 32-bit guests,
>   4096 for 64-bit guests)

aka FIFO thing right?

> 
> * PVH mode (w/ Linux)
>   owner: mukesh@oracle
>   status (Linux): 3rd draft patches posted.

More like v8. And already Acked - just waiting for ABI to be in some way
"nailed down".

>   status (Xen): v10 posted
> 
> * ARM stuff: ??
> 
> * Meta: PVIO NUMA improvements
>  - NUMA affinity for vcpus
>     owner: Dario
>  - PV guest NUMA interface
>     owner: Elena
>  - Sensible dom0 NUMA layout
>  - Toolstack pinning backend thread / virq to appropraite d0 vcpu
> 
> * qemu-upstream stubdom, Linux
>    owner: anthony@citrix
>    status: in progress
>    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
>   owner: ianj@citrix
> 
> * Network performance improvements
>   owner: wei@citrix
> 
> * Disk performance improvements

I think you mean blkback and blkfront?
> 
> * Xen EFI feature: Xen can boot from grub.efi
>  owner: Daniel Kiper
>  status: Just begun
>  prognosis: Fair
> 
> * libvirt/libxl integration (external)
>  > need a status update
>  - owner: jfehlig@suse, dario@citrix
> 
> * Default to credit2
>  - cpu pinning
>  - NUMA affinity
>  - cpu "reservation"
> 
> * xenperf
>   Owner: Boris Otovsky
> 
> * blktap3
>   owner: thanos@citrix
>   status: on hold pending XenServer decision
> 
> * Nested virtualization on Intel
> 
> * Nested virtualization on AMD
> 
> * Make storage migration possible
>   owner: ?
>   status: none
>   There needs to be a way, either via command-line or via some hooks,
>   that someone can build a "storage migration" feature on top of libxl
>   or xl.
> 
> * Full-VM snapshotting
>   owner: ?
>   status: none
>   Have a way of coordinating the taking and restoring of VM memory and
>   disk snapshots.  This would involve some investigation into the best
>   way to accomplish this.
> 
> * VM Cloning
>   owner: ?
>   status: none
>   Again, a way of coordinating the memory and disk aspects.  Research
>   into the best way to do this would probably go along with the
>   snapshotting feature.
> 
> * xl vm-{export,import}
>   owner: ?
>   status: none
>   Allow xl to import and export VMs to other formats; particularly
>   ovf, perhaps the XenServer format, or more.
> 
> * Memory: Replace PoD with paging mechanism
>   owner: george@citrix
>   status: none
> 
> * PV audio (audio for stubdom qemu)
>   owner: stefano.panella@citrix
>   status: ?
> 
> * Wait queues for mm
>  > Needed for more advanced paging schemes
>   owner: ?
>   status: Draft posted Feb 2012; more work to do.
> 
> * V4V: Inter-domain communication
>   owner (Xen): dominic.curran@citrix.com
>   status (Xen): patches submitted
>   owner (Linux driver):  stefano.panella@citrix
>   status (Linux driver): in progress
> 
> === clean-ups ===
> 
> * 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
> 
> * Make network driver domains easier to set up / more useful
>  - Default backend (submitted)
>  - Remove unnecessary restriction wrt dom0 hotplug scripts (submitted)
>  - 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
> 
> * 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
> 
> * 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
>   status: Probably not for 4.3
> 
> * 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
>   status: Probably not for 4.3
> 
> * mac address changes on reboot if not specified in config file
>   > Needs a robust way to "add" to the config
>   status: Too much for 4.3
> 
> * qxl
>   > http://bugs.xenproject.org/xen/bug/11http://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
> 
> * 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
> 
> * Polish up xenbugtool
>   owner: wei.liu2@citrix.com
> 
> * 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.
>  status: Not for 4.3
> 
> * Remove hardcoded mobprobe's in xencommons
>   owner: Wei Liu
>   status: still in discussion
> 
> * xl USB pass-through for HVM guests using Qemu USB emulation
>   owner: George
>   status: v6 patch series posted
> 
> * Rationalized backend scripts
>   owner: roger@citrix
>   status: patches posted
> 
> * Scripts for driver domains (depends on backend scripts)
>   owner: roger@citrix
>   status:
> 
> * Multi-vector PCI MSI (support at least for Dom0)
>   owner: jan@suse
>   status: Patches posted for Intel; AMD not yet done

And patches for Linux upstream are missing.

> 
> * 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.

Which is to say I hadn't actually touched them in a year.

>   - James Harper's GPLPV drivers for Windows include PVUSB frontend drivers.
> 
> * Guest EFI booting
>  - status: tianocore in-tree, some build problems.
>    Needs new owner.
> 
> * Xen EFI feature: pvops dom0 able to make use of EFI run-time
> services (external)
>  owner: Daniel Kiper
>  status: Just begun
> 
> * Serial console improvements
>   owner: ?
>   status: Stalled (see below)
>   -xHCI debug port (Needs hardware)
>   -Firewire (needs hardware)
> 

I would like also to put GPU passthrough working here.

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

Re: Xen 4.4 development update

[Jan Beulich]

>>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> == Open ==
> 
> * __update_vcpu_system_time if system_time comes out negative

Done since Jul 2 (5ad914bc867c5a6a4957869c89918f4e1f9dd9c4).

Jan

Re: Xen 4.4 development update

[Jan Beulich]

>>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> === Big ticket items ===
> 
> * Event channel scalability
>   owner: david@citrix
>   status: RFC v5 submitted

That was Wei's variant I believe; I don't think David's has reached
v5 yet.

> * Default to credit2

Was that really the plan?

* Multi-vector MSI
  (deferred from 4.3, now done)

Jan

Re: Xen 4.4 development update

[Jan Beulich]

>>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> === clean-ups ===
> 
> * Implement Xen hypervisor dmesg log entry timestamps

Isn't that what the "console_timestamps" command line option
already does? Or if not, what is this about?

> * Multi-vector PCI MSI (support at least for Dom0)
>   owner: jan@suse
>   status: Patches posted for Intel; AMD not yet done

Oh, this was listed under cleanups. Anyway - it's done (also for
AMD).

Jan

Re: Xen 4.4 development update

[Jan Beulich]

>>> On 08.08.13 at 18:17, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
> On 08/08/13 17:14, George Dunlap wrote:
>>> * qxl
>>>   > 
> http://bugs.xenproject.org/xen/bug/11http://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
>> qxl has been re-enabled, but we still haven't had anyone step up to
>> implement >8-byte IO instructions.  Any takers?
>>
>>  -George
> 
> Not that I have time to look at this, but can this requirement include
> support for 32 byte IO instructions, to allow for AVX emulation as well
> as just SSE.

If anything, we should make this arbitrary size anyway. AVX-512 is
already at the horizon.

Jan

Re: Xen 4.4 development update

[Jan Beulich]

>>> On 08.08.13 at 18:11, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap
> <George.Dunlap@eu.citrix.com> wrote:
>> * blktap3
>>   owner: thanos@citrix
>>   status: on hold pending XenServer decision
> 
> Sorry, missed this one -- this is more or less cancelled.

So is there any supposed replacement then?

Jan

Re: Xen 4.4 development update

[Dario Faggioli]

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

On ven, 2013-08-09 at 09:02 +0100, Jan Beulich wrote:
> > * Default to credit2
> 
> Was that really the plan?
> 
We want to do that at some point, yes, although, most likely, not for
4.4, right George?

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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 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.4 development update

[Dario Faggioli]

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

On ven, 2013-08-09 at 09:11 +0100, Jan Beulich wrote:
> >>> On 08.08.13 at 18:11, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> > On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap
> > <George.Dunlap@eu.citrix.com> wrote:
> >> * blktap3
> >>   owner: thanos@citrix
> >>   status: on hold pending XenServer decision
> > 
> > Sorry, missed this one -- this is more or less cancelled.
> 
> So is there any supposed replacement then?
> 
AFAIUI, that is using (and improving) qdisk for all the (previous)
blktap use cases:

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

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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 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.4 development update

[Dario Faggioli]

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

On gio, 2013-08-08 at 17:09 +0100, George Dunlap wrote:
> = Timeline =
> 
> As discussed elsewhere, I am proposing a 6-month release cycle.  Xen
> 4.3 was released on 9 July.  That would give us a release on 9 January
> 2014.  This is fairly close after the Christmas season, so I propose
> to make the estimated release date later, on 21 January, giving a few
> extra weeks for the holiday season:
> 
> * Feature freeze: 18 October 2013
> * Code freezing point: 8 November 2013
> * First RC: 26 November 2013
> * Release: 21 January 2014
> 
18 October... Tight. At least code freeze is a bit later! :-P

> Last updated: 8 August 2013
>
> == Backlog ==
> 
> === Testing coverage ===
> 
> [..]
>
 * Performance benchmarking on top of osstest
  @dario

> === Big ticket items ===
> 
> * NUMA Memory migration
>   owner: dario@citrix
>   status: in progress
> 
Confirmed to be in progress.

> * Meta: PVIO NUMA improvements
>  - NUMA affinity for vcpus
>     owner: Dario
>
status: in progress

>  - PV guest NUMA interface
>     owner: Elena
>
status: in progress

Right Elena?

>  - Sensible dom0 NUMA layout
>
status: not started

>  - Toolstack pinning backend thread / virq to appropraite d0 vcpu
>
status: not started

Also, we might want to add:

  - HVM guest NUMA
     owner: Matt Wilson
     status: ?

Is that ok, Matt?

If you're concerned about the libxl part of that, I have a series half
backed that I'll be posting here soon (as RFC or something), so feel
free to leave that to me. :-)

And this one too:

  - NUMA-aware ballooning
     owner: Li Yechen
     status: ?

Is that ok, Yechen?

> * libvirt/libxl integration (external)
>  > need a status update
>  - owner: jfehlig@suse, dario@citrix
>
Yep, putting together a status update right in these days (I plan a
XenSummit talk about it)

> === clean-ups ===
> 
> * Sort out better memory / ballooning / dom0 autoballooning thing
>  > Don't forget NUMA angle
>
Mmm... This is an old discussion which, if I remember correctly (at
least what the "NUMA angle" was), is about a TOCTOU issue involving
automatic NUMA placement and ballooning, domain creation, and perhaps
even more memory related operations (depends on the toolstack)... It's
not "just" a ballooning or autoballooning  problem, and it's completely
different from the "NUMA-aware ballooning" I was talking about before.

I don't have much in mind to properly deal with it. One think I can
double check is whether the claim mechanism Oracle introduced can be of
any help, but nothing much than that for now.

In any case, at least from my side, this is as follows.

status: not started.

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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 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.4 development update

[Daniel Kiper]

On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote:

[...]

> * Xen EFI feature: Xen can boot from grub.efi
>  owner: Daniel Kiper
>  status: Just begun
>  prognosis: Fair

I think that you could change that to Good. I am working
on it. Migration to xbi struct is almost finished and
multiboot2 protocol works on machines with legacy BIOS.
Now I am working on multiboot2 protocol for machines
with EFI. Yesterday, I discovered some issues related
to memory map passed via this protocol. Sadly it looks
that taking into account current GRUB2 implementation
only workaround is available. Final proper solution would
require some changes in GRUB2. I will do that later.

[...]

> * Guest EFI booting
>  - status: tianocore in-tree, some build problems.
>    Needs new owner.

I could take over ownership of this but it would have
lowest priority on my task list now (major stuff only:
1 - multiboot2 protocl, 2 - EFI support for Xen in Linux
Kernel, 3 - guest EFI booting).

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

I am going to start work on it when I finish work on multiboot2 protocol.

Additionally, I think that:
  - new kexec implementation should be added to this list;
    David Vrabel work on this; I think that patches are
    quite mature and need only some polishing,
  - unmodified_drivers should be removed because as I know
    they are not maintained for very long time; if you
    agree I could do that,
  - as I saw there is a quite big mess in directory structure
    used by installed Xen related stuff (especially in /var
    and /usr); I have done some patches for myself but they
    require some improvements to do public release; if you wish
    I could work on this too.

Have a nice weekend,

Daniel

Re: Xen 4.4 development update

[Boris Ostrovsky]

On 08/08/2013 12:09 PM, George Dunlap wrote:
> * xenperf
>    Owner: Boris Otovsky


The first cut is almost done, I only need to get 32-bit PV working. I 
expect to
post v1 patches after I get back from vacation (early September)

-boris

Re: Xen 4.4 development update

[Matt Wilson]

On Fri, Aug 09, 2013 at 04:10:10PM +0200, Dario Faggioli wrote:
> On gio, 2013-08-08 at 17:09 +0100, George Dunlap wrote:
> > = Timeline =
> > 
> > As discussed elsewhere, I am proposing a 6-month release cycle.  Xen
> > 4.3 was released on 9 July.  That would give us a release on 9 January
> > 2014.  This is fairly close after the Christmas season, so I propose
> > to make the estimated release date later, on 21 January, giving a few
> > extra weeks for the holiday season:
> > 
> > * Feature freeze: 18 October 2013
> > * Code freezing point: 8 November 2013
> > * First RC: 26 November 2013
> > * Release: 21 January 2014
> > 

[...]

> > === Big ticket items ===

[...]

> Also, we might want to add:
> 
>   - HVM guest NUMA
>      owner: Matt Wilson
>      status: ?
> 
> Is that ok, Matt?

Yes.

> If you're concerned about the libxl part of that, I have a series half
> backed that I'll be posting here soon (as RFC or something), so feel
> free to leave that to me. :-)

OK! I'll try to find some time to rebase the patch and post as an RFC.

--msw

Re: Xen 4.4 development update

[Dario Faggioli]

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

On ven, 2013-08-09 at 16:08 -0700, Matt Wilson wrote:
> > Also, we might want to add:
> > 
> >   - HVM guest NUMA
> >      owner: Matt Wilson
> >      status: ?
> > 
> > Is that ok, Matt?
> 
> Yes.
> 
> > If you're concerned about the libxl part of that, I have a series half
> > backed that I'll be posting here soon (as RFC or something), so feel
> > free to leave that to me. :-)
> 
> OK! I'll try to find some time to rebase the patch and post as an RFC.
> 
Great! Whenever you're ready. :-)

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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 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.4 development update

[Jan Beulich]

>>> On 09.08.13 at 22:01, Daniel Kiper <dkiper@net-space.pl> wrote:
>   - unmodified_drivers should be removed because as I know
>     they are not maintained for very long time; if you
>     agree I could do that,

The most recent update to them was on 2013-02-12, so not all
_that_ long ago. We're still using them, so I'd hope that they
could stay in the tree, saving us from having to patch them back
in.

Jan

Re: Xen 4.4 development update

[David Vrabel]

On 09/08/13 21:01, Daniel Kiper wrote:
> 
> Additionally, I think that:
>   - new kexec implementation should be added to this list;
>     David Vrabel work on this; I think that patches are
>     quite mature and need only some polishing,

The way it writes the page tables used to exec the image needs changing
-- this is non trivial.

David

Re: Xen 4.4 development update

[David Vrabel]

On 08/08/13 17:09, 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

There's nothing on this page.

> * Event channel scalability
>   owner: david@citrix
>   status: RFC v5 submitted
>   Increase limit on event channels (currently 1024 for 32-bit guests,
>   4096 for 64-bit guests)

RFC v2 of the FIFO ABI has been posted.

David

Re: Xen 4.4 development update

[Daniel Kiper]

On Mon, Aug 12, 2013 at 09:06:08AM +0100, Jan Beulich wrote:
> >>> On 09.08.13 at 22:01, Daniel Kiper <dkiper@net-space.pl> wrote:
> >   - unmodified_drivers should be removed because as I know
> >     they are not maintained for very long time; if you
> >     agree I could do that,
>
> The most recent update to them was on 2013-02-12, so not all
> _that_ long ago. We're still using them, so I'd hope that they
> could stay in the tree, saving us from having to patch them back
> in.

As I understood from [1] unmodified_drivers is not maintained.
However, if you found out that it was updated quite recently then
I do not insist on removing it.

1) http://lists.xen.org/archives/html/xen-devel/2013-06/msg00730.html

Daniel

Re: Xen 4.4 development update

[Daniel Kiper]

On Mon, Aug 12, 2013 at 10:44:35AM +0100, David Vrabel wrote:
> On 09/08/13 21:01, Daniel Kiper wrote:
> >
> > Additionally, I think that:
> >   - new kexec implementation should be added to this list;
> >     David Vrabel work on this; I think that patches are
> >     quite mature and need only some polishing,
>
> The way it writes the page tables used to exec the image needs changing
> -- this is non trivial.

Ugh... Could you tell more?

Daniel

Re: Xen 4.4 development update

[Mukesh Rathor]

On Thu, 8 Aug 2013 17:09:35 +0100
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
> 
> Rather than try to predict precisely what will make it into what
> release (which was something of a disaster last release), I'm just
> going to borrow a term from the Agile world and call all uncompleted
> features the "Backlog".  I'll still track who is doing what, and when
> we get close, what state things seem to be in.
> 
> As mentioned in another e-mail, we'll also be working on improving the
> regression tester.  Feel free to join us.
> 
> And as always, if you are working on a feature / bug that you want
> tracked, please respond to this e-mail.
> 
> = Timeline =
> 
> As discussed elsewhere, I am proposing a 6-month release cycle.  Xen
> 4.3 was released on 9 July.  That would give us a release on 9 January
> 2014.  This is fairly close after the Christmas season, so I propose
> to make the estimated release date later, on 21 January, giving a few
> extra weeks for the holiday season:
> 
> * Feature freeze: 18 October 2013
> * Code freezing point: 8 November 2013
> * First RC: 26 November 2013
> * Release: 21 January 2014
> 
> Feedback on the estimated dates  is welcome.
.....
> === Big ticket items ===
......

> * PVH mode (w/ Linux)
>   owner: mukesh@oracle
>   status (Linux): 3rd draft patches posted.
>   status (Xen): v10 posted

With holidays, vacation, other things on my plate i need to work on
soon, the hurdles faced by V10, and still remaing tools and dom0 patch,
this seems a difficult proposition for 4.4.

thanks
Mukesh

Re: Xen 4.4 development update

[Jan Beulich]

>>> On 12.08.13 at 20:55, Daniel Kiper <dkiper@net-space.pl> wrote:
> On Mon, Aug 12, 2013 at 09:06:08AM +0100, Jan Beulich wrote:
>> >>> On 09.08.13 at 22:01, Daniel Kiper <dkiper@net-space.pl> wrote:
>> >   - unmodified_drivers should be removed because as I know
>> >     they are not maintained for very long time; if you
>> >     agree I could do that,
>>
>> The most recent update to them was on 2013-02-12, so not all
>> _that_ long ago. We're still using them, so I'd hope that they
>> could stay in the tree, saving us from having to patch them back
>> in.
> 
> As I understood from [1] unmodified_drivers is not maintained.
> However, if you found out that it was updated quite recently then
> I do not insist on removing it.
> 
> 1) http://lists.xen.org/archives/html/xen-devel/2013-06/msg00730.html 

What I said there has nothing to do with the maintenance status
of the unmodified_drivers/ subtree; instead, it is related to the
need to also have a suitable forward ported Linux tree to build
them against.

Jan

Re: Xen 4.4 development update

[Daniel Kiper]

On Tue, Aug 13, 2013 at 11:13:42AM +0100, Jan Beulich wrote:
> >>> On 12.08.13 at 20:55, Daniel Kiper <dkiper@net-space.pl> wrote:
> > On Mon, Aug 12, 2013 at 09:06:08AM +0100, Jan Beulich wrote:
> >> >>> On 09.08.13 at 22:01, Daniel Kiper <dkiper@net-space.pl> wrote:
> >> >   - unmodified_drivers should be removed because as I know
> >> >     they are not maintained for very long time; if you
> >> >     agree I could do that,
> >>
> >> The most recent update to them was on 2013-02-12, so not all
> >> _that_ long ago. We're still using them, so I'd hope that they
> >> could stay in the tree, saving us from having to patch them back
> >> in.
> >
> > As I understood from [1] unmodified_drivers is not maintained.
> > However, if you found out that it was updated quite recently then
> > I do not insist on removing it.
> >
> > 1) http://lists.xen.org/archives/html/xen-devel/2013-06/msg00730.html
>
> What I said there has nothing to do with the maintenance status
> of the unmodified_drivers/ subtree; instead, it is related to the
> need to also have a suitable forward ported Linux tree to build
> them against.

It looks that I understood your email in wrong way.
Thanks for clarification.

Daniel

Re: Xen 4.4 development update

[Ben Guthro]

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

On Thu, Aug 8, 2013 at 12:09 PM, George Dunlap
<George.Dunlap@eu.citrix.com>wrote:

*snip*

=== Testing coverage ===
>

*snip*


> * Host S3 suspend
>  @bguthro
>
>
I'm unclear on what "Testing coverage" means, in this context.
Are you asking for development of a new automated test, or to manually test
the release?

If you mean the former, I tried to get the infrastructure up and running to
run osstest before, and failed.
I think I will need some help with this, from someone more familiar with
the testing system, if this is what you mean.

Thanks
Ben

[-- Attachment #1.2: Type: text/html, Size: 1125 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.4 development update

[Dario Faggioli]

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

On mar, 2013-08-13 at 09:17 -0400, Ben Guthro wrote:

> *snip* 
>  
>         * Host S3 suspend
>          @bguthro
>         
> 
> 
> I'm unclear on what "Testing coverage" means, in this context.
> Are you asking for development of a new automated test, or to manually
> test the release?
> 
The former. :-)

> If you mean the former, I tried to get the infrastructure up and
> running to run osstest before, and failed.
>
There are some stuff you have to take care of, yes. I recall succeeding
in bringing it up a while back, but I don't have the details fresh in my
mind.

> I think I will need some help with this, from someone more familiar
> with the testing system, if this is what you mean.
> 
Well, I will have to bring up the osstest machinery again, and I'll
start from scratch, so we can 'try together', meaning that I'll try
(since I did it already) and let you know if I manage, so that you can
try on your turn to ask questions about what's going wrong on your side.

Just know that it will be September when I'll be doing that, since I'm
about to leave for a couple of weeks. If that is not a big deal for you,
we can talk more about it when I will be back.

Let me know,
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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 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.4 development update

[George Dunlap]

On 08/08/13 17:24, Ian Campbell wrote:
> On Thu, 2013-08-08 at 17:14 +0100, George Dunlap wrote:
>>> * qxl
>>>    > http://bugs.xenproject.org/xen/bug/11http://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
>> qxl has been re-enabled,
> Has it? I can't see a patch with qxl in the title after "libxl: Remove
> qxl support for the 4.3 release".

Oh, right -- I thought I'd seen it go in; but I guess not.

>
>> but we still haven't had anyone step up to implement >8-byte IO
>> instructions.  Any takers?
> Assuming I'm right and it hasn't been enabled is there any reason this
> shouldn't be a prerequisite for enabling qxl?

I wouldn't think so -- I view the extended instruction support as a 
bug.  In any case, having the qxl functionality will make an easy way 
for developers to test the vector instruction functionality.

  -George

Re: Xen 4.4 development update

[Ben Guthro]

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

On Tue, Aug 13, 2013 at 11:43 AM, Dario Faggioli
<dario.faggioli@citrix.com>wrote:

> On mar, 2013-08-13 at 09:17 -0400, Ben Guthro wrote:
>
> > *snip*
> >
> >         * Host S3 suspend
> >          @bguthro
> >
> >
> >
> > I'm unclear on what "Testing coverage" means, in this context.
> > Are you asking for development of a new automated test, or to manually
> > test the release?
> >
> The former. :-)
>
> > If you mean the former, I tried to get the infrastructure up and
> > running to run osstest before, and failed.
> >
> There are some stuff you have to take care of, yes. I recall succeeding
> in bringing it up a while back, but I don't have the details fresh in my
> mind.
>
> > I think I will need some help with this, from someone more familiar
> > with the testing system, if this is what you mean.
> >
> Well, I will have to bring up the osstest machinery again, and I'll
> start from scratch, so we can 'try together', meaning that I'll try
> (since I did it already) and let you know if I manage, so that you can
> try on your turn to ask questions about what's going wrong on your side.
>
> Just know that it will be September when I'll be doing that, since I'm
> about to leave for a couple of weeks. If that is not a big deal for you,
> we can talk more about it when I will be back.
>
> Let me know,
>

Sounds like a plan - I've got plenty to do between now, and then anyhow.

Thanks

Ben



> 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)
>
>

[-- Attachment #1.2: Type: text/html, Size: 2586 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.4 development update

[George Dunlap]

On 08/08/13 20:30, Konrad Rzeszutek Wilk wrote:
> On Thu, Aug 08, 2013 at 05:09:35PM +0100, 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
>>
>> Rather than try to predict precisely what will make it into what
>> release (which was something of a disaster last release), I'm just
>> going to borrow a term from the Agile world and call all uncompleted
>> features the "Backlog".  I'll still track who is doing what, and when
>> we get close, what state things seem to be in.
>>
>> As mentioned in another e-mail, we'll also be working on improving the
>> regression tester.  Feel free to join us.
>>
>> And as always, if you are working on a feature / bug that you want
>> tracked, please respond to this e-mail.
>>
>> = Timeline =
>>
>> As discussed elsewhere, I am proposing a 6-month release cycle.  Xen
>> 4.3 was released on 9 July.  That would give us a release on 9 January
>> 2014.  This is fairly close after the Christmas season, so I propose
>> to make the estimated release date later, on 21 January, giving a few
>> extra weeks for the holiday season:
>>
>> * Feature freeze: 18 October 2013
>> * Code freezing point: 8 November 2013
>> * First RC: 26 November 2013
>> * Release: 21 January 2014
>>
>> Feedback on the estimated dates  is welcome.
>>
>> Last updated: 8 August 2013
>>
>> == Completed ==
>>
>> [none]
>>
>> == Open ==
>>
>> * xend still in tree
>>
>> * qemu-upstream not freeing pirq
>>   > http://www.gossamer-threads.com/lists/xen/devel/281498
>>   status: patches posted
> They did fix the problem Oracle saw and I believe have been
> Tested-and-Acked.

Thanks -- have they also been applied?

>
>> * __update_vcpu_system_time if system_time comes out negative
>>
>> * xl pci-detach broken for pv guests?
>>    > http://bugs.xenproject.org/xen/bug/12
>>    > kernel doesn't know about moving into states 7 and 8
>>    status: External
> Didn't I post a patch for this on Linux - and it is in Linux kernel
> already.

Great -- thanks for the update.

>> * 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: Probably a bug in Linux xen drivers
>>
>> == Backlog ==
>>
>> === Testing coverage ===
>>
>> * Network driver domains
>>   @George
>>
>> * new libxl w/ previous versions of xl
>>   @IanJ
>>
>> * Host S3 suspend
>>   @bguthro
>>
>> * 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
>>
>> * 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
>>
>> === Big ticket items ===
>>
>> * NUMA Memory migration
>>    owner: dario@citrix
>>    status: in progress
>>
>> * Event channel scalability
>>    owner: david@citrix
>>    status: RFC v5 submitted
>>    Increase limit on event channels (currently 1024 for 32-bit guests,
>>    4096 for 64-bit guests)
> aka FIFO thing right?

Yep.  I'll make this a bit more clear.

>
>> * PVH mode (w/ Linux)
>>    owner: mukesh@oracle
>>    status (Linux): 3rd draft patches posted.
> More like v8. And already Acked - just waiting for ABI to be in some way
> "nailed down".
>
>>    status (Xen): v10 posted
>>
>> * ARM stuff: ??
>>
>> * Meta: PVIO NUMA improvements
>>   - NUMA affinity for vcpus
>>      owner: Dario
>>   - PV guest NUMA interface
>>      owner: Elena
>>   - Sensible dom0 NUMA layout
>>   - Toolstack pinning backend thread / virq to appropraite d0 vcpu
>>
>> * qemu-upstream stubdom, Linux
>>     owner: anthony@citrix
>>     status: in progress
>>     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
>>    owner: ianj@citrix
>>
>> * Network performance improvements
>>    owner: wei@citrix
>>
>> * Disk performance improvements
> I think you mean blkback and blkfront?
>> * Xen EFI feature: Xen can boot from grub.efi
>>   owner: Daniel Kiper
>>   status: Just begun
>>   prognosis: Fair
>>
>> * libvirt/libxl integration (external)
>>   > need a status update
>>   - owner: jfehlig@suse, dario@citrix
>>
>> * Default to credit2
>>   - cpu pinning
>>   - NUMA affinity
>>   - cpu "reservation"
>>
>> * xenperf
>>    Owner: Boris Otovsky
>>
>> * blktap3
>>    owner: thanos@citrix
>>    status: on hold pending XenServer decision
>>
>> * Nested virtualization on Intel
>>
>> * Nested virtualization on AMD
>>
>> * Make storage migration possible
>>    owner: ?
>>    status: none
>>    There needs to be a way, either via command-line or via some hooks,
>>    that someone can build a "storage migration" feature on top of libxl
>>    or xl.
>>
>> * Full-VM snapshotting
>>    owner: ?
>>    status: none
>>    Have a way of coordinating the taking and restoring of VM memory and
>>    disk snapshots.  This would involve some investigation into the best
>>    way to accomplish this.
>>
>> * VM Cloning
>>    owner: ?
>>    status: none
>>    Again, a way of coordinating the memory and disk aspects.  Research
>>    into the best way to do this would probably go along with the
>>    snapshotting feature.
>>
>> * xl vm-{export,import}
>>    owner: ?
>>    status: none
>>    Allow xl to import and export VMs to other formats; particularly
>>    ovf, perhaps the XenServer format, or more.
>>
>> * Memory: Replace PoD with paging mechanism
>>    owner: george@citrix
>>    status: none
>>
>> * PV audio (audio for stubdom qemu)
>>    owner: stefano.panella@citrix
>>    status: ?
>>
>> * Wait queues for mm
>>   > Needed for more advanced paging schemes
>>    owner: ?
>>    status: Draft posted Feb 2012; more work to do.
>>
>> * V4V: Inter-domain communication
>>    owner (Xen): dominic.curran@citrix.com
>>    status (Xen): patches submitted
>>    owner (Linux driver):  stefano.panella@citrix
>>    status (Linux driver): in progress
>>
>> === clean-ups ===
>>
>> * 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
>>
>> * Make network driver domains easier to set up / more useful
>>   - Default backend (submitted)
>>   - Remove unnecessary restriction wrt dom0 hotplug scripts (submitted)
>>   - 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
>>
>> * 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
>>
>> * 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
>>    status: Probably not for 4.3
>>
>> * 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
>>    status: Probably not for 4.3
>>
>> * mac address changes on reboot if not specified in config file
>>    > Needs a robust way to "add" to the config
>>    status: Too much for 4.3
>>
>> * qxl
>>    > http://bugs.xenproject.org/xen/bug/11http://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
>>
>> * 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
>>
>> * Polish up xenbugtool
>>    owner: wei.liu2@citrix.com
>>
>> * 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.
>>   status: Not for 4.3
>>
>> * Remove hardcoded mobprobe's in xencommons
>>    owner: Wei Liu
>>    status: still in discussion
>>
>> * xl USB pass-through for HVM guests using Qemu USB emulation
>>    owner: George
>>    status: v6 patch series posted
>>
>> * Rationalized backend scripts
>>    owner: roger@citrix
>>    status: patches posted
>>
>> * Scripts for driver domains (depends on backend scripts)
>>    owner: roger@citrix
>>    status:
>>
>> * Multi-vector PCI MSI (support at least for Dom0)
>>    owner: jan@suse
>>    status: Patches posted for Intel; AMD not yet done
> And patches for Linux upstream are missing.



>
>> * 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.
> Which is to say I hadn't actually touched them in a year.

Yeah, I was under the impression they weren't really going anywhere.  If 
you think this is unclear, feel free to suggest alternate wording.

>
>>    - James Harper's GPLPV drivers for Windows include PVUSB frontend drivers.
>>
>> * Guest EFI booting
>>   - status: tianocore in-tree, some build problems.
>>     Needs new owner.
>>
>> * Xen EFI feature: pvops dom0 able to make use of EFI run-time
>> services (external)
>>   owner: Daniel Kiper
>>   status: Just begun
>>
>> * Serial console improvements
>>    owner: ?
>>    status: Stalled (see below)
>>    -xHCI debug port (Needs hardware)
>>    -Firewire (needs hardware)
>>
> I would like also to put GPU passthrough working here.

What aspect do you mean?

  -George

Re: Xen 4.4 development update

[George Dunlap]

On 08/08/13 20:30, Konrad Rzeszutek Wilk wrote:
> On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote:
>> * Multi-vector PCI MSI (support at least for Dom0)
>>    owner: jan@suse
>>    status: Patches posted for Intel; AMD not yet done
> And patches for Linux upstream are missing.

Jan, care to comment on this?

  -George

Re: Xen 4.4 development update

[Jan Beulich]

>>> On 13.08.13 at 18:22, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> On 08/08/13 20:30, Konrad Rzeszutek Wilk wrote:
>> On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote:
>>> * Multi-vector PCI MSI (support at least for Dom0)
>>>    owner: jan@suse
>>>    status: Patches posted for Intel; AMD not yet done
>> And patches for Linux upstream are missing.
> 
> Jan, care to comment on this?

As indicated to Konrad earlier - upstream code is too different from
ours for me to propose a patch here. I handed Konrad the patch
that I have on our kernel for future reference, and am relying on
him (or someone else) to actually do that work.

Jan

Re: Xen 4.4 development update

[Dario Faggioli]

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

On mar, 2013-08-13 at 12:18 -0400, Ben Guthro wrote:
>         
>         Just know that it will be September when I'll be doing that,
>         since I'm
>         about to leave for a couple of weeks. If that is not a big
>         deal for you,
>         we can talk more about it when I will be back.
>         
>         Let me know,
> 
> 
> Sounds like a plan - I've got plenty to do between now, and then
> anyhow.
> 
Cool. I will let you know when done with it then.

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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 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.4 development update

[George Dunlap]

On 09/08/13 09:02, Jan Beulich wrote:
>>>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>> === Big ticket items ===
>>
>> * Event channel scalability
>>    owner: david@citrix
>>    status: RFC v5 submitted
> That was Wei's variant I believe; I don't think David's has reached
> v5 yet.
>
>> * Default to credit2
> Was that really the plan?

It's something I would really like to see in -- but as indicated, there 
are a couple of critical missing features, and I don't think I'll be 
able to make it for 4.4.

  -George

Re: Xen 4.4 development update

[George Dunlap]

On 09/08/13 09:06, Jan Beulich wrote:
>>>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>> === clean-ups ===
>>
>> * Implement Xen hypervisor dmesg log entry timestamps
> Isn't that what the "console_timestamps" command line option
> already does? Or if not, what is this about?

It comes from this uservoice suggestion by Pasi:

https://xenorg.uservoice.com/forums/172169-xen-development/suggestions/3924048-implement-xen-hypervisor-dmesg-log-entry-timestamp

Andy C. commented, saying that "console_timestamps" was a bit 
heavyweight, and that this (which only has seconds since boot) was more 
useful.  I'll update this to reflect that.

>> * Multi-vector PCI MSI (support at least for Dom0)
>>    owner: jan@suse
>>    status: Patches posted for Intel; AMD not yet done
> Oh, this was listed under cleanups. Anyway - it's done (also for
> AMD).

Yes, sorry -- the list is getting awfully long, and I was under some 
pressure to get the list out, particularly as it had been over a month 
since the 4.3 release.  I've re-organized stuff now and will post it to 
the wiki in the better-organized format.

  -George

Re: Xen 4.4 development update

[George Dunlap]

On 09/08/13 15:10, Dario Faggioli wrote:
> On gio, 2013-08-08 at 17:09 +0100, George Dunlap wrote:
>> = Timeline =
>>
>> As discussed elsewhere, I am proposing a 6-month release cycle.  Xen
>> 4.3 was released on 9 July.  That would give us a release on 9 January
>> 2014.  This is fairly close after the Christmas season, so I propose
>> to make the estimated release date later, on 21 January, giving a few
>> extra weeks for the holiday season:
>>
>> * Feature freeze: 18 October 2013
>> * Code freezing point: 8 November 2013
>> * First RC: 26 November 2013
>> * Release: 21 January 2014
>>
> 18 October... Tight. At least code freeze is a bit later! :-P
>
>> Last updated: 8 August 2013
>>
>> == Backlog ==
>>
>> === Testing coverage ===
>>
>> [..]
>>
>   * Performance benchmarking on top of osstest
>    @dario



>
>> === Big ticket items ===
>>
>> * NUMA Memory migration
>>    owner: dario@citrix
>>    status: in progress
>>
> Confirmed to be in progress.
>
>> * Meta: PVIO NUMA improvements
>>   - NUMA affinity for vcpus
>>      owner: Dario
>>
> status: in progress
>
>>   - PV guest NUMA interface
>>      owner: Elena
>>
> status: in progress
>
> Right Elena?
>
>>   - Sensible dom0 NUMA layout
>>
> status: not started
>
>>   - Toolstack pinning backend thread / virq to appropraite d0 vcpu
>>
> status: not started
>
> Also, we might want to add:
>
>    - HVM guest NUMA
>       owner: Matt Wilson
>       status: ?
>
> Is that ok, Matt?
>
> If you're concerned about the libxl part of that, I have a series half
> backed that I'll be posting here soon (as RFC or something), so feel
> free to leave that to me. :-)
>
> And this one too:
>
>    - NUMA-aware ballooning
>       owner: Li Yechen
>       status: ?
>
> Is that ok, Yechen?
>
>> * libvirt/libxl integration (external)
>>   > need a status update
>>   - owner: jfehlig@suse, dario@citrix
>>
> Yep, putting together a status update right in these days (I plan a
> XenSummit talk about it)
>
>> === clean-ups ===
>>
>> * Sort out better memory / ballooning / dom0 autoballooning thing
>>   > Don't forget NUMA angle
>>
> Mmm... This is an old discussion which, if I remember correctly (at
> least what the "NUMA angle" was), is about a TOCTOU issue involving
> automatic NUMA placement and ballooning, domain creation, and perhaps
> even more memory related operations (depends on the toolstack)... It's
> not "just" a ballooning or autoballooning  problem, and it's completely
> different from the "NUMA-aware ballooning" I was talking about before.
>
> I don't have much in mind to properly deal with it. One think I can
> double check is whether the claim mechanism Oracle introduced can be of
> any help, but nothing much than that for now.
>
> In any case, at least from my side, this is as follows.
>
> status: not started.

OK -- I think there are a couple of us with it on our minds, so I'll 
leave it un-claimed.  When someone starts to work on it, let everyone 
else know, so there's no duplicated effort.

  -George

Re: Xen 4.4 development update

[George Dunlap]

On 10/08/13 00:08, Matt Wilson wrote:
> On Fri, Aug 09, 2013 at 04:10:10PM +0200, Dario Faggioli wrote:
>> On gio, 2013-08-08 at 17:09 +0100, George Dunlap wrote:
>>> = Timeline =
>>>
>>> As discussed elsewhere, I am proposing a 6-month release cycle.  Xen
>>> 4.3 was released on 9 July.  That would give us a release on 9 January
>>> 2014.  This is fairly close after the Christmas season, so I propose
>>> to make the estimated release date later, on 21 January, giving a few
>>> extra weeks for the holiday season:
>>>
>>> * Feature freeze: 18 October 2013
>>> * Code freezing point: 8 November 2013
>>> * First RC: 26 November 2013
>>> * Release: 21 January 2014
>>>
> [...]
>
>>> === Big ticket items ===
> [...]
>
>> Also, we might want to add:
>>
>>    - HVM guest NUMA
>>       owner: Matt Wilson
>>       status: ?
>>
>> Is that ok, Matt?
> Yes.
>
>> If you're concerned about the libxl part of that, I have a series half
>> backed that I'll be posting here soon (as RFC or something), so feel
>> free to leave that to me. :-)
> OK! I'll try to find some time to rebase the patch and post as an RFC.

Great!
  -George

Re: Xen 4.4 development update

[George Dunlap]

On 09/08/13 21:01, Daniel Kiper wrote:
> On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote:
>
> [...]
>
>> * Xen EFI feature: Xen can boot from grub.efi
>>   owner: Daniel Kiper
>>   status: Just begun
>>   prognosis: Fair
> I think that you could change that to Good. I am working
> on it. Migration to xbi struct is almost finished and
> multiboot2 protocol works on machines with legacy BIOS.
> Now I am working on multiboot2 protocol for machines
> with EFI. Yesterday, I discovered some issues related
> to memory map passed via this protocol. Sadly it looks
> that taking into account current GRUB2 implementation
> only workaround is available. Final proper solution would
> require some changes in GRUB2. I will do that later.
>
> [...]
>
>> * Guest EFI booting
>>   - status: tianocore in-tree, some build problems.
>>     Needs new owner.
> I could take over ownership of this but it would have
> lowest priority on my task list now (major stuff only:
> 1 - multiboot2 protocl, 2 - EFI support for Xen in Linux
> Kernel, 3 - guest EFI booting).

OK -- I think for now then I'll leave it unclaimed, so that if any other 
enterprising developers show up they can take a look at it.

>
>> * Xen EFI feature: pvops dom0 able to make use of EFI run-time
>> services (external)
>>   owner: Daniel Kiper
>>   status: Just begun
> I am going to start work on it when I finish work on multiboot2 protocol.
>
> Additionally, I think that:
>    - new kexec implementation should be added to this list;
>      David Vrabel work on this; I think that patches are
>      quite mature and need only some polishing,
>    - unmodified_drivers should be removed because as I know
>      they are not maintained for very long time; if you
>      agree I could do that,
>    - as I saw there is a quite big mess in directory structure
>      used by installed Xen related stuff (especially in /var
>      and /usr); I have done some patches for myself but they
>      require some improvements to do public release; if you wish
>      I could work on this too.

It's up to you really -- if you are set on working on it, I'll put it on 
the list; but there is plenty to do othewise. :-)  What kinds of changes 
did you have in mind in particular?

  -George

Re: Xen 4.4 development update

[George Dunlap]

On Thu, Aug 8, 2013 at 5:09 PM, 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

This page is now actually populated, with updates from people's responses.

 -George

Re: Xen 4.4 development update

[Jan Beulich]

>>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> As discussed elsewhere, I am proposing a 6-month release cycle.  Xen
> 4.3 was released on 9 July.  That would give us a release on 9 January
> 2014.  This is fairly close after the Christmas season, so I propose
> to make the estimated release date later, on 21 January, giving a few
> extra weeks for the holiday season:
> 
> * Feature freeze: 18 October 2013
> * Code freezing point: 8 November 2013
> * First RC: 26 November 2013
> * Release: 21 January 2014

So I didn't see any comments on the proposed schedule so far.
Hence I wonder how fixed we have to consider that plan at
this point. I'm asking because from the very beginning I was
not really in favor of shortening the release cycle, and looking
at the number of (smaller) items on my todo list, I don't see any
way to even get just a good part of them done by the proposed
feature freeze date (taking into consideration that working on
those items usually is possible only when no other bugs or
routine work need dealing with).

Jan

Re: Xen 4.4 development update

[Wei Liu]

On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote:
[...]
> 
> * Polish up xenbugtool
>   owner: wei.liu2@citrix.com
> 

I've written a rather primitive prototype and promoted it to some users
some time ago unfortunately they didn't seem to report back.

> * Remove hardcoded mobprobe's in xencommons
>   owner: Wei Liu
>   status: still in discussion
> 

Have we not reached conclusion here? IIRC in a engineering meeting we
had you said we could just leave it as-is for now?

Wei.

Re: Xen 4.4 development update

[Jan Beulich]

>>> On 15.08.13 at 15:02, Wei Liu <wei.liu2@citrix.com> wrote:
> On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote:
>> * Remove hardcoded mobprobe's in xencommons
>>   owner: Wei Liu
>>   status: still in discussion
>> 
> 
> Have we not reached conclusion here? IIRC in a engineering meeting we
> had you said we could just leave it as-is for now?

??? Didn't we long ago agree that this hard coded loading is bogus
and hence should go away? Remember this was originally planned
to happen for 4.3, so any change in direction here needs a very
good reason imo.

Jan

Re: Xen 4.4 development update

[Wei Liu]

On Thu, Aug 15, 2013 at 02:08:01PM +0100, Jan Beulich wrote:
> >>> On 15.08.13 at 15:02, Wei Liu <wei.liu2@citrix.com> wrote:
> > On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote:
> >> * Remove hardcoded mobprobe's in xencommons
> >>   owner: Wei Liu
> >>   status: still in discussion
> >> 
> > 
> > Have we not reached conclusion here? IIRC in a engineering meeting we
> > had you said we could just leave it as-is for now?
> 
> ??? Didn't we long ago agree that this hard coded loading is bogus
> and hence should go away? Remember this was originally planned
> to happen for 4.3, so any change in direction here needs a very
> good reason imo.
> 

Actually I wasn't completely sure I remembered the right thing. I might
be wrong about the conclusion.  Geroge, do you have any clue? :-)

Wei.

> Jan

Re: Xen 4.4 development update

[George Dunlap]

On 15/08/13 14:24, Wei Liu wrote:
> On Thu, Aug 15, 2013 at 02:08:01PM +0100, Jan Beulich wrote:
>>>>> On 15.08.13 at 15:02, Wei Liu <wei.liu2@citrix.com> wrote:
>>> On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote:
>>>> * Remove hardcoded mobprobe's in xencommons
>>>>    owner: Wei Liu
>>>>    status: still in discussion
>>>>
>>> Have we not reached conclusion here? IIRC in a engineering meeting we
>>> had you said we could just leave it as-is for now?
>> ??? Didn't we long ago agree that this hard coded loading is bogus
>> and hence should go away? Remember this was originally planned
>> to happen for 4.3, so any change in direction here needs a very
>> good reason imo.
>>
> Actually I wasn't completely sure I remembered the right thing. I might
> be wrong about the conclusion.  Geroge, do you have any clue? :-)

I think the conclusion we came to was as follows:

* Calling modprobe from libxl is not really feasible due to the fact 
that we have to call exec, which means making some of the calls async; 
one thing led to another and a huge number of calls would have had to be 
made async.

* It is better if kernels use the auto-load mechanisms as much as 
possible, rather than modprobes either in the init scripts or from libxl

* However, blktap is unmaintained.  Unless someone steps up to add the 
functionality (which is not recommended as it would probably te a waste 
of effort), it will continue to require a modprobe. On newer systems, 
without blktap, the modprobe will be harmless.  So for blktap, the 
modprobe will have to remain for the forseeable future.

* It would be good if other modules were modified so that they were 
auto-loaded, rather than modprobed.  However, this was outside of the 
scope of the work I or Wei agreed to do.  We agreed to handle blktap, 
and the blktap module loading issue has been resolved.

* Modifying other modules is an open ticket item

Correct me if I'm wrong, anyone.

I can put "auto-load other modules" on the roadmap without an owner, if 
you like.

  -George

Re: Xen 4.4 development update

[Pasi Kärkkäinen]

On Mon, Aug 19, 2013 at 12:38:16PM +0100, George Dunlap wrote:
> 
> * However, blktap is unmaintained.  Unless someone steps up to add
> the functionality (which is not recommended as it would probably te
> a waste of effort), it will continue to require a modprobe. On newer
> systems, without blktap, the modprobe will be harmless.  So for
> blktap, the modprobe will have to remain for the forseeable future.
> 

What I've been wondering.. XenServer is shipping with and using blktap,
so there must be someone maintaining blktap at Citrix? 

I also understand blktap is on the way out and will be replaced with qdisc in the future.. 

-- Pasi

Re: Xen 4.4 development update

[George Dunlap]

On 19/08/13 13:08, Pasi Kärkkäinen wrote:
> On Mon, Aug 19, 2013 at 12:38:16PM +0100, George Dunlap wrote:
>> * However, blktap is unmaintained.  Unless someone steps up to add
>> the functionality (which is not recommended as it would probably te
>> a waste of effort), it will continue to require a modprobe. On newer
>> systems, without blktap, the modprobe will be harmless.  So for
>> blktap, the modprobe will have to remain for the forseeable future.
>>
> What I've been wondering.. XenServer is shipping with and using blktap,
> so there must be someone maintaining blktap at Citrix?
> I also understand blktap is on the way out and will be replaced with qdisc in the future..

As I understand it, XenServer is using a private fork of blktap2, with 
significant changes.  Since blktap2 as a whole can't be upstreamed into 
the mainline kernel, I think the feeling was that there wasn't any point 
in trying to upstream the local changes to the "classic" kernel.  
Blktap3 was meant to be the mainline-friendly version of blktap, but as 
you say, work on it has halted and the plan at the moment, I'm told is 
to look into qdisk, since it uses a similar technology, but gives access 
to work from other communities as well (Ceph, for example).

Thanos, correct me if I've made a mistake somewhere...

  -George

Re: Xen 4.4 development update

[Thanos Makatos]

> -----Original Message-----
> From: George Dunlap [mailto:george.dunlap@eu.citrix.com]
> Sent: 19 August 2013 13:54
> To: Pasi Kärkkäinen
> Cc: Wei Liu; Ian Jackson; Jan Beulich; xen-devel@lists.xen.org; Thanos
> Makatos
> Subject: Re: [Xen-devel] Xen 4.4 development update
> 
> On 19/08/13 13:08, Pasi Kärkkäinen wrote:
> > On Mon, Aug 19, 2013 at 12:38:16PM +0100, George Dunlap wrote:
> >> * However, blktap is unmaintained.  Unless someone steps up to add
> >> the functionality (which is not recommended as it would probably te
> >> a waste of effort), it will continue to require a modprobe. On newer
> >> systems, without blktap, the modprobe will be harmless.  So for
> >> blktap, the modprobe will have to remain for the forseeable future.
> >>
> > What I've been wondering.. XenServer is shipping with and using
> blktap,
> > so there must be someone maintaining blktap at Citrix?
> > I also understand blktap is on the way out and will be replaced with
> qdisc in the future..
> 
> As I understand it, XenServer is using a private fork of blktap2, with
> significant changes.  Since blktap2 as a whole can't be upstreamed into

That's right, the so-called blktap2.5 that lives in github (https://github.com/xapi-project/blktap).

> the mainline kernel, I think the feeling was that there wasn't any
> point
> in trying to upstream the local changes to the "classic" kernel.
> Blktap3 was meant to be the mainline-friendly version of blktap, but as
> you say, work on it has halted and the plan at the moment, I'm told is
> to look into qdisk, since it uses a similar technology, but gives
> access
> to work from other communities as well (Ceph, for example).

blktap3 work hasn't been halted, only the upstream process has. On the contrary, we're still developing blktap3 (currently on https://github.com/tmakatos/blktap/tree/blktap3 but that's temporary) and our plan is to have it working for XenServer rather soon.

I don't see any technical difficulties in Xen using blktap3, pretty much in the same way it does with qemu.

> 
> Thanos, correct me if I've made a mistake somewhere...
> 
>   -George

Re: Xen 4.4 development update

[George Dunlap]

On 14/08/13 17:35, Jan Beulich wrote:
>>>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>> As discussed elsewhere, I am proposing a 6-month release cycle.  Xen
>> 4.3 was released on 9 July.  That would give us a release on 9 January
>> 2014.  This is fairly close after the Christmas season, so I propose
>> to make the estimated release date later, on 21 January, giving a few
>> extra weeks for the holiday season:
>>
>> * Feature freeze: 18 October 2013
>> * Code freezing point: 8 November 2013
>> * First RC: 26 November 2013
>> * Release: 21 January 2014
> So I didn't see any comments on the proposed schedule so far.
> Hence I wonder how fixed we have to consider that plan at
> this point. I'm asking because from the very beginning I was
> not really in favor of shortening the release cycle, and looking
> at the number of (smaller) items on my todo list, I don't see any
> way to even get just a good part of them done by the proposed
> feature freeze date (taking into consideration that working on
> those items usually is possible only when no other bugs or
> routine work need dealing with).

I think as release cycles get shorter, we have to move into thinking 
more like the Linux "merge windows": you work on your feature, and when 
it's ready, you target it for a specific merge window.  Each release 
will have fewer features, but overall the work should continue at a 
similar pace.

For 4.4, it seems likely that we will have stage one of PVH, host USB 
support, a Linux-based stubdom, a FreeBSD-based libc for minios, vNUMA 
for PV guests, possibly for HVM guests... that seems like a fairly 
feature-ful release.

None of this is set in stone -- if we get to October and it looks like 
4.4 is just "4.3 with some bug fixes", then we can just decide to extend 
the development cycle another few months.

  -George

Re: Xen 4.4 development update

[Ian Campbell]

On Mon, 2013-08-19 at 12:38 +0100, George Dunlap wrote:
> I can put "auto-load other modules" on the roadmap without an owner,
> if you like.

I thought Waldi sent patches for most of hte other backends ages ago and
this stuff just works these days.

Yes, here we are:
commit 149bb2fab547253e6359e76f1b86b95247110e68
Author: Bastian Blank <waldi@debian.org>
Date:   Wed Jun 29 14:40:08 2011 +0200

    xen: Add module alias to autoload backend drivers
    
    All the Xen backend drivers are assigned to a special bus type
    xen-backend. This patch exports xen-backend:* names through modalias and
    uevent to autoload them.
    
    Signed-off-by: Bastian Blank <waldi@debian.org>
    Acked-by: Ian Campbell <ian.campbell@citrix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Seems to have been in 3.1-rc1.

Maybe there are other driver which this didn't affect, evtchn etc
perhaps? I wonder if it is worth init time Xen code synthesising some
uevents iff running on Xen to make these get loaded...

Ian.

Re: Xen 4.4 development update

[Ian Campbell]

On Mon, 2013-08-19 at 14:09 +0100, George Dunlap wrote:
> None of this is set in stone -- if we get to October and it looks like
> 4.4 is just "4.3 with some bug fixes", then we can just decide to
> extend the development cycle another few months.

"4.3 with some bug fixes" doesn't necessarily mean it's not worth
releasing ;-)

Re: Xen 4.4 development update

[Bastian Blank]

On Mon, Aug 19, 2013 at 04:17:46PM +0100, Ian Campbell wrote:
> Maybe there are other driver which this didn't affect, evtchn etc
> perhaps? I wonder if it is worth init time Xen code synthesising some
> uevents iff running on Xen to make these get loaded...

evtchn and privcmd are not auto-loaded. This patch was strictly for
backends.

But it should be possible to create a platform device for xen that
triggers loading of them. Could be also used to differentiate between
control and non-control domain.

Bastian

-- 
Live long and prosper.
		-- Spock, "Amok Time", stardate 3372.7

Re: Xen 4.4 development update

[Ian Campbell]

On Mon, 2013-08-19 at 18:16 +0200, Bastian Blank wrote:
> On Mon, Aug 19, 2013 at 04:17:46PM +0100, Ian Campbell wrote:
> > Maybe there are other driver which this didn't affect, evtchn etc
> > perhaps? I wonder if it is worth init time Xen code synthesising some
> > uevents iff running on Xen to make these get loaded...
> 
> evtchn and privcmd are not auto-loaded. This patch was strictly for
> backends.

right.

> But it should be possible to create a platform device for xen that
> triggers loading of them.

yes, that's the sort of thing I was trying to get at with "synthesizing
uevents"

>  Could be also used to differentiate between
> control and non-control domain.

Hrm, at least evtchn and privcmd are potentially (but not so commonly)
usable in normal domU too. I'd be tempted to just load them if running
on Xen -- they aren't exactly huge...

Ian.

Re: Xen 4.4 development update

[Jan Beulich]

>>> On 19.08.13 at 15:09, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> I think as release cycles get shorter, we have to move into thinking 
> more like the Linux "merge windows": you work on your feature, and when 
> it's ready, you target it for a specific merge window.

Which - as expressed before - I dislike.

Jan

Re: Xen 4.4 development update

[George Dunlap]

On 08/20/2013 08:28 AM, Jan Beulich wrote:
>>>> On 19.08.13 at 15:09, George Dunlap <george.dunlap@eu.citrix.com> wrote:
>> I think as release cycles get shorter, we have to move into thinking
>> more like the Linux "merge windows": you work on your feature, and when
>> it's ready, you target it for a specific merge window.
>
> Which - as expressed before - I dislike.

But I don't think I ever understood the nature of your dislike -- what 
is it you like about the longer release cycles, and/or dislike about the 
shorter ones?

  -George

Re: Xen 4.4 development update

[Jan Beulich]

>>> On 20.08.13 at 11:49, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> On 08/20/2013 08:28 AM, Jan Beulich wrote:
>>>>> On 19.08.13 at 15:09, George Dunlap <george.dunlap@eu.citrix.com> wrote:
>>> I think as release cycles get shorter, we have to move into thinking
>>> more like the Linux "merge windows": you work on your feature, and when
>>> it's ready, you target it for a specific merge window.
>>
>> Which - as expressed before - I dislike.
> 
> But I don't think I ever understood the nature of your dislike -- what 
> is it you like about the longer release cycles, and/or dislike about the 
> shorter ones?

First of all, the dislike above was regarding the merge window model.
That is because I prefer the continuous flow model we got used to,
simply because it allows a more consistent work flow (both from a
developer and from a committer perspective).

As to the shorter release cycles, I'm sure I said before that I see
this problematic wrt stable tree management (resulting in either
shorter stable tree life cycles or more work due to more branches
being maintained) as well as - see above - the worse ratio
between normal development flow and a (partially/mostly) frozen
tree (after all, the merge window concept just is an extreme form
of shortened release cycles, where almost all of the release cycle
is spent in feature frozen state).

Plus to me the argument of more frequent releases allowing
smoother distro adoption doesn't really count: I would
generally expect distros to not ship unpatched versions
anyway, so if they're eager to get a certain feature out to their
users, backporting the feature is always an option.

And just to clarify - don't read into this that I may even be
advocating a significantly longer release cycle. As we learned
with 4.2, anything beyond a year is likely not going to work
out well because of too many changes accumulating.

Jan

Re: Xen 4.4 development update

[Daniel Kiper]

On Wed, Aug 14, 2013 at 02:22:24PM +0100, George Dunlap wrote:
> On 09/08/13 21:01, Daniel Kiper wrote:
> >On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote:
> >
> >[...]
> >
> >>* Xen EFI feature: Xen can boot from grub.efi
> >>  owner: Daniel Kiper
> >>  status: Just begun
> >>  prognosis: Fair
> >I think that you could change that to Good. I am working
> >on it. Migration to xbi struct is almost finished and
> >multiboot2 protocol works on machines with legacy BIOS.
> >Now I am working on multiboot2 protocol for machines
> >with EFI. Yesterday, I discovered some issues related
> >to memory map passed via this protocol. Sadly it looks
> >that taking into account current GRUB2 implementation
> >only workaround is available. Final proper solution would
> >require some changes in GRUB2. I will do that later.
> >
> >[...]
> >
> >>* Guest EFI booting
> >>  - status: tianocore in-tree, some build problems.
> >>    Needs new owner.
> >I could take over ownership of this but it would have
> >lowest priority on my task list now (major stuff only:
> >1 - multiboot2 protocl, 2 - EFI support for Xen in Linux
> >Kernel, 3 - guest EFI booting).
>
> OK -- I think for now then I'll leave it unclaimed, so that if any other
> enterprising developers show up they can take a look at it.

OK.

> >>* Xen EFI feature: pvops dom0 able to make use of EFI run-time
> >>services (external)
> >>  owner: Daniel Kiper
> >>  status: Just begun
> >I am going to start work on it when I finish work on multiboot2 protocol.
> >
> >Additionally, I think that:
> >   - new kexec implementation should be added to this list;
> >     David Vrabel work on this; I think that patches are
> >     quite mature and need only some polishing,
> >   - unmodified_drivers should be removed because as I know
> >     they are not maintained for very long time; if you
> >     agree I could do that,
> >   - as I saw there is a quite big mess in directory structure
> >     used by installed Xen related stuff (especially in /var
> >     and /usr); I have done some patches for myself but they
> >     require some improvements to do public release; if you wish
> >     I could work on this too.
>
> It's up to you really -- if you are set on working on it, I'll put it on
> the list; but there is plenty to do othewise. :-)  What kinds of changes
> did you have in mind in particular?

e.g. a lot of stuff is spread over /var and /var/lib. I do not mention
that /var should not contain any non standard directory, i.e. xen.
Additionally, there are a few directories in /var/lib used by various
stuff. I think that all of them should be moved to /var/lib/xen.
The same is in /var/run and /usr/share case. There are also other
minor issues which are worth to fix.

Daniel

Re: Xen 4.4 development update

[Fabio Fantoni]

Il 13/08/2013 18:19, George Dunlap ha scritto:
> On 08/08/13 20:30, Konrad Rzeszutek Wilk wrote:
>> On Thu, Aug 08, 2013 at 05:09:35PM +0100, 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
>>>
>>> Rather than try to predict precisely what will make it into what
>>> release (which was something of a disaster last release), I'm just
>>> going to borrow a term from the Agile world and call all uncompleted
>>> features the "Backlog".  I'll still track who is doing what, and when
>>> we get close, what state things seem to be in.
>>>
>>> As mentioned in another e-mail, we'll also be working on improving the
>>> regression tester.  Feel free to join us.
>>>
>>> And as always, if you are working on a feature / bug that you want
>>> tracked, please respond to this e-mail.
>>>
>>> = Timeline =
>>>
>>> As discussed elsewhere, I am proposing a 6-month release cycle.  Xen
>>> 4.3 was released on 9 July.  That would give us a release on 9 January
>>> 2014.  This is fairly close after the Christmas season, so I propose
>>> to make the estimated release date later, on 21 January, giving a few
>>> extra weeks for the holiday season:
>>>
>>> * Feature freeze: 18 October 2013
>>> * Code freezing point: 8 November 2013
>>> * First RC: 26 November 2013
>>> * Release: 21 January 2014
>>>
>>> Feedback on the estimated dates  is welcome.
>>>
>>> Last updated: 8 August 2013
>>>
>>> == Completed ==
>>>
>>> [none]
>>>
>>> == Open ==
>>>
>>> * xend still in tree
>>>
>>> * qemu-upstream not freeing pirq
>>>   > http://www.gossamer-threads.com/lists/xen/devel/281498
>>>   status: patches posted
>> They did fix the problem Oracle saw and I believe have been
>> Tested-and-Acked.
>
> Thanks -- have they also been applied?
>
>>
>>> * __update_vcpu_system_time if system_time comes out negative
>>>
>>> * xl pci-detach broken for pv guests?
>>>    > http://bugs.xenproject.org/xen/bug/12
>>>    > kernel doesn't know about moving into states 7 and 8
>>>    status: External
>> Didn't I post a patch for this on Linux - and it is in Linux kernel
>> already.
>
> Great -- thanks for the update.
>
>>> * 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: Probably a bug in Linux xen drivers
>>>
>>> == Backlog ==
>>>
>>> === Testing coverage ===
>>>
>>> * Network driver domains
>>>   @George
>>>
>>> * new libxl w/ previous versions of xl
>>>   @IanJ
>>>
>>> * Host S3 suspend
>>>   @bguthro
>>>
>>> * 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
>>>
>>> * 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
>>>
>>> === Big ticket items ===
>>>
>>> * NUMA Memory migration
>>>    owner: dario@citrix
>>>    status: in progress
>>>
>>> * Event channel scalability
>>>    owner: david@citrix
>>>    status: RFC v5 submitted
>>>    Increase limit on event channels (currently 1024 for 32-bit guests,
>>>    4096 for 64-bit guests)
>> aka FIFO thing right?
>
> Yep.  I'll make this a bit more clear.
>
>>
>>> * PVH mode (w/ Linux)
>>>    owner: mukesh@oracle
>>>    status (Linux): 3rd draft patches posted.
>> More like v8. And already Acked - just waiting for ABI to be in some way
>> "nailed down".
>>
>>>    status (Xen): v10 posted
>>>
>>> * ARM stuff: ??
>>>
>>> * Meta: PVIO NUMA improvements
>>>   - NUMA affinity for vcpus
>>>      owner: Dario
>>>   - PV guest NUMA interface
>>>      owner: Elena
>>>   - Sensible dom0 NUMA layout
>>>   - Toolstack pinning backend thread / virq to appropraite d0 vcpu
>>>
>>> * qemu-upstream stubdom, Linux
>>>     owner: anthony@citrix
>>>     status: in progress
>>>     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
>>>    owner: ianj@citrix
>>>
>>> * Network performance improvements
>>>    owner: wei@citrix
>>>
>>> * Disk performance improvements
>> I think you mean blkback and blkfront?
>>> * Xen EFI feature: Xen can boot from grub.efi
>>>   owner: Daniel Kiper
>>>   status: Just begun
>>>   prognosis: Fair
>>>
>>> * libvirt/libxl integration (external)
>>>   > need a status update
>>>   - owner: jfehlig@suse, dario@citrix
>>>
>>> * Default to credit2
>>>   - cpu pinning
>>>   - NUMA affinity
>>>   - cpu "reservation"
>>>
>>> * xenperf
>>>    Owner: Boris Otovsky
>>>
>>> * blktap3
>>>    owner: thanos@citrix
>>>    status: on hold pending XenServer decision
>>>
>>> * Nested virtualization on Intel
>>>
>>> * Nested virtualization on AMD
>>>
>>> * Make storage migration possible
>>>    owner: ?
>>>    status: none
>>>    There needs to be a way, either via command-line or via some hooks,
>>>    that someone can build a "storage migration" feature on top of libxl
>>>    or xl.
>>>
>>> * Full-VM snapshotting
>>>    owner: ?
>>>    status: none
>>>    Have a way of coordinating the taking and restoring of VM memory and
>>>    disk snapshots.  This would involve some investigation into the best
>>>    way to accomplish this.
>>>
>>> * VM Cloning
>>>    owner: ?
>>>    status: none
>>>    Again, a way of coordinating the memory and disk aspects. Research
>>>    into the best way to do this would probably go along with the
>>>    snapshotting feature.
>>>
>>> * xl vm-{export,import}
>>>    owner: ?
>>>    status: none
>>>    Allow xl to import and export VMs to other formats; particularly
>>>    ovf, perhaps the XenServer format, or more.
>>>
>>> * Memory: Replace PoD with paging mechanism
>>>    owner: george@citrix
>>>    status: none
>>>
>>> * PV audio (audio for stubdom qemu)
>>>    owner: stefano.panella@citrix
>>>    status: ?
>>>
>>> * Wait queues for mm
>>>   > Needed for more advanced paging schemes
>>>    owner: ?
>>>    status: Draft posted Feb 2012; more work to do.
>>>
>>> * V4V: Inter-domain communication
>>>    owner (Xen): dominic.curran@citrix.com
>>>    status (Xen): patches submitted
>>>    owner (Linux driver):  stefano.panella@citrix
>>>    status (Linux driver): in progress
>>>
>>> === clean-ups ===
>>>
>>> * 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
>>>
>>> * Make network driver domains easier to set up / more useful
>>>   - Default backend (submitted)
>>>   - Remove unnecessary restriction wrt dom0 hotplug scripts (submitted)
>>>   - 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
>>>
>>> * 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
>>>
>>> * 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
>>>    status: Probably not for 4.3
>>>
>>> * 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
>>>    status: Probably not for 4.3
>>>
>>> * mac address changes on reboot if not specified in config file
>>>    > Needs a robust way to "add" to the config
>>>    status: Too much for 4.3

Are there news about that?

>>>
>>> * qxl
>>>    > 
>>> http://bugs.xenproject.org/xen/bug/11http://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

Anthony Perard patch about uninitialized qxl struct element in qemu is 
on upstream git:
http://git.qemu.org/?p=qemu.git;a=commit;h=329f97fc4ff4b533fcd2d8f4eab6c9c2568aed27

I think is good improve spice support not only with qxl for now 
unfortunately blocked by the problem with SSE support.
Vdagent and usb redirection are fully working with xen but not supported 
by xl now, I tested them manually for over a year and I found no 
problems caused by xen.

I did xl patch for add vdagent support long time ago, here the last version:
http://lists.xen.org/archives/html/xen-devel/2013-08/msg02635.html

The security question open by Ian Jackson has been answered here:
http://lists.xen.org/archives/html/xen-devel/2013-08/msg01438.html

So I also made this patch to optionally disable the clipboard sharing:
http://lists.xen.org/archives/html/xen-devel/2013-08/msg02651.html

About usbredirection I'll post a new version of patch, for now there is 
a patch about xl usb2 and usb3 controller support ready:
http://lists.xen.org/archives/html/xen-devel/2013-07/msg01101.html

Now on xl there is only usb1 controller support but windows 7 domU (and 
probably also with other windows) doesn't see it correctly.
Consequently it is not working the usb redirection on windows 7, because 
to have it working it needs the usb2 controller.
On ubuntu domU works also with usb1 but based on windows tests I think 
is good to add usb2 controller support before add spice usb redirection 
support.

Thanks for any reply.

>>>
>>> * 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
>>>
>>> * Polish up xenbugtool
>>>    owner: wei.liu2@citrix.com
>>>
>>> * 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.
>>>   status: Not for 4.3
>>>
>>> * Remove hardcoded mobprobe's in xencommons
>>>    owner: Wei Liu
>>>    status: still in discussion
>>>
>>> * xl USB pass-through for HVM guests using Qemu USB emulation
>>>    owner: George
>>>    status: v6 patch series posted
>>>
>>> * Rationalized backend scripts
>>>    owner: roger@citrix
>>>    status: patches posted
>>>
>>> * Scripts for driver domains (depends on backend scripts)
>>>    owner: roger@citrix
>>>    status:
>>>
>>> * Multi-vector PCI MSI (support at least for Dom0)
>>>    owner: jan@suse
>>>    status: Patches posted for Intel; AMD not yet done
>> And patches for Linux upstream are missing.
>
>
>
>>
>>> * 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.
>> Which is to say I hadn't actually touched them in a year.
>
> Yeah, I was under the impression they weren't really going anywhere.  
> If you think this is unclear, feel free to suggest alternate wording.
>
>>
>>>    - James Harper's GPLPV drivers for Windows include PVUSB frontend 
>>> drivers.
>>>
>>> * Guest EFI booting
>>>   - status: tianocore in-tree, some build problems.
>>>     Needs new owner.
>>>
>>> * Xen EFI feature: pvops dom0 able to make use of EFI run-time
>>> services (external)
>>>   owner: Daniel Kiper
>>>   status: Just begun
>>>
>>> * Serial console improvements
>>>    owner: ?
>>>    status: Stalled (see below)
>>>    -xHCI debug port (Needs hardware)
>>>    -Firewire (needs hardware)
>>>
>> I would like also to put GPU passthrough working here.
>
> What aspect do you mean?
>
>  -George
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: Xen 4.4 development update

[Shriram Rajagopalan]

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

On Thu, Aug 8, 2013 at 12:09 PM, 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
>
> Rather than try to predict precisely what will make it into what
> release (which was something of a disaster last release), I'm just
> going to borrow a term from the Agile world and call all uncompleted
> features the "Backlog".  I'll still track who is doing what, and when
> we get close, what state things seem to be in.
>
> As mentioned in another e-mail, we'll also be working on improving the
> regression tester.  Feel free to join us.
>
> And as always, if you are working on a feature / bug that you want
> tracked, please respond to this e-mail.
>
> = Timeline =
>
> As discussed elsewhere, I am proposing a 6-month release cycle.  Xen
> 4.3 was released on 9 July.  That would give us a release on 9 January
> 2014.  This is fairly close after the Christmas season, so I propose
> to make the estimated release date later, on 21 January, giving a few
> extra weeks for the holiday season:
>
> * Feature freeze: 18 October 2013
> * Code freezing point: 8 November 2013
> * First RC: 26 November 2013
> * Release: 21 January 2014
>
> Feedback on the estimated dates  is welcome.
>
> Last updated: 8 August 2013
>
>
>
> == Backlog ==
>
>
This is a late entry.
 * libxl support for Remus
   @shriram
   status: memory checkpointing - done.
              network buffering - patches posted.
              disk replication support using DRBD - TODO

[-- Attachment #1.2: Type: text/html, Size: 2225 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.4 development update

[Jim Fehlig]

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
>
> Rather than try to predict precisely what will make it into what
> release (which was something of a disaster last release), I'm just
> going to borrow a term from the Agile world and call all uncompleted
> features the "Backlog".  I'll still track who is doing what, and when
> we get close, what state things seem to be in.
>
> As mentioned in another e-mail, we'll also be working on improving the
> regression tester.  Feel free to join us.
>
> And as always, if you are working on a feature / bug that you want
> tracked, please respond to this e-mail.
>
> = Timeline =
>
> As discussed elsewhere, I am proposing a 6-month release cycle.  Xen
> 4.3 was released on 9 July.  That would give us a release on 9 January
> 2014.  This is fairly close after the Christmas season, so I propose
> to make the estimated release date later, on 21 January, giving a few
> extra weeks for the holiday season:
>
> * Feature freeze: 18 October 2013
> * Code freezing point: 8 November 2013
> * First RC: 26 November 2013
> * Release: 21 January 2014
>
> Feedback on the estimated dates  is welcome.
>
> Last updated: 8 August 2013
>
> == Completed ==
>
> [none]
>
> == Open ==
>
> * xend still in tree
>
> * qemu-upstream not freeing pirq
>  > http://www.gossamer-threads.com/lists/xen/devel/281498
>  status: patches posted
>
> * __update_vcpu_system_time if system_time comes out negative
>
> * xl pci-detach broken for pv guests?
>   > http://bugs.xenproject.org/xen/bug/12
>   > kernel doesn't know about moving into states 7 and 8
>   status: External
>
> * 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: Probably a bug in Linux xen drivers
>
> == Backlog ==
>
> === Testing coverage ===
>
> * Network driver domains
>  @George
>
> * new libxl w/ previous versions of xl
>  @IanJ
>
> * Host S3 suspend
>  @bguthro
>
> * 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
>
> * 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
>
> === Big ticket items ===
>
> * NUMA Memory migration
>   owner: dario@citrix
>   status: in progress
>
> * Event channel scalability
>   owner: david@citrix
>   status: RFC v5 submitted
>   Increase limit on event channels (currently 1024 for 32-bit guests,
>   4096 for 64-bit guests)
>
> * PVH mode (w/ Linux)
>   owner: mukesh@oracle
>   status (Linux): 3rd draft patches posted.
>   status (Xen): v10 posted
>
> * ARM stuff: ??
>
> * Meta: PVIO NUMA improvements
>  - NUMA affinity for vcpus
>     owner: Dario
>  - PV guest NUMA interface
>     owner: Elena
>  - Sensible dom0 NUMA layout
>  - Toolstack pinning backend thread / virq to appropraite d0 vcpu
>
> * qemu-upstream stubdom, Linux
>    owner: anthony@citrix
>    status: in progress
>    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
>   owner: ianj@citrix
>   

There is no mention of updating to the latest upstream qemu.  Wasn't
there talk of updating to the latest qemu release at the beginning of a
Xen development cycle?

> * Network performance improvements
>   owner: wei@citrix
>
> * Disk performance improvements
>
> * Xen EFI feature: Xen can boot from grub.efi
>  owner: Daniel Kiper
>  status: Just begun
>  prognosis: Fair
>
> * libvirt/libxl integration (external)
>  > need a status update
>  - owner: jfehlig@suse, dario@citrix
>   

The main items missing in the libvirt libxl driver wrt the legacy Xen
driver are migration and PCI passthrough.  But patches for both of these
features have been posted to the libvirt dev list

https://www.redhat.com/archives/libvir-list/2013-September/msg00667.html
https://www.redhat.com/archives/libvir-list/2013-September/msg00660.html

libvirt is on a monthly release cycle, so there will certainly be a
release containing these patches before Xen 4.4.

There are also patches in the works to add functionality that was
generally not possible in the legacy Xen driver, e.g. integration with
libvirt's lock manager, providing protection of disk resources.  I'm
also working on patches to improve concurrency in the driver.  Slowly,
with each libvirt release, the libxl driver is improving.

Regards,
Jim

Re: Xen 4.4 development update

[Jan Beulich]

>>> On 17.09.13 at 17:12, Jim Fehlig <jfehlig@suse.com> wrote:
> George Dunlap wrote:
>> * qemu-upstream stubdom, BSD libc
>>   owner: ianj@citrix
>>   
> 
> There is no mention of updating to the latest upstream qemu.  Wasn't
> there talk of updating to the latest qemu release at the beginning of a
> Xen development cycle?

Talking of which - shouldn't we also update to the latest stable
SeaBIOS for the new release?

Jan

Re: Xen 4.4 development update

[Ian Campbell]

On Tue, 2013-09-17 at 16:39 +0100, Jan Beulich wrote:
> >>> On 17.09.13 at 17:12, Jim Fehlig <jfehlig@suse.com> wrote:
> > George Dunlap wrote:
> >> * qemu-upstream stubdom, BSD libc
> >>   owner: ianj@citrix
> >>   
> > 
> > There is no mention of updating to the latest upstream qemu.  Wasn't
> > there talk of updating to the latest qemu release at the beginning of a
> > Xen development cycle?
> 
> Talking of which - shouldn't we also update to the latest stable
> SeaBIOS for the new release?

Yes we should. Which means I should, just need to get around to it :-(

Ian.

Re: Xen 4.4 development update

[George Dunlap]

On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> * qemu-upstream not freeing pirq
>  > http://www.gossamer-threads.com/lists/xen/devel/281498
>  status: patches posted

Did this one get fixed yet?

 -George

Re: Xen 4.4 development update

[George Dunlap]

On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:

> * xl pci-detach broken for pv guests?
>   > http://bugs.xenproject.org/xen/bug/12
>   > kernel doesn't know about moving into states 7 and 8
>   status: External
>
> * 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: Probably a bug in Linux xen drivers

Konrad, I think you were looking at these -- has there been any update?

 -George

Re: Xen 4.4 development update

[Konrad Rzeszutek Wilk]

On Wed, Sep 18, 2013 at 12:16:29PM +0100, George Dunlap wrote:
> On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap
> <George.Dunlap@eu.citrix.com> wrote:
> > * qemu-upstream not freeing pirq
> >  > http://www.gossamer-threads.com/lists/xen/devel/281498
> >  status: patches posted
> 
> Did this one get fixed yet?

I believe so. We are just waiting for Stefano to merge it in.
> 
>  -George

Re: Xen 4.4 development update

[Konrad Rzeszutek Wilk]

On Wed, Sep 18, 2013 at 12:27:15PM +0100, George Dunlap wrote:
> On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap
> <George.Dunlap@eu.citrix.com> wrote:
> 
> > * xl pci-detach broken for pv guests?
> >   > http://bugs.xenproject.org/xen/bug/12
> >   > kernel doesn't know about moving into states 7 and 8
> >   status: External
> >
> > * 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: Probably a bug in Linux xen drivers
> 
> Konrad, I think you were looking at these -- has there been any update?

Oh boy. I need to replicate this.  Thanks for the remainder.
> 
>  -George

Re: Xen 4.4 development update

[Jan Beulich]

>>> On 27.01.14 at 19:49, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> * Disable IOMMU if no southbridge
>  > http://bugs.xenproject.org/xen/bug/37 

Patch posted (for testing by the reporter of the problem), but
certainly not even coming close to being a blocker.

Jan

Re: Xen 4.4 development update

[Jim Fehlig]

George Dunlap wrote:
> It's probably about time to start looking at "cross-compatibility"
> test matrix:
>
> * Migrating from 4.3 to 4.4
>
> * Compiling applications written for 4.3's libxl against 4.4's libxl
>   

The libvirt libxl driver compiles cleanly with 4.2, 4.3, and 4.4 libxl.

Regards,
Jim

Re: Xen 4.4 development update

[George Dunlap]

On Mon, Jan 27, 2014 at 6:49 PM, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> It's probably about time to start looking at "cross-compatibility"
> test matrix:
>
> * Migrating from 4.3 to 4.4
>
> * Compiling applications written for 4.3's libxl against 4.4's libxl

Diana / Alex:

I think I recall that you guys had your own toolstack that you were
compiling against libxl.  If you guys could spare a few cycles, it
would be really helpful to try the new 4.4 libxl and make sure that
we're being suitable backwards-compatible.

Thanks,
 -George

Xen 4.4 development update

[George Dunlap]

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

I've just spent some time going through xen-devel, and it looks like
the main blocker we know about is the Windows install BSOD introduced
with the update to qemu 1.6.

I've divided the list of open bugs into "Open" (might be for 4.4) and
"Open, not for 4.4".  If there are any other important bugs that need
to be considered for this release which are not on the first list,
please let me know.

It's probably about time to start looking at "cross-compatibility"
test matrix:

* Migrating from 4.3 to 4.4

* Compiling applications written for 4.3's libxl against 4.4's libxl

Anything else I missed?

The next question is: Once the qemu issue is fixed, how much more
testing do we need before we can be confident we've caught all the
necessary bugs?

I'm inclined to say that if we do one more test day and wait a week,
we should be ready.  Thoughts?

= 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: When it's ready (Probably by the end of February).

Last updated: 27 January 2014

== 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.2

* SWIOTLB (in Linux 3.13)

* Disk: indirect descriptors (in 3.11)

* Reworked ocaml bindings

== Resolved since last update ==

* xl support for vnc and vnclisten options with PV guests

* xl needs to disallow PoD with PCI passthrough

== Open ==

* osstest windows-install failures
  > http://bugs.xenproject.org/xen/bug/29
  > http://www.chiark.greenend.org.uk/~xensrcts/logs/24250/
  Anthony investigating
  Blocker

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

* libxl / xl does not handle failure of remote qemu gracefully
  > Related to http://bugs.xenproject.org/xen/bug/30
  > 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
 Ian J investigating

* Claim mode and PoD
  > http://bugs.xenproject.org/xen/bug/32
  Probably not a blocker, but easily fixed
  status: Patch posted

* Disable IOMMU if no southbridge
 > http://bugs.xenproject.org/xen/bug/37

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

== Open, not for 4.4 ==

* 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
 it hasn't been tested because of the other passthrough issues.

 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, need more work, will be stalled for some time
 The fix is to the Linux side of things.
 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
 Ian J investigated -- can of worms, too big to be a blocker for 4.4

* 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 )

  > andyhhp: my proposed RTC fixes break migrate from older versions of
  > Xen, so I have to redesign it from scratch. no way it is going to
  > be ready for 4.4

* HPET interrupt stack overflow (when using hpet_broadcast mode and MSI
capable HPETs)
  owner: andyh@citrix
  status: patches posted, undergoing review iteration.
  > andyhhp: I have more work to do on the HPET series
  > andyhhp: no way it is going to be ready or safe for 4.4

* PCI hole resize support hvmloader/qemu-traditional/qemu-upstream
with PCI/GPU passthrough
  > http://bugs.xenproject.org/xen/bug/28
  > 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

  status: not going to be fixed for 4.4 either. Created bug #28.

Re: Xen 4.4 development update

[Zhang, Yang Z]

Ian Campbell wrote on 2014-01-08:
> I'm filing in for George while he is on vacation and travelling to a conference etc.
> I'm still coming up to speed wrt what is going on with this release so
> please do correct me when I'm wrong. George will be back on 20 January.
> 
> This information will be mirrored on the Xen 4.4 Roadmap wiki page:
>  http://wiki.xen.org/wiki/Xen_Roadmap/4.4
> We tagged 4.4.0-rc1 on 19 December. Based on the conversation had last
> time and on George's final comments in [1] I think this means that PVH
> dom0 support has not made the cut for 4.4, which is a shame but there
> is plenty of good functionality (including PVH domU support) in there.
> 
> [1]
> http://bugs.xenproject.org/xen/mid/%3C52B05C0A.4040404@eu.citrix.com%3 E
> 
> = 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: 8 January 2014
> 
> == 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

Can I say nested virtualization also is good supported in Xen 4.4?

> 
> == Resolved since last update ==
> 
> == Open ==
> 
> * xl support for vnc and vnclisten options with PV guests  >
> http://bugs.xenproject.org/xen/bug/25
>  status: V4 patch posted. Should go in.
>  Blocker?
> * libxl / xl does not handle failure of remote qemu gracefully
>> Related to http://bugs.xenproject.org/xen/bug/29
>> 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  Ian J investigating
> 
> * xl needs to disallow PoD with PCI passthrough
>> see
> http://xen.1045712.n5.nabble.com/PATCH-VT-d-Dis-allow-PCI-device-assig
> nme nt-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
>> Ian J investigated -- can of worms, too big to be a blocker for 4.4
> * 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 )
> 
>> andyhhp: my proposed RTC fixes break migrate from older versions of
>> Xen, so I have to redesign it from scratch. no way it is going to
>> be ready for 4.4
> 
> * HPET interrupt stack overflow (when using hpet_broadcast mode and
> MSI capable HPETs)
>   owner: andyh@citrix
>   status: patches posted, undergoing review iteration.
>> andyhhp: I have more work to do on the HPET series
>> andyhhp: no way it is going to be ready or safe for 4.4
> 
> * PCI hole resize support hvmloader/qemu-traditional/qemu-upstream
> with PCI/GPU passthrough
>> http://bugs.xenproject.org/xen/bug/28
>> 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
> 
>   status: not going to be fixed for 4.4 either. Created bug #28.
> * 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
>   Anthony Perard to patch docs
> * osstest windows-install failures
>> http://bugs.xenproject.org/xen/bug/29
>> http://www.chiark.greenend.org.uk/~xensrcts/logs/24250/
>   Anthony and/or Jan investigating
> === 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; no longer 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
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel


Best regards,
Yang

Re: Xen 4.4 development update

[Wei Liu]

On Wed, Jan 08, 2014 at 01:16:24PM +0000, Ian Campbell wrote:
[...]
> == Open ==
> 
> * xl support for vnc and vnclisten options with PV guests
>  > http://bugs.xenproject.org/xen/bug/25
>  status: V4 patch posted. Should go in.
>  Blocker?
> 

Konrad (the reporter) confirmed this is not a blocker.

Wei.

Re: Xen 4.4 development update

[Ian Campbell]

On Wed, 2014-01-08 at 15:21 +0100, Sander Eikelenboom wrote:
> We
> Perhaps worth noting as a separate non-blocking (for 4.5) item:
> * PVH support for AMD (/SVM)

I leave that up to the 4.5 RM.

> And also mention this "lack" of support in the announcement of the new experimental feature PVH.

It is certainly worth making the point that it is Intel only in the
Release Notes or announcements etc.

Ian.

Re: Xen 4.4 development update

[Sander Eikelenboom]

Wednesday, January 8, 2014, 2:16:24 PM, you wrote:

> I'm filing in for George while he is on vacation and travelling to a
> conference etc. I'm still coming up to speed wrt what is going on with
> this release so please do correct me when I'm wrong. George will be
> back on 20 January.

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

> We tagged 4.4.0-rc1 on 19 December. Based on the conversation had last
> time and on George's final comments in [1] I think this means that PVH
> dom0 support has not made the cut for 4.4, which is a shame but there
> is plenty of good functionality (including PVH domU support) in there.

> [1] http://bugs.xenproject.org/xen/mid/%3C52B05C0A.4040404@eu.citrix.com%3E

> = 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: 8 January 2014

> == Completed ==

<snip>

> * PHV domU (experimental only)

<snip>

> === 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; no longer considered a blocker

Perhaps worth noting as a separate non-blocking (for 4.5) item:
* PVH support for AMD (/SVM)

And also mention this "lack" of support in the announcement of the new experimental feature PVH.

Re: Xen 4.4 development update

[Ian Campbell]

On Wed, 2014-01-08 at 13:29 +0000, Ian Campbell wrote:
> On Wed, 2014-01-08 at 13:16 +0000, Ian Campbell wrote:
> > 
> > * libxl / xl does not handle failure of remote qemu gracefully
> >   > Related to http://bugs.xenproject.org/xen/bug/29
> 
> This should be http://bugs.xenproject.org/xen/bug/30
> 
> http://bugs.xenproject.org/xen/bug/29 is
> 
> * Windows install failures/BSOD
>  > http://bugs.xenproject.org/xen/bug/29
>  status: Anthony attempting to reproduce
>  Blocker
> 
> which I forgot to list.

Except I didn't -- it was at the end...

Re: Xen 4.4 development update

[Ian Campbell]

On Wed, 2014-01-08 at 13:16 +0000, Ian Campbell wrote:
> 
> * libxl / xl does not handle failure of remote qemu gracefully
>   > Related to http://bugs.xenproject.org/xen/bug/29

This should be http://bugs.xenproject.org/xen/bug/30

http://bugs.xenproject.org/xen/bug/29 is

* Windows install failures/BSOD
 > http://bugs.xenproject.org/xen/bug/29
 status: Anthony attempting to reproduce
 Blocker

which I forgot to list.

Xen 4.4 development update

[Ian Campbell]

I'm filing in for George while he is on vacation and travelling to a
conference etc. I'm still coming up to speed wrt what is going on with
this release so please do correct me when I'm wrong. George will be
back on 20 January.

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

We tagged 4.4.0-rc1 on 19 December. Based on the conversation had last
time and on George's final comments in [1] I think this means that PVH
dom0 support has not made the cut for 4.4, which is a shame but there
is plenty of good functionality (including PVH domU support) in there.

[1] http://bugs.xenproject.org/xen/mid/%3C52B05C0A.4040404@eu.citrix.com%3E

= 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: 8 January 2014

== 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 ==

== Open ==

* xl support for vnc and vnclisten options with PV guests
 > http://bugs.xenproject.org/xen/bug/25
 status: V4 patch posted. Should go in.
 Blocker?

* libxl / xl does not handle failure of remote qemu gracefully
  > Related to http://bugs.xenproject.org/xen/bug/29
  > 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
 Ian J investigating

* 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
 Ian J investigated -- can of worms, too big to be a blocker for 4.4

* 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 )

  > andyhhp: my proposed RTC fixes break migrate from older versions of
  > Xen, so I have to redesign it from scratch. no way it is going to
  > be ready for 4.4

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

  > andyhhp: I have more work to do on the HPET series
  > andyhhp: no way it is going to be ready or safe for 4.4

* PCI hole resize support hvmloader/qemu-traditional/qemu-upstream with PCI/GPU passthrough
  > http://bugs.xenproject.org/xen/bug/28
  > 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

  status: not going to be fixed for 4.4 either. Created bug #28.

* 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
  Anthony Perard to patch docs

* osstest windows-install failures
  > http://bugs.xenproject.org/xen/bug/29
  > http://www.chiark.greenend.org.uk/~xensrcts/logs/24250/
  Anthony and/or Jan investigating

=== 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; no longer 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

Re: Xen 4.4 development update

[Stefano Stabellini]

On Tue, 3 Dec 2013, Konrad Rzeszutek Wilk wrote:
> > * qemu-upstream not freeing pirq
> >  > http://www.gossamer-threads.com/lists/xen/devel/281498
> >  status: patches posted; latest patches need testing
> 
> So.. I know there was a patch, but looking at that thread I see:
> 
> 
> 	> Hi Stefano, 
> 	> 
> 	> do you work out a patch for me to test? 
> 
> 	I'll be traveling/busy for a few weeks, maybe it's best if someone else 
> 	picks up this work item. 
> 
> 
> And then there was a patch posted by Stefano at some point. But I can't find it?
> Stefano, help?!

it should be this one:

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

Re: Xen 4.4 development update

[Ian Campbell]

create ^
title it xl support for vnc and vnclisten options with PV guests
thanks 

On Tue, 2013-12-03 at 14:37 -0500, Konrad Rzeszutek Wilk wrote:
> > * xend still in tree (x)
[...]
> Please also add in the vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1']
> vs just adding 'vnc=1, vnclisten=...' options.
> 
> With Xend you could use either one with a PV guest and it would
> setup a framebuffer. With xl if you do:
> 
> vnc=1
> vnclisten=0.0.0.0
> 
> it won't setup a framebuffer.

Looks like xl_cmdimpl.c only implements those top level options for HVM
guests.

Ian.

Re: Xen 4.4 development update

[Konrad Rzeszutek Wilk]

> * qemu-upstream not freeing pirq
>  > http://www.gossamer-threads.com/lists/xen/devel/281498
>  status: patches posted; latest patches need testing

So.. I know there was a patch, but looking at that thread I see:


	> Hi Stefano, 
	> 
	> do you work out a patch for me to test? 

	I'll be traveling/busy for a few weeks, maybe it's best if someone else 
	picks up this work item. 


And then there was a patch posted by Stefano at some point. But I can't find it?
Stefano, help?!

Re: Xen 4.4 development update

[Konrad Rzeszutek Wilk]

> * 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

Please also add in the vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1']
vs just adding 'vnc=1, vnclisten=...' options.

With Xend you could use either one with a PV guest and it would
setup a framebuffer. With xl if you do:

vnc=1
vnclisten=0.0.0.0

it won't setup a framebuffer.

But if you do:
vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1']

Then it works.

Re: Xen 4.4 development update

[Dario Faggioli]

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

On mar, 2013-11-26 at 12:14 +0000, George Dunlap wrote:
> === Meta-items (composed of other items) ===
> 
> * Meta: PVIO NUMA improvements
>  - soft affinity for vcpus (4.4 possible)
>
v5 posted.

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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 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.4 development update

[Dario Faggioli]

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

On mer, 2013-11-27 at 10:51 +0000, Gordan Bobic wrote:
> > == Completed ==
> 
>  [...]
> 
> > * PHV domU (experimental only)
> 
>  It should be interesting to see if this will make Nvidia
>  cards work in domU without the need to modify them into
>  Quadros. 
>
Honestly, I really don't think PVH would make much difference wrt to
this... But yeah, let's see...

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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 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.4 development update

[Lars Kurth]

George,
I guess we need to start looking at drafting a press release and getting 
Advisory Board approval to get the funds. Assuming there are no major 
delays, targeting the week before FOSDEM (the week of Jan 23) would be 
ideal for a release
Lars

On 26/11/2013 12:14, 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
>
> We're one week into the "code freezing point", which means that every
> patch that introduces new functionality needs a freeze exception.
>
> 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).
>
> So when posting a patch requesting a freeze exception, please
> consider the following questions:
>
>   1. What is the benefit of this feature?  Why should we accept this
>   now instead of waiting for 4.5?
>
>   2. What is the risk that this may introduce bugs that may slip the
>   releass, or bugs that may not be discovered and end up in the
>   release?
>
> The more skeptical you are in your evaluation, the more generous I can
> afford to be.
>
> We will become progressively more conservative until the first RC,
> which is scheduled for 2 weeks' time (6 December).  After that, we
> will only accept bug fixes.
>
> Bug fixes can be checked in without a freeze exception throughout the
> code freeze, unless the maintianer 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.  (Tianocore is something which would probably fall under
> this.)
>
> 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.
>
> = Timeline =
>
> Here is our current timeline based on a 6-month release:
>
> * Feature freeze: 18 October 2013
> * Code freezing point: 18 November 2013 <== WE ARE HERE
> * First RC: 6 December 2013
> * Release: 21 January 2014
>
> Last updated: 25 November 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
>
> * PHV domU (experimental only)
>
> * Guest EFI booting (tianocore)
>
> * kexec
>
> * Testing: Xen on ARM
>
> * Update to SeaBIOS 1.7.3.1
>
> * pvgrub2 checked into grub upstream
>
> * SWIOTLB (in Linux 3.13)
>
> * Disk: indirect descriptors (in 3.11)
>
> == Resolved since last update ==
>
> * credit scheduler doesn't update other fields when tslice updated from sysctl
>
> == Open ==
>
> * qemu-upstream not freeing pirq
>   > http://www.gossamer-threads.com/lists/xen/devel/281498
>   status: patches posted; latest patches need testing
>
> * 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
>
> * 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
>   status: Patches posted
>
> * 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
>
> * HPET interrupt stack overflow (when using hpet_broadcast mode and MSI
> capable HPETs)
>    owner: andyh@citrix
>    status: patches posted, undergoing review iteration.
>
> * 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
>
> * 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
>
> == 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
>
> * 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
>
> === Meta-items (composed of other items) ===
>
> * Meta: PVIO NUMA improvements
>   - soft affinity for vcpus (4.4 possible)
>   - PV guest NUMA interface (4.4 possible)
>   - Sensible dom0 NUMA layout
>   - Toolstack pinning backend thread / virq to appropraite d0 vcpu
>   - NUMA-aware ballooning
>
> * 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
>
> === Big ticket items ===
>
> * PVH mode (w/ Linux)
>    owner: mukesh@oracle, george@citrix
>    status (Linux): Acked, waiting for ABI to be nailed down
>    status (Xen): Initial version checked in, still nailing down interface
>
> * Update to qemu 1.6
>    owner: Anthonyper
>    status: In staging, still working out a bug in the VMX code
>
> * ARM 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.
>
> * soft affinity for vcpus (was NUMA affinity for vcpus)
>      owner: Dario
>      status: v2 posted
>
> * PV guest NUMA interface
>      owner: Elena
>      status: v3 posted
>
> * 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
>
> * 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
>
> * libxl network buffering support for Remus
>     @shriram
>     status: patches posted
>     prognosis: fair
>
> * xencrashd
>     owner: don@verizon
>     status: v2 posted
>    > http://lists.xen.org/archives/html/xen-devel/2013-11/msg02569.html
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel

Re: Xen 4.4 development update

[Gordan Bobic]

> == Completed ==

 [...]

> * PHV domU (experimental only)

 It should be interesting to see if this will make Nvidia
 cards work in domU without the need to modify them into
 Quadros. Or whether they have pre-empted the possibility
 and added further checks to disable it (should also be
 interesting to see if older drivers work if the latest
 ones don't).

 Gordan

Re: Xen 4.4 development update

[Ian Campbell]

On Tue, 2013-11-26 at 12:14 +0000, George Dunlap wrote:
> * Update to qemu 1.6
>   owner: Anthonyper
>   status: In staging, still working out a bug in the VMX code

This was pushed a couple of days ago.

> 
> * ARM Live Migration Support
>   owner: Jaeyong Yoo <jaeyong.yoo@samsung.com>
>   status: v5 posted, looking good for code freeze

I updated you on this last tine around:
http://article.gmane.org/gmane.comp.emulators.xen.devel/179068

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

In already.

Ian.

Re: Xen 4.4 development update

[Jan Beulich]

>>> On 26.11.13 at 13:14, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> * 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.

Patch v6 at

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

ready to go in, but wanting to give people some time to review.

Jan

Xen 4.4 development update

[George Dunlap]

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

We're one week into the "code freezing point", which means that every
patch that introduces new functionality needs a freeze exception.

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).

So when posting a patch requesting a freeze exception, please
consider the following questions:

 1. What is the benefit of this feature?  Why should we accept this
 now instead of waiting for 4.5?

 2. What is the risk that this may introduce bugs that may slip the
 releass, or bugs that may not be discovered and end up in the
 release?

The more skeptical you are in your evaluation, the more generous I can
afford to be.

We will become progressively more conservative until the first RC,
which is scheduled for 2 weeks' time (6 December).  After that, we
will only accept bug fixes.

Bug fixes can be checked in without a freeze exception throughout the
code freeze, unless the maintianer 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.  (Tianocore is something which would probably fall under
this.)

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.

= Timeline =

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

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

Last updated: 25 November 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

* PHV domU (experimental only)

* Guest EFI booting (tianocore)

* kexec

* Testing: Xen on ARM

* Update to SeaBIOS 1.7.3.1

* pvgrub2 checked into grub upstream

* SWIOTLB (in Linux 3.13)

* Disk: indirect descriptors (in 3.11)

== Resolved since last update ==

* credit scheduler doesn't update other fields when tslice updated from sysctl

== Open ==

* qemu-upstream not freeing pirq
 > http://www.gossamer-threads.com/lists/xen/devel/281498
 status: patches posted; latest patches need testing

* 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

* 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
 status: Patches posted

* 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

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

* 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

* 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

== 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

* 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

=== Meta-items (composed of other items) ===

* Meta: PVIO NUMA improvements
 - soft affinity for vcpus (4.4 possible)
 - PV guest NUMA interface (4.4 possible)
 - Sensible dom0 NUMA layout
 - Toolstack pinning backend thread / virq to appropraite d0 vcpu
 - NUMA-aware ballooning

* 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

=== Big ticket items ===

* PVH mode (w/ Linux)
  owner: mukesh@oracle, george@citrix
  status (Linux): Acked, waiting for ABI to be nailed down
  status (Xen): Initial version checked in, still nailing down interface

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

* ARM 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.

* soft affinity for vcpus (was NUMA affinity for vcpus)
    owner: Dario
    status: v2 posted

* PV guest NUMA interface
    owner: Elena
    status: v3 posted

* 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

* 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

* libxl network buffering support for Remus
   @shriram
   status: patches posted
   prognosis: fair

* xencrashd
   owner: don@verizon
   status: v2 posted
  > http://lists.xen.org/archives/html/xen-devel/2013-11/msg02569.html

Re: Xen 4.4 development update

[George Dunlap]

On 23/09/13 13:13, Jan Beulich wrote:
>>>> On 23.09.13 at 13:48, George Dunlap <george.dunlap@eu.citrix.com> wrote:
>> (Though again, I think that at some
>> point, if it's not important enough for someone to implement, it's not
>> important enough to keep supporting.)
> I accept that this is one way of viewing things, but as someone
> implementing hypervisor side stuff for people even if neither I nor
> customers of my employer immediately need it, I think it is not
> completely off to expect some symmetry here: I think it is
> reasonable for someone to point out deficiencies in areas (s)he
> doesn't normally work on, and expect those responsible for
> these areas to pick this up unless it's completely off.

Fair enough. :-)

  -George

Re: Xen 4.4 development update

[Jan Beulich]

>>> On 23.09.13 at 13:48, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> (Though again, I think that at some 
> point, if it's not important enough for someone to implement, it's not 
> important enough to keep supporting.)

I accept that this is one way of viewing things, but as someone
implementing hypervisor side stuff for people even if neither I nor
customers of my employer immediately need it, I think it is not
completely off to expect some symmetry here: I think it is
reasonable for someone to point out deficiencies in areas (s)he
doesn't normally work on, and expect those responsible for
these areas to pick this up unless it's completely off.

But yes, this request could/should have been made earlier.

Jan

Re: Xen 4.4 development update

[George Dunlap]

On 23/09/13 08:24, Jan Beulich wrote:
>>>> On 20.09.13 at 18:04, George Dunlap <george.dunlap@eu.citrix.com> wrote:
>> On 20/09/13 16:57, Olaf Hering wrote:
>>> On Mon, Sep 16, George Dunlap wrote:
>>>
>>>> * xend still in tree
>>>>    - xl list -l on a dom0-only system
>>>>    - xl list -l doesn't contain tty console port
>>>>    - Alternate transport support for migration
>>> libxl has no pvscsi support. This is listed as "SCSI LUN/Host
>>> passthrough (PVSCSI)" in the page below.
>>
>>> Is PVUSB already handled by libxl?
>>>
>>> http://wiki.xen.org/wiki/XL_vs_Xend_Feature_Comparison
>> Are you personally using PVSCSI, and/or pvusb, and/or do you know any
>> large downstreams and/or user bases that depend on them?
> We certainly have customers using pvSCSI (for some I perhaps
> should say "would like to", as so far they can't due to limitations
> of the protocol).
>
>> There was never any intention of making xl have every single feature of
>> xend; only the features that people cared enough about to argue for /
>> implement themselves. The list above was generated from a recent
>> discussion of why Oracle and Amazon object to removing xend at this
>> time.  If these is an important feature to you, the time to say
>> something about it was 1 year ago.
> I'm pretty certain the question of both pvSCSI and pvUSB not
> being there in xl was raised before.
>
> And no, I don't agree with your initial statement. The outcome of
> the most recent community call was "make all regressions of xl vs
> xm a blocker for 4.4". Of course I don't read this to imply features
> no-one uses, but I certainly read this to cover features that some
> people use, even if they're not a majority.

Well, that's exactly the sticking point -- what is a "feature no-one 
uses" and not?  How are we to know if we don't have this kind of 
discussion and ask about it?

That's my point -- we've been saying, "we're going to get rid of xend 
soon, let us know what features are missing from xl" for two years now.  
It's time to actually make a list of specific features which are 
blockers and get them implemented.

And I don't think we should just give every feature of xend a pass. I 
don't really think we *can* if we wanted to -- for instance, we can't 
allow executable python code in the config file.  According to the 
rubric you propose above, then if there's one guy who is using python in 
his config files, then we're stuck with xend forever.

Furthermore, ultimately code talks.  If those features are valuable, 
then it should be worth someone's time to implement them in xl.  If 
they're not valuable enough for someone to implement, then are they 
really valuable enough to keep?

I think that if the people on the community call want those features, 
it's time to put their money where their mouth is and actually implement 
them in xl.

> And the use case for pvSCSI is pretty obvious: Without it, in order
> to do e.g. a tape backup, you have to PCI-pass-through a whole
> HBA to a guest instead of just the single SCSI tape device that
> you need the guest to have access to.

It's obvious if you know people who do that, but I don't.  This is what 
I was asking Olaf for.  I wouldn't consider this a blocker just to check 
a box on the feature list.  But if you've got a number of customers 
using it, then of course it's an important feature, and we should try to 
implement it before dropping xend.  (Though again, I think that at some 
point, if it's not important enough for someone to implement, it's not 
important enough to keep supporting.)

  -George

Re: Xen 4.4 development update

[George Dunlap]

On 23/09/13 08:24, Jan Beulich wrote:
> And no, I don't agree with your initial statement. The outcome of
> the most recent community call was "make all regressions of xl vs
> xm a blocker for 4.4". Of course I don't read this to imply features
> no-one uses, but I certainly read this to cover features that some
> people use, even if they're not a majority.

Any decision about the direction of where Xen goes needs to be made in 
public.  Everyone who has a stake needs to be able to see the reasoning 
that went into it, and challenge it and make their own viewpoint known 
if necessary.  The community call cannot do this -- the call is not 
recorded, so no one can listen in to the discussion to see what the 
reasoning was, and no one can retroactively go back and enter the 
discussion to affect the outcome.

The community call is good for significant contributors to more 
effectively discuss what the positions of the individual people on the 
call are, what problems there are, and quickly brainstorm solutions or 
compromises that work for everyone.  But if the people on the call 
decide something, all it means is that the individual people on the call 
have decided -- it's not binding on the community until it has been 
discussed on the list.

Obviously the people on the call carry a lot of weight in the community, 
so it's likely that anything decided there will ultimately be decided 
here; but it's not something that can be taken for granted.

  -George

Re: Xen 4.4 development update

[Pasi Kärkkäinen]

On Mon, Sep 23, 2013 at 10:48:13AM +0200, Olaf Hering wrote:
> On Fri, Sep 20, George Dunlap wrote:
> 
> > On 20/09/13 16:57, Olaf Hering wrote:
> > >On Mon, Sep 16, George Dunlap wrote:
> > >
> > >>* xend still in tree
> > >>  - xl list -l on a dom0-only system
> > >>  - xl list -l doesn't contain tty console port
> > >>  - Alternate transport support for migration
> > >libxl has no pvscsi support. This is listed as "SCSI LUN/Host
> > >passthrough (PVSCSI)" in the page below.
> > 
> > 
> > >
> > >Is PVUSB already handled by libxl?
> > >
> > >http://wiki.xen.org/wiki/XL_vs_Xend_Feature_Comparison
> > 
> > Are you personally using PVSCSI, and/or pvusb, and/or do you know any large
> > downstreams and/or user bases that depend on them?
> 
> I'm not using it myself. At least two different customers were using it.
> As Jan said in his reply, we should not silently drop functionality.
> 

Earlier James Harper mentioned on xen-devel that he'd take a look at implementing PVSCSI in xl/libxl,
because he's using Xen PVSCSI for tape backups, but I don't think he got to it so far...

> > That said, pvusb should be really simple to do once we have the HVM hot-plug
> > support; I've got a patch series that just needs to be cleaned up and
> > submitted.  It's on my short list of things to do, but realistically looking
> > like it's not going to happen for 4.4 (unless we reconsider the release
> > cycle length).  If you're interested in taking it over, I'd be happy to hand
> > it off to you.
> 
> Up to now I have not looked at pvusb. I will do so in the next days.
> 

A lot of Xen users are asking for PVUSB, it's being discussed often on ##xen and on mailinglists,
but it isn't very easy to use these days because of the out-of-tree usbback/usbfront drivers, 
and toolstack support only in xm/xend.


-- Pasi

Re: Xen 4.4 development update

[Olaf Hering]

On Fri, Sep 20, George Dunlap wrote:

> On 20/09/13 16:57, Olaf Hering wrote:
> >On Mon, Sep 16, George Dunlap wrote:
> >
> >>* xend still in tree
> >>  - xl list -l on a dom0-only system
> >>  - xl list -l doesn't contain tty console port
> >>  - Alternate transport support for migration
> >libxl has no pvscsi support. This is listed as "SCSI LUN/Host
> >passthrough (PVSCSI)" in the page below.
> 
> 
> >
> >Is PVUSB already handled by libxl?
> >
> >http://wiki.xen.org/wiki/XL_vs_Xend_Feature_Comparison
> 
> Are you personally using PVSCSI, and/or pvusb, and/or do you know any large
> downstreams and/or user bases that depend on them?

I'm not using it myself. At least two different customers were using it.
As Jan said in his reply, we should not silently drop functionality.

> That said, pvusb should be really simple to do once we have the HVM hot-plug
> support; I've got a patch series that just needs to be cleaned up and
> submitted.  It's on my short list of things to do, but realistically looking
> like it's not going to happen for 4.4 (unless we reconsider the release
> cycle length).  If you're interested in taking it over, I'd be happy to hand
> it off to you.

Up to now I have not looked at pvusb. I will do so in the next days.


Olaf

Re: Xen 4.4 development update

[Jan Beulich]

>>> On 20.09.13 at 18:04, George Dunlap <george.dunlap@eu.citrix.com> wrote:
> On 20/09/13 16:57, Olaf Hering wrote:
>> On Mon, Sep 16, George Dunlap wrote:
>>
>>> * xend still in tree
>>>   - xl list -l on a dom0-only system
>>>   - xl list -l doesn't contain tty console port
>>>   - Alternate transport support for migration
>> libxl has no pvscsi support. This is listed as "SCSI LUN/Host
>> passthrough (PVSCSI)" in the page below.
> 
> 
>>
>> Is PVUSB already handled by libxl?
>>
>> http://wiki.xen.org/wiki/XL_vs_Xend_Feature_Comparison 
> 
> Are you personally using PVSCSI, and/or pvusb, and/or do you know any 
> large downstreams and/or user bases that depend on them?

We certainly have customers using pvSCSI (for some I perhaps
should say "would like to", as so far they can't due to limitations
of the protocol).

> There was never any intention of making xl have every single feature of 
> xend; only the features that people cared enough about to argue for / 
> implement themselves. The list above was generated from a recent 
> discussion of why Oracle and Amazon object to removing xend at this 
> time.  If these is an important feature to you, the time to say 
> something about it was 1 year ago.

I'm pretty certain the question of both pvSCSI and pvUSB not
being there in xl was raised before.

And no, I don't agree with your initial statement. The outcome of
the most recent community call was "make all regressions of xl vs
xm a blocker for 4.4". Of course I don't read this to imply features
no-one uses, but I certainly read this to cover features that some
people use, even if they're not a majority.

And the use case for pvSCSI is pretty obvious: Without it, in order
to do e.g. a tape backup, you have to PCI-pass-through a whole
HBA to a guest instead of just the single SCSI tape device that
you need the guest to have access to.

Jan

Re: Xen 4.4 development update

[George Dunlap]

On 20/09/13 16:57, Olaf Hering wrote:
> On Mon, Sep 16, George Dunlap wrote:
>
>> * xend still in tree
>>   - xl list -l on a dom0-only system
>>   - xl list -l doesn't contain tty console port
>>   - Alternate transport support for migration
> libxl has no pvscsi support. This is listed as "SCSI LUN/Host
> passthrough (PVSCSI)" in the page below.


>
> Is PVUSB already handled by libxl?
>
> http://wiki.xen.org/wiki/XL_vs_Xend_Feature_Comparison

Are you personally using PVSCSI, and/or pvusb, and/or do you know any 
large downstreams and/or user bases that depend on them?

There was never any intention of making xl have every single feature of 
xend; only the features that people cared enough about to argue for / 
implement themselves. The list above was generated from a recent 
discussion of why Oracle and Amazon object to removing xend at this 
time.  If these is an important feature to you, the time to say 
something about it was 1 year ago.

That said, pvusb should be really simple to do once we have the HVM 
hot-plug support; I've got a patch series that just needs to be cleaned 
up and submitted.  It's on my short list of things to do, but 
realistically looking like it's not going to happen for 4.4 (unless we 
reconsider the release cycle length).  If you're interested in taking it 
over, I'd be happy to hand it off to you.

  -George

Re: Xen 4.4 development update

[Olaf Hering]

On Mon, Sep 16, George Dunlap wrote:

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

libxl has no pvscsi support. This is listed as "SCSI LUN/Host
passthrough (PVSCSI)" in the page below.

Is PVUSB already handled by libxl?

http://wiki.xen.org/wiki/XL_vs_Xend_Feature_Comparison


Olaf

Re: Xen 4.4 development update

[George Dunlap]

On 17/09/13 20:18, Pasi Kärkkäinen wrote:
> On Mon, Sep 16, 2013 at 02:06:23PM +0100, George Dunlap wrote:
>> == Backlog ==
>>
>> === Testing coverage ===
>>
>>
>> * HVM pci passthrough
>>   @anthony
>>
> Is this entry about the mismatch of hvmloader/seabios/qemu-upstream memory ranges / BAR mapping?

This entry is about getting a test case into osstest that will test HVM 
pci passthrough so that we can detect regressions early.

  -George

Re: Xen 4.4 development update

[George Dunlap]

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

On 17/09/13 13:04, Ben Guthro wrote:
>
>
>
> On Tue, Sep 17, 2013 at 3:14 AM, Dario Faggioli 
> <dario.faggioli@citrix.com <mailto:dario.faggioli@citrix.com>> wrote:
>
>     On lun, 2013-09-16 at 20:45 -0400, Ben Guthro wrote:
>
>
>     > On Mon, Sep 16, 2013 at 9:06 AM, George Dunlap
>     > <George.Dunlap@eu.citrix.com
>     <mailto:George.Dunlap@eu.citrix.com>> wrote:
>     >
>     >
>     > <snip>
>     >
>     >         * Host S3 suspend
>     >          @bguthro
>     >
>     >
>     >
>     > Please add Dario to this, as well.
>     > He had graciously volunteered to look into this, with regard to
>     > osstest.
>     >
>     Indeed I did... And of course I'm a bit behind. Anyway, yes,
>     George, add
>     me here.
>
>     BTW, Ben, could you send me (either here or in private) some hints on
>     how you usually test S3? I'll then look into how to translate that
>     into
>     a test case.
>
>
> Here are a few threads from the past when I have done so, and one 
> where I made a failed attempt to create a test case:
> http://markmail.org/message/4piyk3ztagsm7ueb#query:+page:1+mid:6pc5lnrtrmd7hmrr+state:results
> http://markmail.org/message/lzolxkwipnyc7hqj
> http://xen.markmail.org/thread/ghj2ffngemccq6p4
>
> Hopefully, these will be helpful.

So one aspect of getting this testing automated would be to make the 
"wake up timer" a proper HV parameter, rather than a patch that has to 
be pasted on for testing.

  -George

[-- Attachment #1.2: Type: text/html, Size: 3610 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.4 development update

[George Dunlap]

On 16/09/13 15:52, Fabio Fantoni wrote:
> Il 16/09/2013 15:06, George Dunlap ha scritto:
>> == Completed  ==
>
> * Improved Spice support on libxl
>  - Added Spice vdagent support
>  - Added Spice clipboard sharing support
>
>
>>
>> == Open ==
>>
> * 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

"Open" is for bugs -- I'll put these under "Backlog".  Thanks.

  -George

Re: Xen 4.4 development update

[Pasi Kärkkäinen]

On Mon, Sep 16, 2013 at 02:06:23PM +0100, George Dunlap wrote:
> 
> == Backlog ==
> 
> === Testing coverage ===
> 
> 
> * HVM pci passthrough
>  @anthony
> 

Is this entry about the mismatch of hvmloader/seabios/qemu-upstream memory ranges / BAR mapping? 

-- Pasi

Re: Xen 4.4 development update

[Andrew Cooper]

On 16/09/2013 14:28, Jan Beulich wrote:
>>>> On 16.09.13 at 15:06, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
>> == Open ==
> * 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.
>
>> === Clean-ups ===
> * ACPI WAET table vs RTC emulation mode
>
> 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.
>
> Jan

Relatedly, there is still an outstanding regression in this code were
Win2k3 Enterprise SP2 occasionally falls into an infinite loop probing
the RTC.  I still need to get to the bottom of why this is happening.

~Andrew

Re: Xen 4.4 development update

[Ben Guthro]

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

On Tue, Sep 17, 2013 at 3:14 AM, Dario Faggioli
<dario.faggioli@citrix.com>wrote:

> On lun, 2013-09-16 at 20:45 -0400, Ben Guthro wrote:
>
>
> > On Mon, Sep 16, 2013 at 9:06 AM, George Dunlap
> > <George.Dunlap@eu.citrix.com> wrote:
> >
> >
> > <snip>
> >
> >         * Host S3 suspend
> >          @bguthro
> >
> >
> >
> > Please add Dario to this, as well.
> > He had graciously volunteered to look into this, with regard to
> > osstest.
> >
> Indeed I did... And of course I'm a bit behind. Anyway, yes, George, add
> me here.
>
> BTW, Ben, could you send me (either here or in private) some hints on
> how you usually test S3? I'll then look into how to translate that into
> a test case.
>

Here are a few threads from the past when I have done so, and one where I
made a failed attempt to create a test case:
http://markmail.org/message/4piyk3ztagsm7ueb#query:+page:1+mid:6pc5lnrtrmd7hmrr+state:results
http://markmail.org/message/lzolxkwipnyc7hqj
http://xen.markmail.org/thread/ghj2ffngemccq6p4

Hopefully, these will be helpful.

Thanks
Ben


>
> 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)
>
>

[-- Attachment #1.2: Type: text/html, Size: 2643 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.4 development update

[Dario Faggioli]

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

On lun, 2013-09-16 at 20:45 -0400, Ben Guthro wrote:


> On Mon, Sep 16, 2013 at 9:06 AM, George Dunlap
> <George.Dunlap@eu.citrix.com> wrote:
> 
> 
> <snip> 
>         
>         * Host S3 suspend
>          @bguthro
>         
> 
> 
> Please add Dario to this, as well.
> He had graciously volunteered to look into this, with regard to
> osstest.
> 
Indeed I did... And of course I'm a bit behind. Anyway, yes, George, add
me here.

BTW, Ben, could you send me (either here or in private) some hints on
how you usually test S3? I'll then look into how to translate that into
a test case.

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)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 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.4 development update

[Ben Guthro]

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

On Mon, Sep 16, 2013 at 9:06 AM, George Dunlap
<George.Dunlap@eu.citrix.com>wrote:

<snip>

>
> * Host S3 suspend
>  @bguthro
>
>
Please add Dario to this, as well.
He had graciously volunteered to look into this, with regard to osstest.

In the last update, he said he would be looking into it sometime in Sept.

Ben

[-- Attachment #1.2: Type: text/html, Size: 823 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.4 development update

[Fabio Fantoni]

Il 16/09/2013 15:06, George Dunlap ha scritto:
> == Completed  ==

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


>
> == Open ==
>
* 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

Re: Xen 4.4 development update

[David Vrabel]

On 16/09/13 14:06, George Dunlap wrote:
> 
> * New kexec implementation

owner: David Vrabel
status: v7 posted, only minor updates expected.

David

Re: Xen 4.4 development update

[David Vrabel]

On 16/09/13 14:06, George Dunlap wrote:
> 
> * New kexec implementation

owner: David Vrabel
status: v7 posted, only minor updates expected.

David

Re: Xen 4.4 development update

[Jan Beulich]

>>> On 16.09.13 at 15:06, George Dunlap <George.Dunlap@eu.citrix.com> wrote:
> == Open ==

* 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.

> === Clean-ups ===

* ACPI WAET table vs RTC emulation mode

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.

Jan

Xen 4.4 development update

[George Dunlap]

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

Rather than try to predict precisely what will make it into what
release (which was something of a disaster last release), I'm just
going to borrow a term from the Agile world and call all uncompleted
features the "Backlog".  I'll still track who is doing what, and when
we get close, what state things seem to be in.

As mentioned in another e-mail, we'll also be working on improving the
regression tester.  Feel free to join us.

And as always, if you are working on a feature / bug that you want
tracked, please respond to this e-mail.

= Timeline =

As discussed elsewhere, I am proposing a 6-month release cycle.  Xen
4.3 was released on 9 July.  That would give us a release on 9 January
2014.  This is fairly close after the Christmas season, so I propose
to make the estimated release date later, on 21 January, giving a few
extra weeks for the holiday season:

* Feature freeze: 18 October 2013
* Code freezing point: 8 November 2013
* First RC: 26 November 2013
* Release: 21 January 2014

Feedback on the estimated dates  is welcome.

Last updated: 16 September 2016

== Completed  ==

* Multi-vector PCI MSI (Hypervisor side)

== Open ==

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

* 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: Probably a bug in Linux xen drivers

* 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

== Backlog ==

=== Testing coverage ===

* new libxl w/ previous versions of xl
 @IanJ

* Host S3 suspend
 @bguthro

* 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 pce 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

=== Clean-ups ===

* 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

* 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

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

* qxl
  > http://bugs.xenproject.org/xen/bug/11http://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

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

* 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.

=== Big ticket items ===

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

* Event channel scalability (FIFO event channels)
  owner: david@citrix
  status: RFC v3 posted
  Increase limit on event channels (currently 1024 for 32-bit guests,
  4096 for 64-bit guests)

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

* ARM stuff: ??

* Meta: PVIO NUMA improvements
 - NUMA affinity for vcpus
    owner: Dario
    status: in progress
 - 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

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

* qemu-upstream stubdom, Linux
   owner: anthony@citrix
   status: in progress
   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
  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

* libvirt/libxl integration (external)
 > need a status update
 - owner: jfehlig@suse, dario@citrix

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

* xenperf
  Owner: Boris Otovsky
  status: v1 patches posted

* blktap3
  owner: thanos@citrix
  status: on hold pending XenServer decision

* Nested virtualization on Intel

* Nested virtualization on AMD

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

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

* Scripts for driver domains (depends on backend scripts)
  owner: roger@citrix
  status:

* 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.

* Guest EFI booting
 - status: tianocore in-tree, some build problems.
   Needs new owner.

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

* New kexec implementation
  > dvrabel has some patches, but page tables need non-trivial changes.
  status: ?

=== Wishlist / someday ===

* Make storage migration possible
  owner: ?
  status: none
  There needs to be a way, either via command-line or via some hooks,
  that someone can build a "storage migration" feature on top of libxl
  or xl.

* Full-VM snapshotting
  owner: ?
  status: none
  Have a way of coordinating the taking and restoring of VM memory and
  disk snapshots.  This would involve some investigation into the best
  way to accomplish this.

* VM Cloning
  owner: ?
  status: none
  Again, a way of coordinating the memory and disk aspects.  Research
  into the best way to do this would probably go along with the
  snapshotting feature.

* xl vm-{export,import}
  owner: ?
  status: none
  Allow xl to import and export VMs to other formats; particularly
  ovf, perhaps the XenServer format, or more.

* Memory: Replace PoD with paging mechanism
  owner: george@citrix
  status: none

* PV audio (audio for stubdom qemu)
  owner: stefano.panella@citrix
  status: ?

* Wait queues for mm
 > Needed for more advanced paging schemes
  owner: ?
  status: Draft posted Feb 2012; more work to do.

* V4V: Inter-domain communication
  owner (Xen): dominic.curran@citrix.com
  status (Xen): patches submitted
  owner (Linux driver):  stefano.panella@citrix
  status (Linux driver): in progress

* Serial console improvements
  owner: ?
  status: Stalled (see below)
  -xHCI debug port (Needs hardware)
  -Firewire (needs hardware)

Re: Xen 4.4 development update

[Stefano Stabellini]

On Thu, 8 Aug 2013, Eric Shelton wrote:
> Related to this, is the Xen hypervisor booting under EFI for arm
> already?

Not yet, but it's on our todo list.


> I assume not, if Linux currently lacks the needed
> hypercalls.  Does anything arm-specific need to happen in an
> EFI-friendly dom0 kernel, given that it is hypercall driven?  Is there
> a platform for test?

It would be great if you could generalize your work enough so that it
would at least compile on arm.

Re: Xen 4.4 development update

[Eric Shelton]

On 08/09/2013 02:56 PM, Daniel Kiper wrote:
> On Thu, Aug 08, 2013 at 04:51:51PM -0400, Eric Shelton wrote:
>> On Thu, Aug 8, 2013 at 3:55 PM, Konrad Rzeszutek Wilk
>> <konrad.wilk@oracle.com> wrote:
>> . . .
>>> Rework them. The maintainer would like it done differently - that was my
>>> recollection last year when I chatted with him (Matthew Garret).
>>>
>>> Daniel will know more - but he is right now making multiboot2 work with
>>> Xen and then attacking this.
>>
>> Back then (https://lkml.org/lkml/2012/2/9/299), Matthew said:
>>
>>> Hm. Is there absolutely no way to do this by replacing efi_call_*? It'd
>>> really be nice to avoid yet another set of duplicate functions here -
>>> the ia64/x86 situation is already bad enough. Ideally this would be
>>> sufficiently generic that arm can also plug into it.
>>
>> It looks like the arm patches are just now nearing commit worthiness,
>> with V2 just posted a couple of days ago:
>>
>> https://lkml.org/lkml/2013/8/6/584
>>
>> It looks like Garrett's goal of merging arm and x86 EFI code is being
>> realized, and that I will need to refactor my patchset to keep up with
>> these changes.  Roy Franz seems to be doing the heavy lifting on arm
>> EFI, with Matt Fleming serving as the maintainer.
>
> I have not dug very deep but it looks that it is only EFI loader
> patch series (called stub in Linux Kernel). It is not related to
> Xen EFI stuff in Linux Kernel.

That looks correct.  The only file in common between the two sets of 
patches is include/linux/efi.h, and those changes do not affect each other.

>> Related to this, is the Xen hypervisor booting under EFI for arm
>> already?  I assume not, if Linux currently lacks the needed
>> hypercalls.  Does anything arm-specific need to happen in an
>> EFI-friendly dom0 kernel, given that it is hypercall driven?  Is there
>> a platform for test?
>
> IIRC there is no EFI support in Xen on ARM. However, you should ask
> Stefano and/or Ian Campbell for more details. They are ARM maintainers
> for Xen.
>
> As Konrad said I am working on multiboot2 protocol support for Xen.
> It is needed to load Xen from e.g. GRUB2 loader on EFI platforms.
> I would like to finish this first because there are some interests
> in that project. Then I will be working on EFI support for Xen
> in Linux Kernel. However, if you like to work on this stuff go
> ahead. I do no have any objections. Just drop me line then I would
> not duplicate your efforts.

In the interest of getting a more finalized patch out while I still 
recall some of the details of this, please find below a revised patch. 
There continues to be an issue with reboot working on my laptop, but I 
think it is in the hypervisor, as the kernel is making the hypercall 
requesting the reboot.  Unfortunately, I do not have the tools to debug 
Xen on my laptop, as it lacks a serial port and I do not have a few of 
the things needed for EHCI port debugging.  The kernel reboots just fine 
when running directly under EFI, although I do not know right now if it 
is via the EFI runtime or the more traditional reboot mechanisms.

If there are no comments, I will try running this by the Linux EFI 
maintainer.

=============

From: Eric Shelton <eshelton@pobox.com>
Date: Thu, 15 Aug 2013 00:31:08 -0400
Subject: [PATCH 1/1] EFI stub: add support for boot under EFI-booted Xen

Allows dom0 kernel to detect when it is running under a Xen hypervisor 
booted under EFI, and then make hyper calls to Xen to identify and 
obtain resources such as ACPI tables, E820 information, and the EFI 
console in order to complete booting.

Applies cleanly against 3.11rc5 and recent arm efi patches.

Signed-off-by: Eric Shelton <eshelton@pobox.com>
---
  arch/x86/platform/efi/Makefile   |   3 +
  arch/x86/platform/efi/efi.c      |  82 ++++++--
  arch/x86/platform/efi/xen.c      | 427 
+++++++++++++++++++++++++++++++++++++++
  arch/x86/xen/enlighten.c         |  22 +-
  include/linux/efi.h              |   8 +
  include/xen/interface/platform.h | 132 ++++++++++++
  6 files changed, 649 insertions(+), 25 deletions(-)
  create mode 100644 arch/x86/platform/efi/xen.c

diff --git a/arch/x86/platform/efi/Makefile b/arch/x86/platform/efi/Makefile
index 6db1cc4..f485766 100644
--- a/arch/x86/platform/efi/Makefile
+++ b/arch/x86/platform/efi/Makefile
@@ -1,2 +1,5 @@
  obj-$(CONFIG_EFI) 		+= efi.o efi_$(BITS).o efi_stub_$(BITS).o
+#ifdef CONFIG_XEN
+obj-$(CONFIG_EFI) 		+= xen.o
+#endif
  obj-$(CONFIG_ACPI_BGRT) += efi-bgrt.o
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 90f6ed1..ca043bda 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -12,6 +12,7 @@
   *	Bibo Mao <bibo.mao@intel.com>
   *	Chandramouli Narayanan <mouli@linux.intel.com>
   *	Huang Ying <ying.huang@intel.com>
+ * Copyright (C) 2013 Eric Shelton <eshelton@pobox.com>
   *
   * Copied from efi_32.c to eliminate the duplicated code between EFI
   * 32/64 support code. --ying 2007-10-26
@@ -51,6 +52,12 @@
  #include <asm/x86_init.h>
  #include <asm/rtc.h>

+#ifdef CONFIG_XEN
+extern void efi_init_xen(void);
+extern u32 efi_mem_type_xen(unsigned long phys_addr);
+extern u64 efi_mem_attributes_xen(unsigned long phys_addr);
+#endif
+
  #define EFI_DEBUG	1

  #define EFI_MIN_RESERVE 5120
@@ -381,6 +388,11 @@ int __init efi_memblock_x86_reserve_range(void)
  	struct efi_info *e = &boot_params.efi_info;
  	unsigned long pmap;

+#ifdef CONFIG_XEN
+	if (efi_enabled(EFI_XEN))
+		return 0;
+#endif
+
  #ifdef CONFIG_X86_32
  	/* Can't handle data above 4GB at this time */
  	if (e->efi_memmap_hi) {
@@ -409,6 +421,8 @@ static void __init print_efi_memmap(void)
  	void *p;
  	int i;

+	if (memmap.map == NULL) return;
+
  	for (p = memmap.map, i = 0;
  	     p < memmap.map_end;
  	     p += memmap.desc_size, i++) {
@@ -426,6 +440,11 @@ void __init efi_reserve_boot_services(void)
  {
  	void *p;

+#ifdef CONFIG_XEN
+	if (efi_enabled(EFI_XEN))
+		return;
+#endif
+
  	for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
  		efi_memory_desc_t *md = p;
  		u64 start = md->phys_addr;
@@ -467,6 +486,11 @@ void __init efi_free_boot_services(void)
  {
  	void *p;

+#ifdef CONFIG_XEN
+	if (efi_enabled(EFI_XEN))
+		return;
+#endif
+
  	if (!efi_is_native())
  		return;

@@ -578,20 +602,15 @@ static int __init efi_systab_init(void *phys)
  	return 0;
  }

-static int __init efi_config_init(u64 tables, int nr_tables)
+int __init efi_config_init(u64 tables, int nr_tables, int entrySz)
  {
  	void *config_tables, *tablep;
-	int i, sz;
-
-	if (efi_enabled(EFI_64BIT))
-		sz = sizeof(efi_config_table_64_t);
-	else
-		sz = sizeof(efi_config_table_32_t);
+	int i;

  	/*
  	 * Let's see what config tables the firmware passed to us.
  	 */
-	config_tables = early_ioremap(tables, nr_tables * sz);
+	config_tables = early_ioremap(tables, nr_tables * entrySz);
  	if (config_tables == NULL) {
  		pr_err("Could not map Configuration table!\n");
  		return -ENOMEM;
@@ -599,7 +618,7 @@ static int __init efi_config_init(u64 tables, int 
nr_tables)

  	tablep = config_tables;
  	pr_info("");
-	for (i = 0; i < efi.systab->nr_tables; i++) {
+	for (i = 0; i < nr_tables; i++) {
  		efi_guid_t guid;
  		unsigned long table;

@@ -612,8 +631,7 @@ static int __init efi_config_init(u64 tables, int 
nr_tables)
  			if (table64 >> 32) {
  				pr_cont("\n");
  				pr_err("Table located above 4GB, disabling EFI.\n");
-				early_iounmap(config_tables,
-					      efi.systab->nr_tables * sz);
+				early_iounmap(config_tables, nr_tables * entrySz);
  				return -EINVAL;
  			}
  #endif
@@ -645,10 +663,10 @@ static int __init efi_config_init(u64 tables, int 
nr_tables)
  			efi.uga = table;
  			pr_cont(" UGA=0x%lx ", table);
  		}
-		tablep += sz;
+		tablep += entrySz;
  	}
  	pr_cont("\n");
-	early_iounmap(config_tables, efi.systab->nr_tables * sz);
+	early_iounmap(config_tables, nr_tables * entrySz);
  	return 0;
  }

@@ -708,9 +726,16 @@ void __init efi_init(void)
  {
  	efi_char16_t *c16;
  	char vendor[100] = "unknown";
-	int i = 0;
+	int entrySz, i = 0;
  	void *tmp;

+#ifdef CONFIG_XEN
+	if (efi_enabled(EFI_XEN)) {
+		efi_init_xen();
+		return;
+	}
+#endif
+
  #ifdef CONFIG_X86_32
  	if (boot_params.efi_info.efi_systab_hi ||
  	    boot_params.efi_info.efi_memmap_hi) {
@@ -745,7 +770,12 @@ void __init efi_init(void)
  		efi.systab->hdr.revision >> 16,
  		efi.systab->hdr.revision & 0xffff, vendor);

-	if (efi_config_init(efi.systab->tables, efi.systab->nr_tables))
+	if (efi_enabled(EFI_64BIT))
+		entrySz = sizeof(efi_config_table_64_t);
+	else
+		entrySz = sizeof(efi_config_table_32_t);
+
+	if (efi_config_init(efi.systab->tables, efi.systab->nr_tables, entrySz))
  		return;

  	set_bit(EFI_CONFIG_TABLES, &x86_efi_facility);
@@ -782,7 +812,14 @@ void __init efi_init(void)

  void __init efi_late_init(void)
  {
+#ifdef CONFIG_XEN
+	if (efi_enabled(EFI_XEN))
+		return;
+#endif
+
+#ifdef CONFIG_ACPI_BGRT
  	efi_bgrt_init();
+#endif
  }

  void __init efi_set_executable(efi_memory_desc_t *md, bool executable)
@@ -871,6 +908,11 @@ void __init efi_enter_virtual_mode(void)
  	void *p, *va, *new_memmap = NULL;
  	int count = 0;

+#ifdef CONFIG_XEN
+	if (efi_enabled(EFI_XEN))
+		return;
+#endif
+
  	efi.systab = NULL;

  	/*
@@ -1007,6 +1049,11 @@ u32 efi_mem_type(unsigned long phys_addr)
  	efi_memory_desc_t *md;
  	void *p;

+#ifdef CONFIG_XEN
+	if (efi_enabled(EFI_XEN))
+		return efi_mem_type_xen(phys_addr);
+#endif
+
  	if (!efi_enabled(EFI_MEMMAP))
  		return 0;

@@ -1025,6 +1072,11 @@ u64 efi_mem_attributes(unsigned long phys_addr)
  	efi_memory_desc_t *md;
  	void *p;

+#ifdef CONFIG_XEN
+	if (efi_enabled(EFI_XEN))
+		return efi_mem_attributes_xen(phys_addr);
+#endif
+
  	for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
  		md = p;
  		if ((md->phys_addr <= phys_addr) &&
diff --git a/arch/x86/platform/efi/xen.c b/arch/x86/platform/efi/xen.c
new file mode 100644
index 0000000..ec0943a
--- /dev/null
+++ b/arch/x86/platform/efi/xen.c
@@ -0,0 +1,427 @@
+/*
+ * Xen EFI (Extensible Firmware Interface) support functions
+ * Based on related efforts in SLE and SUSE trees
+ *
+ * Copyright (C) 1999 VA Linux Systems
+ * Copyright (C) 1999 Walt Drummond <drummond@valinux.com>
+ * Copyright (C) 1999-2002 Hewlett-Packard Co.
+ *	David Mosberger-Tang <davidm@hpl.hp.com>
+ *	Stephane Eranian <eranian@hpl.hp.com>
+ * Copyright (C) 2005-2008 Intel Co.
+ *	Fenghua Yu <fenghua.yu@intel.com>
+ *	Bibo Mao <bibo.mao@intel.com>
+ *	Chandramouli Narayanan <mouli@linux.intel.com>
+ *	Huang Ying <ying.huang@intel.com>
+ * Copyright (C) 2011 Novell Co.
+ *	Jan Beulic <JBeulich@suse.com>
+ * Copyright (C) 2011-2012 Oracle Co.
+ *	Liang Tang <liang.tang@oracle.com>
+ * Copyright (C) 2013 Eric Shelton <eshelton@pobox.com>
+ */
+
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/efi.h>
+#include <linux/export.h>
+#include <linux/platform_device.h>
+#include <linux/spinlock.h>
+#include <linux/time.h>
+
+#include <asm/setup.h>
+#include <asm/efi.h>
+#include <asm/time.h>
+#include <asm/cacheflush.h>
+#include <asm/tlbflush.h>
+#include <asm/x86_init.h>
+
+#include <xen/interface/platform.h>
+#include <xen/interface/sched.h>
+#include <asm/xen/hypercall.h>
+
+#define PFX		"EFI: "
+
+#define call (op.u.efi_runtime_call)
+#define DECLARE_CALL(what) \
+	struct xen_platform_op op; \
+	op.cmd = XENPF_efi_runtime_call; \
+	call.function = XEN_EFI_##what; \
+	call.misc = 0
+
+static efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
+{
+	int err;
+	DECLARE_CALL(get_time);
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	if (tm) {
+		BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.get_time.time));
+		memcpy(tm, &call.u.get_time.time, sizeof(*tm));
+	}
+
+	if (tc) {
+		tc->resolution = call.u.get_time.resolution;
+		tc->accuracy = call.u.get_time.accuracy;
+		tc->sets_to_zero = !!(call.misc &
+				      XEN_EFI_GET_TIME_SET_CLEARS_NS);
+	}
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_set_time(efi_time_t *tm)
+{
+	DECLARE_CALL(set_time);
+
+	BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.set_time));
+	memcpy(&call.u.set_time, tm, sizeof(*tm));
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled,
+					    efi_bool_t *pending,
+					    efi_time_t *tm)
+{
+	int err;
+	DECLARE_CALL(get_wakeup_time);
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	if (tm) {
+		BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.get_wakeup_time));
+		memcpy(tm, &call.u.get_wakeup_time, sizeof(*tm));
+	}
+
+	if (enabled)
+		*enabled = !!(call.misc & XEN_EFI_GET_WAKEUP_TIME_ENABLED);
+
+	if (pending)
+		*pending = !!(call.misc & XEN_EFI_GET_WAKEUP_TIME_PENDING);
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, 
efi_time_t *tm)
+{
+	DECLARE_CALL(set_wakeup_time);
+
+	BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.set_wakeup_time));
+	if (enabled)
+		call.misc = XEN_EFI_SET_WAKEUP_TIME_ENABLE;
+	if (tm)
+		memcpy(&call.u.set_wakeup_time, tm, sizeof(*tm));
+	else
+		call.misc |= XEN_EFI_SET_WAKEUP_TIME_ENABLE_ONLY;
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_get_variable(efi_char16_t *name,
+					 efi_guid_t *vendor,
+					 u32 *attr,
+					 unsigned long *data_size,
+					 void *data)
+{
+	int err;
+	DECLARE_CALL(get_variable);
+
+	set_xen_guest_handle(call.u.get_variable.name, name);
+	BUILD_BUG_ON(sizeof(*vendor) !=
+		     sizeof(call.u.get_variable.vendor_guid));
+	memcpy(&call.u.get_variable.vendor_guid, vendor, sizeof(*vendor));
+	call.u.get_variable.size = *data_size;
+	set_xen_guest_handle(call.u.get_variable.data, data);
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*data_size = call.u.get_variable.size;
+	*attr = call.misc; /* misc in struction is U32 variable*/
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_get_next_variable(unsigned long *name_size,
+					      efi_char16_t *name,
+					      efi_guid_t *vendor)
+{
+	int err;
+	DECLARE_CALL(get_next_variable_name);
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+	call.u.get_next_variable_name.size = *name_size;
+	set_xen_guest_handle(call.u.get_next_variable_name.name, name);
+	BUILD_BUG_ON(sizeof(*vendor) !=
+		     sizeof(call.u.get_next_variable_name.vendor_guid));
+	memcpy(&call.u.get_next_variable_name.vendor_guid, vendor,
+	       sizeof(*vendor));
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*name_size = call.u.get_next_variable_name.size;
+	memcpy(vendor, &call.u.get_next_variable_name.vendor_guid,
+	       sizeof(*vendor));
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_set_variable(efi_char16_t *name,
+					 efi_guid_t *vendor,
+					 u32 attr,
+					 unsigned long data_size,
+					 void *data)
+{
+	DECLARE_CALL(set_variable);
+
+	set_xen_guest_handle(call.u.set_variable.name, name);
+	call.misc = attr;
+	BUILD_BUG_ON(sizeof(*vendor) !=
+		     sizeof(call.u.set_variable.vendor_guid));
+	memcpy(&call.u.set_variable.vendor_guid, vendor, sizeof(*vendor));
+	call.u.set_variable.size = data_size;
+	set_xen_guest_handle(call.u.set_variable.data, data);
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_query_variable_info(u32 attr,
+						u64 *storage_space,
+						u64 *remaining_space,
+						u64 *max_variable_size)
+{
+	int err;
+	DECLARE_CALL(query_variable_info);
+
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*storage_space = call.u.query_variable_info.max_store_size;
+	*remaining_space = call.u.query_variable_info.remain_store_size;
+	*max_variable_size = call.u.query_variable_info.max_size;
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_get_next_high_mono_count(u32 *count)
+{
+	int err;
+	DECLARE_CALL(get_next_high_monotonic_count);
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*count = call.misc;
+
+	return call.status;
+}
+
+static efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules,
+					   unsigned long count,
+					   unsigned long sg_list)
+{
+	DECLARE_CALL(update_capsule);
+
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+
+	set_xen_guest_handle(call.u.update_capsule.capsule_header_array,
+			     capsules);
+	call.u.update_capsule.capsule_count = count;
+	call.u.update_capsule.sg_list = sg_list;
+
+	return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status;
+}
+
+static efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t 
**capsules,
+					       unsigned long count,
+					       u64 *max_size,
+					       int *reset_type)
+{
+	int err;
+	DECLARE_CALL(query_capsule_capabilities);
+
+	if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION)
+		return EFI_UNSUPPORTED;
+
+	set_xen_guest_handle(call.u.query_capsule_capabilities.
+		capsule_header_array, capsules);
+	call.u.query_capsule_capabilities.capsule_count = count;
+
+	err = HYPERVISOR_dom0_op(&op);
+	if (err)
+		return EFI_UNSUPPORTED;
+
+	*max_size = call.u.query_capsule_capabilities.max_capsule_size;
+	*reset_type = call.u.query_capsule_capabilities.reset_type;
+
+	return call.status;
+}
+
+#undef DECLARE_CALL
+#undef call
+
+static void xen_efi_reset_system(int reset_type,
+                                 efi_status_t status,
+			         unsigned long data_size,
+	                         efi_char16_t *data)
+{
+	struct sched_shutdown r = { .reason = SHUTDOWN_reboot };
+
+	if (HYPERVISOR_sched_op(SCHEDOP_shutdown, &r))
+		BUG();
+}
+
+void __init xen_efi_probe(void)
+{
+	static struct xen_platform_op __initdata op = {
+		.cmd = XENPF_firmware_info,
+		.u.firmware_info = {
+			.type = XEN_FW_EFI_INFO,
+			.index = XEN_FW_EFI_CONFIG_TABLE
+		}
+	};
+
+	if (HYPERVISOR_dom0_op(&op) == 0) {
+		/* TODO: check return info */
+		set_bit(EFI_XEN, &x86_efi_facility);
+		set_bit(EFI_BOOT, &x86_efi_facility);
+		/* since hypervisor calls the runtime, 32/64 bit
+		 * EFI/kernel mismatch is not an issue.  Set to
+		 * match kernel so runtime calls will be made */
+#ifdef CONFIG_64BIT
+		set_bit(EFI_64BIT, &x86_efi_facility);
+#endif
+	}
+}
+
+
+void __init efi_init_xen(void)
+{
+	efi_char16_t c16[100];
+	char vendor[ARRAY_SIZE(c16)] = "unknown";
+	int ret, i;
+	struct xen_platform_op op;
+	union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+	/* redirect system to Xen hypercall implementation */
+	efi.systab                   = NULL,
+	efi.mps                      = EFI_INVALID_TABLE_ADDR;
+	efi.acpi                     = EFI_INVALID_TABLE_ADDR;
+	efi.acpi20                   = EFI_INVALID_TABLE_ADDR;
+	efi.smbios                   = EFI_INVALID_TABLE_ADDR;
+	efi.sal_systab               = EFI_INVALID_TABLE_ADDR;
+	efi.boot_info                = EFI_INVALID_TABLE_ADDR;
+	efi.hcdp                     = EFI_INVALID_TABLE_ADDR;
+	efi.uga                      = EFI_INVALID_TABLE_ADDR;
+	efi.uv_systab                = EFI_INVALID_TABLE_ADDR;
+	efi.get_time                 = xen_efi_get_time;
+	efi.set_time                 = xen_efi_set_time;
+	efi.get_wakeup_time          = xen_efi_get_wakeup_time;
+	efi.set_wakeup_time          = xen_efi_set_wakeup_time;
+	efi.get_variable             = xen_efi_get_variable;
+	efi.get_next_variable        = xen_efi_get_next_variable;
+	efi.set_variable             = xen_efi_set_variable;
+	efi.query_variable_info      = xen_efi_query_variable_info;
+	efi.update_capsule           = xen_efi_update_capsule;
+	efi.query_capsule_caps       = xen_efi_query_capsule_caps;
+	efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count;
+	efi.set_virtual_address_map  = NULL;
+	efi.reset_system             = xen_efi_reset_system;
+
+	/*
+	 * Show what we know for posterity
+	 */
+	op.cmd = XENPF_firmware_info;
+	op.u.firmware_info.type = XEN_FW_EFI_INFO;
+
+	op.u.firmware_info.index = XEN_FW_EFI_VENDOR;
+	info->vendor.bufsz = sizeof(c16);
+	set_xen_guest_handle(info->vendor.name, c16);
+	ret = HYPERVISOR_dom0_op(&op);
+	if (!ret) {
+		for (i = 0; i < sizeof(vendor) - 1 && c16[i]; ++i)
+			vendor[i] = c16[i];
+		vendor[i] = '\0';
+	} else
+		pr_err("Could not get the firmware vendor!\n");
+
+	op.u.firmware_info.index = XEN_FW_EFI_VERSION;
+	ret = HYPERVISOR_dom0_op(&op);
+	if (!ret)
+		pr_info("EFI-xen v%u.%.02u by %s\n",
+		       info->version >> 16,
+		       info->version & 0xffff, vendor);
+	else
+		pr_err("Could not get EFI revision!\n");
+
+	op.u.firmware_info.index = XEN_FW_EFI_RT_VERSION;
+	ret = HYPERVISOR_dom0_op(&op);
+	if (!ret)
+		efi.runtime_version = info->version;
+	else
+		pr_warn(PFX "Could not get runtime services revision.\n");
+	set_bit(EFI_RUNTIME_SERVICES, &x86_efi_facility);
+
+	/*
+	 * Let's see what config tables the firmware passed to us.
+	 */
+	op.u.firmware_info.index = XEN_FW_EFI_CONFIG_TABLE;
+	if (HYPERVISOR_dom0_op(&op))
+		BUG();
+
+	if (efi_config_init(info->cfg.addr, info->cfg.nent,
+	                    sizeof(efi_config_table_64_t)))
+		panic("Could not init EFI Configuration Tables!\n");
+	set_bit(EFI_CONFIG_TABLES, &x86_efi_facility);
+
+	/* the EFI memory info is digested by the hypervisor and
+	 * supplied to dom0 via E820 entries */
+	set_bit(EFI_MEMMAP, &x86_efi_facility);
+
+	set_bit(EFI_SYSTEM_TABLES, &x86_efi_facility); /* not checked */
+
+	/* NOTE: efi.c only does this for CONFIG_X86_32 */
+	x86_platform.get_wallclock = efi_get_time;
+	x86_platform.set_wallclock = efi_set_rtc_mmss;
+}
+
+/*
+ * Convenience functions to obtain memory types and attributes
+ */
+u32 efi_mem_type_xen(unsigned long phys_addr)
+{
+	struct xen_platform_op op;
+	union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+	op.cmd = XENPF_firmware_info;
+	op.u.firmware_info.type = XEN_FW_EFI_INFO;
+	op.u.firmware_info.index = XEN_FW_EFI_MEM_INFO;
+	info->mem.addr = phys_addr;
+	info->mem.size = 0;
+	return HYPERVISOR_dom0_op(&op) ? 0 : info->mem.type;
+}
+
+u64 efi_mem_attributes_xen(unsigned long phys_addr)
+{
+	struct xen_platform_op op;
+	union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info;
+
+	op.cmd = XENPF_firmware_info;
+	op.u.firmware_info.type = XEN_FW_EFI_INFO;
+	op.u.firmware_info.index = XEN_FW_EFI_MEM_INFO;
+	info->mem.addr = phys_addr;
+	info->mem.size = 0;
+	return HYPERVISOR_dom0_op(&op) ? 0 : info->mem.attr;
+}
+
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 193097e..51edc64 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -32,6 +32,7 @@
  #include <linux/gfp.h>
  #include <linux/memblock.h>
  #include <linux/edd.h>
+#include <linux/efi.h>

  #include <xen/xen.h>
  #include <xen/events.h>
@@ -1342,15 +1343,6 @@ int xen_panic_handler_init(void)
  	return 0;
  }

-static const struct machine_ops xen_machine_ops __initconst = {
-	.restart = xen_restart,
-	.halt = xen_machine_halt,
-	.power_off = xen_machine_power_off,
-	.shutdown = xen_machine_halt,
-	.crash_shutdown = xen_crash_shutdown,
-	.emergency_restart = xen_emergency_restart,
-};
-
  static void __init xen_boot_params_init_edd(void)
  {
  #if IS_ENABLED(CONFIG_EDD)
@@ -1493,7 +1485,12 @@ asmlinkage void __init xen_start_kernel(void)
  		pv_mmu_ops.ptep_modify_prot_commit = xen_ptep_modify_prot_commit;
  	}

-	machine_ops = xen_machine_ops;
+	machine_ops.restart = xen_restart;
+	machine_ops.halt = xen_machine_halt;
+	machine_ops.power_off = xen_machine_power_off;
+	machine_ops.shutdown = xen_machine_halt;
+	machine_ops.crash_shutdown = xen_crash_shutdown;
+	machine_ops.emergency_restart = xen_emergency_restart;

  	/*
  	 * The only reliable way to retain the initial address of the
@@ -1613,6 +1610,11 @@ asmlinkage void __init xen_start_kernel(void)

  	xen_setup_runstate_info(0);

+#ifdef CONFIG_EFI
+	if (xen_initial_domain())
+		xen_efi_probe();
+#endif
+
  	/* Start the world */
  #ifdef CONFIG_X86_32
  	i386_start_kernel();
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 5f8f176..2781dea 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -84,7 +84,10 @@ typedef	struct {
  #define EFI_PAL_CODE			13
  #define EFI_MAX_MEMORY_TYPE		14

+#define EFI_INVALID_TYPE		0xffffffff
+
  /* Attribute values: */
+#define EFI_INVALID_ATTRIBUTE	((u64)0x0000000000000000ULL)	/* invalid 
attribute */
  #define EFI_MEMORY_UC		((u64)0x0000000000000001ULL)	/* uncached */
  #define EFI_MEMORY_WC		((u64)0x0000000000000002ULL)	/* write-coalescing */
  #define EFI_MEMORY_WT		((u64)0x0000000000000004ULL)	/* write-through */
@@ -597,6 +600,10 @@ extern void efi_initialize_iomem_resources(struct 
resource *code_resource,
  extern void efi_get_time(struct timespec *now);
  extern int efi_set_rtc_mmss(const struct timespec *now);
  extern void efi_reserve_boot_services(void);
+#ifdef CONFIG_XEN
+extern int __init efi_config_init(u64 tables, int nr_tables, int entrySz);
+extern void xen_efi_probe(void);
+#endif
  extern struct efi_memory_map memmap;

  /**
@@ -634,6 +641,7 @@ extern int __init efi_setup_pcdp_console(char *);
  #define EFI_RUNTIME_SERVICES	3	/* Can we use runtime services? */
  #define EFI_MEMMAP		4	/* Can we use EFI memory map? */
  #define EFI_64BIT		5	/* Is the firmware 64-bit? */
+#define EFI_XEN			6	/* Must we access EFI via Xen? */

  #ifdef CONFIG_EFI
  # ifdef CONFIG_X86
diff --git a/include/xen/interface/platform.h 
b/include/xen/interface/platform.h
index c57d5f6..d005f0b 100644
--- a/include/xen/interface/platform.h
+++ b/include/xen/interface/platform.h
@@ -108,10 +108,111 @@ struct xenpf_platform_quirk {
  };
  DEFINE_GUEST_HANDLE_STRUCT(xenpf_platform_quirk_t);

+#define XENPF_efi_runtime_call    49
+#define XEN_EFI_get_time                      1
+#define XEN_EFI_set_time                      2
+#define XEN_EFI_get_wakeup_time               3
+#define XEN_EFI_set_wakeup_time               4
+#define XEN_EFI_get_next_high_monotonic_count 5
+#define XEN_EFI_get_variable                  6
+#define XEN_EFI_set_variable                  7
+#define XEN_EFI_get_next_variable_name        8
+#define XEN_EFI_query_variable_info           9
+#define XEN_EFI_query_capsule_capabilities   10
+#define XEN_EFI_update_capsule               11
+
+struct xenpf_efi_runtime_call {
+	uint32_t function;
+    /*
+     * This field is generally used for per sub-function flags (defined
+     * below), except for the XEN_EFI_get_next_high_monotonic_count case,
+     * where it holds the single returned value.
+     */
+	uint32_t misc;
+	unsigned long status;
+	union {
+#define XEN_EFI_GET_TIME_SET_CLEARS_NS 0x00000001
+	struct {
+		struct xenpf_efi_time {
+			uint16_t year;
+			uint8_t month;
+			uint8_t day;
+			uint8_t hour;
+			uint8_t min;
+			uint8_t sec;
+			uint32_t ns;
+			int16_t tz;
+			uint8_t daylight;
+		} time;
+		uint32_t resolution;
+		uint32_t accuracy;
+	} get_time;
+
+	struct xenpf_efi_time set_time;
+
+#define XEN_EFI_GET_WAKEUP_TIME_ENABLED 0x00000001
+#define XEN_EFI_GET_WAKEUP_TIME_PENDING 0x00000002
+	struct xenpf_efi_time get_wakeup_time;
+
+#define XEN_EFI_SET_WAKEUP_TIME_ENABLE      0x00000001
+#define XEN_EFI_SET_WAKEUP_TIME_ENABLE_ONLY 0x00000002
+	struct xenpf_efi_time set_wakeup_time;
+
+#define XEN_EFI_VARIABLE_NON_VOLATILE       0x00000001
+#define XEN_EFI_VARIABLE_BOOTSERVICE_ACCESS 0x00000002
+#define XEN_EFI_VARIABLE_RUNTIME_ACCESS     0x00000004
+	struct {
+		GUEST_HANDLE(void) name;  /* UCS-2/UTF-16 string */
+		unsigned long size;
+		GUEST_HANDLE(void) data;
+		struct xenpf_efi_guid {
+			uint32_t data1;
+			uint16_t data2;
+			uint16_t data3;
+			uint8_t data4[8];
+			} vendor_guid;
+		} get_variable, set_variable;
+
+	struct {
+		unsigned long size;
+		GUEST_HANDLE(void) name;  /* UCS-2/UTF-16 string */
+		struct xenpf_efi_guid vendor_guid;
+		} get_next_variable_name;
+
+	struct {
+		uint32_t attr;
+		uint64_t max_store_size;
+		uint64_t remain_store_size;
+		uint64_t max_size;
+		} query_variable_info;
+
+	struct {
+		GUEST_HANDLE(void) capsule_header_array;
+		unsigned long capsule_count;
+		uint64_t max_capsule_size;
+		unsigned int reset_type;
+		} query_capsule_capabilities;
+
+	struct {
+		GUEST_HANDLE(void) capsule_header_array;
+		unsigned long capsule_count;
+		uint64_t sg_list; /* machine address */
+		} update_capsule;
+	} u;
+};
+DEFINE_GUEST_HANDLE_STRUCT(xenpf_efi_runtime_call);
+
  #define XENPF_firmware_info       50
  #define XEN_FW_DISK_INFO          1 /* from int 13 AH=08/41/48 */
  #define XEN_FW_DISK_MBR_SIGNATURE 2 /* from MBR offset 0x1b8 */
  #define XEN_FW_VBEDDC_INFO        3 /* from int 10 AX=4f15 */
+#define XEN_FW_EFI_INFO           4 /* from EFI */
+#define  XEN_FW_EFI_VERSION        0
+#define  XEN_FW_EFI_CONFIG_TABLE   1
+#define  XEN_FW_EFI_VENDOR         2
+#define  XEN_FW_EFI_MEM_INFO       3
+#define  XEN_FW_EFI_RT_VERSION     4
+#define  XEN_FW_EFI_PCI_ROM        5
  #define XEN_FW_KBD_SHIFT_FLAGS    5 /* Int16, Fn02: Get keyboard shift 
flags. */
  struct xenpf_firmware_info {
  	/* IN variables. */
@@ -143,6 +244,36 @@ struct xenpf_firmware_info {
  			/* must refer to 128-byte buffer */
  			GUEST_HANDLE(uchar) edid;
  		} vbeddc_info; /* XEN_FW_VBEDDC_INFO */
+		union xenpf_efi_info {
+			uint32_t version;
+			struct {
+				uint64_t addr;   /* EFI_CONFIGURATION_TABLE */
+				uint32_t nent;
+			} cfg;
+			struct {
+				uint32_t revision;
+				uint32_t bufsz;  /* input, in bytes */
+				GUEST_HANDLE(void) name;
+				/* UCS-2/UTF-16 string */
+				} vendor;
+			struct {
+				uint64_t addr;
+				uint64_t size;
+				uint64_t attr;
+				uint32_t type;
+				} mem;
+			struct {
+				/* IN variables */
+				uint16_t segment;
+				uint8_t bus;
+				uint8_t devfn;
+				uint16_t vendor;
+				uint16_t devid;
+				/* OUT variables */
+				uint64_t address;
+				xen_ulong_t size;
+				} pci_rom;
+		} efi_info; /* XEN_FW_EFI_INFO */

  		uint8_t kbd_shift_flags; /* XEN_FW_KBD_SHIFT_FLAGS */
  	} u;
@@ -361,6 +492,7 @@ struct xen_platform_op {
  		struct xenpf_read_memtype      read_memtype;
  		struct xenpf_microcode_update  microcode;
  		struct xenpf_platform_quirk    platform_quirk;
+		struct xenpf_efi_runtime_call  efi_runtime_call;
  		struct xenpf_firmware_info     firmware_info;
  		struct xenpf_enter_acpi_sleep  enter_acpi_sleep;
  		struct xenpf_change_freq       change_freq;
-- 
1.8.3.4

Re: Xen 4.4 development update

[Daniel Kiper]

On Thu, Aug 08, 2013 at 04:51:51PM -0400, Eric Shelton wrote:
> On Thu, Aug 8, 2013 at 3:55 PM, Konrad Rzeszutek Wilk
> <konrad.wilk@oracle.com> wrote:
> . . .
> > Rework them. The maintainer would like it done differently - that was my
> > recollection last year when I chatted with him (Matthew Garret).
> >
> > Daniel will know more - but he is right now making multiboot2 work with
> > Xen and then attacking this.
>
> Back then (https://lkml.org/lkml/2012/2/9/299), Matthew said:
>
> > Hm. Is there absolutely no way to do this by replacing efi_call_*? It'd
> > really be nice to avoid yet another set of duplicate functions here -
> > the ia64/x86 situation is already bad enough. Ideally this would be
> > sufficiently generic that arm can also plug into it.
>
> It looks like the arm patches are just now nearing commit worthiness,
> with V2 just posted a couple of days ago:
>
> https://lkml.org/lkml/2013/8/6/584
>
> It looks like Garrett's goal of merging arm and x86 EFI code is being
> realized, and that I will need to refactor my patchset to keep up with
> these changes.  Roy Franz seems to be doing the heavy lifting on arm
> EFI, with Matt Fleming serving as the maintainer.

I have not dug very deep but it looks that it is only EFI loader
patch series (called stub in Linux Kernel). It is not related to
Xen EFI stuff in Linux Kernel.

> Related to this, is the Xen hypervisor booting under EFI for arm
> already?  I assume not, if Linux currently lacks the needed
> hypercalls.  Does anything arm-specific need to happen in an
> EFI-friendly dom0 kernel, given that it is hypercall driven?  Is there
> a platform for test?

IIRC there is no EFI support in Xen on ARM. However, you should ask
Stefano and/or Ian Campbell for more details. They are ARM maintainers
for Xen.

As Konrad said I am working on multiboot2 protocol support for Xen.
It is needed to load Xen from e.g. GRUB2 loader on EFI platforms.
I would like to finish this first because there are some interests
in that project. Then I will be working on EFI support for Xen
in Linux Kernel. However, if you like to work on this stuff go
ahead. I do no have any objections. Just drop me line then I would
not duplicate your efforts.

Daniel

Re: Xen 4.4 development update

[Eric Shelton]

On Thu, Aug 8, 2013 at 3:55 PM, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> wrote:
. . .
> Rework them. The maintainer would like it done differently - that was my
> recollection last year when I chatted with him (Matthew Garret).
>
> Daniel will know more - but he is right now making multiboot2 work with
> Xen and then attacking this.

Back then (https://lkml.org/lkml/2012/2/9/299), Matthew said:

> Hm. Is there absolutely no way to do this by replacing efi_call_*? It'd
> really be nice to avoid yet another set of duplicate functions here -
> the ia64/x86 situation is already bad enough. Ideally this would be
> sufficiently generic that arm can also plug into it.

It looks like the arm patches are just now nearing commit worthiness,
with V2 just posted a couple of days ago:

https://lkml.org/lkml/2013/8/6/584

It looks like Garrett's goal of merging arm and x86 EFI code is being
realized, and that I will need to refactor my patchset to keep up with
these changes.  Roy Franz seems to be doing the heavy lifting on arm
EFI, with Matt Fleming serving as the maintainer.

Related to this, is the Xen hypervisor booting under EFI for arm
already?  I assume not, if Linux currently lacks the needed
hypercalls.  Does anything arm-specific need to happen in an
EFI-friendly dom0 kernel, given that it is hypercall driven?  Is there
a platform for test?

- Eric

Re: Xen 4.4 development update

[Konrad Rzeszutek Wilk]

On Thu, Aug 08, 2013 at 03:38:58PM -0400, Eric Shelton wrote:
> > * Xen EFI feature: pvops dom0 able to make use of EFI run-time
> > services (external)
> >  owner: Daniel Kiper
> >  status: Just begun
> 
> I think this is addressed, maybe in full, by this patchset, presented
> in the midst of getting 4.3 in order:
> 
> http://lists.xen.org/archives/html/xen-devel/2013-05/msg02492.html
> 
> I have used this for the last 3 months.  The noted i915 issue was
> resolved by later updates to the kernel or X driver, as 3.10.1 is
> running smoothly.  The only issue I have observed is that although Xen
> correctly powers off the system in response to a dom0-initiated
> shutdown, Xen is not currently rebooting - I have to let the system
> wind down and then do a power cycle.
> 
> The patchset is an update to a set originally submitted by Tang Liang,
> which I gather was based on work done by Suse.  Given that the patches
> are 100% kernel-side (the Xen code was put in place some time ago),
> what needs to be done for acceptance by the LKML folks?

Rework them. The maintainer would like it done differently - that was my
recollection last year when I chatted with him (Matthew Garret).

Daniel will know more - but he is right now making multiboot2 work with
Xen and then attacking this.

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

Re: Xen 4.4 development update

[Eric Shelton]

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

I think this is addressed, maybe in full, by this patchset, presented
in the midst of getting 4.3 in order:

http://lists.xen.org/archives/html/xen-devel/2013-05/msg02492.html

I have used this for the last 3 months.  The noted i915 issue was
resolved by later updates to the kernel or X driver, as 3.10.1 is
running smoothly.  The only issue I have observed is that although Xen
correctly powers off the system in response to a dom0-initiated
shutdown, Xen is not currently rebooting - I have to let the system
wind down and then do a power cycle.

The patchset is an update to a set originally submitted by Tang Liang,
which I gather was based on work done by Suse.  Given that the patches
are 100% kernel-side (the Xen code was put in place some time ago),
what needs to be done for acceptance by the LKML folks?

- Eric