[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 2014/7/24 20:16, Jan Beulich wrote:
On 24.07.14 at 13:51, <tiejun.chen@xxxxxxxxx> wrote:
On 2014/7/24 19:35, Tim Deegan wrote:
At 19:25 +0800 on 24 Jul (1406226315), Chen, Tiejun wrote:
On 2014/7/24 19:11, Tim Deegan wrote:
though I am still worried about what happens if this overwrites an
existing mapping.

As I understand RMRR should be specific. Its unlikely created for
different mapping since this should be fixed in BIOS phase. And this is
why that function is named as rmrr_identity_mapping().

But the BIOS only sets up _Xen's_ memory map.  The toolstack sets up
the _VM's_ memory map, and unless it can avoid the RMRRs of all
devices in the system (and add them to guest E820s) it risks a clash

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.

may be related to more than one device (at least in theory), and

Are you saying one RMRR corresponds to multiple devfns?

in such case it is insecure to assign these devices to distinct

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?

But if I'm wrong please correct me.

As said in an earlier reply to Tim - I think this half baked solution
isn't worth checking in without the other issues with RMRRs
properly taken care of.

If you can hot-plug one of these devices into a running guest, then
there's no way to be safe, as the guest might have been booted on
another system and migrated.

I guess the original RMRR implementation don't consider live migration
so current RMRR shouldn't support live migration, right?

You didn't read Tim's reply properly: He was referring to the case
where a passed through device gets hotplugged into a guest for
the first time _after_ the guest was already live migrated at least

Thanks for you explanation.


Xen-devel mailing list



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