[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [v3][PATCH 1/1] xen:vtd: missing RMRR mapping while share EPT



>>> On 25.07.14 at 08:48, <tiejun.chen@xxxxxxxxx> wrote:
> On 2014/7/24 20:16, Jan Beulich wrote:
>>>>> On 24.07.14 at 13:51, <tiejun.chen@xxxxxxxxx> wrote:
>>> RMRR seems be used barely. Here in my case, just GFX passthrough needs
>>> this since some windows GFX drivers may access those stolen memory now.
>>
>> USB legacy emulation is another use case iirc, as seen on at least
>> one of the systems I have here.
>>
>> Furthermore an RMRR (as pointed out a couple of months ago)
> 
> I'm poor in this problem, so could you point where I can get this 
> discussion? I think I should take a look at that to know about more.

http://lists.xenproject.org/archives/html/xen-devel/2014-02/msg00824.html
(continued in March; the list server doesn't properly deal with
cross-month follow-ups, so you'll need to search for the same
subject in
http://lists.xenproject.org/archives/html/xen-devel/2014-03/threads.html)

>> may be related to more than one device (at least in theory), and
> 
> Are you saying one RMRR corresponds to multiple devfns?

Yes, just look at acpi_parse_one_rmrr() and its helper
acpi_parse_dev_scope(): There's nothing there enforcing just
a single device per RMRR.

>> in such case it is insecure to assign these devices to distinct
>> domains.
> 
> But looks we always create one RMRR when an associated devfn is assigned 
> to one given domain, so this mean its always insecure before I introduce 
> this patch, right?

If you meant "already" instead of "always", then yes. Your patch
is just widening the issue.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.