[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Issue policing writes from Xen to PV domain memory
>>>> > On adding some debugging, I discovered that it happens after >>>> > mem_access >>>>is >>>>> enabled but xen-access has not started handling events. After >>>>> comparing >>>>the >>>>> stack trace and gla in question There are multiple write faults to >>>>> the runstate_guest(v), each causing an event to be sent to >>>>> xen-access. Since >>>>the >>>>> listener is not handling events yet, the fault continues to occur. I >>>>> am not sure why the listener does not get a chance to run. I also >>>>> do not follow is that why there are multiple faults as the vcpu >>>>> should have been paused >>>>after >>>>> the first event was sent to xen-access and only be resumed after >>>>> violation >>>>has >>>>> been resolved and when it calls xc_access_resume(), which ends up >>>>unpausing >>>>> the vcpu. Or is this occurring because runstate_guest(v).p is being >>>>> accessed from Xen? >>>> >>>>The runstate changes (and hence needs to get written) as a side effect >>>>of pausing the guest (as can be seen from the stack trace). The first >>>>question that needs clarification (for me at least, since I don't know >>>>much about the access stuff for HVM) is how the same situation gets >>>>handled >>>>there: Do Xen writes to HVM guest memory get intercepted? Other than >>>>for PV, they're not going through the same page tables, so special >>>>precautions would be needed to filter them. Quite obviously (I think) >>>>if they're not being filtered for HVM, then they shouldn't be for PV. >>> >>> AFAIK, they are not being filtered for HVM. I brought up a HVM domain >>> and printed out the runstate_guest area value when it is registered. I >>> then ran the xen-access test program to monitor for writes. >>> Interestingly I never saw a GLA that matched the runstate_guest area. >>> This is not the case for a PV domain as it is one of the first violations >>> the >xen- >>access test program sees. >>> Is this an EPT vs regular page table difference as in one case it is shared? >> >>Yes, as said in my earlier reply. And when hypervisor writes aren't subject to >>filtering in HVM, you probably want/need to make things behave that way >for >>PV too (albeit it may not be trivial, as you clearly don't want to start >emulating >>hypervisor accesses). > >The main issue I am seeing is the same violation being sent multiple times to >the mem_event queue and the listener not getting scheduled to run. I would >think that the same issue would happen with a HVM guest but in that case I >don't even see a violation of the runstate_guest area. I guess I should try >figuring out why wqv->esp becomes 0 instead of trying to stop multiple >events for the same violations being sent. If you have a suggestion in the area >I should be looking at, it would be welcome. I meant to say why wqv->esp becomes non-zero in the message above. Thanks, Aravindh _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |