xen@bugs.xenproject.org
2013-Oct-09 12:15 UTC
Processed: Re: [HVM} xen_platform_pci=0 doesn''t prevent platform device creation and disk and nic take over by PV drivers.
Processing commands for xen@bugs.xenproject.org:> create ^Created new bug #20 rooted at `<1571692646.20131009000945@eikelenboom.it>'' Title: `Re: [HVM} xen_platform_pci=0 doesn''t prevent platform device creation and disk and nic take over by PV drivers.''> title it xen_platform_pci=0 doesn''t work with qemu-xenSet title for #20 to `xen_platform_pci=0 doesn''t work with qemu-xen''> owner it Anthony Perard <anthony.perard@citrix.com>Change owner for #20 to `Anthony Perard <anthony.perard@citrix.com>''> thanksFinished processing. Modified/created Bugs: - 20: http://bugs.xenproject.org/xen/bug/20 (new) --- Xen Hypervisor Bug Tracker See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on reporting bugs Contact xen-bugs-owner@bugs.xenproject.org with any infrastructure issues
Ian Campbell
2013-Oct-11 15:04 UTC
Re: Processed: Re: [HVM} xen_platform_pci=0 doesn''t prevent platform device creation and disk and nic take over by PV drivers.
graft 20 ! prune 20 <1043931136.20131009144924@eikelenboom.it> thanks On Wed, 2013-10-09 at 13:15 +0100, xen@bugs.xenproject.org wrote:> Processing commands for xen@bugs.xenproject.org:[...]> Modified/created Bugs: > - 20: http://bugs.xenproject.org/xen/bug/20 (new)Hrm, this bug is missing the useful content because Sander mailed Stefano and I privately and I didn''t notice. The original message was simply:> While trying to get to the bottom of my passthrough problem with the rom bar, > i noticed that specifiying "xen_platform_pci=0" in the config file does not prevent > the platform device to appear in my HVM guest and consequently the disk and nic are taken over. > > Running latest xen-unstable, together with upstream qemu and upstream seabios.
Sander Eikelenboom
2013-Oct-11 15:22 UTC
Re: Processed: Re: [HVM} xen_platform_pci=0 doesn''t prevent platform device creation and disk and nic take over by PV drivers.
Friday, October 11, 2013, 5:04:04 PM, you wrote:> graft 20 ! > prune 20 <1043931136.20131009144924@eikelenboom.it> > thanks> On Wed, 2013-10-09 at 13:15 +0100, xen@bugs.xenproject.org wrote: >> Processing commands for xen@bugs.xenproject.org: > [...] >> Modified/created Bugs: >> - 20: http://bugs.xenproject.org/xen/bug/20 (new)> Hrm, this bug is missing the useful content because Sander mailed > Stefano and I privately and I didn''t notice.Sorry for that, it seemed xen-devel got dropped somewhere along that thread and i didn''t notice. Perhaps relevant if any one is going to take a look at this (since it will crash on boot for a newer kernel anyhow):> Tried with xen_platform_pci=0 with qemu-xen-traditional and that makes a linux 3.12-rc3 kernel crash on boot > unfortunatly the strack trace runs from the small vnc screen here :S > It also crashes on kernel 3.9.2 and 3.9.0-rc3, and 3.8.13 > but not on the debian supplied 3.2.0 and 3.8.0-rc2. > So the cause seems to be introduced or backported to the 3.8 series somewhere.> The original message was simply: >> While trying to get to the bottom of my passthrough problem with the rom bar, >> i noticed that specifiying "xen_platform_pci=0" in the config file does not prevent >> the platform device to appear in my HVM guest and consequently the disk and nic are taken over. >> >> Running latest xen-unstable, together with upstream qemu and upstream seabios.
xen@bugs.xenproject.org
2013-Oct-11 15:45 UTC
Processed: Re: Processed: Re: [HVM} xen_platform_pci=0 doesn''t prevent platform device creation and disk and nic take over by PV drivers.
Processing commands for xen@bugs.xenproject.org:> graft 20 <1381503844.24708.46.camel@kazak.uk.xensource.com>Graft `<1381503844.24708.46.camel@kazak.uk.xensource.com>'' onto #20> prune 20 <1043931136.20131009144924@eikelenboom.it>Prune `<1043931136.20131009144924@eikelenboom.it>'' from #20> thanksFinished processing. Modified/created Bugs: - 20: http://bugs.xenproject.org/xen/bug/20 --- Xen Hypervisor Bug Tracker See http://wiki.xen.org/wiki/Reporting_Bugs_against_Xen for information on reporting bugs Contact xen-bugs-owner@bugs.xenproject.org with any infrastructure issues
Anthony PERARD
2013-Oct-11 16:53 UTC
Re: Processed: Re: [HVM} xen_platform_pci=0 doesn''t prevent platform device creation and disk and nic take over by PV drivers.
On Fri, Oct 11, 2013 at 05:22:47PM +0200, Sander Eikelenboom wrote:> > The original message was simply: > >> While trying to get to the bottom of my passthrough problem with the rom bar, > >> i noticed that specifiying "xen_platform_pci=0" in the config file does not prevent > >> the platform device to appear in my HVM guest and consequently the disk and nic are taken over. > >> > >> Running latest xen-unstable, together with upstream qemu and upstream seabios.I''ve start looking at this, and the fix would be easy: removing the creation of the xen-platform from QEMU, and let xl ask QEMU to create it. But if one uses an older version of one project (qemu/xl) and a newer version of the other, then we can end-up with no xen-platform or two xen-platform ... So should we try to be clever about this, or just backport patchs for both qemu and xl? "Clever" option: There is a recent patch for xl that make use of the -nodefault QEMU''s command line option. So if it''s present, we could ask QEMU to not add xen-platform, and xl can decide. Thought? Regards, -- Anthony PERARD
George Dunlap
2013-Oct-11 17:10 UTC
Re: Processed: Re: [HVM} xen_platform_pci=0 doesn''t prevent platform device creation and disk and nic take over by PV drivers.
On Fri, Oct 11, 2013 at 5:53 PM, Anthony PERARD <anthony.perard@citrix.com> wrote:> On Fri, Oct 11, 2013 at 05:22:47PM +0200, Sander Eikelenboom wrote: >> > The original message was simply: >> >> While trying to get to the bottom of my passthrough problem with the rom bar, >> >> i noticed that specifiying "xen_platform_pci=0" in the config file does not prevent >> >> the platform device to appear in my HVM guest and consequently the disk and nic are taken over. >> >> >> >> Running latest xen-unstable, together with upstream qemu and upstream seabios. > > I''ve start looking at this, and the fix would be easy: removing the > creation of the xen-platform from QEMU, and let xl ask QEMU to create > it. > > But if one uses an older version of one project (qemu/xl) and a newer > version of the other, then we can end-up with no xen-platform or two > xen-platform ...So what''s the plan for compatibility here -- full forward and backward compatibily on both sides? (i.e., newer qemu works with older Xen, newer Xen works with older qemu)?> So should we try to be clever about this, or just backport patchs for > both qemu and xl? > > "Clever" option: There is a recent patch for xl that make use of > the -nodefault QEMU''s command line option. So if it''s present, we could > ask QEMU to not add xen-platform, and xl can decide.I wouldn''t mind doing something like this; but would it make more sense to have some kind of a "capability" or "version" interface, like we have between Xen and Linux, rather than relying on other quirks like the presence of "-nodefault"? -George
Anthony PERARD
2013-Oct-11 17:31 UTC
Re: Processed: Re: [HVM} xen_platform_pci=0 doesn''t prevent platform device creation and disk and nic take over by PV drivers.
On Fri, Oct 11, 2013 at 06:10:32PM +0100, George Dunlap wrote:> On Fri, Oct 11, 2013 at 5:53 PM, Anthony PERARD > <anthony.perard@citrix.com> wrote: > > On Fri, Oct 11, 2013 at 05:22:47PM +0200, Sander Eikelenboom wrote: > >> > The original message was simply: > >> >> While trying to get to the bottom of my passthrough problem with the rom bar, > >> >> i noticed that specifiying "xen_platform_pci=0" in the config file does not prevent > >> >> the platform device to appear in my HVM guest and consequently the disk and nic are taken over. > >> >> > >> >> Running latest xen-unstable, together with upstream qemu and upstream seabios. > > > > I''ve start looking at this, and the fix would be easy: removing the > > creation of the xen-platform from QEMU, and let xl ask QEMU to create > > it. > > > > But if one uses an older version of one project (qemu/xl) and a newer > > version of the other, then we can end-up with no xen-platform or two > > xen-platform ... > > So what''s the plan for compatibility here -- full forward and backward > compatibily on both sides? (i.e., newer qemu works with older Xen, > newer Xen works with older qemu)? > > > So should we try to be clever about this, or just backport patchs for > > both qemu and xl? > > > > "Clever" option: There is a recent patch for xl that make use of > > the -nodefault QEMU''s command line option. So if it''s present, we could > > ask QEMU to not add xen-platform, and xl can decide. > > I wouldn''t mind doing something like this; but would it make more > sense to have some kind of a "capability" or "version" interface, like > we have between Xen and Linux, rather than relying on other quirks > like the presence of "-nodefault"?Well, we can always check if the xen-platform-pci is already there after having started QEMU (through QMP) and react by adding it, display a warning or do nothing more, depending the result and the config of the vm. -- Anthony PERARD
Maybe Matching Threads
- Re: [HVM} xen_platform_pci=0 doesn't prevent platform device creation and disk and nic take over by PV drivers.
- [PATCH v2] Handle xen_platform_pci=0 case
- [PATCH] docs: Update xen_platform_pci in man xl.cfg
- [PATCH] xen/pvhvm: If xen_platform_pci=0 is set don''t blow up.
- xen_platform_pci