[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] Marvell, IOMMU/VT-d, and pci-phantom
>>> On 28.06.13 at 13:57, Ian Campbell <Ian.Campbell@xxxxxxxxxx> 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 _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxx http://lists.xen.org/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |