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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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


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