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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> 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
>> here.
> 
> 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)
may be related to more than one device (at least in theory), and
in such case it is insecure to assign these devices to distinct
domains.

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
once.

Jan


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