[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


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.


Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.