Re: [v6][PATCH 2/2] xen:vtd: missing RMRR mapping while share EPT

["Jan Beulich" <JBeulich@suse.com>]

>>> On 24.09.14 at 10:23, <yang.z.zhang@intel.com> wrote:
> Since we still have arguments on the whole RMRR patch set, so I list the 
> existing RMRR problem to make sure all of us on the same page. And then we 
> can have a discussion on how to solve them perfectly. I also give my 
> suggestion but it may not be the best solution. Also, if there is any missing 
> problem, please tell me.

Thanks for doing this; it looks complete to me (except for lacking an
explicit statement on the consequences of some of the changes).

> 1. RMRR region isn't reserved in guest e820 table and guest is able to touch 
> it.
> 
> Possible solution: set RMRR region as reserved in guest e820 table and 
> create identity map in EPT and VT-d page table.

And relocate guest RAM accordingly.

> 2. RMRR region may conflict with MMIO.
> 
> Possible solution: Refuse to assign device or reallocate the MMIO.

"Reallocate" is perhaps the wrong term here: Since the allocation of
MMIO resources happens in hvmloader, it's really that this allocation
needs to be done with the RMRRs in mind from the beginning.

> 3. RMRR region isn't checked when updating EPT table and VT-d table.
> 
> Possible solution: Return error when trying to update EPT and VT-d table if 
> the gfn is inside RMRR region.
> 
> 4. RMRR region isn't setup in page table in sharing EPT case.
> 
> Tiejun's two patches are able to fix this issue.
> 
> 5. rmrr_identity_mapping() blindly overwrites what may already be in the 
> page tables(EPT table in share case and VT-table in non-share case).
> 
> Possible solution: Actually, it should be same to issue 1. If RMRR region is 
> reserved in guest e820 table, guest should not touch it. Otherwise, any 
> unpredictable behavior to guest is acceptable.

This leaves aside that not all updates are necessarily caused by
guest activity (i.e. qemu and the tool stack could affect such too).

> 6. Live migration with RMRR region and hotplug.
> 
> Possible solution: Do the checking in tool stack: If the device which 
> requires RMRR but the corresponding region is not reserved in guest e820 or 
> have overlap with MMIO, then refuse to do the hotplug.
> 
> One question, should we fix all of them at once or can we fix them one by 
> one based on severity? For example, the issue 6 happens rarely and I think we 
> can leave it after Xen 4.5.

I really only see two routes for 4.5: Either fix everything properly
or disallow assignment of devices associated with RMRRs altogether
(with log messages clearly pointing to an override command line
option).

Jan