[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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |