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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 29.10.14 at 01:48, <tiejun.chen@xxxxxxxxx> wrote:
> On 2014/10/28 17:34, Jan Beulich wrote:
>>>>> On 28.10.14 at 09:36, <tiejun.chen@xxxxxxxxx> wrote:
>>> On 2014/10/27 17:41, Jan Beulich wrote:
>>>>>>> On 27.10.14 at 03:00, <tiejun.chen@xxxxxxxxx> wrote:
>>>>> n 2014/10/24 18:52, Jan Beulich wrote:
>>>>>>>>> On 24.10.14 at 09:34, <tiejun.chen@xxxxxxxxx> 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
(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


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel