Re: [Xen-devel] xc_hvm_inject_trap() races

["Jan Beulich" <jbeulich@xxxxxxxx>]

>>> Andrei Vlad LUTAS <vlutas@xxxxxxxxxxxxxxx> 11/01/16 5:13 PM >>>

First of all, please don't top post.

>First of all, to answer your original question: the injection decision is made
>when the introspection logic needs to inspect a page that is not present in
>the physical memory. We don't really care if the current instruction triggers
>multiple faults or not (and here I'm not sure what you mean by that - multiple
>exceptions, or multiple EPT violations - but the answer is still the same),
>and removing the page restrictions after the #PF injection is introspection
>specific logic - the address for which we inject the #PF doesn't have to be
>related in any way to the current instruction.

Ah, that's this no-architectural behavior again. What if the OS doesn't fully
carry out the page-in, relying on the #PF to retrigger once the insn for which
it got reported has been restarted? Or what if the page gets paged out again
before the insn actually gets to execute (e.g. because a re-schedule
happened inside the guest on the way out of the #PF handler)? All of this
suggests that you really can't lift any restrictions _before_ seeing what you
need to see.

>Assuming that we wouldn't remove the restrictions and we would rely on
>re-generating the event - that is not acceptable: first of all because the
>instruction would normally be emulated anyway before re-entering the guest,

How would that be a problem?

>and secondly because that is not a normal CPU behavior

This really is the main problem here, afaict.

Jan

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