https://bugzilla.novell.com/show_bug.cgi?id=489735 User pgnet.trash@gmail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=489735#c2 --- Comment #2 from pgnet _ <pgnet.trash@gmail.com> 2009-03-30 09:43:26 MDT --- (In reply to comment #1)

Try putting the device in a different slot, so that it ends up on a different bus.

unfortunately, not an option in these micro-atx boxes (card/slot geometry is inflexible :-( ), without removing something completely. can get around to trying that, eventually ...

I assume you're running into the situation where all devices behind a bridge need to be assigned to the same domain.

i'm not clear whether that's a system "need" (which exists?) or my "need", which doesn't. i just need to assign this _one_ card (04:07.0) to this domain. 04:08.0 is inisting on tagging-along for the ride -- when i actually need/want it to 'stay' @ Dom0.

This is definitely a requirement when using an IOMMU, but the tools may just always require this to be the case.

atm, i'm booting to root (hd0,0) kernel /xen.gz dom0_mem=768M loglvl=all loglvl_guest=all vga=gfx-1280x1024x32 console=vga,com1 com1=57600,8n1 module /vmlinuz-xen root=/dev/vg0/ROOT resume=/dev/vgS/SWAP showopts console=tty0 console=xvc0,57600 elevator=cfq max_loop=64 physdev_dom0_hide=(04:07.0)(04:08.0) reassigndev=(04:07.0) module /initrd-xen i.e., no IOMMU you've CLOSED this bug as INVALID ... is that to say that you consider the inability to split these device assignments (1 to Dom0, 1 to DomU)normal function, and not an issue? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=489735 User jbeulich@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=489735#c4 Jan Beulich <jbeulich@novell.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID | --- Comment #4 from Jan Beulich <jbeulich@novell.com> 2009-03-31 01:59:01 MDT ---

From Dexuan Cui (the author of the offending change): c/s 18046 adds the requirement to co-assign PCI devices behind bridges/ PCIe functions on the same device when the (perhaps individual) device/ function intended to be assigned doesn't support FLR and doesn't sit on bus 0. For non-IOMMU environments (which are insecure anyway) this could be considered a regression, since passing through individual devices/ functions didn't know such a restriction earlier. Yes, this may not proper for the non-IOMMU case. I planned to fix it, but haven't done that yet... I'd appreciate anybody who can help to do that. :-) We need to consider IOMMU case, non-IOMMU case and 'hybrid case'(namely, the xen parameter iommu=on,no-pv).

-- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=489735 User pgnet.trash@gmail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=489735#c5 --- Comment #5 from pgnet _ <pgnet.trash@gmail.com> 2009-03-31 08:51:14 MDT ---

must be capable of separating them well enough (in particular, allow the set of devices [perhaps an individual one] assigned to a guest to be reset upon guest termination without affecting other devices

ok, i understand the in-principle requirement

whole hierarchy behind a bridge must be passed through

i don't see how/why the motherboard-firewire & the pci-card-sata are considered the "same hierarchy". not arguing, just unclear.

device(s) assigned must support FLR

no clue even what FLR is (yet). will explore its presence/support, partiuclarly for this mobo. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=489735 User jbeulich@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=489735#c6 --- Comment #6 from Jan Beulich <jbeulich@novell.com> 2009-03-31 09:25:05 MDT --- (In reply to comment #5)

...

whole hierarchy behind a bridge must be passed through

i don't see how/why the motherboard-firewire & the pci-card-sata are considered the "same hierarchy". not arguing, just unclear.

Both devices sit on the same bus (according to the numbers you provided), and thus have a common upstream bridge.

...

device(s) assigned must support FLR

no clue even what FLR is (yet). will explore its presence/support, partiuclarly for this mobo.

Function Level Reset (not a motherboard capability, but a per-device-function one). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=489735 User pgnet.trash@gmail.com added comment https://bugzilla.novell.com/show_bug.cgi?id=489735#c8 --- Comment #8 from pgnet _ <pgnet.trash@gmail.com> 2009-03-31 09:28:40 MDT --- (In reply to comment #6)

Both devices sit on the same bus (according to the numbers you provided), and thus have a common upstream bridge. .. Function Level Reset (not a motherboard capability, but a per-device-function one).

thanks. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.