[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] xc_evtchn_status fails with EFAULT on HVM, the same on PV works
On Fri, Jan 13, 2017 at 07:27:20PM +0000, Andrew Cooper wrote: > On 13/01/17 18:59, Marek Marczykowski-Górecki wrote: > > On Fri, Jan 13, 2017 at 06:37:06PM +0000, Andrew Cooper wrote: > >> On 13/01/17 18:32, Marek Marczykowski-Górecki wrote: > >>> On Fri, Jan 13, 2017 at 06:15:35PM +0000, Andrew Cooper wrote: > >>>> Can you get the result of this piece of debugging in the failure case? > >>> I've got this: > >>> ** d4v0 CFG(24, 00007f794bd07004, 1) = 24 > >> Silly question (and I really hope the answer isn't yes, but I have a > >> sinking feeling it is). > >> > >> Is the guest in question using SMAP? If so, does disabling SMAP fix the > >> problem? > > How can I check that? If looking at 0x200000 CR4 bit in `xl debug-keys > > v` output enough, then yes - it's enabled. And booting hypervisor with > > smap=0 "fixed" the problem. > > :(, although now I think about it, there might be a quick option. > > > So, what would be the correct solution? I'd prefer not to disable SMAP > > "just" for this reason... > > For the quick option, the privcmd driver in Linux needs a stac()/clac() > pair around the actual hypercall invocation, to whitelist userspace > memory accesses as being ok. > > Something like this (completely untested) > > andrewcoop@andrewcoop:/local/linux.git/arch/x86$ git diff > diff --git a/arch/x86/include/asm/xen/hypercall.h > b/arch/x86/include/asm/xen/hypercall.h > index a12a047..e1b2af9e 100644 > --- a/arch/x86/include/asm/xen/hypercall.h > +++ b/arch/x86/include/asm/xen/hypercall.h > @@ -214,10 +214,12 @@ privcmd_call(unsigned call, > __HYPERCALL_DECLS; > __HYPERCALL_5ARG(a1, a2, a3, a4, a5); > > + stac(); > asm volatile("call *%[call]" > : __HYPERCALL_5PARAM > : [call] "a" (&hypercall_page[call]) > : __HYPERCALL_CLOBBER5); > + clac(); > > return (long)__res; > } Is there any option to do that from hypervisor side? For example somehow modify copy_from_guest/copy_to_guest? I'm not always controlling the VM kernel (for example sometimes I need to cope with the one from Debian stable). > For the longer option, introducing a non-virtual ABI for Xen. This is > going to become a necessary prerequisite to support AMD's Secure Virtual > Encryption technology (where the hypervisor deliberately cannot follow > the pagetables), and would remove the overhead of Xen having to walk the > guest pagetables. > > Another optimisation would be to alter some of the ops to pass their > parameters in registers rather than in memory. There are quite a few > ops which pass pointers to a single int, which could be completed more > efficiently by Xen (for both PV and HVM guests) by avoiding the memory > access entirely. Yes, but it will not solve all the cases. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? Attachment:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |