Xen project Mailing List

On Nov 26, 2013, at 10:37 AM, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> 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@xxxxxxx> 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.. )

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