Xen devel - Jan 2013 - Xen 4.3 development update, and stock-taking

Below is a summary of the projects / features being worked on for the 4.3
time frame.  The tentative feature freeze is scheduled for 25 March, which
is just over 2 months away.  With that in mind, I think it''s time to
take
stock of the development, so we know whether to ask for more help or divert
resources.

To that end, I''ve added a line called "prognosis", indicating
the
likelihood of completion in the 4.3 timeframe.  For items involving code
hosted on the Xen.org site (including qemu-xen), that means a likelihood of
having the feature code-complete and mostly working by the feature freeze.
(It''s OK if there are still bugs to be worked out.)  For items in
Linux, I
think it would mean having items on track to make it into the kernel
released just after the scheduled 4.3 time frame.  Not sure what that means
for libvirt. :-)

I''ve given ratings to projects that I thought I had some insight on,
but I
would appreciate if everyone could review these and let me know if
they''re
not accurate.

I''d particularly appreciate it if the people listed below could give
prognoses on the project listed.

Meanings of prognoses:
- Excellent: It would be very unlikely for this not to be finished in time.
- Good: Everything is on track, and is likely to make it.
- Fair: A pretty good chance of making it, but not as certain
- Poor: Likely not to make it unless intervention is made
- Not for 4.3: self-explanatory

Mukesh Rathor: PVH

Wei: Event channel scalability

Daniel de Graaf: IS_PRIV->XSM

Roger Pau Monne: Persistent blk grants, openvswitch integration, backend
scripts

Konrad Wilk: Persistent net grants, multi-page network, multi-page blk

Jim Fehlig: libvirt migration support

Matthew Fioravante: vTPM

Stefano Panella: PV Audio

Igor Kozhukov: IllumOS support

Once we know what items are "at risk", we can list them and decide
what to
do about it.

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

= Timeline 
We are planning on a 9-month release cycle.  Based on that, below are
our estimated dates:
* Feature Freeze: 25 March 2013
* First RC: 6 May 2013
* Release: 17 June 2013

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

= Feature tracking 
Below is a list of features we''re tracking for this release. Please
respond to this mail with any updates to the status.

There are a number of items whose owners are marked as "?".  If you
are working on this, or know who is working on it, please respond and
let me know.  Alternately, if you would *like* to work on it, please
let me know as well.

And if there is something you''re working on you''d like
tracked, please
respond, and I will add it to the list.

NB: Several of the items on this list are from external projects:
linux, qemu, and libvirt.  These are not part of the Xen tree, but are
directly related to our users'' experience (e.g., work in Linux or
qemu) or to integration with other important projects (e.g., libvirt
bindings).  Since all of these are part of the Xen community work, and
comes from the same pool of labor, it makes sense to track the
progress here, even though they won''t explicitly be released as part
of 4.3.

Meanings of prognoses:
- Excellent: It would be very unlikely for this not to be finished in time.
- Good: Everything is on track, and is likely to make it.
- Fair: A pretty good chance of making it, but not as certain
- Poor: Likely not to make it unless intervention is made

== Completed =
* Serial console improvements
  -EHCI debug port

* Default to QEMU upstream (partial)
 - pci pass-thru (external)
 - enable dirtybit tracking during migration (external)
 - xl cd-{insert,eject} (external)

* CPUID-based idle (don''t rely on ACPI info f/ dom0)

== Bugs =
* xl, compat mode, and older kernels
  owner: ?
  Many older 32-bit PV kernels that can run on a 64-bit hypervisor with
  xend do not work when started with xl.  The following work-around seems to
  work:
    xl create -p lightning.cfg
    xenstore-write /local/domain/$(xl domid
lightning)/device/vbd/51713/protocol x86_32-abi
    xl unpause lightning
  This node is normally written by the guest kernel, but for older kernels
  seems not to be.  xend must have a work-around; port this work-around to
xl.

== Not yet complete =
* PVH mode (w/ Linux)
  owner: mukesh@oracle
  status (Linux): 3rd draft patches posted.
  status (Xen): RFC submitted
  prognosis: Good

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

* ARM v7 server port
  owner: ijc@citrix
  prognosis: Excellent
  status: Core hypervisor and Linux patches accepted.  Tools patches
submitted.

* ARM v8 server port (tech preview)
  owner: ijc@citrix
  status: ?
  prognosis: Tech preview only

* NUMA scheduler affinity
  critical
  owner: dario@citrix
  status: Patches posted
  prognosis: Excellent

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

* blktap3
  owner: thanos@citrix
  status: RFCs posted
  prognosis: Not for 4.3

* Default to QEMU upstream
 > Add "intel-hda" to xmexample file, since it works with 64-bit
Win7/8
 - qemu-based stubdom (Linux or BSD libc)
   owner: anthony@citrix
   status: in progress
   prognosis: ?
   qemu-upstream needs a more fully-featured libc than exists in
   mini-os.  Either work on a minimalist linux-based stubdom with
   glibc, or port one of the BSD libcs to minios.

* Persistent grants for blk (external)
  owner: roger.pau@citrix
  status: Initial implementation posted
  prognosis: ?

* Persistent grants for net
  owner: annie.li@citrix
  status: Initial implementation posted
  prognosis: ?

* Multi-page blk rings (external)
 - blkback in kernel (konrad@oracle, ?@intel)
 - qemu blkback
  status: Not started.
  prognosis: UNKNOWN

* Multi-page net protocol (external)
  owner: ijc@citrix or annie.li@oracle
  status: Initial patches posted (by Wei Liu)
  expand the network ring protocol to allow multiple pages for
  increased throughput

* Scalability: 16TiB of RAM
  owner: jan@suse
  status: Not started

* vTPM updates
  owner: Matthew Fioravante @ Johns Hopkins
  prognosis: Good
  status: some patches submitted, more in progress
  - Allow all vTPM components to run in stub domains for increased security
  - Update vtpm to 0.7.1 from 0.5.x

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

* libvirt/libxl integration (external)
 - Update libvirt to 4.2
   status: Patch accepted
 - Migration
   owner: cyliu@suse (?)
   status: first draft implemented, not yet submitted
   prognosis: ?
 - Itemize other things that need work
   To begin with, we need someone to go and make some lists:
   - Features available in libvirt/KVM not available in libvirt/libxl
     See http://libvirt.org/hvsupport.html
   - Features available in xl/Xen but not available in libvirt/Xen

* Allow XSM to override IS_PRIV checks in the hypervisor
  owner: Daniel De Graaf
  status: patches against 4.3-unstable posted, awaiting approval
  prognosis: Good
  This makes it possible to allow some user domains limited access to
  dom0-only hypercalls. This could be used to allow a user-created
  toolstack domain to administer its own set of VMs instead of relying
  on dom0''s toolstack.

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

* Wait queues for mm
  owner: ?
  status: Draft posted Feb 2012; more work to do.
  prognosis: Poor

* xl PVUSB pass-through for both PV and HVM guests
  owner: George
  status: ?
  prognosis: Fair
  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.

* xl USB pass-through for HVM guests using Qemu USB emulation
  owner: George
  status: Config file pass-through submitted.
  prognosis: Good
  xm/xend with qemu-traditional supports USB passthrough to HVM guests
using the Qemu emulated USB controller.
  The HVM guest does not need any special drivers for this feature.
  So basicly the qemu cmdline needs to have:
     -usb -usbdevice host:xxxx:yyyy
  - port the xm/xend functionality to xl.
  - make sure USB passthrough with xl works with both qemu-traditional and
qemu-upstream.

* xl QXL Spice support
  owner: Zhou Peng
  prognosis: Fair
  status: Patches against 4.3-unstable posted, awaiting approval

* Remove hardcoded mobprobe''s in xencommons
  owner: ?
  status: ?
  prognosis: Poor.

* openvswitch toostack integration
  owner: roger@citrix
  prognosis: ?
  status: Sample script posted by Bastian ("[RFC] openvswitch support
script")

* Rationalized backend scripts (incl. driver domains)
  owner: roger@citrix
  status: patches submitted
  prognosis: Good

* Xen EFI boot
 - Signature checking for dom0 kernel / initrd?
 status: No owner.
 prognosis: Probably not for 4.4

* Serial console improvements
  owner: ?
  status: Stalled (see below)
  prognosis: Probably not for 4.4.
  -xHCI debug port (Needs hardware)
  -Firewire (needs hardware)

* Make storage migration possible
  owner: ?
  status: none
  prognosis: Probably delay until 4.4
  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
  prognosis: Probably delay until 4.4
  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
  prognosis: Probably need 4.4
  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
  prognosis: Prob put off until 4.4 (or GSoC project)
  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
  prognosis: Prob put off until 4.4

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

* IllumOS support
  owner: Igor Kozhukov
  status: In progress
  prognosis: ?


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

On 01/16/2013 12:55 PM, George Dunlap wrote:
> Below is a summary of the projects / features being worked on for the 
> 4.3 time frame.  The tentative feature freeze is scheduled for 25 
> March, which is just over 2 months away.  With that in mind, I think 
> it''s time to take stock of the development, so we know whether to
ask
> for more help or divert resources.
>
> To that end, I''ve added a line called "prognosis",
indicating the
> likelihood of completion in the 4.3 timeframe.  For items involving 
> code hosted on the Xen.org site (including qemu-xen), that means a 
> likelihood of having the feature code-complete and mostly working by 
> the feature freeze.  (It''s OK if there are still bugs to be worked
> out.)  For items in Linux, I think it would mean having items on track 
> to make it into the kernel released just after the scheduled 4.3 time 
> frame.  Not sure what that means for libvirt. :-)
>
> I''ve given ratings to projects that I thought I had some insight
on,
> but I would appreciate if everyone could review these and let me know 
> if they''re not accurate.
>
> I''d particularly appreciate it if the people listed below could
give
> prognoses on the project listed.
>
> Meanings of prognoses:
> - Excellent: It would be very unlikely for this not to be finished in 
> time.
> - Good: Everything is on track, and is likely to make it.
> - Fair: A pretty good chance of making it, but not as certain
> - Poor: Likely not to make it unless intervention is made
> - Not for 4.3: self-explanatory
>
> Mukesh Rathor: PVH
>
> Wei: Event channel scalability
>
> Daniel de Graaf: IS_PRIV->XSM
>
> Roger Pau Monne: Persistent blk grants, openvswitch integration, 
> backend scripts
>
> Konrad Wilk: Persistent net grants, multi-page network, multi-page blk
>
> Jim Fehlig: libvirt migration support
>
> Matthew Fioravante: vTPM
vTPM should be ready for next release, we just have one minor issue to 
workout with the configure scripts. So I agree with your prognosis of 
"Good".
>
> Stefano Panella: PV Audio
>
> Igor Kozhukov: IllumOS support
>
> Once we know what items are "at risk", we can list them and
decide
> what to do about it.
>
> This information will be mirrored on the Xen 4.3 Roadmap wiki page:
> http://wiki.xen.org/wiki/Xen_Roadmap/4.3
>
> = Timeline >
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
> * Feature Freeze: 25 March 2013
> * First RC: 6 May 2013
> * Release: 17 June 2013
>
> The RCs and release will of course depend on stability and bugs, and
> will therefore be fairly unpredictable.  The feature freeze may be
> slipped for especially important features which are near completion.
>
> = Feature tracking >
> Below is a list of features we''re tracking for this release.
Please
> respond to this mail with any updates to the status.
>
> There are a number of items whose owners are marked as "?".  If
you
> are working on this, or know who is working on it, please respond and
> let me know.  Alternately, if you would *like* to work on it, please
> let me know as well.
>
> And if there is something you''re working on you''d like
tracked, please
> respond, and I will add it to the list.
>
> NB: Several of the items on this list are from external projects:
> linux, qemu, and libvirt.  These are not part of the Xen tree, but are
> directly related to our users'' experience (e.g., work in Linux or
> qemu) or to integration with other important projects (e.g., libvirt
> bindings).  Since all of these are part of the Xen community work, and
> comes from the same pool of labor, it makes sense to track the
> progress here, even though they won''t explicitly be released as
part
> of 4.3.
>
> Meanings of prognoses:
> - Excellent: It would be very unlikely for this not to be finished in 
> time.
> - Good: Everything is on track, and is likely to make it.
> - Fair: A pretty good chance of making it, but not as certain
> - Poor: Likely not to make it unless intervention is made
>
> == Completed =>
> * Serial console improvements
>   -EHCI debug port
>
> * Default to QEMU upstream (partial)
>  - pci pass-thru (external)
>  - enable dirtybit tracking during migration (external)
>  - xl cd-{insert,eject} (external)
>
> * CPUID-based idle (don''t rely on ACPI info f/ dom0)
>
> == Bugs =>
> * xl, compat mode, and older kernels
>   owner: ?
>   Many older 32-bit PV kernels that can run on a 64-bit hypervisor with
>   xend do not work when started with xl.  The following work-around 
> seems to
>   work:
>     xl create -p lightning.cfg
>     xenstore-write /local/domain/$(xl domid 
> lightning)/device/vbd/51713/protocol x86_32-abi
>     xl unpause lightning
>   This node is normally written by the guest kernel, but for older kernels
>   seems not to be.  xend must have a work-around; port this 
> work-around to xl.
>
> == Not yet complete =>
> * PVH mode (w/ Linux)
>   owner: mukesh@oracle
>   status (Linux): 3rd draft patches posted.
>   status (Xen): RFC submitted
>   prognosis: Good
>
> * Event channel scalability
>   owner: wei@citrix
>   status: RFC submitted
>   prognosis: Good
>   Increase limit on event channels (currently 1024 for 32-bit guests,
>   4096 for 64-bit guests)
>
> * ARM v7 server port
>   owner: ijc@citrix
>   prognosis: Excellent
>   status: Core hypervisor and Linux patches accepted. Tools patches 
> submitted.
>
> * ARM v8 server port (tech preview)
>   owner: ijc@citrix
>   status: ?
>   prognosis: Tech preview only
>
> * NUMA scheduler affinity
>   critical
>   owner: dario@citrix
>   status: Patches posted
>   prognosis: Excellent
>
> * NUMA Memory migration
>   owner: dario@citrix
>   status: in progress
>   prognosis: Fair
>
> * blktap3
>   owner: thanos@citrix
>   status: RFCs posted
>   prognosis: Not for 4.3
>
> * Default to QEMU upstream
>  > Add "intel-hda" to xmexample file, since it works with
64-bit Win7/8
>  - qemu-based stubdom (Linux or BSD libc)
>    owner: anthony@citrix
>    status: in progress
>    prognosis: ?
>    qemu-upstream needs a more fully-featured libc than exists in
>    mini-os.  Either work on a minimalist linux-based stubdom with
>    glibc, or port one of the BSD libcs to minios.
>
> * Persistent grants for blk (external)
>   owner: roger.pau@citrix
>   status: Initial implementation posted
>   prognosis: ?
>
> * Persistent grants for net
>   owner: annie.li@citrix
>   status: Initial implementation posted
>   prognosis: ?
>
> * Multi-page blk rings (external)
>  - blkback in kernel (konrad@oracle, ?@intel)
>  - qemu blkback
>   status: Not started.
>   prognosis: UNKNOWN
>
> * Multi-page net protocol (external)
>   owner: ijc@citrix or annie.li@oracle
>   status: Initial patches posted (by Wei Liu)
>   expand the network ring protocol to allow multiple pages for
>   increased throughput
>
> * Scalability: 16TiB of RAM
>   owner: jan@suse
>   status: Not started
>
> * vTPM updates
>   owner: Matthew Fioravante @ Johns Hopkins
>   prognosis: Good
>   status: some patches submitted, more in progress
>   - Allow all vTPM components to run in stub domains for increased 
> security
>   - Update vtpm to 0.7.1 from 0.5.x
Say this:
- New vtpm domain uses tpm_emulator 0.7.4.
The old vtpmd was not upgraded, it was deprecated and removed
entirely.
>
> * Guest EFI booting
>  - status: tianocore in-tree, some build problems.
>    prognosis: Poor.
>    Needs new owner.
>
> * libvirt/libxl integration (external)
>  - Update libvirt to 4.2
>    status: Patch accepted
>  - Migration
>    owner: cyliu@suse (?)
>    status: first draft implemented, not yet submitted
>    prognosis: ?
>  - Itemize other things that need work
>    To begin with, we need someone to go and make some lists:
>    - Features available in libvirt/KVM not available in libvirt/libxl
>      See http://libvirt.org/hvsupport.html
>    - Features available in xl/Xen but not available in libvirt/Xen
>
> * Allow XSM to override IS_PRIV checks in the hypervisor
>   owner: Daniel De Graaf
>   status: patches against 4.3-unstable posted, awaiting approval
>   prognosis: Good
>   This makes it possible to allow some user domains limited access to
>   dom0-only hypercalls. This could be used to allow a user-created
>   toolstack domain to administer its own set of VMs instead of relying
>   on dom0''s toolstack.
>
> * V4V: Inter-domain communication
>   owner (Xen): jean.guyader@citrix.com
<mailto:jean.guyader@citrix.com>
>   status (Xen): patches submitted
>   prognosis: ?
>   owner (Linux driver):  stefano.panella@citrix
>   status (Linux driver): in progress
>
> * Wait queues for mm
>   owner: ?
>   status: Draft posted Feb 2012; more work to do.
>   prognosis: Poor
>
> * xl PVUSB pass-through for both PV and HVM guests
>   owner: George
>   status: ?
>   prognosis: Fair
>   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.
>
> * xl USB pass-through for HVM guests using Qemu USB emulation
>   owner: George
>   status: Config file pass-through submitted.
>   prognosis: Good
>   xm/xend with qemu-traditional supports USB passthrough to HVM guests 
> using the Qemu emulated USB controller.
>   The HVM guest does not need any special drivers for this feature.
>   So basicly the qemu cmdline needs to have:
>      -usb -usbdevice host:xxxx:yyyy
>   - port the xm/xend functionality to xl.
>   - make sure USB passthrough with xl works with both qemu-traditional 
> and qemu-upstream.
>
> * xl QXL Spice support
>   owner: Zhou Peng
>   prognosis: Fair
>   status: Patches against 4.3-unstable posted, awaiting approval
>
> * Remove hardcoded mobprobe''s in xencommons
>   owner: ?
>   status: ?
>   prognosis: Poor.
>
> * openvswitch toostack integration
>   owner: roger@citrix
>   prognosis: ?
>   status: Sample script posted by Bastian ("[RFC] openvswitch support 
> script")
>
> * Rationalized backend scripts (incl. driver domains)
>   owner: roger@citrix
>   status: patches submitted
>   prognosis: Good
>
> * Xen EFI boot
>  - Signature checking for dom0 kernel / initrd?
>  status: No owner.
>  prognosis: Probably not for 4.4
>
> * Serial console improvements
>   owner: ?
>   status: Stalled (see below)
>   prognosis: Probably not for 4.4.
>   -xHCI debug port (Needs hardware)
>   -Firewire (needs hardware)
>
> * Make storage migration possible
>   owner: ?
>   status: none
>   prognosis: Probably delay until 4.4
>   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
>   prognosis: Probably delay until 4.4
>   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
>   prognosis: Probably need 4.4
>   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
>   prognosis: Prob put off until 4.4 (or GSoC project)
>   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
>   prognosis: Prob put off until 4.4
>
> * PV audio (audio for stubdom qemu)
>   owner: stefano.panella@citrix
>   status: ?
>   prognosis: ?
>
> * IllumOS support
>   owner: Igor Kozhukov
>   status: In progress
>   prognosis: ?
>



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

On Wed, 2013-01-16 at 17:55 +0000, George Dunlap wrote:
> Below is a summary of the projects / features being worked on for the
> 4.3 time frame.  The tentative feature freeze is scheduled for 25
> March, which is just over 2 months away.  With that in mind, I think
> it''s time to take stock of the development, so we know whether to
ask
> for more help or divert resources.
> 
> To that end, I''ve added a line called "prognosis",
indicating the
> likelihood of completion in the 4.3 timeframe.  For items involving
> code hosted on the Xen.org site (including qemu-xen), that means a
> likelihood of having the feature code-complete and mostly working by
> the feature freeze.  (It''s OK if there are still bugs to be worked
> out.)  For items in Linux, I think it would mean having items on track
> to make it into the kernel released just after the scheduled 4.3 time
> frame.  Not sure what that means for libvirt. :-)
> 
> 
> I''ve given ratings to projects that I thought I had some insight
on,
> but I would appreciate if everyone could review these and let me know
> if they''re not accurate.
> 
> 
> I''d particularly appreciate it if the people listed below could
give
> prognoses on the project listed.
> 
> Meanings of prognoses:
> - Excellent: It would be very unlikely for this not to be finished in
> time.
> - Good: Everything is on track, and is likely to make it.
> - Fair: A pretty good chance of making it, but not as certain
> - Poor: Likely not to make it unless intervention is made
> 
> - Not for 4.3: self-explanatory
> 
> 
> 
> Mukesh Rathor: PVH
> 
> 
> Wei: Event channel scalability
> 
> 
I think I will rate my project as Good. Will send another RFC seires
(hopefully two) by the end of this month. But this is my first time to
estimate a real world project though.


Wei.

>>> On 16.01.13 at 18:55, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> * Persistent grants for blk (external)
>   owner: roger.pau@citrix
>   status: Initial implementation posted
>   prognosis: ?
I think this went into 3.8-rc.
> * Scalability: 16TiB of RAM
>   owner: jan@suse
>   status: Not started
Patches almost ready to be posted (working fine for "normal"
mode, but working on simulating the mode we''d be in when
having this much of memory).

Prognosis: Good.
> * Remove hardcoded mobprobe''s in xencommons
>   owner: ?
>   status: ?
>   prognosis: Poor.
This was actually _promised_ to be a temporary hack, so I''d
consider it a release blocker if nothing at all was done here.
> * Xen EFI boot
>  - Signature checking for dom0 kernel / initrd?
>  status: No owner.
>  prognosis: Probably not for 4.4
This is already in the tree (c/s 26262:b62bd62b2683). Nothing else
should be necessary on the hypervisor side if the shim is to be used.

But of course pv-ops Linux continues to lack EFI support altogether.

Jan

On 16/01/13 18:55, George Dunlap wrote:
> Below is a summary of the projects / features being worked on for the
> 4.3 time frame.  The tentative feature freeze is scheduled for 25 March,
> which is just over 2 months away.  With that in mind, I think it''s
time
> to take stock of the development, so we know whether to ask for more
> help or divert resources.
> 
> To that end, I''ve added a line called "prognosis",
indicating the
> likelihood of completion in the 4.3 timeframe.  For items involving code
> hosted on the Xen.org site (including qemu-xen), that means a likelihood
> of having the feature code-complete and mostly working by the feature
> freeze.  (It''s OK if there are still bugs to be worked out.)  For
items
> in Linux, I think it would mean having items on track to make it into
> the kernel released just after the scheduled 4.3 time frame.  Not sure
> what that means for libvirt. :-)
> 
> I''ve given ratings to projects that I thought I had some insight
on, but
> I would appreciate if everyone could review these and let me know if
> they''re not accurate.
> 
> I''d particularly appreciate it if the people listed below could
give
> prognoses on the project listed.
> 
> Meanings of prognoses:
> - Excellent: It would be very unlikely for this not to be finished in time.
> - Good: Everything is on track, and is likely to make it.
> - Fair: A pretty good chance of making it, but not as certain
> - Poor: Likely not to make it unless intervention is made
> - Not for 4.3: self-explanatory
> 
> Mukesh Rathor: PVH
> 
> Wei: Event channel scalability
> 
> Daniel de Graaf: IS_PRIV->XSM
> 
> Roger Pau Monne: Persistent blk grants, openvswitch integration, backend
> scripts
> 
> Konrad Wilk: Persistent net grants, multi-page network, multi-page blk
> 
> Jim Fehlig: libvirt migration support
> 
> Matthew Fioravante: vTPM
> 
> Stefano Panella: PV Audio
> 
> Igor Kozhukov: IllumOS support
> 
> Once we know what items are "at risk", we can list them and
decide what
> to do about it.
> 
> This information will be mirrored on the Xen 4.3 Roadmap wiki page:
>  http://wiki.xen.org/wiki/Xen_Roadmap/4.3
> 
> = Timeline > 
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
> * Feature Freeze: 25 March 2013
> * First RC: 6 May 2013
> * Release: 17 June 2013
> 
> The RCs and release will of course depend on stability and bugs, and
> will therefore be fairly unpredictable.  The feature freeze may be
> slipped for especially important features which are near completion.
> 
> = Feature tracking > 
> Below is a list of features we''re tracking for this release.
Please
> respond to this mail with any updates to the status.
> 
> There are a number of items whose owners are marked as "?".  If
you
> are working on this, or know who is working on it, please respond and
> let me know.  Alternately, if you would *like* to work on it, please
> let me know as well.
> 
> And if there is something you''re working on you''d like
tracked, please
> respond, and I will add it to the list.
> 
> NB: Several of the items on this list are from external projects:
> linux, qemu, and libvirt.  These are not part of the Xen tree, but are
> directly related to our users'' experience (e.g., work in Linux or
> qemu) or to integration with other important projects (e.g., libvirt
> bindings).  Since all of these are part of the Xen community work, and
> comes from the same pool of labor, it makes sense to track the
> progress here, even though they won''t explicitly be released as
part
> of 4.3.
> 
> Meanings of prognoses:
> - Excellent: It would be very unlikely for this not to be finished in time.
> - Good: Everything is on track, and is likely to make it.
> - Fair: A pretty good chance of making it, but not as certain
> - Poor: Likely not to make it unless intervention is made
> 
> == Completed => 
> * Serial console improvements
>   -EHCI debug port
> 
> * Default to QEMU upstream (partial)
>  - pci pass-thru (external)
>  - enable dirtybit tracking during migration (external)
>  - xl cd-{insert,eject} (external)
> 
> * CPUID-based idle (don''t rely on ACPI info f/ dom0)
> 
> == Bugs => 
> * xl, compat mode, and older kernels
>   owner: ?
>   Many older 32-bit PV kernels that can run on a 64-bit hypervisor with
>   xend do not work when started with xl.  The following work-around seems
to
>   work:
>     xl create -p lightning.cfg
>     xenstore-write /local/domain/$(xl domid
> lightning)/device/vbd/51713/protocol x86_32-abi
>     xl unpause lightning
>   This node is normally written by the guest kernel, but for older kernels
>   seems not to be.  xend must have a work-around; port this work-around
> to xl.
> 
> == Not yet complete => 
> * PVH mode (w/ Linux)
>   owner: mukesh@oracle
>   status (Linux): 3rd draft patches posted. 
>   status (Xen): RFC submitted
>   prognosis: Good
> 
> * Event channel scalability
>   owner: wei@citrix
>   status: RFC submitted
>   prognosis: Good
>   Increase limit on event channels (currently 1024 for 32-bit guests,
>   4096 for 64-bit guests)
> 
> * ARM v7 server port
>   owner: ijc@citrix
>   prognosis: Excellent
>   status: Core hypervisor and Linux patches accepted.  Tools patches
> submitted.
> 
> * ARM v8 server port (tech preview)
>   owner: ijc@citrix
>   status: ?
>   prognosis: Tech preview only
> 
> * NUMA scheduler affinity
>   critical
>   owner: dario@citrix
>   status: Patches posted
>   prognosis: Excellent
> 
> * NUMA Memory migration
>   owner: dario@citrix
>   status: in progress
>   prognosis: Fair
> 
> * blktap3
>   owner: thanos@citrix
>   status: RFCs posted
>   prognosis: Not for 4.3
> 
> * Default to QEMU upstream
>  > Add "intel-hda" to xmexample file, since it works with
64-bit Win7/8
>  - qemu-based stubdom (Linux or BSD libc)
>    owner: anthony@citrix
>    status: in progress
>    prognosis: ?
>    qemu-upstream needs a more fully-featured libc than exists in
>    mini-os.  Either work on a minimalist linux-based stubdom with
>    glibc, or port one of the BSD libcs to minios.
> 
> * Persistent grants for blk (external)
>   owner: roger.pau@citrix
>   status: Initial implementation posted
>   prognosis: ?
Done, Linux implementation scheduled for 3.8, and Qemu side is also done
and being upstreamed right now.
> 
> * Persistent grants for net
>   owner: annie.li@citrix
>   status: Initial implementation posted
>   prognosis: ?
> 
> * Multi-page blk rings (external)
>  - blkback in kernel (konrad@oracle, ?@intel)
>  - qemu blkback
>   status: Not started.
>   prognosis: UNKNOWN
I will be taking on this project, following Intel, FreeBSD and Konrad
suggestions. Since I''m just starting now, I will mark it as
"Fair".
> 
> * Multi-page net protocol (external)
>   owner: ijc@citrix or annie.li@oracle
>   status: Initial patches posted (by Wei Liu)
>   expand the network ring protocol to allow multiple pages for
>   increased throughput
> 
> * Scalability: 16TiB of RAM
>   owner: jan@suse
>   status: Not started
> 
> * vTPM updates
>   owner: Matthew Fioravante @ Johns Hopkins
>   prognosis: Good
>   status: some patches submitted, more in progress
>   - Allow all vTPM components to run in stub domains for increased security
>   - Update vtpm to 0.7.1 from 0.5.x
> 
> * Guest EFI booting
>  - status: tianocore in-tree, some build problems.
>    prognosis: Poor.
>    Needs new owner.
> 
> * libvirt/libxl integration (external)
>  - Update libvirt to 4.2
>    status: Patch accepted
>  - Migration
>    owner: cyliu@suse (?)
>    status: first draft implemented, not yet submitted
>    prognosis: ?
>  - Itemize other things that need work
>    To begin with, we need someone to go and make some lists:
>    - Features available in libvirt/KVM not available in libvirt/libxl
>      See http://libvirt.org/hvsupport.html
>    - Features available in xl/Xen but not available in libvirt/Xen
> 
> * Allow XSM to override IS_PRIV checks in the hypervisor
>   owner: Daniel De Graaf
>   status: patches against 4.3-unstable posted, awaiting approval
>   prognosis: Good
>   This makes it possible to allow some user domains limited access to
>   dom0-only hypercalls. This could be used to allow a user-created
>   toolstack domain to administer its own set of VMs instead of relying
>   on dom0''s toolstack.
> 
> * V4V: Inter-domain communication
>   owner (Xen): jean.guyader@citrix.com
<mailto:jean.guyader@citrix.com>
>   status (Xen): patches submitted
>   prognosis: ?
>   owner (Linux driver):  stefano.panella@citrix
>   status (Linux driver): in progress
> 
> * Wait queues for mm
>   owner: ?
>   status: Draft posted Feb 2012; more work to do.
>   prognosis: Poor
> 
> * xl PVUSB pass-through for both PV and HVM guests
>   owner: George
>   status: ?
>   prognosis: Fair
>   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.
> 
> * xl USB pass-through for HVM guests using Qemu USB emulation
>   owner: George
>   status: Config file pass-through submitted.
>   prognosis: Good
>   xm/xend with qemu-traditional supports USB passthrough to HVM guests
> using the Qemu emulated USB controller.
>   The HVM guest does not need any special drivers for this feature.
>   So basicly the qemu cmdline needs to have:
>      -usb -usbdevice host:xxxx:yyyy
>   - port the xm/xend functionality to xl.
>   - make sure USB passthrough with xl works with both qemu-traditional
> and qemu-upstream.
> 
> * xl QXL Spice support
>   owner: Zhou Peng
>   prognosis: Fair
>   status: Patches against 4.3-unstable posted, awaiting approval
> 
> * Remove hardcoded mobprobe''s in xencommons
>   owner: ?
>   status: ?
>   prognosis: Poor.
> 
> * openvswitch toostack integration
>   owner: roger@citrix
>   prognosis: ?
>   status: Sample script posted by Bastian ("[RFC] openvswitch support
> script")
I have no experience with Open vSwitch, so if some with more experience
wants to take on this I would appreciate it. It should just be a matter
of adding a hotplug script.
> 
> * Rationalized backend scripts (incl. driver domains)
>   owner: roger@citrix
>   status: patches submitted
>   prognosis: Good
The first part of this effort, that includes a new hotplug interface for
libxl has been submitted for review. The protocol between the control
and the driver domains still needs to be designed/revised based on Ian
Jackson proposal.
> * Xen EFI boot
>  - Signature checking for dom0 kernel / initrd?
>  status: No owner.
>  prognosis: Probably not for 4.4
> 
> * Serial console improvements
>   owner: ?
>   status: Stalled (see below)
>   prognosis: Probably not for 4.4.
>   -xHCI debug port (Needs hardware)
>   -Firewire (needs hardware)
> 
> * Make storage migration possible
>   owner: ?
>   status: none
>   prognosis: Probably delay until 4.4
>   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
>   prognosis: Probably delay until 4.4
>   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
>   prognosis: Probably need 4.4
>   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
>   prognosis: Prob put off until 4.4 (or GSoC project)
>   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
>   prognosis: Prob put off until 4.4
> 
> * PV audio (audio for stubdom qemu)
>   owner: stefano.panella@citrix
>   status: ?
>   prognosis: ?
> 
> * IllumOS support
>   owner: Igor Kozhukov
>   status: In progress
>   prognosis: ?
>

On Wed, Jan 16, George Dunlap wrote:
> * Memory: Replace PoD with paging mechanism
>   owner: george@citrix
>   status: none
>   prognosis: Prob put off until 4.4
Related to this feature:
A few months ago we talked about integration of paging/sharing into
libxl. Some proposals were made. Unfortunately I dont have the time
right now to work on this for 4.3.

Olaf

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

On 16/01/13 18:15, Wei Liu wrote:
> I think I will rate my project as Good. Will send another RFC seires
> (hopefully two) by the end of this month. But this is my first time to
> estimate a real world project though.
Well, I think even for experienced people, software estimation is only 
slightly better than "wild guess". This is particularly true when 
developing new features, as by definition you don''t know
what''s possible
and what might go wrong.  If you''re implementing your 10th Farmville 
clone, I think it''s probably more predictable.  :-)

Thanks,
  -George

On 17/01/13 09:09, Jan Beulich wrote:
>>>> On 16.01.13 at 18:55, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
>> * Persistent grants for blk (external)
>>    owner: roger.pau@citrix
>>    status: Initial implementation posted
>>    prognosis: ?
> I think this went into 3.8-rc.
Ah, great.
>
>> * Scalability: 16TiB of RAM
>>    owner: jan@suse
>>    status: Not started
> Patches almost ready to be posted (working fine for "normal"
> mode, but working on simulating the mode we''d be in when
> having this much of memory).
>
> Prognosis: Good.
Good, I''ll update that.
>
>> * Remove hardcoded mobprobe''s in xencommons
>>    owner: ?
>>    status: ?
>>    prognosis: Poor.
> This was actually _promised_ to be a temporary hack, so I''d
> consider it a release blocker if nothing at all was done here.
I agree.  But I thought it would be useful *first* to have a clear list 
of where everything is.  Then when we know what''s at-risk, we can
decide
which things are critical / blockers and have a call to action.
>
>> * Xen EFI boot
>>   - Signature checking for dom0 kernel / initrd?
>>   status: No owner.
>>   prognosis: Probably not for 4.4
> This is already in the tree (c/s 26262:b62bd62b2683). Nothing else
> should be necessary on the hypervisor side if the shim is to be used.
>
> But of course pv-ops Linux continues to lack EFI support altogether.
OK, so I think the description needs an update, then.  For Xen to be 
fully featured, I think it would need all of the following:
* An EFI-bootable dom0 (this should be done, right?)
* dom0 able to make use of EFI run-time services
* Xen able to use EFI boot-time services (?)
* Xen able to detect the existence of a signed Linux binary, and leave 
EFI boot-time services enabled for dom0 to use when appropriate
* dom0 able to use boot-time EFI services and disable them when done

Are any of these that should be blockers for 4.3?

  -George

On 17/01/13 10:00, Roger Pau Monne wrote:
> On 16/01/13 18:55, George Dunlap wrote:
>> * Persistent grants for blk (external)
>>    owner: roger.pau@citrix
>>    status: Initial implementation posted
>>    prognosis: ?
> Done, Linux implementation scheduled for 3.8, and Qemu side is also done
> and being upstreamed right now.
OK, so I''ll mark the Linux component as "done", and the qemu
component
as "Good".
>> * Persistent grants for net
>>    owner: annie.li@citrix
>>    status: Initial implementation posted
>>    prognosis: ?
>>
>> * Multi-page blk rings (external)
>>   - blkback in kernel (konrad@oracle, ?@intel)
>>   - qemu blkback
>>    status: Not started.
>>    prognosis: UNKNOWN
> I will be taking on this project, following Intel, FreeBSD and Konrad
> suggestions. Since I''m just starting now, I will mark it as
"Fair".
OK, thanks for the info.  Out of curiosity, if someone were to consider 
this a blocker, would having someone else working on it speed things up, 
do you think?  Or is it development probably "non-parallelizable"? :-)
>> * openvswitch toostack integration
>>    owner: roger@citrix
>>    prognosis: ?
>>    status: Sample script posted by Bastian ("[RFC] openvswitch
support
>> script")
> I have no experience with Open vSwitch, so if some with more experience
> wants to take on this I would appreciate it. It should just be a matter
> of adding a hotplug script.
OK -- well shall I take your name off and call this "poor"?  That
would
put it on the list of "at-risk" features for which we would ask for 
volunteers.
>> * Rationalized backend scripts (incl. driver domains)
>>    owner: roger@citrix
>>    status: patches submitted
>>    prognosis: Good
> The first part of this effort, that includes a new hotplug interface for
> libxl has been submitted for review. The protocol between the control
> and the driver domains still needs to be designed/revised based on Ian
> Jackson proposal.
OK -- so, should I downgrade this to "Fair"?

Thanks for the updates,

  -George

>>> On 17.01.13 at 12:12, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> On 17/01/13 09:09, Jan Beulich wrote:
>>>>> On 16.01.13 at 18:55, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
>>> * Xen EFI boot
>>>   - Signature checking for dom0 kernel / initrd?
>>>   status: No owner.
>>>   prognosis: Probably not for 4.4
>> This is already in the tree (c/s 26262:b62bd62b2683). Nothing else
>> should be necessary on the hypervisor side if the shim is to be used.
>>
>> But of course pv-ops Linux continues to lack EFI support altogether.
> 
> OK, so I think the description needs an update, then.  For Xen to be 
> fully featured, I think it would need all of the following:
> * An EFI-bootable dom0 (this should be done, right?)
"Done" in the sense of todo for pvops (our kernels have been able
to for quite a long while).
> * dom0 able to make use of EFI run-time services
Indirectly, through hypercalls.
> * Xen able to use EFI boot-time services (?)
Sure, that''s how things work. Otherwise we wouldn''t boot at
all from EFI. The one extra thing that some people had asked
for was to be able to also properly boot Xen via grub.efi.
> * Xen able to detect the existence of a signed Linux binary, and leave 
> EFI boot-time services enabled for dom0 to use when appropriate
No. We can''t leave bot services enabled, and we also don''t
need to. The model is that only the Dom0 kernel binary needs
validation at the boot loader level. Everything else will be
done in the kernel (including initrd validation, or really the
parts of it that need validation).
> * dom0 able to use boot-time EFI services and disable them when done
As above - that''s not even an option.

Jan

On 17/01/13 12:51, Jan Beulich wrote:
>> On 17/01/13 09:09, Jan Beulich wrote:
>>> But of course pv-ops Linux continues to lack EFI support
altogether.
>> OK, so I think the description needs an update, then.  For Xen to be
>> fully featured, I think it would need all of the following:
>> * An EFI-bootable dom0 (this should be done, right?)
> "Done" in the sense of todo for pvops (our kernels have been able
> to for quite a long while).
Just to be clear here: are you saying that there is no way to boot Xen 
directly from EFI with a pvops kernel?  if so, that seems like a pretty 
big deal to me...
>
>> * dom0 able to make use of EFI run-time services
> Indirectly, through hypercalls.
Naturally. :-)
>
>> * Xen able to use EFI boot-time services (?)
> Sure, that''s how things work. Otherwise we wouldn''t boot
at
> all from EFI. The one extra thing that some people had asked
> for was to be able to also properly boot Xen via grub.efi.
Doesn''t this already work?
>
>> * Xen able to detect the existence of a signed Linux binary, and leave
>> EFI boot-time services enabled for dom0 to use when appropriate
> No. We can''t leave bot services enabled, and we also
don''t
> need to. The model is that only the Dom0 kernel binary needs
> validation at the boot loader level. Everything else will be
> done in the kernel (including initrd validation, or really the
> parts of it that need validation).
As I understood it, the Ubuntu bootloader will not require an image to 
be signed to boot.  Nonetheless, Ubuntu are still signing their kernel 
images, because they want the kernel to be able to play some fancy 
tricks for which they need boot-time services.  (I think this is 
something to do with making it easy to upload your own keys.) Full EFI 
functionality for Xen would include the ability to do this as well.

  -George

