[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] vm_event: Implement ARM SMC events
On 4/11/2016 10:47 PM, Tamas K Lengyel wrote: From: Tamas K Lengyel <tklengyel@xxxxxxxxxxxxx> The ARM SMC instructions are already configured to trap to Xen by default. In this patch we allow a user-space process in a privileged domain to receive notification of when such event happens through the vm_event subsystem. This patch will likely needs to be broken up into several smaller patches. Right now what this patch adds (and could be broken into smaller patches accordingly): - Implement monitor_op domctl handler for SOFTWARE_BREAKPOINTs on ARM - Implement vm_event register fill/set routines for ARM. This required removing the function from common as the function prototype now differs on the two archs. - Sending notification as SOFTWARE_BREAKPOINT vm_event from the SMC trap handlers. - Extend the xen-access test tool to receive SMC notification and step the PC manually in the reply. I'm sending it as an RFC to gather feedback on what has been overlooked in this revision. This patch has been tested on a Cubietruck board and works fine, but would probably not work on 64-bit boards. Hi Tamas,If I may, I'm still unable to work at the moment, being ill, but I'm checking the xen-devel lists from time to time. Your patch caught my attention, reminding me of the conversation we had some time ago on this matter. The only real reason I don't see SMC (secure-monitor-call) as being an ideal candidate for this is that, according to the ARM manuals, SMC should directly cause undefined exception if executed from user-mode (EL0), instead of a hypervisor trap - isn't that the case on the machine you tested this on or is this really only for the EL1 of domains? Also:- SMC, by definition, is a call to the secure side, it doesn't relate to debugging directly (it's a syscall to the 'secure' side). There is a viable INT3 equivalent on ARM, that being the BKPT/BRK instruction, using that instead would require a bit more effort (but would, conceptually, be more correct) and might be less performant, I suppose that's why you didn't go for that? - SMC can be disabled by the secure side (over which Xen doesn't have control) - not really a problem on though, since the hypervisor trap happens before that check But these 2 are conceptual problems, they don't impede usage of SMC as you intend in practice. Cheers, Corneliu. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |