* Xen 4.4 development update @ 2013-09-16 13:06 George Dunlap 2013-09-16 13:28 ` Jan Beulich ` (6 more replies) 0 siblings, 7 replies; 116+ messages in thread From: George Dunlap @ 2013-09-16 13:06 UTC (permalink / raw) To: xen-devel This information will be mirrored on the Xen 4.4 Roadmap wiki page: http://wiki.xen.org/wiki/Xen_Roadmap/4.4 Rather than try to predict precisely what will make it into what release (which was something of a disaster last release), I'm just going to borrow a term from the Agile world and call all uncompleted features the "Backlog". I'll still track who is doing what, and when we get close, what state things seem to be in. As mentioned in another e-mail, we'll also be working on improving the regression tester. Feel free to join us. And as always, if you are working on a feature / bug that you want tracked, please respond to this e-mail. = Timeline = As discussed elsewhere, I am proposing a 6-month release cycle. Xen 4.3 was released on 9 July. That would give us a release on 9 January 2014. This is fairly close after the Christmas season, so I propose to make the estimated release date later, on 21 January, giving a few extra weeks for the holiday season: * Feature freeze: 18 October 2013 * Code freezing point: 8 November 2013 * First RC: 26 November 2013 * Release: 21 January 2014 Feedback on the estimated dates is welcome. Last updated: 16 September 2016 == Completed == * Multi-vector PCI MSI (Hypervisor side) == Open == * xend still in tree - xl list -l on a dom0-only system - xl list -l doesn't contain tty console port - Alternate transport support for migration * qemu-upstream not freeing pirq > http://www.gossamer-threads.com/lists/xen/devel/281498 status: patches posted, tested-and-acked * Race in PV shutdown between tool detection and shutdown watch > http://www.gossamer-threads.com/lists/xen/devel/282467 > Nothing to do with ACPI status: Probably a bug in Linux xen drivers * credit scheduler doesn't update other fields when tslice updated from sysctl > Reported by Luwei Cheng <lwcheng@cs.hku.hk> > http://bugs.xenproject.org/xen/bug/16 == Backlog == === Testing coverage === * new libxl w/ previous versions of xl @IanJ * Host S3 suspend @bguthro * Default [example] XSM policy @Stefano to ask Daniel D * Xen on ARM # hardware @ianc emulator: @stefano to think about it * Storage driver domains @roger * HVM pci passthrough @anthony * PV pce passthrough @konrad (or @george if he gets to it first) * Network driver domains @George * Nested virt? @intel (chased by George) * Fix SRIOV test (chase intel) @ianj * Fix bisector to e-mail blame-worthy parties @ianj * Fix xl shutdown @ianj * stub domains @athony * performance benchmarks @dario === Clean-ups === * Sort out better memory / ballooning / dom0 autoballooning thing > Don't forget NUMA angle - Inaccurate / incomplete info from HV * Implement Xen hypervisor dmesg log entry timestamps > https://xenorg.uservoice.com/forums/172169-xen-development/suggestions/3924048-implement-xen-hypervisor-dmesg-log-entry-timestamp > Request seems to be for a shorter stamp (seconds-only, rather than full date) * Make network driver domains easier to set up / more useful - Make it easy to make a device assignable (in discussion) - Automatically start/shutdown (xendomains?) - Pause booting of other domains until network driver domain is up (necessary?) * libxl: More fine-grained control over when to pass through a device > Some IOMMUs are secure; some are merely functional, some are not present. > Allow the adminitrator to set the default * xl does not handle migrate interruption gracefully > If you start a localhost migrate, and press "Ctrl-C" in the middle, > you get two hung domains * libxl / xl does not handle failure of remote qemu gracefully > Easiest way to reproduce: > - set "vncunused=0" and do a local migrate > - The "remote" qemu will fail because the vnc port is in use > The failure isn't the problem, but everything being stuck afterwards is * mac address changes on reboot if not specified in config file > Needs a robust way to "add" to the config * qxl > http://bugs.xenproject.org/xen/bug/11http://bugs.xenproject.org/xen/bug/11 - Uninitialized struct element in qemu - Revert 5479961 to re-enable qxl in xl,libxl - Option in Xen top-level to enable qxl support in qemu tree - Fix sse2 MMIO issue - make word size arbitrary * libxl config file * libxl: Don't use RAW format for "URL"-based qdisks (e.g., rbd:rbd/foo.img) - Figure out whether to use a generic URL or have a specific type for each one - Check existence of disk file for all RAW * Polish up xenbugtool owner: wei.liu2@citrix.com * acpi-related xenstore entries not propagated on migrate > http://www.gossamer-threads.com/lists/xen/devel/282466 > Only used by hvmloader; only a clean-up, not a bug. === Big ticket items === * NUMA Memory migration owner: dario@citrix status: in progress * Event channel scalability (FIFO event channels) owner: david@citrix status: RFC v3 posted Increase limit on event channels (currently 1024 for 32-bit guests, 4096 for 64-bit guests) * PVH mode (w/ Linux) owner: mukesh@oracle, george@citrix status (Linux): Acked, waiting for ABI to be nailed down status (Xen): v12 posted * ARM stuff: ?? * Meta: PVIO NUMA improvements - NUMA affinity for vcpus owner: Dario status: in progress - PV guest NUMA interface owner: Elena status: v2 posted - Sensible dom0 NUMA layout - Toolstack pinning backend thread / virq to appropraite d0 vcpu - NUMA-aware ballooning owner: Li Yechen status: in progress * HVM guest NUMA owner: Matt Wilson@amazon status: in progress (?) * qemu-upstream stubdom, Linux owner: anthony@citrix status: in progress qemu-upstream needs a more fully-featured libc than exists in mini-os. Either work on a minimalist linux-based stubdom with glibc, or port one of the BSD libcs to minios. * qemu-upstream stubdom, BSD libc owner: ianj@citrix * Network performance improvements owner: wei@citrix * Disk performance improvements * Xen EFI feature: Xen can boot from grub.efi owner: Daniel Kiper status: in progress * libvirt/libxl integration (external) > need a status update - owner: jfehlig@suse, dario@citrix * Default to credit2 status: Probably not for 4.4 - cpu pinning - NUMA affinity - cpu "reservation" * xenperf Owner: Boris Otovsky status: v1 patches posted * blktap3 owner: thanos@citrix status: on hold pending XenServer decision * Nested virtualization on Intel * Nested virtualization on AMD * xl USB pass-through for HVM guests using Qemu USB emulation owner: George status: v6 patch series posted * Rationalized backend scripts owner: roger@citrix status: patches posted * Scripts for driver domains (depends on backend scripts) owner: roger@citrix status: * Multi-vector PCI MSI (upstream Linux) owner: konrad@oracle * xl: passing more defaults in configuration in xl.conf owner: ? There are a number of options for which it might be useful to pass a default in xl.conf. For example, if we could have a default "backend" parameter for vifs, then it would be easy to switch back and forth between a backend in a driver domain and a backend in dom0. * xl PVUSB pass-through for PV guests * xl PVUSB pass-through for HVM guests owner: George status: ? xm/xend supports PVUSB pass-through to guests with PVUSB drivers (both PV and HVM guests). - port the xm/xend functionality to xl. - this PVUSB feature does not require support or emulation from Qemu. - upstream the Linux frontend/backend drivers. Current work-in-progress versions are in Konrad's git tree. - James Harper's GPLPV drivers for Windows include PVUSB frontend drivers. * Guest EFI booting - status: tianocore in-tree, some build problems. Needs new owner. * Xen EFI feature: pvops dom0 able to make use of EFI run-time services (external) owner: Daniel Kiper status: Just begun * New kexec implementation > dvrabel has some patches, but page tables need non-trivial changes. status: ? === Wishlist / someday === * Make storage migration possible owner: ? status: none There needs to be a way, either via command-line or via some hooks, that someone can build a "storage migration" feature on top of libxl or xl. * Full-VM snapshotting owner: ? status: none Have a way of coordinating the taking and restoring of VM memory and disk snapshots. This would involve some investigation into the best way to accomplish this. * VM Cloning owner: ? status: none Again, a way of coordinating the memory and disk aspects. Research into the best way to do this would probably go along with the snapshotting feature. * xl vm-{export,import} owner: ? status: none Allow xl to import and export VMs to other formats; particularly ovf, perhaps the XenServer format, or more. * Memory: Replace PoD with paging mechanism owner: george@citrix status: none * PV audio (audio for stubdom qemu) owner: stefano.panella@citrix status: ? * Wait queues for mm > Needed for more advanced paging schemes owner: ? status: Draft posted Feb 2012; more work to do. * V4V: Inter-domain communication owner (Xen): dominic.curran@citrix.com status (Xen): patches submitted owner (Linux driver): stefano.panella@citrix status (Linux driver): in progress * Serial console improvements owner: ? status: Stalled (see below) -xHCI debug port (Needs hardware) -Firewire (needs hardware) ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-16 13:06 Xen 4.4 development update George Dunlap @ 2013-09-16 13:28 ` Jan Beulich 2013-09-17 14:55 ` Andrew Cooper 2013-09-16 14:05 ` David Vrabel ` (5 subsequent siblings) 6 siblings, 1 reply; 116+ messages in thread From: Jan Beulich @ 2013-09-16 13:28 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel >>> On 16.09.13 at 15:06, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > == Open == * Supposed regression from a3513737 ("x86: allow guest to set/clear MSI-X mask bit (try 2)"), as per http://lists.xenproject.org/archives/html/xen-devel/2013-09/msg01589.html. > === Clean-ups === * ACPI WAET table vs RTC emulation mode An overly simplified fix was posted a while ago (http://lists.xenproject.org/archives/html/xen-devel/2013-07/msg00122.html), but Tim's objection is rather valid. I can't, however, estimate if/when I would find time to learn what tools side changes are necessary to accommodate a new HVM param, and hence this is currently stalled. The current solution (as of 3fa7fb8b ["x86/HVM: RTC code must be in line with WAET flags passed by hvmloader"]) isn't desirable to be kept for 4.4. Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-16 13:28 ` Jan Beulich @ 2013-09-17 14:55 ` Andrew Cooper 0 siblings, 0 replies; 116+ messages in thread From: Andrew Cooper @ 2013-09-17 14:55 UTC (permalink / raw) To: Jan Beulich; +Cc: George Dunlap, xen-devel On 16/09/2013 14:28, Jan Beulich wrote: >>>> On 16.09.13 at 15:06, George Dunlap <George.Dunlap@eu.citrix.com> wrote: >> == Open == > * Supposed regression from a3513737 ("x86: allow guest to set/clear > MSI-X mask bit (try 2)"), as per > http://lists.xenproject.org/archives/html/xen-devel/2013-09/msg01589.html. > >> === Clean-ups === > * ACPI WAET table vs RTC emulation mode > > An overly simplified fix was posted a while ago > (http://lists.xenproject.org/archives/html/xen-devel/2013-07/msg00122.html), > but Tim's objection is rather valid. I can't, however, estimate if/when > I would find time to learn what tools side changes are necessary to > accommodate a new HVM param, and hence this is currently stalled. > The current solution (as of 3fa7fb8b ["x86/HVM: RTC code must be > in line with WAET flags passed by hvmloader"]) isn't desirable to be > kept for 4.4. > > Jan Relatedly, there is still an outstanding regression in this code were Win2k3 Enterprise SP2 occasionally falls into an infinite loop probing the RTC. I still need to get to the bottom of why this is happening. ~Andrew ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-16 13:06 Xen 4.4 development update George Dunlap 2013-09-16 13:28 ` Jan Beulich @ 2013-09-16 14:05 ` David Vrabel 2013-09-16 14:06 ` David Vrabel ` (4 subsequent siblings) 6 siblings, 0 replies; 116+ messages in thread From: David Vrabel @ 2013-09-16 14:05 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel On 16/09/13 14:06, George Dunlap wrote: > > * New kexec implementation owner: David Vrabel status: v7 posted, only minor updates expected. David ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-16 13:06 Xen 4.4 development update George Dunlap 2013-09-16 13:28 ` Jan Beulich 2013-09-16 14:05 ` David Vrabel @ 2013-09-16 14:06 ` David Vrabel 2013-09-16 14:52 ` Fabio Fantoni ` (3 subsequent siblings) 6 siblings, 0 replies; 116+ messages in thread From: David Vrabel @ 2013-09-16 14:06 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel On 16/09/13 14:06, George Dunlap wrote: > > * New kexec implementation owner: David Vrabel status: v7 posted, only minor updates expected. David ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-16 13:06 Xen 4.4 development update George Dunlap ` (2 preceding siblings ...) 2013-09-16 14:06 ` David Vrabel @ 2013-09-16 14:52 ` Fabio Fantoni 2013-09-18 11:29 ` George Dunlap 2013-09-17 0:45 ` Ben Guthro ` (2 subsequent siblings) 6 siblings, 1 reply; 116+ messages in thread From: Fabio Fantoni @ 2013-09-16 14:52 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel Il 16/09/2013 15:06, George Dunlap ha scritto: > == Completed == * Improved Spice support on libxl - Added Spice vdagent support - Added Spice clipboard sharing support > > == Open == > * libxl: Spice usbredirection support for upstream qemu owner: fabio@M2R status: I'll post new patch version shortly * libxl: usb2 and usb3 controller support for upstream qemu owner: fabio@M2R status: patch v5 posted, tested and working, awaiting reviews ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-16 14:52 ` Fabio Fantoni @ 2013-09-18 11:29 ` George Dunlap 0 siblings, 0 replies; 116+ messages in thread From: George Dunlap @ 2013-09-18 11:29 UTC (permalink / raw) To: Fabio Fantoni; +Cc: xen-devel On 16/09/13 15:52, Fabio Fantoni wrote: > Il 16/09/2013 15:06, George Dunlap ha scritto: >> == Completed == > > * Improved Spice support on libxl > - Added Spice vdagent support > - Added Spice clipboard sharing support > > >> >> == Open == >> > * libxl: Spice usbredirection support for upstream qemu > owner: fabio@M2R > status: I'll post new patch version shortly > > > * libxl: usb2 and usb3 controller support for upstream qemu > owner: fabio@M2R > status: patch v5 posted, tested and working, awaiting reviews "Open" is for bugs -- I'll put these under "Backlog". Thanks. -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-16 13:06 Xen 4.4 development update George Dunlap ` (3 preceding siblings ...) 2013-09-16 14:52 ` Fabio Fantoni @ 2013-09-17 0:45 ` Ben Guthro 2013-09-17 7:14 ` Dario Faggioli 2013-09-17 19:18 ` Pasi Kärkkäinen 2013-09-20 15:57 ` Olaf Hering 6 siblings, 1 reply; 116+ messages in thread From: Ben Guthro @ 2013-09-17 0:45 UTC (permalink / raw) To: George Dunlap; +Cc: Dario Faggioli, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 318 bytes --] On Mon, Sep 16, 2013 at 9:06 AM, George Dunlap <George.Dunlap@eu.citrix.com>wrote: <snip> > > * Host S3 suspend > @bguthro > > Please add Dario to this, as well. He had graciously volunteered to look into this, with regard to osstest. In the last update, he said he would be looking into it sometime in Sept. Ben [-- Attachment #1.2: Type: text/html, Size: 823 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-17 0:45 ` Ben Guthro @ 2013-09-17 7:14 ` Dario Faggioli 2013-09-17 12:04 ` Ben Guthro 0 siblings, 1 reply; 116+ messages in thread From: Dario Faggioli @ 2013-09-17 7:14 UTC (permalink / raw) To: Ben Guthro; +Cc: George Dunlap, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 908 bytes --] On lun, 2013-09-16 at 20:45 -0400, Ben Guthro wrote: > On Mon, Sep 16, 2013 at 9:06 AM, George Dunlap > <George.Dunlap@eu.citrix.com> wrote: > > > <snip> > > * Host S3 suspend > @bguthro > > > > Please add Dario to this, as well. > He had graciously volunteered to look into this, with regard to > osstest. > Indeed I did... And of course I'm a bit behind. Anyway, yes, George, add me here. BTW, Ben, could you send me (either here or in private) some hints on how you usually test S3? I'll then look into how to translate that into a test case. Thanks and Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-17 7:14 ` Dario Faggioli @ 2013-09-17 12:04 ` Ben Guthro 2013-09-18 15:36 ` George Dunlap 0 siblings, 1 reply; 116+ messages in thread From: Ben Guthro @ 2013-09-17 12:04 UTC (permalink / raw) To: Dario Faggioli; +Cc: George Dunlap, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 1354 bytes --] On Tue, Sep 17, 2013 at 3:14 AM, Dario Faggioli <dario.faggioli@citrix.com>wrote: > On lun, 2013-09-16 at 20:45 -0400, Ben Guthro wrote: > > > > On Mon, Sep 16, 2013 at 9:06 AM, George Dunlap > > <George.Dunlap@eu.citrix.com> wrote: > > > > > > <snip> > > > > * Host S3 suspend > > @bguthro > > > > > > > > Please add Dario to this, as well. > > He had graciously volunteered to look into this, with regard to > > osstest. > > > Indeed I did... And of course I'm a bit behind. Anyway, yes, George, add > me here. > > BTW, Ben, could you send me (either here or in private) some hints on > how you usually test S3? I'll then look into how to translate that into > a test case. > Here are a few threads from the past when I have done so, and one where I made a failed attempt to create a test case: http://markmail.org/message/4piyk3ztagsm7ueb#query:+page:1+mid:6pc5lnrtrmd7hmrr+state:results http://markmail.org/message/lzolxkwipnyc7hqj http://xen.markmail.org/thread/ghj2ffngemccq6p4 Hopefully, these will be helpful. Thanks Ben > > Thanks and Regards, > Dario > > -- > <<This happens because I choose it to happen!>> (Raistlin Majere) > ----------------------------------------------------------------- > Dario Faggioli, Ph.D, http://about.me/dario.faggioli > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) > > [-- Attachment #1.2: Type: text/html, Size: 2643 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-17 12:04 ` Ben Guthro @ 2013-09-18 15:36 ` George Dunlap 0 siblings, 0 replies; 116+ messages in thread From: George Dunlap @ 2013-09-18 15:36 UTC (permalink / raw) To: Ben Guthro; +Cc: Dario Faggioli, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 1457 bytes --] On 17/09/13 13:04, Ben Guthro wrote: > > > > On Tue, Sep 17, 2013 at 3:14 AM, Dario Faggioli > <dario.faggioli@citrix.com <mailto:dario.faggioli@citrix.com>> wrote: > > On lun, 2013-09-16 at 20:45 -0400, Ben Guthro wrote: > > > > On Mon, Sep 16, 2013 at 9:06 AM, George Dunlap > > <George.Dunlap@eu.citrix.com > <mailto:George.Dunlap@eu.citrix.com>> wrote: > > > > > > <snip> > > > > * Host S3 suspend > > @bguthro > > > > > > > > Please add Dario to this, as well. > > He had graciously volunteered to look into this, with regard to > > osstest. > > > Indeed I did... And of course I'm a bit behind. Anyway, yes, > George, add > me here. > > BTW, Ben, could you send me (either here or in private) some hints on > how you usually test S3? I'll then look into how to translate that > into > a test case. > > > Here are a few threads from the past when I have done so, and one > where I made a failed attempt to create a test case: > http://markmail.org/message/4piyk3ztagsm7ueb#query:+page:1+mid:6pc5lnrtrmd7hmrr+state:results > http://markmail.org/message/lzolxkwipnyc7hqj > http://xen.markmail.org/thread/ghj2ffngemccq6p4 > > Hopefully, these will be helpful. So one aspect of getting this testing automated would be to make the "wake up timer" a proper HV parameter, rather than a patch that has to be pasted on for testing. -George [-- Attachment #1.2: Type: text/html, Size: 3610 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-16 13:06 Xen 4.4 development update George Dunlap ` (4 preceding siblings ...) 2013-09-17 0:45 ` Ben Guthro @ 2013-09-17 19:18 ` Pasi Kärkkäinen 2013-09-18 16:59 ` George Dunlap 2013-09-20 15:57 ` Olaf Hering 6 siblings, 1 reply; 116+ messages in thread From: Pasi Kärkkäinen @ 2013-09-17 19:18 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel On Mon, Sep 16, 2013 at 02:06:23PM +0100, George Dunlap wrote: > > == Backlog == > > === Testing coverage === > > > * HVM pci passthrough > @anthony > Is this entry about the mismatch of hvmloader/seabios/qemu-upstream memory ranges / BAR mapping? -- Pasi ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-17 19:18 ` Pasi Kärkkäinen @ 2013-09-18 16:59 ` George Dunlap 0 siblings, 0 replies; 116+ messages in thread From: George Dunlap @ 2013-09-18 16:59 UTC (permalink / raw) To: Pasi Kärkkäinen; +Cc: xen-devel On 17/09/13 20:18, Pasi Kärkkäinen wrote: > On Mon, Sep 16, 2013 at 02:06:23PM +0100, George Dunlap wrote: >> == Backlog == >> >> === Testing coverage === >> >> >> * HVM pci passthrough >> @anthony >> > Is this entry about the mismatch of hvmloader/seabios/qemu-upstream memory ranges / BAR mapping? This entry is about getting a test case into osstest that will test HVM pci passthrough so that we can detect regressions early. -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-16 13:06 Xen 4.4 development update George Dunlap ` (5 preceding siblings ...) 2013-09-17 19:18 ` Pasi Kärkkäinen @ 2013-09-20 15:57 ` Olaf Hering 2013-09-20 16:04 ` George Dunlap 6 siblings, 1 reply; 116+ messages in thread From: Olaf Hering @ 2013-09-20 15:57 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel On Mon, Sep 16, George Dunlap wrote: > * xend still in tree > - xl list -l on a dom0-only system > - xl list -l doesn't contain tty console port > - Alternate transport support for migration libxl has no pvscsi support. This is listed as "SCSI LUN/Host passthrough (PVSCSI)" in the page below. Is PVUSB already handled by libxl? http://wiki.xen.org/wiki/XL_vs_Xend_Feature_Comparison Olaf ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-20 15:57 ` Olaf Hering @ 2013-09-20 16:04 ` George Dunlap 2013-09-23 7:24 ` Jan Beulich 2013-09-23 8:48 ` Olaf Hering 0 siblings, 2 replies; 116+ messages in thread From: George Dunlap @ 2013-09-20 16:04 UTC (permalink / raw) To: Olaf Hering; +Cc: xen-devel On 20/09/13 16:57, Olaf Hering wrote: > On Mon, Sep 16, George Dunlap wrote: > >> * xend still in tree >> - xl list -l on a dom0-only system >> - xl list -l doesn't contain tty console port >> - Alternate transport support for migration > libxl has no pvscsi support. This is listed as "SCSI LUN/Host > passthrough (PVSCSI)" in the page below. > > Is PVUSB already handled by libxl? > > http://wiki.xen.org/wiki/XL_vs_Xend_Feature_Comparison Are you personally using PVSCSI, and/or pvusb, and/or do you know any large downstreams and/or user bases that depend on them? There was never any intention of making xl have every single feature of xend; only the features that people cared enough about to argue for / implement themselves. The list above was generated from a recent discussion of why Oracle and Amazon object to removing xend at this time. If these is an important feature to you, the time to say something about it was 1 year ago. That said, pvusb should be really simple to do once we have the HVM hot-plug support; I've got a patch series that just needs to be cleaned up and submitted. It's on my short list of things to do, but realistically looking like it's not going to happen for 4.4 (unless we reconsider the release cycle length). If you're interested in taking it over, I'd be happy to hand it off to you. -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-20 16:04 ` George Dunlap @ 2013-09-23 7:24 ` Jan Beulich 2013-09-23 11:22 ` George Dunlap 2013-09-23 11:48 ` George Dunlap 2013-09-23 8:48 ` Olaf Hering 1 sibling, 2 replies; 116+ messages in thread From: Jan Beulich @ 2013-09-23 7:24 UTC (permalink / raw) To: Olaf Hering, George Dunlap; +Cc: xen-devel >>> On 20.09.13 at 18:04, George Dunlap <george.dunlap@eu.citrix.com> wrote: > On 20/09/13 16:57, Olaf Hering wrote: >> On Mon, Sep 16, George Dunlap wrote: >> >>> * xend still in tree >>> - xl list -l on a dom0-only system >>> - xl list -l doesn't contain tty console port >>> - Alternate transport support for migration >> libxl has no pvscsi support. This is listed as "SCSI LUN/Host >> passthrough (PVSCSI)" in the page below. > > >> >> Is PVUSB already handled by libxl? >> >> http://wiki.xen.org/wiki/XL_vs_Xend_Feature_Comparison > > Are you personally using PVSCSI, and/or pvusb, and/or do you know any > large downstreams and/or user bases that depend on them? We certainly have customers using pvSCSI (for some I perhaps should say "would like to", as so far they can't due to limitations of the protocol). > There was never any intention of making xl have every single feature of > xend; only the features that people cared enough about to argue for / > implement themselves. The list above was generated from a recent > discussion of why Oracle and Amazon object to removing xend at this > time. If these is an important feature to you, the time to say > something about it was 1 year ago. I'm pretty certain the question of both pvSCSI and pvUSB not being there in xl was raised before. And no, I don't agree with your initial statement. The outcome of the most recent community call was "make all regressions of xl vs xm a blocker for 4.4". Of course I don't read this to imply features no-one uses, but I certainly read this to cover features that some people use, even if they're not a majority. And the use case for pvSCSI is pretty obvious: Without it, in order to do e.g. a tape backup, you have to PCI-pass-through a whole HBA to a guest instead of just the single SCSI tape device that you need the guest to have access to. Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-23 7:24 ` Jan Beulich @ 2013-09-23 11:22 ` George Dunlap 2013-09-23 11:48 ` George Dunlap 1 sibling, 0 replies; 116+ messages in thread From: George Dunlap @ 2013-09-23 11:22 UTC (permalink / raw) To: Jan Beulich; +Cc: Lars Kurth, Olaf Hering, Ian Campbell, Ian Jackson, xen-devel On 23/09/13 08:24, Jan Beulich wrote: > And no, I don't agree with your initial statement. The outcome of > the most recent community call was "make all regressions of xl vs > xm a blocker for 4.4". Of course I don't read this to imply features > no-one uses, but I certainly read this to cover features that some > people use, even if they're not a majority. Any decision about the direction of where Xen goes needs to be made in public. Everyone who has a stake needs to be able to see the reasoning that went into it, and challenge it and make their own viewpoint known if necessary. The community call cannot do this -- the call is not recorded, so no one can listen in to the discussion to see what the reasoning was, and no one can retroactively go back and enter the discussion to affect the outcome. The community call is good for significant contributors to more effectively discuss what the positions of the individual people on the call are, what problems there are, and quickly brainstorm solutions or compromises that work for everyone. But if the people on the call decide something, all it means is that the individual people on the call have decided -- it's not binding on the community until it has been discussed on the list. Obviously the people on the call carry a lot of weight in the community, so it's likely that anything decided there will ultimately be decided here; but it's not something that can be taken for granted. -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-23 7:24 ` Jan Beulich 2013-09-23 11:22 ` George Dunlap @ 2013-09-23 11:48 ` George Dunlap 2013-09-23 12:13 ` Jan Beulich 1 sibling, 1 reply; 116+ messages in thread From: George Dunlap @ 2013-09-23 11:48 UTC (permalink / raw) To: Jan Beulich; +Cc: Olaf Hering, xen-devel On 23/09/13 08:24, Jan Beulich wrote: >>>> On 20.09.13 at 18:04, George Dunlap <george.dunlap@eu.citrix.com> wrote: >> On 20/09/13 16:57, Olaf Hering wrote: >>> On Mon, Sep 16, George Dunlap wrote: >>> >>>> * xend still in tree >>>> - xl list -l on a dom0-only system >>>> - xl list -l doesn't contain tty console port >>>> - Alternate transport support for migration >>> libxl has no pvscsi support. This is listed as "SCSI LUN/Host >>> passthrough (PVSCSI)" in the page below. >> >>> Is PVUSB already handled by libxl? >>> >>> http://wiki.xen.org/wiki/XL_vs_Xend_Feature_Comparison >> Are you personally using PVSCSI, and/or pvusb, and/or do you know any >> large downstreams and/or user bases that depend on them? > We certainly have customers using pvSCSI (for some I perhaps > should say "would like to", as so far they can't due to limitations > of the protocol). > >> There was never any intention of making xl have every single feature of >> xend; only the features that people cared enough about to argue for / >> implement themselves. The list above was generated from a recent >> discussion of why Oracle and Amazon object to removing xend at this >> time. If these is an important feature to you, the time to say >> something about it was 1 year ago. > I'm pretty certain the question of both pvSCSI and pvUSB not > being there in xl was raised before. > > And no, I don't agree with your initial statement. The outcome of > the most recent community call was "make all regressions of xl vs > xm a blocker for 4.4". Of course I don't read this to imply features > no-one uses, but I certainly read this to cover features that some > people use, even if they're not a majority. Well, that's exactly the sticking point -- what is a "feature no-one uses" and not? How are we to know if we don't have this kind of discussion and ask about it? That's my point -- we've been saying, "we're going to get rid of xend soon, let us know what features are missing from xl" for two years now. It's time to actually make a list of specific features which are blockers and get them implemented. And I don't think we should just give every feature of xend a pass. I don't really think we *can* if we wanted to -- for instance, we can't allow executable python code in the config file. According to the rubric you propose above, then if there's one guy who is using python in his config files, then we're stuck with xend forever. Furthermore, ultimately code talks. If those features are valuable, then it should be worth someone's time to implement them in xl. If they're not valuable enough for someone to implement, then are they really valuable enough to keep? I think that if the people on the community call want those features, it's time to put their money where their mouth is and actually implement them in xl. > And the use case for pvSCSI is pretty obvious: Without it, in order > to do e.g. a tape backup, you have to PCI-pass-through a whole > HBA to a guest instead of just the single SCSI tape device that > you need the guest to have access to. It's obvious if you know people who do that, but I don't. This is what I was asking Olaf for. I wouldn't consider this a blocker just to check a box on the feature list. But if you've got a number of customers using it, then of course it's an important feature, and we should try to implement it before dropping xend. (Though again, I think that at some point, if it's not important enough for someone to implement, it's not important enough to keep supporting.) -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-23 11:48 ` George Dunlap @ 2013-09-23 12:13 ` Jan Beulich 2013-09-23 12:50 ` George Dunlap 0 siblings, 1 reply; 116+ messages in thread From: Jan Beulich @ 2013-09-23 12:13 UTC (permalink / raw) To: George Dunlap; +Cc: Olaf Hering, xen-devel >>> On 23.09.13 at 13:48, George Dunlap <george.dunlap@eu.citrix.com> wrote: > (Though again, I think that at some > point, if it's not important enough for someone to implement, it's not > important enough to keep supporting.) I accept that this is one way of viewing things, but as someone implementing hypervisor side stuff for people even if neither I nor customers of my employer immediately need it, I think it is not completely off to expect some symmetry here: I think it is reasonable for someone to point out deficiencies in areas (s)he doesn't normally work on, and expect those responsible for these areas to pick this up unless it's completely off. But yes, this request could/should have been made earlier. Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-23 12:13 ` Jan Beulich @ 2013-09-23 12:50 ` George Dunlap 0 siblings, 0 replies; 116+ messages in thread From: George Dunlap @ 2013-09-23 12:50 UTC (permalink / raw) To: Jan Beulich; +Cc: Olaf Hering, xen-devel On 23/09/13 13:13, Jan Beulich wrote: >>>> On 23.09.13 at 13:48, George Dunlap <george.dunlap@eu.citrix.com> wrote: >> (Though again, I think that at some >> point, if it's not important enough for someone to implement, it's not >> important enough to keep supporting.) > I accept that this is one way of viewing things, but as someone > implementing hypervisor side stuff for people even if neither I nor > customers of my employer immediately need it, I think it is not > completely off to expect some symmetry here: I think it is > reasonable for someone to point out deficiencies in areas (s)he > doesn't normally work on, and expect those responsible for > these areas to pick this up unless it's completely off. Fair enough. :-) -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-20 16:04 ` George Dunlap 2013-09-23 7:24 ` Jan Beulich @ 2013-09-23 8:48 ` Olaf Hering 2013-09-23 10:29 ` Pasi Kärkkäinen 1 sibling, 1 reply; 116+ messages in thread From: Olaf Hering @ 2013-09-23 8:48 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel On Fri, Sep 20, George Dunlap wrote: > On 20/09/13 16:57, Olaf Hering wrote: > >On Mon, Sep 16, George Dunlap wrote: > > > >>* xend still in tree > >> - xl list -l on a dom0-only system > >> - xl list -l doesn't contain tty console port > >> - Alternate transport support for migration > >libxl has no pvscsi support. This is listed as "SCSI LUN/Host > >passthrough (PVSCSI)" in the page below. > > > > > >Is PVUSB already handled by libxl? > > > >http://wiki.xen.org/wiki/XL_vs_Xend_Feature_Comparison > > Are you personally using PVSCSI, and/or pvusb, and/or do you know any large > downstreams and/or user bases that depend on them? I'm not using it myself. At least two different customers were using it. As Jan said in his reply, we should not silently drop functionality. > That said, pvusb should be really simple to do once we have the HVM hot-plug > support; I've got a patch series that just needs to be cleaned up and > submitted. It's on my short list of things to do, but realistically looking > like it's not going to happen for 4.4 (unless we reconsider the release > cycle length). If you're interested in taking it over, I'd be happy to hand > it off to you. Up to now I have not looked at pvusb. I will do so in the next days. Olaf ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-23 8:48 ` Olaf Hering @ 2013-09-23 10:29 ` Pasi Kärkkäinen 0 siblings, 0 replies; 116+ messages in thread From: Pasi Kärkkäinen @ 2013-09-23 10:29 UTC (permalink / raw) To: Olaf Hering; +Cc: George Dunlap, James Harper, xen-devel On Mon, Sep 23, 2013 at 10:48:13AM +0200, Olaf Hering wrote: > On Fri, Sep 20, George Dunlap wrote: > > > On 20/09/13 16:57, Olaf Hering wrote: > > >On Mon, Sep 16, George Dunlap wrote: > > > > > >>* xend still in tree > > >> - xl list -l on a dom0-only system > > >> - xl list -l doesn't contain tty console port > > >> - Alternate transport support for migration > > >libxl has no pvscsi support. This is listed as "SCSI LUN/Host > > >passthrough (PVSCSI)" in the page below. > > > > > > > > > >Is PVUSB already handled by libxl? > > > > > >http://wiki.xen.org/wiki/XL_vs_Xend_Feature_Comparison > > > > Are you personally using PVSCSI, and/or pvusb, and/or do you know any large > > downstreams and/or user bases that depend on them? > > I'm not using it myself. At least two different customers were using it. > As Jan said in his reply, we should not silently drop functionality. > Earlier James Harper mentioned on xen-devel that he'd take a look at implementing PVSCSI in xl/libxl, because he's using Xen PVSCSI for tape backups, but I don't think he got to it so far... > > That said, pvusb should be really simple to do once we have the HVM hot-plug > > support; I've got a patch series that just needs to be cleaned up and > > submitted. It's on my short list of things to do, but realistically looking > > like it's not going to happen for 4.4 (unless we reconsider the release > > cycle length). If you're interested in taking it over, I'd be happy to hand > > it off to you. > > Up to now I have not looked at pvusb. I will do so in the next days. > A lot of Xen users are asking for PVUSB, it's being discussed often on ##xen and on mailinglists, but it isn't very easy to use these days because of the out-of-tree usbback/usbfront drivers, and toolstack support only in xm/xend. -- Pasi ^ permalink raw reply [flat|nested] 116+ messages in thread
* Xen 4.4 development update @ 2014-01-27 18:49 George Dunlap 2014-01-27 18:51 ` George Dunlap ` (2 more replies) 0 siblings, 3 replies; 116+ messages in thread From: George Dunlap @ 2014-01-27 18:49 UTC (permalink / raw) To: xen-devel This information will be mirrored on the Xen 4.4 Roadmap wiki page: http://wiki.xen.org/wiki/Xen_Roadmap/4.4 I've just spent some time going through xen-devel, and it looks like the main blocker we know about is the Windows install BSOD introduced with the update to qemu 1.6. I've divided the list of open bugs into "Open" (might be for 4.4) and "Open, not for 4.4". If there are any other important bugs that need to be considered for this release which are not on the first list, please let me know. It's probably about time to start looking at "cross-compatibility" test matrix: * Migrating from 4.3 to 4.4 * Compiling applications written for 4.3's libxl against 4.4's libxl Anything else I missed? The next question is: Once the qemu issue is fixed, how much more testing do we need before we can be confident we've caught all the necessary bugs? I'm inclined to say that if we do one more test day and wait a week, we should be ready. Thoughts? = Timeline = Here is our current timeline based on a 6-month release: * Feature freeze: 18 October 2013 * Code freezing point: 18 November 2013 * First RCs: 6 December 2013 <== WE ARE HERE * Release: When it's ready (Probably by the end of February). Last updated: 27 January 2014 == Completed == * Event channel scalability (FIFO event channels) * Non-udev scripts for driver domains (non-Linux driver domains) * Multi-vector PCI MSI (Hypervisor side) * Improved Spice support on libxl - Added Spice vdagent support - Added Spice clipboard sharing support - Spice usbredirection support for upstream qemu * PHV domU (experimental only) * pvgrub2 checked into grub upstream * ARM64 guest * Guest EFI booting (tianocore) * kexec * Testing: Xen on ARM * Update to SeaBIOS 1.7.3.1 * Update to qemu 1.6.2 * SWIOTLB (in Linux 3.13) * Disk: indirect descriptors (in 3.11) * Reworked ocaml bindings == Resolved since last update == * xl support for vnc and vnclisten options with PV guests * xl needs to disallow PoD with PCI passthrough == Open == * osstest windows-install failures > http://bugs.xenproject.org/xen/bug/29 > http://www.chiark.greenend.org.uk/~xensrcts/logs/24250/ Anthony investigating Blocker * qemu-* parses "008" as octal in USB bus.addr format > http://bugs.xenproject.org/xen/bug/15 > just needs documenting Anthony Perard to patch docs * libxl / xl does not handle failure of remote qemu gracefully > Related to http://bugs.xenproject.org/xen/bug/30 > Easiest way to reproduce: > - set "vncunused=0" and do a local migrate > - The "remote" qemu will fail because the vnc port is in use > The failure isn't the problem, but everything being stuck afterwards is Ian J investigating * Claim mode and PoD > http://bugs.xenproject.org/xen/bug/32 Probably not a blocker, but easily fixed status: Patch posted * Disable IOMMU if no southbridge > http://bugs.xenproject.org/xen/bug/37 * qemu memory leak? > http://lists.xen.org/archives/html/xen-users/2013-03/msg00276.html == Open, not for 4.4 == * qemu-upstream not freeing pirq > http://www.gossamer-threads.com/lists/xen/devel/281498 > http://marc.info/?l=xen-devel&m=137265766424502 status: patches posted; latest patches need testing it hasn't been tested because of the other passthrough issues. Not a blocker. * Race in PV shutdown between tool detection and shutdown watch > http://www.gossamer-threads.com/lists/xen/devel/282467 > Nothing to do with ACPI status: Patches posted, need more work, will be stalled for some time The fix is to the Linux side of things. Not a blocker. * xl does not support specifying virtual function for passthrough device > http://bugs.xenproject.org/xen/bug/22 Too much work to be a blocker. * xl does not handle migrate interruption gracefully > If you start a localhost migrate, and press "Ctrl-C" in the middle, > you get two hung domains Ian J investigated -- can of worms, too big to be a blocker for 4.4 * Win2k3 SP2 RTC infinite loops > Regression introduced late in Xen-4.3 development owner: andrew.cooper@citrix status: patches posted, undergoing review. ( v2 ID 1386241748-9617-1-git-send-email-andrew.cooper3@citrix.com ) > andyhhp: my proposed RTC fixes break migrate from older versions of > Xen, so I have to redesign it from scratch. no way it is going to > be ready for 4.4 * HPET interrupt stack overflow (when using hpet_broadcast mode and MSI capable HPETs) owner: andyh@citrix status: patches posted, undergoing review iteration. > andyhhp: I have more work to do on the HPET series > andyhhp: no way it is going to be ready or safe for 4.4 * PCI hole resize support hvmloader/qemu-traditional/qemu-upstream with PCI/GPU passthrough > http://bugs.xenproject.org/xen/bug/28 > http://lists.xen.org/archives/html/xen-devel/2013-05/msg02813.html > Where Stefano writes: > 2) for Xen 4.4 rework the two patches above and improve > i440fx_update_pci_mem_hole: resizing the pci_hole subregion is not > enough, it also needs to be able to resize the system memory region > (xen.ram) to make room for the bigger pci_hole status: not going to be fixed for 4.4 either. Created bug #28. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2014-01-27 18:49 George Dunlap @ 2014-01-27 18:51 ` George Dunlap 2014-01-27 23:52 ` Jim Fehlig 2014-01-28 10:37 ` Jan Beulich 2 siblings, 0 replies; 116+ messages in thread From: George Dunlap @ 2014-01-27 18:51 UTC (permalink / raw) To: xen-devel; +Cc: Diana Crisan, Alex Bligh On Mon, Jan 27, 2014 at 6:49 PM, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > It's probably about time to start looking at "cross-compatibility" > test matrix: > > * Migrating from 4.3 to 4.4 > > * Compiling applications written for 4.3's libxl against 4.4's libxl Diana / Alex: I think I recall that you guys had your own toolstack that you were compiling against libxl. If you guys could spare a few cycles, it would be really helpful to try the new 4.4 libxl and make sure that we're being suitable backwards-compatible. Thanks, -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2014-01-27 18:49 George Dunlap 2014-01-27 18:51 ` George Dunlap @ 2014-01-27 23:52 ` Jim Fehlig 2014-01-28 10:37 ` Jan Beulich 2 siblings, 0 replies; 116+ messages in thread From: Jim Fehlig @ 2014-01-27 23:52 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel George Dunlap wrote: > It's probably about time to start looking at "cross-compatibility" > test matrix: > > * Migrating from 4.3 to 4.4 > > * Compiling applications written for 4.3's libxl against 4.4's libxl > The libvirt libxl driver compiles cleanly with 4.2, 4.3, and 4.4 libxl. Regards, Jim ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2014-01-27 18:49 George Dunlap 2014-01-27 18:51 ` George Dunlap 2014-01-27 23:52 ` Jim Fehlig @ 2014-01-28 10:37 ` Jan Beulich 2 siblings, 0 replies; 116+ messages in thread From: Jan Beulich @ 2014-01-28 10:37 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel >>> On 27.01.14 at 19:49, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > * Disable IOMMU if no southbridge > > http://bugs.xenproject.org/xen/bug/37 Patch posted (for testing by the reporter of the problem), but certainly not even coming close to being a blocker. Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Xen 4.4 development update @ 2014-01-08 13:16 Ian Campbell 2014-01-08 13:29 ` Ian Campbell ` (3 more replies) 0 siblings, 4 replies; 116+ messages in thread From: Ian Campbell @ 2014-01-08 13:16 UTC (permalink / raw) To: xen-devel; +Cc: George Dunlap I'm filing in for George while he is on vacation and travelling to a conference etc. I'm still coming up to speed wrt what is going on with this release so please do correct me when I'm wrong. George will be back on 20 January. This information will be mirrored on the Xen 4.4 Roadmap wiki page: http://wiki.xen.org/wiki/Xen_Roadmap/4.4 We tagged 4.4.0-rc1 on 19 December. Based on the conversation had last time and on George's final comments in [1] I think this means that PVH dom0 support has not made the cut for 4.4, which is a shame but there is plenty of good functionality (including PVH domU support) in there. [1] http://bugs.xenproject.org/xen/mid/%3C52B05C0A.4040404@eu.citrix.com%3E = Timeline = Here is our current timeline based on a 6-month release: * Feature freeze: 18 October 2013 * Code freezing point: 18 November 2013 * First RCs: 6 December 2013 <== WE ARE HERE * Release: 21 January 2014 Last updated: 8 January 2014 == Completed == * Event channel scalability (FIFO event channels) * Non-udev scripts for driver domains (non-Linux driver domains) * Multi-vector PCI MSI (Hypervisor side) * Improved Spice support on libxl - Added Spice vdagent support - Added Spice clipboard sharing support - Spice usbredirection support for upstream qemu * PHV domU (experimental only) * pvgrub2 checked into grub upstream * ARM64 guest * Guest EFI booting (tianocore) * kexec * Testing: Xen on ARM * Update to SeaBIOS 1.7.3.1 * Update to qemu 1.6 * SWIOTLB (in Linux 3.13) * Disk: indirect descriptors (in 3.11) * Reworked ocaml bindings == Resolved since last update == == Open == * xl support for vnc and vnclisten options with PV guests > http://bugs.xenproject.org/xen/bug/25 status: V4 patch posted. Should go in. Blocker? * libxl / xl does not handle failure of remote qemu gracefully > Related to http://bugs.xenproject.org/xen/bug/29 > Easiest way to reproduce: > - set "vncunused=0" and do a local migrate > - The "remote" qemu will fail because the vnc port is in use > The failure isn't the problem, but everything being stuck afterwards is Ian J investigating * xl needs to disallow PoD with PCI passthrough >see http://xen.1045712.n5.nabble.com/PATCH-VT-d-Dis-allow-PCI-device-assignment-if-PoD-is-enabled-td2547788.html * qemu-upstream not freeing pirq > http://www.gossamer-threads.com/lists/xen/devel/281498 > http://marc.info/?l=xen-devel&m=137265766424502 status: patches posted; latest patches need testing Not a blocker. * Race in PV shutdown between tool detection and shutdown watch > http://www.gossamer-threads.com/lists/xen/devel/282467 > Nothing to do with ACPI status: Patches posted Not a blocker. * xl does not support specifying virtual function for passthrough device > http://bugs.xenproject.org/xen/bug/22 Too much work to be a blocker. * xl does not handle migrate interruption gracefully > If you start a localhost migrate, and press "Ctrl-C" in the middle, > you get two hung domains Ian J investigated -- can of worms, too big to be a blocker for 4.4 * Win2k3 SP2 RTC infinite loops > Regression introduced late in Xen-4.3 development owner: andrew.cooper@citrix status: patches posted, undergoing review. ( v2 ID 1386241748-9617-1-git-send-email-andrew.cooper3@citrix.com ) > andyhhp: my proposed RTC fixes break migrate from older versions of > Xen, so I have to redesign it from scratch. no way it is going to > be ready for 4.4 * HPET interrupt stack overflow (when using hpet_broadcast mode and MSI capable HPETs) owner: andyh@citrix status: patches posted, undergoing review iteration. > andyhhp: I have more work to do on the HPET series > andyhhp: no way it is going to be ready or safe for 4.4 * PCI hole resize support hvmloader/qemu-traditional/qemu-upstream with PCI/GPU passthrough > http://bugs.xenproject.org/xen/bug/28 > http://lists.xen.org/archives/html/xen-devel/2013-05/msg02813.html > Where Stefano writes: > 2) for Xen 4.4 rework the two patches above and improve > i440fx_update_pci_mem_hole: resizing the pci_hole subregion is not > enough, it also needs to be able to resize the system memory region > (xen.ram) to make room for the bigger pci_hole status: not going to be fixed for 4.4 either. Created bug #28. * qemu memory leak? > http://lists.xen.org/archives/html/xen-users/2013-03/msg00276.html * qemu-* parses "008" as octal in USB bus.addr format > http://bugs.xenproject.org/xen/bug/15 > just needs documenting Anthony Perard to patch docs * osstest windows-install failures > http://bugs.xenproject.org/xen/bug/29 > http://www.chiark.greenend.org.uk/~xensrcts/logs/24250/ Anthony and/or Jan investigating === Big ticket items === * PVH dom0 (w/ Linux) blocker owner: mukesh@oracle, george@citrix status (Linux): Acked, waiting for ABI to be nailed down status (Xen): v6 posted; no longer considered a blocker * libvirt/libxl integration (external) - owner: jfehlig@suse, dario@citrix - patches posted (should be released before 4.4) - migration - PCI pass-through - In progress - integration w/ libvirt's lock manager - improved concurrency ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2014-01-08 13:16 Ian Campbell @ 2014-01-08 13:29 ` Ian Campbell 2014-01-08 13:30 ` Ian Campbell 2014-01-08 14:21 ` Sander Eikelenboom ` (2 subsequent siblings) 3 siblings, 1 reply; 116+ messages in thread From: Ian Campbell @ 2014-01-08 13:29 UTC (permalink / raw) To: xen-devel; +Cc: George Dunlap On Wed, 2014-01-08 at 13:16 +0000, Ian Campbell wrote: > > * libxl / xl does not handle failure of remote qemu gracefully > > Related to http://bugs.xenproject.org/xen/bug/29 This should be http://bugs.xenproject.org/xen/bug/30 http://bugs.xenproject.org/xen/bug/29 is * Windows install failures/BSOD > http://bugs.xenproject.org/xen/bug/29 status: Anthony attempting to reproduce Blocker which I forgot to list. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2014-01-08 13:29 ` Ian Campbell @ 2014-01-08 13:30 ` Ian Campbell 0 siblings, 0 replies; 116+ messages in thread From: Ian Campbell @ 2014-01-08 13:30 UTC (permalink / raw) To: xen-devel; +Cc: George Dunlap On Wed, 2014-01-08 at 13:29 +0000, Ian Campbell wrote: > On Wed, 2014-01-08 at 13:16 +0000, Ian Campbell wrote: > > > > * libxl / xl does not handle failure of remote qemu gracefully > > > Related to http://bugs.xenproject.org/xen/bug/29 > > This should be http://bugs.xenproject.org/xen/bug/30 > > http://bugs.xenproject.org/xen/bug/29 is > > * Windows install failures/BSOD > > http://bugs.xenproject.org/xen/bug/29 > status: Anthony attempting to reproduce > Blocker > > which I forgot to list. Except I didn't -- it was at the end... ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2014-01-08 13:16 Ian Campbell 2014-01-08 13:29 ` Ian Campbell @ 2014-01-08 14:21 ` Sander Eikelenboom 2014-01-08 14:23 ` Ian Campbell 2014-01-08 14:35 ` Wei Liu 2014-01-16 6:54 ` Zhang, Yang Z 3 siblings, 1 reply; 116+ messages in thread From: Sander Eikelenboom @ 2014-01-08 14:21 UTC (permalink / raw) To: Ian Campbell; +Cc: George Dunlap, xen-devel Wednesday, January 8, 2014, 2:16:24 PM, you wrote: > I'm filing in for George while he is on vacation and travelling to a > conference etc. I'm still coming up to speed wrt what is going on with > this release so please do correct me when I'm wrong. George will be > back on 20 January. > This information will be mirrored on the Xen 4.4 Roadmap wiki page: > http://wiki.xen.org/wiki/Xen_Roadmap/4.4 > We tagged 4.4.0-rc1 on 19 December. Based on the conversation had last > time and on George's final comments in [1] I think this means that PVH > dom0 support has not made the cut for 4.4, which is a shame but there > is plenty of good functionality (including PVH domU support) in there. > [1] http://bugs.xenproject.org/xen/mid/%3C52B05C0A.4040404@eu.citrix.com%3E > = Timeline = > Here is our current timeline based on a 6-month release: > * Feature freeze: 18 October 2013 > * Code freezing point: 18 November 2013 > * First RCs: 6 December 2013 <== WE ARE HERE > * Release: 21 January 2014 > Last updated: 8 January 2014 > == Completed == <snip> > * PHV domU (experimental only) <snip> > === Big ticket items === > * PVH dom0 (w/ Linux) > blocker > owner: mukesh@oracle, george@citrix > status (Linux): Acked, waiting for ABI to be nailed down > status (Xen): v6 posted; no longer considered a blocker Perhaps worth noting as a separate non-blocking (for 4.5) item: * PVH support for AMD (/SVM) And also mention this "lack" of support in the announcement of the new experimental feature PVH. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2014-01-08 14:21 ` Sander Eikelenboom @ 2014-01-08 14:23 ` Ian Campbell 0 siblings, 0 replies; 116+ messages in thread From: Ian Campbell @ 2014-01-08 14:23 UTC (permalink / raw) To: Sander Eikelenboom; +Cc: George Dunlap, xen-devel On Wed, 2014-01-08 at 15:21 +0100, Sander Eikelenboom wrote: > We > Perhaps worth noting as a separate non-blocking (for 4.5) item: > * PVH support for AMD (/SVM) I leave that up to the 4.5 RM. > And also mention this "lack" of support in the announcement of the new experimental feature PVH. It is certainly worth making the point that it is Intel only in the Release Notes or announcements etc. Ian. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2014-01-08 13:16 Ian Campbell 2014-01-08 13:29 ` Ian Campbell 2014-01-08 14:21 ` Sander Eikelenboom @ 2014-01-08 14:35 ` Wei Liu 2014-01-16 6:54 ` Zhang, Yang Z 3 siblings, 0 replies; 116+ messages in thread From: Wei Liu @ 2014-01-08 14:35 UTC (permalink / raw) To: Ian Campbell; +Cc: George Dunlap, xen-devel, wei.liu2 On Wed, Jan 08, 2014 at 01:16:24PM +0000, Ian Campbell wrote: [...] > == Open == > > * xl support for vnc and vnclisten options with PV guests > > http://bugs.xenproject.org/xen/bug/25 > status: V4 patch posted. Should go in. > Blocker? > Konrad (the reporter) confirmed this is not a blocker. Wei. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2014-01-08 13:16 Ian Campbell ` (2 preceding siblings ...) 2014-01-08 14:35 ` Wei Liu @ 2014-01-16 6:54 ` Zhang, Yang Z 3 siblings, 0 replies; 116+ messages in thread From: Zhang, Yang Z @ 2014-01-16 6:54 UTC (permalink / raw) To: Ian Campbell, xen-devel; +Cc: George Dunlap Ian Campbell wrote on 2014-01-08: > I'm filing in for George while he is on vacation and travelling to a conference etc. > I'm still coming up to speed wrt what is going on with this release so > please do correct me when I'm wrong. George will be back on 20 January. > > This information will be mirrored on the Xen 4.4 Roadmap wiki page: > http://wiki.xen.org/wiki/Xen_Roadmap/4.4 > We tagged 4.4.0-rc1 on 19 December. Based on the conversation had last > time and on George's final comments in [1] I think this means that PVH > dom0 support has not made the cut for 4.4, which is a shame but there > is plenty of good functionality (including PVH domU support) in there. > > [1] > http://bugs.xenproject.org/xen/mid/%3C52B05C0A.4040404@eu.citrix.com%3 E > > = Timeline = > > Here is our current timeline based on a 6-month release: > > * Feature freeze: 18 October 2013 > * Code freezing point: 18 November 2013 > * First RCs: 6 December 2013 <== WE ARE HERE > * Release: 21 January 2014 > > Last updated: 8 January 2014 > > == Completed == > > * Event channel scalability (FIFO event channels) > > * Non-udev scripts for driver domains (non-Linux driver domains) > > * Multi-vector PCI MSI (Hypervisor side) > > * Improved Spice support on libxl > - Added Spice vdagent support > - Added Spice clipboard sharing support > - Spice usbredirection support for upstream qemu > * PHV domU (experimental only) > > * pvgrub2 checked into grub upstream > > * ARM64 guest > > * Guest EFI booting (tianocore) > > * kexec > > * Testing: Xen on ARM > > * Update to SeaBIOS 1.7.3.1 > > * Update to qemu 1.6 > > * SWIOTLB (in Linux 3.13) > > * Disk: indirect descriptors (in 3.11) > > * Reworked ocaml bindings Can I say nested virtualization also is good supported in Xen 4.4? > > == Resolved since last update == > > == Open == > > * xl support for vnc and vnclisten options with PV guests > > http://bugs.xenproject.org/xen/bug/25 > status: V4 patch posted. Should go in. > Blocker? > * libxl / xl does not handle failure of remote qemu gracefully >> Related to http://bugs.xenproject.org/xen/bug/29 >> Easiest way to reproduce: >> - set "vncunused=0" and do a local migrate >> - The "remote" qemu will fail because the vnc port is in use >> The failure isn't the problem, but everything being stuck > afterwards is Ian J investigating > > * xl needs to disallow PoD with PCI passthrough >> see > http://xen.1045712.n5.nabble.com/PATCH-VT-d-Dis-allow-PCI-device-assig > nme nt-if-PoD-is-enabled-td2547788.html > > * qemu-upstream not freeing pirq >> http://www.gossamer-threads.com/lists/xen/devel/281498 >> http://marc.info/?l=xen-devel&m=137265766424502 >> status: patches posted; latest patches need testing Not a blocker. > * Race in PV shutdown between tool detection and shutdown watch > > http://www.gossamer-threads.com/lists/xen/devel/282467 >> Nothing to do with ACPI >> status: Patches posted >> Not a blocker. > * xl does not support specifying virtual function for passthrough > device > > http://bugs.xenproject.org/xen/bug/22 > Too much work to be a blocker. > * xl does not handle migrate interruption gracefully >> If you start a localhost migrate, and press "Ctrl-C" in the middle, >> you get two hung domains >> Ian J investigated -- can of worms, too big to be a blocker for 4.4 > * Win2k3 SP2 RTC infinite loops >> Regression introduced late in Xen-4.3 development > owner: andrew.cooper@citrix > status: patches posted, undergoing review. ( v2 ID > 1386241748-9617-1-git-send-email-andrew.cooper3@citrix.com ) > >> andyhhp: my proposed RTC fixes break migrate from older versions of >> Xen, so I have to redesign it from scratch. no way it is going to >> be ready for 4.4 > > * HPET interrupt stack overflow (when using hpet_broadcast mode and > MSI capable HPETs) > owner: andyh@citrix > status: patches posted, undergoing review iteration. >> andyhhp: I have more work to do on the HPET series >> andyhhp: no way it is going to be ready or safe for 4.4 > > * PCI hole resize support hvmloader/qemu-traditional/qemu-upstream > with PCI/GPU passthrough >> http://bugs.xenproject.org/xen/bug/28 >> http://lists.xen.org/archives/html/xen-devel/2013-05/msg02813.html >> Where Stefano writes: >> 2) for Xen 4.4 rework the two patches above and improve >> i440fx_update_pci_mem_hole: resizing the pci_hole subregion is not >> enough, it also needs to be able to resize the system memory region >> (xen.ram) to make room for the bigger pci_hole > > status: not going to be fixed for 4.4 either. Created bug #28. > * qemu memory leak? >> http://lists.xen.org/archives/html/xen-users/2013-03/msg00276.html > > * qemu-* parses "008" as octal in USB bus.addr format >> http://bugs.xenproject.org/xen/bug/15 >> just needs documenting > Anthony Perard to patch docs > * osstest windows-install failures >> http://bugs.xenproject.org/xen/bug/29 >> http://www.chiark.greenend.org.uk/~xensrcts/logs/24250/ > Anthony and/or Jan investigating > === Big ticket items === > > * PVH dom0 (w/ Linux) > blocker > owner: mukesh@oracle, george@citrix > status (Linux): Acked, waiting for ABI to be nailed down > status (Xen): v6 posted; no longer considered a blocker > * libvirt/libxl integration (external) > - owner: jfehlig@suse, dario@citrix > - patches posted (should be released before 4.4) > - migration - PCI pass-through - In progress - integration w/ > libvirt's lock manager - improved concurrency > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel Best regards, Yang ^ permalink raw reply [flat|nested] 116+ messages in thread
* Xen 4.4 development update @ 2013-11-26 12:14 George Dunlap 2013-11-26 12:55 ` Jan Beulich ` (6 more replies) 0 siblings, 7 replies; 116+ messages in thread From: George Dunlap @ 2013-11-26 12:14 UTC (permalink / raw) To: xen-devel This information will be mirrored on the Xen 4.4 Roadmap wiki page: http://wiki.xen.org/wiki/Xen_Roadmap/4.4 We're one week into the "code freezing point", which means that every patch that introduces new functionality needs a freeze exception. Remember our goal for the release: 1. A bug-free release 2. An awesome release 3. An on-time release Accepting a new feature may make Xen more awesome; but it also introduces a risk that it will introduce more bugs. That bug may be found before the release (threatening #3), or it may not be found until after the release (threatening #1). So when posting a patch requesting a freeze exception, please consider the following questions: 1. What is the benefit of this feature? Why should we accept this now instead of waiting for 4.5? 2. What is the risk that this may introduce bugs that may slip the releass, or bugs that may not be discovered and end up in the release? The more skeptical you are in your evaluation, the more generous I can afford to be. We will become progressively more conservative until the first RC, which is scheduled for 2 weeks' time (6 December). After that, we will only accept bug fixes. Bug fixes can be checked in without a freeze exception throughout the code freeze, unless the maintianer thinks they are particularly high risk. In later RC's, we may even begin rejecting bug fixes if the broken functionality is small and the risk to other functionality is high. Features which are currently marked "experimental" or do not at the moment work at all cannot be broken really; so changes to code only used by those features should be able to get a freeze exception easily. (Tianocore is something which would probably fall under this.) Features which change or add new interfaces which will need to be supported in a backwards-compatible way (for instance, vNUMA) will need freeze exceptions to make sure that the interface itself has enough time to be considered stable. These are guidelines and principles to give you an idea where we're coming from; if you think there's a good reason why making an exception for you will help us achieve goals 1-3 above better than not doing so, feel free to make your case. = Timeline = Here is our current timeline based on a 6-month release: * Feature freeze: 18 October 2013 * Code freezing point: 18 November 2013 <== WE ARE HERE * First RC: 6 December 2013 * Release: 21 January 2014 Last updated: 25 November 2013 == Completed == * Event channel scalability (FIFO event channels) * Non-udev scripts for driver domains (non-Linux driver domains) * Multi-vector PCI MSI (Hypervisor side) * Improved Spice support on libxl - Added Spice vdagent support - Added Spice clipboard sharing support * PHV domU (experimental only) * Guest EFI booting (tianocore) * kexec * Testing: Xen on ARM * Update to SeaBIOS 1.7.3.1 * pvgrub2 checked into grub upstream * SWIOTLB (in Linux 3.13) * Disk: indirect descriptors (in 3.11) == Resolved since last update == * credit scheduler doesn't update other fields when tslice updated from sysctl == Open == * qemu-upstream not freeing pirq > http://www.gossamer-threads.com/lists/xen/devel/281498 status: patches posted; latest patches need testing * Race in PV shutdown between tool detection and shutdown watch > http://www.gossamer-threads.com/lists/xen/devel/282467 > Nothing to do with ACPI status: Patches posted * Supposed regression from a3513737 ("x86: allow guest to set/clear > MSI-X mask bit (try 2)"), as per > http://lists.xenproject.org/archives/html/xen-devel/2013-09/msg01589.html. * qemu-traditional mis-parses host bus 8 as 0 > http://bugs.xenproject.org/xen/bug/15 * xen_platform_pci=0 doesn't work with qemu-xen > http://bugs.xenproject.org/xen/bug/20 status: Patches posted * xl does not support specifying virtual function for passthrough device > http://bugs.xenproject.org/xen/bug/22 * xl does not handle migrate interruption gracefully > If you start a localhost migrate, and press "Ctrl-C" in the middle, > you get two hung domains * libxl / xl does not handle failure of remote qemu gracefully > Easiest way to reproduce: > - set "vncunused=0" and do a local migrate > - The "remote" qemu will fail because the vnc port is in use > The failure isn't the problem, but everything being stuck afterwards is * HPET interrupt stack overflow (when using hpet_broadcast mode and MSI capable HPETs) owner: andyh@citrix status: patches posted, undergoing review iteration. * xl needs to disallow PoD with PCI passthrough >see http://xen.1045712.n5.nabble.com/PATCH-VT-d-Dis-allow-PCI-device-assignment-if-PoD-is-enabled-td2547788.html * PCI hole resize support hvmloader/qemu-traditional/qemu-upstream with PCI/GPU passthrough > http://lists.xen.org/archives/html/xen-devel/2013-05/msg02813.html > Where Stefano writes: > 2) for Xen 4.4 rework the two patches above and improve > i440fx_update_pci_mem_hole: resizing the pci_hole subregion is not > enough, it also needs to be able to resize the system memory region > (xen.ram) to make room for the bigger pci_hole * qemu memory leak? > http://lists.xen.org/archives/html/xen-users/2013-03/msg00276.html == Backlog == === Testing coverage === * new libxl w/ previous versions of xl @IanJ * Host S3 suspend @bguthro, @dariof * Default [example] XSM policy @Stefano to ask Daniel D * Storage driver domains @roger * HVM pci passthrough @anthony * PV pci passthrough @konrad (or @george if he gets to it first) * Network driver domains @George * Nested virt? @intel (chased by George) * Fix SRIOV test (chase intel) @ianj * Fix bisector to e-mail blame-worthy parties @ianj * Fix xl shutdown @ianj * stub domains @athony * performance benchmarks @dario === Meta-items (composed of other items) === * Meta: PVIO NUMA improvements - soft affinity for vcpus (4.4 possible) - PV guest NUMA interface (4.4 possible) - Sensible dom0 NUMA layout - Toolstack pinning backend thread / virq to appropraite d0 vcpu - NUMA-aware ballooning * xend still in tree (x) - xl list -l on a dom0-only system - xl list -l doesn't contain tty console port - xl Alternate transport support for migration* - xl PVSCSI support - xl PVUSB support === Big ticket items === * PVH mode (w/ Linux) owner: mukesh@oracle, george@citrix status (Linux): Acked, waiting for ABI to be nailed down status (Xen): Initial version checked in, still nailing down interface * Update to qemu 1.6 owner: Anthonyper status: In staging, still working out a bug in the VMX code * ARM Live Migration Support owner: Jaeyong Yoo <jaeyong.yoo@samsung.com> status: v5 posted, looking good for code freeze * ARM64 guest owner: IanC status: v3 posted, v4 in progress. looking good. * soft affinity for vcpus (was NUMA affinity for vcpus) owner: Dario status: v2 posted * PV guest NUMA interface owner: Elena status: v3 posted * libvirt/libxl integration (external) - owner: jfehlig@suse, dario@citrix - patches posted (should be released before 4.4) - migration - PCI pass-through - In progress - integration w/ libvirt's lock manager - improved concurrency * libxl: Spice usbredirection support for upstream qemu owner: fabio@M2R status: I'll post new patch version shortly * libxl: usb2 and usb3 controller support for upstream qemu owner: fabio@M2R status: patch v5 posted, tested and working, awaiting reviews * libxl network buffering support for Remus @shriram status: patches posted prognosis: fair * xencrashd owner: don@verizon status: v2 posted > http://lists.xen.org/archives/html/xen-devel/2013-11/msg02569.html ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-11-26 12:14 George Dunlap @ 2013-11-26 12:55 ` Jan Beulich 2013-11-26 14:16 ` Ian Campbell ` (5 subsequent siblings) 6 siblings, 0 replies; 116+ messages in thread From: Jan Beulich @ 2013-11-26 12:55 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel >>> On 26.11.13 at 13:14, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > * Supposed regression from a3513737 ("x86: allow guest to set/clear > > MSI-X mask bit (try 2)"), as per > > http://lists.xenproject.org/archives/html/xen-devel/2013-09/msg01589.html. Patch v6 at http://lists.xenproject.org/archives/html/xen-devel/2013-11/msg03752.html ready to go in, but wanting to give people some time to review. Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-11-26 12:14 George Dunlap 2013-11-26 12:55 ` Jan Beulich @ 2013-11-26 14:16 ` Ian Campbell 2013-11-27 10:51 ` Gordan Bobic ` (4 subsequent siblings) 6 siblings, 0 replies; 116+ messages in thread From: Ian Campbell @ 2013-11-26 14:16 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel On Tue, 2013-11-26 at 12:14 +0000, George Dunlap wrote: > * Update to qemu 1.6 > owner: Anthonyper > status: In staging, still working out a bug in the VMX code This was pushed a couple of days ago. > > * ARM Live Migration Support > owner: Jaeyong Yoo <jaeyong.yoo@samsung.com> > status: v5 posted, looking good for code freeze I updated you on this last tine around: http://article.gmane.org/gmane.comp.emulators.xen.devel/179068 > > * ARM64 guest > owner: IanC > status: v3 posted, v4 in progress. looking good. In already. Ian. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-11-26 12:14 George Dunlap 2013-11-26 12:55 ` Jan Beulich 2013-11-26 14:16 ` Ian Campbell @ 2013-11-27 10:51 ` Gordan Bobic 2013-12-02 18:34 ` Dario Faggioli 2013-12-02 17:36 ` Lars Kurth ` (3 subsequent siblings) 6 siblings, 1 reply; 116+ messages in thread From: Gordan Bobic @ 2013-11-27 10:51 UTC (permalink / raw) To: xen-devel > == Completed == [...] > * PHV domU (experimental only) It should be interesting to see if this will make Nvidia cards work in domU without the need to modify them into Quadros. Or whether they have pre-empted the possibility and added further checks to disable it (should also be interesting to see if older drivers work if the latest ones don't). Gordan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-11-27 10:51 ` Gordan Bobic @ 2013-12-02 18:34 ` Dario Faggioli 0 siblings, 0 replies; 116+ messages in thread From: Dario Faggioli @ 2013-12-02 18:34 UTC (permalink / raw) To: Gordan Bobic; +Cc: xen-devel [-- Attachment #1.1: Type: text/plain, Size: 648 bytes --] On mer, 2013-11-27 at 10:51 +0000, Gordan Bobic wrote: > > == Completed == > > [...] > > > * PHV domU (experimental only) > > It should be interesting to see if this will make Nvidia > cards work in domU without the need to modify them into > Quadros. > Honestly, I really don't think PVH would make much difference wrt to this... But yeah, let's see... Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-11-26 12:14 George Dunlap ` (2 preceding siblings ...) 2013-11-27 10:51 ` Gordan Bobic @ 2013-12-02 17:36 ` Lars Kurth 2013-12-02 18:34 ` Dario Faggioli ` (2 subsequent siblings) 6 siblings, 0 replies; 116+ messages in thread From: Lars Kurth @ 2013-12-02 17:36 UTC (permalink / raw) To: George Dunlap, xen-devel George, I guess we need to start looking at drafting a press release and getting Advisory Board approval to get the funds. Assuming there are no major delays, targeting the week before FOSDEM (the week of Jan 23) would be ideal for a release Lars On 26/11/2013 12:14, George Dunlap wrote: > This information will be mirrored on the Xen 4.4 Roadmap wiki page: > http://wiki.xen.org/wiki/Xen_Roadmap/4.4 > > We're one week into the "code freezing point", which means that every > patch that introduces new functionality needs a freeze exception. > > Remember our goal for the release: > 1. A bug-free release > 2. An awesome release > 3. An on-time release > > Accepting a new feature may make Xen more awesome; but it also > introduces a risk that it will introduce more bugs. That bug may be > found before the release (threatening #3), or it may not be found > until after the release (threatening #1). > > So when posting a patch requesting a freeze exception, please > consider the following questions: > > 1. What is the benefit of this feature? Why should we accept this > now instead of waiting for 4.5? > > 2. What is the risk that this may introduce bugs that may slip the > releass, or bugs that may not be discovered and end up in the > release? > > The more skeptical you are in your evaluation, the more generous I can > afford to be. > > We will become progressively more conservative until the first RC, > which is scheduled for 2 weeks' time (6 December). After that, we > will only accept bug fixes. > > Bug fixes can be checked in without a freeze exception throughout the > code freeze, unless the maintianer thinks they are particularly high > risk. In later RC's, we may even begin rejecting bug fixes if the > broken functionality is small and the risk to other functionality is > high. > > Features which are currently marked "experimental" or do not at the > moment work at all cannot be broken really; so changes to code only > used by those features should be able to get a freeze exception > easily. (Tianocore is something which would probably fall under > this.) > > Features which change or add new interfaces which will need to be > supported in a backwards-compatible way (for instance, vNUMA) will > need freeze exceptions to make sure that the interface itself has > enough time to be considered stable. > > These are guidelines and principles to give you an idea where we're > coming from; if you think there's a good reason why making an > exception for you will help us achieve goals 1-3 above better than not > doing so, feel free to make your case. > > = Timeline = > > Here is our current timeline based on a 6-month release: > > * Feature freeze: 18 October 2013 > * Code freezing point: 18 November 2013 <== WE ARE HERE > * First RC: 6 December 2013 > * Release: 21 January 2014 > > Last updated: 25 November 2013 > > == Completed == > > * Event channel scalability (FIFO event channels) > > * Non-udev scripts for driver domains (non-Linux driver domains) > > * Multi-vector PCI MSI (Hypervisor side) > > * Improved Spice support on libxl > - Added Spice vdagent support > - Added Spice clipboard sharing support > > * PHV domU (experimental only) > > * Guest EFI booting (tianocore) > > * kexec > > * Testing: Xen on ARM > > * Update to SeaBIOS 1.7.3.1 > > * pvgrub2 checked into grub upstream > > * SWIOTLB (in Linux 3.13) > > * Disk: indirect descriptors (in 3.11) > > == Resolved since last update == > > * credit scheduler doesn't update other fields when tslice updated from sysctl > > == Open == > > * qemu-upstream not freeing pirq > > http://www.gossamer-threads.com/lists/xen/devel/281498 > status: patches posted; latest patches need testing > > * Race in PV shutdown between tool detection and shutdown watch > > http://www.gossamer-threads.com/lists/xen/devel/282467 > > Nothing to do with ACPI > status: Patches posted > > * Supposed regression from a3513737 ("x86: allow guest to set/clear > > MSI-X mask bit (try 2)"), as per > > http://lists.xenproject.org/archives/html/xen-devel/2013-09/msg01589.html. > > * qemu-traditional mis-parses host bus 8 as 0 > > http://bugs.xenproject.org/xen/bug/15 > > * xen_platform_pci=0 doesn't work with qemu-xen > > http://bugs.xenproject.org/xen/bug/20 > status: Patches posted > > * xl does not support specifying virtual function for passthrough device > > http://bugs.xenproject.org/xen/bug/22 > > * xl does not handle migrate interruption gracefully > > If you start a localhost migrate, and press "Ctrl-C" in the middle, > > you get two hung domains > > * libxl / xl does not handle failure of remote qemu gracefully > > Easiest way to reproduce: > > - set "vncunused=0" and do a local migrate > > - The "remote" qemu will fail because the vnc port is in use > > The failure isn't the problem, but everything being stuck afterwards is > > * HPET interrupt stack overflow (when using hpet_broadcast mode and MSI > capable HPETs) > owner: andyh@citrix > status: patches posted, undergoing review iteration. > > * xl needs to disallow PoD with PCI passthrough > >see http://xen.1045712.n5.nabble.com/PATCH-VT-d-Dis-allow-PCI-device-assignment-if-PoD-is-enabled-td2547788.html > > * PCI hole resize support hvmloader/qemu-traditional/qemu-upstream > with PCI/GPU passthrough > > http://lists.xen.org/archives/html/xen-devel/2013-05/msg02813.html > > Where Stefano writes: > > 2) for Xen 4.4 rework the two patches above and improve > > i440fx_update_pci_mem_hole: resizing the pci_hole subregion is not > > enough, it also needs to be able to resize the system memory region > > (xen.ram) to make room for the bigger pci_hole > > * qemu memory leak? > > http://lists.xen.org/archives/html/xen-users/2013-03/msg00276.html > > == Backlog == > > === Testing coverage === > > * new libxl w/ previous versions of xl > @IanJ > > * Host S3 suspend > @bguthro, @dariof > > * Default [example] XSM policy > @Stefano to ask Daniel D > > * Storage driver domains > @roger > > * HVM pci passthrough > @anthony > > * PV pci passthrough > @konrad (or @george if he gets to it first) > > * Network driver domains > @George > > * Nested virt? > @intel (chased by George) > > * Fix SRIOV test (chase intel) > @ianj > > * Fix bisector to e-mail blame-worthy parties > @ianj > > * Fix xl shutdown > @ianj > > * stub domains > @athony > > * performance benchmarks > @dario > > === Meta-items (composed of other items) === > > * Meta: PVIO NUMA improvements > - soft affinity for vcpus (4.4 possible) > - PV guest NUMA interface (4.4 possible) > - Sensible dom0 NUMA layout > - Toolstack pinning backend thread / virq to appropraite d0 vcpu > - NUMA-aware ballooning > > * xend still in tree (x) > - xl list -l on a dom0-only system > - xl list -l doesn't contain tty console port > - xl Alternate transport support for migration* > - xl PVSCSI support > - xl PVUSB support > > === Big ticket items === > > * PVH mode (w/ Linux) > owner: mukesh@oracle, george@citrix > status (Linux): Acked, waiting for ABI to be nailed down > status (Xen): Initial version checked in, still nailing down interface > > * Update to qemu 1.6 > owner: Anthonyper > status: In staging, still working out a bug in the VMX code > > * ARM Live Migration Support > owner: Jaeyong Yoo <jaeyong.yoo@samsung.com> > status: v5 posted, looking good for code freeze > > * ARM64 guest > owner: IanC > status: v3 posted, v4 in progress. looking good. > > * soft affinity for vcpus (was NUMA affinity for vcpus) > owner: Dario > status: v2 posted > > * PV guest NUMA interface > owner: Elena > status: v3 posted > > * libvirt/libxl integration (external) > - owner: jfehlig@suse, dario@citrix > - patches posted (should be released before 4.4) > - migration > - PCI pass-through > - In progress > - integration w/ libvirt's lock manager > - improved concurrency > > * libxl: Spice usbredirection support for upstream qemu > owner: fabio@M2R > status: I'll post new patch version shortly > > * libxl: usb2 and usb3 controller support for upstream qemu > owner: fabio@M2R > status: patch v5 posted, tested and working, awaiting reviews > > * libxl network buffering support for Remus > @shriram > status: patches posted > prognosis: fair > > * xencrashd > owner: don@verizon > status: v2 posted > > http://lists.xen.org/archives/html/xen-devel/2013-11/msg02569.html > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-11-26 12:14 George Dunlap ` (3 preceding siblings ...) 2013-12-02 17:36 ` Lars Kurth @ 2013-12-02 18:34 ` Dario Faggioli 2013-12-03 19:37 ` Konrad Rzeszutek Wilk 2013-12-03 19:41 ` Konrad Rzeszutek Wilk 6 siblings, 0 replies; 116+ messages in thread From: Dario Faggioli @ 2013-12-02 18:34 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel [-- Attachment #1.1: Type: text/plain, Size: 476 bytes --] On mar, 2013-11-26 at 12:14 +0000, George Dunlap wrote: > === Meta-items (composed of other items) === > > * Meta: PVIO NUMA improvements > - soft affinity for vcpus (4.4 possible) > v5 posted. Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-11-26 12:14 George Dunlap ` (4 preceding siblings ...) 2013-12-02 18:34 ` Dario Faggioli @ 2013-12-03 19:37 ` Konrad Rzeszutek Wilk 2013-12-04 10:30 ` Ian Campbell 2013-12-03 19:41 ` Konrad Rzeszutek Wilk 6 siblings, 1 reply; 116+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-12-03 19:37 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel > * xend still in tree (x) > - xl list -l on a dom0-only system > - xl list -l doesn't contain tty console port > - xl Alternate transport support for migration* > - xl PVSCSI support > - xl PVUSB support Please also add in the vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1'] vs just adding 'vnc=1, vnclisten=...' options. With Xend you could use either one with a PV guest and it would setup a framebuffer. With xl if you do: vnc=1 vnclisten=0.0.0.0 it won't setup a framebuffer. But if you do: vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1'] Then it works. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-12-03 19:37 ` Konrad Rzeszutek Wilk @ 2013-12-04 10:30 ` Ian Campbell 0 siblings, 0 replies; 116+ messages in thread From: Ian Campbell @ 2013-12-04 10:30 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: George Dunlap, xen-devel create ^ title it xl support for vnc and vnclisten options with PV guests thanks On Tue, 2013-12-03 at 14:37 -0500, Konrad Rzeszutek Wilk wrote: > > * xend still in tree (x) [...] > Please also add in the vfb = [ 'vnc=1, vnclisten=0.0.0.0,vncunused=1'] > vs just adding 'vnc=1, vnclisten=...' options. > > With Xend you could use either one with a PV guest and it would > setup a framebuffer. With xl if you do: > > vnc=1 > vnclisten=0.0.0.0 > > it won't setup a framebuffer. Looks like xl_cmdimpl.c only implements those top level options for HVM guests. Ian. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-11-26 12:14 George Dunlap ` (5 preceding siblings ...) 2013-12-03 19:37 ` Konrad Rzeszutek Wilk @ 2013-12-03 19:41 ` Konrad Rzeszutek Wilk 2013-12-04 10:38 ` Stefano Stabellini 6 siblings, 1 reply; 116+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-12-03 19:41 UTC (permalink / raw) To: George Dunlap, Stefano Stabellini; +Cc: xen-devel > * qemu-upstream not freeing pirq > > http://www.gossamer-threads.com/lists/xen/devel/281498 > status: patches posted; latest patches need testing So.. I know there was a patch, but looking at that thread I see: > Hi Stefano, > > do you work out a patch for me to test? I'll be traveling/busy for a few weeks, maybe it's best if someone else picks up this work item. And then there was a patch posted by Stefano at some point. But I can't find it? Stefano, help?! ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-12-03 19:41 ` Konrad Rzeszutek Wilk @ 2013-12-04 10:38 ` Stefano Stabellini 0 siblings, 0 replies; 116+ messages in thread From: Stefano Stabellini @ 2013-12-04 10:38 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: George Dunlap, xen-devel, Stefano Stabellini On Tue, 3 Dec 2013, Konrad Rzeszutek Wilk wrote: > > * qemu-upstream not freeing pirq > > > http://www.gossamer-threads.com/lists/xen/devel/281498 > > status: patches posted; latest patches need testing > > So.. I know there was a patch, but looking at that thread I see: > > > > Hi Stefano, > > > > do you work out a patch for me to test? > > I'll be traveling/busy for a few weeks, maybe it's best if someone else > picks up this work item. > > > And then there was a patch posted by Stefano at some point. But I can't find it? > Stefano, help?! it should be this one: http://marc.info/?l=xen-devel&m=137265766424502 ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update
@ 2013-08-08 19:38 Eric Shelton
2013-08-08 19:55 ` Konrad Rzeszutek Wilk
0 siblings, 1 reply; 116+ messages in thread
From: Eric Shelton @ 2013-08-08 19:38 UTC (permalink / raw)
To: George Dunlap; +Cc: Daniel Kiper, xen-devel
> * Xen EFI feature: pvops dom0 able to make use of EFI run-time
> services (external)
> owner: Daniel Kiper
> status: Just begun
I think this is addressed, maybe in full, by this patchset, presented
in the midst of getting 4.3 in order:
http://lists.xen.org/archives/html/xen-devel/2013-05/msg02492.html
I have used this for the last 3 months. The noted i915 issue was
resolved by later updates to the kernel or X driver, as 3.10.1 is
running smoothly. The only issue I have observed is that although Xen
correctly powers off the system in response to a dom0-initiated
shutdown, Xen is not currently rebooting - I have to let the system
wind down and then do a power cycle.
The patchset is an update to a set originally submitted by Tang Liang,
which I gather was based on work done by Suse. Given that the patches
are 100% kernel-side (the Xen code was put in place some time ago),
what needs to be done for acceptance by the LKML folks?
- Eric
^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 19:38 Eric Shelton @ 2013-08-08 19:55 ` Konrad Rzeszutek Wilk 2013-08-08 20:51 ` Eric Shelton 0 siblings, 1 reply; 116+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-08-08 19:55 UTC (permalink / raw) To: Eric Shelton; +Cc: George Dunlap, Daniel Kiper, xen-devel On Thu, Aug 08, 2013 at 03:38:58PM -0400, Eric Shelton wrote: > > * Xen EFI feature: pvops dom0 able to make use of EFI run-time > > services (external) > > owner: Daniel Kiper > > status: Just begun > > I think this is addressed, maybe in full, by this patchset, presented > in the midst of getting 4.3 in order: > > http://lists.xen.org/archives/html/xen-devel/2013-05/msg02492.html > > I have used this for the last 3 months. The noted i915 issue was > resolved by later updates to the kernel or X driver, as 3.10.1 is > running smoothly. The only issue I have observed is that although Xen > correctly powers off the system in response to a dom0-initiated > shutdown, Xen is not currently rebooting - I have to let the system > wind down and then do a power cycle. > > The patchset is an update to a set originally submitted by Tang Liang, > which I gather was based on work done by Suse. Given that the patches > are 100% kernel-side (the Xen code was put in place some time ago), > what needs to be done for acceptance by the LKML folks? Rework them. The maintainer would like it done differently - that was my recollection last year when I chatted with him (Matthew Garret). Daniel will know more - but he is right now making multiboot2 work with Xen and then attacking this. > > - Eric > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 19:55 ` Konrad Rzeszutek Wilk @ 2013-08-08 20:51 ` Eric Shelton 2013-08-09 18:56 ` Daniel Kiper 2013-08-20 16:13 ` Stefano Stabellini 0 siblings, 2 replies; 116+ messages in thread From: Eric Shelton @ 2013-08-08 20:51 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: George Dunlap, Daniel Kiper, xen-devel On Thu, Aug 8, 2013 at 3:55 PM, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: . . . > Rework them. The maintainer would like it done differently - that was my > recollection last year when I chatted with him (Matthew Garret). > > Daniel will know more - but he is right now making multiboot2 work with > Xen and then attacking this. Back then (https://lkml.org/lkml/2012/2/9/299), Matthew said: > Hm. Is there absolutely no way to do this by replacing efi_call_*? It'd > really be nice to avoid yet another set of duplicate functions here - > the ia64/x86 situation is already bad enough. Ideally this would be > sufficiently generic that arm can also plug into it. It looks like the arm patches are just now nearing commit worthiness, with V2 just posted a couple of days ago: https://lkml.org/lkml/2013/8/6/584 It looks like Garrett's goal of merging arm and x86 EFI code is being realized, and that I will need to refactor my patchset to keep up with these changes. Roy Franz seems to be doing the heavy lifting on arm EFI, with Matt Fleming serving as the maintainer. Related to this, is the Xen hypervisor booting under EFI for arm already? I assume not, if Linux currently lacks the needed hypercalls. Does anything arm-specific need to happen in an EFI-friendly dom0 kernel, given that it is hypercall driven? Is there a platform for test? - Eric ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 20:51 ` Eric Shelton @ 2013-08-09 18:56 ` Daniel Kiper 2013-08-15 5:32 ` Eric Shelton 2013-08-20 16:13 ` Stefano Stabellini 1 sibling, 1 reply; 116+ messages in thread From: Daniel Kiper @ 2013-08-09 18:56 UTC (permalink / raw) To: Eric Shelton; +Cc: George Dunlap, xen-devel On Thu, Aug 08, 2013 at 04:51:51PM -0400, Eric Shelton wrote: > On Thu, Aug 8, 2013 at 3:55 PM, Konrad Rzeszutek Wilk > <konrad.wilk@oracle.com> wrote: > . . . > > Rework them. The maintainer would like it done differently - that was my > > recollection last year when I chatted with him (Matthew Garret). > > > > Daniel will know more - but he is right now making multiboot2 work with > > Xen and then attacking this. > > Back then (https://lkml.org/lkml/2012/2/9/299), Matthew said: > > > Hm. Is there absolutely no way to do this by replacing efi_call_*? It'd > > really be nice to avoid yet another set of duplicate functions here - > > the ia64/x86 situation is already bad enough. Ideally this would be > > sufficiently generic that arm can also plug into it. > > It looks like the arm patches are just now nearing commit worthiness, > with V2 just posted a couple of days ago: > > https://lkml.org/lkml/2013/8/6/584 > > It looks like Garrett's goal of merging arm and x86 EFI code is being > realized, and that I will need to refactor my patchset to keep up with > these changes. Roy Franz seems to be doing the heavy lifting on arm > EFI, with Matt Fleming serving as the maintainer. I have not dug very deep but it looks that it is only EFI loader patch series (called stub in Linux Kernel). It is not related to Xen EFI stuff in Linux Kernel. > Related to this, is the Xen hypervisor booting under EFI for arm > already? I assume not, if Linux currently lacks the needed > hypercalls. Does anything arm-specific need to happen in an > EFI-friendly dom0 kernel, given that it is hypercall driven? Is there > a platform for test? IIRC there is no EFI support in Xen on ARM. However, you should ask Stefano and/or Ian Campbell for more details. They are ARM maintainers for Xen. As Konrad said I am working on multiboot2 protocol support for Xen. It is needed to load Xen from e.g. GRUB2 loader on EFI platforms. I would like to finish this first because there are some interests in that project. Then I will be working on EFI support for Xen in Linux Kernel. However, if you like to work on this stuff go ahead. I do no have any objections. Just drop me line then I would not duplicate your efforts. Daniel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-09 18:56 ` Daniel Kiper @ 2013-08-15 5:32 ` Eric Shelton 0 siblings, 0 replies; 116+ messages in thread From: Eric Shelton @ 2013-08-15 5:32 UTC (permalink / raw) To: Daniel Kiper; +Cc: George Dunlap, xen-devel On 08/09/2013 02:56 PM, Daniel Kiper wrote: > On Thu, Aug 08, 2013 at 04:51:51PM -0400, Eric Shelton wrote: >> On Thu, Aug 8, 2013 at 3:55 PM, Konrad Rzeszutek Wilk >> <konrad.wilk@oracle.com> wrote: >> . . . >>> Rework them. The maintainer would like it done differently - that was my >>> recollection last year when I chatted with him (Matthew Garret). >>> >>> Daniel will know more - but he is right now making multiboot2 work with >>> Xen and then attacking this. >> >> Back then (https://lkml.org/lkml/2012/2/9/299), Matthew said: >> >>> Hm. Is there absolutely no way to do this by replacing efi_call_*? It'd >>> really be nice to avoid yet another set of duplicate functions here - >>> the ia64/x86 situation is already bad enough. Ideally this would be >>> sufficiently generic that arm can also plug into it. >> >> It looks like the arm patches are just now nearing commit worthiness, >> with V2 just posted a couple of days ago: >> >> https://lkml.org/lkml/2013/8/6/584 >> >> It looks like Garrett's goal of merging arm and x86 EFI code is being >> realized, and that I will need to refactor my patchset to keep up with >> these changes. Roy Franz seems to be doing the heavy lifting on arm >> EFI, with Matt Fleming serving as the maintainer. > > I have not dug very deep but it looks that it is only EFI loader > patch series (called stub in Linux Kernel). It is not related to > Xen EFI stuff in Linux Kernel. That looks correct. The only file in common between the two sets of patches is include/linux/efi.h, and those changes do not affect each other. >> Related to this, is the Xen hypervisor booting under EFI for arm >> already? I assume not, if Linux currently lacks the needed >> hypercalls. Does anything arm-specific need to happen in an >> EFI-friendly dom0 kernel, given that it is hypercall driven? Is there >> a platform for test? > > IIRC there is no EFI support in Xen on ARM. However, you should ask > Stefano and/or Ian Campbell for more details. They are ARM maintainers > for Xen. > > As Konrad said I am working on multiboot2 protocol support for Xen. > It is needed to load Xen from e.g. GRUB2 loader on EFI platforms. > I would like to finish this first because there are some interests > in that project. Then I will be working on EFI support for Xen > in Linux Kernel. However, if you like to work on this stuff go > ahead. I do no have any objections. Just drop me line then I would > not duplicate your efforts. In the interest of getting a more finalized patch out while I still recall some of the details of this, please find below a revised patch. There continues to be an issue with reboot working on my laptop, but I think it is in the hypervisor, as the kernel is making the hypercall requesting the reboot. Unfortunately, I do not have the tools to debug Xen on my laptop, as it lacks a serial port and I do not have a few of the things needed for EHCI port debugging. The kernel reboots just fine when running directly under EFI, although I do not know right now if it is via the EFI runtime or the more traditional reboot mechanisms. If there are no comments, I will try running this by the Linux EFI maintainer. ============= From: Eric Shelton <eshelton@pobox.com> Date: Thu, 15 Aug 2013 00:31:08 -0400 Subject: [PATCH 1/1] EFI stub: add support for boot under EFI-booted Xen Allows dom0 kernel to detect when it is running under a Xen hypervisor booted under EFI, and then make hyper calls to Xen to identify and obtain resources such as ACPI tables, E820 information, and the EFI console in order to complete booting. Applies cleanly against 3.11rc5 and recent arm efi patches. Signed-off-by: Eric Shelton <eshelton@pobox.com> --- arch/x86/platform/efi/Makefile | 3 + arch/x86/platform/efi/efi.c | 82 ++++++-- arch/x86/platform/efi/xen.c | 427 +++++++++++++++++++++++++++++++++++++++ arch/x86/xen/enlighten.c | 22 +- include/linux/efi.h | 8 + include/xen/interface/platform.h | 132 ++++++++++++ 6 files changed, 649 insertions(+), 25 deletions(-) create mode 100644 arch/x86/platform/efi/xen.c diff --git a/arch/x86/platform/efi/Makefile b/arch/x86/platform/efi/Makefile index 6db1cc4..f485766 100644 --- a/arch/x86/platform/efi/Makefile +++ b/arch/x86/platform/efi/Makefile @@ -1,2 +1,5 @@ obj-$(CONFIG_EFI) += efi.o efi_$(BITS).o efi_stub_$(BITS).o +#ifdef CONFIG_XEN +obj-$(CONFIG_EFI) += xen.o +#endif obj-$(CONFIG_ACPI_BGRT) += efi-bgrt.o diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c index 90f6ed1..ca043bda 100644 --- a/arch/x86/platform/efi/efi.c +++ b/arch/x86/platform/efi/efi.c @@ -12,6 +12,7 @@ * Bibo Mao <bibo.mao@intel.com> * Chandramouli Narayanan <mouli@linux.intel.com> * Huang Ying <ying.huang@intel.com> + * Copyright (C) 2013 Eric Shelton <eshelton@pobox.com> * * Copied from efi_32.c to eliminate the duplicated code between EFI * 32/64 support code. --ying 2007-10-26 @@ -51,6 +52,12 @@ #include <asm/x86_init.h> #include <asm/rtc.h> +#ifdef CONFIG_XEN +extern void efi_init_xen(void); +extern u32 efi_mem_type_xen(unsigned long phys_addr); +extern u64 efi_mem_attributes_xen(unsigned long phys_addr); +#endif + #define EFI_DEBUG 1 #define EFI_MIN_RESERVE 5120 @@ -381,6 +388,11 @@ int __init efi_memblock_x86_reserve_range(void) struct efi_info *e = &boot_params.efi_info; unsigned long pmap; +#ifdef CONFIG_XEN + if (efi_enabled(EFI_XEN)) + return 0; +#endif + #ifdef CONFIG_X86_32 /* Can't handle data above 4GB at this time */ if (e->efi_memmap_hi) { @@ -409,6 +421,8 @@ static void __init print_efi_memmap(void) void *p; int i; + if (memmap.map == NULL) return; + for (p = memmap.map, i = 0; p < memmap.map_end; p += memmap.desc_size, i++) { @@ -426,6 +440,11 @@ void __init efi_reserve_boot_services(void) { void *p; +#ifdef CONFIG_XEN + if (efi_enabled(EFI_XEN)) + return; +#endif + for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) { efi_memory_desc_t *md = p; u64 start = md->phys_addr; @@ -467,6 +486,11 @@ void __init efi_free_boot_services(void) { void *p; +#ifdef CONFIG_XEN + if (efi_enabled(EFI_XEN)) + return; +#endif + if (!efi_is_native()) return; @@ -578,20 +602,15 @@ static int __init efi_systab_init(void *phys) return 0; } -static int __init efi_config_init(u64 tables, int nr_tables) +int __init efi_config_init(u64 tables, int nr_tables, int entrySz) { void *config_tables, *tablep; - int i, sz; - - if (efi_enabled(EFI_64BIT)) - sz = sizeof(efi_config_table_64_t); - else - sz = sizeof(efi_config_table_32_t); + int i; /* * Let's see what config tables the firmware passed to us. */ - config_tables = early_ioremap(tables, nr_tables * sz); + config_tables = early_ioremap(tables, nr_tables * entrySz); if (config_tables == NULL) { pr_err("Could not map Configuration table!\n"); return -ENOMEM; @@ -599,7 +618,7 @@ static int __init efi_config_init(u64 tables, int nr_tables) tablep = config_tables; pr_info(""); - for (i = 0; i < efi.systab->nr_tables; i++) { + for (i = 0; i < nr_tables; i++) { efi_guid_t guid; unsigned long table; @@ -612,8 +631,7 @@ static int __init efi_config_init(u64 tables, int nr_tables) if (table64 >> 32) { pr_cont("\n"); pr_err("Table located above 4GB, disabling EFI.\n"); - early_iounmap(config_tables, - efi.systab->nr_tables * sz); + early_iounmap(config_tables, nr_tables * entrySz); return -EINVAL; } #endif @@ -645,10 +663,10 @@ static int __init efi_config_init(u64 tables, int nr_tables) efi.uga = table; pr_cont(" UGA=0x%lx ", table); } - tablep += sz; + tablep += entrySz; } pr_cont("\n"); - early_iounmap(config_tables, efi.systab->nr_tables * sz); + early_iounmap(config_tables, nr_tables * entrySz); return 0; } @@ -708,9 +726,16 @@ void __init efi_init(void) { efi_char16_t *c16; char vendor[100] = "unknown"; - int i = 0; + int entrySz, i = 0; void *tmp; +#ifdef CONFIG_XEN + if (efi_enabled(EFI_XEN)) { + efi_init_xen(); + return; + } +#endif + #ifdef CONFIG_X86_32 if (boot_params.efi_info.efi_systab_hi || boot_params.efi_info.efi_memmap_hi) { @@ -745,7 +770,12 @@ void __init efi_init(void) efi.systab->hdr.revision >> 16, efi.systab->hdr.revision & 0xffff, vendor); - if (efi_config_init(efi.systab->tables, efi.systab->nr_tables)) + if (efi_enabled(EFI_64BIT)) + entrySz = sizeof(efi_config_table_64_t); + else + entrySz = sizeof(efi_config_table_32_t); + + if (efi_config_init(efi.systab->tables, efi.systab->nr_tables, entrySz)) return; set_bit(EFI_CONFIG_TABLES, &x86_efi_facility); @@ -782,7 +812,14 @@ void __init efi_init(void) void __init efi_late_init(void) { +#ifdef CONFIG_XEN + if (efi_enabled(EFI_XEN)) + return; +#endif + +#ifdef CONFIG_ACPI_BGRT efi_bgrt_init(); +#endif } void __init efi_set_executable(efi_memory_desc_t *md, bool executable) @@ -871,6 +908,11 @@ void __init efi_enter_virtual_mode(void) void *p, *va, *new_memmap = NULL; int count = 0; +#ifdef CONFIG_XEN + if (efi_enabled(EFI_XEN)) + return; +#endif + efi.systab = NULL; /* @@ -1007,6 +1049,11 @@ u32 efi_mem_type(unsigned long phys_addr) efi_memory_desc_t *md; void *p; +#ifdef CONFIG_XEN + if (efi_enabled(EFI_XEN)) + return efi_mem_type_xen(phys_addr); +#endif + if (!efi_enabled(EFI_MEMMAP)) return 0; @@ -1025,6 +1072,11 @@ u64 efi_mem_attributes(unsigned long phys_addr) efi_memory_desc_t *md; void *p; +#ifdef CONFIG_XEN + if (efi_enabled(EFI_XEN)) + return efi_mem_attributes_xen(phys_addr); +#endif + for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) { md = p; if ((md->phys_addr <= phys_addr) && diff --git a/arch/x86/platform/efi/xen.c b/arch/x86/platform/efi/xen.c new file mode 100644 index 0000000..ec0943a --- /dev/null +++ b/arch/x86/platform/efi/xen.c @@ -0,0 +1,427 @@ +/* + * Xen EFI (Extensible Firmware Interface) support functions + * Based on related efforts in SLE and SUSE trees + * + * Copyright (C) 1999 VA Linux Systems + * Copyright (C) 1999 Walt Drummond <drummond@valinux.com> + * Copyright (C) 1999-2002 Hewlett-Packard Co. + * David Mosberger-Tang <davidm@hpl.hp.com> + * Stephane Eranian <eranian@hpl.hp.com> + * Copyright (C) 2005-2008 Intel Co. + * Fenghua Yu <fenghua.yu@intel.com> + * Bibo Mao <bibo.mao@intel.com> + * Chandramouli Narayanan <mouli@linux.intel.com> + * Huang Ying <ying.huang@intel.com> + * Copyright (C) 2011 Novell Co. + * Jan Beulic <JBeulich@suse.com> + * Copyright (C) 2011-2012 Oracle Co. + * Liang Tang <liang.tang@oracle.com> + * Copyright (C) 2013 Eric Shelton <eshelton@pobox.com> + */ + +#include <linux/kernel.h> +#include <linux/init.h> +#include <linux/efi.h> +#include <linux/export.h> +#include <linux/platform_device.h> +#include <linux/spinlock.h> +#include <linux/time.h> + +#include <asm/setup.h> +#include <asm/efi.h> +#include <asm/time.h> +#include <asm/cacheflush.h> +#include <asm/tlbflush.h> +#include <asm/x86_init.h> + +#include <xen/interface/platform.h> +#include <xen/interface/sched.h> +#include <asm/xen/hypercall.h> + +#define PFX "EFI: " + +#define call (op.u.efi_runtime_call) +#define DECLARE_CALL(what) \ + struct xen_platform_op op; \ + op.cmd = XENPF_efi_runtime_call; \ + call.function = XEN_EFI_##what; \ + call.misc = 0 + +static efi_status_t xen_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc) +{ + int err; + DECLARE_CALL(get_time); + + err = HYPERVISOR_dom0_op(&op); + if (err) + return EFI_UNSUPPORTED; + + if (tm) { + BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.get_time.time)); + memcpy(tm, &call.u.get_time.time, sizeof(*tm)); + } + + if (tc) { + tc->resolution = call.u.get_time.resolution; + tc->accuracy = call.u.get_time.accuracy; + tc->sets_to_zero = !!(call.misc & + XEN_EFI_GET_TIME_SET_CLEARS_NS); + } + + return call.status; +} + +static efi_status_t xen_efi_set_time(efi_time_t *tm) +{ + DECLARE_CALL(set_time); + + BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.set_time)); + memcpy(&call.u.set_time, tm, sizeof(*tm)); + + return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status; +} + +static efi_status_t xen_efi_get_wakeup_time(efi_bool_t *enabled, + efi_bool_t *pending, + efi_time_t *tm) +{ + int err; + DECLARE_CALL(get_wakeup_time); + + err = HYPERVISOR_dom0_op(&op); + if (err) + return EFI_UNSUPPORTED; + + if (tm) { + BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.get_wakeup_time)); + memcpy(tm, &call.u.get_wakeup_time, sizeof(*tm)); + } + + if (enabled) + *enabled = !!(call.misc & XEN_EFI_GET_WAKEUP_TIME_ENABLED); + + if (pending) + *pending = !!(call.misc & XEN_EFI_GET_WAKEUP_TIME_PENDING); + + return call.status; +} + +static efi_status_t xen_efi_set_wakeup_time(efi_bool_t enabled, efi_time_t *tm) +{ + DECLARE_CALL(set_wakeup_time); + + BUILD_BUG_ON(sizeof(*tm) != sizeof(call.u.set_wakeup_time)); + if (enabled) + call.misc = XEN_EFI_SET_WAKEUP_TIME_ENABLE; + if (tm) + memcpy(&call.u.set_wakeup_time, tm, sizeof(*tm)); + else + call.misc |= XEN_EFI_SET_WAKEUP_TIME_ENABLE_ONLY; + + return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status; +} + +static efi_status_t xen_efi_get_variable(efi_char16_t *name, + efi_guid_t *vendor, + u32 *attr, + unsigned long *data_size, + void *data) +{ + int err; + DECLARE_CALL(get_variable); + + set_xen_guest_handle(call.u.get_variable.name, name); + BUILD_BUG_ON(sizeof(*vendor) != + sizeof(call.u.get_variable.vendor_guid)); + memcpy(&call.u.get_variable.vendor_guid, vendor, sizeof(*vendor)); + call.u.get_variable.size = *data_size; + set_xen_guest_handle(call.u.get_variable.data, data); + err = HYPERVISOR_dom0_op(&op); + if (err) + return EFI_UNSUPPORTED; + + *data_size = call.u.get_variable.size; + *attr = call.misc; /* misc in struction is U32 variable*/ + + return call.status; +} + +static efi_status_t xen_efi_get_next_variable(unsigned long *name_size, + efi_char16_t *name, + efi_guid_t *vendor) +{ + int err; + DECLARE_CALL(get_next_variable_name); + if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION) + return EFI_UNSUPPORTED; + call.u.get_next_variable_name.size = *name_size; + set_xen_guest_handle(call.u.get_next_variable_name.name, name); + BUILD_BUG_ON(sizeof(*vendor) != + sizeof(call.u.get_next_variable_name.vendor_guid)); + memcpy(&call.u.get_next_variable_name.vendor_guid, vendor, + sizeof(*vendor)); + err = HYPERVISOR_dom0_op(&op); + if (err) + return EFI_UNSUPPORTED; + + *name_size = call.u.get_next_variable_name.size; + memcpy(vendor, &call.u.get_next_variable_name.vendor_guid, + sizeof(*vendor)); + + return call.status; +} + +static efi_status_t xen_efi_set_variable(efi_char16_t *name, + efi_guid_t *vendor, + u32 attr, + unsigned long data_size, + void *data) +{ + DECLARE_CALL(set_variable); + + set_xen_guest_handle(call.u.set_variable.name, name); + call.misc = attr; + BUILD_BUG_ON(sizeof(*vendor) != + sizeof(call.u.set_variable.vendor_guid)); + memcpy(&call.u.set_variable.vendor_guid, vendor, sizeof(*vendor)); + call.u.set_variable.size = data_size; + set_xen_guest_handle(call.u.set_variable.data, data); + + return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status; +} + +static efi_status_t xen_efi_query_variable_info(u32 attr, + u64 *storage_space, + u64 *remaining_space, + u64 *max_variable_size) +{ + int err; + DECLARE_CALL(query_variable_info); + + if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION) + return EFI_UNSUPPORTED; + + err = HYPERVISOR_dom0_op(&op); + if (err) + return EFI_UNSUPPORTED; + + *storage_space = call.u.query_variable_info.max_store_size; + *remaining_space = call.u.query_variable_info.remain_store_size; + *max_variable_size = call.u.query_variable_info.max_size; + + return call.status; +} + +static efi_status_t xen_efi_get_next_high_mono_count(u32 *count) +{ + int err; + DECLARE_CALL(get_next_high_monotonic_count); + + err = HYPERVISOR_dom0_op(&op); + if (err) + return EFI_UNSUPPORTED; + + *count = call.misc; + + return call.status; +} + +static efi_status_t xen_efi_update_capsule(efi_capsule_header_t **capsules, + unsigned long count, + unsigned long sg_list) +{ + DECLARE_CALL(update_capsule); + + if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION) + return EFI_UNSUPPORTED; + + set_xen_guest_handle(call.u.update_capsule.capsule_header_array, + capsules); + call.u.update_capsule.capsule_count = count; + call.u.update_capsule.sg_list = sg_list; + + return HYPERVISOR_dom0_op(&op) ? EFI_UNSUPPORTED : call.status; +} + +static efi_status_t xen_efi_query_capsule_caps(efi_capsule_header_t **capsules, + unsigned long count, + u64 *max_size, + int *reset_type) +{ + int err; + DECLARE_CALL(query_capsule_capabilities); + + if (efi.runtime_version < EFI_2_00_SYSTEM_TABLE_REVISION) + return EFI_UNSUPPORTED; + + set_xen_guest_handle(call.u.query_capsule_capabilities. + capsule_header_array, capsules); + call.u.query_capsule_capabilities.capsule_count = count; + + err = HYPERVISOR_dom0_op(&op); + if (err) + return EFI_UNSUPPORTED; + + *max_size = call.u.query_capsule_capabilities.max_capsule_size; + *reset_type = call.u.query_capsule_capabilities.reset_type; + + return call.status; +} + +#undef DECLARE_CALL +#undef call + +static void xen_efi_reset_system(int reset_type, + efi_status_t status, + unsigned long data_size, + efi_char16_t *data) +{ + struct sched_shutdown r = { .reason = SHUTDOWN_reboot }; + + if (HYPERVISOR_sched_op(SCHEDOP_shutdown, &r)) + BUG(); +} + +void __init xen_efi_probe(void) +{ + static struct xen_platform_op __initdata op = { + .cmd = XENPF_firmware_info, + .u.firmware_info = { + .type = XEN_FW_EFI_INFO, + .index = XEN_FW_EFI_CONFIG_TABLE + } + }; + + if (HYPERVISOR_dom0_op(&op) == 0) { + /* TODO: check return info */ + set_bit(EFI_XEN, &x86_efi_facility); + set_bit(EFI_BOOT, &x86_efi_facility); + /* since hypervisor calls the runtime, 32/64 bit + * EFI/kernel mismatch is not an issue. Set to + * match kernel so runtime calls will be made */ +#ifdef CONFIG_64BIT + set_bit(EFI_64BIT, &x86_efi_facility); +#endif + } +} + + +void __init efi_init_xen(void) +{ + efi_char16_t c16[100]; + char vendor[ARRAY_SIZE(c16)] = "unknown"; + int ret, i; + struct xen_platform_op op; + union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info; + + /* redirect system to Xen hypercall implementation */ + efi.systab = NULL, + efi.mps = EFI_INVALID_TABLE_ADDR; + efi.acpi = EFI_INVALID_TABLE_ADDR; + efi.acpi20 = EFI_INVALID_TABLE_ADDR; + efi.smbios = EFI_INVALID_TABLE_ADDR; + efi.sal_systab = EFI_INVALID_TABLE_ADDR; + efi.boot_info = EFI_INVALID_TABLE_ADDR; + efi.hcdp = EFI_INVALID_TABLE_ADDR; + efi.uga = EFI_INVALID_TABLE_ADDR; + efi.uv_systab = EFI_INVALID_TABLE_ADDR; + efi.get_time = xen_efi_get_time; + efi.set_time = xen_efi_set_time; + efi.get_wakeup_time = xen_efi_get_wakeup_time; + efi.set_wakeup_time = xen_efi_set_wakeup_time; + efi.get_variable = xen_efi_get_variable; + efi.get_next_variable = xen_efi_get_next_variable; + efi.set_variable = xen_efi_set_variable; + efi.query_variable_info = xen_efi_query_variable_info; + efi.update_capsule = xen_efi_update_capsule; + efi.query_capsule_caps = xen_efi_query_capsule_caps; + efi.get_next_high_mono_count = xen_efi_get_next_high_mono_count; + efi.set_virtual_address_map = NULL; + efi.reset_system = xen_efi_reset_system; + + /* + * Show what we know for posterity + */ + op.cmd = XENPF_firmware_info; + op.u.firmware_info.type = XEN_FW_EFI_INFO; + + op.u.firmware_info.index = XEN_FW_EFI_VENDOR; + info->vendor.bufsz = sizeof(c16); + set_xen_guest_handle(info->vendor.name, c16); + ret = HYPERVISOR_dom0_op(&op); + if (!ret) { + for (i = 0; i < sizeof(vendor) - 1 && c16[i]; ++i) + vendor[i] = c16[i]; + vendor[i] = '\0'; + } else + pr_err("Could not get the firmware vendor!\n"); + + op.u.firmware_info.index = XEN_FW_EFI_VERSION; + ret = HYPERVISOR_dom0_op(&op); + if (!ret) + pr_info("EFI-xen v%u.%.02u by %s\n", + info->version >> 16, + info->version & 0xffff, vendor); + else + pr_err("Could not get EFI revision!\n"); + + op.u.firmware_info.index = XEN_FW_EFI_RT_VERSION; + ret = HYPERVISOR_dom0_op(&op); + if (!ret) + efi.runtime_version = info->version; + else + pr_warn(PFX "Could not get runtime services revision.\n"); + set_bit(EFI_RUNTIME_SERVICES, &x86_efi_facility); + + /* + * Let's see what config tables the firmware passed to us. + */ + op.u.firmware_info.index = XEN_FW_EFI_CONFIG_TABLE; + if (HYPERVISOR_dom0_op(&op)) + BUG(); + + if (efi_config_init(info->cfg.addr, info->cfg.nent, + sizeof(efi_config_table_64_t))) + panic("Could not init EFI Configuration Tables!\n"); + set_bit(EFI_CONFIG_TABLES, &x86_efi_facility); + + /* the EFI memory info is digested by the hypervisor and + * supplied to dom0 via E820 entries */ + set_bit(EFI_MEMMAP, &x86_efi_facility); + + set_bit(EFI_SYSTEM_TABLES, &x86_efi_facility); /* not checked */ + + /* NOTE: efi.c only does this for CONFIG_X86_32 */ + x86_platform.get_wallclock = efi_get_time; + x86_platform.set_wallclock = efi_set_rtc_mmss; +} + +/* + * Convenience functions to obtain memory types and attributes + */ +u32 efi_mem_type_xen(unsigned long phys_addr) +{ + struct xen_platform_op op; + union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info; + + op.cmd = XENPF_firmware_info; + op.u.firmware_info.type = XEN_FW_EFI_INFO; + op.u.firmware_info.index = XEN_FW_EFI_MEM_INFO; + info->mem.addr = phys_addr; + info->mem.size = 0; + return HYPERVISOR_dom0_op(&op) ? 0 : info->mem.type; +} + +u64 efi_mem_attributes_xen(unsigned long phys_addr) +{ + struct xen_platform_op op; + union xenpf_efi_info *info = &op.u.firmware_info.u.efi_info; + + op.cmd = XENPF_firmware_info; + op.u.firmware_info.type = XEN_FW_EFI_INFO; + op.u.firmware_info.index = XEN_FW_EFI_MEM_INFO; + info->mem.addr = phys_addr; + info->mem.size = 0; + return HYPERVISOR_dom0_op(&op) ? 0 : info->mem.attr; +} + diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c index 193097e..51edc64 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -32,6 +32,7 @@ #include <linux/gfp.h> #include <linux/memblock.h> #include <linux/edd.h> +#include <linux/efi.h> #include <xen/xen.h> #include <xen/events.h> @@ -1342,15 +1343,6 @@ int xen_panic_handler_init(void) return 0; } -static const struct machine_ops xen_machine_ops __initconst = { - .restart = xen_restart, - .halt = xen_machine_halt, - .power_off = xen_machine_power_off, - .shutdown = xen_machine_halt, - .crash_shutdown = xen_crash_shutdown, - .emergency_restart = xen_emergency_restart, -}; - static void __init xen_boot_params_init_edd(void) { #if IS_ENABLED(CONFIG_EDD) @@ -1493,7 +1485,12 @@ asmlinkage void __init xen_start_kernel(void) pv_mmu_ops.ptep_modify_prot_commit = xen_ptep_modify_prot_commit; } - machine_ops = xen_machine_ops; + machine_ops.restart = xen_restart; + machine_ops.halt = xen_machine_halt; + machine_ops.power_off = xen_machine_power_off; + machine_ops.shutdown = xen_machine_halt; + machine_ops.crash_shutdown = xen_crash_shutdown; + machine_ops.emergency_restart = xen_emergency_restart; /* * The only reliable way to retain the initial address of the @@ -1613,6 +1610,11 @@ asmlinkage void __init xen_start_kernel(void) xen_setup_runstate_info(0); +#ifdef CONFIG_EFI + if (xen_initial_domain()) + xen_efi_probe(); +#endif + /* Start the world */ #ifdef CONFIG_X86_32 i386_start_kernel(); diff --git a/include/linux/efi.h b/include/linux/efi.h index 5f8f176..2781dea 100644 --- a/include/linux/efi.h +++ b/include/linux/efi.h @@ -84,7 +84,10 @@ typedef struct { #define EFI_PAL_CODE 13 #define EFI_MAX_MEMORY_TYPE 14 +#define EFI_INVALID_TYPE 0xffffffff + /* Attribute values: */ +#define EFI_INVALID_ATTRIBUTE ((u64)0x0000000000000000ULL) /* invalid attribute */ #define EFI_MEMORY_UC ((u64)0x0000000000000001ULL) /* uncached */ #define EFI_MEMORY_WC ((u64)0x0000000000000002ULL) /* write-coalescing */ #define EFI_MEMORY_WT ((u64)0x0000000000000004ULL) /* write-through */ @@ -597,6 +600,10 @@ extern void efi_initialize_iomem_resources(struct resource *code_resource, extern void efi_get_time(struct timespec *now); extern int efi_set_rtc_mmss(const struct timespec *now); extern void efi_reserve_boot_services(void); +#ifdef CONFIG_XEN +extern int __init efi_config_init(u64 tables, int nr_tables, int entrySz); +extern void xen_efi_probe(void); +#endif extern struct efi_memory_map memmap; /** @@ -634,6 +641,7 @@ extern int __init efi_setup_pcdp_console(char *); #define EFI_RUNTIME_SERVICES 3 /* Can we use runtime services? */ #define EFI_MEMMAP 4 /* Can we use EFI memory map? */ #define EFI_64BIT 5 /* Is the firmware 64-bit? */ +#define EFI_XEN 6 /* Must we access EFI via Xen? */ #ifdef CONFIG_EFI # ifdef CONFIG_X86 diff --git a/include/xen/interface/platform.h b/include/xen/interface/platform.h index c57d5f6..d005f0b 100644 --- a/include/xen/interface/platform.h +++ b/include/xen/interface/platform.h @@ -108,10 +108,111 @@ struct xenpf_platform_quirk { }; DEFINE_GUEST_HANDLE_STRUCT(xenpf_platform_quirk_t); +#define XENPF_efi_runtime_call 49 +#define XEN_EFI_get_time 1 +#define XEN_EFI_set_time 2 +#define XEN_EFI_get_wakeup_time 3 +#define XEN_EFI_set_wakeup_time 4 +#define XEN_EFI_get_next_high_monotonic_count 5 +#define XEN_EFI_get_variable 6 +#define XEN_EFI_set_variable 7 +#define XEN_EFI_get_next_variable_name 8 +#define XEN_EFI_query_variable_info 9 +#define XEN_EFI_query_capsule_capabilities 10 +#define XEN_EFI_update_capsule 11 + +struct xenpf_efi_runtime_call { + uint32_t function; + /* + * This field is generally used for per sub-function flags (defined + * below), except for the XEN_EFI_get_next_high_monotonic_count case, + * where it holds the single returned value. + */ + uint32_t misc; + unsigned long status; + union { +#define XEN_EFI_GET_TIME_SET_CLEARS_NS 0x00000001 + struct { + struct xenpf_efi_time { + uint16_t year; + uint8_t month; + uint8_t day; + uint8_t hour; + uint8_t min; + uint8_t sec; + uint32_t ns; + int16_t tz; + uint8_t daylight; + } time; + uint32_t resolution; + uint32_t accuracy; + } get_time; + + struct xenpf_efi_time set_time; + +#define XEN_EFI_GET_WAKEUP_TIME_ENABLED 0x00000001 +#define XEN_EFI_GET_WAKEUP_TIME_PENDING 0x00000002 + struct xenpf_efi_time get_wakeup_time; + +#define XEN_EFI_SET_WAKEUP_TIME_ENABLE 0x00000001 +#define XEN_EFI_SET_WAKEUP_TIME_ENABLE_ONLY 0x00000002 + struct xenpf_efi_time set_wakeup_time; + +#define XEN_EFI_VARIABLE_NON_VOLATILE 0x00000001 +#define XEN_EFI_VARIABLE_BOOTSERVICE_ACCESS 0x00000002 +#define XEN_EFI_VARIABLE_RUNTIME_ACCESS 0x00000004 + struct { + GUEST_HANDLE(void) name; /* UCS-2/UTF-16 string */ + unsigned long size; + GUEST_HANDLE(void) data; + struct xenpf_efi_guid { + uint32_t data1; + uint16_t data2; + uint16_t data3; + uint8_t data4[8]; + } vendor_guid; + } get_variable, set_variable; + + struct { + unsigned long size; + GUEST_HANDLE(void) name; /* UCS-2/UTF-16 string */ + struct xenpf_efi_guid vendor_guid; + } get_next_variable_name; + + struct { + uint32_t attr; + uint64_t max_store_size; + uint64_t remain_store_size; + uint64_t max_size; + } query_variable_info; + + struct { + GUEST_HANDLE(void) capsule_header_array; + unsigned long capsule_count; + uint64_t max_capsule_size; + unsigned int reset_type; + } query_capsule_capabilities; + + struct { + GUEST_HANDLE(void) capsule_header_array; + unsigned long capsule_count; + uint64_t sg_list; /* machine address */ + } update_capsule; + } u; +}; +DEFINE_GUEST_HANDLE_STRUCT(xenpf_efi_runtime_call); + #define XENPF_firmware_info 50 #define XEN_FW_DISK_INFO 1 /* from int 13 AH=08/41/48 */ #define XEN_FW_DISK_MBR_SIGNATURE 2 /* from MBR offset 0x1b8 */ #define XEN_FW_VBEDDC_INFO 3 /* from int 10 AX=4f15 */ +#define XEN_FW_EFI_INFO 4 /* from EFI */ +#define XEN_FW_EFI_VERSION 0 +#define XEN_FW_EFI_CONFIG_TABLE 1 +#define XEN_FW_EFI_VENDOR 2 +#define XEN_FW_EFI_MEM_INFO 3 +#define XEN_FW_EFI_RT_VERSION 4 +#define XEN_FW_EFI_PCI_ROM 5 #define XEN_FW_KBD_SHIFT_FLAGS 5 /* Int16, Fn02: Get keyboard shift flags. */ struct xenpf_firmware_info { /* IN variables. */ @@ -143,6 +244,36 @@ struct xenpf_firmware_info { /* must refer to 128-byte buffer */ GUEST_HANDLE(uchar) edid; } vbeddc_info; /* XEN_FW_VBEDDC_INFO */ + union xenpf_efi_info { + uint32_t version; + struct { + uint64_t addr; /* EFI_CONFIGURATION_TABLE */ + uint32_t nent; + } cfg; + struct { + uint32_t revision; + uint32_t bufsz; /* input, in bytes */ + GUEST_HANDLE(void) name; + /* UCS-2/UTF-16 string */ + } vendor; + struct { + uint64_t addr; + uint64_t size; + uint64_t attr; + uint32_t type; + } mem; + struct { + /* IN variables */ + uint16_t segment; + uint8_t bus; + uint8_t devfn; + uint16_t vendor; + uint16_t devid; + /* OUT variables */ + uint64_t address; + xen_ulong_t size; + } pci_rom; + } efi_info; /* XEN_FW_EFI_INFO */ uint8_t kbd_shift_flags; /* XEN_FW_KBD_SHIFT_FLAGS */ } u; @@ -361,6 +492,7 @@ struct xen_platform_op { struct xenpf_read_memtype read_memtype; struct xenpf_microcode_update microcode; struct xenpf_platform_quirk platform_quirk; + struct xenpf_efi_runtime_call efi_runtime_call; struct xenpf_firmware_info firmware_info; struct xenpf_enter_acpi_sleep enter_acpi_sleep; struct xenpf_change_freq change_freq; -- 1.8.3.4 ^ permalink raw reply related [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 20:51 ` Eric Shelton 2013-08-09 18:56 ` Daniel Kiper @ 2013-08-20 16:13 ` Stefano Stabellini 1 sibling, 0 replies; 116+ messages in thread From: Stefano Stabellini @ 2013-08-20 16:13 UTC (permalink / raw) To: Eric Shelton Cc: Ian Campbell, George Dunlap, Daniel Kiper, xen-devel, Julien Grall On Thu, 8 Aug 2013, Eric Shelton wrote: > Related to this, is the Xen hypervisor booting under EFI for arm > already? Not yet, but it's on our todo list. > I assume not, if Linux currently lacks the needed > hypercalls. Does anything arm-specific need to happen in an > EFI-friendly dom0 kernel, given that it is hypercall driven? Is there > a platform for test? It would be great if you could generalize your work enough so that it would at least compile on arm. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Xen 4.4 development update @ 2013-08-08 16:09 George Dunlap 2013-08-08 16:11 ` George Dunlap ` (18 more replies) 0 siblings, 19 replies; 116+ messages in thread From: George Dunlap @ 2013-08-08 16:09 UTC (permalink / raw) To: xen-devel This information will be mirrored on the Xen 4.4 Roadmap wiki page: http://wiki.xen.org/wiki/Xen_Roadmap/4.4 Rather than try to predict precisely what will make it into what release (which was something of a disaster last release), I'm just going to borrow a term from the Agile world and call all uncompleted features the "Backlog". I'll still track who is doing what, and when we get close, what state things seem to be in. As mentioned in another e-mail, we'll also be working on improving the regression tester. Feel free to join us. And as always, if you are working on a feature / bug that you want tracked, please respond to this e-mail. = Timeline = As discussed elsewhere, I am proposing a 6-month release cycle. Xen 4.3 was released on 9 July. That would give us a release on 9 January 2014. This is fairly close after the Christmas season, so I propose to make the estimated release date later, on 21 January, giving a few extra weeks for the holiday season: * Feature freeze: 18 October 2013 * Code freezing point: 8 November 2013 * First RC: 26 November 2013 * Release: 21 January 2014 Feedback on the estimated dates is welcome. Last updated: 8 August 2013 == Completed == [none] == Open == * xend still in tree * qemu-upstream not freeing pirq > http://www.gossamer-threads.com/lists/xen/devel/281498 status: patches posted * __update_vcpu_system_time if system_time comes out negative * xl pci-detach broken for pv guests? > http://bugs.xenproject.org/xen/bug/12 > kernel doesn't know about moving into states 7 and 8 status: External * Race in PV shutdown between tool detection and shutdown watch > http://www.gossamer-threads.com/lists/xen/devel/282467 > Nothing to do with ACPI status: Probably a bug in Linux xen drivers == Backlog == === Testing coverage === * Network driver domains @George * new libxl w/ previous versions of xl @IanJ * Host S3 suspend @bguthro * Default [example] XSM policy @Stefano to ask Daniel D * Xen on ARM # hardware @ianc emulator: @stefano to think about it * Storage driver domains @roger * HVM pci passthrough @anthony * Nested virt? @intel (chased by George) * Fix SRIOV test (chase intel) @ianj * Fix bisector to e-mail blame-worthy parties @ianj * Fix xl shutdown @ianj * stub domains @athony === Big ticket items === * NUMA Memory migration owner: dario@citrix status: in progress * Event channel scalability owner: david@citrix status: RFC v5 submitted Increase limit on event channels (currently 1024 for 32-bit guests, 4096 for 64-bit guests) * PVH mode (w/ Linux) owner: mukesh@oracle status (Linux): 3rd draft patches posted. status (Xen): v10 posted * ARM stuff: ?? * Meta: PVIO NUMA improvements - NUMA affinity for vcpus owner: Dario - PV guest NUMA interface owner: Elena - Sensible dom0 NUMA layout - Toolstack pinning backend thread / virq to appropraite d0 vcpu * qemu-upstream stubdom, Linux owner: anthony@citrix status: in progress qemu-upstream needs a more fully-featured libc than exists in mini-os. Either work on a minimalist linux-based stubdom with glibc, or port one of the BSD libcs to minios. * qemu-upstream stubdom, BSD libc owner: ianj@citrix * Network performance improvements owner: wei@citrix * Disk performance improvements * Xen EFI feature: Xen can boot from grub.efi owner: Daniel Kiper status: Just begun prognosis: Fair * libvirt/libxl integration (external) > need a status update - owner: jfehlig@suse, dario@citrix * Default to credit2 - cpu pinning - NUMA affinity - cpu "reservation" * xenperf Owner: Boris Otovsky * blktap3 owner: thanos@citrix status: on hold pending XenServer decision * Nested virtualization on Intel * Nested virtualization on AMD * Make storage migration possible owner: ? status: none There needs to be a way, either via command-line or via some hooks, that someone can build a "storage migration" feature on top of libxl or xl. * Full-VM snapshotting owner: ? status: none Have a way of coordinating the taking and restoring of VM memory and disk snapshots. This would involve some investigation into the best way to accomplish this. * VM Cloning owner: ? status: none Again, a way of coordinating the memory and disk aspects. Research into the best way to do this would probably go along with the snapshotting feature. * xl vm-{export,import} owner: ? status: none Allow xl to import and export VMs to other formats; particularly ovf, perhaps the XenServer format, or more. * Memory: Replace PoD with paging mechanism owner: george@citrix status: none * PV audio (audio for stubdom qemu) owner: stefano.panella@citrix status: ? * Wait queues for mm > Needed for more advanced paging schemes owner: ? status: Draft posted Feb 2012; more work to do. * V4V: Inter-domain communication owner (Xen): dominic.curran@citrix.com status (Xen): patches submitted owner (Linux driver): stefano.panella@citrix status (Linux driver): in progress === clean-ups === * Sort out better memory / ballooning / dom0 autoballooning thing > Don't forget NUMA angle - Inaccurate / incomplete info from HV * Implement Xen hypervisor dmesg log entry timestamps * Make network driver domains easier to set up / more useful - Default backend (submitted) - Remove unnecessary restriction wrt dom0 hotplug scripts (submitted) - Make it easy to make a device assignable (in discussion) - Automatically start/shutdown (xendomains?) - Pause booting of other domains until network driver domain is up * libxl: More fine-grained control over when to pass through a device > Some IOMMUs are secure; some are merely functional, some are not present. > Allow the adminitrator to set the default * xl does not handle migrate interruption gracefully > If you start a localhost migrate, and press "Ctrl-C" in the middle, > you get two hung domains status: Probably not for 4.3 * libxl / xl does not handle failure of remote qemu gracefully > Easiest way to reproduce: > - set "vncunused=0" and do a local migrate > - The "remote" qemu will fail because the vnc port is in use > The failure isn't the problem, but everything being stuck afterwards is status: Probably not for 4.3 * mac address changes on reboot if not specified in config file > Needs a robust way to "add" to the config status: Too much for 4.3 * qxl > http://bugs.xenproject.org/xen/bug/11http://bugs.xenproject.org/xen/bug/11 - Uninitialized struct element in qemu - Revert 5479961 to re-enable qxl in xl,libxl - Option in Xen top-level to enable qxl support in qemu tree - Fix sse2 MMIO issue * libxl config file * libxl: Don't use RAW format for "URL"-based qdisks (e.g., rbd:rbd/foo.img) - Figure out whether to use a generic URL or have a specific type for each one - Check existence of disk file for all RAW * Polish up xenbugtool owner: wei.liu2@citrix.com * acpi-related xenstore entries not propagated on migrate > http://www.gossamer-threads.com/lists/xen/devel/282466 > Only used by hvmloader; only a clean-up, not a bug. status: Not for 4.3 * Remove hardcoded mobprobe's in xencommons owner: Wei Liu status: still in discussion * xl USB pass-through for HVM guests using Qemu USB emulation owner: George status: v6 patch series posted * Rationalized backend scripts owner: roger@citrix status: patches posted * Scripts for driver domains (depends on backend scripts) owner: roger@citrix status: * Multi-vector PCI MSI (support at least for Dom0) owner: jan@suse status: Patches posted for Intel; AMD not yet done * xl: passing more defaults in configuration in xl.conf owner: ? There are a number of options for which it might be useful to pass a default in xl.conf. For example, if we could have a default "backend" parameter for vifs, then it would be easy to switch back and forth between a backend in a driver domain and a backend in dom0. * xl PVUSB pass-through for PV guests * xl PVUSB pass-through for HVM guests owner: George status: ? xm/xend supports PVUSB pass-through to guests with PVUSB drivers (both PV and HVM guests). - port the xm/xend functionality to xl. - this PVUSB feature does not require support or emulation from Qemu. - upstream the Linux frontend/backend drivers. Current work-in-progress versions are in Konrad's git tree. - James Harper's GPLPV drivers for Windows include PVUSB frontend drivers. * Guest EFI booting - status: tianocore in-tree, some build problems. Needs new owner. * Xen EFI feature: pvops dom0 able to make use of EFI run-time services (external) owner: Daniel Kiper status: Just begun * Serial console improvements owner: ? status: Stalled (see below) -xHCI debug port (Needs hardware) -Firewire (needs hardware) ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:09 George Dunlap @ 2013-08-08 16:11 ` George Dunlap 2013-08-09 8:11 ` Jan Beulich 2013-08-08 16:14 ` George Dunlap ` (17 subsequent siblings) 18 siblings, 1 reply; 116+ messages in thread From: George Dunlap @ 2013-08-08 16:11 UTC (permalink / raw) To: xen-devel On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > * blktap3 > owner: thanos@citrix > status: on hold pending XenServer decision Sorry, missed this one -- this is more or less cancelled. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:11 ` George Dunlap @ 2013-08-09 8:11 ` Jan Beulich 2013-08-09 11:08 ` Dario Faggioli 0 siblings, 1 reply; 116+ messages in thread From: Jan Beulich @ 2013-08-09 8:11 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel >>> On 08.08.13 at 18:11, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap > <George.Dunlap@eu.citrix.com> wrote: >> * blktap3 >> owner: thanos@citrix >> status: on hold pending XenServer decision > > Sorry, missed this one -- this is more or less cancelled. So is there any supposed replacement then? Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-09 8:11 ` Jan Beulich @ 2013-08-09 11:08 ` Dario Faggioli 0 siblings, 0 replies; 116+ messages in thread From: Dario Faggioli @ 2013-08-09 11:08 UTC (permalink / raw) To: Jan Beulich; +Cc: George Dunlap, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 877 bytes --] On ven, 2013-08-09 at 09:11 +0100, Jan Beulich wrote: > >>> On 08.08.13 at 18:11, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > > On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap > > <George.Dunlap@eu.citrix.com> wrote: > >> * blktap3 > >> owner: thanos@citrix > >> status: on hold pending XenServer decision > > > > Sorry, missed this one -- this is more or less cancelled. > > So is there any supposed replacement then? > AFAIUI, that is using (and improving) qdisk for all the (previous) blktap use cases: http://lists.xen.org/archives/html/xen-devel/2013-07/msg02433.html Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:09 George Dunlap 2013-08-08 16:11 ` George Dunlap @ 2013-08-08 16:14 ` George Dunlap 2013-08-08 16:17 ` Andrew Cooper 2013-08-08 16:24 ` Ian Campbell 2013-08-08 19:30 ` Konrad Rzeszutek Wilk ` (16 subsequent siblings) 18 siblings, 2 replies; 116+ messages in thread From: George Dunlap @ 2013-08-08 16:14 UTC (permalink / raw) To: xen-devel > * qxl > > http://bugs.xenproject.org/xen/bug/11http://bugs.xenproject.org/xen/bug/11 > - Uninitialized struct element in qemu > - Revert 5479961 to re-enable qxl in xl,libxl > - Option in Xen top-level to enable qxl support in qemu tree > - Fix sse2 MMIO issue qxl has been re-enabled, but we still haven't had anyone step up to implement >8-byte IO instructions. Any takers? -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:14 ` George Dunlap @ 2013-08-08 16:17 ` Andrew Cooper 2013-08-09 8:08 ` Jan Beulich 2013-08-08 16:24 ` Ian Campbell 1 sibling, 1 reply; 116+ messages in thread From: Andrew Cooper @ 2013-08-08 16:17 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel On 08/08/13 17:14, George Dunlap wrote: >> * qxl >> > http://bugs.xenproject.org/xen/bug/11http://bugs.xenproject.org/xen/bug/11 >> - Uninitialized struct element in qemu >> - Revert 5479961 to re-enable qxl in xl,libxl >> - Option in Xen top-level to enable qxl support in qemu tree >> - Fix sse2 MMIO issue > qxl has been re-enabled, but we still haven't had anyone step up to > implement >8-byte IO instructions. Any takers? > > -George Not that I have time to look at this, but can this requirement include support for 32 byte IO instructions, to allow for AVX emulation as well as just SSE. ~Andrew > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:17 ` Andrew Cooper @ 2013-08-09 8:08 ` Jan Beulich 0 siblings, 0 replies; 116+ messages in thread From: Jan Beulich @ 2013-08-09 8:08 UTC (permalink / raw) To: Andrew Cooper, George Dunlap; +Cc: xen-devel >>> On 08.08.13 at 18:17, Andrew Cooper <andrew.cooper3@citrix.com> wrote: > On 08/08/13 17:14, George Dunlap wrote: >>> * qxl >>> > > http://bugs.xenproject.org/xen/bug/11http://bugs.xenproject.org/xen/bug/11 >>> - Uninitialized struct element in qemu >>> - Revert 5479961 to re-enable qxl in xl,libxl >>> - Option in Xen top-level to enable qxl support in qemu tree >>> - Fix sse2 MMIO issue >> qxl has been re-enabled, but we still haven't had anyone step up to >> implement >8-byte IO instructions. Any takers? >> >> -George > > Not that I have time to look at this, but can this requirement include > support for 32 byte IO instructions, to allow for AVX emulation as well > as just SSE. If anything, we should make this arbitrary size anyway. AVX-512 is already at the horizon. Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:14 ` George Dunlap 2013-08-08 16:17 ` Andrew Cooper @ 2013-08-08 16:24 ` Ian Campbell 2013-08-13 16:06 ` George Dunlap 1 sibling, 1 reply; 116+ messages in thread From: Ian Campbell @ 2013-08-08 16:24 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel On Thu, 2013-08-08 at 17:14 +0100, George Dunlap wrote: > > * qxl > > > http://bugs.xenproject.org/xen/bug/11http://bugs.xenproject.org/xen/bug/11 > > - Uninitialized struct element in qemu > > - Revert 5479961 to re-enable qxl in xl,libxl > > - Option in Xen top-level to enable qxl support in qemu tree > > - Fix sse2 MMIO issue > > qxl has been re-enabled, Has it? I can't see a patch with qxl in the title after "libxl: Remove qxl support for the 4.3 release". > but we still haven't had anyone step up to implement >8-byte IO > instructions. Any takers? Assuming I'm right and it hasn't been enabled is there any reason this shouldn't be a prerequisite for enabling qxl? Ian. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:24 ` Ian Campbell @ 2013-08-13 16:06 ` George Dunlap 0 siblings, 0 replies; 116+ messages in thread From: George Dunlap @ 2013-08-13 16:06 UTC (permalink / raw) To: Ian Campbell; +Cc: xen-devel On 08/08/13 17:24, Ian Campbell wrote: > On Thu, 2013-08-08 at 17:14 +0100, George Dunlap wrote: >>> * qxl >>> > http://bugs.xenproject.org/xen/bug/11http://bugs.xenproject.org/xen/bug/11 >>> - Uninitialized struct element in qemu >>> - Revert 5479961 to re-enable qxl in xl,libxl >>> - Option in Xen top-level to enable qxl support in qemu tree >>> - Fix sse2 MMIO issue >> qxl has been re-enabled, > Has it? I can't see a patch with qxl in the title after "libxl: Remove > qxl support for the 4.3 release". Oh, right -- I thought I'd seen it go in; but I guess not. > >> but we still haven't had anyone step up to implement >8-byte IO >> instructions. Any takers? > Assuming I'm right and it hasn't been enabled is there any reason this > shouldn't be a prerequisite for enabling qxl? I wouldn't think so -- I view the extended instruction support as a bug. In any case, having the qxl functionality will make an easy way for developers to test the vector instruction functionality. -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:09 George Dunlap 2013-08-08 16:11 ` George Dunlap 2013-08-08 16:14 ` George Dunlap @ 2013-08-08 19:30 ` Konrad Rzeszutek Wilk 2013-08-13 16:19 ` George Dunlap 2013-08-13 16:22 ` George Dunlap 2013-08-09 7:57 ` Jan Beulich ` (15 subsequent siblings) 18 siblings, 2 replies; 116+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-08-08 19:30 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: > This information will be mirrored on the Xen 4.4 Roadmap wiki page: > http://wiki.xen.org/wiki/Xen_Roadmap/4.4 > > Rather than try to predict precisely what will make it into what > release (which was something of a disaster last release), I'm just > going to borrow a term from the Agile world and call all uncompleted > features the "Backlog". I'll still track who is doing what, and when > we get close, what state things seem to be in. > > As mentioned in another e-mail, we'll also be working on improving the > regression tester. Feel free to join us. > > And as always, if you are working on a feature / bug that you want > tracked, please respond to this e-mail. > > = Timeline = > > As discussed elsewhere, I am proposing a 6-month release cycle. Xen > 4.3 was released on 9 July. That would give us a release on 9 January > 2014. This is fairly close after the Christmas season, so I propose > to make the estimated release date later, on 21 January, giving a few > extra weeks for the holiday season: > > * Feature freeze: 18 October 2013 > * Code freezing point: 8 November 2013 > * First RC: 26 November 2013 > * Release: 21 January 2014 > > Feedback on the estimated dates is welcome. > > Last updated: 8 August 2013 > > == Completed == > > [none] > > == Open == > > * xend still in tree > > * qemu-upstream not freeing pirq > > http://www.gossamer-threads.com/lists/xen/devel/281498 > status: patches posted They did fix the problem Oracle saw and I believe have been Tested-and-Acked. > > * __update_vcpu_system_time if system_time comes out negative > > * xl pci-detach broken for pv guests? > > http://bugs.xenproject.org/xen/bug/12 > > kernel doesn't know about moving into states 7 and 8 > status: External Didn't I post a patch for this on Linux - and it is in Linux kernel already. > > * Race in PV shutdown between tool detection and shutdown watch > > http://www.gossamer-threads.com/lists/xen/devel/282467 > > Nothing to do with ACPI > status: Probably a bug in Linux xen drivers > > == Backlog == > > === Testing coverage === > > * Network driver domains > @George > > * new libxl w/ previous versions of xl > @IanJ > > * Host S3 suspend > @bguthro > > * Default [example] XSM policy > @Stefano to ask Daniel D > > * Xen on ARM > # hardware > @ianc > emulator: @stefano to think about it > > * Storage driver domains > @roger > > * HVM pci passthrough > @anthony > > * Nested virt? > @intel (chased by George) > > * Fix SRIOV test (chase intel) > @ianj > > * Fix bisector to e-mail blame-worthy parties > @ianj > > * Fix xl shutdown > @ianj > > * stub domains > @athony > > === Big ticket items === > > * NUMA Memory migration > owner: dario@citrix > status: in progress > > * Event channel scalability > owner: david@citrix > status: RFC v5 submitted > Increase limit on event channels (currently 1024 for 32-bit guests, > 4096 for 64-bit guests) aka FIFO thing right? > > * PVH mode (w/ Linux) > owner: mukesh@oracle > status (Linux): 3rd draft patches posted. More like v8. And already Acked - just waiting for ABI to be in some way "nailed down". > status (Xen): v10 posted > > * ARM stuff: ?? > > * Meta: PVIO NUMA improvements > - NUMA affinity for vcpus > owner: Dario > - PV guest NUMA interface > owner: Elena > - Sensible dom0 NUMA layout > - Toolstack pinning backend thread / virq to appropraite d0 vcpu > > * qemu-upstream stubdom, Linux > owner: anthony@citrix > status: in progress > qemu-upstream needs a more fully-featured libc than exists in > mini-os. Either work on a minimalist linux-based stubdom with > glibc, or port one of the BSD libcs to minios. > > * qemu-upstream stubdom, BSD libc > owner: ianj@citrix > > * Network performance improvements > owner: wei@citrix > > * Disk performance improvements I think you mean blkback and blkfront? > > * Xen EFI feature: Xen can boot from grub.efi > owner: Daniel Kiper > status: Just begun > prognosis: Fair > > * libvirt/libxl integration (external) > > need a status update > - owner: jfehlig@suse, dario@citrix > > * Default to credit2 > - cpu pinning > - NUMA affinity > - cpu "reservation" > > * xenperf > Owner: Boris Otovsky > > * blktap3 > owner: thanos@citrix > status: on hold pending XenServer decision > > * Nested virtualization on Intel > > * Nested virtualization on AMD > > * Make storage migration possible > owner: ? > status: none > There needs to be a way, either via command-line or via some hooks, > that someone can build a "storage migration" feature on top of libxl > or xl. > > * Full-VM snapshotting > owner: ? > status: none > Have a way of coordinating the taking and restoring of VM memory and > disk snapshots. This would involve some investigation into the best > way to accomplish this. > > * VM Cloning > owner: ? > status: none > Again, a way of coordinating the memory and disk aspects. Research > into the best way to do this would probably go along with the > snapshotting feature. > > * xl vm-{export,import} > owner: ? > status: none > Allow xl to import and export VMs to other formats; particularly > ovf, perhaps the XenServer format, or more. > > * Memory: Replace PoD with paging mechanism > owner: george@citrix > status: none > > * PV audio (audio for stubdom qemu) > owner: stefano.panella@citrix > status: ? > > * Wait queues for mm > > Needed for more advanced paging schemes > owner: ? > status: Draft posted Feb 2012; more work to do. > > * V4V: Inter-domain communication > owner (Xen): dominic.curran@citrix.com > status (Xen): patches submitted > owner (Linux driver): stefano.panella@citrix > status (Linux driver): in progress > > === clean-ups === > > * Sort out better memory / ballooning / dom0 autoballooning thing > > Don't forget NUMA angle > - Inaccurate / incomplete info from HV > > * Implement Xen hypervisor dmesg log entry timestamps > > * Make network driver domains easier to set up / more useful > - Default backend (submitted) > - Remove unnecessary restriction wrt dom0 hotplug scripts (submitted) > - Make it easy to make a device assignable (in discussion) > - Automatically start/shutdown (xendomains?) > - Pause booting of other domains until network driver domain is up > > * libxl: More fine-grained control over when to pass through a device > > Some IOMMUs are secure; some are merely functional, some are not present. > > Allow the adminitrator to set the default > > * xl does not handle migrate interruption gracefully > > If you start a localhost migrate, and press "Ctrl-C" in the middle, > > you get two hung domains > status: Probably not for 4.3 > > * libxl / xl does not handle failure of remote qemu gracefully > > Easiest way to reproduce: > > - set "vncunused=0" and do a local migrate > > - The "remote" qemu will fail because the vnc port is in use > > The failure isn't the problem, but everything being stuck afterwards is > status: Probably not for 4.3 > > * mac address changes on reboot if not specified in config file > > Needs a robust way to "add" to the config > status: Too much for 4.3 > > * qxl > > http://bugs.xenproject.org/xen/bug/11http://bugs.xenproject.org/xen/bug/11 > - Uninitialized struct element in qemu > - Revert 5479961 to re-enable qxl in xl,libxl > - Option in Xen top-level to enable qxl support in qemu tree > - Fix sse2 MMIO issue > > * libxl config file > > * libxl: Don't use RAW format for "URL"-based qdisks (e.g., rbd:rbd/foo.img) > - Figure out whether to use a generic URL or have a specific type for each one > - Check existence of disk file for all RAW > > * Polish up xenbugtool > owner: wei.liu2@citrix.com > > * acpi-related xenstore entries not propagated on migrate > > http://www.gossamer-threads.com/lists/xen/devel/282466 > > Only used by hvmloader; only a clean-up, not a bug. > status: Not for 4.3 > > * Remove hardcoded mobprobe's in xencommons > owner: Wei Liu > status: still in discussion > > * xl USB pass-through for HVM guests using Qemu USB emulation > owner: George > status: v6 patch series posted > > * Rationalized backend scripts > owner: roger@citrix > status: patches posted > > * Scripts for driver domains (depends on backend scripts) > owner: roger@citrix > status: > > * Multi-vector PCI MSI (support at least for Dom0) > owner: jan@suse > status: Patches posted for Intel; AMD not yet done And patches for Linux upstream are missing. > > * xl: passing more defaults in configuration in xl.conf > owner: ? > There are a number of options for which it might be useful to pass a > default in xl.conf. For example, if we could have a default > "backend" parameter for vifs, then it would be easy to switch back > and forth between a backend in a driver domain and a backend in dom0. > > * xl PVUSB pass-through for PV guests > * xl PVUSB pass-through for HVM guests > owner: George > status: ? > xm/xend supports PVUSB pass-through to guests with PVUSB drivers > (both PV and HVM guests). > - port the xm/xend functionality to xl. > - this PVUSB feature does not require support or emulation from Qemu. > - upstream the Linux frontend/backend drivers. Current > work-in-progress versions are in Konrad's git tree. Which is to say I hadn't actually touched them in a year. > - James Harper's GPLPV drivers for Windows include PVUSB frontend drivers. > > * Guest EFI booting > - status: tianocore in-tree, some build problems. > Needs new owner. > > * Xen EFI feature: pvops dom0 able to make use of EFI run-time > services (external) > owner: Daniel Kiper > status: Just begun > > * Serial console improvements > owner: ? > status: Stalled (see below) > -xHCI debug port (Needs hardware) > -Firewire (needs hardware) > I would like also to put GPU passthrough working here. > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 19:30 ` Konrad Rzeszutek Wilk @ 2013-08-13 16:19 ` George Dunlap 2013-08-29 11:49 ` Fabio Fantoni 2013-08-13 16:22 ` George Dunlap 1 sibling, 1 reply; 116+ messages in thread From: George Dunlap @ 2013-08-13 16:19 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: xen-devel On 08/08/13 20:30, Konrad Rzeszutek Wilk wrote: > On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: >> This information will be mirrored on the Xen 4.4 Roadmap wiki page: >> http://wiki.xen.org/wiki/Xen_Roadmap/4.4 >> >> Rather than try to predict precisely what will make it into what >> release (which was something of a disaster last release), I'm just >> going to borrow a term from the Agile world and call all uncompleted >> features the "Backlog". I'll still track who is doing what, and when >> we get close, what state things seem to be in. >> >> As mentioned in another e-mail, we'll also be working on improving the >> regression tester. Feel free to join us. >> >> And as always, if you are working on a feature / bug that you want >> tracked, please respond to this e-mail. >> >> = Timeline = >> >> As discussed elsewhere, I am proposing a 6-month release cycle. Xen >> 4.3 was released on 9 July. That would give us a release on 9 January >> 2014. This is fairly close after the Christmas season, so I propose >> to make the estimated release date later, on 21 January, giving a few >> extra weeks for the holiday season: >> >> * Feature freeze: 18 October 2013 >> * Code freezing point: 8 November 2013 >> * First RC: 26 November 2013 >> * Release: 21 January 2014 >> >> Feedback on the estimated dates is welcome. >> >> Last updated: 8 August 2013 >> >> == Completed == >> >> [none] >> >> == Open == >> >> * xend still in tree >> >> * qemu-upstream not freeing pirq >> > http://www.gossamer-threads.com/lists/xen/devel/281498 >> status: patches posted > They did fix the problem Oracle saw and I believe have been > Tested-and-Acked. Thanks -- have they also been applied? > >> * __update_vcpu_system_time if system_time comes out negative >> >> * xl pci-detach broken for pv guests? >> > http://bugs.xenproject.org/xen/bug/12 >> > kernel doesn't know about moving into states 7 and 8 >> status: External > Didn't I post a patch for this on Linux - and it is in Linux kernel > already. Great -- thanks for the update. >> * Race in PV shutdown between tool detection and shutdown watch >> > http://www.gossamer-threads.com/lists/xen/devel/282467 >> > Nothing to do with ACPI >> status: Probably a bug in Linux xen drivers >> >> == Backlog == >> >> === Testing coverage === >> >> * Network driver domains >> @George >> >> * new libxl w/ previous versions of xl >> @IanJ >> >> * Host S3 suspend >> @bguthro >> >> * Default [example] XSM policy >> @Stefano to ask Daniel D >> >> * Xen on ARM >> # hardware >> @ianc >> emulator: @stefano to think about it >> >> * Storage driver domains >> @roger >> >> * HVM pci passthrough >> @anthony >> >> * Nested virt? >> @intel (chased by George) >> >> * Fix SRIOV test (chase intel) >> @ianj >> >> * Fix bisector to e-mail blame-worthy parties >> @ianj >> >> * Fix xl shutdown >> @ianj >> >> * stub domains >> @athony >> >> === Big ticket items === >> >> * NUMA Memory migration >> owner: dario@citrix >> status: in progress >> >> * Event channel scalability >> owner: david@citrix >> status: RFC v5 submitted >> Increase limit on event channels (currently 1024 for 32-bit guests, >> 4096 for 64-bit guests) > aka FIFO thing right? Yep. I'll make this a bit more clear. > >> * PVH mode (w/ Linux) >> owner: mukesh@oracle >> status (Linux): 3rd draft patches posted. > More like v8. And already Acked - just waiting for ABI to be in some way > "nailed down". > >> status (Xen): v10 posted >> >> * ARM stuff: ?? >> >> * Meta: PVIO NUMA improvements >> - NUMA affinity for vcpus >> owner: Dario >> - PV guest NUMA interface >> owner: Elena >> - Sensible dom0 NUMA layout >> - Toolstack pinning backend thread / virq to appropraite d0 vcpu >> >> * qemu-upstream stubdom, Linux >> owner: anthony@citrix >> status: in progress >> qemu-upstream needs a more fully-featured libc than exists in >> mini-os. Either work on a minimalist linux-based stubdom with >> glibc, or port one of the BSD libcs to minios. >> >> * qemu-upstream stubdom, BSD libc >> owner: ianj@citrix >> >> * Network performance improvements >> owner: wei@citrix >> >> * Disk performance improvements > I think you mean blkback and blkfront? >> * Xen EFI feature: Xen can boot from grub.efi >> owner: Daniel Kiper >> status: Just begun >> prognosis: Fair >> >> * libvirt/libxl integration (external) >> > need a status update >> - owner: jfehlig@suse, dario@citrix >> >> * Default to credit2 >> - cpu pinning >> - NUMA affinity >> - cpu "reservation" >> >> * xenperf >> Owner: Boris Otovsky >> >> * blktap3 >> owner: thanos@citrix >> status: on hold pending XenServer decision >> >> * Nested virtualization on Intel >> >> * Nested virtualization on AMD >> >> * Make storage migration possible >> owner: ? >> status: none >> There needs to be a way, either via command-line or via some hooks, >> that someone can build a "storage migration" feature on top of libxl >> or xl. >> >> * Full-VM snapshotting >> owner: ? >> status: none >> Have a way of coordinating the taking and restoring of VM memory and >> disk snapshots. This would involve some investigation into the best >> way to accomplish this. >> >> * VM Cloning >> owner: ? >> status: none >> Again, a way of coordinating the memory and disk aspects. Research >> into the best way to do this would probably go along with the >> snapshotting feature. >> >> * xl vm-{export,import} >> owner: ? >> status: none >> Allow xl to import and export VMs to other formats; particularly >> ovf, perhaps the XenServer format, or more. >> >> * Memory: Replace PoD with paging mechanism >> owner: george@citrix >> status: none >> >> * PV audio (audio for stubdom qemu) >> owner: stefano.panella@citrix >> status: ? >> >> * Wait queues for mm >> > Needed for more advanced paging schemes >> owner: ? >> status: Draft posted Feb 2012; more work to do. >> >> * V4V: Inter-domain communication >> owner (Xen): dominic.curran@citrix.com >> status (Xen): patches submitted >> owner (Linux driver): stefano.panella@citrix >> status (Linux driver): in progress >> >> === clean-ups === >> >> * Sort out better memory / ballooning / dom0 autoballooning thing >> > Don't forget NUMA angle >> - Inaccurate / incomplete info from HV >> >> * Implement Xen hypervisor dmesg log entry timestamps >> >> * Make network driver domains easier to set up / more useful >> - Default backend (submitted) >> - Remove unnecessary restriction wrt dom0 hotplug scripts (submitted) >> - Make it easy to make a device assignable (in discussion) >> - Automatically start/shutdown (xendomains?) >> - Pause booting of other domains until network driver domain is up >> >> * libxl: More fine-grained control over when to pass through a device >> > Some IOMMUs are secure; some are merely functional, some are not present. >> > Allow the adminitrator to set the default >> >> * xl does not handle migrate interruption gracefully >> > If you start a localhost migrate, and press "Ctrl-C" in the middle, >> > you get two hung domains >> status: Probably not for 4.3 >> >> * libxl / xl does not handle failure of remote qemu gracefully >> > Easiest way to reproduce: >> > - set "vncunused=0" and do a local migrate >> > - The "remote" qemu will fail because the vnc port is in use >> > The failure isn't the problem, but everything being stuck afterwards is >> status: Probably not for 4.3 >> >> * mac address changes on reboot if not specified in config file >> > Needs a robust way to "add" to the config >> status: Too much for 4.3 >> >> * qxl >> > http://bugs.xenproject.org/xen/bug/11http://bugs.xenproject.org/xen/bug/11 >> - Uninitialized struct element in qemu >> - Revert 5479961 to re-enable qxl in xl,libxl >> - Option in Xen top-level to enable qxl support in qemu tree >> - Fix sse2 MMIO issue >> >> * libxl config file >> >> * libxl: Don't use RAW format for "URL"-based qdisks (e.g., rbd:rbd/foo.img) >> - Figure out whether to use a generic URL or have a specific type for each one >> - Check existence of disk file for all RAW >> >> * Polish up xenbugtool >> owner: wei.liu2@citrix.com >> >> * acpi-related xenstore entries not propagated on migrate >> > http://www.gossamer-threads.com/lists/xen/devel/282466 >> > Only used by hvmloader; only a clean-up, not a bug. >> status: Not for 4.3 >> >> * Remove hardcoded mobprobe's in xencommons >> owner: Wei Liu >> status: still in discussion >> >> * xl USB pass-through for HVM guests using Qemu USB emulation >> owner: George >> status: v6 patch series posted >> >> * Rationalized backend scripts >> owner: roger@citrix >> status: patches posted >> >> * Scripts for driver domains (depends on backend scripts) >> owner: roger@citrix >> status: >> >> * Multi-vector PCI MSI (support at least for Dom0) >> owner: jan@suse >> status: Patches posted for Intel; AMD not yet done > And patches for Linux upstream are missing. > >> * xl: passing more defaults in configuration in xl.conf >> owner: ? >> There are a number of options for which it might be useful to pass a >> default in xl.conf. For example, if we could have a default >> "backend" parameter for vifs, then it would be easy to switch back >> and forth between a backend in a driver domain and a backend in dom0. >> >> * xl PVUSB pass-through for PV guests >> * xl PVUSB pass-through for HVM guests >> owner: George >> status: ? >> xm/xend supports PVUSB pass-through to guests with PVUSB drivers >> (both PV and HVM guests). >> - port the xm/xend functionality to xl. >> - this PVUSB feature does not require support or emulation from Qemu. >> - upstream the Linux frontend/backend drivers. Current >> work-in-progress versions are in Konrad's git tree. > Which is to say I hadn't actually touched them in a year. Yeah, I was under the impression they weren't really going anywhere. If you think this is unclear, feel free to suggest alternate wording. > >> - James Harper's GPLPV drivers for Windows include PVUSB frontend drivers. >> >> * Guest EFI booting >> - status: tianocore in-tree, some build problems. >> Needs new owner. >> >> * Xen EFI feature: pvops dom0 able to make use of EFI run-time >> services (external) >> owner: Daniel Kiper >> status: Just begun >> >> * Serial console improvements >> owner: ? >> status: Stalled (see below) >> -xHCI debug port (Needs hardware) >> -Firewire (needs hardware) >> > I would like also to put GPU passthrough working here. What aspect do you mean? -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-13 16:19 ` George Dunlap @ 2013-08-29 11:49 ` Fabio Fantoni 0 siblings, 0 replies; 116+ messages in thread From: Fabio Fantoni @ 2013-08-29 11:49 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel Il 13/08/2013 18:19, George Dunlap ha scritto: > On 08/08/13 20:30, Konrad Rzeszutek Wilk wrote: >> On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: >>> This information will be mirrored on the Xen 4.4 Roadmap wiki page: >>> http://wiki.xen.org/wiki/Xen_Roadmap/4.4 >>> >>> Rather than try to predict precisely what will make it into what >>> release (which was something of a disaster last release), I'm just >>> going to borrow a term from the Agile world and call all uncompleted >>> features the "Backlog". I'll still track who is doing what, and when >>> we get close, what state things seem to be in. >>> >>> As mentioned in another e-mail, we'll also be working on improving the >>> regression tester. Feel free to join us. >>> >>> And as always, if you are working on a feature / bug that you want >>> tracked, please respond to this e-mail. >>> >>> = Timeline = >>> >>> As discussed elsewhere, I am proposing a 6-month release cycle. Xen >>> 4.3 was released on 9 July. That would give us a release on 9 January >>> 2014. This is fairly close after the Christmas season, so I propose >>> to make the estimated release date later, on 21 January, giving a few >>> extra weeks for the holiday season: >>> >>> * Feature freeze: 18 October 2013 >>> * Code freezing point: 8 November 2013 >>> * First RC: 26 November 2013 >>> * Release: 21 January 2014 >>> >>> Feedback on the estimated dates is welcome. >>> >>> Last updated: 8 August 2013 >>> >>> == Completed == >>> >>> [none] >>> >>> == Open == >>> >>> * xend still in tree >>> >>> * qemu-upstream not freeing pirq >>> > http://www.gossamer-threads.com/lists/xen/devel/281498 >>> status: patches posted >> They did fix the problem Oracle saw and I believe have been >> Tested-and-Acked. > > Thanks -- have they also been applied? > >> >>> * __update_vcpu_system_time if system_time comes out negative >>> >>> * xl pci-detach broken for pv guests? >>> > http://bugs.xenproject.org/xen/bug/12 >>> > kernel doesn't know about moving into states 7 and 8 >>> status: External >> Didn't I post a patch for this on Linux - and it is in Linux kernel >> already. > > Great -- thanks for the update. > >>> * Race in PV shutdown between tool detection and shutdown watch >>> > http://www.gossamer-threads.com/lists/xen/devel/282467 >>> > Nothing to do with ACPI >>> status: Probably a bug in Linux xen drivers >>> >>> == Backlog == >>> >>> === Testing coverage === >>> >>> * Network driver domains >>> @George >>> >>> * new libxl w/ previous versions of xl >>> @IanJ >>> >>> * Host S3 suspend >>> @bguthro >>> >>> * Default [example] XSM policy >>> @Stefano to ask Daniel D >>> >>> * Xen on ARM >>> # hardware >>> @ianc >>> emulator: @stefano to think about it >>> >>> * Storage driver domains >>> @roger >>> >>> * HVM pci passthrough >>> @anthony >>> >>> * Nested virt? >>> @intel (chased by George) >>> >>> * Fix SRIOV test (chase intel) >>> @ianj >>> >>> * Fix bisector to e-mail blame-worthy parties >>> @ianj >>> >>> * Fix xl shutdown >>> @ianj >>> >>> * stub domains >>> @athony >>> >>> === Big ticket items === >>> >>> * NUMA Memory migration >>> owner: dario@citrix >>> status: in progress >>> >>> * Event channel scalability >>> owner: david@citrix >>> status: RFC v5 submitted >>> Increase limit on event channels (currently 1024 for 32-bit guests, >>> 4096 for 64-bit guests) >> aka FIFO thing right? > > Yep. I'll make this a bit more clear. > >> >>> * PVH mode (w/ Linux) >>> owner: mukesh@oracle >>> status (Linux): 3rd draft patches posted. >> More like v8. And already Acked - just waiting for ABI to be in some way >> "nailed down". >> >>> status (Xen): v10 posted >>> >>> * ARM stuff: ?? >>> >>> * Meta: PVIO NUMA improvements >>> - NUMA affinity for vcpus >>> owner: Dario >>> - PV guest NUMA interface >>> owner: Elena >>> - Sensible dom0 NUMA layout >>> - Toolstack pinning backend thread / virq to appropraite d0 vcpu >>> >>> * qemu-upstream stubdom, Linux >>> owner: anthony@citrix >>> status: in progress >>> qemu-upstream needs a more fully-featured libc than exists in >>> mini-os. Either work on a minimalist linux-based stubdom with >>> glibc, or port one of the BSD libcs to minios. >>> >>> * qemu-upstream stubdom, BSD libc >>> owner: ianj@citrix >>> >>> * Network performance improvements >>> owner: wei@citrix >>> >>> * Disk performance improvements >> I think you mean blkback and blkfront? >>> * Xen EFI feature: Xen can boot from grub.efi >>> owner: Daniel Kiper >>> status: Just begun >>> prognosis: Fair >>> >>> * libvirt/libxl integration (external) >>> > need a status update >>> - owner: jfehlig@suse, dario@citrix >>> >>> * Default to credit2 >>> - cpu pinning >>> - NUMA affinity >>> - cpu "reservation" >>> >>> * xenperf >>> Owner: Boris Otovsky >>> >>> * blktap3 >>> owner: thanos@citrix >>> status: on hold pending XenServer decision >>> >>> * Nested virtualization on Intel >>> >>> * Nested virtualization on AMD >>> >>> * Make storage migration possible >>> owner: ? >>> status: none >>> There needs to be a way, either via command-line or via some hooks, >>> that someone can build a "storage migration" feature on top of libxl >>> or xl. >>> >>> * Full-VM snapshotting >>> owner: ? >>> status: none >>> Have a way of coordinating the taking and restoring of VM memory and >>> disk snapshots. This would involve some investigation into the best >>> way to accomplish this. >>> >>> * VM Cloning >>> owner: ? >>> status: none >>> Again, a way of coordinating the memory and disk aspects. Research >>> into the best way to do this would probably go along with the >>> snapshotting feature. >>> >>> * xl vm-{export,import} >>> owner: ? >>> status: none >>> Allow xl to import and export VMs to other formats; particularly >>> ovf, perhaps the XenServer format, or more. >>> >>> * Memory: Replace PoD with paging mechanism >>> owner: george@citrix >>> status: none >>> >>> * PV audio (audio for stubdom qemu) >>> owner: stefano.panella@citrix >>> status: ? >>> >>> * Wait queues for mm >>> > Needed for more advanced paging schemes >>> owner: ? >>> status: Draft posted Feb 2012; more work to do. >>> >>> * V4V: Inter-domain communication >>> owner (Xen): dominic.curran@citrix.com >>> status (Xen): patches submitted >>> owner (Linux driver): stefano.panella@citrix >>> status (Linux driver): in progress >>> >>> === clean-ups === >>> >>> * Sort out better memory / ballooning / dom0 autoballooning thing >>> > Don't forget NUMA angle >>> - Inaccurate / incomplete info from HV >>> >>> * Implement Xen hypervisor dmesg log entry timestamps >>> >>> * Make network driver domains easier to set up / more useful >>> - Default backend (submitted) >>> - Remove unnecessary restriction wrt dom0 hotplug scripts (submitted) >>> - Make it easy to make a device assignable (in discussion) >>> - Automatically start/shutdown (xendomains?) >>> - Pause booting of other domains until network driver domain is up >>> >>> * libxl: More fine-grained control over when to pass through a device >>> > Some IOMMUs are secure; some are merely functional, some are not >>> present. >>> > Allow the adminitrator to set the default >>> >>> * xl does not handle migrate interruption gracefully >>> > If you start a localhost migrate, and press "Ctrl-C" in the >>> middle, >>> > you get two hung domains >>> status: Probably not for 4.3 >>> >>> * libxl / xl does not handle failure of remote qemu gracefully >>> > Easiest way to reproduce: >>> > - set "vncunused=0" and do a local migrate >>> > - The "remote" qemu will fail because the vnc port is in use >>> > The failure isn't the problem, but everything being stuck >>> afterwards is >>> status: Probably not for 4.3 >>> >>> * mac address changes on reboot if not specified in config file >>> > Needs a robust way to "add" to the config >>> status: Too much for 4.3 Are there news about that? >>> >>> * qxl >>> > >>> http://bugs.xenproject.org/xen/bug/11http://bugs.xenproject.org/xen/bug/11 >>> - Uninitialized struct element in qemu >>> - Revert 5479961 to re-enable qxl in xl,libxl >>> - Option in Xen top-level to enable qxl support in qemu tree >>> - Fix sse2 MMIO issue Anthony Perard patch about uninitialized qxl struct element in qemu is on upstream git: http://git.qemu.org/?p=qemu.git;a=commit;h=329f97fc4ff4b533fcd2d8f4eab6c9c2568aed27 I think is good improve spice support not only with qxl for now unfortunately blocked by the problem with SSE support. Vdagent and usb redirection are fully working with xen but not supported by xl now, I tested them manually for over a year and I found no problems caused by xen. I did xl patch for add vdagent support long time ago, here the last version: http://lists.xen.org/archives/html/xen-devel/2013-08/msg02635.html The security question open by Ian Jackson has been answered here: http://lists.xen.org/archives/html/xen-devel/2013-08/msg01438.html So I also made this patch to optionally disable the clipboard sharing: http://lists.xen.org/archives/html/xen-devel/2013-08/msg02651.html About usbredirection I'll post a new version of patch, for now there is a patch about xl usb2 and usb3 controller support ready: http://lists.xen.org/archives/html/xen-devel/2013-07/msg01101.html Now on xl there is only usb1 controller support but windows 7 domU (and probably also with other windows) doesn't see it correctly. Consequently it is not working the usb redirection on windows 7, because to have it working it needs the usb2 controller. On ubuntu domU works also with usb1 but based on windows tests I think is good to add usb2 controller support before add spice usb redirection support. Thanks for any reply. >>> >>> * libxl config file >>> >>> * libxl: Don't use RAW format for "URL"-based qdisks (e.g., >>> rbd:rbd/foo.img) >>> - Figure out whether to use a generic URL or have a specific type >>> for each one >>> - Check existence of disk file for all RAW >>> >>> * Polish up xenbugtool >>> owner: wei.liu2@citrix.com >>> >>> * acpi-related xenstore entries not propagated on migrate >>> > http://www.gossamer-threads.com/lists/xen/devel/282466 >>> > Only used by hvmloader; only a clean-up, not a bug. >>> status: Not for 4.3 >>> >>> * Remove hardcoded mobprobe's in xencommons >>> owner: Wei Liu >>> status: still in discussion >>> >>> * xl USB pass-through for HVM guests using Qemu USB emulation >>> owner: George >>> status: v6 patch series posted >>> >>> * Rationalized backend scripts >>> owner: roger@citrix >>> status: patches posted >>> >>> * Scripts for driver domains (depends on backend scripts) >>> owner: roger@citrix >>> status: >>> >>> * Multi-vector PCI MSI (support at least for Dom0) >>> owner: jan@suse >>> status: Patches posted for Intel; AMD not yet done >> And patches for Linux upstream are missing. > > > >> >>> * xl: passing more defaults in configuration in xl.conf >>> owner: ? >>> There are a number of options for which it might be useful to pass a >>> default in xl.conf. For example, if we could have a default >>> "backend" parameter for vifs, then it would be easy to switch back >>> and forth between a backend in a driver domain and a backend in >>> dom0. >>> >>> * xl PVUSB pass-through for PV guests >>> * xl PVUSB pass-through for HVM guests >>> owner: George >>> status: ? >>> xm/xend supports PVUSB pass-through to guests with PVUSB drivers >>> (both PV and HVM guests). >>> - port the xm/xend functionality to xl. >>> - this PVUSB feature does not require support or emulation from >>> Qemu. >>> - upstream the Linux frontend/backend drivers. Current >>> work-in-progress versions are in Konrad's git tree. >> Which is to say I hadn't actually touched them in a year. > > Yeah, I was under the impression they weren't really going anywhere. > If you think this is unclear, feel free to suggest alternate wording. > >> >>> - James Harper's GPLPV drivers for Windows include PVUSB frontend >>> drivers. >>> >>> * Guest EFI booting >>> - status: tianocore in-tree, some build problems. >>> Needs new owner. >>> >>> * Xen EFI feature: pvops dom0 able to make use of EFI run-time >>> services (external) >>> owner: Daniel Kiper >>> status: Just begun >>> >>> * Serial console improvements >>> owner: ? >>> status: Stalled (see below) >>> -xHCI debug port (Needs hardware) >>> -Firewire (needs hardware) >>> >> I would like also to put GPU passthrough working here. > > What aspect do you mean? > > -George > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 19:30 ` Konrad Rzeszutek Wilk 2013-08-13 16:19 ` George Dunlap @ 2013-08-13 16:22 ` George Dunlap 2013-08-13 16:27 ` Jan Beulich 1 sibling, 1 reply; 116+ messages in thread From: George Dunlap @ 2013-08-13 16:22 UTC (permalink / raw) To: Konrad Rzeszutek Wilk; +Cc: Jan Beulich, xen-devel On 08/08/13 20:30, Konrad Rzeszutek Wilk wrote: > On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: >> * Multi-vector PCI MSI (support at least for Dom0) >> owner: jan@suse >> status: Patches posted for Intel; AMD not yet done > And patches for Linux upstream are missing. Jan, care to comment on this? -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-13 16:22 ` George Dunlap @ 2013-08-13 16:27 ` Jan Beulich 0 siblings, 0 replies; 116+ messages in thread From: Jan Beulich @ 2013-08-13 16:27 UTC (permalink / raw) To: George Dunlap, Konrad Rzeszutek Wilk; +Cc: xen-devel >>> On 13.08.13 at 18:22, George Dunlap <george.dunlap@eu.citrix.com> wrote: > On 08/08/13 20:30, Konrad Rzeszutek Wilk wrote: >> On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: >>> * Multi-vector PCI MSI (support at least for Dom0) >>> owner: jan@suse >>> status: Patches posted for Intel; AMD not yet done >> And patches for Linux upstream are missing. > > Jan, care to comment on this? As indicated to Konrad earlier - upstream code is too different from ours for me to propose a patch here. I handed Konrad the patch that I have on our kernel for future reference, and am relying on him (or someone else) to actually do that work. Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:09 George Dunlap ` (2 preceding siblings ...) 2013-08-08 19:30 ` Konrad Rzeszutek Wilk @ 2013-08-09 7:57 ` Jan Beulich 2013-08-09 8:02 ` Jan Beulich ` (14 subsequent siblings) 18 siblings, 0 replies; 116+ messages in thread From: Jan Beulich @ 2013-08-09 7:57 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel >>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > == Open == > > * __update_vcpu_system_time if system_time comes out negative Done since Jul 2 (5ad914bc867c5a6a4957869c89918f4e1f9dd9c4). Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:09 George Dunlap ` (3 preceding siblings ...) 2013-08-09 7:57 ` Jan Beulich @ 2013-08-09 8:02 ` Jan Beulich 2013-08-09 11:03 ` Dario Faggioli 2013-08-14 10:27 ` George Dunlap 2013-08-09 8:06 ` Jan Beulich ` (13 subsequent siblings) 18 siblings, 2 replies; 116+ messages in thread From: Jan Beulich @ 2013-08-09 8:02 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel >>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > === Big ticket items === > > * Event channel scalability > owner: david@citrix > status: RFC v5 submitted That was Wei's variant I believe; I don't think David's has reached v5 yet. > * Default to credit2 Was that really the plan? * Multi-vector MSI (deferred from 4.3, now done) Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-09 8:02 ` Jan Beulich @ 2013-08-09 11:03 ` Dario Faggioli 2013-08-14 10:27 ` George Dunlap 1 sibling, 0 replies; 116+ messages in thread From: Dario Faggioli @ 2013-08-09 11:03 UTC (permalink / raw) To: Jan Beulich; +Cc: George Dunlap, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 482 bytes --] On ven, 2013-08-09 at 09:02 +0100, Jan Beulich wrote: > > * Default to credit2 > > Was that really the plan? > We want to do that at some point, yes, although, most likely, not for 4.4, right George? Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-09 8:02 ` Jan Beulich 2013-08-09 11:03 ` Dario Faggioli @ 2013-08-14 10:27 ` George Dunlap 1 sibling, 0 replies; 116+ messages in thread From: George Dunlap @ 2013-08-14 10:27 UTC (permalink / raw) To: Jan Beulich; +Cc: xen-devel On 09/08/13 09:02, Jan Beulich wrote: >>>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote: >> === Big ticket items === >> >> * Event channel scalability >> owner: david@citrix >> status: RFC v5 submitted > That was Wei's variant I believe; I don't think David's has reached > v5 yet. > >> * Default to credit2 > Was that really the plan? It's something I would really like to see in -- but as indicated, there are a couple of critical missing features, and I don't think I'll be able to make it for 4.4. -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:09 George Dunlap ` (4 preceding siblings ...) 2013-08-09 8:02 ` Jan Beulich @ 2013-08-09 8:06 ` Jan Beulich 2013-08-14 10:35 ` George Dunlap 2013-08-09 14:10 ` Dario Faggioli ` (12 subsequent siblings) 18 siblings, 1 reply; 116+ messages in thread From: Jan Beulich @ 2013-08-09 8:06 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel >>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > === clean-ups === > > * Implement Xen hypervisor dmesg log entry timestamps Isn't that what the "console_timestamps" command line option already does? Or if not, what is this about? > * Multi-vector PCI MSI (support at least for Dom0) > owner: jan@suse > status: Patches posted for Intel; AMD not yet done Oh, this was listed under cleanups. Anyway - it's done (also for AMD). Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-09 8:06 ` Jan Beulich @ 2013-08-14 10:35 ` George Dunlap 0 siblings, 0 replies; 116+ messages in thread From: George Dunlap @ 2013-08-14 10:35 UTC (permalink / raw) To: Jan Beulich; +Cc: xen-devel On 09/08/13 09:06, Jan Beulich wrote: >>>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote: >> === clean-ups === >> >> * Implement Xen hypervisor dmesg log entry timestamps > Isn't that what the "console_timestamps" command line option > already does? Or if not, what is this about? It comes from this uservoice suggestion by Pasi: https://xenorg.uservoice.com/forums/172169-xen-development/suggestions/3924048-implement-xen-hypervisor-dmesg-log-entry-timestamp Andy C. commented, saying that "console_timestamps" was a bit heavyweight, and that this (which only has seconds since boot) was more useful. I'll update this to reflect that. >> * Multi-vector PCI MSI (support at least for Dom0) >> owner: jan@suse >> status: Patches posted for Intel; AMD not yet done > Oh, this was listed under cleanups. Anyway - it's done (also for > AMD). Yes, sorry -- the list is getting awfully long, and I was under some pressure to get the list out, particularly as it had been over a month since the 4.3 release. I've re-organized stuff now and will post it to the wiki in the better-organized format. -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:09 George Dunlap ` (5 preceding siblings ...) 2013-08-09 8:06 ` Jan Beulich @ 2013-08-09 14:10 ` Dario Faggioli 2013-08-09 23:08 ` Matt Wilson 2013-08-14 11:10 ` George Dunlap 2013-08-09 20:01 ` Daniel Kiper ` (11 subsequent siblings) 18 siblings, 2 replies; 116+ messages in thread From: Dario Faggioli @ 2013-08-09 14:10 UTC (permalink / raw) To: George Dunlap; +Cc: Li Yechen, Matt Wilson, Elena Ufimtseva, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 2999 bytes --] On gio, 2013-08-08 at 17:09 +0100, George Dunlap wrote: > = Timeline = > > As discussed elsewhere, I am proposing a 6-month release cycle. Xen > 4.3 was released on 9 July. That would give us a release on 9 January > 2014. This is fairly close after the Christmas season, so I propose > to make the estimated release date later, on 21 January, giving a few > extra weeks for the holiday season: > > * Feature freeze: 18 October 2013 > * Code freezing point: 8 November 2013 > * First RC: 26 November 2013 > * Release: 21 January 2014 > 18 October... Tight. At least code freeze is a bit later! :-P > Last updated: 8 August 2013 > > == Backlog == > > === Testing coverage === > > [..] > * Performance benchmarking on top of osstest @dario > === Big ticket items === > > * NUMA Memory migration > owner: dario@citrix > status: in progress > Confirmed to be in progress. > * Meta: PVIO NUMA improvements > - NUMA affinity for vcpus > owner: Dario > status: in progress > - PV guest NUMA interface > owner: Elena > status: in progress Right Elena? > - Sensible dom0 NUMA layout > status: not started > - Toolstack pinning backend thread / virq to appropraite d0 vcpu > status: not started Also, we might want to add: - HVM guest NUMA owner: Matt Wilson status: ? Is that ok, Matt? If you're concerned about the libxl part of that, I have a series half backed that I'll be posting here soon (as RFC or something), so feel free to leave that to me. :-) And this one too: - NUMA-aware ballooning owner: Li Yechen status: ? Is that ok, Yechen? > * libvirt/libxl integration (external) > > need a status update > - owner: jfehlig@suse, dario@citrix > Yep, putting together a status update right in these days (I plan a XenSummit talk about it) > === clean-ups === > > * Sort out better memory / ballooning / dom0 autoballooning thing > > Don't forget NUMA angle > Mmm... This is an old discussion which, if I remember correctly (at least what the "NUMA angle" was), is about a TOCTOU issue involving automatic NUMA placement and ballooning, domain creation, and perhaps even more memory related operations (depends on the toolstack)... It's not "just" a ballooning or autoballooning problem, and it's completely different from the "NUMA-aware ballooning" I was talking about before. I don't have much in mind to properly deal with it. One think I can double check is whether the claim mechanism Oracle introduced can be of any help, but nothing much than that for now. In any case, at least from my side, this is as follows. status: not started. Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-09 14:10 ` Dario Faggioli @ 2013-08-09 23:08 ` Matt Wilson 2013-08-09 23:42 ` Dario Faggioli 2013-08-14 11:11 ` George Dunlap 2013-08-14 11:10 ` George Dunlap 1 sibling, 2 replies; 116+ messages in thread From: Matt Wilson @ 2013-08-09 23:08 UTC (permalink / raw) To: Dario Faggioli; +Cc: George Dunlap, Li Yechen, Elena Ufimtseva, xen-devel On Fri, Aug 09, 2013 at 04:10:10PM +0200, Dario Faggioli wrote: > On gio, 2013-08-08 at 17:09 +0100, George Dunlap wrote: > > = Timeline = > > > > As discussed elsewhere, I am proposing a 6-month release cycle. Xen > > 4.3 was released on 9 July. That would give us a release on 9 January > > 2014. This is fairly close after the Christmas season, so I propose > > to make the estimated release date later, on 21 January, giving a few > > extra weeks for the holiday season: > > > > * Feature freeze: 18 October 2013 > > * Code freezing point: 8 November 2013 > > * First RC: 26 November 2013 > > * Release: 21 January 2014 > > [...] > > === Big ticket items === [...] > Also, we might want to add: > > - HVM guest NUMA > owner: Matt Wilson > status: ? > > Is that ok, Matt? Yes. > If you're concerned about the libxl part of that, I have a series half > backed that I'll be posting here soon (as RFC or something), so feel > free to leave that to me. :-) OK! I'll try to find some time to rebase the patch and post as an RFC. --msw ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-09 23:08 ` Matt Wilson @ 2013-08-09 23:42 ` Dario Faggioli 2013-08-14 11:11 ` George Dunlap 1 sibling, 0 replies; 116+ messages in thread From: Dario Faggioli @ 2013-08-09 23:42 UTC (permalink / raw) To: Matt Wilson; +Cc: George Dunlap, Li Yechen, Elena Ufimtseva, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 808 bytes --] On ven, 2013-08-09 at 16:08 -0700, Matt Wilson wrote: > > Also, we might want to add: > > > > - HVM guest NUMA > > owner: Matt Wilson > > status: ? > > > > Is that ok, Matt? > > Yes. > > > If you're concerned about the libxl part of that, I have a series half > > backed that I'll be posting here soon (as RFC or something), so feel > > free to leave that to me. :-) > > OK! I'll try to find some time to rebase the patch and post as an RFC. > Great! Whenever you're ready. :-) Thanks and Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-09 23:08 ` Matt Wilson 2013-08-09 23:42 ` Dario Faggioli @ 2013-08-14 11:11 ` George Dunlap 1 sibling, 0 replies; 116+ messages in thread From: George Dunlap @ 2013-08-14 11:11 UTC (permalink / raw) To: Matt Wilson; +Cc: Dario Faggioli, Li Yechen, Elena Ufimtseva, xen-devel On 10/08/13 00:08, Matt Wilson wrote: > On Fri, Aug 09, 2013 at 04:10:10PM +0200, Dario Faggioli wrote: >> On gio, 2013-08-08 at 17:09 +0100, George Dunlap wrote: >>> = Timeline = >>> >>> As discussed elsewhere, I am proposing a 6-month release cycle. Xen >>> 4.3 was released on 9 July. That would give us a release on 9 January >>> 2014. This is fairly close after the Christmas season, so I propose >>> to make the estimated release date later, on 21 January, giving a few >>> extra weeks for the holiday season: >>> >>> * Feature freeze: 18 October 2013 >>> * Code freezing point: 8 November 2013 >>> * First RC: 26 November 2013 >>> * Release: 21 January 2014 >>> > [...] > >>> === Big ticket items === > [...] > >> Also, we might want to add: >> >> - HVM guest NUMA >> owner: Matt Wilson >> status: ? >> >> Is that ok, Matt? > Yes. > >> If you're concerned about the libxl part of that, I have a series half >> backed that I'll be posting here soon (as RFC or something), so feel >> free to leave that to me. :-) > OK! I'll try to find some time to rebase the patch and post as an RFC. Great! -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-09 14:10 ` Dario Faggioli 2013-08-09 23:08 ` Matt Wilson @ 2013-08-14 11:10 ` George Dunlap 1 sibling, 0 replies; 116+ messages in thread From: George Dunlap @ 2013-08-14 11:10 UTC (permalink / raw) To: Dario Faggioli; +Cc: Li Yechen, Matt Wilson, Elena Ufimtseva, xen-devel On 09/08/13 15:10, Dario Faggioli wrote: > On gio, 2013-08-08 at 17:09 +0100, George Dunlap wrote: >> = Timeline = >> >> As discussed elsewhere, I am proposing a 6-month release cycle. Xen >> 4.3 was released on 9 July. That would give us a release on 9 January >> 2014. This is fairly close after the Christmas season, so I propose >> to make the estimated release date later, on 21 January, giving a few >> extra weeks for the holiday season: >> >> * Feature freeze: 18 October 2013 >> * Code freezing point: 8 November 2013 >> * First RC: 26 November 2013 >> * Release: 21 January 2014 >> > 18 October... Tight. At least code freeze is a bit later! :-P > >> Last updated: 8 August 2013 >> >> == Backlog == >> >> === Testing coverage === >> >> [..] >> > * Performance benchmarking on top of osstest > @dario > >> === Big ticket items === >> >> * NUMA Memory migration >> owner: dario@citrix >> status: in progress >> > Confirmed to be in progress. > >> * Meta: PVIO NUMA improvements >> - NUMA affinity for vcpus >> owner: Dario >> > status: in progress > >> - PV guest NUMA interface >> owner: Elena >> > status: in progress > > Right Elena? > >> - Sensible dom0 NUMA layout >> > status: not started > >> - Toolstack pinning backend thread / virq to appropraite d0 vcpu >> > status: not started > > Also, we might want to add: > > - HVM guest NUMA > owner: Matt Wilson > status: ? > > Is that ok, Matt? > > If you're concerned about the libxl part of that, I have a series half > backed that I'll be posting here soon (as RFC or something), so feel > free to leave that to me. :-) > > And this one too: > > - NUMA-aware ballooning > owner: Li Yechen > status: ? > > Is that ok, Yechen? > >> * libvirt/libxl integration (external) >> > need a status update >> - owner: jfehlig@suse, dario@citrix >> > Yep, putting together a status update right in these days (I plan a > XenSummit talk about it) > >> === clean-ups === >> >> * Sort out better memory / ballooning / dom0 autoballooning thing >> > Don't forget NUMA angle >> > Mmm... This is an old discussion which, if I remember correctly (at > least what the "NUMA angle" was), is about a TOCTOU issue involving > automatic NUMA placement and ballooning, domain creation, and perhaps > even more memory related operations (depends on the toolstack)... It's > not "just" a ballooning or autoballooning problem, and it's completely > different from the "NUMA-aware ballooning" I was talking about before. > > I don't have much in mind to properly deal with it. One think I can > double check is whether the claim mechanism Oracle introduced can be of > any help, but nothing much than that for now. > > In any case, at least from my side, this is as follows. > > status: not started. OK -- I think there are a couple of us with it on our minds, so I'll leave it un-claimed. When someone starts to work on it, let everyone else know, so there's no duplicated effort. -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:09 George Dunlap ` (6 preceding siblings ...) 2013-08-09 14:10 ` Dario Faggioli @ 2013-08-09 20:01 ` Daniel Kiper 2013-08-12 8:06 ` Jan Beulich ` (2 more replies) 2013-08-09 20:15 ` Boris Ostrovsky ` (10 subsequent siblings) 18 siblings, 3 replies; 116+ messages in thread From: Daniel Kiper @ 2013-08-09 20:01 UTC (permalink / raw) To: George Dunlap Cc: jbeulich, stefano.stabellini, xen-devel, david.vrabel, ross.philipson, richard.l.maliszewski On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: [...] > * Xen EFI feature: Xen can boot from grub.efi > owner: Daniel Kiper > status: Just begun > prognosis: Fair I think that you could change that to Good. I am working on it. Migration to xbi struct is almost finished and multiboot2 protocol works on machines with legacy BIOS. Now I am working on multiboot2 protocol for machines with EFI. Yesterday, I discovered some issues related to memory map passed via this protocol. Sadly it looks that taking into account current GRUB2 implementation only workaround is available. Final proper solution would require some changes in GRUB2. I will do that later. [...] > * Guest EFI booting > - status: tianocore in-tree, some build problems. > Needs new owner. I could take over ownership of this but it would have lowest priority on my task list now (major stuff only: 1 - multiboot2 protocl, 2 - EFI support for Xen in Linux Kernel, 3 - guest EFI booting). > * Xen EFI feature: pvops dom0 able to make use of EFI run-time > services (external) > owner: Daniel Kiper > status: Just begun I am going to start work on it when I finish work on multiboot2 protocol. Additionally, I think that: - new kexec implementation should be added to this list; David Vrabel work on this; I think that patches are quite mature and need only some polishing, - unmodified_drivers should be removed because as I know they are not maintained for very long time; if you agree I could do that, - as I saw there is a quite big mess in directory structure used by installed Xen related stuff (especially in /var and /usr); I have done some patches for myself but they require some improvements to do public release; if you wish I could work on this too. Have a nice weekend, Daniel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-09 20:01 ` Daniel Kiper @ 2013-08-12 8:06 ` Jan Beulich 2013-08-12 18:55 ` Daniel Kiper 2013-08-12 9:44 ` David Vrabel 2013-08-14 13:22 ` George Dunlap 2 siblings, 1 reply; 116+ messages in thread From: Jan Beulich @ 2013-08-12 8:06 UTC (permalink / raw) To: George Dunlap, Daniel Kiper Cc: xen-devel, richard.l.maliszewski, david.vrabel, ross.philipson, stefano.stabellini >>> On 09.08.13 at 22:01, Daniel Kiper <dkiper@net-space.pl> wrote: > - unmodified_drivers should be removed because as I know > they are not maintained for very long time; if you > agree I could do that, The most recent update to them was on 2013-02-12, so not all _that_ long ago. We're still using them, so I'd hope that they could stay in the tree, saving us from having to patch them back in. Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-12 8:06 ` Jan Beulich @ 2013-08-12 18:55 ` Daniel Kiper 2013-08-13 10:13 ` Jan Beulich 0 siblings, 1 reply; 116+ messages in thread From: Daniel Kiper @ 2013-08-12 18:55 UTC (permalink / raw) To: Jan Beulich Cc: stefano.stabellini, George Dunlap, xen-devel, david.vrabel, ross.philipson, richard.l.maliszewski, Daniel Kiper On Mon, Aug 12, 2013 at 09:06:08AM +0100, Jan Beulich wrote: > >>> On 09.08.13 at 22:01, Daniel Kiper <dkiper@net-space.pl> wrote: > > - unmodified_drivers should be removed because as I know > > they are not maintained for very long time; if you > > agree I could do that, > > The most recent update to them was on 2013-02-12, so not all > _that_ long ago. We're still using them, so I'd hope that they > could stay in the tree, saving us from having to patch them back > in. As I understood from [1] unmodified_drivers is not maintained. However, if you found out that it was updated quite recently then I do not insist on removing it. 1) http://lists.xen.org/archives/html/xen-devel/2013-06/msg00730.html Daniel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-12 18:55 ` Daniel Kiper @ 2013-08-13 10:13 ` Jan Beulich 2013-08-13 12:43 ` Daniel Kiper 0 siblings, 1 reply; 116+ messages in thread From: Jan Beulich @ 2013-08-13 10:13 UTC (permalink / raw) To: Daniel Kiper Cc: stefano.stabellini, George Dunlap, xen-devel, david.vrabel, ross.philipson, richard.l.maliszewski >>> On 12.08.13 at 20:55, Daniel Kiper <dkiper@net-space.pl> wrote: > On Mon, Aug 12, 2013 at 09:06:08AM +0100, Jan Beulich wrote: >> >>> On 09.08.13 at 22:01, Daniel Kiper <dkiper@net-space.pl> wrote: >> > - unmodified_drivers should be removed because as I know >> > they are not maintained for very long time; if you >> > agree I could do that, >> >> The most recent update to them was on 2013-02-12, so not all >> _that_ long ago. We're still using them, so I'd hope that they >> could stay in the tree, saving us from having to patch them back >> in. > > As I understood from [1] unmodified_drivers is not maintained. > However, if you found out that it was updated quite recently then > I do not insist on removing it. > > 1) http://lists.xen.org/archives/html/xen-devel/2013-06/msg00730.html What I said there has nothing to do with the maintenance status of the unmodified_drivers/ subtree; instead, it is related to the need to also have a suitable forward ported Linux tree to build them against. Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-13 10:13 ` Jan Beulich @ 2013-08-13 12:43 ` Daniel Kiper 0 siblings, 0 replies; 116+ messages in thread From: Daniel Kiper @ 2013-08-13 12:43 UTC (permalink / raw) To: Jan Beulich Cc: stefano.stabellini, George Dunlap, xen-devel, david.vrabel, ross.philipson, richard.l.maliszewski, Daniel Kiper On Tue, Aug 13, 2013 at 11:13:42AM +0100, Jan Beulich wrote: > >>> On 12.08.13 at 20:55, Daniel Kiper <dkiper@net-space.pl> wrote: > > On Mon, Aug 12, 2013 at 09:06:08AM +0100, Jan Beulich wrote: > >> >>> On 09.08.13 at 22:01, Daniel Kiper <dkiper@net-space.pl> wrote: > >> > - unmodified_drivers should be removed because as I know > >> > they are not maintained for very long time; if you > >> > agree I could do that, > >> > >> The most recent update to them was on 2013-02-12, so not all > >> _that_ long ago. We're still using them, so I'd hope that they > >> could stay in the tree, saving us from having to patch them back > >> in. > > > > As I understood from [1] unmodified_drivers is not maintained. > > However, if you found out that it was updated quite recently then > > I do not insist on removing it. > > > > 1) http://lists.xen.org/archives/html/xen-devel/2013-06/msg00730.html > > What I said there has nothing to do with the maintenance status > of the unmodified_drivers/ subtree; instead, it is related to the > need to also have a suitable forward ported Linux tree to build > them against. It looks that I understood your email in wrong way. Thanks for clarification. Daniel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-09 20:01 ` Daniel Kiper 2013-08-12 8:06 ` Jan Beulich @ 2013-08-12 9:44 ` David Vrabel 2013-08-12 18:56 ` Daniel Kiper 2013-08-14 13:22 ` George Dunlap 2 siblings, 1 reply; 116+ messages in thread From: David Vrabel @ 2013-08-12 9:44 UTC (permalink / raw) To: Daniel Kiper Cc: jbeulich, George Dunlap, stefano.stabellini, xen-devel, ross.philipson, richard.l.maliszewski On 09/08/13 21:01, Daniel Kiper wrote: > > Additionally, I think that: > - new kexec implementation should be added to this list; > David Vrabel work on this; I think that patches are > quite mature and need only some polishing, The way it writes the page tables used to exec the image needs changing -- this is non trivial. David ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-12 9:44 ` David Vrabel @ 2013-08-12 18:56 ` Daniel Kiper 0 siblings, 0 replies; 116+ messages in thread From: Daniel Kiper @ 2013-08-12 18:56 UTC (permalink / raw) To: David Vrabel Cc: ross.philipson, George Dunlap, stefano.stabellini, xen-devel, jbeulich, richard.l.maliszewski, Daniel Kiper On Mon, Aug 12, 2013 at 10:44:35AM +0100, David Vrabel wrote: > On 09/08/13 21:01, Daniel Kiper wrote: > > > > Additionally, I think that: > > - new kexec implementation should be added to this list; > > David Vrabel work on this; I think that patches are > > quite mature and need only some polishing, > > The way it writes the page tables used to exec the image needs changing > -- this is non trivial. Ugh... Could you tell more? Daniel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-09 20:01 ` Daniel Kiper 2013-08-12 8:06 ` Jan Beulich 2013-08-12 9:44 ` David Vrabel @ 2013-08-14 13:22 ` George Dunlap 2013-08-27 9:51 ` Daniel Kiper 2 siblings, 1 reply; 116+ messages in thread From: George Dunlap @ 2013-08-14 13:22 UTC (permalink / raw) To: Daniel Kiper Cc: jbeulich, stefano.stabellini, xen-devel, david.vrabel, ross.philipson, richard.l.maliszewski On 09/08/13 21:01, Daniel Kiper wrote: > On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: > > [...] > >> * Xen EFI feature: Xen can boot from grub.efi >> owner: Daniel Kiper >> status: Just begun >> prognosis: Fair > I think that you could change that to Good. I am working > on it. Migration to xbi struct is almost finished and > multiboot2 protocol works on machines with legacy BIOS. > Now I am working on multiboot2 protocol for machines > with EFI. Yesterday, I discovered some issues related > to memory map passed via this protocol. Sadly it looks > that taking into account current GRUB2 implementation > only workaround is available. Final proper solution would > require some changes in GRUB2. I will do that later. > > [...] > >> * Guest EFI booting >> - status: tianocore in-tree, some build problems. >> Needs new owner. > I could take over ownership of this but it would have > lowest priority on my task list now (major stuff only: > 1 - multiboot2 protocl, 2 - EFI support for Xen in Linux > Kernel, 3 - guest EFI booting). OK -- I think for now then I'll leave it unclaimed, so that if any other enterprising developers show up they can take a look at it. > >> * Xen EFI feature: pvops dom0 able to make use of EFI run-time >> services (external) >> owner: Daniel Kiper >> status: Just begun > I am going to start work on it when I finish work on multiboot2 protocol. > > Additionally, I think that: > - new kexec implementation should be added to this list; > David Vrabel work on this; I think that patches are > quite mature and need only some polishing, > - unmodified_drivers should be removed because as I know > they are not maintained for very long time; if you > agree I could do that, > - as I saw there is a quite big mess in directory structure > used by installed Xen related stuff (especially in /var > and /usr); I have done some patches for myself but they > require some improvements to do public release; if you wish > I could work on this too. It's up to you really -- if you are set on working on it, I'll put it on the list; but there is plenty to do othewise. :-) What kinds of changes did you have in mind in particular? -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-14 13:22 ` George Dunlap @ 2013-08-27 9:51 ` Daniel Kiper 0 siblings, 0 replies; 116+ messages in thread From: Daniel Kiper @ 2013-08-27 9:51 UTC (permalink / raw) To: George Dunlap Cc: ross.philipson, stefano.stabellini, xen-devel, david.vrabel, jbeulich, richard.l.maliszewski, Daniel Kiper On Wed, Aug 14, 2013 at 02:22:24PM +0100, George Dunlap wrote: > On 09/08/13 21:01, Daniel Kiper wrote: > >On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: > > > >[...] > > > >>* Xen EFI feature: Xen can boot from grub.efi > >> owner: Daniel Kiper > >> status: Just begun > >> prognosis: Fair > >I think that you could change that to Good. I am working > >on it. Migration to xbi struct is almost finished and > >multiboot2 protocol works on machines with legacy BIOS. > >Now I am working on multiboot2 protocol for machines > >with EFI. Yesterday, I discovered some issues related > >to memory map passed via this protocol. Sadly it looks > >that taking into account current GRUB2 implementation > >only workaround is available. Final proper solution would > >require some changes in GRUB2. I will do that later. > > > >[...] > > > >>* Guest EFI booting > >> - status: tianocore in-tree, some build problems. > >> Needs new owner. > >I could take over ownership of this but it would have > >lowest priority on my task list now (major stuff only: > >1 - multiboot2 protocl, 2 - EFI support for Xen in Linux > >Kernel, 3 - guest EFI booting). > > OK -- I think for now then I'll leave it unclaimed, so that if any other > enterprising developers show up they can take a look at it. OK. > >>* Xen EFI feature: pvops dom0 able to make use of EFI run-time > >>services (external) > >> owner: Daniel Kiper > >> status: Just begun > >I am going to start work on it when I finish work on multiboot2 protocol. > > > >Additionally, I think that: > > - new kexec implementation should be added to this list; > > David Vrabel work on this; I think that patches are > > quite mature and need only some polishing, > > - unmodified_drivers should be removed because as I know > > they are not maintained for very long time; if you > > agree I could do that, > > - as I saw there is a quite big mess in directory structure > > used by installed Xen related stuff (especially in /var > > and /usr); I have done some patches for myself but they > > require some improvements to do public release; if you wish > > I could work on this too. > > It's up to you really -- if you are set on working on it, I'll put it on > the list; but there is plenty to do othewise. :-) What kinds of changes > did you have in mind in particular? e.g. a lot of stuff is spread over /var and /var/lib. I do not mention that /var should not contain any non standard directory, i.e. xen. Additionally, there are a few directories in /var/lib used by various stuff. I think that all of them should be moved to /var/lib/xen. The same is in /var/run and /usr/share case. There are also other minor issues which are worth to fix. Daniel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:09 George Dunlap ` (7 preceding siblings ...) 2013-08-09 20:01 ` Daniel Kiper @ 2013-08-09 20:15 ` Boris Ostrovsky 2013-08-12 9:49 ` David Vrabel ` (9 subsequent siblings) 18 siblings, 0 replies; 116+ messages in thread From: Boris Ostrovsky @ 2013-08-09 20:15 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel On 08/08/2013 12:09 PM, George Dunlap wrote: > * xenperf > Owner: Boris Otovsky The first cut is almost done, I only need to get 32-bit PV working. I expect to post v1 patches after I get back from vacation (early September) -boris ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:09 George Dunlap ` (8 preceding siblings ...) 2013-08-09 20:15 ` Boris Ostrovsky @ 2013-08-12 9:49 ` David Vrabel 2013-08-13 0:38 ` Mukesh Rathor ` (8 subsequent siblings) 18 siblings, 0 replies; 116+ messages in thread From: David Vrabel @ 2013-08-12 9:49 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel On 08/08/13 17:09, George Dunlap wrote: > This information will be mirrored on the Xen 4.4 Roadmap wiki page: > http://wiki.xen.org/wiki/Xen_Roadmap/4.4 There's nothing on this page. > * Event channel scalability > owner: david@citrix > status: RFC v5 submitted > Increase limit on event channels (currently 1024 for 32-bit guests, > 4096 for 64-bit guests) RFC v2 of the FIFO ABI has been posted. David ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:09 George Dunlap ` (9 preceding siblings ...) 2013-08-12 9:49 ` David Vrabel @ 2013-08-13 0:38 ` Mukesh Rathor 2013-08-13 13:17 ` Ben Guthro ` (7 subsequent siblings) 18 siblings, 0 replies; 116+ messages in thread From: Mukesh Rathor @ 2013-08-13 0:38 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel On Thu, 8 Aug 2013 17:09:35 +0100 George Dunlap <George.Dunlap@eu.citrix.com> wrote: > This information will be mirrored on the Xen 4.4 Roadmap wiki page: > http://wiki.xen.org/wiki/Xen_Roadmap/4.4 > > Rather than try to predict precisely what will make it into what > release (which was something of a disaster last release), I'm just > going to borrow a term from the Agile world and call all uncompleted > features the "Backlog". I'll still track who is doing what, and when > we get close, what state things seem to be in. > > As mentioned in another e-mail, we'll also be working on improving the > regression tester. Feel free to join us. > > And as always, if you are working on a feature / bug that you want > tracked, please respond to this e-mail. > > = Timeline = > > As discussed elsewhere, I am proposing a 6-month release cycle. Xen > 4.3 was released on 9 July. That would give us a release on 9 January > 2014. This is fairly close after the Christmas season, so I propose > to make the estimated release date later, on 21 January, giving a few > extra weeks for the holiday season: > > * Feature freeze: 18 October 2013 > * Code freezing point: 8 November 2013 > * First RC: 26 November 2013 > * Release: 21 January 2014 > > Feedback on the estimated dates is welcome. ..... > === Big ticket items === ...... > * PVH mode (w/ Linux) > owner: mukesh@oracle > status (Linux): 3rd draft patches posted. > status (Xen): v10 posted With holidays, vacation, other things on my plate i need to work on soon, the hurdles faced by V10, and still remaing tools and dom0 patch, this seems a difficult proposition for 4.4. thanks Mukesh ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:09 George Dunlap ` (10 preceding siblings ...) 2013-08-13 0:38 ` Mukesh Rathor @ 2013-08-13 13:17 ` Ben Guthro 2013-08-13 15:43 ` Dario Faggioli 2013-08-14 13:42 ` George Dunlap ` (6 subsequent siblings) 18 siblings, 1 reply; 116+ messages in thread From: Ben Guthro @ 2013-08-13 13:17 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel [-- Attachment #1.1: Type: text/plain, Size: 557 bytes --] On Thu, Aug 8, 2013 at 12:09 PM, George Dunlap <George.Dunlap@eu.citrix.com>wrote: *snip* === Testing coverage === > *snip* > * Host S3 suspend > @bguthro > > I'm unclear on what "Testing coverage" means, in this context. Are you asking for development of a new automated test, or to manually test the release? If you mean the former, I tried to get the infrastructure up and running to run osstest before, and failed. I think I will need some help with this, from someone more familiar with the testing system, if this is what you mean. Thanks Ben [-- Attachment #1.2: Type: text/html, Size: 1125 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-13 13:17 ` Ben Guthro @ 2013-08-13 15:43 ` Dario Faggioli 2013-08-13 16:18 ` Ben Guthro 0 siblings, 1 reply; 116+ messages in thread From: Dario Faggioli @ 2013-08-13 15:43 UTC (permalink / raw) To: Ben Guthro; +Cc: George Dunlap, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 1495 bytes --] On mar, 2013-08-13 at 09:17 -0400, Ben Guthro wrote: > *snip* > > * Host S3 suspend > @bguthro > > > > I'm unclear on what "Testing coverage" means, in this context. > Are you asking for development of a new automated test, or to manually > test the release? > The former. :-) > If you mean the former, I tried to get the infrastructure up and > running to run osstest before, and failed. > There are some stuff you have to take care of, yes. I recall succeeding in bringing it up a while back, but I don't have the details fresh in my mind. > I think I will need some help with this, from someone more familiar > with the testing system, if this is what you mean. > Well, I will have to bring up the osstest machinery again, and I'll start from scratch, so we can 'try together', meaning that I'll try (since I did it already) and let you know if I manage, so that you can try on your turn to ask questions about what's going wrong on your side. Just know that it will be September when I'll be doing that, since I'm about to leave for a couple of weeks. If that is not a big deal for you, we can talk more about it when I will be back. Let me know, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-13 15:43 ` Dario Faggioli @ 2013-08-13 16:18 ` Ben Guthro 2013-08-13 18:50 ` Dario Faggioli 0 siblings, 1 reply; 116+ messages in thread From: Ben Guthro @ 2013-08-13 16:18 UTC (permalink / raw) To: Dario Faggioli; +Cc: George Dunlap, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 1692 bytes --] On Tue, Aug 13, 2013 at 11:43 AM, Dario Faggioli <dario.faggioli@citrix.com>wrote: > On mar, 2013-08-13 at 09:17 -0400, Ben Guthro wrote: > > > *snip* > > > > * Host S3 suspend > > @bguthro > > > > > > > > I'm unclear on what "Testing coverage" means, in this context. > > Are you asking for development of a new automated test, or to manually > > test the release? > > > The former. :-) > > > If you mean the former, I tried to get the infrastructure up and > > running to run osstest before, and failed. > > > There are some stuff you have to take care of, yes. I recall succeeding > in bringing it up a while back, but I don't have the details fresh in my > mind. > > > I think I will need some help with this, from someone more familiar > > with the testing system, if this is what you mean. > > > Well, I will have to bring up the osstest machinery again, and I'll > start from scratch, so we can 'try together', meaning that I'll try > (since I did it already) and let you know if I manage, so that you can > try on your turn to ask questions about what's going wrong on your side. > > Just know that it will be September when I'll be doing that, since I'm > about to leave for a couple of weeks. If that is not a big deal for you, > we can talk more about it when I will be back. > > Let me know, > Sounds like a plan - I've got plenty to do between now, and then anyhow. Thanks Ben > Dario > > -- > <<This happens because I choose it to happen!>> (Raistlin Majere) > ----------------------------------------------------------------- > Dario Faggioli, Ph.D, http://about.me/dario.faggioli > Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) > > [-- Attachment #1.2: Type: text/html, Size: 2586 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-13 16:18 ` Ben Guthro @ 2013-08-13 18:50 ` Dario Faggioli 0 siblings, 0 replies; 116+ messages in thread From: Dario Faggioli @ 2013-08-13 18:50 UTC (permalink / raw) To: Ben Guthro; +Cc: George Dunlap, xen-devel [-- Attachment #1.1: Type: text/plain, Size: 773 bytes --] On mar, 2013-08-13 at 12:18 -0400, Ben Guthro wrote: > > Just know that it will be September when I'll be doing that, > since I'm > about to leave for a couple of weeks. If that is not a big > deal for you, > we can talk more about it when I will be back. > > Let me know, > > > Sounds like a plan - I've got plenty to do between now, and then > anyhow. > Cool. I will let you know when done with it then. Regards, Dario -- <<This happens because I choose it to happen!>> (Raistlin Majere) ----------------------------------------------------------------- Dario Faggioli, Ph.D, http://about.me/dario.faggioli Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK) [-- Attachment #1.2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 198 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:09 George Dunlap ` (11 preceding siblings ...) 2013-08-13 13:17 ` Ben Guthro @ 2013-08-14 13:42 ` George Dunlap 2013-08-14 16:35 ` Jan Beulich ` (5 subsequent siblings) 18 siblings, 0 replies; 116+ messages in thread From: George Dunlap @ 2013-08-14 13:42 UTC (permalink / raw) To: xen-devel On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > This information will be mirrored on the Xen 4.4 Roadmap wiki page: > http://wiki.xen.org/wiki/Xen_Roadmap/4.4 This page is now actually populated, with updates from people's responses. -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:09 George Dunlap ` (12 preceding siblings ...) 2013-08-14 13:42 ` George Dunlap @ 2013-08-14 16:35 ` Jan Beulich 2013-08-19 13:09 ` George Dunlap 2013-08-15 13:02 ` Wei Liu ` (4 subsequent siblings) 18 siblings, 1 reply; 116+ messages in thread From: Jan Beulich @ 2013-08-14 16:35 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel >>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > As discussed elsewhere, I am proposing a 6-month release cycle. Xen > 4.3 was released on 9 July. That would give us a release on 9 January > 2014. This is fairly close after the Christmas season, so I propose > to make the estimated release date later, on 21 January, giving a few > extra weeks for the holiday season: > > * Feature freeze: 18 October 2013 > * Code freezing point: 8 November 2013 > * First RC: 26 November 2013 > * Release: 21 January 2014 So I didn't see any comments on the proposed schedule so far. Hence I wonder how fixed we have to consider that plan at this point. I'm asking because from the very beginning I was not really in favor of shortening the release cycle, and looking at the number of (smaller) items on my todo list, I don't see any way to even get just a good part of them done by the proposed feature freeze date (taking into consideration that working on those items usually is possible only when no other bugs or routine work need dealing with). Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-14 16:35 ` Jan Beulich @ 2013-08-19 13:09 ` George Dunlap 2013-08-19 15:18 ` Ian Campbell 2013-08-20 7:28 ` Jan Beulich 0 siblings, 2 replies; 116+ messages in thread From: George Dunlap @ 2013-08-19 13:09 UTC (permalink / raw) To: Jan Beulich; +Cc: xen-devel On 14/08/13 17:35, Jan Beulich wrote: >>>> On 08.08.13 at 18:09, George Dunlap <George.Dunlap@eu.citrix.com> wrote: >> As discussed elsewhere, I am proposing a 6-month release cycle. Xen >> 4.3 was released on 9 July. That would give us a release on 9 January >> 2014. This is fairly close after the Christmas season, so I propose >> to make the estimated release date later, on 21 January, giving a few >> extra weeks for the holiday season: >> >> * Feature freeze: 18 October 2013 >> * Code freezing point: 8 November 2013 >> * First RC: 26 November 2013 >> * Release: 21 January 2014 > So I didn't see any comments on the proposed schedule so far. > Hence I wonder how fixed we have to consider that plan at > this point. I'm asking because from the very beginning I was > not really in favor of shortening the release cycle, and looking > at the number of (smaller) items on my todo list, I don't see any > way to even get just a good part of them done by the proposed > feature freeze date (taking into consideration that working on > those items usually is possible only when no other bugs or > routine work need dealing with). I think as release cycles get shorter, we have to move into thinking more like the Linux "merge windows": you work on your feature, and when it's ready, you target it for a specific merge window. Each release will have fewer features, but overall the work should continue at a similar pace. For 4.4, it seems likely that we will have stage one of PVH, host USB support, a Linux-based stubdom, a FreeBSD-based libc for minios, vNUMA for PV guests, possibly for HVM guests... that seems like a fairly feature-ful release. None of this is set in stone -- if we get to October and it looks like 4.4 is just "4.3 with some bug fixes", then we can just decide to extend the development cycle another few months. -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-19 13:09 ` George Dunlap @ 2013-08-19 15:18 ` Ian Campbell 2013-08-20 7:28 ` Jan Beulich 1 sibling, 0 replies; 116+ messages in thread From: Ian Campbell @ 2013-08-19 15:18 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel, Jan Beulich On Mon, 2013-08-19 at 14:09 +0100, George Dunlap wrote: > None of this is set in stone -- if we get to October and it looks like > 4.4 is just "4.3 with some bug fixes", then we can just decide to > extend the development cycle another few months. "4.3 with some bug fixes" doesn't necessarily mean it's not worth releasing ;-) ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-19 13:09 ` George Dunlap 2013-08-19 15:18 ` Ian Campbell @ 2013-08-20 7:28 ` Jan Beulich 2013-08-20 9:49 ` George Dunlap 1 sibling, 1 reply; 116+ messages in thread From: Jan Beulich @ 2013-08-20 7:28 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel >>> On 19.08.13 at 15:09, George Dunlap <george.dunlap@eu.citrix.com> wrote: > I think as release cycles get shorter, we have to move into thinking > more like the Linux "merge windows": you work on your feature, and when > it's ready, you target it for a specific merge window. Which - as expressed before - I dislike. Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-20 7:28 ` Jan Beulich @ 2013-08-20 9:49 ` George Dunlap 2013-08-20 10:40 ` Jan Beulich 0 siblings, 1 reply; 116+ messages in thread From: George Dunlap @ 2013-08-20 9:49 UTC (permalink / raw) To: Jan Beulich; +Cc: xen-devel On 08/20/2013 08:28 AM, Jan Beulich wrote: >>>> On 19.08.13 at 15:09, George Dunlap <george.dunlap@eu.citrix.com> wrote: >> I think as release cycles get shorter, we have to move into thinking >> more like the Linux "merge windows": you work on your feature, and when >> it's ready, you target it for a specific merge window. > > Which - as expressed before - I dislike. But I don't think I ever understood the nature of your dislike -- what is it you like about the longer release cycles, and/or dislike about the shorter ones? -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-20 9:49 ` George Dunlap @ 2013-08-20 10:40 ` Jan Beulich 0 siblings, 0 replies; 116+ messages in thread From: Jan Beulich @ 2013-08-20 10:40 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel >>> On 20.08.13 at 11:49, George Dunlap <george.dunlap@eu.citrix.com> wrote: > On 08/20/2013 08:28 AM, Jan Beulich wrote: >>>>> On 19.08.13 at 15:09, George Dunlap <george.dunlap@eu.citrix.com> wrote: >>> I think as release cycles get shorter, we have to move into thinking >>> more like the Linux "merge windows": you work on your feature, and when >>> it's ready, you target it for a specific merge window. >> >> Which - as expressed before - I dislike. > > But I don't think I ever understood the nature of your dislike -- what > is it you like about the longer release cycles, and/or dislike about the > shorter ones? First of all, the dislike above was regarding the merge window model. That is because I prefer the continuous flow model we got used to, simply because it allows a more consistent work flow (both from a developer and from a committer perspective). As to the shorter release cycles, I'm sure I said before that I see this problematic wrt stable tree management (resulting in either shorter stable tree life cycles or more work due to more branches being maintained) as well as - see above - the worse ratio between normal development flow and a (partially/mostly) frozen tree (after all, the merge window concept just is an extreme form of shortened release cycles, where almost all of the release cycle is spent in feature frozen state). Plus to me the argument of more frequent releases allowing smoother distro adoption doesn't really count: I would generally expect distros to not ship unpatched versions anyway, so if they're eager to get a certain feature out to their users, backporting the feature is always an option. And just to clarify - don't read into this that I may even be advocating a significantly longer release cycle. As we learned with 4.2, anything beyond a year is likely not going to work out well because of too many changes accumulating. Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:09 George Dunlap ` (13 preceding siblings ...) 2013-08-14 16:35 ` Jan Beulich @ 2013-08-15 13:02 ` Wei Liu 2013-08-15 13:08 ` Jan Beulich 2013-08-29 23:34 ` Shriram Rajagopalan ` (3 subsequent siblings) 18 siblings, 1 reply; 116+ messages in thread From: Wei Liu @ 2013-08-15 13:02 UTC (permalink / raw) To: George Dunlap; +Cc: wei.liu2, xen-devel On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: [...] > > * Polish up xenbugtool > owner: wei.liu2@citrix.com > I've written a rather primitive prototype and promoted it to some users some time ago unfortunately they didn't seem to report back. > * Remove hardcoded mobprobe's in xencommons > owner: Wei Liu > status: still in discussion > Have we not reached conclusion here? IIRC in a engineering meeting we had you said we could just leave it as-is for now? Wei. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-15 13:02 ` Wei Liu @ 2013-08-15 13:08 ` Jan Beulich 2013-08-15 13:24 ` Wei Liu 0 siblings, 1 reply; 116+ messages in thread From: Jan Beulich @ 2013-08-15 13:08 UTC (permalink / raw) To: wei.liu2; +Cc: George Dunlap, xen-devel >>> On 15.08.13 at 15:02, Wei Liu <wei.liu2@citrix.com> wrote: > On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: >> * Remove hardcoded mobprobe's in xencommons >> owner: Wei Liu >> status: still in discussion >> > > Have we not reached conclusion here? IIRC in a engineering meeting we > had you said we could just leave it as-is for now? ??? Didn't we long ago agree that this hard coded loading is bogus and hence should go away? Remember this was originally planned to happen for 4.3, so any change in direction here needs a very good reason imo. Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-15 13:08 ` Jan Beulich @ 2013-08-15 13:24 ` Wei Liu 2013-08-19 11:38 ` George Dunlap 0 siblings, 1 reply; 116+ messages in thread From: Wei Liu @ 2013-08-15 13:24 UTC (permalink / raw) To: Jan Beulich; +Cc: George Dunlap, wei.liu2, xen-devel On Thu, Aug 15, 2013 at 02:08:01PM +0100, Jan Beulich wrote: > >>> On 15.08.13 at 15:02, Wei Liu <wei.liu2@citrix.com> wrote: > > On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: > >> * Remove hardcoded mobprobe's in xencommons > >> owner: Wei Liu > >> status: still in discussion > >> > > > > Have we not reached conclusion here? IIRC in a engineering meeting we > > had you said we could just leave it as-is for now? > > ??? Didn't we long ago agree that this hard coded loading is bogus > and hence should go away? Remember this was originally planned > to happen for 4.3, so any change in direction here needs a very > good reason imo. > Actually I wasn't completely sure I remembered the right thing. I might be wrong about the conclusion. Geroge, do you have any clue? :-) Wei. > Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-15 13:24 ` Wei Liu @ 2013-08-19 11:38 ` George Dunlap 2013-08-19 12:08 ` Pasi Kärkkäinen 2013-08-19 15:17 ` Ian Campbell 0 siblings, 2 replies; 116+ messages in thread From: George Dunlap @ 2013-08-19 11:38 UTC (permalink / raw) To: Wei Liu; +Cc: Ian Jackson, Jan Beulich, xen-devel On 15/08/13 14:24, Wei Liu wrote: > On Thu, Aug 15, 2013 at 02:08:01PM +0100, Jan Beulich wrote: >>>>> On 15.08.13 at 15:02, Wei Liu <wei.liu2@citrix.com> wrote: >>> On Thu, Aug 08, 2013 at 05:09:35PM +0100, George Dunlap wrote: >>>> * Remove hardcoded mobprobe's in xencommons >>>> owner: Wei Liu >>>> status: still in discussion >>>> >>> Have we not reached conclusion here? IIRC in a engineering meeting we >>> had you said we could just leave it as-is for now? >> ??? Didn't we long ago agree that this hard coded loading is bogus >> and hence should go away? Remember this was originally planned >> to happen for 4.3, so any change in direction here needs a very >> good reason imo. >> > Actually I wasn't completely sure I remembered the right thing. I might > be wrong about the conclusion. Geroge, do you have any clue? :-) I think the conclusion we came to was as follows: * Calling modprobe from libxl is not really feasible due to the fact that we have to call exec, which means making some of the calls async; one thing led to another and a huge number of calls would have had to be made async. * It is better if kernels use the auto-load mechanisms as much as possible, rather than modprobes either in the init scripts or from libxl * However, blktap is unmaintained. Unless someone steps up to add the functionality (which is not recommended as it would probably te a waste of effort), it will continue to require a modprobe. On newer systems, without blktap, the modprobe will be harmless. So for blktap, the modprobe will have to remain for the forseeable future. * It would be good if other modules were modified so that they were auto-loaded, rather than modprobed. However, this was outside of the scope of the work I or Wei agreed to do. We agreed to handle blktap, and the blktap module loading issue has been resolved. * Modifying other modules is an open ticket item Correct me if I'm wrong, anyone. I can put "auto-load other modules" on the roadmap without an owner, if you like. -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-19 11:38 ` George Dunlap @ 2013-08-19 12:08 ` Pasi Kärkkäinen 2013-08-19 12:53 ` George Dunlap 2013-08-19 15:17 ` Ian Campbell 1 sibling, 1 reply; 116+ messages in thread From: Pasi Kärkkäinen @ 2013-08-19 12:08 UTC (permalink / raw) To: George Dunlap; +Cc: Ian Jackson, Wei Liu, Jan Beulich, xen-devel On Mon, Aug 19, 2013 at 12:38:16PM +0100, George Dunlap wrote: > > * However, blktap is unmaintained. Unless someone steps up to add > the functionality (which is not recommended as it would probably te > a waste of effort), it will continue to require a modprobe. On newer > systems, without blktap, the modprobe will be harmless. So for > blktap, the modprobe will have to remain for the forseeable future. > What I've been wondering.. XenServer is shipping with and using blktap, so there must be someone maintaining blktap at Citrix? I also understand blktap is on the way out and will be replaced with qdisc in the future.. -- Pasi ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-19 12:08 ` Pasi Kärkkäinen @ 2013-08-19 12:53 ` George Dunlap 2013-08-19 13:09 ` Thanos Makatos 0 siblings, 1 reply; 116+ messages in thread From: George Dunlap @ 2013-08-19 12:53 UTC (permalink / raw) To: Pasi Kärkkäinen Cc: Ian Jackson, Thanos Makatos, Wei Liu, Jan Beulich, xen-devel On 19/08/13 13:08, Pasi Kärkkäinen wrote: > On Mon, Aug 19, 2013 at 12:38:16PM +0100, George Dunlap wrote: >> * However, blktap is unmaintained. Unless someone steps up to add >> the functionality (which is not recommended as it would probably te >> a waste of effort), it will continue to require a modprobe. On newer >> systems, without blktap, the modprobe will be harmless. So for >> blktap, the modprobe will have to remain for the forseeable future. >> > What I've been wondering.. XenServer is shipping with and using blktap, > so there must be someone maintaining blktap at Citrix? > I also understand blktap is on the way out and will be replaced with qdisc in the future.. As I understand it, XenServer is using a private fork of blktap2, with significant changes. Since blktap2 as a whole can't be upstreamed into the mainline kernel, I think the feeling was that there wasn't any point in trying to upstream the local changes to the "classic" kernel. Blktap3 was meant to be the mainline-friendly version of blktap, but as you say, work on it has halted and the plan at the moment, I'm told is to look into qdisk, since it uses a similar technology, but gives access to work from other communities as well (Ceph, for example). Thanos, correct me if I've made a mistake somewhere... -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-19 12:53 ` George Dunlap @ 2013-08-19 13:09 ` Thanos Makatos 0 siblings, 0 replies; 116+ messages in thread From: Thanos Makatos @ 2013-08-19 13:09 UTC (permalink / raw) To: George Dunlap, Pasi Kärkkäinen Cc: Ian Jackson, Wei Liu, Jan Beulich, xen-devel > -----Original Message----- > From: George Dunlap [mailto:george.dunlap@eu.citrix.com] > Sent: 19 August 2013 13:54 > To: Pasi Kärkkäinen > Cc: Wei Liu; Ian Jackson; Jan Beulich; xen-devel@lists.xen.org; Thanos > Makatos > Subject: Re: [Xen-devel] Xen 4.4 development update > > On 19/08/13 13:08, Pasi Kärkkäinen wrote: > > On Mon, Aug 19, 2013 at 12:38:16PM +0100, George Dunlap wrote: > >> * However, blktap is unmaintained. Unless someone steps up to add > >> the functionality (which is not recommended as it would probably te > >> a waste of effort), it will continue to require a modprobe. On newer > >> systems, without blktap, the modprobe will be harmless. So for > >> blktap, the modprobe will have to remain for the forseeable future. > >> > > What I've been wondering.. XenServer is shipping with and using > blktap, > > so there must be someone maintaining blktap at Citrix? > > I also understand blktap is on the way out and will be replaced with > qdisc in the future.. > > As I understand it, XenServer is using a private fork of blktap2, with > significant changes. Since blktap2 as a whole can't be upstreamed into That's right, the so-called blktap2.5 that lives in github (https://github.com/xapi-project/blktap). > the mainline kernel, I think the feeling was that there wasn't any > point > in trying to upstream the local changes to the "classic" kernel. > Blktap3 was meant to be the mainline-friendly version of blktap, but as > you say, work on it has halted and the plan at the moment, I'm told is > to look into qdisk, since it uses a similar technology, but gives > access > to work from other communities as well (Ceph, for example). blktap3 work hasn't been halted, only the upstream process has. On the contrary, we're still developing blktap3 (currently on https://github.com/tmakatos/blktap/tree/blktap3 but that's temporary) and our plan is to have it working for XenServer rather soon. I don't see any technical difficulties in Xen using blktap3, pretty much in the same way it does with qemu. > > Thanos, correct me if I've made a mistake somewhere... > > -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-19 11:38 ` George Dunlap 2013-08-19 12:08 ` Pasi Kärkkäinen @ 2013-08-19 15:17 ` Ian Campbell 2013-08-19 16:16 ` Bastian Blank 1 sibling, 1 reply; 116+ messages in thread From: Ian Campbell @ 2013-08-19 15:17 UTC (permalink / raw) To: George Dunlap; +Cc: Wei Liu, Bastian Blank, Ian Jackson, xen-devel, Jan Beulich On Mon, 2013-08-19 at 12:38 +0100, George Dunlap wrote: > I can put "auto-load other modules" on the roadmap without an owner, > if you like. I thought Waldi sent patches for most of hte other backends ages ago and this stuff just works these days. Yes, here we are: commit 149bb2fab547253e6359e76f1b86b95247110e68 Author: Bastian Blank <waldi@debian.org> Date: Wed Jun 29 14:40:08 2011 +0200 xen: Add module alias to autoload backend drivers All the Xen backend drivers are assigned to a special bus type xen-backend. This patch exports xen-backend:* names through modalias and uevent to autoload them. Signed-off-by: Bastian Blank <waldi@debian.org> Acked-by: Ian Campbell <ian.campbell@citrix.com> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Seems to have been in 3.1-rc1. Maybe there are other driver which this didn't affect, evtchn etc perhaps? I wonder if it is worth init time Xen code synthesising some uevents iff running on Xen to make these get loaded... Ian. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-19 15:17 ` Ian Campbell @ 2013-08-19 16:16 ` Bastian Blank 2013-08-19 16:38 ` Ian Campbell 0 siblings, 1 reply; 116+ messages in thread From: Bastian Blank @ 2013-08-19 16:16 UTC (permalink / raw) To: Ian Campbell; +Cc: George Dunlap, Ian Jackson, Wei Liu, Jan Beulich, xen-devel On Mon, Aug 19, 2013 at 04:17:46PM +0100, Ian Campbell wrote: > Maybe there are other driver which this didn't affect, evtchn etc > perhaps? I wonder if it is worth init time Xen code synthesising some > uevents iff running on Xen to make these get loaded... evtchn and privcmd are not auto-loaded. This patch was strictly for backends. But it should be possible to create a platform device for xen that triggers loading of them. Could be also used to differentiate between control and non-control domain. Bastian -- Live long and prosper. -- Spock, "Amok Time", stardate 3372.7 ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-19 16:16 ` Bastian Blank @ 2013-08-19 16:38 ` Ian Campbell 0 siblings, 0 replies; 116+ messages in thread From: Ian Campbell @ 2013-08-19 16:38 UTC (permalink / raw) To: Bastian Blank; +Cc: George Dunlap, Ian Jackson, Wei Liu, Jan Beulich, xen-devel On Mon, 2013-08-19 at 18:16 +0200, Bastian Blank wrote: > On Mon, Aug 19, 2013 at 04:17:46PM +0100, Ian Campbell wrote: > > Maybe there are other driver which this didn't affect, evtchn etc > > perhaps? I wonder if it is worth init time Xen code synthesising some > > uevents iff running on Xen to make these get loaded... > > evtchn and privcmd are not auto-loaded. This patch was strictly for > backends. right. > But it should be possible to create a platform device for xen that > triggers loading of them. yes, that's the sort of thing I was trying to get at with "synthesizing uevents" > Could be also used to differentiate between > control and non-control domain. Hrm, at least evtchn and privcmd are potentially (but not so commonly) usable in normal domU too. I'd be tempted to just load them if running on Xen -- they aren't exactly huge... Ian. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:09 George Dunlap ` (14 preceding siblings ...) 2013-08-15 13:02 ` Wei Liu @ 2013-08-29 23:34 ` Shriram Rajagopalan 2013-09-17 15:12 ` Jim Fehlig ` (2 subsequent siblings) 18 siblings, 0 replies; 116+ messages in thread From: Shriram Rajagopalan @ 2013-08-29 23:34 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel [-- Attachment #1.1: Type: text/plain, Size: 1558 bytes --] On Thu, Aug 8, 2013 at 12:09 PM, George Dunlap <George.Dunlap@eu.citrix.com>wrote: > This information will be mirrored on the Xen 4.4 Roadmap wiki page: > http://wiki.xen.org/wiki/Xen_Roadmap/4.4 > > Rather than try to predict precisely what will make it into what > release (which was something of a disaster last release), I'm just > going to borrow a term from the Agile world and call all uncompleted > features the "Backlog". I'll still track who is doing what, and when > we get close, what state things seem to be in. > > As mentioned in another e-mail, we'll also be working on improving the > regression tester. Feel free to join us. > > And as always, if you are working on a feature / bug that you want > tracked, please respond to this e-mail. > > = Timeline = > > As discussed elsewhere, I am proposing a 6-month release cycle. Xen > 4.3 was released on 9 July. That would give us a release on 9 January > 2014. This is fairly close after the Christmas season, so I propose > to make the estimated release date later, on 21 January, giving a few > extra weeks for the holiday season: > > * Feature freeze: 18 October 2013 > * Code freezing point: 8 November 2013 > * First RC: 26 November 2013 > * Release: 21 January 2014 > > Feedback on the estimated dates is welcome. > > Last updated: 8 August 2013 > > > > == Backlog == > > This is a late entry. * libxl support for Remus @shriram status: memory checkpointing - done. network buffering - patches posted. disk replication support using DRBD - TODO [-- Attachment #1.2: Type: text/html, Size: 2225 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:09 George Dunlap ` (15 preceding siblings ...) 2013-08-29 23:34 ` Shriram Rajagopalan @ 2013-09-17 15:12 ` Jim Fehlig 2013-09-17 15:39 ` Jan Beulich 2013-09-18 11:16 ` George Dunlap 2013-09-18 11:27 ` George Dunlap 18 siblings, 1 reply; 116+ messages in thread From: Jim Fehlig @ 2013-09-17 15:12 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel George Dunlap wrote: > This information will be mirrored on the Xen 4.4 Roadmap wiki page: > http://wiki.xen.org/wiki/Xen_Roadmap/4.4 > > Rather than try to predict precisely what will make it into what > release (which was something of a disaster last release), I'm just > going to borrow a term from the Agile world and call all uncompleted > features the "Backlog". I'll still track who is doing what, and when > we get close, what state things seem to be in. > > As mentioned in another e-mail, we'll also be working on improving the > regression tester. Feel free to join us. > > And as always, if you are working on a feature / bug that you want > tracked, please respond to this e-mail. > > = Timeline = > > As discussed elsewhere, I am proposing a 6-month release cycle. Xen > 4.3 was released on 9 July. That would give us a release on 9 January > 2014. This is fairly close after the Christmas season, so I propose > to make the estimated release date later, on 21 January, giving a few > extra weeks for the holiday season: > > * Feature freeze: 18 October 2013 > * Code freezing point: 8 November 2013 > * First RC: 26 November 2013 > * Release: 21 January 2014 > > Feedback on the estimated dates is welcome. > > Last updated: 8 August 2013 > > == Completed == > > [none] > > == Open == > > * xend still in tree > > * qemu-upstream not freeing pirq > > http://www.gossamer-threads.com/lists/xen/devel/281498 > status: patches posted > > * __update_vcpu_system_time if system_time comes out negative > > * xl pci-detach broken for pv guests? > > http://bugs.xenproject.org/xen/bug/12 > > kernel doesn't know about moving into states 7 and 8 > status: External > > * Race in PV shutdown between tool detection and shutdown watch > > http://www.gossamer-threads.com/lists/xen/devel/282467 > > Nothing to do with ACPI > status: Probably a bug in Linux xen drivers > > == Backlog == > > === Testing coverage === > > * Network driver domains > @George > > * new libxl w/ previous versions of xl > @IanJ > > * Host S3 suspend > @bguthro > > * Default [example] XSM policy > @Stefano to ask Daniel D > > * Xen on ARM > # hardware > @ianc > emulator: @stefano to think about it > > * Storage driver domains > @roger > > * HVM pci passthrough > @anthony > > * Nested virt? > @intel (chased by George) > > * Fix SRIOV test (chase intel) > @ianj > > * Fix bisector to e-mail blame-worthy parties > @ianj > > * Fix xl shutdown > @ianj > > * stub domains > @athony > > === Big ticket items === > > * NUMA Memory migration > owner: dario@citrix > status: in progress > > * Event channel scalability > owner: david@citrix > status: RFC v5 submitted > Increase limit on event channels (currently 1024 for 32-bit guests, > 4096 for 64-bit guests) > > * PVH mode (w/ Linux) > owner: mukesh@oracle > status (Linux): 3rd draft patches posted. > status (Xen): v10 posted > > * ARM stuff: ?? > > * Meta: PVIO NUMA improvements > - NUMA affinity for vcpus > owner: Dario > - PV guest NUMA interface > owner: Elena > - Sensible dom0 NUMA layout > - Toolstack pinning backend thread / virq to appropraite d0 vcpu > > * qemu-upstream stubdom, Linux > owner: anthony@citrix > status: in progress > qemu-upstream needs a more fully-featured libc than exists in > mini-os. Either work on a minimalist linux-based stubdom with > glibc, or port one of the BSD libcs to minios. > > * qemu-upstream stubdom, BSD libc > owner: ianj@citrix > There is no mention of updating to the latest upstream qemu. Wasn't there talk of updating to the latest qemu release at the beginning of a Xen development cycle? > * Network performance improvements > owner: wei@citrix > > * Disk performance improvements > > * Xen EFI feature: Xen can boot from grub.efi > owner: Daniel Kiper > status: Just begun > prognosis: Fair > > * libvirt/libxl integration (external) > > need a status update > - owner: jfehlig@suse, dario@citrix > The main items missing in the libvirt libxl driver wrt the legacy Xen driver are migration and PCI passthrough. But patches for both of these features have been posted to the libvirt dev list https://www.redhat.com/archives/libvir-list/2013-September/msg00667.html https://www.redhat.com/archives/libvir-list/2013-September/msg00660.html libvirt is on a monthly release cycle, so there will certainly be a release containing these patches before Xen 4.4. There are also patches in the works to add functionality that was generally not possible in the legacy Xen driver, e.g. integration with libvirt's lock manager, providing protection of disk resources. I'm also working on patches to improve concurrency in the driver. Slowly, with each libvirt release, the libxl driver is improving. Regards, Jim ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-17 15:12 ` Jim Fehlig @ 2013-09-17 15:39 ` Jan Beulich 2013-09-17 15:45 ` Ian Campbell 0 siblings, 1 reply; 116+ messages in thread From: Jan Beulich @ 2013-09-17 15:39 UTC (permalink / raw) To: Ian Campbell, George Dunlap; +Cc: Jim Fehlig, xen-devel >>> On 17.09.13 at 17:12, Jim Fehlig <jfehlig@suse.com> wrote: > George Dunlap wrote: >> * qemu-upstream stubdom, BSD libc >> owner: ianj@citrix >> > > There is no mention of updating to the latest upstream qemu. Wasn't > there talk of updating to the latest qemu release at the beginning of a > Xen development cycle? Talking of which - shouldn't we also update to the latest stable SeaBIOS for the new release? Jan ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-17 15:39 ` Jan Beulich @ 2013-09-17 15:45 ` Ian Campbell 0 siblings, 0 replies; 116+ messages in thread From: Ian Campbell @ 2013-09-17 15:45 UTC (permalink / raw) To: Jan Beulich; +Cc: George Dunlap, Jim Fehlig, xen-devel On Tue, 2013-09-17 at 16:39 +0100, Jan Beulich wrote: > >>> On 17.09.13 at 17:12, Jim Fehlig <jfehlig@suse.com> wrote: > > George Dunlap wrote: > >> * qemu-upstream stubdom, BSD libc > >> owner: ianj@citrix > >> > > > > There is no mention of updating to the latest upstream qemu. Wasn't > > there talk of updating to the latest qemu release at the beginning of a > > Xen development cycle? > > Talking of which - shouldn't we also update to the latest stable > SeaBIOS for the new release? Yes we should. Which means I should, just need to get around to it :-( Ian. ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:09 George Dunlap ` (16 preceding siblings ...) 2013-09-17 15:12 ` Jim Fehlig @ 2013-09-18 11:16 ` George Dunlap 2013-09-20 19:48 ` Konrad Rzeszutek Wilk 2013-09-18 11:27 ` George Dunlap 18 siblings, 1 reply; 116+ messages in thread From: George Dunlap @ 2013-09-18 11:16 UTC (permalink / raw) To: xen-devel, Anthony PERARD, Konrad Rzeszutek Wilk On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > * qemu-upstream not freeing pirq > > http://www.gossamer-threads.com/lists/xen/devel/281498 > status: patches posted Did this one get fixed yet? -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-18 11:16 ` George Dunlap @ 2013-09-20 19:48 ` Konrad Rzeszutek Wilk 0 siblings, 0 replies; 116+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-09-20 19:48 UTC (permalink / raw) To: George Dunlap; +Cc: Anthony PERARD, xen-devel On Wed, Sep 18, 2013 at 12:16:29PM +0100, George Dunlap wrote: > On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap > <George.Dunlap@eu.citrix.com> wrote: > > * qemu-upstream not freeing pirq > > > http://www.gossamer-threads.com/lists/xen/devel/281498 > > status: patches posted > > Did this one get fixed yet? I believe so. We are just waiting for Stefano to merge it in. > > -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-08-08 16:09 George Dunlap ` (17 preceding siblings ...) 2013-09-18 11:16 ` George Dunlap @ 2013-09-18 11:27 ` George Dunlap 2013-09-20 19:51 ` Konrad Rzeszutek Wilk 18 siblings, 1 reply; 116+ messages in thread From: George Dunlap @ 2013-09-18 11:27 UTC (permalink / raw) To: xen-devel, Konrad Rzeszutek Wilk On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > * xl pci-detach broken for pv guests? > > http://bugs.xenproject.org/xen/bug/12 > > kernel doesn't know about moving into states 7 and 8 > status: External > > * Race in PV shutdown between tool detection and shutdown watch > > http://www.gossamer-threads.com/lists/xen/devel/282467 > > Nothing to do with ACPI > status: Probably a bug in Linux xen drivers Konrad, I think you were looking at these -- has there been any update? -George ^ permalink raw reply [flat|nested] 116+ messages in thread
* Re: Xen 4.4 development update 2013-09-18 11:27 ` George Dunlap @ 2013-09-20 19:51 ` Konrad Rzeszutek Wilk 0 siblings, 0 replies; 116+ messages in thread From: Konrad Rzeszutek Wilk @ 2013-09-20 19:51 UTC (permalink / raw) To: George Dunlap; +Cc: xen-devel On Wed, Sep 18, 2013 at 12:27:15PM +0100, George Dunlap wrote: > On Thu, Aug 8, 2013 at 5:09 PM, George Dunlap > <George.Dunlap@eu.citrix.com> wrote: > > > * xl pci-detach broken for pv guests? > > > http://bugs.xenproject.org/xen/bug/12 > > > kernel doesn't know about moving into states 7 and 8 > > status: External > > > > * Race in PV shutdown between tool detection and shutdown watch > > > http://www.gossamer-threads.com/lists/xen/devel/282467 > > > Nothing to do with ACPI > > status: Probably a bug in Linux xen drivers > > Konrad, I think you were looking at these -- has there been any update? Oh boy. I need to replicate this. Thanks for the remainder. > > -George ^ permalink raw reply [flat|nested] 116+ messages in thread
end of thread, other threads:[~2014-01-28 10:37 UTC | newest] Thread overview: 116+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-09-16 13:06 Xen 4.4 development update George Dunlap 2013-09-16 13:28 ` Jan Beulich 2013-09-17 14:55 ` Andrew Cooper 2013-09-16 14:05 ` David Vrabel 2013-09-16 14:06 ` David Vrabel 2013-09-16 14:52 ` Fabio Fantoni 2013-09-18 11:29 ` George Dunlap 2013-09-17 0:45 ` Ben Guthro 2013-09-17 7:14 ` Dario Faggioli 2013-09-17 12:04 ` Ben Guthro 2013-09-18 15:36 ` George Dunlap 2013-09-17 19:18 ` Pasi Kärkkäinen 2013-09-18 16:59 ` George Dunlap 2013-09-20 15:57 ` Olaf Hering 2013-09-20 16:04 ` George Dunlap 2013-09-23 7:24 ` Jan Beulich 2013-09-23 11:22 ` George Dunlap 2013-09-23 11:48 ` George Dunlap 2013-09-23 12:13 ` Jan Beulich 2013-09-23 12:50 ` George Dunlap 2013-09-23 8:48 ` Olaf Hering 2013-09-23 10:29 ` Pasi Kärkkäinen -- strict thread matches above, loose matches on Subject: below -- 2014-01-27 18:49 George Dunlap 2014-01-27 18:51 ` George Dunlap 2014-01-27 23:52 ` Jim Fehlig 2014-01-28 10:37 ` Jan Beulich 2014-01-08 13:16 Ian Campbell 2014-01-08 13:29 ` Ian Campbell 2014-01-08 13:30 ` Ian Campbell 2014-01-08 14:21 ` Sander Eikelenboom 2014-01-08 14:23 ` Ian Campbell 2014-01-08 14:35 ` Wei Liu 2014-01-16 6:54 ` Zhang, Yang Z 2013-11-26 12:14 George Dunlap 2013-11-26 12:55 ` Jan Beulich 2013-11-26 14:16 ` Ian Campbell 2013-11-27 10:51 ` Gordan Bobic 2013-12-02 18:34 ` Dario Faggioli 2013-12-02 17:36 ` Lars Kurth 2013-12-02 18:34 ` Dario Faggioli 2013-12-03 19:37 ` Konrad Rzeszutek Wilk 2013-12-04 10:30 ` Ian Campbell 2013-12-03 19:41 ` Konrad Rzeszutek Wilk 2013-12-04 10:38 ` Stefano Stabellini 2013-08-08 19:38 Eric Shelton 2013-08-08 19:55 ` Konrad Rzeszutek Wilk 2013-08-08 20:51 ` Eric Shelton 2013-08-09 18:56 ` Daniel Kiper 2013-08-15 5:32 ` Eric Shelton 2013-08-20 16:13 ` Stefano Stabellini 2013-08-08 16:09 George Dunlap 2013-08-08 16:11 ` George Dunlap 2013-08-09 8:11 ` Jan Beulich 2013-08-09 11:08 ` Dario Faggioli 2013-08-08 16:14 ` George Dunlap 2013-08-08 16:17 ` Andrew Cooper 2013-08-09 8:08 ` Jan Beulich 2013-08-08 16:24 ` Ian Campbell 2013-08-13 16:06 ` George Dunlap 2013-08-08 19:30 ` Konrad Rzeszutek Wilk 2013-08-13 16:19 ` George Dunlap 2013-08-29 11:49 ` Fabio Fantoni 2013-08-13 16:22 ` George Dunlap 2013-08-13 16:27 ` Jan Beulich 2013-08-09 7:57 ` Jan Beulich 2013-08-09 8:02 ` Jan Beulich 2013-08-09 11:03 ` Dario Faggioli 2013-08-14 10:27 ` George Dunlap 2013-08-09 8:06 ` Jan Beulich 2013-08-14 10:35 ` George Dunlap 2013-08-09 14:10 ` Dario Faggioli 2013-08-09 23:08 ` Matt Wilson 2013-08-09 23:42 ` Dario Faggioli 2013-08-14 11:11 ` George Dunlap 2013-08-14 11:10 ` George Dunlap 2013-08-09 20:01 ` Daniel Kiper 2013-08-12 8:06 ` Jan Beulich 2013-08-12 18:55 ` Daniel Kiper 2013-08-13 10:13 ` Jan Beulich 2013-08-13 12:43 ` Daniel Kiper 2013-08-12 9:44 ` David Vrabel 2013-08-12 18:56 ` Daniel Kiper 2013-08-14 13:22 ` George Dunlap 2013-08-27 9:51 ` Daniel Kiper 2013-08-09 20:15 ` Boris Ostrovsky 2013-08-12 9:49 ` David Vrabel 2013-08-13 0:38 ` Mukesh Rathor 2013-08-13 13:17 ` Ben Guthro 2013-08-13 15:43 ` Dario Faggioli 2013-08-13 16:18 ` Ben Guthro 2013-08-13 18:50 ` Dario Faggioli 2013-08-14 13:42 ` George Dunlap 2013-08-14 16:35 ` Jan Beulich 2013-08-19 13:09 ` George Dunlap 2013-08-19 15:18 ` Ian Campbell 2013-08-20 7:28 ` Jan Beulich 2013-08-20 9:49 ` George Dunlap 2013-08-20 10:40 ` Jan Beulich 2013-08-15 13:02 ` Wei Liu 2013-08-15 13:08 ` Jan Beulich 2013-08-15 13:24 ` Wei Liu 2013-08-19 11:38 ` George Dunlap 2013-08-19 12:08 ` Pasi Kärkkäinen 2013-08-19 12:53 ` George Dunlap 2013-08-19 13:09 ` Thanos Makatos 2013-08-19 15:17 ` Ian Campbell 2013-08-19 16:16 ` Bastian Blank 2013-08-19 16:38 ` Ian Campbell 2013-08-29 23:34 ` Shriram Rajagopalan 2013-09-17 15:12 ` Jim Fehlig 2013-09-17 15:39 ` Jan Beulich 2013-09-17 15:45 ` Ian Campbell 2013-09-18 11:16 ` George Dunlap 2013-09-20 19:48 ` Konrad Rzeszutek Wilk 2013-09-18 11:27 ` George Dunlap 2013-09-20 19:51 ` Konrad Rzeszutek Wilk
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.