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

Re: [Xen-devel] Enabling #VE for a domain from dom0



On 24/02/17 14:14, Vlad-Ioan TOPAN wrote:
> Hello,
>
> We are trying to use the #VE support in Xen to monitor memory accesses
> to certain pages from a kernel module in Windows. 
>
> As it is written now, the #VE-enabling code appears to enforce being
> called by a domain for itself (by each VCPU for itself, actually), which
> severely limits its usefulness. Is there an architectural reasoning for
> this or some other factor I'm missing?
>
> The process of enabling #VE as I understand it starts from 
> xc_altp2m_set_vcpu_enable_notify(); further along, when the
> HVMOP_altp2m_vcpu_enable_notify message is handled, several checks are
> made to ensure it's called for the current VCPU. 
>
> Another check is in p2m.c in the function p2m_set_altp2m_mem_access(),
> which clears the "suppress #VE" bit only for pages on the same domain:
>
>     return ap2m->set_entry(ap2m, gfn_l, mfn, PAGE_ORDER_4K, t, a,
>                          (current->domain != d));
>
> The "(current->domain != d)" bit there is the sve parameter.
>
> Is there any reason not to allow cross-domain enabling of #VE?

#VE, by design, raises an exception in non-root context, without
breaking out to the hypervisor.

The vcpu in question needs to set up a suitable #VE handler, so it is
not safe for an external entity to chose when a vcpu should start
receiving #VE's.

~Andrew

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

 


Rackspace

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