From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH V2] ns16550: Add support for UART present in Broadcom TruManage capable NetXtreme chips Date: Tue, 26 Nov 2013 11:37:54 -0500 Message-ID: <20131126163754.GE2959@phenom.dumpdata.com> References: <1384450802-1870-1-git-send-email-Aravind.Gopalakrishnan@amd.com> <5285F7F40200007800103710@nat28.tlf.novell.com> <52865F3D.8000207@amd.com> <5289D8130200007800103E48@nat28.tlf.novell.com> <528B9475.9080809@amd.com> <528BA4240200007800104A8B@nat28.tlf.novell.com> <528C07F2.3030401@amd.com> <528C7C7B0200007800104D95@nat28.tlf.novell.com> <528E8DFD.90706@amd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1VlLeJ-0007c2-Eg for xen-devel@lists.xenproject.org; Tue, 26 Nov 2013 16:38:07 +0000 Content-Disposition: inline In-Reply-To: <528E8DFD.90706@amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Aravind Gopalakrishnan , boris.ostrovsky@oracle.com Cc: Thomas Lendacky , keir@xen.org, Jan Beulich , andrew.cooper3@citrix.com, SuraveeSuthikulpanit , sherry.hurwitz@amd.com, xen-devel , shurd@broadcom.com List-Id: xen-devel@lists.xenproject.org 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 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 > > Also, to your comments on V3 - (Sorry I have to do this here as my > mail client seems to have lost the V3 thread..) > I have fixed the code in accordance to your comments except for the > '(-len)' suggestion. Reason being - > It does not work all the time. Example: (for IO case) > after applying (len &= PCI_BASE_ADDRESS_IO_MASK), > len = fff8; > len = -(len) would give you ffff0008 and you will need to mask off > higher 16 bits again.. > > Instead, I have kept length calculation consistent with what linux > does and extended that to IO case.. > > Sending the changes out as V4. > (Tested the code changes with BCM5725 and an IO based UART and > verified to be working correctly..) > > -Aravind. > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel