From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= Subject: Re: xc_evtchn_status fails with EFAULT on HVM, the same on PV works Date: Fri, 13 Jan 2017 20:40:52 +0100 Message-ID: <20170113194052.GB18728@mail-itl> References: <20170113173130.GI5268@mail-itl> <20170113180348.GJ5268@mail-itl> <3f9e01ca-3450-6af9-eb0c-8c867c3a6f96@citrix.com> <20170113183239.GK5268@mail-itl> <20170113185922.GL1341@mail-itl> <0c47b88f-4130-a9b8-cf93-89ae03b25dab@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6555739886867220880==" Return-path: In-Reply-To: <0c47b88f-4130-a9b8-cf93-89ae03b25dab@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Andrew Cooper Cc: xen-devel List-Id: xen-devel@lists.xenproject.org --===============6555739886867220880== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="NMuMz9nt05w80d4+" Content-Disposition: inline --NMuMz9nt05w80d4+ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 13, 2017 at 07:27:20PM +0000, Andrew Cooper wrote: > On 13/01/17 18:59, Marek Marczykowski-G=C3=B3recki wrote: > > On Fri, Jan 13, 2017 at 06:37:06PM +0000, Andrew Cooper wrote: > >> On 13/01/17 18:32, Marek Marczykowski-G=C3=B3recki 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 cas= e? > >>> I've got this: > >>> ** d4v0 CFG(24, 00007f794bd07004, 1) =3D 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=3D0 "fixed" the problem. >=20 > :(, although now I think about it, there might be a quick option. >=20 > > So, what would be the correct solution? I'd prefer not to disable SMAP > > "just" for this reason... >=20 > 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. >=20 > Something like this (completely untested) >=20 > 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); > =20 > + stac(); > asm volatile("call *%[call]" > : __HYPERCALL_5PARAM > : [call] "a" (&hypercall_page[call]) > : __HYPERCALL_CLOBBER5); > + clac(); > =20 > 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. >=20 > 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. --=20 Best Regards, Marek Marczykowski-G=C3=B3recki 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? --NMuMz9nt05w80d4+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYeS1FAAoJENuP0xzK19cs1KYH/2rBy8sURz8IOPjo0nQFX0Qv F85JMcj/m9BmoPrO+L6PWLkbFJ90m65ylS76KEG+zzLWR7p+dmi6bs6cxIi6/TPy pgQ9ywfgctF1EHOnjZSfp0AGVG+KOrUqqaV2nLCpSGqNMlzpDpI1cJDnOYU+hiX2 7vQGB7sf/KYb1KFFgzG8/UidVdNOsHp8xcK8Qk+Gq+O30zRCmrsMnLX/E5vZM1Tk lht1pHHIr60LLvh4tnrEkP6k1gglPhyZ0r5v97C0zZ8lcpWQoL9b/qT3lxIwMF8v Gm9grsEz0pB9hOlPyRq0Vn0wqdWTx1h7iyicyctKW/Y7a3zRgk2WC7ZL68PqhOg= =LbOd -----END PGP SIGNATURE----- --NMuMz9nt05w80d4+-- --===============6555739886867220880== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============6555739886867220880==--