>>> On 17.01.13 at 14:58, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> On 17/01/13 12:51, Jan Beulich wrote:
>>> On 17/01/13 09:09, Jan Beulich wrote:
>>>> But of course pv-ops Linux continues to lack EFI support
altogether.
>>> OK, so I think the description needs an update, then.  For Xen to
be
>>> fully featured, I think it would need all of the following:
>>> * An EFI-bootable dom0 (this should be done, right?)
>> "Done" in the sense of todo for pvops (our kernels have been
able
>> to for quite a long while).
> 
> Just to be clear here: are you saying that there is no way to boot Xen 
> directly from EFI with a pvops kernel?  if so, that seems like a pretty 
> big deal to me...
It depends on the system: Those ones where legacy methods still
allow finding namely ACPI tables would allow booting. On ones
where those tables can be found only by consulting EFI, booting
is possible, but you''d generally end up without PCI interrupts
(which to me is almost the same as "doesn''t boot").
>>> * Xen able to use EFI boot-time services (?)
>> Sure, that''s how things work. Otherwise we wouldn''t
boot at
>> all from EFI. The one extra thing that some people had asked
>> for was to be able to also properly boot Xen via grub.efi.
> 
> Doesn''t this already work?
Not generally, the same restriction as above applies.
>>> * Xen able to detect the existence of a signed Linux binary, and
leave
>>> EFI boot-time services enabled for dom0 to use when appropriate
>> No. We can''t leave bot services enabled, and we also
don''t
>> need to. The model is that only the Dom0 kernel binary needs
>> validation at the boot loader level. Everything else will be
>> done in the kernel (including initrd validation, or really the
>> parts of it that need validation).
> 
> As I understood it, the Ubuntu bootloader will not require an image to 
> be signed to boot.
Yes - the plan is to decide whether booting securely by picking
to boot with or without the shim. All layers above have to
react accordingly. However, it is my understanding that if you
use the shim and your kernel isn''t signed, boot will fail.
>  Nonetheless, Ubuntu are still signing their kernel 
> images, because they want the kernel to be able to play some fancy 
> tricks for which they need boot-time services.  (I think this is 
> something to do with making it easy to upload your own keys.) Full EFI 
> functionality for Xen would include the ability to do this as well.
Yes, because you particularly need access to the EFI variables
from the kernel. Which in turn requires an EFI-enabled kernel.

Jan

On 17/01/13 14:15, Jan Beulich wrote:
>> Just to be clear here: are you saying that there is no way to boot 
>> Xen directly from EFI with a pvops kernel? if so, that seems like a 
>> pretty big deal to me... 
> It depends on the system: Those ones where legacy methods still
> allow finding namely ACPI tables would allow booting. On ones
> where those tables can be found only by consulting EFI, booting
> is possible, but you''d generally end up without PCI interrupts
> (which to me is almost the same as "doesn''t boot").
OK; so we''re talking about different things.  I''m talking
about 1) can
the binary be loaded into memory by EFI bootloaders 2) can dom0 access 
EFI runtime services.  You''re talking about "can it boot",
which
minimally requires 1, and on some systems (i.e., systems that do not 
provide appropriate ACPI tables) also requires 2.

So we already have #1 for both xenlinux and pvops; we just need #2. Is 
that correct?
>>>> * Xen able to detect the existence of a signed Linux binary,
and leave
>>>> EFI boot-time services enabled for dom0 to use when appropriate
>>> No. We can''t leave bot services enabled, and we also
don''t
>>> need to. The model is that only the Dom0 kernel binary needs
>>> validation at the boot loader level. Everything else will be
>>> done in the kernel (including initrd validation, or really the
>>> parts of it that need validation).
>> As I understood it, the Ubuntu bootloader will not require an image to
>> be signed to boot.
> Yes - the plan is to decide whether booting securely by picking
> to boot with or without the shim. All layers above have to
> react accordingly. However, it is my understanding that if you
> use the shim and your kernel isn''t signed, boot will fail.
My understanding was that Ubuntu''s shim will load Ubuntu''s
signed
bootloader; and the bootloader will load either signed or unsigned 
kernels.  If the kernel is signed, it will (as I understand it) leave 
boot services on so that the kernel can use them, leaving the kernel to 
turn them off.
>>   Nonetheless, Ubuntu are still signing their kernel
>> images, because they want the kernel to be able to play some fancy
>> tricks for which they need boot-time services.  (I think this is
>> something to do with making it easy to upload your own keys.) Full EFI
>> functionality for Xen would include the ability to do this as well.
> Yes, because you particularly need access to the EFI variables
> from the kernel. Which in turn requires an EFI-enabled kernel.
I''m responding to what you said above:  "No.  We can''t
leave [boot]
services enabled, and we don''t need to."  If we want the dom0
kernel to
be able to use boot-time services, to enable whatever features Ubuntu &c 
are using them for, then yes, we will need to leave boot services 
enabled until dom0 is done using them.

But we should only do that if 1) EFI services are enabled but Xen
wasn''t
signed (i.e,. SecureBoot disabled), or 2) both Xen and dom0 are signed.

  -George

>>> On 17.01.13 at 15:32, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> On 17/01/13 14:15, Jan Beulich wrote:
>>> Just to be clear here: are you saying that there is no way to boot 
>>> Xen directly from EFI with a pvops kernel? if so, that seems like a
>>> pretty big deal to me... 
>> It depends on the system: Those ones where legacy methods still
>> allow finding namely ACPI tables would allow booting. On ones
>> where those tables can be found only by consulting EFI, booting
>> is possible, but you''d generally end up without PCI interrupts
>> (which to me is almost the same as "doesn''t boot").
> 
> OK; so we''re talking about different things.  I''m talking
about 1) can
> the binary be loaded into memory by EFI bootloaders 2) can dom0 access 
> EFI runtime services.  You''re talking about "can it
boot", which
> minimally requires 1, and on some systems (i.e., systems that do not 
> provide appropriate ACPI tables) also requires 2.
> 
> So we already have #1 for both xenlinux and pvops; we just need #2. Is 
> that correct?
Yes, except that "just" is a gross understatement imo.

Also, just for clarification, runtime service access and getting at
the ACPI (and other) tables are two different things.

Jan

>>> On 17.01.13 at 15:32, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> On 17/01/13 14:15, Jan Beulich wrote:
>>> As I understood it, the Ubuntu bootloader will not require an image
to
>>> be signed to boot.
>> Yes - the plan is to decide whether booting securely by picking
>> to boot with or without the shim. All layers above have to
>> react accordingly. However, it is my understanding that if you
>> use the shim and your kernel isn''t signed, boot will fail.
> 
> My understanding was that Ubuntu''s shim will load
Ubuntu''s signed
> bootloader; and the bootloader will load either signed or unsigned 
> kernels.  If the kernel is signed, it will (as I understand it) leave 
> boot services on so that the kernel can use them, leaving the kernel to 
> turn them off.
I think it''s slightly different: The shim will only load signed
kernels,
but the same kernel can be loaded directly by EFI or the boot
loader to boot non-securely.

As to boot services - in the native case it''s always the kernel to
turn them off; in the Xen case it''s always Xen.
>>>   Nonetheless, Ubuntu are still signing their kernel
>>> images, because they want the kernel to be able to play some fancy
>>> tricks for which they need boot-time services.  (I think this is
>>> something to do with making it easy to upload your own keys.) Full
EFI
>>> functionality for Xen would include the ability to do this as well.
>> Yes, because you particularly need access to the EFI variables
>> from the kernel. Which in turn requires an EFI-enabled kernel.
> 
> I''m responding to what you said above:  "No.  We
can''t leave [boot]
> services enabled, and we don''t need to."  If we want the dom0
kernel to
> be able to use boot-time services, to enable whatever features Ubuntu
&c
> are using them for, then yes, we will need to leave boot services 
> enabled until dom0 is done using them.
Again, no. Boot services are meaningless to the Dom0 kernel
when run under Xen.

Jan

On 17/01/13 15:30, Jan Beulich wrote:
>>>> On 17.01.13 at 15:32, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
>> On 17/01/13 14:15, Jan Beulich wrote:
>>>> As I understood it, the Ubuntu bootloader will not require an
image to
>>>> be signed to boot.
>>> Yes - the plan is to decide whether booting securely by picking
>>> to boot with or without the shim. All layers above have to
>>> react accordingly. However, it is my understanding that if you
>>> use the shim and your kernel isn''t signed, boot will fail.
>> My understanding was that Ubuntu''s shim will load
Ubuntu''s signed
>> bootloader; and the bootloader will load either signed or unsigned
>> kernels.  If the kernel is signed, it will (as I understand it) leave
>> boot services on so that the kernel can use them, leaving the kernel to
>> turn them off.
> I think it''s slightly different: The shim will only load signed
kernels,
> but the same kernel can be loaded directly by EFI or the boot
> loader to boot non-securely.
> As to boot services - in the native case it''s always the kernel to
> turn them off; in the Xen case it''s always Xen.
> Again, no. Boot services are meaningless to the Dom0 kernel
> when run under Xen.
You are suggesting that Ubuntu only signed their kernels so that someone 
can use the EFI boot menu to boot shim + Ubuntu kernel?

 From what I undertstood from the discussion at the Ubuntu Developer 
Summit, you are wrong.  I may have misunderstood, but it seemed pretty 
clear to me at the time that:

* Ubuntu, and most of the distros, are trying to avoid having the user 
do anything through the native EFI menu.  This is because the EFI menu 
will be implemented differently by each different motherboard 
manufacturer -- making it impossible to provide any kind of reasonable 
instructions on how to do anything.  Furthermore, there''s every 
possibility that the EFI user interface for adding new keys will be 
quirky, difficult (e.g., type in the key long-hand), or just plain 
buggy.  For that reason, they are still planning on using software 
bootloaders (like grub) by default, and also planning on providing ways 
to add keys without using the EFI menu.

Therefore, the plan as I understood it from the EFI session at UDS was 
as follows:

* Ubuntu has their own shim which will enforce signatures
* Ubuntu plans on having the shim always load a bootloader (with a more 
full-featured menu which is under Ubuntu''s control, as opposed to the 
EFI menu, which will be different for each platform)
* The bootloader will load either signed or unsigned kernel images
* Ubuntu will still be signing their kernel images, however, because:
* The bootloader will turn off boot services for unsigned images, but 
will leave boot services on for signed images, so that
* The signed kernel binaries can do *other* things with boot services 
besides booting.  I don''t know the details of this but I think it had
to
do with making it possible for users to add their own keys in a 
consistent manner (rather than using the platform interface, which will 
be different for each OEM).

Therefore, if we want Ubuntu+Xen to have the same functionality as 
Ubuntu w/o Xen, then:
* When the dom0 kernel is signed, Xen will need to leave boot-time 
services enabled
* dom0 will need to have hooks so that it can access boot-time services 
and then disable them.

  -George

On 17/01/13 15:54, Daniel De Graaf wrote:
> On 01/16/2013 12:55 PM, George Dunlap wrote:
>> Below is a summary of the projects / features being worked on for the
4.3
>> time frame.  The tentative feature freeze is scheduled for 25 March,
which
>> is just over 2 months away.  With that in mind, I think it''s
time to take
>> stock of the development, so we know whether to ask for more help or
divert
>> resources.
>>
>> To that end, I''ve added a line called "prognosis",
indicating the
>> likelihood of completion in the 4.3 timeframe.  For items involving
code
>> hosted on the Xen.org site (including qemu-xen), that means a
likelihood of
>> having the feature code-complete and mostly working by the feature
freeze.
>> (It''s OK if there are still bugs to be worked out.)  For items
in Linux, I
>> think it would mean having items on track to make it into the kernel
>> released just after the scheduled 4.3 time frame.  Not sure what that
means
>> for libvirt. :-)
>>
>> I''ve given ratings to projects that I thought I had some
insight on, but I
>> would appreciate if everyone could review these and let me know if
they''re
>> not accurate.
>>
>> I''d particularly appreciate it if the people listed below
could give
>> prognoses on the project listed.
>>
>> Meanings of prognoses:
>> - Excellent: It would be very unlikely for this not to be finished in
time.
>> - Good: Everything is on track, and is likely to make it.
>> - Fair: A pretty good chance of making it, but not as certain
>> - Poor: Likely not to make it unless intervention is made
>> - Not for 4.3: self-explanatory
> [...]
>> * Allow XSM to override IS_PRIV checks in the hypervisor
>>    owner: Daniel De Graaf
>>    status: patches against 4.3-unstable posted, awaiting approval
>>    prognosis: Good
>>    This makes it possible to allow some user domains limited access to
>>    dom0-only hypercalls. This could be used to allow a user-created
>>    toolstack domain to administer its own set of VMs instead of relying
>>    on dom0''s toolstack.
> These patches are now in xen-unstable.
>
OK, so this is done?  Great!  I''ll mark it down.

  -George

On 01/16/2013 12:55 PM, George Dunlap wrote:
> Below is a summary of the projects / features being worked on for the 4.3
> time frame.  The tentative feature freeze is scheduled for 25 March, which
> is just over 2 months away.  With that in mind, I think it''s time
to take
> stock of the development, so we know whether to ask for more help or divert
> resources.
> 
> To that end, I''ve added a line called "prognosis",
indicating the
> likelihood of completion in the 4.3 timeframe.  For items involving code
> hosted on the Xen.org site (including qemu-xen), that means a likelihood of
> having the feature code-complete and mostly working by the feature freeze.
> (It''s OK if there are still bugs to be worked out.)  For items in
Linux, I
> think it would mean having items on track to make it into the kernel
> released just after the scheduled 4.3 time frame.  Not sure what that means
> for libvirt. :-)
> 
> I''ve given ratings to projects that I thought I had some insight
on, but I
> would appreciate if everyone could review these and let me know if
they''re
> not accurate.
> 
> I''d particularly appreciate it if the people listed below could
give
> prognoses on the project listed.
> 
> Meanings of prognoses:
> - Excellent: It would be very unlikely for this not to be finished in time.
> - Good: Everything is on track, and is likely to make it.
> - Fair: A pretty good chance of making it, but not as certain
> - Poor: Likely not to make it unless intervention is made
> - Not for 4.3: self-explanatory
[...]
> * Allow XSM to override IS_PRIV checks in the hypervisor
>   owner: Daniel De Graaf
>   status: patches against 4.3-unstable posted, awaiting approval
>   prognosis: Good
>   This makes it possible to allow some user domains limited access to
>   dom0-only hypercalls. This could be used to allow a user-created
>   toolstack domain to administer its own set of VMs instead of relying
>   on dom0''s toolstack.
These patches are now in xen-unstable.

-- 
Daniel De Graaf
National Security Agency

