From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:42061) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R9PQl-0006oD-2x for qemu-devel@nongnu.org; Thu, 29 Sep 2011 18:50:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R9PQj-000234-Kj for qemu-devel@nongnu.org; Thu, 29 Sep 2011 18:50:15 -0400 Received: from a82-161-217-249.adsl.xs4all.nl ([82.161.217.249]:20098 helo=pubserv1.fransdb.nl) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R9PQj-00022p-EL for qemu-devel@nongnu.org; Thu, 29 Sep 2011 18:50:13 -0400 Received: from localhost (localhost [127.0.0.1]) by pubserv1.fransdb.nl (Postfix) with ESMTP id D93ED400B2 for ; Fri, 30 Sep 2011 00:13:51 +0200 (CEST) Received: from pubserv1.fransdb.nl ([127.0.0.1]) by localhost (pubserv1.fransdb.nl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UtUY41tsoLyp for ; Fri, 30 Sep 2011 00:13:48 +0200 (CEST) Received: from [192.168.100.23] (unknown [192.168.100.23]) by pubserv1.fransdb.nl (Postfix) with ESMTPA id A20B74009C for ; Fri, 30 Sep 2011 00:13:48 +0200 (CEST) Message-ID: <4E84ED9B.9020802@fransdb.nl> Date: Fri, 30 Sep 2011 00:13:47 +0200 From: Frans de Boer MIME-Version: 1.0 References: <20110929134727.19559.54734.stgit@ginnungagap.bsc.es> <20110929134749.19559.26774.stgit@ginnungagap.bsc.es> <87y5x76mtk.fsf@ginnungagap.bsc.es> In-Reply-To: <87y5x76mtk.fsf@ginnungagap.bsc.es> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 4/5] backdoor: [softmmu] Add QEMU-side proxy to "libbackdoor.a" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 09/29/2011 11:49 PM, Llu=C3=ADs Vilanova wrote: > Blue Swirl writes: > >> 2011/9/29 Llu=C3=ADs Vilanova: >>> +static uint64_t control_io_read(void *opaque, target_phys_addr_t add= r, unsigned size) >>> +{ >>> + State *s =3D opaque; >>> + >>> + uint64_t res =3D ldq_p(&s->size); >>> + uint8_t *resb =3D (uint8_t*)&res; >>> + return resb[addr % CTRL_BYTES]; > >> I don't think these lines do what you mean, but I'm also not sure what >> it is supposed to mean. > > Pre: only can read on a byte-per-byte basis (as stated in control_ops.i= mpl), > just because the code looks less ugly, and host performance should not = be an > issue here. > > The device is treated as a circular buffer of length CTRL_BYTES > > Reads are only used to get the size of the data channel. > > First line should handle guest/host endianess swapping, although I'm no= t sure if > that's the API I'm supposed to use. > > Then return the N'th byte of the uint64_t variable holding the (endiane= ss-aware) > result. > >>> +} >>> + >>> +static void control_io_write(void *opaque, target_phys_addr_t addr, = uint64_t data, unsigned size) >>> +{ >>> + State *s =3D opaque; >>> + >>> + uint8_t *cmdb =3D (uint8_t*)&s->cmd; >>> + cmdb[addr % CTRL_BYTES] =3D (uint8_t)data; >>> + >>> + if ((addr + size) % CTRL_BYTES =3D=3D 0) { >>> + qemu_backdoor(ldq_p(&s->cmd), s->data_ptr); >>> + } > >> Same here. > > Pre: same as during reads. > > Accumulates writes into s->cmd to build the command the guest is sendin= g us (in > guest endianess). > > When CTRL_BYTES bytes have been written into the device, get the comman= d value > into host endianess and invoke the user-provided backdoor callback. > > This assumes that when executing in KVM, the device handling infrastruc= ture will > get a lock and only one CPU will be sending a backdoor command until co= mpletion. > > > I'll add some comments there and prefix all structs and functions with > "backdoor_", as otherwise debugging could get harder if everyone starte= d > avoiding the prefixes. > > > Lluis > I have not read the whole thread, but being an advisor in matters of=20 information risk management, the very word "backdoor" send quivers along=20 my spine. Why use a backdoor at all? The word alone gives us bad vibes. Using these words will disseminate QEMU from professional use since a=20 possible risk might be introduced (even if it seems documented). So,=20 please clarify the word "backdoor" or change it into something less=20 threatening. regards, Frans de Boer.