From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Elena Ufimtseva <elena.ufimtseva@oracle.com>, JBeulich@suse.com
Cc: kevin.tian@intel.com, andrew.cooper3@citrix.com, tim@xen.org,
xen-devel@lists.xen.org, yang.z.zhang@intel.com,
boris.ostrovsky@oracle.com
Subject: Re: [PATCH RFC] p2m: p2m_mmio_direct set RW permissions
Date: Thu, 22 Jan 2015 16:42:52 +0100 [thread overview]
Message-ID: <54C11A7C.6090602@citrix.com> (raw)
In-Reply-To: <29df2db1-7845-42ee-99e0-901ec8f2930a@default>
El 22/01/15 a les 16.18, Elena Ufimtseva ha escrit:
>
> ----- JBeulich@suse.com wrote:
>
>>>>> On 22.01.15 at 12:37, <roger.pau@citrix.com> wrote:
>>> El 22/01/15 a les 12.09, Jan Beulich ha escrit:
>>>>>>> On 22.01.15 at 11:59, <andrew.cooper3@citrix.com> wrote:
>>>>> On 22/01/15 09:53, Jan Beulich wrote:
>>>>>>>>> On 21.01.15 at 21:55, <elena.ufimtseva@oracle.com> wrote:
>>>>>>> p2m_mmio_direct should result in setting IOMMUF_readable and
>> IOMMUF_writable
>>>>>>> flags.
>>>>>>> When pvh domain maps mmio regions, the EPT entries are not
>> getting mapped.
>>>>>>> This leads to IOMMU Page faults for some devices, as for example
>> USB Host
>>>>>>> controllers with embedded Debug devices. See
>> pvh-set-need_iommu-early RFC
>>>>>>> patch discussion fgor detail.
>>>>>> Even more so that the two patches aren't even a series, that
>> part
>>>>>> of the description belongs here, not in the other patch.
>>>>>>
>>>>>>> I will appreciate your comments and ideas in regards to this
>> change.
>>>>>>>
>>>>>>> Looking at Roger patches (xen/pvh: check permissions when adding
>> MMIO
>>>>>>> regions)
>>>>>>> the mmio memory type is proposed to be changed from
>> p2m_mmio_direct to
>>>>>>> p2m_access_rw.
>>>>>>> This type still does not have proper IOMMU flags mapping.
>>>>>> A fundamental question is what business devices have to DMA
>> their
>>>>>> own (or other devices') MMIO space. I could remotely see a need
>>>>>> for this for e.g. frame buffers, but I have difficulty
>> understanding
>>>>>> this for USB devices. Please at the very least provide details on
>> the
>>>>>> MMIO regions that those devices have, and which of them you
>>>>>> observed IOMMU faults on.
>>>>>
>>>>> It would appear that, in this case, it is a USB controller lacking
>> an
>>>>> appropriate RMRR description in the ACPI tables.
>>>>
>>>> No, RMRRs only reference RAM pages afaik.
>>>
>>> According to Linux IOMMU support document RMRRs reference regions
>> marked
>>> as "reserved" in the e820 memory map:
>>>
>>> https://www.kernel.org/doc/Documentation/Intel-IOMMU.txt
>>
>> Exactly. And MMIO PCI BARs in particular are never to be
>> reflected in the E820 (not the least because they're relocatable).
>>
>>> I don't think we are setting proper IOMMU entries for this regions
>> at
>>> all with the current PVH Dom0 code. IMHO instead of just adding
>> IOMMU
>>> entries for every MMIO region we should just add IOMMU entries for
>> the
>>> RMRR regions.
>>
>> Yes, RMRR regions should certainly be put there as r/w entries.
>>
>> Jan
>
> How it will help in cases like this when this regions are not reported as RMRRs in ACPI?
AFAIK even if they are properly reported as RMRRs they won't have the
right IOMMU mappings, are you sure they are not reported as RMRRs?
Roger.
next prev parent reply other threads:[~2015-01-22 15:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-22 15:18 [PATCH RFC] p2m: p2m_mmio_direct set RW permissions Elena Ufimtseva
2015-01-22 15:36 ` Jan Beulich
2015-01-22 15:42 ` Roger Pau Monné [this message]
2015-01-22 16:23 ` Elena Ufimtseva
2015-01-22 17:34 ` Elena Ufimtseva
2015-01-23 10:50 ` Jan Beulich
2015-01-26 16:57 ` Elena Ufimtseva
2015-01-26 17:06 ` Jan Beulich
2015-01-26 17:30 ` Elena Ufimtseva
2015-01-27 6:41 ` Tian, Kevin
2015-01-27 15:05 ` Elena Ufimtseva
2015-01-28 2:28 ` Tian, Kevin
2015-01-27 8:24 ` Jan Beulich
2015-01-27 15:07 ` Elena Ufimtseva
2015-01-30 16:34 ` Elena Ufimtseva
2015-01-30 16:48 ` Jan Beulich
-- strict thread matches above, loose matches on Subject: below --
2015-01-22 15:43 Elena Ufimtseva
2015-01-23 11:19 ` Jan Beulich
2015-01-22 15:42 Elena Ufimtseva
2015-01-22 15:11 Elena Ufimtseva
2015-01-22 15:34 ` Jan Beulich
2015-01-21 20:55 Elena Ufimtseva
2015-01-22 9:53 ` Jan Beulich
2015-01-22 10:59 ` Andrew Cooper
2015-01-22 11:09 ` Jan Beulich
2015-01-22 11:37 ` Roger Pau Monné
2015-01-22 11:54 ` Jan Beulich
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=54C11A7C.6090602@citrix.com \
--to=roger.pau@citrix.com \
--cc=JBeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=boris.ostrovsky@oracle.com \
--cc=elena.ufimtseva@oracle.com \
--cc=kevin.tian@intel.com \
--cc=tim@xen.org \
--cc=xen-devel@lists.xen.org \
--cc=yang.z.zhang@intel.com \
/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.