Re: [v7][RFC][PATCH 01/13] xen: RMRR fix

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

On 2014/10/29 16:44, Jan Beulich wrote:
>>>> On 29.10.14 at 01:48, <tiejun.chen@intel.com> wrote:
>> On 2014/10/28 17:34, Jan Beulich wrote:
>>>>>> On 28.10.14 at 09:36, <tiejun.chen@intel.com> wrote:
>>>> On 2014/10/27 17:41, Jan Beulich wrote:
>>>>>>>> On 27.10.14 at 03:00, <tiejun.chen@intel.com> wrote:
>>>>>> n 2014/10/24 18:52, Jan Beulich wrote:
>>>>>>>>>> On 24.10.14 at 09:34, <tiejun.chen@intel.com> wrote:
>>>>>>>> 5. Before we take real device assignment, any access to RMRR may issue
>>>>>>>> ept_handle_violation because of p2m_access_n. Then we just call
>>>>>>>> update_guest_eip() to return.
>>>>>>>
>>>>>>> I.e. ignore such accesses? Why?
>>>>>>
>>>>>> Yeah. This illegal access isn't allowed but its enough to ignore that
>>>>>> without further protection or punishment.
>>>>>>
>>>>>> Or what procedure should be concerned here based on your opinion?
>>>>>
>>>>> If the access is illegal, inject a fault to the guest or kill it, unless you
>>>>
>>>> Kill means we will crash domain? Seems its radical, isn't it? So I guess
>>>> its better to inject a fault.
>>>>
>>>> But what kind of fault you prefer currently?
>>>
>>> #GP (but this being arbitrary is why simply killing the guest is another
>>> option to consider).
>>
>> In this case I think we just need to refer to native behavior. So I feel
>> GP may be a little bit reasonable.
>
> But as said before - prior to switching to raising #GP, clarify for
> yourself what behavior you want and why. It you properly explain

Our previous thought is that, we always reserve these ranges since we 
never allow any stuff to poke them.

But in theory some untrusted VM can maliciously access them, right? So 
we also set p2m_access_n in p2m table then we can intercept this 
approach. But we just don't want to leak anything or introduce any side 
affect since other OSs may touch them by careless behavior, so I think 
its enough to have a lightweight way. I mean it shouldn't be same as 
those broken pages which cause domain crush.

So we just need to return with next eip then let VM/OS itself handle 
such a scenario as its own logic.

Thanks
Tiejun

> (in the patch description) why ignoring the accesses is better (read:
> closer to native behavior in comparable cases), then this is fine with
> me. I.e. I'm not so much questioning the solution, but the lack of
> reasoning why it got chosen.
>
> Jan
>
>
>