On 17/01/13 15:48, George Dunlap wrote:
> On 17/01/13 15:30, Jan Beulich wrote:
>>>>> On 17.01.13 at 15:32, George Dunlap
<george.dunlap@eu.citrix.com>
>>>>> wrote:
>>> On 17/01/13 14:15, Jan Beulich wrote:
>>>>> As I understood it, the Ubuntu bootloader will not require
an
>>>>> image to
>>>>> be signed to boot.
>>>> Yes - the plan is to decide whether booting securely by picking
>>>> to boot with or without the shim. All layers above have to
>>>> react accordingly. However, it is my understanding that if you
>>>> use the shim and your kernel isn''t signed, boot will
fail.
>>> My understanding was that Ubuntu''s shim will load
Ubuntu''s signed
>>> bootloader; and the bootloader will load either signed or unsigned
>>> kernels.  If the kernel is signed, it will (as I understand it)
leave
>>> boot services on so that the kernel can use them, leaving the
kernel to
>>> turn them off.
>> I think it''s slightly different: The shim will only load
signed kernels,
>> but the same kernel can be loaded directly by EFI or the boot
>> loader to boot non-securely.
>> As to boot services - in the native case it''s always the
kernel to
>> turn them off; in the Xen case it''s always Xen.
>> Again, no. Boot services are meaningless to the Dom0 kernel
>> when run under Xen.
>
> You are suggesting that Ubuntu only signed their kernels so that 
> someone can use the EFI boot menu to boot shim + Ubuntu kernel?
>
> From what I undertstood from the discussion at the Ubuntu Developer 
> Summit, you are wrong.  I may have misunderstood, but it seemed pretty 
> clear to me at the time that:
>
> * Ubuntu, and most of the distros, are trying to avoid having the user 
> do anything through the native EFI menu.  This is because the EFI menu 
> will be implemented differently by each different motherboard 
> manufacturer -- making it impossible to provide any kind of reasonable 
> instructions on how to do anything. Furthermore, there''s every 
> possibility that the EFI user interface for adding new keys will be 
> quirky, difficult (e.g., type in the key long-hand), or just plain 
> buggy.  For that reason, they are still planning on using software 
> bootloaders (like grub) by default, and also planning on providing 
> ways to add keys without using the EFI menu.
>
> Therefore, the plan as I understood it from the EFI session at UDS was 
> as follows:
>
> * Ubuntu has their own shim which will enforce signatures
> * Ubuntu plans on having the shim always load a bootloader (with a 
> more full-featured menu which is under Ubuntu''s control, as
opposed to
> the EFI menu, which will be different for each platform)
> * The bootloader will load either signed or unsigned kernel images
> * Ubuntu will still be signing their kernel images, however, because:
> * The bootloader will turn off boot services for unsigned images, but 
> will leave boot services on for signed images, so that
> * The signed kernel binaries can do *other* things with boot services 
> besides booting.  I don''t know the details of this but I think it
had
> to do with making it possible for users to add their own keys in a 
> consistent manner (rather than using the platform interface, which 
> will be different for each OEM).
I just looked back over a discussion I had with Colin Watson at Ubuntu 
after UDS.  He said:

--- Begin Quote ---

Specifically, we sign kernels in order that we can enter the
kernel without calling ExitBootServices, have the kernel perform some
quirks handling at startup (such as fixing up the framebuffer stride),
and then have the kernel call ExitBootServices itself before doing
anything else interesting.  When Secure Boot is enabled, unsigned
kernels must be entered after calling ExitBootServices, and so cannot
make use of UEFI boot services.

--- End Quote ---

So unless we plan to handle the same quirks in Xen, we''re going to need
to make it possible for dom0 to do it.

  -George

> Below is a summary of the projects / features being worked on for the 4.3
> time frame.  The tentative feature freeze is scheduled for 25 March, which
> is just over 2 months away.  With that in mind, I think it''s time
to take
> stock of the development, so we know whether to ask for more help or divert
> resources.
> 
> To that end, I''ve added a line called "prognosis",
indicating the
> likelihood of completion in the 4.3 timeframe.  For items involving code
> hosted on the Xen.org site (including qemu-xen), that means a likelihood of
> having the feature code-complete and mostly working by the feature freeze.
> (It''s OK if there are still bugs to be worked out.)  For items in
Linux, I
> think it would mean having items on track to make it into the kernel
> released just after the scheduled 4.3 time frame.  Not sure what that means
> for libvirt. :-)
> 
> I''ve given ratings to projects that I thought I had some insight
on, but I
> would appreciate if everyone could review these and let me know if
they''re
> not accurate.
> 
> I''d particularly appreciate it if the people listed below could
give
> prognoses on the project listed.
> 
> Meanings of prognoses:
> - Excellent: It would be very unlikely for this not to be finished in time.
> - Good: Everything is on track, and is likely to make it.
> - Fair: A pretty good chance of making it, but not as certain
> - Poor: Likely not to make it unless intervention is made
> - Not for 4.3: self-explanatory
> 
> Mukesh Rathor: PVH
> 
> Wei: Event channel scalability
> 
> Daniel de Graaf: IS_PRIV->XSM
> 
> Roger Pau Monne: Persistent blk grants, openvswitch integration, backend
> scripts
> 
> Konrad Wilk: Persistent net grants, multi-page network, multi-page blk
> 
> Jim Fehlig: libvirt migration support
> 
> Matthew Fioravante: vTPM
> 
> Stefano Panella: PV Audio
> 
> Igor Kozhukov: IllumOS support
> 
> Once we know what items are "at risk", we can list them and
decide what to
> do about it.
> 
> This information will be mirrored on the Xen 4.3 Roadmap wiki page:
> http://wiki.xen.org/wiki/Xen_Roadmap/4.3
> 
> = Timeline > 
> We are planning on a 9-month release cycle.  Based on that, below are
> our estimated dates:
> * Feature Freeze: 25 March 2013
> * First RC: 6 May 2013
> * Release: 17 June 2013
> 
> The RCs and release will of course depend on stability and bugs, and
> will therefore be fairly unpredictable.  The feature freeze may be
> slipped for especially important features which are near completion.
> 
> = Feature tracking > 
> Below is a list of features we''re tracking for this release.
Please
> respond to this mail with any updates to the status.
> 
> There are a number of items whose owners are marked as "?".  If
you
> are working on this, or know who is working on it, please respond and
> let me know.  Alternately, if you would *like* to work on it, please
> let me know as well.
> 
> And if there is something you''re working on you''d like
tracked, please
> respond, and I will add it to the list.
> 
> NB: Several of the items on this list are from external projects:
> linux, qemu, and libvirt.  These are not part of the Xen tree, but are
> directly related to our users'' experience (e.g., work in Linux or
> qemu) or to integration with other important projects (e.g., libvirt
> bindings).  Since all of these are part of the Xen community work, and
> comes from the same pool of labor, it makes sense to track the
> progress here, even though they won''t explicitly be released as
part
> of 4.3.
> 
> Meanings of prognoses:
> - Excellent: It would be very unlikely for this not to be finished in time.
> - Good: Everything is on track, and is likely to make it.
> - Fair: A pretty good chance of making it, but not as certain
> - Poor: Likely not to make it unless intervention is made
> 
> == Completed => 
> * Serial console improvements
>  -EHCI debug port
> 
> * Default to QEMU upstream (partial)
> - pci pass-thru (external)
> - enable dirtybit tracking during migration (external)
> - xl cd-{insert,eject} (external)
> 
> * CPUID-based idle (don''t rely on ACPI info f/ dom0)
> 
> == Bugs => 
> * xl, compat mode, and older kernels
>  owner: ?
>  Many older 32-bit PV kernels that can run on a 64-bit hypervisor with
>  xend do not work when started with xl.  The following work-around seems to
>  work:
>    xl create -p lightning.cfg
>    xenstore-write /local/domain/$(xl domid
> lightning)/device/vbd/51713/protocol x86_32-abi
>    xl unpause lightning
>  This node is normally written by the guest kernel, but for older kernels
>  seems not to be.  xend must have a work-around; port this work-around to
> xl.
> 
> == Not yet complete => 
> * PVH mode (w/ Linux)
>  owner: mukesh@oracle
>  status (Linux): 3rd draft patches posted.
>  status (Xen): RFC submitted
>  prognosis: Good
> 
> * Event channel scalability
>  owner: wei@citrix
>  status: RFC submitted
>  prognosis: Good
>  Increase limit on event channels (currently 1024 for 32-bit guests,
>  4096 for 64-bit guests)
> 
> * ARM v7 server port
>  owner: ijc@citrix
>  prognosis: Excellent
>  status: Core hypervisor and Linux patches accepted.  Tools patches
> submitted.
> 
> * ARM v8 server port (tech preview)
>  owner: ijc@citrix
>  status: ?
>  prognosis: Tech preview only
> 
> * NUMA scheduler affinity
>  critical
>  owner: dario@citrix
>  status: Patches posted
>  prognosis: Excellent
> 
> * NUMA Memory migration
>  owner: dario@citrix
>  status: in progress
>  prognosis: Fair
> 
> * blktap3
>  owner: thanos@citrix
>  status: RFCs posted
>  prognosis: Not for 4.3
> 
> * Default to QEMU upstream
>> Add "intel-hda" to xmexample file, since it works with 64-bit
Win7/8
> - qemu-based stubdom (Linux or BSD libc)
>   owner: anthony@citrix
>   status: in progress
>   prognosis: ?
>   qemu-upstream needs a more fully-featured libc than exists in
>   mini-os.  Either work on a minimalist linux-based stubdom with
>   glibc, or port one of the BSD libcs to minios.
> 
> * Persistent grants for blk (external)
>  owner: roger.pau@citrix
>  status: Initial implementation posted
>  prognosis: ?
> 
> * Persistent grants for net
>  owner: annie.li@citrix
>  status: Initial implementation posted
>  prognosis: ?
> 
> * Multi-page blk rings (external)
> - blkback in kernel (konrad@oracle, ?@intel)
> - qemu blkback
>  status: Not started.
>  prognosis: UNKNOWN
> 
> * Multi-page net protocol (external)
>  owner: ijc@citrix or annie.li@oracle
>  status: Initial patches posted (by Wei Liu)
>  expand the network ring protocol to allow multiple pages for
>  increased throughput
> 
> * Scalability: 16TiB of RAM
>  owner: jan@suse
>  status: Not started
> 
> * vTPM updates
>  owner: Matthew Fioravante @ Johns Hopkins
>  prognosis: Good
>  status: some patches submitted, more in progress
>  - Allow all vTPM components to run in stub domains for increased security
>  - Update vtpm to 0.7.1 from 0.5.x
> 
> * Guest EFI booting
> - status: tianocore in-tree, some build problems.
>   prognosis: Poor.
>   Needs new owner.
> 
> * libvirt/libxl integration (external)
> - Update libvirt to 4.2
>   status: Patch accepted
> - Migration
>   owner: cyliu@suse (?)
>   status: first draft implemented, not yet submitted
>   prognosis: ?
> - Itemize other things that need work
>   To begin with, we need someone to go and make some lists:
>   - Features available in libvirt/KVM not available in libvirt/libxl
>     See http://libvirt.org/hvsupport.html
>   - Features available in xl/Xen but not available in libvirt/Xen
> 
> * Allow XSM to override IS_PRIV checks in the hypervisor
>  owner: Daniel De Graaf
>  status: patches against 4.3-unstable posted, awaiting approval
>  prognosis: Good
>  This makes it possible to allow some user domains limited access to
>  dom0-only hypercalls. This could be used to allow a user-created
>  toolstack domain to administer its own set of VMs instead of relying
>  on dom0''s toolstack.
> 
> * V4V: Inter-domain communication
>  owner (Xen): jean.guyader@citrix.com
>  status (Xen): patches submitted
>  prognosis: ?
>  owner (Linux driver):  stefano.panella@citrix
>  status (Linux driver): in progress
> 
> * Wait queues for mm
>  owner: ?
>  status: Draft posted Feb 2012; more work to do.
>  prognosis: Poor
Mostly due to lack of time availability. All I''ve been able to do is
float a (bad) idea in the list.

There is some clean up work to p2m and sharing that I have in my backlog as a
precondition for that. I.e. unshares that don''t unnecessarily allocate
pages in paths such as remove_page, better sharing stats, use remove_page in
XENMEM_remove_from_physmap, etc. Once I get cycles I''ll aim to get that
into 4.3. 
> 
> * xl PVUSB pass-through for both PV and HVM guests
>  owner: George
>  status: ?
>  prognosis: Fair
>  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.
> 
> * xl USB pass-through for HVM guests using Qemu USB emulation
>  owner: George
>  status: Config file pass-through submitted.
>  prognosis: Good
>  xm/xend with qemu-traditional supports USB passthrough to HVM guests
> using the Qemu emulated USB controller.
>  The HVM guest does not need any special drivers for this feature.
>  So basicly the qemu cmdline needs to have:
>     -usb -usbdevice host:xxxx:yyyy
>  - port the xm/xend functionality to xl.
>  - make sure USB passthrough with xl works with both qemu-traditional and
> qemu-upstream.
> 
> * xl QXL Spice support
>  owner: Zhou Peng
>  prognosis: Fair
>  status: Patches against 4.3-unstable posted, awaiting approval
> 
> * Remove hardcoded mobprobe''s in xencommons
>  owner: ?
>  status: ?
>  prognosis: Poor.
> 
> * openvswitch toostack integration
>  owner: roger@citrix
>  prognosis: ?
>  status: Sample script posted by Bastian ("[RFC] openvswitch support
> script")
> 
> * Rationalized backend scripts (incl. driver domains)
>  owner: roger@citrix
>  status: patches submitted
>  prognosis: Good
> 
> * Xen EFI boot
> - Signature checking for dom0 kernel / initrd?
> status: No owner.
> prognosis: Probably not for 4.4
> 
> * Serial console improvements
>  owner: ?
>  status: Stalled (see below)
>  prognosis: Probably not for 4.4.
>  -xHCI debug port (Needs hardware)
>  -Firewire (needs hardware)
> 
> * Make storage migration possible
>  owner: ?
>  status: none
>  prognosis: Probably delay until 4.4
>  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
>  prognosis: Probably delay until 4.4
>  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
>  prognosis: Probably need 4.4
>  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
>  prognosis: Prob put off until 4.4 (or GSoC project)
>  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
>  prognosis: Prob put off until 4.4
You''re the boss here :) I think we could address most concerns with a
few extensions: 1. Create a p2m_paged_out_zero state that allocates on
p2m_paging_populate with no upcall. 2. Wire populate_physmap with pod flag to
set this new state. 3. Remove lots of code :)

However, I do not fully understand the accounting that goes on in p2m-pod.c
vis-a-vis the cache, and we''d need to find a way to keep super pages in
a cache the way PoD currently does.

My 0.02
Andres
> 
> * PV audio (audio for stubdom qemu)
>  owner: stefano.panella@citrix
>  status: ?
>  prognosis: ?
> 
> * IllumOS support
>  owner: Igor Kozhukov
>  status: In progress
>  prognosis: ?
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
<http://lists.xen.org/archives/html/xen-devel/attachments/20130116/89505b0f/attachment.html>
> 
> ------------------------------
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
> 
> 
> End of Xen-devel Digest, Vol 95, Issue 243
> ******************************************

>>> On 17.01.13 at 16:48, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> You are suggesting that Ubuntu only signed their kernels so that someone 
> can use the EFI boot menu to boot shim + Ubuntu kernel?
Yes, what else?
>  From what I undertstood from the discussion at the Ubuntu Developer 
> Summit, you are wrong.  I may have misunderstood, but it seemed pretty 
> clear to me at the time that:
> 
> * Ubuntu, and most of the distros, are trying to avoid having the user 
> do anything through the native EFI menu.  This is because the EFI menu 
> will be implemented differently by each different motherboard 
> manufacturer -- making it impossible to provide any kind of reasonable 
> instructions on how to do anything.  Furthermore, there''s every 
> possibility that the EFI user interface for adding new keys will be 
> quirky, difficult (e.g., type in the key long-hand), or just plain 
> buggy.  For that reason, they are still planning on using software 
> bootloaders (like grub) by default, and also planning on providing ways 
> to add keys without using the EFI menu.
That all sounds very close to what our folks are intending to do,
except that we''re not planning on enforcing the use of a boot
loader (or if so, Xen would get chain-loaded rather than started
through multiboot).
> Therefore, the plan as I understood it from the EFI session at UDS was 
> as follows:
> 
> * Ubuntu has their own shim which will enforce signatures
My understanding was that the fundamentals of the shim are
going to be shared.
> * Ubuntu plans on having the shim always load a bootloader (with a more 
> full-featured menu which is under Ubuntu''s control, as opposed to
the
> EFI menu, which will be different for each platform)
> * The bootloader will load either signed or unsigned kernel images
> * Ubuntu will still be signing their kernel images, however, because:
> * The bootloader will turn off boot services for unsigned images, but 
> will leave boot services on for signed images, so that
Again - Linux expects to be turning off boot services itself. So
there''s no question of the boot loader doing so.

There are certain other restrictions to what a not securely boot
can do, of course.
> * The signed kernel binaries can do *other* things with boot services 
> besides booting.  I don''t know the details of this but I think it
had to
> do with making it possible for users to add their own keys in a 
> consistent manner (rather than using the platform interface, which will 
> be different for each OEM).
Adding keys, according to the vague description I had been
given, is an indirect operation - the kernel tells the shim to
add a key during next boot. And there was some extra step
to be done for the first time (installation) boot.
> Therefore, if we want Ubuntu+Xen to have the same functionality as 
> Ubuntu w/o Xen, then:
> * When the dom0 kernel is signed, Xen will need to leave boot-time 
> services enabled
Once again - this is a no-go. All boot services memory got
reclaimed by the time Dom0 gets launched, so there''s no way
for Dom0 to access boot services. Even Xen itself cannot
arbitrarily use them - they get turned of near the end of
efi_start(). Anything else is conceptually wrong, even if it
might be possible to be made work.
> * dom0 will need to have hooks so that it can access boot-time services 
> and then disable them.
If there''s any runtime service they need access to and we
don''t,
they''d need to contribute patches. For our model, all pieces
should be in place (albeit someone is yet to try this all out).

And to be clear - unless someone manages to eliminate the
"conceptually wrong" argument above, I''m intending to veto
any changes that violate the model set by the specification.

Jan

>>> On 17.01.13 at 17:04, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> I just looked back over a discussion I had with Colin Watson at Ubuntu 
> after UDS.  He said:
> 
> --- Begin Quote ---
> 
> Specifically, we sign kernels in order that we can enter the
> kernel without calling ExitBootServices, have the kernel perform some
> quirks handling at startup (such as fixing up the framebuffer stride),
> and then have the kernel call ExitBootServices itself before doing
> anything else interesting.  When Secure Boot is enabled, unsigned
> kernels must be entered after calling ExitBootServices, and so cannot
> make use of UEFI boot services.
Which would mean neither Xen nor Linux can be started if not
signed, and if secure boot is enabled. There''s no way for the
boot loader or shim to fake up firmware tables in a compatible
way.

But there might be some fundamental understanding issue here:
I take it that it is not a property of a system whether one wants
secure boot, but a request of the owner of the system. If (s)he
wants to boot securely, then of course anything that isn''t signed
doesn''t even get loaded. If (s)he wants to boot "normally",
the
shim gets left out of the picture, and off we go. But maybe I''m
wrong with that?
> --- End Quote ---
> 
> So unless we plan to handle the same quirks in Xen, we''re going to
need
> to make it possible for dom0 to do it.
We will have to - see my other reply.

Jan

On 17/01/13 16:14, Jan Beulich wrote:
>> Therefore, if we want Ubuntu+Xen to have the same functionality as
>> Ubuntu w/o Xen, then:
>> * When the dom0 kernel is signed, Xen will need to leave boot-time
>> services enabled
> Once again - this is a no-go. All boot services memory got
> reclaimed by the time Dom0 gets launched, so there''s no way
> for Dom0 to access boot services. Even Xen itself cannot
> arbitrarily use them - they get turned of near the end of
> efi_start(). Anything else is conceptually wrong, even if it
> might be possible to be made work.
Right -- well "this is probably impossible" is different than,
"you
shouldn''t need to". :-)
>> So unless we plan to handle the same quirks in Xen, we''re
going to need
>> to make it possible for dom0 to do it.
> We will have to - see my other reply.
I suppose then we''ll have to plan on it.

In that case, it would be good if, sometime in the next month or two, 
someone could take a look at exactly what these "quirks" are that
Linux
needs boot services for, and figure out whether we are likely to need 
them.  I''ll put that in a sort of "call to action", along
with any other
important features not currently on track to make it into 4.3.

  -George

On 17/01/13 16:14, Jan Beulich wrote:
>>>> On 17.01.13 at 16:48, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
>> You are suggesting that Ubuntu only signed their kernels so that
someone
>> can use the EFI boot menu to boot shim + Ubuntu kernel?
> Yes, what else?
Well, the whole reason we had this discussion is that my understanding 
of how EFI secure boot is going to work and your understanding of how 
it''s going to work were different in important ways.  Given that, how 
should I know what else you might mean? Better to say it explicitly to 
make sure, rather than arguing for another 10 e-mails based on a 
misunderstanding. :-)
>>   From what I undertstood from the discussion at the Ubuntu Developer
>> Summit, you are wrong.  I may have misunderstood, but it seemed pretty
>> clear to me at the time that:
>>
>> * Ubuntu, and most of the distros, are trying to avoid having the user
>> do anything through the native EFI menu.  This is because the EFI menu
>> will be implemented differently by each different motherboard
>> manufacturer -- making it impossible to provide any kind of reasonable
>> instructions on how to do anything.  Furthermore, there''s
every
>> possibility that the EFI user interface for adding new keys will be
>> quirky, difficult (e.g., type in the key long-hand), or just plain
>> buggy.  For that reason, they are still planning on using software
>> bootloaders (like grub) by default, and also planning on providing ways
>> to add keys without using the EFI menu.
> That all sounds very close to what our folks are intending to do,
> except that we''re not planning on enforcing the use of a boot
> loader (or if so, Xen would get chain-loaded rather than started
> through multiboot).
I don''t think Ubuntu is planning on *enforcing* it; just that Ubuntu 
(and other distros) will *prefer* it.
>> * Ubuntu plans on having the shim always load a bootloader (with a more
>> full-featured menu which is under Ubuntu''s control, as opposed
to the
>> EFI menu, which will be different for each platform)
>> * The bootloader will load either signed or unsigned kernel images
>> * Ubuntu will still be signing their kernel images, however, because:
>> * The bootloader will turn off boot services for unsigned images, but
>> will leave boot services on for signed images, so that
> Again - Linux expects to be turning off boot services itself. So
> there''s no question of the boot loader doing so.
>
> There are certain other restrictions to what a not securely boot
> can do, of course.
How does this in any way disagree with the sentence to which you''re 
responding?

Case 1: Signed linux image.  Linux expects to turn boot services off -> 
bootloader doesn''t.
Case 2: Unsigned linux image.  "Certain other restrictions" -> 
bootloader turns boot services off.

They seem 100% compatible.

  -George

On 17/01/13 16:14, Jan Beulich wrote:
> And to be clear - unless someone manages to eliminate the 
> "conceptually wrong" argument above, I''m intending to
veto any changes
> that violate the model set by the specification. Jan 
Just for my information, could you describe what you think is 
"conceptually wrong" about leaving boot services for dom0?  I would 
consider Xen+dom0 to be two halves of the "Xen system", and so leaving
boot services on until dom0 gets a chance to fix up quirks doesn''t seem
to me any different than leaving it on when booting to Linux directly.  
If the spec doesn''t explicitly say "hypervisor", then I would
think
"kernel" in a Xen system would conceptually include both Xen and dom0.

  -George

(And sorry for responding 3 times to the same mail!)

>>> On 17.01.13 at 17:29, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> In that case, it would be good if, sometime in the next month or two, 
> someone could take a look at exactly what these "quirks" are that
Linux
> needs boot services for, and figure out whether we are likely to need 
> them.  I''ll put that in a sort of "call to action",
along with any other
> important features not currently on track to make it into 4.3.
I know that code pretty well meanwhile, and I''m unaware of
quirks requiring boot services access.

Also, I was slightly wrong in saying it is always Linux to exit boot
services: That''s the case when booted without boot loader
(i.e. using the EFI_STUB mechanism). Otherwise it''s the boot
loader doing so. But you remember that so far we don''t really
support booting from EFI with boot loader, so we ought to
always compare ourselves to that stub mechanism.

Jan

>>> On 17.01.13 at 17:43, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> On 17/01/13 16:14, Jan Beulich wrote:
>>>>> On 17.01.13 at 16:48, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
>>> * Ubuntu plans on having the shim always load a bootloader (with a
more
>>> full-featured menu which is under Ubuntu''s control, as
opposed to the
>>> EFI menu, which will be different for each platform)
>>> * The bootloader will load either signed or unsigned kernel images
>>> * Ubuntu will still be signing their kernel images, however,
because:
>>> * The bootloader will turn off boot services for unsigned images,
but
>>> will leave boot services on for signed images, so that
>> Again - Linux expects to be turning off boot services itself. So
>> there''s no question of the boot loader doing so.
>>
>> There are certain other restrictions to what a not securely boot
>> can do, of course.
> 
> How does this in any way disagree with the sentence to which
you''re
> responding?
> 
> Case 1: Signed linux image.  Linux expects to turn boot services off -> 
> bootloader doesn''t.
> Case 2: Unsigned linux image.  "Certain other restrictions" ->
> bootloader turns boot services off.
> 
> They seem 100% compatible.
In a way they are - xen.efi acts as the boot loader in the Xen
case.

Jan

On 17/01/13 16:49, Jan Beulich wrote:
>> In that case, it would be good if, sometime in the next month or two,
>> someone could take a look at exactly what these "quirks" are
that Linux
>> needs boot services for, and figure out whether we are likely to need
>> them.  I''ll put that in a sort of "call to action",
along with any other
>> important features not currently on track to make it into 4.3.
> I know that code pretty well meanwhile, and I''m unaware of
> quirks requiring boot services access.
Interesting.  Well, maybe I should just ask Colin which changes he was 
talking about.  It''s always possible they''re in the Ubuntu
patchqueue
and haven''t been upstreamed yet.  If it really does have to do with the
framebuffer, it might just have to do with the Ubuntu splash screen, 
which will be replaced once X.org comes up anyway.
> Also, I was slightly wrong in saying it is always Linux to exit boot
> services: That''s the case when booted without boot loader
> (i.e. using the EFI_STUB mechanism). Otherwise it''s the boot
> loader doing so. But you remember that so far we don''t really
> support booting from EFI with boot loader, so we ought to
> always compare ourselves to that stub mechanism.
To decide what "Xen has full support for EFI" means, we ought to
compare
ourselves with anywhere Linux can boot.  So if there is some 
functionality for Ubuntu when booting "EFI -> shim -> bootloader
->
Linux", then "full support" means having the same functionality
when
booting "EFI -> shim -> bootloader -> Xen -> Linux".

Not all of that functionality needs to be implemented -- we may decide 
that "full support" isn''t really worth our while (e.g. if
it''s a lot of
work just to make Ubuntu''s splash screen function properly instead of 
falling back to text mode).  But it needs to be a conscious decision 
made for specific reasons, not because we just didn''t think about it.

  -George

On 17/01/13 16:20, Jan Beulich wrote:
> But there might be some fundamental understanding issue here:
> I take it that it is not a property of a system whether one wants
> secure boot, but a request of the owner of the system. If (s)he
> wants to boot securely, then of course anything that isn''t signed
> doesn''t even get loaded. If (s)he wants to boot
"normally", the
> shim gets left out of the picture, and off we go. But maybe I''m
> wrong with that?
As I understand it, the whole reason Fedora and Ubuntu are going through 
this whole hassle with secure boot is:
* Microsoft requires a system to ship w/ secure boot enabled to get "MS 
Certified" for Windows 8
* The vast majority of desktop systems will be shipping with Windows 8, 
and so will want to be certified
* Therefore the vast majority of desktop systems will ship w/ secure 
boot enabled
* MS requires that secure boot be able to be disabled; however
* Each EFI system will be different, so it will be impossible to provide 
instructions on how to do so
* Furthermore many EFI systems may be buggy, so it may still not be 
possible to disable EFI

So the vast majority of desktop systems, saying that secure boot was "a 
request of the owner of the system" is false.  They didn''t ask for
it to
be turned on, and it may be difficult or impossible to turn off.

  -George

On 17/01/13 10:20, Olaf Hering wrote:
> On Wed, Jan 16, George Dunlap wrote:
>
>> * Memory: Replace PoD with paging mechanism
>>    owner: george@citrix
>>    status: none
>>    prognosis: Prob put off until 4.4
> Related to this feature:
> A few months ago we talked about integration of paging/sharing into
> libxl. Some proposals were made. Unfortunately I dont have the time
> right now to work on this for 4.3.
Right -- thanks for the heads-up.

  -George

>>> On 17.01.13 at 17:49, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> On 17/01/13 16:14, Jan Beulich wrote:
>> And to be clear - unless someone manages to eliminate the 
>> "conceptually wrong" argument above, I''m intending
to veto any changes
>> that violate the model set by the specification. Jan 
> 
> Just for my information, could you describe what you think is 
> "conceptually wrong" about leaving boot services for dom0?  I
would
> consider Xen+dom0 to be two halves of the "Xen system", and so
leaving
> boot services on until dom0 gets a chance to fix up quirks doesn''t
seem
> to me any different than leaving it on when booting to Linux directly.  
> If the spec doesn''t explicitly say "hypervisor", then I
would think
> "kernel" in a Xen system would conceptually include both Xen and
dom0.
But the spec says "OS loader", and that can only be interpreted
as far as up into the very first things a kernel might do. Which in
the Xen case is the hypervisor (much like in Linux''es EFI_STUB
case, the OS loader here really is bundled into the main binary).

Furthermore,
- Linux without EFI_STUB has no provisions to call boot services
  (it doesn''t even get passed the respective table pointer afaict)
- Linux with EFI_STUB calls boot services only from the stub code,
  and the stub code is what exists boot services

Consequently, with Xen basically replacing the stub code in Linux,
there is no reason to think of other alternative models.

Jan

>>> On 17.01.13 at 18:11, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> To decide what "Xen has full support for EFI" means, we ought to
compare
> ourselves with anywhere Linux can boot.  So if there is some 
> functionality for Ubuntu when booting "EFI -> shim -> bootloader
->
> Linux", then "full support" means having the same
functionality when
> booting "EFI -> shim -> bootloader -> Xen -> Linux".
Again, the bootloader portion here is a really questionable piece
under EFI, at least as long as the firmware provides a half way
user friendly representation of the EFI boot manager. An I can
only re-iterate that this - to me - i being proven by the fact that
Linux has enabled itself being booted without a boot manager
being involved.
> Not all of that functionality needs to be implemented -- we may decide 
> that "full support" isn''t really worth our while (e.g.
if it''s a lot of
> work just to make Ubuntu''s splash screen function properly instead
of
> falling back to text mode).  But it needs to be a conscious decision 
> made for specific reasons, not because we just didn''t think about
it.
The splash screen is a particularly bad example - all needed setup
is done by xen.efi (as it wants to use the console itself), and all
needed information to make use of the framebuffer is being passed
to the kernel.

Jan

On 17/01/13 12:22, George Dunlap wrote:
> On 17/01/13 10:00, Roger Pau Monne wrote:
>> On 16/01/13 18:55, George Dunlap wrote:
>>> * Persistent grants for blk (external)
>>>    owner: roger.pau@citrix
>>>    status: Initial implementation posted
>>>    prognosis: ?
>> Done, Linux implementation scheduled for 3.8, and Qemu side is also
done
>> and being upstreamed right now.
> 
> OK, so I''ll mark the Linux component as "done", and the
qemu component
> as "Good".
> 
>>> * Persistent grants for net
>>>    owner: annie.li@citrix
>>>    status: Initial implementation posted
>>>    prognosis: ?
>>>
>>> * Multi-page blk rings (external)
>>>   - blkback in kernel (konrad@oracle, ?@intel)
>>>   - qemu blkback
>>>    status: Not started.
>>>    prognosis: UNKNOWN
>> I will be taking on this project, following Intel, FreeBSD and Konrad
>> suggestions. Since I''m just starting now, I will mark it as
"Fair".
> 
> OK, thanks for the info.  Out of curiosity, if someone were to consider 
> this a blocker, would having someone else working on it speed things up, 
> do you think?  Or is it development probably
"non-parallelizable"? :-)
Let''s wait until we have a clear roadmap about how are we going to
handle it. This is not related to Xen itself, so I wouldn''t see it as a
blocker, most of the work will be done in the Linux kernel, and the only
hypervisor part of this might be changes to the block protocol (blkif.h)
and the ring (ring.h) protocol.
> 
>>> * openvswitch toostack integration
>>>    owner: roger@citrix
>>>    prognosis: ?
>>>    status: Sample script posted by Bastian ("[RFC] openvswitch
support
>>> script")
>> I have no experience with Open vSwitch, so if some with more experience
>> wants to take on this I would appreciate it. It should just be a matter
>> of adding a hotplug script.
> 
> OK -- well shall I take your name off and call this "poor"?  That
would
> put it on the list of "at-risk" features for which we would ask
for
> volunteers.
Maybe we can try to engage Bastian to contribute a more complete script,
that includes support for HVM domains.
> 
>>> * Rationalized backend scripts (incl. driver domains)
>>>    owner: roger@citrix
>>>    status: patches submitted
>>>    prognosis: Good
>> The first part of this effort, that includes a new hotplug interface
for
>> libxl has been submitted for review. The protocol between the control
>> and the driver domains still needs to be designed/revised based on Ian
>> Jackson proposal.
> 
> OK -- so, should I downgrade this to "Fair"?
I would say:

Rationalized backend scripts: Good
Driver domains: Fair
> 
> Thanks for the updates,
> 
>   -George
> 
> 
>

On Thu, Jan 17, 2013 at 11:12:34AM +0000, George Dunlap wrote:

[...]
> OK, so I think the description needs an update, then.  For Xen to be
> fully featured, I think it would need all of the following:
> * An EFI-bootable dom0 (this should be done, right?)
> * dom0 able to make use of EFI run-time services
> * Xen able to use EFI boot-time services (?)
> * Xen able to detect the existence of a signed Linux binary, and leave
> EFI boot-time services enabled for dom0 to use when appropriate
> * dom0 able to use boot-time EFI services and disable them when done
I am slowly starting work on EFI stuff in Xen and dom0 with upstream Linux
Kernel.
I am preparing my new platform for this now. At first I am going to figure out
what
works and what does not work. Additionally, I am going to work on GRUB2 to
properly
load Xen and other needed stuff. I think that final goal is to have Xen
evironment
working in all possible EFI configs.

You could assign me to this task.

Daniel

> >Matthew Fioravante: vTPM
> vTPM should be ready for next release, we just have one minor issue
> to workout with the configure scripts. So I agree with your
> prognosis of "Good".
The v3.9 merge window is going to happen in March. Do you think you will be able
to repost the patches for the Linux kernel by that time?

On Fri, Jan 18, 2013 at 10:50:46AM +0100, Roger Pau Monné
wrote:
> On 17/01/13 12:22, George Dunlap wrote:
> > On 17/01/13 10:00, Roger Pau Monne wrote:
> >> On 16/01/13 18:55, George Dunlap wrote:
> >>> * Persistent grants for blk (external)
> >>>    owner: roger.pau@citrix
> >>>    status: Initial implementation posted
> >>>    prognosis: ?
> >> Done, Linux implementation scheduled for 3.8, and Qemu side is
also done
> >> and being upstreamed right now.
> > 
> > OK, so I''ll mark the Linux component as "done", and
the qemu component
> > as "Good".
> > 
> >>> * Persistent grants for net
> >>>    owner: annie.li@citrix
> >>>    status: Initial implementation posted
> >>>    prognosis: ?
> >>>
> >>> * Multi-page blk rings (external)
> >>>   - blkback in kernel (konrad@oracle, ?@intel)
> >>>   - qemu blkback
> >>>    status: Not started.
> >>>    prognosis: UNKNOWN
> >> I will be taking on this project, following Intel, FreeBSD and
Konrad
> >> suggestions. Since I''m just starting now, I will mark it
as "Fair".
> > 
> > OK, thanks for the info.  Out of curiosity, if someone were to
consider
> > this a blocker, would having someone else working on it speed things
up,
> > do you think?  Or is it development probably
"non-parallelizable"? :-)
> 
> Let''s wait until we have a clear roadmap about how are we going to
> handle it. This is not related to Xen itself, so I wouldn''t see it
as a
> blocker, most of the work will be done in the Linux kernel, and the only
> hypervisor part of this might be changes to the block protocol (blkif.h)
> and the ring (ring.h) protocol.
Did you have a chance to look at the issues I enumerated with the block
protocol?

Perhaps we should continue the discussion on the "clear roadmap" on
that
thread?

On Thu, Jan 17, 2013 at 09:09:03AM +0000, Jan Beulich
wrote:
> >>> On 16.01.13 at 18:55, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> > * Persistent grants for blk (external)
> >   owner: roger.pau@citrix
> >   status: Initial implementation posted
> >   prognosis: ?
> 
> I think this went into 3.8-rc.
> 
> > * Scalability: 16TiB of RAM
> >   owner: jan@suse
> >   status: Not started
> 
> Patches almost ready to be posted (working fine for "normal"
> mode, but working on simulating the mode we''d be in when
> having this much of memory).
> 
> Prognosis: Good.
> 
> > * Remove hardcoded mobprobe''s in xencommons
> >   owner: ?
> >   status: ?
> >   prognosis: Poor.
> 
> This was actually _promised_ to be a temporary hack, so I''d
> consider it a release blocker if nothing at all was done here.
> 
> > * Xen EFI boot
> >  - Signature checking for dom0 kernel / initrd?
> >  status: No owner.
> >  prognosis: Probably not for 4.4
> 
> This is already in the tree (c/s 26262:b62bd62b2683). Nothing else
> should be necessary on the hypervisor side if the shim is to be used.
> 
> But of course pv-ops Linux continues to lack EFI support altogether.
CC-ing Daniel here.

On Thu, Jan 17, 2013 at 12:51:45PM +0000, Jan Beulich
wrote:
> >>> On 17.01.13 at 12:12, George Dunlap
<george.dunlap@eu.citrix.com> wrote:
> > On 17/01/13 09:09, Jan Beulich wrote:
> >>>>> On 16.01.13 at 18:55, George Dunlap
<George.Dunlap@eu.citrix.com> wrote:
> >>> * Xen EFI boot
> >>>   - Signature checking for dom0 kernel / initrd?
> >>>   status: No owner.
> >>>   prognosis: Probably not for 4.4
> >> This is already in the tree (c/s 26262:b62bd62b2683). Nothing else
> >> should be necessary on the hypervisor side if the shim is to be
used.
> >>
> >> But of course pv-ops Linux continues to lack EFI support
altogether.
> > 
> > OK, so I think the description needs an update, then.  For Xen to be 
> > fully featured, I think it would need all of the following:
> > * An EFI-bootable dom0 (this should be done, right?)
> 
> "Done" in the sense of todo for pvops (our kernels have been able
> to for quite a long while).
> 
> > * dom0 able to make use of EFI run-time services
> 
> Indirectly, through hypercalls.
> 
> > * Xen able to use EFI boot-time services (?)
> 
> Sure, that''s how things work. Otherwise we wouldn''t boot
at
> all from EFI. The one extra thing that some people had asked
> for was to be able to also properly boot Xen via grub.efi.
> 
> > * Xen able to detect the existence of a signed Linux binary, and leave
> > EFI boot-time services enabled for dom0 to use when appropriate
> 
> No. We can''t leave bot services enabled, and we also
don''t
> need to. The model is that only the Dom0 kernel binary needs
> validation at the boot loader level. Everything else will be
> done in the kernel (including initrd validation, or really the
> parts of it that need validation).
> 
> > * dom0 able to use boot-time EFI services and disable them when done
> 
> As above - that''s not even an option.
> 
> Jan
From the Linux pvops side it is all in ''Not-done'' camp. Daniel
is now
taking a look at it.
>

On 18/01/13 16:21, Konrad Rzeszutek Wilk wrote:
>>>>> * Multi-page blk rings (external)
>>>>>   - blkback in kernel (konrad@oracle, ?@intel)
>>>>>   - qemu blkback
>>>>>    status: Not started.
>>>>>    prognosis: UNKNOWN
>>>> I will be taking on this project, following Intel, FreeBSD and
Konrad
>>>> suggestions. Since I''m just starting now, I will mark
it as "Fair".
>>>
>>> OK, thanks for the info.  Out of curiosity, if someone were to
consider
>>> this a blocker, would having someone else working on it speed
things up,
>>> do you think?  Or is it development probably
"non-parallelizable"? :-)
>>
>> Let''s wait until we have a clear roadmap about how are we
going to
>> handle it. This is not related to Xen itself, so I wouldn''t
see it as a
>> blocker, most of the work will be done in the Linux kernel, and the
only
>> hypervisor part of this might be changes to the block protocol
(blkif.h)
>> and the ring (ring.h) protocol.
> 
> Did you have a chance to look at the issues I enumerated with the block
> protocol?
> 
> Perhaps we should continue the discussion on the "clear roadmap"
on that
> thread?
Yes, I''m currently writing a reply to that email with my proposal,
let''s
continue the discussion there.

> Konrad Wilk: Persistent net grants, multi-page network, multi-page blk
a) persistent-page grants are in the Linux kernel.

b) Multi-page network and persistent net grants.
Annie is doing a hollistic look at the network stack
and is going to setup a collaboration meeting between interested parties
(for right now I think it is Intel, Citrix, Amazon, SuSE, and Oracle)
to collaborate on that. There are multiple items in this and it would
be good that we don''t step on each other toes.


c) Mutli-page block. That kind of morphed in me taking a hard look at the
block protocol itself and how we can fix this and other. 

http://lists.xen.org/archives/html/xen-devel/2012-12/msg01346.html

Need more people to disuss and make sure we are actually on the
same page on the issues I enumerated.
> 
> Jim Fehlig: libvirt migration support
> 
> Matthew Fioravante: vTPM
He posted some patches for the Linux kernel, but they need some tweaking.
..
> == Not yet complete => 
> * PVH mode (w/ Linux)
>   owner: mukesh@oracle
>   status (Linux): 3rd draft patches posted.
>   status (Xen): RFC submitted
>   prognosis: Good
The Linux side is good. The Xen hypervisor side needs reviews and
foremost the new hypercall needs to be set in stone (otherwsie
the Linux patches need to be redone).


.. snip..
> * Persistent grants for net
>   owner: annie.li@citrix
>   status: Initial implementation posted
>   prognosis: ?
Shelved. The perf reports with Xen 4.2 did not show much improvement.
They should have but there is something amiss.

goto b;
> 
> * Multi-page blk rings (external)
>  - blkback in kernel (konrad@oracle, ?@intel)
>  - qemu blkback
>   status: Not started.
>   prognosis: UNKNOWN
goto c;
> 
> * Multi-page net protocol (external)
>   owner: ijc@citrix or annie.li@oracle
>   status: Initial patches posted (by Wei Liu)
>   expand the network ring protocol to allow multiple pages for
>   increased throughput
goto b;


We might also put on this list:

 - hardware performance counters.
  Investigate what is important.

Yes I''ll have the updated linux patch out very soon. It
doesn''t contain
Daniel De Graaf''s interface update so it still uses backend/vtpm (not
vtpm2).

However, I will be out of commission for most of the month of February so 
if there is more feedback and/or changes required they may not make it in time.

All of the Xen components have been committed. The linux patch is the only
outstanding piece.
________________________________________
From: Konrad Rzeszutek Wilk [konrad.wilk@oracle.com]
Sent: Friday, January 18, 2013 10:19 AM
To: Fioravante, Matthew E.
Cc: George Dunlap; Ian Campbell; Wei Liu; xen-devel@lists.xen.org; Jim Fehlig;
Jan Beulich; Anthony PERARD; Daniel De Graaf; Roger Pau Monné
Subject: Re: [Xen-devel] Xen 4.3 development update, and stock-taking
> >Matthew Fioravante: vTPM
> vTPM should be ready for next release, we just have one minor issue
> to workout with the configure scripts. So I agree with your
> prognosis of "Good".
The v3.9 merge window is going to happen in March. Do you think you will be able
to repost the patches for the Linux kernel by that time?

On 18/01/13 11:20, Daniel Kiper wrote:
> On Thu, Jan 17, 2013 at 11:12:34AM +0000, George Dunlap wrote:
>
> [...]
>
>> OK, so I think the description needs an update, then.  For Xen to be
>> fully featured, I think it would need all of the following:
>> * An EFI-bootable dom0 (this should be done, right?)
>> * dom0 able to make use of EFI run-time services
>> * Xen able to use EFI boot-time services (?)
>> * Xen able to detect the existence of a signed Linux binary, and leave
>> EFI boot-time services enabled for dom0 to use when appropriate
>> * dom0 able to use boot-time EFI services and disable them when done
> I am slowly starting work on EFI stuff in Xen and dom0 with upstream Linux
Kernel.
> I am preparing my new platform for this now. At first I am going to figure
out what
> works and what does not work. Additionally, I am going to work on GRUB2 to
properly
> load Xen and other needed stuff. I think that final goal is to have Xen
evironment
> working in all possible EFI configs.
>
> You could assign me to this task.
OK, I''ve added you as the owner.  Do you think the Xen-side EFI hooks 
might be ready by the 4.3 feature freeze (scheduled for March 25)?

  -George

On 18/01/13 15:41, Konrad Rzeszutek Wilk wrote:
>> Konrad Wilk: Persistent net grants, multi-page network, multi-page blk
> a) persistent-page grants are in the Linux kernel.
>
> b) Multi-page network and persistent net grants.
> Annie is doing a hollistic look at the network stack
> and is going to setup a collaboration meeting between interested parties
> (for right now I think it is Intel, Citrix, Amazon, SuSE, and Oracle)
> to collaborate on that. There are multiple items in this and it would
> be good that we don''t step on each other toes.
>
>
> c) Mutli-page block. That kind of morphed in me taking a hard look at the
> block protocol itself and how we can fix this and other.
>
> http://lists.xen.org/archives/html/xen-devel/2012-12/msg01346.html
>
> Need more people to disuss and make sure we are actually on the
> same page on the issues I enumerated.
>
>> Jim Fehlig: libvirt migration support
>>
>> Matthew Fioravante: vTPM
> He posted some patches for the Linux kernel, but they need some tweaking.
> ..
>> == Not yet complete =>>
>> * PVH mode (w/ Linux)
>>    owner: mukesh@oracle
>>    status (Linux): 3rd draft patches posted.
>>    status (Xen): RFC submitted
>>    prognosis: Good
> The Linux side is good. The Xen hypervisor side needs reviews and
> foremost the new hypercall needs to be set in stone (otherwsie
> the Linux patches need to be redone).
OK -- the main question for planning purposes is, does it seem like we 
can get this sorted out by the scheduled feature freeze on March 25?  At 
the moment I''m going to leave this as "Good".
>
>
> .. snip..
>> * Persistent grants for net
>>    owner: annie.li@citrix
>>    status: Initial implementation posted
>>    prognosis: ?
> Shelved. The perf reports with Xen 4.2 did not show much improvement.
> They should have but there is something amiss.
>
> goto b;
OK -- so I''ll put this down as "Not for 4.3".
>> * Multi-page blk rings (external)
>>   - blkback in kernel (konrad@oracle, ?@intel)
>>   - qemu blkback
>>    status: Not started.
>>    prognosis: UNKNOWN
> goto c;
OK -- we still have a bit of time, so I''ll leave this with
Roger''s
assessment of "Fair" for now.  We can always review the assessment
later.
>> * Multi-page net protocol (external)
>>    owner: ijc@citrix or annie.li@oracle
>>    status: Initial patches posted (by Wei Liu)
>>    expand the network ring protocol to allow multiple pages for
>>    increased throughput
> goto b;
OK -- I''ll mark this as "Poor".
> We might also put on this list:
>
>   - hardware performance counters.
>    Investigate what is important.
This seems a bit to vague.  How do I know when it can be crossed off? :-)

  -George

On 18/01/13 09:50, Roger Pau Monne wrote:
>>>> * openvswitch toostack integration
>>>>     owner: roger@citrix
>>>>     prognosis: ?
>>>>     status: Sample script posted by Bastian ("[RFC]
openvswitch support
>>>> script")
>>> I have no experience with Open vSwitch, so if some with more
experience
>>> wants to take on this I would appreciate it. It should just be a
matter
>>> of adding a hotplug script.
>> OK -- well shall I take your name off and call this "poor"? 
That would
>> put it on the list of "at-risk" features for which we would
ask for
>> volunteers.
> Maybe we can try to engage Bastian to contribute a more complete script,
> that includes support for HVM domains.
OK -- I think I''ll note this down, and then when we come to do the
"what
to do about things not going to make it", we can talk about it.

  -George

On Mon, Jan 21, 2013 at 02:12:40PM +0000, George Dunlap
wrote:
> On 18/01/13 11:20, Daniel Kiper wrote:
> >On Thu, Jan 17, 2013 at 11:12:34AM +0000, George Dunlap wrote:
> >
> >[...]
> >
> >>OK, so I think the description needs an update, then.  For Xen to
be
> >>fully featured, I think it would need all of the following:
> >>* An EFI-bootable dom0 (this should be done, right?)
> >>* dom0 able to make use of EFI run-time services
> >>* Xen able to use EFI boot-time services (?)
> >>* Xen able to detect the existence of a signed Linux binary, and
leave
> >>EFI boot-time services enabled for dom0 to use when appropriate
> >>* dom0 able to use boot-time EFI services and disable them when
done
> >I am slowly starting work on EFI stuff in Xen and dom0 with upstream
Linux Kernel.
> >I am preparing my new platform for this now. At first I am going to
figure out what
> >works and what does not work. Additionally, I am going to work on GRUB2
to properly
> >load Xen and other needed stuff. I think that final goal is to have Xen
evironment
> >working in all possible EFI configs.
> >
> >You could assign me to this task.
>
> OK, I''ve added you as the owner.  Do you think the Xen-side EFI
hooks
> might be ready by the 4.3 feature freeze (scheduled for March 25)?
As I know there are some hooks which allows us to use EFI on some systems.
However, I do not know how they could be used in PVOPS kernel. It requires
some investigation (which I start doing). Maybe they are sufficient but
maybe some of them or all should be changed (as it is the case in kaxec/kdump
functionality). Anyway, I hope that I will have full view of that in ~1 month.
I will send you update ASAP.

Daniel

>>> On 22.01.13 at 14:53, Daniel Kiper <dkiper@net-space.pl>
wrote:
> On Mon, Jan 21, 2013 at 02:12:40PM +0000, George Dunlap wrote:
>> OK, I''ve added you as the owner.  Do you think the Xen-side
EFI hooks
>> might be ready by the 4.3 feature freeze (scheduled for March 25)?
> 
> As I know there are some hooks which allows us to use EFI on some systems.
> However, I do not know how they could be used in PVOPS kernel. It requires
> some investigation (which I start doing). Maybe they are sufficient but
> maybe some of them or all should be changed (as it is the case in 
> kaxec/kdump
> functionality). Anyway, I hope that I will have full view of that in ~1 
> month.
No need to re-do everything from scratch - someone at Oracle
had initial patches ready quite some time ago (Konrad will likely
recall who that was, and maybe even have retained those
patches), they just needed some polishing iirc.

Jan

>>>> On 22.01.13 at 14:53, Daniel Kiper <dkiper@net-space.pl>
wrote:
>> On Mon, Jan 21, 2013 at 02:12:40PM +0000, George Dunlap wrote:
>>> OK, I''ve added you as the owner.  Do you think the
Xen-side EFI hooks
>>> might be ready by the 4.3 feature freeze (scheduled for March 25)?
>>
>> As I know there are some hooks which allows us to use EFI on some
systems.
>> However, I do not know how they could be used in PVOPS kernel. It
requires
>> some investigation (which I start doing). Maybe they are sufficient but
>> maybe some of them or all should be changed (as it is the case in
kaxec/kdump
>> functionality). Anyway, I hope that I will have full view of that in ~1
month.
>
> No need to re-do everything from scratch - someone at Oracle
> had initial patches ready quite some time ago (Konrad will likely
> recall who that was, and maybe even have retained those
> patches), they just needed some polishing iirc.
Thanks. I have this patches but as I know they are at least one year old.
Additionally, as I know there were some objections among Linux EFI maintainers
and some issues should be solved. I am going to put all pieces of this puzzle
together and see what is going on.

Jan

On Mon, Jan 21, 2013 at 03:04:30PM +0000, George Dunlap
wrote:
> On 18/01/13 15:41, Konrad Rzeszutek Wilk wrote:
> >>Konrad Wilk: Persistent net grants, multi-page network, multi-page
blk
> >a) persistent-page grants are in the Linux kernel.
> >
> >b) Multi-page network and persistent net grants.
> >Annie is doing a hollistic look at the network stack
> >and is going to setup a collaboration meeting between interested
parties
> >(for right now I think it is Intel, Citrix, Amazon, SuSE, and Oracle)
> >to collaborate on that. There are multiple items in this and it would
> >be good that we don''t step on each other toes.
> >
> >
> >c) Mutli-page block. That kind of morphed in me taking a hard look at
the
> >block protocol itself and how we can fix this and other.
> >
> >http://lists.xen.org/archives/html/xen-devel/2012-12/msg01346.html
> >
> >Need more people to disuss and make sure we are actually on the
> >same page on the issues I enumerated.
> >
> >>Jim Fehlig: libvirt migration support
> >>
> >>Matthew Fioravante: vTPM
> >He posted some patches for the Linux kernel, but they need some
tweaking.
> >..
> >>== Not yet complete => >>
> >>* PVH mode (w/ Linux)
> >>   owner: mukesh@oracle
> >>   status (Linux): 3rd draft patches posted.
> >>   status (Xen): RFC submitted
> >>   prognosis: Good
> >The Linux side is good. The Xen hypervisor side needs reviews and
> >foremost the new hypercall needs to be set in stone (otherwsie
> >the Linux patches need to be redone).
> 
> OK -- the main question for planning purposes is, does it seem like
> we can get this sorted out by the scheduled feature freeze on March
> 25?  At the moment I''m going to leave this as "Good".
Aye. 
> 
> >
> >
> >.. snip..
> >>* Persistent grants for net
> >>   owner: annie.li@citrix
> >>   status: Initial implementation posted
> >>   prognosis: ?
> >Shelved. The perf reports with Xen 4.2 did not show much improvement.
> >They should have but there is something amiss.
> >
> >goto b;
> 
> OK -- so I''ll put this down as "Not for 4.3".
Aye
> 
> >>* Multi-page blk rings (external)
> >>  - blkback in kernel (konrad@oracle, ?@intel)
> >>  - qemu blkback
> >>   status: Not started.
> >>   prognosis: UNKNOWN
> >goto c;
> 
> OK -- we still have a bit of time, so I''ll leave this with
Roger''s
> assessment of "Fair" for now.  We can always review the
assessment
> later.
OK. Most of this (all of it?) is Linux related. So I would say that if you
are trying to hit the March deadline (which is when 3.9 merge window
opens), that means Roger has one month to code this up.
> 
> >>* Multi-page net protocol (external)
> >>   owner: ijc@citrix or annie.li@oracle
> >>   status: Initial patches posted (by Wei Liu)
> >>   expand the network ring protocol to allow multiple pages for
> >>   increased throughput
> >goto b;
> 
> OK -- I''ll mark this as "Poor".
Aye.
> 
> >We might also put on this list:
> >
> >  - hardware performance counters.
> >   Investigate what is important.
> 
> This seems a bit to vague.  How do I know when it can be crossed off? :-)
Deferred to Xen 4.4 then. Right now cooking up the list of items
we would like to do and see which ones can be part of GSOC (if any?)
> 
>  -George
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
>