[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 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:
At 19:00 +0800 on 24 Jul (1406224818), Tiejun Chen wrote:
intel_iommu_map_page() does nothing if VT-d shares EPT page table.
So rmrr_identity_mapping() never create RMRR mapping but in some
cases like some GFX drivers it still need to access RMRR.

Here we will create those RMRR mappings even in shared EPT case.

Signed-off-by: Tiejun Chen <tiejun.chen@xxxxxxxxx>

For the interaction with p2m code:

Acked-by: Tim Deegn <tim@xxxxxxx>

Thanks a lot.


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.


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?

So this should be anther story we need to address.


So I think it would be prudent to at least try to detect a clash here
and return an error.

Or do you already have some better ways to do this? I'd like to code them in another thread.

Tiejun


(BTW, I think this patch can go in as-is, and the address-space clash
be fixed up separately.)

Tim.



_______________________________________________
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®.