We''re 4 months into our estimated 9-months release schedule, and 2
months
away from the scheduled feature freeze. It seems like a good time to take
stock of where we are and make sure we''re on track for the release.
Below are the features on my list, sorted by how likely they are to be
completed. Overall, the set of {completed, on-track} features looks pretty
good.
The first question to ask is this this:
1. Are there any features we absolutely need for 4.3 that are not on this
list?
Recall that one of the main reasons for the delay of 4.2 was that we
didn''t
have a stable API for libxl, and no one really realized it until after the
feature freeze -- I want to try to avoid that this time. :-)
In particular, "Default to QEMU upstream" is a feature we want to make
sure
to have -- is there anything else we need for that, besides the linux-based
stubdom (which is on track)?
2. Are there any features marked "fair" or "at risk" that we
think are
important enough to intervene in?
Keeping in mind that our options for intervening are basically:
* Getting someone already in our community to spend more effort on it
(which may mean less of something else)
* Ask for additional outside resources (e.g., recruiting active users or
intermittent contributors)
* Slip the schedule.
I''ll respond to this e-mail with my own thoughts.
-George
== Finished features =
* Default to QEMU upstream (partial)
- pci pass-thru (external)
- enable dirtybit tracking during migration (external)
- xl cd-{insert,eject} (external)
* Persistent grants for blk (Linux)
* Allow XSM to override IS_PRIV checks in the hypervisor
* CPUID-based idle (don''t rely on ACPI info f/ dom0)
* Serial console improvements
== Features on-track =
* PVH mode (Xen & Linux)
* Event channel scalability
* ARM v7 server port
* NUMA scheduler affinity
* Default to QEMU upstream
- linux-based qemu stubdom
* Persistent grants for blk (qemu)
* Scalability: 16TiB of RAM
* vTPM updates
* libvirt/libxl integration (external)
* xl USB pass-through for HVM guests using Qemu USB emulation
* xl QXL Spice support
* Rationalized backend scripts
== Features marked as Fair =
* Scripts for driver domains (depends on backend scripts)
* xl PVUSB pass-through for PV guests
* xl PVUSB pass-through for HVM guests
* NUMA Memory migration
* Multi-page blk rings (external)
== Features at risk =
* Remove hardcoded mobprobe''s in xencommons
* openvswitch toostack integration
* blktap3
* Xen EFI feature: dom0 able to make use of EFI run-time services
* Guest EFI booting
* Persistent grants for net
* Multi-page net protocol (external)
* V4V: Inter-domain communication
* Wait queues for mm
* xl vm-{export,import}
* PV audio (audio for stubdom qemu)
* IllumOS (OpenSolaris fork) support
* Make storage migration possible
* Full-VM snapshotting
* VM Cloning
* Memory: Replace PoD with paging mechanism
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
On Wed, Jan 23, 2013 at 4:32 PM, George Dunlap <George.Dunlap@eu.citrix.com>wrote:> == Finished features => > * Default to QEMU upstream (partial) > - pci pass-thru (external) > - enable dirtybit tracking during migration (external) > - xl cd-{insert,eject} (external) > * Persistent grants for blk (Linux) > * Allow XSM to override IS_PRIV checks in the hypervisor > * CPUID-based idle (don''t rely on ACPI info f/ dom0) > * Serial console improvements > > == Features on-track => > * PVH mode (Xen & Linux) > * Event channel scalability > * ARM v7 server port > * NUMA scheduler affinity > * Default to QEMU upstream > - linux-based qemu stubdom > * Persistent grants for blk (qemu) > * Scalability: 16TiB of RAM > * vTPM updates > * libvirt/libxl integration (external) > * xl USB pass-through for HVM guests using Qemu USB emulation > * xl QXL Spice support > * Rationalized backend scripts > > == Features marked as Fair => > * Scripts for driver domains (depends on backend scripts) >I think this should be a blocker. Not having driver domains for xl will be a very big regression, and will remove one of the key features that can differentiate us from our competitors. I think we should consider this one a blocker.> * xl PVUSB pass-through for PV guests > * xl PVUSB pass-through for HVM guests > * NUMA Memory migration > * Multi-page blk rings (external) > > == Features at risk => > * Remove hardcoded mobprobe''s in xencommons >As Jan already mentioned, should be a blocker. This just needs someone to step up to do it.> * openvswitch toostack integration >I think openvswitch is a win from a benefit/effort point of view. It''s already got an RFC posted by Bastian to the list; and we''ve got some expertise on openvswitch in the XenServer team -- who can''t write it but could maybe give advice / figure out bugs quicker. If we can just get someone motivated enough to take it up, then we''d have a pretty good feature for not too much work.> * blktap3 >One that I really wish we could get into 4.3 is blktap3 -- this is one of the big things keeping "Xen+pvops" from having feature parity with "Xen+classic Xen". Thanos is doing good work, but only has a few hours a week to dedicate to it. If someone were able to take it over full-time starting in the next few weeks, it might be possible. But it''s not clear where such a person would come from.> * Xen EFI feature: dom0 able to make use of EFI run-time services >Daniel Kiper is already working on this, but has just started. The issue (as I understand it) is that if there are systems where the ACPI tables are only discoverable via EFI, then Xen+pvops will not be able to boot if pvops doesn''t have EFI run-time support. The following version of Xen won''t come out until probably Q2 2014, and won''t hit distros probably until 6 months after that. Given that, what do we think is the likelihood of such systems cropping up in that timeframe? If the answer is anything other than "very low", I think that as a strategic measure, this one is probably important enough to slip the schedule a little bit if necessary. I think everything else is probably fine. -George> * Guest EFI booting > * Persistent grants for net > * Multi-page net protocol (external) > * V4V: Inter-domain communication > * Wait queues for mm > * xl vm-{export,import} > * PV audio (audio for stubdom qemu) > * IllumOS (OpenSolaris fork) support > * Make storage migration possible > * Full-VM snapshotting > * VM Cloning > * Memory: Replace PoD with paging mechanism >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
>>> On 23.01.13 at 17:52, George Dunlap <George.Dunlap@eu.citrix.com> wrote: >> * Xen EFI feature: dom0 able to make use of EFI run-time services >> > > Daniel Kiper is already working on this, but has just started. The issue > (as I understand it) is that if there are systems where the ACPI tables are > only discoverable via EFI, then Xen+pvops will not be able to boot if pvops > doesn''t have EFI run-time support. The following version of Xen won''t come > out until probably Q2 2014, and won''t hit distros probably until 6 months > after that. > > Given that, what do we think is the likelihood of such systems cropping up > in that timeframe? If the answer is anything other than "very low", I > think that as a strategic measure, this one is probably important enough to > slip the schedule a little bit if necessary.Except that this ought to be marked (external) in the first place: The hypervisor support is all there (otherwise our kernels wouldn''t have been successfully booting on EFI for well over a year), and hence this work shouldn''t really have any impact on the schedule. The one feature here that requires work in our tree is to be able to boot via grub.efi (irrespective of how little I personally like that); I''m not sure Daniel was also planning to look into that part. Jan
On Wed, Jan 23, 2013 at 04:32:05PM +0000, George Dunlap wrote:> We''re 4 months into our estimated 9-months release schedule, and 2 months > away from the scheduled feature freeze. It seems like a good time to take > stock of where we are and make sure we''re on track for the release. > > Below are the features on my list, sorted by how likely they are to be > completed. Overall, the set of {completed, on-track} features looks pretty > good. > > The first question to ask is this this: > > 1. Are there any features we absolutely need for 4.3 that are not on this > list?PVH .. at least the hypercall number/format needs to be set in stone.
On 23/01/13 17:05, Konrad Rzeszutek Wilk wrote:> On Wed, Jan 23, 2013 at 04:32:05PM +0000, George Dunlap wrote: >> We''re 4 months into our estimated 9-months release schedule, and 2 months >> away from the scheduled feature freeze. It seems like a good time to take >> stock of where we are and make sure we''re on track for the release. >> >> Below are the features on my list, sorted by how likely they are to be >> completed. Overall, the set of {completed, on-track} features looks pretty >> good. >> >> The first question to ask is this this: >> >> 1. Are there any features we absolutely need for 4.3 that are not on this >> list? > PVH .. at least the hypercall number/format needs to be set in stone.PVH is right at the top of the "features on track" section. :-) The purpose of this question is to ask everyone to think about anything *else* we we really need, so we don''t end up with a 6-month feature freeze again. I think everyone agrees that PVH is a blocker. At the moment it doesn''t look like it needs any intervention; there''s no particular need to talk about interventions until something comes up. -George
On 23/01/13 17:00, Jan Beulich wrote:>>>> On 23.01.13 at 17:52, George Dunlap <George.Dunlap@eu.citrix.com> wrote: >>> * Xen EFI feature: dom0 able to make use of EFI run-time services >>> >> Daniel Kiper is already working on this, but has just started. The issue >> (as I understand it) is that if there are systems where the ACPI tables are >> only discoverable via EFI, then Xen+pvops will not be able to boot if pvops >> doesn''t have EFI run-time support. The following version of Xen won''t come >> out until probably Q2 2014, and won''t hit distros probably until 6 months >> after that. >> >> Given that, what do we think is the likelihood of such systems cropping up >> in that timeframe? If the answer is anything other than "very low", I >> think that as a strategic measure, this one is probably important enough to >> slip the schedule a little bit if necessary. > Except that this ought to be marked (external) in the first place: > The hypervisor support is all there (otherwise our kernels wouldn''t > have been successfully booting on EFI for well over a year), and > hence this work shouldn''t really have any impact on the schedule.Ah, right -- sorry, I misunderstood the situation. As long as the Xen side is there to use as soon as the functionality is ready, I think we''re probably fine.> The one feature here that requires work in our tree is to be able > to boot via grub.efi (irrespective of how little I personally like that); > I''m not sure Daniel was also planning to look into that part.Do you think not having this for 4.3 will be a potential problem for Xen? -George
> * blktap3 > > One that I really wish we could get into 4.3 is blktap3 -- this is one of the big things keeping "Xen+pvops" from having feature parity with "Xen+classic Xen". Thanos is doing good work, but only has a few hours a week to dedicate to it. If someone were able to take it over full-time starting in the next few weeks, it might be possible. But it''s not clear where such a person would come from.Unfortunately this is true.. If anyone is interesting in helping with blktap3 the patches are here: https://bitbucket.org/tmakatos/blktap3-patches
On Wed, Jan 23, 2013 at 05:00:26PM +0000, Jan Beulich wrote:> >>> On 23.01.13 at 17:52, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > >> * Xen EFI feature: dom0 able to make use of EFI run-time services > >> > > > > Daniel Kiper is already working on this, but has just started. The issue > > (as I understand it) is that if there are systems where the ACPI tables are > > only discoverable via EFI, then Xen+pvops will not be able to boot if pvops > > doesn''t have EFI run-time support. The following version of Xen won''t come > > out until probably Q2 2014, and won''t hit distros probably until 6 months > > after that. > > > > Given that, what do we think is the likelihood of such systems cropping up > > in that timeframe? If the answer is anything other than "very low", I > > think that as a strategic measure, this one is probably important enough to > > slip the schedule a little bit if necessary. > > Except that this ought to be marked (external) in the first place: > The hypervisor support is all there (otherwise our kernels wouldn''t > have been successfully booting on EFI for well over a year), and > hence this work shouldn''t really have any impact on the schedule. > > The one feature here that requires work in our tree is to be able > to boot via grub.efi (irrespective of how little I personally like that); > I''m not sure Daniel was also planning to look into that part.CC-ing Daniel here. My recollection is that from the Linux PV dom0 standpoint it does not matter what the bootloader is. It ends up with the information from the hypervisor - and it is the hypervisor that is either called (xen.efi) or it (the hypervisor) gets the information from an EFI-enabled bootloader (grub*.efi). Either way, the Linux kernel gets called via XEN_ELFNOTE_ENTRY entry and it would be responsible for making the proper hypercalls to populate the bootparams and the efi tables so that the generic code can continue on with the proper information.
> > * openvswitch toostack integration > > I think openvswitch is a win from a benefit/effort point of view. It''s already > got an RFC posted by Bastian to the list; and we''ve got some expertise on > openvswitch in the XenServer team -- who can''t write it but could maybe > give advice / figure out bugs quicker. If we can just get someone motivated > enough to take it up, then we''d have a pretty good feature for not too much > work. >What are the requirements here? I just had a look at http://lists.xen.org/archives/html/xen-devel/2012-09/msg00943.html, is that the RFC script you are referring to? What I would need is to be able to specify a vlan tag for the port too, but even better would be that you manually create the port outside of xen and the domu would plug into that port. I''m not sure if the port/interface names are long enough to allow this in an intuitive way though (eg to specify grokable port names). The big problem I have with brctl compatibility layer is that at the moment it isn''t working for vlan tagged virtual switches (it used to, don''t know what''s changed), and if the cleanup script doesn''t get run for any reason it leaves stale ports around, and they collide after reboot when the same vif number is reused. Also there is a qemu-ifup script that does some brctl stuff too, and also seems to race with the interface rename, at least under the Debian Xen 4.1 packages. James
>>> On 23.01.13 at 18:10, George Dunlap <george.dunlap@eu.citrix.com> wrote: > On 23/01/13 17:00, Jan Beulich wrote: >> The one feature here that requires work in our tree is to be able >> to boot via grub.efi (irrespective of how little I personally like that); >> I''m not sure Daniel was also planning to look into that part. > > Do you think not having this for 4.3 will be a potential problem for Xen?The feature was reportedly missed by two or three people so far, all of which simply were told to go the currently working route. But I recall IanC saying something about Debian (or was it Ubuntu) not being willing to support the boot loader free approach... Jan
>>> On 23.01.13 at 18:54, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote: > My recollection is that from the Linux PV dom0 standpoint it does not matter > what the bootloader is. It ends up with the information from the hypervisor > - and it is the hypervisor that is either called (xen.efi) or it (the > hypervisor) > gets the information from an EFI-enabled bootloader (grub*.efi). > > Either way, the Linux kernel gets called via XEN_ELFNOTE_ENTRY entry and > it would be responsible for making the proper hypercalls to populate > the bootparams and the efi tables so that the generic code can > continue on with the proper information.Yes and yes - the two work items are completely independent. Jan
(adding waldi) On Wed, 2013-01-23 at 22:03 +0000, James Harper wrote:> > > > * openvswitch toostack integration > > > > I think openvswitch is a win from a benefit/effort point of view. It''s already > > got an RFC posted by Bastian to the list; and we''ve got some expertise on > > openvswitch in the XenServer team -- who can''t write it but could maybe > > give advice / figure out bugs quicker. If we can just get someone motivated > > enough to take it up, then we''d have a pretty good feature for not too much > > work. > > > > What are the requirements here?Nothing exciting, it should hook up VIFs and emulated devices to the specified bridge and tear them down again on shutdown. Expanding http://wiki.xen.org/wiki/HostConfiguration/Networking e.g. examples for howto setup /etc/network/interfaces and/or ifcfg files for the host ovs config, and linking to the right ovs docs, would also be good.> I just had a look at > http://lists.xen.org/archives/html/xen-devel/2012-09/msg00943.html, is > that the RFC script you are referring to?Yes. Bastian, did you continue to evolve the script after posting or is this your final version?> What I would need is to be able to specify a vlan tag for the port > too,Bastian handled that by adding some syntax to the bridge name and parsing it in this script, see around the: tag="${BASH_REMATCH[3]}"> but even better would be that you manually create the port outside of > xen and the domu would plug into that port. I''m not sure if the > port/interface names are long enough to allow this in an intuitive way > though (eg to specify grokable port names).I can never remember the OVS terminology but what you are saying is that you want to create ovsbr0 and several named ports (lets say, eth0, web and db) where eth0 is a real thing and web and db are "floating" ports where there is no corresponding network device. When the vif is created it can then be bound to the port? This means that you can preconfigure the rules for web and db even before starting the domain? Which ovs commands would you use to do this? If it can be done by hand then I expect it could also be done by extending the syntax Bastian added. If you are just saying you want the vif to be named "web" then the existing vifname stuff (which the script should be applying prior to connecting to the bridge) would do the job.> The big problem I have with brctl compatibility layer is that at the > moment it isn''t working for vlan tagged virtual switches (it used to, > don''t know what''s changed), and if the cleanup script doesn''t get run > for any reason it leaves stale ports around, and they collide after > reboot when the same vif number is reused.Yes, we definitely don''t want to be using the brctl compat layer. The lack of a cleanup script getting run correctly on network devices was something Roger solved with his hotplug rework for xl in 4.2 (essentially the script used to be run after the backend was torn down in xenstore so it couldn''t get at many of its parameters)> Also there is a qemu-ifup script that does some brctl stuff too, and > also seems to race with the interface rename, at least under the > Debian Xen 4.1 packages.In 4.2 I made it so that Xen emulated devices used the Xen hotplug scripts instead of the qemu-ifup script, for consistency. Ian.
On Thu, 2013-01-24 at 08:32 +0000, Jan Beulich wrote:> >>> On 23.01.13 at 18:10, George Dunlap <george.dunlap@eu.citrix.com> wrote: > > On 23/01/13 17:00, Jan Beulich wrote: > >> The one feature here that requires work in our tree is to be able > >> to boot via grub.efi (irrespective of how little I personally like that); > >> I''m not sure Daniel was also planning to look into that part. > > > > Do you think not having this for 4.3 will be a potential problem for Xen? > > The feature was reportedly missed by two or three people so far, > all of which simply were told to go the currently working route. But > I recall IanC saying something about Debian (or was it Ubuntu) not > being willing to support the boot loader free approach...I think both of them would prefer to have a standard bootloader "experience" for both Linux and Xen. Looking back at the Debian conversation what Bastian actually asked when I suggested packaging the EFI hypervisor image was if the same image could be used for UEFI and BIOS, which I suppose isn''t exactly the same as above since having the same binary (if that were even possible) doesn''t necessitate booting via a bootloader. Ian.
>>> On 24.01.13 at 10:49, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Thu, 2013-01-24 at 08:32 +0000, Jan Beulich wrote: >> >>> On 23.01.13 at 18:10, George Dunlap <george.dunlap@eu.citrix.com> wrote: >> > On 23/01/13 17:00, Jan Beulich wrote: >> >> The one feature here that requires work in our tree is to be able >> >> to boot via grub.efi (irrespective of how little I personally like that); >> >> I''m not sure Daniel was also planning to look into that part. >> > >> > Do you think not having this for 4.3 will be a potential problem for Xen? >> >> The feature was reportedly missed by two or three people so far, >> all of which simply were told to go the currently working route. But >> I recall IanC saying something about Debian (or was it Ubuntu) not >> being willing to support the boot loader free approach... > > I think both of them would prefer to have a standard bootloader > "experience" for both Linux and Xen. > > Looking back at the Debian conversation what Bastian actually asked when > I suggested packaging the EFI hypervisor image was if the same image > could be used for UEFI and BIOS, which I suppose isn''t exactly the same > as above since having the same binary (if that were even possible) > doesn''t necessitate booting via a bootloader.But a single binary is not an option - the ELF and MSDOS signatures both sit at file offset 0. Jan
On Thu, 2013-01-24 at 10:03 +0000, Jan Beulich wrote:> >>> On 24.01.13 at 10:49, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > On Thu, 2013-01-24 at 08:32 +0000, Jan Beulich wrote: > >> >>> On 23.01.13 at 18:10, George Dunlap <george.dunlap@eu.citrix.com> wrote: > >> > On 23/01/13 17:00, Jan Beulich wrote: > >> >> The one feature here that requires work in our tree is to be able > >> >> to boot via grub.efi (irrespective of how little I personally like that); > >> >> I''m not sure Daniel was also planning to look into that part. > >> > > >> > Do you think not having this for 4.3 will be a potential problem for Xen? > >> > >> The feature was reportedly missed by two or three people so far, > >> all of which simply were told to go the currently working route. But > >> I recall IanC saying something about Debian (or was it Ubuntu) not > >> being willing to support the boot loader free approach... > > > > I think both of them would prefer to have a standard bootloader > > "experience" for both Linux and Xen. > > > > Looking back at the Debian conversation what Bastian actually asked when > > I suggested packaging the EFI hypervisor image was if the same image > > could be used for UEFI and BIOS, which I suppose isn''t exactly the same > > as above since having the same binary (if that were even possible) > > doesn''t necessitate booting via a bootloader. > > But a single binary is not an option - the ELF and MSDOS signatures > both sit at file offset 0.Yes, I thought you might say that ;-) If we boot via grub is the binary the same there regardless of whether it is grub-efi or grub-pc (/bios) ? Ian.
>>> On 24.01.13 at 11:07, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Thu, 2013-01-24 at 10:03 +0000, Jan Beulich wrote: >> >>> On 24.01.13 at 10:49, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> > On Thu, 2013-01-24 at 08:32 +0000, Jan Beulich wrote: >> >> >>> On 23.01.13 at 18:10, George Dunlap <george.dunlap@eu.citrix.com> wrote: >> >> > On 23/01/13 17:00, Jan Beulich wrote: >> >> >> The one feature here that requires work in our tree is to be able >> >> >> to boot via grub.efi (irrespective of how little I personally like that); >> >> >> I''m not sure Daniel was also planning to look into that part. >> >> > >> >> > Do you think not having this for 4.3 will be a potential problem for Xen? >> >> >> >> The feature was reportedly missed by two or three people so far, >> >> all of which simply were told to go the currently working route. But >> >> I recall IanC saying something about Debian (or was it Ubuntu) not >> >> being willing to support the boot loader free approach... >> > >> > I think both of them would prefer to have a standard bootloader >> > "experience" for both Linux and Xen. >> > >> > Looking back at the Debian conversation what Bastian actually asked when >> > I suggested packaging the EFI hypervisor image was if the same image >> > could be used for UEFI and BIOS, which I suppose isn''t exactly the same >> > as above since having the same binary (if that were even possible) >> > doesn''t necessitate booting via a bootloader. >> >> But a single binary is not an option - the ELF and MSDOS signatures >> both sit at file offset 0. > > Yes, I thought you might say that ;-) > > If we boot via grub is the binary the same there regardless of whether > it is grub-efi or grub-pc (/bios) ?I suppose so, but don''t know (as I never looked at how grub.efi works). Jan
On 24/01/13 11:16, Daniel Kiper wrote:> On Wed, Jan 23, 2013 at 05:00:26PM +0000, Jan Beulich wrote: >>>>> On 23.01.13 at 17:52, George Dunlap <George.Dunlap@eu.citrix.com> wrote: >>>> * Xen EFI feature: dom0 able to make use of EFI run-time services >>>> >>> Daniel Kiper is already working on this, but has just started. The issue >>> (as I understand it) is that if there are systems where the ACPI tables are >>> only discoverable via EFI, then Xen+pvops will not be able to boot if pvops >>> doesn''t have EFI run-time support. The following version of Xen won''t come >>> out until probably Q2 2014, and won''t hit distros probably until 6 months >>> after that. >>> >>> Given that, what do we think is the likelihood of such systems cropping up >>> in that timeframe? If the answer is anything other than "very low", I >>> think that as a strategic measure, this one is probably important enough to >>> slip the schedule a little bit if necessary. >> Except that this ought to be marked (external) in the first place: >> The hypervisor support is all there (otherwise our kernels wouldn''t >> have been successfully booting on EFI for well over a year), and >> hence this work shouldn''t really have any impact on the schedule. >> >> The one feature here that requires work in our tree is to be able >> to boot via grub.efi (irrespective of how little I personally like that); >> I''m not sure Daniel was also planning to look into that part. > I am going to do all work which is needed to run Xen + upstream Linux > Kernel on EFI enabled platform. I am going to look at GRUB2 too (as > stated eariler). I hope that this does not require a lot of work and > relevant patches could be ready before 4.3 feature freeze.Great! If you could prioritize Xen booting under grub2.efi, it seems like that would benefit the xen.org project overall. Shall I put you down as owner for "Xen on grub.efi", and mark it as "Fair" (given that you don''t yet know how much work it will be)? -George
On Wed, Jan 23, 2013 at 05:00:26PM +0000, Jan Beulich wrote:> >>> On 23.01.13 at 17:52, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > >> * Xen EFI feature: dom0 able to make use of EFI run-time services > >> > > > > Daniel Kiper is already working on this, but has just started. The issue > > (as I understand it) is that if there are systems where the ACPI tables are > > only discoverable via EFI, then Xen+pvops will not be able to boot if pvops > > doesn''t have EFI run-time support. The following version of Xen won''t come > > out until probably Q2 2014, and won''t hit distros probably until 6 months > > after that. > > > > Given that, what do we think is the likelihood of such systems cropping up > > in that timeframe? If the answer is anything other than "very low", I > > think that as a strategic measure, this one is probably important enough to > > slip the schedule a little bit if necessary. > > Except that this ought to be marked (external) in the first place: > The hypervisor support is all there (otherwise our kernels wouldn''t > have been successfully booting on EFI for well over a year), and > hence this work shouldn''t really have any impact on the schedule. > > The one feature here that requires work in our tree is to be able > to boot via grub.efi (irrespective of how little I personally like that); > I''m not sure Daniel was also planning to look into that part.I am going to do all work which is needed to run Xen + upstream Linux Kernel on EFI enabled platform. I am going to look at GRUB2 too (as stated eariler). I hope that this does not require a lot of work and relevant patches could be ready before 4.3 feature freeze. Daniel
On Thu, Jan 24, 2013 at 11:12:48AM +0000, George Dunlap wrote:> On 24/01/13 11:16, Daniel Kiper wrote: > >On Wed, Jan 23, 2013 at 05:00:26PM +0000, Jan Beulich wrote: > >>>>>On 23.01.13 at 17:52, George Dunlap <George.Dunlap@eu.citrix.com> wrote: > >>>>* Xen EFI feature: dom0 able to make use of EFI run-time services > >>>> > >>>Daniel Kiper is already working on this, but has just started. The issue > >>>(as I understand it) is that if there are systems where the ACPI tables are > >>>only discoverable via EFI, then Xen+pvops will not be able to boot if pvops > >>>doesn''t have EFI run-time support. The following version of Xen won''t come > >>>out until probably Q2 2014, and won''t hit distros probably until 6 months > >>>after that. > >>> > >>>Given that, what do we think is the likelihood of such systems cropping up > >>>in that timeframe? If the answer is anything other than "very low", I > >>>think that as a strategic measure, this one is probably important enough to > >>>slip the schedule a little bit if necessary. > >>Except that this ought to be marked (external) in the first place: > >>The hypervisor support is all there (otherwise our kernels wouldn''t > >>have been successfully booting on EFI for well over a year), and > >>hence this work shouldn''t really have any impact on the schedule. > >> > >>The one feature here that requires work in our tree is to be able > >>to boot via grub.efi (irrespective of how little I personally like that); > >>I''m not sure Daniel was also planning to look into that part. > >I am going to do all work which is needed to run Xen + upstream Linux > >Kernel on EFI enabled platform. I am going to look at GRUB2 too (as > >stated eariler). I hope that this does not require a lot of work and > >relevant patches could be ready before 4.3 feature freeze. > > Great! If you could prioritize Xen booting under grub2.efi, it seems > like that would benefit the xen.org project overall.I am going to do that in that way.> Shall I put you down as owner for "Xen on grub.efi", and mark it as > "Fair" (given that you don''t yet know how much work it will be)?Yes, go ahead. Daniel
> > but even better would be that you manually create the port outside of > > xen and the domu would plug into that port. I'm not sure if the > > port/interface names are long enough to allow this in an intuitive way > > though (eg to specify grokable port names). > > I can never remember the OVS terminology but what you are saying is that > you want to create ovsbr0 and several named ports (lets say, eth0, web > and db) where eth0 is a real thing and web and db are "floating" ports > where there is no corresponding network device. When the vif is created > it can then be bound to the port? > > This means that you can preconfigure the rules for web and db even > before starting the domain? > > Which ovs commands would you use to do this? If it can be done by hand > then I expect it could also be done by extending the syntax Bastian > added. > > If you are just saying you want the vif to be named "web" then the > existing vifname stuff (which the script should be applying prior to > connecting to the bridge) would do the job. > > <snip> > > The lack of a cleanup script getting run correctly on network devices > was something Roger solved with his hotplug rework for xl in 4.2 > (essentially the script used to be run after the backend was torn down > in xenstore so it couldn't get at many of its parameters)The problem here is that ovs remembers all the ports in its database. You do add-port once and the port is there forever until you remove it again, even over reboots. It's great for eth0 etc because everything "just works" once ovs is started, but it's not so great for your vif's if your Dom0 crashes and you have stale ports around, or at least it isn't if you expect the brctl compatibility layer to do the right thing. I did experiment with seeing what would happen when the port suddenly appeared and if ovs would add it automatically, but this didn’t seem to be the case. I'm not sure if it's something to do with the way the vif interfaces appear or what. Is there some sort of rename operation that happens or are the vif and tap interfaces 'born' with their correct name? If it's the former then that might be why ovs can't match them up. A 'transient' option to ovs to not keep the port in the database would solve that problem, but such a thing doesn't seem to exist.> > Also there is a qemu-ifup script that does some brctl stuff too, and > > also seems to race with the interface rename, at least under the > > Debian Xen 4.1 packages. > > In 4.2 I made it so that Xen emulated devices used the Xen hotplug > scripts instead of the qemu-ifup script, for consistency. >Perfect. qemu-ifup seemed a bit dodgy... it even has (had?) a bug where it said 'echo -c' instead of 'echo -n' to avoid the trailing newline. Thanks James _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Please fix four mail client. It lacks proper attribution and produces too long lines. On Thu, Jan 24, 2013 at 11:48:39AM +0000, James Harper wrote:> > The lack of a cleanup script getting run correctly on network devices > > was something Roger solved with his hotplug rework for xl in 4.2 > > (essentially the script used to be run after the backend was torn down > > in xenstore so it couldn''t get at many of its parameters) > The problem here is that ovs remembers all the ports in its database. You do add-port once and the port is there forever until you remove it again, even over reboots. It''s great for eth0 etc because everything "just works" once ovs is started, but it''s not so great for your vif''s if your Dom0 crashes and you have stale ports around, or at least it isn''t if you expect the brctl compatibility layer to do the right thing.This is no problem as openvswitch does not add new devices, which appears somewhere after the setup on boot, to existing ports. At least my test setup works this way. And my script explicitely removes pre-existing ports.> A ''transient'' option to ovs to not keep the port in the database would solve that problem, but such a thing doesn''t seem to exist.Why don''t wo handle this on your own with openvswitch upstream? Bastian -- Earth -- mother of the most beautiful women in the universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
On Thu, 2013-01-24 at 11:48 +0000, James Harper wrote:> > > but even better would be that you manually create the port outside of > > > xen and the domu would plug into that port. I''m not sure if the > > > port/interface names are long enough to allow this in an intuitive way > > > though (eg to specify grokable port names). > > > > I can never remember the OVS terminology but what you are saying is that > > you want to create ovsbr0 and several named ports (lets say, eth0, web > > and db) where eth0 is a real thing and web and db are "floating" ports > > where there is no corresponding network device. When the vif is created > > it can then be bound to the port? > > > > This means that you can preconfigure the rules for web and db even > > before starting the domain? > > > > Which ovs commands would you use to do this? If it can be done by hand > > then I expect it could also be done by extending the syntax Bastian > > added. > > > > If you are just saying you want the vif to be named "web" then the > > existing vifname stuff (which the script should be applying prior to > > connecting to the bridge) would do the job. > > > > <snip> > > > > The lack of a cleanup script getting run correctly on network devices > > was something Roger solved with his hotplug rework for xl in 4.2 > > (essentially the script used to be run after the backend was torn down > > in xenstore so it couldn''t get at many of its parameters) > > The problem here is that ovs remembers all the ports in its database. > You do add-port once and the port is there forever until you remove it > again, even over reboots. It''s great for eth0 etc because everything > "just works" once ovs is started, but it''s not so great for your vif''s > if your Dom0 crashes and you have stale ports around,I think the start of day networking setup should take care of resetting things to a known good set of ports, which would involve clearing out any stale ones caused by this In the normal non-crashing world the vif script should be removing them on domain shutdown (including on host reboot)> or at least it isn''t if you expect the brctl compatibility layer to > do the right thing.Lets not go there... [...]> Is there some sort of rename operation that happens or are the vif and > tap interfaces ''born'' with their correct name?In 4.2+ they are born with the vifX.Y(-emu) name and renamed to the name specified in the config file (if any) in the vif hotplug script. Ian.