Hi, guys.
I''ve been trying to use the pci-phantom command line options to xen so
as to work around the hardware issue with the Marvell 88SE91xx SATA
controllers in IOMMU ([Intel:] VT-d) mode, but I cannot seem to get my
head around it. From having had a glance here:
http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html
and in particular the syntax described as such:
pci-phantom
=[<seg>:]<bus>:<device>,<stride>
I decided to try and work out the correct values for this command.
Being no expert (nor even an adept) when it comes to PCI bus
addressing, I did this:
mybox:~$ lspci | grep -i marvell
06:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9172
SATA 6Gb/s Controller (rev 11)
0a:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9172
SATA 6Gb/s Controller (rev 11)
and then experimented like so:
/boot/xen-4.3-unstable.gz placeholder pci-phantom=06:00.0
pci-phantom=0a:00.0
/boot/xen-4.3-unstable.gz placeholder pci-phantom=06:00,0
pci-phantom=0a:00,0
/boot/xen-4.3-unstable.gz placeholder pci-phantom=0:06:00,0
pci-phantom=0:0a:00,0
/boot/xen-4.3-unstable.gz placeholder pci-phantom=0:06:00,0
pci-phantom=1:0a:00,0
and finally, on the off chance I''d glean something useful doing this:
mybox:~$ strings /boot/xen-syms-4.3-unstable | grep -i phantom
<3>PCI phantom %04x:%02x:%02x.%u
pci-phantom
I even tried this:
/boot/xen-4.3-unstable.gz placeholder pci-phantom=0000:06:00.0
pci-phantom=0000:0a:00.0
All to no avail. I''ve Googled my smallish head off and I''ve
tried to
scour this list to see if anybody else has been trying out this
option, but I can''t seem to find anything.
And so, hopefully, I ask: Can anyone see what I''m doing wrong? Has
anyone gotten the pci-phantom option to work? Am I just using the
wrong syntax?
Regards,
Erlend
On Tue, 2013-06-25 at 21:05 +0200, Erlend Hoel wrote:> Hi, guys. > > I''ve been trying to use the pci-phantom command line options to xen so > as to work around the hardware issue with the Marvell 88SE91xx SATA > controllers in IOMMU ([Intel:] VT-d) mode, but I cannot seem to get my > head around it. From having had a glance here: > > http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html > > and in particular the syntax described as such: > > pci-phantom > > =[<seg>:]<bus>:<device>,<stride> > > I decided to try and work out the correct values for this command. > Being no expert (nor even an adept) when it comes to PCI bus > addressing, I did this: > > mybox:~$ lspci | grep -i marvell > 06:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9172 > SATA 6Gb/s Controller (rev 11) > 0a:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9172 > SATA 6Gb/s Controller (rev 11) > > and then experimented like so: > > /boot/xen-4.3-unstable.gz placeholder pci-phantom=06:00.0 pci-phantom=0a:00.0 > /boot/xen-4.3-unstable.gz placeholder pci-phantom=06:00,0 pci-phantom=0a:00,0 > /boot/xen-4.3-unstable.gz placeholder pci-phantom=0:06:00,0 pci-phantom=0:0a:00,0 > /boot/xen-4.3-unstable.gz placeholder pci-phantom=0:06:00,0 pci-phantom=1:0a:00,0It seems to me from peering at the docs that one of those (probably the second) ought to be correct, but I''m not sure what the <stride> parameter is supposed to be, although I suspect it ought to be non-zero. Jan, since you wrote this patch for Marvell devices I suppose you know the right incantation for this bit of hardware?> > and finally, on the off chance I''d glean something useful doing this: > > mybox:~$ strings /boot/xen-syms-4.3-unstable | grep -i phantom > <3>PCI phantom %04x:%02x:%02x.%u > pci-phantom > > I even tried this: > > /boot/xen-4.3-unstable.gz placeholder pci-phantom=0000:06:00.0 > pci-phantom=0000:0a:00.0 > > All to no avail. I''ve Googled my smallish head off and I''ve tried to > scour this list to see if anybody else has been trying out this > option, but I can''t seem to find anything. > > And so, hopefully, I ask: Can anyone see what I''m doing wrong? Has > anyone gotten the pci-phantom option to work? Am I just using the > wrong syntax? > > Regards, > Erlend > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xen.org > http://lists.xen.org/xen-users
>>> On 28.06.13 at 13:57, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Tue, 2013-06-25 at 21:05 +0200, Erlend Hoel wrote: >> Hi, guys. >> >> I''ve been trying to use the pci-phantom command line options to xen so >> as to work around the hardware issue with the Marvell 88SE91xx SATA >> controllers in IOMMU ([Intel:] VT-d) mode, but I cannot seem to get my >> head around it. From having had a glance here: >> >> http://xenbits.xen.org/docs/unstable/misc/xen-command-line.html >> >> and in particular the syntax described as such: >> >> pci-phantom >> >> =[<seg>:]<bus>:<device>,<stride> >> >> I decided to try and work out the correct values for this command. >> Being no expert (nor even an adept) when it comes to PCI bus >> addressing, I did this: >> >> mybox:~$ lspci | grep -i marvell >> 06:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9172 >> SATA 6Gb/s Controller (rev 11) >> 0a:00.0 SATA controller: Marvell Technology Group Ltd. 88SE9172 >> SATA 6Gb/s Controller (rev 11) >> >> and then experimented like so: >> >> /boot/xen-4.3-unstable.gz placeholder pci-phantom=06:00.0 > pci-phantom=0a:00.0 >> /boot/xen-4.3-unstable.gz placeholder pci-phantom=06:00,0 > pci-phantom=0a:00,0 >> /boot/xen-4.3-unstable.gz placeholder pci-phantom=0:06:00,0 > pci-phantom=0:0a:00,0 >> /boot/xen-4.3-unstable.gz placeholder pci-phantom=0:06:00,0 > pci-phantom=1:0a:00,0 > > It seems to me from peering at the docs that one of those (probably the > second) ought to be correct, but I''m not sure what the <stride> > parameter is supposed to be, although I suspect it ought to be non-zero.Exactly (at least to me "stride" can''t possibly mean something that might be zero, except perhaps as a disable indicator). So pci-phantom=06:00,1 should do, provided this is a single-function device.> Jan, since you wrote this patch for Marvell devices I suppose you know > the right incantation for this bit of hardware?The specific hardware doesn''t matter, we''re basically just overriding rwo bits that a device behaving this way should have set in its PCIe capability structure (i.e. the resulting behavior is generic).>> and finally, on the off chance I''d glean something useful doing this: >> >> mybox:~$ strings /boot/xen-syms-4.3-unstable | grep -i phantom >> <3>PCI phantom %04x:%02x:%02x.%u >> pci-phantom >> >> I even tried this: >> >> /boot/xen-4.3-unstable.gz placeholder pci-phantom=0000:06:00.0 >> pci-phantom=0000:0a:00.0 >> >> All to no avail. I''ve Googled my smallish head off and I''ve tried to >> scour this list to see if anybody else has been trying out this >> option, but I can''t seem to find anything.Googling is probably of less help here than simply taking a look at the function that does the parsing (xen/drivers/passthrough/pci.c:parse_phantom_dev()); of course I admit this assumes you can at least read C code. Jan
On Fri, 2013-06-28 at 14:59 +0100, Jan Beulich wrote:> > It seems to me from peering at the docs that one of those (probably the > > second) ought to be correct, but I''m not sure what the <stride> > > parameter is supposed to be, although I suspect it ought to be non-zero. > > Exactly (at least to me "stride" can''t possibly mean something that > might be zero, except perhaps as a disable indicator).Right.> So > > pci-phantom=06:00,1 > > should do, provided this is a single-function device.So what does stride actually mean? To me it suggests every N-th device, but in that case how do we know how many there are in total?> > Jan, since you wrote this patch for Marvell devices I suppose you know > > the right incantation for this bit of hardware? > > The specific hardware doesn''t matter, we''re basically just overriding > rwo bits that a device behaving this way should have set in its PCIe > capability structure (i.e. the resulting behavior is generic).I''m not 100% convinced that requiring users to understand the PCIe capability structures here is "fair", but I suppose it is an advanced feature. Assuming you meant "two" not "rwo", which two bits are they?> >> and finally, on the off chance I''d glean something useful doing this: > >> > >> mybox:~$ strings /boot/xen-syms-4.3-unstable | grep -i phantom > >> <3>PCI phantom %04x:%02x:%02x.%u > >> pci-phantom > >> > >> I even tried this: > >> > >> /boot/xen-4.3-unstable.gz placeholder pci-phantom=0000:06:00.0 > >> pci-phantom=0000:0a:00.0 > >> > >> All to no avail. I''ve Googled my smallish head off and I''ve tried to > >> scour this list to see if anybody else has been trying out this > >> option, but I can''t seem to find anything. > > Googling is probably of less help here than simply taking a look at > the function that does the parsing > (xen/drivers/passthrough/pci.c:parse_phantom_dev()); of course > I admit this assumes you can at least read C code. > > Jan >
>>> On 28.06.13 at 16:10, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Fri, 2013-06-28 at 14:59 +0100, Jan Beulich wrote: >> So >> >> pci-phantom=06:00,1 >> >> should do, provided this is a single-function device. > > So what does stride actually mean? To me it suggests every N-th device, > but in that case how do we know how many there are in total?Every N-th function. With there being up to 8 functions per device, stride one means all of them, stride 2 every even one, and stride 4 functions 0 and 4. On a single function device it is generally safe to use stride 1. On multi function devices stride must not result in collisions with one of the other functions.>> > Jan, since you wrote this patch for Marvell devices I suppose you know >> > the right incantation for this bit of hardware? >> >> The specific hardware doesn''t matter, we''re basically just overriding >> rwo bits that a device behaving this way should have set in its PCIe >> capability structure (i.e. the resulting behavior is generic). > > I''m not 100% convinced that requiring users to understand the PCIe > capability structures here is "fair", but I suppose it is an advanced > feature.Oh, that part of the response was more to you than the original user.> Assuming you meant "two" not "rwo", which two bits are they?PCI_EXP_DEVCAP_PHANTOM in terms of xen/include/xen/pci_regs.h. Jan
On Fri, 2013-06-28 at 15:38 +0100, Jan Beulich wrote:> >>> On 28.06.13 at 16:10, Ian Campbell <Ian.Campbell@citrix.com> wrote: > > On Fri, 2013-06-28 at 14:59 +0100, Jan Beulich wrote: > >> So > >> > >> pci-phantom=06:00,1 > >> > >> should do, provided this is a single-function device. > > > > So what does stride actually mean? To me it suggests every N-th device, > > but in that case how do we know how many there are in total? > > Every N-th function. With there being up to 8 functions per device, > stride one means all of them, stride 2 every even one, and stride 4 > functions 0 and 4. > > On a single function device it is generally safe to use stride 1. On > multi function devices stride must not result in collisions with one > of the other functions. > > >> > Jan, since you wrote this patch for Marvell devices I suppose you know > >> > the right incantation for this bit of hardware? > >> > >> The specific hardware doesn''t matter, we''re basically just overriding > >> rwo bits that a device behaving this way should have set in its PCIe > >> capability structure (i.e. the resulting behavior is generic). > > > > I''m not 100% convinced that requiring users to understand the PCIe > > capability structures here is "fair", but I suppose it is an advanced > > feature. > > Oh, that part of the response was more to you than the original > user. > > > Assuming you meant "two" not "rwo", which two bits are they? > > PCI_EXP_DEVCAP_PHANTOM in terms of xen/include/xen/pci_regs.h.And those are a shift, giving you the stride={1,2,4}, got it, thanks! Ian
Reasonably Related Threads
- disk controller not working with xen: Marvell Technology Group Ltd. 88SE9172
- phantom(0) doesn't do what I expect it to [plotmath]
- Phantom Domain Master Browser
- phantom new mail (mailboxes keep on being reported as having new mail)
- phantom incomming calls from asterisk