[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

>>>>> Now in our case we add a rule:
>>>>>    - if p2m_access_n is set we also set this mapping.
>>>> Does that not conflict with eventual use mem-access makes of this
>>>> type?
> Do you mean what will happen after we reset these ranges as 
> p2m_access_rw? We already reserve these ranges guest shouldn't access 
> these range actually. And a guest still maliciously access them, that 
> device may not work well.

mem-access is functionality used by a control domain, not the domain
itself. You need to make sure that neither your use of p2m_access_n
can confuse the mem-access code, nor that their use can confuse you.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.