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

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




On 2014/10/29 16:44, Jan Beulich wrote:
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

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




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


 


Rackspace

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