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 19:32:39 +0100 Message-ID: <20170113183239.GK5268@mail-itl> References: <20170113173130.GI5268@mail-itl> <20170113180348.GJ5268@mail-itl> <3f9e01ca-3450-6af9-eb0c-8c867c3a6f96@citrix.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6420936165098340747==" Return-path: In-Reply-To: <3f9e01ca-3450-6af9-eb0c-8c867c3a6f96@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 --===============6420936165098340747== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H7QJU8Gl1+/xsYtC" Content-Disposition: inline --H7QJU8Gl1+/xsYtC Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 13, 2017 at 06:15:35PM +0000, Andrew Cooper wrote: > On 13/01/17 18:03, Marek Marczykowski-G=C3=B3recki wrote: > > On Fri, Jan 13, 2017 at 05:38:42PM +0000, Andrew Cooper wrote: > >> On 13/01/17 17:31, Marek Marczykowski-G=C3=B3recki wrote: > >>> Hi, > >>> > >>> I have a strange problem - xc_evtchn_status fails when running in HVM, > >>> while exactly the same code (same kernel, same application etc) works > >>> fine in PV. I've narrowed it down to copy_from_guest call in > >>> common/event_channel.c, but no idea why it fails there. Xen version is > >>> 4.8.0. kernel is kernel-4.8.13-100.fc23. Any idea? > >> Which specific copy_from_guest() call? > >> > >> Copying data out of a PV guest is different to copying out of a HVM > >> guest, but copy_from_guest() should cope properly with both. > >> > >> However, to progress, it would help to know exactly which piece of data > >> is being requested. > > This one: > > https://github.com/xen-project/xen/blob/stable-4.8/xen/common/event_cha= nnel.c#L1104 > > > > case EVTCHNOP_status: { > > struct evtchn_status status; > > if ( copy_from_guest(&status, arg, 1) !=3D 0 ) > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > return -EFAULT; > > rc =3D evtchn_status(&status); > > if ( !rc && __copy_to_guest(arg, &status, 1) ) > > rc =3D -EFAULT; > > break; > > > > The evtchn_status structure in application is on stack (local variable), > > but I think it shouldn't matter, as libxc copy it to a bounce buffer. > > >=20 > The intent of bounce buffers is certainly to avoid this problem from > happening. >=20 > Is this a 32bit HVM guest? Compat argument translation does make the > logic a little more complicated. No, its 64bit guest. > Can you get the result of this piece of debugging in the failure case? I've got this: ** d4v0 CFG(24, 00007f794bd07004, 1) =3D 24 > diff --git a/xen/common/event_channel.c b/xen/common/event_channel.c > index 638dc5e..ab5d82a 100644 > --- a/xen/common/event_channel.c > +++ b/xen/common/event_channel.c > @@ -1101,8 +1101,13 @@ long do_event_channel_op(int cmd, > XEN_GUEST_HANDLE_PARAM(void) arg) > =20 > case EVTCHNOP_status: { > struct evtchn_status status; > - if ( copy_from_guest(&status, arg, 1) !=3D 0 ) > + unsigned int res =3D copy_from_guest(&status, arg, 1); > + if ( res !=3D 0 ) > + { > + printk("** %pv CFG(%zu, %p, 1) =3D %u\n", > + current, sizeof(status), _p(arg.p), res); > return -EFAULT; > + } > rc =3D evtchn_status(&status); > if ( !rc && __copy_to_guest(arg, &status, 1) ) > rc =3D -EFAULT; --=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? --H7QJU8Gl1+/xsYtC Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYeR1IAAoJENuP0xzK19cs1WkIAI/NJxZmNxzGNKMoum2BAnl4 CRApwCHtOg7I7dKYXA0fItkFnXT527qoKZZVncEXKtQz4htiJIlUo5ztP4ZoBsob HvhHpUDecsWlGi9g+TrbsBwLifTl1B3rGyju1lfPbK32xT+iCmgWKZZBtmRcSzI+ mtPckP+aanSYRalyBeQp0gyUL5WYDjYkSLVnnNytDZ7fK+0a1qdBNZ/tG7vTWL5B zF6E+01uvIz1eobUVSKB3GAioIxfYJDXva7eWy6nD0XVqXKvN4PxIar5EDKFDWox +2FWLVdu3HKdlMm6boDfies3Yn72Xtq7HEvBaPLbdviAkHivx6Ppmwe/4m2OAyA= =ImIP -----END PGP SIGNATURE----- --H7QJU8Gl1+/xsYtC-- --===============6420936165098340747== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --===============6420936165098340747==--