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)
>>> 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
On 16/09/13 14:06, George Dunlap wrote:> > * New kexec implementationowner: David Vrabel status: v7 posted, only minor updates expected. David
On 16/09/13 14:06, George Dunlap wrote:> > * New kexec implementationowner: David Vrabel status: v7 posted, only minor updates expected. David
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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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) _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
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) > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/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. > > JanRelatedly, 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
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
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
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/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
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 migrationlibxl 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
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_ComparisonAre 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
>>> 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
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
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
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
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
>>> 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
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