Xen devel - Oct 2013 - 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-xen
Set 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>''
> thanks
Finished 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

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.

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.

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
> thanks
Finished 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

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

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

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