From: Aravind Gopalakrishnan <aravind.gopalakrishnan@amd.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Thomas Lendacky <Thomas.Lendacky@amd.com>,
keir@xen.org, andrew.cooper3@citrix.com,
SuraveeSuthikulpanit <Suravee.Suthikulpanit@amd.com>,
sherry.hurwitz@amd.com,
xen-devel <xen-devel@lists.xenproject.org>,
shurd@broadcom.com
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 [thread overview]
Message-ID: <528C07F2.3030401@amd.com> (raw)
In-Reply-To: <528BA4240200007800104A8B@nat28.tlf.novell.com>
On 11/19/2013 10:47 AM, Jan Beulich wrote:
>>>> On 19.11.13 at 17:40, Aravind Gopalakrioshnan <aravind.gopalakrishnan@amd.com> 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.
next prev parent reply other threads:[~2013-11-20 0:53 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-14 17:40 [PATCH V2] ns16550: Add support for UART present in Broadcom TruManage capable NetXtreme chips Aravind Gopalakrishnan
2013-11-15 9:31 ` Jan Beulich
2013-11-15 17:51 ` Aravind Gopalakrioshnan
2013-11-18 8:04 ` Jan Beulich
2013-11-19 16:40 ` Aravind Gopalakrioshnan
2013-11-19 16:47 ` Jan Beulich
2013-11-20 0:53 ` Aravind Gopalakrishnan [this message]
2013-11-20 8:10 ` Jan Beulich
2013-11-21 22:49 ` Aravind Gopalakrishnan
2013-11-26 16:37 ` Konrad Rzeszutek Wilk
2013-12-02 18:30 ` Aravind Gopalakrishnan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=528C07F2.3030401@amd.com \
--to=aravind.gopalakrishnan@amd.com \
--cc=JBeulich@suse.com \
--cc=Suravee.Suthikulpanit@amd.com \
--cc=Thomas.Lendacky@amd.com \
--cc=andrew.cooper3@citrix.com \
--cc=keir@xen.org \
--cc=sherry.hurwitz@amd.com \
--cc=shurd@broadcom.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.