[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH V2] ns16550: Add support for UART present in Broadcom TruManage capable NetXtreme chips
On 11/19/2013 10:47 AM, Jan Beulich wrote: Looks like the arguments I was passing in to 'iomem_deny_access' was incorrect before (apologies)On 19.11.13 at 17:40, Aravind Gopalakrioshnan <aravind.gopalakrishnan@xxxxxxx> 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. (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 spaceThe 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. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |