| Message ID | 1395918009.22909.50.camel@kazak.uk.xensource.com |
|---|---|
| State | New |
| Headers | show |
On Thu, Mar 27, 2014 at 11:00 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Thu, 2014-03-20 at 14:02 +0000, Ian Campbell wrote: >> On Thu, 2014-03-20 at 13:32 +0000, Jan Beulich wrote: >> > Which reminds me - didn't you want to rip out xend >> > right away after 4.4 (which would render pointless the patch >> > here)? >> >> I still want to do it before 4.5, this is more of a short term thing >> because people were sending me patches right now. >> >> Step one of the removal is to stop osstest from testing xend, I sent a >> patch for that a week or two ago. > > That patch is now in place in the production osstest. So I propose the > following pull request (since the actual patch is nearly 3M in size, > even the diffstat here is bigger than most patches!). On my list of dependencies for removing xend, I have the following: * 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 - xl support for vnc and vnclisten options with PV guests Have all of these been addressed? -George
On Thu, 2014-03-27 at 11:08 +0000, George Dunlap wrote: > On Thu, Mar 27, 2014 at 11:00 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On my list of dependencies for removing xend, I have the following: > > * xend still in tree (x) > - xl list -l on a dom0-only system Not sure what this was, doesn't sound either hard or critical though. > - xl list -l doesn't contain tty console port I think this was fixed, wasn't it (assuming I understand what it actually means). > - xl Alternate transport support for migration* What is this? > - xl support for vnc and vnclisten options with PV guests Wei fixed this already, in 4.4 even perhaps. > - xl PVSCSI support > - xl PVUSB support Meh. Any of the above which are still issues can still be considered to become blockers for 4.5, that doesn't necessarily imply they should block removal of xend. I think at some point we just have to rip the plaster off and I think that time is now. Doing so will provide additional impetus to actually fix any remaining issues, as it stands things have stagnated because people just think "oh, it's ok xend is still available". Ian.
On Thu, Mar 27, George Dunlap wrote:
> - xl PVSCSI support
I have some incomplete patch, which supports at least vscsi=[] in domU.cfg.
It will certainly take N iterations until it can get into 4.5.
I think, based on this change, PVUSB shouldnt be hard. But then, no idea
what PVUSB actually requires.
Olaf
On Thu, Mar 27, 2014 at 11:18 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Thu, 2014-03-27 at 11:08 +0000, George Dunlap wrote: >> On Thu, Mar 27, 2014 at 11:00 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> On my list of dependencies for removing xend, I have the following: >> >> * xend still in tree (x) >> - xl list -l on a dom0-only system > > Not sure what this was, doesn't sound either hard or critical though. This is from an e-mail from Konrad, msd-id <20130904140414.GA3188@phenom.dumpdata.com> . He said: - No status in xl list -l when only dom0 is present. I'm not sure exactly what that means. On my system, "xl list -l" on a system with no domUs running produces an empty, but valid, array -- "[ ]". (With some extra whitespace.) Looking further in the thread, it looks like Wei took a look at this, and that at the moment "xl list -l" depends on reading the config file from disk, which is a bigger architectural issue that needs to be resolved. You posted a PoC patch that you had started, but obviously it hasn't been upstreamed yet. So this should probably actually be "xl list -l contains no information for dom0". > >> - xl list -l doesn't contain tty console port > > I think this was fixed, wasn't it (assuming I understand what it > actually means). > >> - xl Alternate transport support for migration* > > What is this? From another section of my to-do list: * xl migrate transport improvements owner: None > See discussion here: http://bugs.xenproject.org/xen/bug/19 - Option to connect over a plain TCP socket rather than ssh - xl-migrate-recieve suitable for running in inetd - option for above to redirect log output somewhere useful - Documentation for setting up alternate transports OTOH, as a result of that discussion, it became clear that: 1. xl did have the ability to use socat / ssl; the command-line arguments to do that are a bit wonky, however, and the documentation is far from clear 2. The system envisioned was terribly insecure. Receiving a domain at the moment allows the sender trivial access to all files on the system (including your root disk); receiving domains without authenticating the sender means implicit trust of the entire control network. So perhaps this wouldn't be a blocker. > >> - xl support for vnc and vnclisten options with PV guests > > Wei fixed this already, in 4.4 even perhaps. > >> - xl PVSCSI support >> - xl PVUSB support > > Meh. > > Any of the above which are still issues can still be considered to > become blockers for 4.5, that doesn't necessarily imply they should > block removal of xend. > > I think at some point we just have to rip the plaster off and I think > that time is now. Doing so will provide additional impetus to actually > fix any remaining issues, as it stands things have stagnated because > people just think "oh, it's ok xend is still available". FWIW, back in September when we had this discussion, Olaf and Jan both said they still had customers using PVSCSI. I responded: "...at some point, if it's not important enough for someone to implement, it's not important enough to keep supporting." To which Jan replied, "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." And I think he has a point. So what about the following dependency list? * xend still in tree [blocker] - xl list -l doesn't contain information about dom0 - xl PVSCSI support [nice-to-have] - xl Alternate transport support for migration* - xl PVUSB support [fixed] - xl list -l doesn't contain tty console port - xl support for vnc and vnclisten options with PV guests -George
On Thu, 2014-03-27 at 12:03 +0000, George Dunlap wrote: > On Thu, Mar 27, 2014 at 11:18 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > On Thu, 2014-03-27 at 11:08 +0000, George Dunlap wrote: > >> On Thu, Mar 27, 2014 at 11:00 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > >> On my list of dependencies for removing xend, I have the following: > >> > >> * xend still in tree (x) > >> - xl list -l on a dom0-only system > > > > Not sure what this was, doesn't sound either hard or critical though. > > This is from an e-mail from Konrad, msd-id > <20130904140414.GA3188@phenom.dumpdata.com> . He said: > > - No status in xl list -l when only dom0 is present. > > I'm not sure exactly what that means. On my system, "xl list -l" on a > system with no domUs running produces an empty, but valid, array -- "[ > ]". (With some extra whitespace.) > > Looking further in the thread, it looks like Wei took a look at this, > and that at the moment "xl list -l" depends on reading the config file > from disk, which is a bigger architectural issue that needs to be > resolved. You posted a PoC patch that you had started, but obviously > it hasn't been upstreamed yet. > > So this should probably actually be "xl list -l contains no > information for dom0". I think Wei was going to work on this again shortly IIRC from our discussion last week. > >> - xl list -l doesn't contain tty console port > > > > I think this was fixed, wasn't it (assuming I understand what it > > actually means). > > > >> - xl Alternate transport support for migration* > > > > What is this? > > From another section of my to-do list: > > * xl migrate transport improvements > owner: None > > See discussion here: http://bugs.xenproject.org/xen/bug/19 > - Option to connect over a plain TCP socket rather than ssh > - xl-migrate-recieve suitable for running in inetd > - option for above to redirect log output somewhere useful > - Documentation for setting up alternate transports http://bugs.xenproject.org/xen/bug/18 might be something of a duplicate of this. It's not clear what this has to do with xend though, it looks like a wishlist feature request for xl to me, but one that has no relationship with xend. > > OTOH, as a result of that discussion, it became clear that: > 1. xl did have the ability to use socat / ssl; the command-line > arguments to do that are a bit wonky, however, and the documentation > is far from clear > 2. The system envisioned was terribly insecure. Receiving a domain at > the moment allows the sender trivial access to all files on the system > (including your root disk); receiving domains without authenticating > the sender means implicit trust of the entire control network. > > So perhaps this wouldn't be a blocker. Indeed, not even close IMHO. > >> - xl support for vnc and vnclisten options with PV guests > > > > Wei fixed this already, in 4.4 even perhaps. > > > >> - xl PVSCSI support > >> - xl PVUSB support > > > > Meh. > > > > Any of the above which are still issues can still be considered to > > become blockers for 4.5, that doesn't necessarily imply they should > > block removal of xend. > > > > I think at some point we just have to rip the plaster off and I think > > that time is now. Doing so will provide additional impetus to actually > > fix any remaining issues, as it stands things have stagnated because > > people just think "oh, it's ok xend is still available". > > FWIW, back in September when we had this discussion, Olaf and Jan both > said they still had customers using PVSCSI. I responded: > > "...at some point, if it's not important enough for someone to > implement, it's not important enough to keep supporting." > > To which Jan replied, "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." > > And I think he has a point. True. It looks like Olaf has this in hand though. > So what about the following dependency list? > > * xend still in tree > [blocker] NB: I would consider these blockers for 4.5, *not* blockers for removing xend. > - xl list -l doesn't contain information about dom0 > - xl PVSCSI support > [nice-to-have] > - xl Alternate transport support for migration* > - xl PVUSB support > [fixed] > - xl list -l doesn't contain tty console port > - xl support for vnc and vnclisten options with PV guests > > -George
On Thu, Mar 27, 2014 at 12:01 PM, Olaf Hering <olaf@aepfle.de> wrote: > On Thu, Mar 27, George Dunlap wrote: > >> - xl PVSCSI support > > I have some incomplete patch, which supports at least vscsi=[] in domU.cfg. > It will certainly take N iterations until it can get into 4.5. > > I think, based on this change, PVUSB shouldnt be hard. But then, no idea > what PVUSB actually requires. I think the difficult part of PVUSB was actually getting the libxl interface right. Back during 4.3 development, I had begun work on a proper libxl usb interface for emulated devices, which would have trivially been able to be extended to include PVUSB devices as well. Getting the plumbing for qemu working was the space of a week; we then spent three months haggling about the interface, and in the end I had to drop it for the feature freeze. I never got a chance to pick it back up again for 4.4. I took a brief look at what would be necesseary to do the PVUSB plumbing, and it looks like it should be equally as simple. If you could pick up that patch series for 4.5, I'd really appreciate it. :-) -George
On Thu, 2014-03-27 at 13:01 +0100, Olaf Hering wrote: > On Thu, Mar 27, George Dunlap wrote: > > > - xl PVSCSI support > > I have some incomplete patch, which supports at least vscsi=[] in domU.cfg. > It will certainly take N iterations until it can get into 4.5. That's great, looking forward to it. Ian.
On Thu, Mar 27, 2014 at 12:12 PM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Thu, 2014-03-27 at 12:03 +0000, George Dunlap wrote: >> On Thu, Mar 27, 2014 at 11:18 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> > On Thu, 2014-03-27 at 11:08 +0000, George Dunlap wrote: >> >> On Thu, Mar 27, 2014 at 11:00 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: >> >> On my list of dependencies for removing xend, I have the following: >> >> >> >> * xend still in tree (x) >> >> - xl list -l on a dom0-only system >> > >> > Not sure what this was, doesn't sound either hard or critical though. >> >> This is from an e-mail from Konrad, msd-id >> <20130904140414.GA3188@phenom.dumpdata.com> . He said: >> >> - No status in xl list -l when only dom0 is present. >> >> I'm not sure exactly what that means. On my system, "xl list -l" on a >> system with no domUs running produces an empty, but valid, array -- "[ >> ]". (With some extra whitespace.) >> >> Looking further in the thread, it looks like Wei took a look at this, >> and that at the moment "xl list -l" depends on reading the config file >> from disk, which is a bigger architectural issue that needs to be >> resolved. You posted a PoC patch that you had started, but obviously >> it hasn't been upstreamed yet. >> >> So this should probably actually be "xl list -l contains no >> information for dom0". > > I think Wei was going to work on this again shortly IIRC from our > discussion last week. > >> >> - xl list -l doesn't contain tty console port >> > >> > I think this was fixed, wasn't it (assuming I understand what it >> > actually means). >> > >> >> - xl Alternate transport support for migration* >> > >> > What is this? >> >> From another section of my to-do list: >> >> * xl migrate transport improvements >> owner: None >> > See discussion here: http://bugs.xenproject.org/xen/bug/19 >> - Option to connect over a plain TCP socket rather than ssh >> - xl-migrate-recieve suitable for running in inetd >> - option for above to redirect log output somewhere useful >> - Documentation for setting up alternate transports > > http://bugs.xenproject.org/xen/bug/18 might be something of a duplicate > of this. > > It's not clear what this has to do with xend though, it looks like a > wishlist feature request for xl to me, but one that has no relationship > with xend. > >> >> OTOH, as a result of that discussion, it became clear that: >> 1. xl did have the ability to use socat / ssl; the command-line >> arguments to do that are a bit wonky, however, and the documentation >> is far from clear >> 2. The system envisioned was terribly insecure. Receiving a domain at >> the moment allows the sender trivial access to all files on the system >> (including your root disk); receiving domains without authenticating >> the sender means implicit trust of the entire control network. >> >> So perhaps this wouldn't be a blocker. > > Indeed, not even close IMHO. > >> >> - xl support for vnc and vnclisten options with PV guests >> > >> > Wei fixed this already, in 4.4 even perhaps. >> > >> >> - xl PVSCSI support >> >> - xl PVUSB support >> > >> > Meh. >> > >> > Any of the above which are still issues can still be considered to >> > become blockers for 4.5, that doesn't necessarily imply they should >> > block removal of xend. >> > >> > I think at some point we just have to rip the plaster off and I think >> > that time is now. Doing so will provide additional impetus to actually >> > fix any remaining issues, as it stands things have stagnated because >> > people just think "oh, it's ok xend is still available". >> >> FWIW, back in September when we had this discussion, Olaf and Jan both >> said they still had customers using PVSCSI. I responded: >> >> "...at some point, if it's not important enough for someone to >> implement, it's not important enough to keep supporting." >> >> To which Jan replied, "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." >> >> And I think he has a point. > > True. > > It looks like Olaf has this in hand though. > >> So what about the following dependency list? >> >> * xend still in tree >> [blocker] > > NB: I would consider these blockers for 4.5, *not* blockers for removing > xend. Blockers for xl for 4.5 if re remove xend. :-) If we're OK to accept those two as blockers for 4.5, then this pull has my ack. -George
On Thu, 2014-03-27 at 12:15 +0000, George Dunlap wrote: > >> * xend still in tree > >> [blocker] > > > > NB: I would consider these blockers for 4.5, *not* blockers for removing > > xend. > > Blockers for xl for 4.5 if re remove xend. :-) If they are important then why aren't they blockers regardless of whether xend is in or out? :-P > If we're OK to accept those two as blockers for 4.5, then this pull > has my ack. Thanks. Ian.
On Thu, Mar 27, Ian Campbell wrote:
> That's great, looking forward to it.
If anyone is curious:
https://github.com/olafhering/xen/compare/RELEASE-4.4.0...local-fate316613-pvscsi-staging-4.4
Olaf
On Thu, Mar 27, 2014 at 11:08:47AM +0000, George Dunlap wrote: > On Thu, Mar 27, 2014 at 11:00 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > On Thu, 2014-03-20 at 14:02 +0000, Ian Campbell wrote: > >> On Thu, 2014-03-20 at 13:32 +0000, Jan Beulich wrote: > >> > Which reminds me - didn't you want to rip out xend > >> > right away after 4.4 (which would render pointless the patch > >> > here)? > >> > >> I still want to do it before 4.5, this is more of a short term thing > >> because people were sending me patches right now. > >> > >> Step one of the removal is to stop osstest from testing xend, I sent a > >> patch for that a week or two ago. > > > > That patch is now in place in the production osstest. So I propose the > > following pull request (since the actual patch is nearly 3M in size, > > even the diffstat here is bigger than most patches!). > > On my list of dependencies for removing xend, I have the following: > > * 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 > - xl support for vnc and vnclisten options with PV guests I don't really like adding more of 'xend has this' to the list, but Jan discovered that 'xend' was using the group assigment hypercall for PCI devices while 'xl' is not doing that. That hypercall has certain benefits - you can use it to figure out if all of the PCI devices underneath a bridge are assigned to one guest and not shared amongts the guests. > > Have all of these been addressed? > > -George
On Fri, 2014-03-28 at 13:09 -0400, Konrad Rzeszutek Wilk wrote: > On Thu, Mar 27, 2014 at 11:08:47AM +0000, George Dunlap wrote: > > On Thu, Mar 27, 2014 at 11:00 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > > On Thu, 2014-03-20 at 14:02 +0000, Ian Campbell wrote: > > >> On Thu, 2014-03-20 at 13:32 +0000, Jan Beulich wrote: > > >> > Which reminds me - didn't you want to rip out xend > > >> > right away after 4.4 (which would render pointless the patch > > >> > here)? > > >> > > >> I still want to do it before 4.5, this is more of a short term thing > > >> because people were sending me patches right now. > > >> > > >> Step one of the removal is to stop osstest from testing xend, I sent a > > >> patch for that a week or two ago. > > > > > > That patch is now in place in the production osstest. So I propose the > > > following pull request (since the actual patch is nearly 3M in size, > > > even the diffstat here is bigger than most patches!). > > > > On my list of dependencies for removing xend, I have the following: > > > > * 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 > > - xl support for vnc and vnclisten options with PV guests > > I don't really like adding more of 'xend has this' to the list, that's ok. > but > Jan discovered that 'xend' was using the group assigment hypercall for > PCI devices while 'xl' is not doing that. > > That hypercall has certain benefits - you can use it to figure out if > all of the PCI devices underneath a bridge are assigned to one > guest and not shared amongts the guests. I think this is at the wishlist rather than blocker end of the spectrum, and probably falls under the general category of "xl pci passthrough has sharp edges"? Does that sound right? Ian.
On Mon, Mar 31, 2014 at 12:18:53PM +0100, Ian Campbell wrote: > On Fri, 2014-03-28 at 13:09 -0400, Konrad Rzeszutek Wilk wrote: [...] > > I don't really like adding more of 'xend has this' to the list, > > that's ok. > > > but > > Jan discovered that 'xend' was using the group assigment hypercall for > > PCI devices while 'xl' is not doing that. > > > > That hypercall has certain benefits - you can use it to figure out if > > all of the PCI devices underneath a bridge are assigned to one > > guest and not shared amongts the guests. > > I think this is at the wishlist rather than blocker end of the spectrum, > and probably falls under the general category of "xl pci passthrough has > sharp edges"? Does that sound right? Probably. There are other areas that are mightily sharp as well. They might not be blockers for the project to remove Xend code from the tree, but they'll be blockers for adoption of newer releases that don't include Xend. Another for the list is AER handling. That's only implemented in Xend now [1]. --msw [1] http://wiki.xenproject.org/wiki/GSoc_2014#Improve_PCIe_Advanced_Error_Reporting_.28AER.29_handling_for_passed-through_devices
On 03/31/2014 12:56 PM, Matt Wilson wrote: > On Mon, Mar 31, 2014 at 12:18:53PM +0100, Ian Campbell wrote: >> On Fri, 2014-03-28 at 13:09 -0400, Konrad Rzeszutek Wilk wrote: > [...] > >>> I don't really like adding more of 'xend has this' to the list, >> that's ok. >> >>> but >>> Jan discovered that 'xend' was using the group assigment hypercall for >>> PCI devices while 'xl' is not doing that. >>> >>> That hypercall has certain benefits - you can use it to figure out if >>> all of the PCI devices underneath a bridge are assigned to one >>> guest and not shared amongts the guests. >> I think this is at the wishlist rather than blocker end of the spectrum, >> and probably falls under the general category of "xl pci passthrough has >> sharp edges"? Does that sound right? > Probably. There are other areas that are mightily sharp as well. They > might not be blockers for the project to remove Xend code from the > tree, but they'll be blockers for adoption of newer releases that > don't include Xend. > > Another for the list is AER handling. That's only implemented in Xend > now [1]. Well, given that AER was not mentioned 6 months ago when this came up, it seems that keeping xend in tree is a blocker for people actually asking for things to be added to xl. I think as Ian said, it's time to "tear off the plaster" (plaster == band-aid, for those in the US). If that means people don't migrate to 4.5, but actually report their requirements so that they can move to 4.6, it will be worth it in the long run. -George
On Mon, Mar 31, 2014 at 01:03:25PM +0100, George Dunlap wrote: > On 03/31/2014 12:56 PM, Matt Wilson wrote: > >On Mon, Mar 31, 2014 at 12:18:53PM +0100, Ian Campbell wrote: > >>On Fri, 2014-03-28 at 13:09 -0400, Konrad Rzeszutek Wilk wrote: > >[...] > > > >>>I don't really like adding more of 'xend has this' to the list, > >>that's ok. > >> > >>>but > >>>Jan discovered that 'xend' was using the group assigment hypercall for > >>>PCI devices while 'xl' is not doing that. > >>>That hypercall has certain benefits - you can use it to figure out if > >>>all of the PCI devices underneath a bridge are assigned to one > >>>guest and not shared amongts the guests. > >>I think this is at the wishlist rather than blocker end of the spectrum, > >>and probably falls under the general category of "xl pci passthrough has > >>sharp edges"? Does that sound right? > >Probably. There are other areas that are mightily sharp as well. They > >might not be blockers for the project to remove Xend code from the > >tree, but they'll be blockers for adoption of newer releases that > >don't include Xend. > > > >Another for the list is AER handling. That's only implemented in Xend > >now [1]. > > Well, given that AER was not mentioned 6 months ago when this came > up, it seems that keeping xend in tree is a blocker for people > actually asking for things to be added to xl. Actually, we discussed it on the phone [1]. Unfortunately I didn't complete my assigned action item to post on the list. > I think as Ian said, it's time to "tear off the plaster" (plaster == > band-aid, for those in the US). If that means people don't migrate > to 4.5, but actually report their requirements so that they can move > to 4.6, it will be worth it in the long run. I agree. --msw [1] http://wiki.xenproject.org/wiki/TCT_Meeting/November_2013_Minutes#Review_Action_items
On 03/28/2014 05:09 PM, Konrad Rzeszutek Wilk wrote: > On Thu, Mar 27, 2014 at 11:08:47AM +0000, George Dunlap wrote: >> On Thu, Mar 27, 2014 at 11:00 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: >>> On Thu, 2014-03-20 at 14:02 +0000, Ian Campbell wrote: >>>> On Thu, 2014-03-20 at 13:32 +0000, Jan Beulich wrote: >>>>> Which reminds me - didn't you want to rip out xend >>>>> right away after 4.4 (which would render pointless the patch >>>>> here)? >>>> I still want to do it before 4.5, this is more of a short term thing >>>> because people were sending me patches right now. >>>> >>>> Step one of the removal is to stop osstest from testing xend, I sent a >>>> patch for that a week or two ago. >>> That patch is now in place in the production osstest. So I propose the >>> following pull request (since the actual patch is nearly 3M in size, >>> even the diffstat here is bigger than most patches!). >> On my list of dependencies for removing xend, I have the following: >> >> * 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 >> - xl support for vnc and vnclisten options with PV guests > I don't really like adding more of 'xend has this' to the list, but > Jan discovered that 'xend' was using the group assigment hypercall for > PCI devices while 'xl' is not doing that. > > That hypercall has certain benefits - you can use it to figure out if > all of the PCI devices underneath a bridge are assigned to one > guest and not shared amongts the guests. I'm copying this into my roadmap list (to hand on to the next release coordinator, whoever he or she may be). Are there any references you can give for this? -George
On 03/31/2014 01:16 PM, Matt Wilson wrote: > On Mon, Mar 31, 2014 at 01:03:25PM +0100, George Dunlap wrote: >> On 03/31/2014 12:56 PM, Matt Wilson wrote: >>> On Mon, Mar 31, 2014 at 12:18:53PM +0100, Ian Campbell wrote: >>>> On Fri, 2014-03-28 at 13:09 -0400, Konrad Rzeszutek Wilk wrote: >>> [...] >>> >>>>> I don't really like adding more of 'xend has this' to the list, >>>> that's ok. >>>> >>>>> but >>>>> Jan discovered that 'xend' was using the group assigment hypercall for >>>>> PCI devices while 'xl' is not doing that. >>>>> That hypercall has certain benefits - you can use it to figure out if >>>>> all of the PCI devices underneath a bridge are assigned to one >>>>> guest and not shared amongts the guests. >>>> I think this is at the wishlist rather than blocker end of the spectrum, >>>> and probably falls under the general category of "xl pci passthrough has >>>> sharp edges"? Does that sound right? >>> Probably. There are other areas that are mightily sharp as well. They >>> might not be blockers for the project to remove Xend code from the >>> tree, but they'll be blockers for adoption of newer releases that >>> don't include Xend. >>> >>> Another for the list is AER handling. That's only implemented in Xend >>> now [1]. >> Well, given that AER was not mentioned 6 months ago when this came >> up, it seems that keeping xend in tree is a blocker for people >> actually asking for things to be added to xl. > Actually, we discussed it on the phone [1]. Unfortunately I didn't > complete my assigned action item to post on the list. Ah, right. :-) In any case, the relevant question isn't so much "Is this a blocker for xend removal", so much as "Is xl support for this a blocker for the 4.5 release?" -George
Il 31/03/2014 15:17, George Dunlap ha scritto: > On 03/31/2014 01:16 PM, Matt Wilson wrote: >> On Mon, Mar 31, 2014 at 01:03:25PM +0100, George Dunlap wrote: >>> On 03/31/2014 12:56 PM, Matt Wilson wrote: >>>> On Mon, Mar 31, 2014 at 12:18:53PM +0100, Ian Campbell wrote: >>>>> On Fri, 2014-03-28 at 13:09 -0400, Konrad Rzeszutek Wilk wrote: >>>> [...] >>>> >>>>>> I don't really like adding more of 'xend has this' to the list, >>>>> that's ok. >>>>> >>>>>> but >>>>>> Jan discovered that 'xend' was using the group assigment >>>>>> hypercall for >>>>>> PCI devices while 'xl' is not doing that. >>>>>> That hypercall has certain benefits - you can use it to figure >>>>>> out if >>>>>> all of the PCI devices underneath a bridge are assigned to one >>>>>> guest and not shared amongts the guests. >>>>> I think this is at the wishlist rather than blocker end of the >>>>> spectrum, >>>>> and probably falls under the general category of "xl pci >>>>> passthrough has >>>>> sharp edges"? Does that sound right? >>>> Probably. There are other areas that are mightily sharp as well. They >>>> might not be blockers for the project to remove Xend code from the >>>> tree, but they'll be blockers for adoption of newer releases that >>>> don't include Xend. >>>> >>>> Another for the list is AER handling. That's only implemented in Xend >>>> now [1]. >>> Well, given that AER was not mentioned 6 months ago when this came >>> up, it seems that keeping xend in tree is a blocker for people >>> actually asking for things to be added to xl. >> Actually, we discussed it on the phone [1]. Unfortunately I didn't >> complete my assigned action item to post on the list. > > Ah, right. :-) > > In any case, the relevant question isn't so much "Is this a blocker > for xend removal", so much as "Is xl support for this a blocker for > the 4.5 release?" There is another thing to do in libxl to solve the problem of network not working after restore. Actually the only workaround is to assign fixed mac address in xl cfg. I reported this during 4.2 development but it was too late to "fix" it if I remember good. Thanks for any reply. > > -George > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel
On 03/31/2014 03:05 PM, Fabio Fantoni wrote: > Il 31/03/2014 15:17, George Dunlap ha scritto: >> On 03/31/2014 01:16 PM, Matt Wilson wrote: >>> On Mon, Mar 31, 2014 at 01:03:25PM +0100, George Dunlap wrote: >>>> On 03/31/2014 12:56 PM, Matt Wilson wrote: >>>>> On Mon, Mar 31, 2014 at 12:18:53PM +0100, Ian Campbell wrote: >>>>>> On Fri, 2014-03-28 at 13:09 -0400, Konrad Rzeszutek Wilk wrote: >>>>> [...] >>>>> >>>>>>> I don't really like adding more of 'xend has this' to the list, >>>>>> that's ok. >>>>>> >>>>>>> but >>>>>>> Jan discovered that 'xend' was using the group assigment >>>>>>> hypercall for >>>>>>> PCI devices while 'xl' is not doing that. >>>>>>> That hypercall has certain benefits - you can use it to figure >>>>>>> out if >>>>>>> all of the PCI devices underneath a bridge are assigned to one >>>>>>> guest and not shared amongts the guests. >>>>>> I think this is at the wishlist rather than blocker end of the >>>>>> spectrum, >>>>>> and probably falls under the general category of "xl pci >>>>>> passthrough has >>>>>> sharp edges"? Does that sound right? >>>>> Probably. There are other areas that are mightily sharp as well. They >>>>> might not be blockers for the project to remove Xend code from the >>>>> tree, but they'll be blockers for adoption of newer releases that >>>>> don't include Xend. >>>>> >>>>> Another for the list is AER handling. That's only implemented in Xend >>>>> now [1]. >>>> Well, given that AER was not mentioned 6 months ago when this came >>>> up, it seems that keeping xend in tree is a blocker for people >>>> actually asking for things to be added to xl. >>> Actually, we discussed it on the phone [1]. Unfortunately I didn't >>> complete my assigned action item to post on the list. >> >> Ah, right. :-) >> >> In any case, the relevant question isn't so much "Is this a blocker >> for xend removal", so much as "Is xl support for this a blocker for >> the 4.5 release?" > > There is another thing to do in libxl to solve the problem of network > not working after restore. > Actually the only workaround is to assign fixed mac address in xl cfg. > I reported this during 4.2 development but it was too late to "fix" it > if I remember good. > > Thanks for any reply. Yes, this is on our list, and I think it should be a blocker for 4.5. For future reference, please don't change the subject -- this thread is about xend / xl functionality, not general 4.5 planning. (Hopefully those e-mails should start soon.) -George
Monday, March 31, 2014, 4:08:10 PM, you wrote: > On 03/31/2014 03:05 PM, Fabio Fantoni wrote: >> Il 31/03/2014 15:17, George Dunlap ha scritto: >>> On 03/31/2014 01:16 PM, Matt Wilson wrote: >>>> On Mon, Mar 31, 2014 at 01:03:25PM +0100, George Dunlap wrote: >>>>> On 03/31/2014 12:56 PM, Matt Wilson wrote: >>>>>> On Mon, Mar 31, 2014 at 12:18:53PM +0100, Ian Campbell wrote: >>>>>>> On Fri, 2014-03-28 at 13:09 -0400, Konrad Rzeszutek Wilk wrote: >>>>>> [...] >>>>>> >>>>>>>> I don't really like adding more of 'xend has this' to the list, >>>>>>> that's ok. >>>>>>> >>>>>>>> but >>>>>>>> Jan discovered that 'xend' was using the group assigment >>>>>>>> hypercall for >>>>>>>> PCI devices while 'xl' is not doing that. >>>>>>>> That hypercall has certain benefits - you can use it to figure >>>>>>>> out if >>>>>>>> all of the PCI devices underneath a bridge are assigned to one >>>>>>>> guest and not shared amongts the guests. >>>>>>> I think this is at the wishlist rather than blocker end of the >>>>>>> spectrum, >>>>>>> and probably falls under the general category of "xl pci >>>>>>> passthrough has >>>>>>> sharp edges"? Does that sound right? >>>>>> Probably. There are other areas that are mightily sharp as well. They >>>>>> might not be blockers for the project to remove Xend code from the >>>>>> tree, but they'll be blockers for adoption of newer releases that >>>>>> don't include Xend. >>>>>> >>>>>> Another for the list is AER handling. That's only implemented in Xend >>>>>> now [1]. >>>>> Well, given that AER was not mentioned 6 months ago when this came >>>>> up, it seems that keeping xend in tree is a blocker for people >>>>> actually asking for things to be added to xl. >>>> Actually, we discussed it on the phone [1]. Unfortunately I didn't >>>> complete my assigned action item to post on the list. >>> >>> Ah, right. :-) >>> >>> In any case, the relevant question isn't so much "Is this a blocker >>> for xend removal", so much as "Is xl support for this a blocker for >>> the 4.5 release?" >> >> There is another thing to do in libxl to solve the problem of network >> not working after restore. >> Actually the only workaround is to assign fixed mac address in xl cfg. >> I reported this during 4.2 development but it was too late to "fix" it >> if I remember good. >> >> Thanks for any reply. > Yes, this is on our list, and I think it should be a blocker for 4.5. > For future reference, please don't change the subject -- this thread is > about xend / xl functionality, not general 4.5 planning. (Hopefully > those e-mails should start soon.) Since some xend -> xl items could also be qemu related, what is the general opinion about qemu-trad -> qemu-(xen|upstream) for these items ? Should they also be implemented for qemu traditional or only for qemu-(xen|upstream) ? -- Sander > -George
On Mon, Mar 31, 2014 at 02:13:31PM +0100, George Dunlap wrote: > On 03/28/2014 05:09 PM, Konrad Rzeszutek Wilk wrote: > >On Thu, Mar 27, 2014 at 11:08:47AM +0000, George Dunlap wrote: > >>On Thu, Mar 27, 2014 at 11:00 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > >>>On Thu, 2014-03-20 at 14:02 +0000, Ian Campbell wrote: > >>>>On Thu, 2014-03-20 at 13:32 +0000, Jan Beulich wrote: > >>>>> Which reminds me - didn't you want to rip out xend > >>>>>right away after 4.4 (which would render pointless the patch > >>>>>here)? > >>>>I still want to do it before 4.5, this is more of a short term thing > >>>>because people were sending me patches right now. > >>>> > >>>>Step one of the removal is to stop osstest from testing xend, I sent a > >>>>patch for that a week or two ago. > >>>That patch is now in place in the production osstest. So I propose the > >>>following pull request (since the actual patch is nearly 3M in size, > >>>even the diffstat here is bigger than most patches!). > >>On my list of dependencies for removing xend, I have the following: > >> > >>* 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 > >> - xl support for vnc and vnclisten options with PV guests > >I don't really like adding more of 'xend has this' to the list, but > >Jan discovered that 'xend' was using the group assigment hypercall for > >PCI devices while 'xl' is not doing that. > >That hypercall has certain benefits - you can use it to figure out if > >all of the PCI devices underneath a bridge are assigned to one > >guest and not shared amongts the guests. > > I'm copying this into my roadmap list (to hand on to the next > release coordinator, whoever he or she may be). Are there any > references you can give for this? It kind of started with this thread: http://lists.xen.org/archives/html/xen-devel/2014-03/msg01053.html And then Jan clued me in (http://lists.xen.org/archives/html/xen-devel/2014-03/msg01101.html) and that we could use this group assigment as a way to fix this problem. That is since each PCI bridge and its devices underneath would have a group id - you just assign it that group and the VT-d/AMD-VI would go through and setup contexts for all possible BDFs underneath. > > -George
On Mon, Mar 31, 2014 at 12:18:53PM +0100, Ian Campbell wrote: > On Fri, 2014-03-28 at 13:09 -0400, Konrad Rzeszutek Wilk wrote: > > On Thu, Mar 27, 2014 at 11:08:47AM +0000, George Dunlap wrote: > > > On Thu, Mar 27, 2014 at 11:00 AM, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > > > On Thu, 2014-03-20 at 14:02 +0000, Ian Campbell wrote: > > > >> On Thu, 2014-03-20 at 13:32 +0000, Jan Beulich wrote: > > > >> > Which reminds me - didn't you want to rip out xend > > > >> > right away after 4.4 (which would render pointless the patch > > > >> > here)? > > > >> > > > >> I still want to do it before 4.5, this is more of a short term thing > > > >> because people were sending me patches right now. > > > >> > > > >> Step one of the removal is to stop osstest from testing xend, I sent a > > > >> patch for that a week or two ago. > > > > > > > > That patch is now in place in the production osstest. So I propose the > > > > following pull request (since the actual patch is nearly 3M in size, > > > > even the diffstat here is bigger than most patches!). > > > > > > On my list of dependencies for removing xend, I have the following: > > > > > > * 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 > > > - xl support for vnc and vnclisten options with PV guests > > > > I don't really like adding more of 'xend has this' to the list, > > that's ok. > > > but > > Jan discovered that 'xend' was using the group assigment hypercall for > > PCI devices while 'xl' is not doing that. > > > > That hypercall has certain benefits - you can use it to figure out if > > all of the PCI devices underneath a bridge are assigned to one > > guest and not shared amongts the guests. > > I think this is at the wishlist rather than blocker end of the spectrum, > and probably falls under the general category of "xl pci passthrough has > sharp edges"? Does that sound right? Yes, they are hazardous to ones health. > > Ian. >