[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |