From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57632) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R9PCX-0003kW-3X for qemu-devel@nongnu.org; Thu, 29 Sep 2011 18:35:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R9PCV-0003zv-Td for qemu-devel@nongnu.org; Thu, 29 Sep 2011 18:35:33 -0400 Received: from a82-161-217-249.adsl.xs4all.nl ([82.161.217.249]:19928 helo=pubserv1.fransdb.nl) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R9PCV-0003z2-EI for qemu-devel@nongnu.org; Thu, 29 Sep 2011 18:35:31 -0400 Received: from localhost (localhost [127.0.0.1]) by pubserv1.fransdb.nl (Postfix) with ESMTP id 4C314400BD for ; Fri, 30 Sep 2011 00:35:28 +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 J_JKD3prbJIH for ; Fri, 30 Sep 2011 00:35:25 +0200 (CEST) Received: from [192.168.100.23] (unknown [192.168.100.23]) by pubserv1.fransdb.nl (Postfix) with ESMTPA id 246CA3FC3E for ; Fri, 30 Sep 2011 00:35:25 +0200 (CEST) Message-ID: <4E84F2AC.8070807@fransdb.nl> Date: Fri, 30 Sep 2011 00:35:24 +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.