From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aravind Gopalakrishnan Subject: Re: [PATCH V2] ns16550: Add support for UART present in Broadcom TruManage capable NetXtreme chips Date: Tue, 19 Nov 2013 18:53:06 -0600 Message-ID: <528C07F2.3030401@amd.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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" 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 1Viw2e-0003bc-RT for xen-devel@lists.xenproject.org; Wed, 20 Nov 2013 00:53:17 +0000 In-Reply-To: <528BA4240200007800104A8B@nat28.tlf.novell.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: Jan Beulich Cc: Thomas Lendacky , keir@xen.org, andrew.cooper3@citrix.com, SuraveeSuthikulpanit , sherry.hurwitz@amd.com, xen-devel , shurd@broadcom.com List-Id: xen-devel@lists.xenproject.org On 11/19/2013 10:47 AM, Jan Beulich wrote: >>>> On 19.11.13 at 17:40, Aravind Gopalakrioshnan wrote: >> On 11/18/2013 2:04 AM, Jan Beulich wrote: >>> But then you'd need to carefully consider what the remainder of >>> the MMIO range is used for - if any of that could conflict with >>> what Xen needs to fully control the device, then you should also >>> hide any PAGE_SIZE chunks from all domains (including Dom0). >>> (Unfortunately we can't currently hide sub-page chunks in an >>> effective manner.) >> With respect to this, >> I am not seeing any untoward side effects to Xen from letting the code >> run as-is. >> I have tested the patch with the Broadcom 5725 UART chip and a IO based >> UART as well >> and both seem to function fine.. > Sure, because you surely used a well behaved Dom0. But you > should (a) protect Xen from a bug in Dom0 and (b) either prevent > the device from being assigned to a guest, or make sure a > malicious guest can't interfere with Xen's operation. > >> I did try using 'iomem_deny_access' to hide the MMIO range from dom0. >> But I don't see an effect. >> Not sure if I am missing something or is there a different way to hide >> PAGE_SIZE chunks? > No, what you say you did is correct afaict. > > 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 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..). But- Could this be due to the fact that this is a multifunction device and the UART is only a subfunction? Meanwhile, I am sending a V3 with the other changes.. Thanks, Aravind.