Re: [PATCH V2] ns16550: Add support for UART present in Broadcom TruManage capable NetXtreme chips

[Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>]

[-- Attachment #1.1: Type: text/plain, Size: 6473 bytes --]


On Nov 26, 2013, at 10:37 AM, Konrad Rzeszutek Wilk 
<konrad.wilk@oracle.com> wrote:

> On Thu, Nov 21, 2013 at 04:49:33PM -0600, Aravind Gopalakrishnan wrote:
>> On 11/20/2013 2:10 AM, Jan Beulich wrote:
>>>>>> On 20.11.13 at 01:53, Aravind Gopalakrishnan 
>>>>>> <aravind.gopalakrishnan@amd.com> wrote:
>>>> Looks like the arguments I was passing in to 'iomem_deny_access' was
>>>> incorrect before (apologies)
>>>> (I just had to use paddr_to_pfn() to get PAGE_SHIFT-ed value)
>>>> I tried with the proper (page shifted) values, but it breaks Xen
>>>> throwing the message:
>>>>
>>>> (XEN) mm.c:785:d0 Non-privileged (0) attempt to map I/O space
>>> Xen should not be affected by this message appearing; Dom0
>>> likely would be in one way or another.
>>>
>>>> The reason for this is -  dom0 sees the UART device and tries to
>>>> configure it at the bar value (which is blocked by Xen)
>>>> which means pci_hide_device() is not functioning as expected..(again,
>>>> not sure if I am missing something..).
>>> Then you didn't understand the purpose of pci_hide_device(),
>>> yet I would have expected you to have looked at commit e46ea4d4
>>> ("PCI: don't allow guest assignment of devices used by Xen") in this
>>> context: Such devices are unavailable for assignment to a DomU,
>>> but visible as usual to Dom0 (and nothing prevents Dom0 from
>>> assigning the device e.g. new BAR values - pci_ro_device() would -,
>>> and hence using iomem_deny_access() is pointless/wrong).
>>>
>>>> But-
>>>> Could this be due to the fact that this is a multifunction device and
>>>> the UART is only a subfunction?
>>> Multi-function in the usual sense? If so, all the BARs on that
>>> function are only to be used by that function... Or do you perhaps
>>> mean a function in the PCI sense providing more functionality than
>>> just the serial port (as in many other combined serial/parallel or
>>> multi-port serial add in cards)?
>>>
>>> Jan
>>>
>>>
>>
>> I meant multi-function as in latter sense (provides more than a
>> serial port). Here is snapshot of lspci for clarity -
>>
>> 02:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme
>> BCM5725 Gigabit Ethernet PCIe [14e4:1643] (rev 10)
>> 02:00.5 Communication controller [0780]: Broadcom Corporation Device
>> [14e4:160a] (rev 01)
>> 02:00.6 IPMI SMIC interface [0c07]: Broadcom Corporation Device
>> [14e4:16b9] (rev 10)
>>
>> Anyway, I have now reworked the code such that Xen hides the MMIO
>> region from (io_base+PAGE_SIZE) to end of the region.
>> ([    0.000000] Xen: [mem 0x00000000d0031000-0x00000000d003ffff] 
>> reserved)
>> This would (in some extent) alleviate conflicts in case Dom0
>> interferes with Xen's control of the device as we are hiding all
>> possible PAGE_SIZE'd chunks of the MMIO region..
>> Since we can't hide the device from dom0, dom0 sees the device and
>> tries to 'ioremap' at the above said regions, but fails.
>> Although it does not break Xen, dom0 throws a stack trace with a
>> warning message. dom0 continues to boot fine..
>
> What is the stack trace? So that at least I know what to look for
> if somebody mentions this?
>
> Thanks
>>
>>
(per Jan's commets), I have reworked the patch to make the pci device 
read only and also included the MMIO range to mmio_ro_ranges. This seems 
to work fine and does not throw any dom0 stack trace either.. (Am 
sending this out as V6)

In case you are still curious, here is the stack trace from dom0 when I 
used iomem_deny_access -

(XEN) mm.c:785:d0 Non-privileged (0) attempt to map I/O space 000d003f
[ 13.726130] resource map sanity check conflict: 0xd0030000 0xd003ffff 
0xd0031000 0xd003ffff reserved
[ 13.758008] ------------[ cut here ]------------
[ 13.758231] WARNING: CPU: 31 PID: 1 at arch/x86/mm/ioremap.c:171 
__ioremap_caller+0x2f2/0x380()
[ 13.759200] Info: mapping multiple BARs. Your kernel is fine.
[ 13.760048] Modules linked in:
[ 13.790037] CPU: 31 PID: 1 Comm: swapper/0 Not tainted 3.12.0-rc5+ #7
[ 13.790984] Hardware name: empty empty/ S8237 , BIOS V1.0B 07/23/2013
[ 13.791214]  0000000000000009 ffff880828cbf948 ffffffff816f867d 
ffff880828cbf990
[ 13.792269]  ffff880828cbf980 ffffffff81067a3c ffffc900036a0000 
00000000d0040000
[ 13.823332]  00000000d0030000 00000000000d0040 0000000000010000 
ffff880828cbf9e0
[ 13.824280] Call Trace:
[ 13.824987]  [<ffffffff816f867d>] dump_stack+0x45/0x56
[ 13.825183]  [<ffffffff81067a3c>] warn_slowpath_common+0x8c/0xc0
[ 13.855176]  [<ffffffff81067b2c>] warn_slowpath_fmt+0x4c/0x50
[ 13.856003]  [<ffffffff810580c2>] __ioremap_caller+0x2f2/0x380
[ 13.856218]  [<ffffffff810581a7>] ioremap_nocache+0x17/0x20
[ 13.888203]  [<ffffffff8146598f>] setup_port+0x10f/0x130
[ 13.888403]  [<ffffffff81465c01>] pci_default_setup+0x91/0xb0
[ 13.889244]  [<ffffffff81465c32>] pci_brcm_trumanage_setup+0x12/0x30
[ 13.890151]  [<ffffffff81466f47>] pciserial_init_ports+0x147/0x210
[ 13.913649]  [<ffffffff814670e9>] pciserial_init_one+0xd9/0x1e0
[ 13.913870]  [<ffffffff813a21cb>] local_pci_probe+0x4b/0x80
[ 13.915128]  [<ffffffff813a2421>] pci_device_probe+0x111/0x120
[ 13.915370]  [<ffffffff81484e37>] driver_probe_device+0x77/0x240
[ 13.915632]  [<ffffffff814850ab>] __driver_attach+0xab/0xb0
[ 13.916893]  [<ffffffff81485000>] ? driver_probe_device+0x240/0x240
[ 13.917122]  [<ffffffff81482f3d>] bus_for_each_dev+0x5d/0xa0
[ 13.918376]  [<ffffffff8148491e>] driver_attach+0x1e/0x20
[ 13.918579]  [<ffffffff81484434>] bus_add_driver+0x104/0x290
[ 13.918788]  [<ffffffff814857c4>] driver_register+0x64/0xf0
[ 13.920076]  [<ffffffff81d60e66>] ? early_serial_setup+0x129/0x129
[ 13.920330]  [<ffffffff813a12fc>] __pci_register_driver+0x4c/0x50
[ 13.921617]  [<ffffffff81d60e7f>] serial_pci_driver_init+0x19/0x1b
[ 13.921844]  [<ffffffff8100217a>] do_one_initcall+0x12a/0x190
[ 13.922093]  [<ffffffff81088ffb>] ? parse_args+0x1fb/0x350
[ 13.923385]  [<ffffffff81d1a047>] kernel_init_freeable+0x139/0x1cb
[ 13.923611]  [<ffffffff81d19815>] ? loglevel+0x31/0x31
[ 13.924843]  [<ffffffff816e8e70>] ? rest_init+0x80/0x80
[ 13.925040]  [<ffffffff816e8e7e>] kernel_init+0xe/0xf0
[ 13.925262]  [<ffffffff8170803c>] ret_from_fork+0x7c/0xb0
[ 13.925468]  [<ffffffff816e8e70>] ? rest_init+0x80/0x80
[ 13.926690] ---[ end trace 6d7c17d875f132f5 ]---

(Apologies for the late reply.. )



Thanks,
Aravind

>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xen.org <mailto:Xen-devel@lists.xen.org>
>> http://lists.xen.org/xen-devel



[-- Attachment #1.2: Type: text/html, Size: 15075 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel