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

["Chen, Tiejun" <tiejun.chen@intel.com>]

On 2014/9/25 16:08, Jan Beulich wrote:
>>>> On 25.09.14 at 03:53, <yang.z.zhang@intel.com> wrote:
>> Jan Beulich wrote on 2014-09-24:
>>>>>> On 24.09.14 at 10:23, <yang.z.zhang@intel.com> wrote:
>>>> 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?
>
> The hypercall is clearly the route to go imo - xenstore would be a

Yes.

And based on recent discussion looks nothing to block covering these all 
7 problems with current hypercall implementation, right? I means we 
already took more time to get current hypercall codes, and looks its 
clearly good enough, right? So maybe we just can go through fixing these 
problems we were discussing.

Thanks
Tiejun

> pretty crude mechanism for conveying that information (and using
> the hypercall approach precludes neither the tools nor hvmloader
> from obtaining that data).
>
>>>> 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?
>
> I think so - anything more sophisticated (like checking in the tools)
> will not give any better results (except for a more explicit error
> message maybe, but this can certainly be had equally well by using a
> very specific error code should the hypervisor side check fail).
>
>>>> 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?
>
> Considering it's a bug that gets fixed, I would think so. But as for
> anything more involved, Konrad as the release manager will have
> the final say.
>
> Jan
>
>
>