[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Issue policing writes from Xen to PV domain memory
>If you want to single step ... well that goes to the point Jan raises below. >You >can't single-step the hypervisor. I guess the right question to ask is "What >would GDB do?". Imagine you are tracing a user-space process with shared >memory and a separate process starts changing that shared memory? > >I think that spells the answer. > >We have the luxury of defining this interface, and the responsibility to keep >it >as stable as possible. I think that for extending to PV we should either (i) >live >with this event merge and not pretend we can even remotely single-step >hypervisor accesses to shared memory -- but keep in mind the potential for >ring exhaustion exists; or (ii) discard altogether accesses by Xen to shared >memory from the set of trackable operations. > >Aravindh, is there a reason not to choose (ii)? > And no, I have no good idea about how to deal with the situation. I > continue to think that this is the wrong overall approach though, due > to the resultant inconsistency with HVM (where Xen writes are being > ignored), i.e. I believe you ought to rather think about making these > not fault, or deal with the faults gracefully and without needing to > emulate the instructions. One possibility I can see would be to clear > CR0.WP in the fault handler (and set a flag that this was done), > restoring it on the path back out of guest memory access function(s). > But that of course implies that the situation can only ever arise for > writes. And it would need to be done extremely carefully to make > sure you don't inadvertently allow writes to regions that are truly > write protected. > >As per above, we could forsake this and choose (ii). > > > > PS: I did try running with a hacked up version where the max ring >buffer > > entries (nr_ents) is 1 and I could not make this situation happen but >I guess > > it is still theoretically possible. Or am I mistaken? > > No, you aren't - if the ring doesn't get consumed from, it will > unavoidably become full at some point. > >Yes the fundamental problem (with PV) remains, if we choose (i). > >Andres > >I am fine with going with option (ii) and keep things consistent with HVM. > >Jan, I will resubmit this patch with the other changes you and Tim asked for. Jan, I am re-opening this thread due to "Xen 4.5 Development update" thread. I was under the impression that you wanted to keep PV on par with HVM and not allow policing of Xen writes to guest memory. So I continued down that path by detecting if the write is coming from Xen and allowing the write fault to be handled gracefully and not passed to the mem_access listener. Please let me know if you are fine with this approach. Thanks, Aravindh _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |