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

["Zhang, Yang Z" <yang.z.zhang@intel.com>]

Jan Beulich wrote on 2014-09-24:
> >>> 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.

ok. Let's look into more detail:
1. Whether there has device assigned or not, the RMRR mapping must be created when building e820 table if the VT-d is enabled.
2. Despite of share or non-share case, the RMRR region must be identity map in EPT and VT-d page table.
3. Tiejun's patch uses hypercall to get the RMRR info, is it ok? Or should we get it from xenstore, and then both tools and hvmloader can access it?

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

Yes, you are right.

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

So just do a simple check in EPT table and VT-d table updating is ok?

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

Yes, but qemu and tool stack should not touch the memory marked as reserved in e820. They should only touch the memory that they know.

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

Ok. It makes sense. Do you think it possible to cacth the Xen 4.5 if everything is fixed properly?

> 
> Jan


Best regards,
Yang