From: Alexander Oleinik <alxndr@bu.edu>
To: John Snow <jsnow@redhat.com>, Stefan Hajnoczi <stefanha@redhat.com>
Cc: Thomas Huth <thuth@redhat.com>,
"pbonzini@redhat.com" <pbonzini@redhat.com>,
"bsd@redhat.com" <bsd@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Laurent Vivier <lvivier@redhat.com>
Subject: Re: [PATCH v3 13/22] libqtest: make qtest_bufwrite send "atomic"
Date: Thu, 19 Sep 2019 15:50:47 -0400 [thread overview]
Message-ID: <3e6476e5-7632-5e2d-5270-b14599ffba35@bu.edu> (raw)
In-Reply-To: <da63050e-73b2-d9ac-112b-75b9a7caa54d@redhat.com>
On 9/19/19 2:56 PM, John Snow wrote:
>
>
> On 9/19/19 6:37 AM, Stefan Hajnoczi wrote:
>> On Wed, Sep 18, 2019 at 11:19:40PM +0000, Oleinik, Alexander wrote:
>>> When using qtest "in-process" communication, qtest_sendf directly calls
>>> a function in the server (qtest.c). Combining the contents of the
>>> subsequent socket_sends into the qtest_sendf, makes it so the server can
>>> immediately handle the command, without building a local buffer and
>>> waiting for a newline.
>>>
>>> Signed-off-by: Alexander Oleinik <alxndr@bu.edu>
>>> ---
>>> tests/libqtest.c | 4 +---
>>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>>
>>> diff --git a/tests/libqtest.c b/tests/libqtest.c
>>> index 19feea9e17..d770462869 100644
>>> --- a/tests/libqtest.c
>>> +++ b/tests/libqtest.c
>>> @@ -1086,9 +1086,7 @@ void qtest_bufwrite(QTestState *s, uint64_t addr, const void *data, size_t size)
>>> gchar *bdata;
>>>
>>> bdata = g_base64_encode(data, size);
>>> - qtest_sendf(s, "b64write 0x%" PRIx64 " 0x%zx ", addr, size);
>>> - socket_send(s->fd, bdata, strlen(bdata));
>>> - socket_send(s->fd, "\n", 1);
>>> + qtest_sendf(s, "b64write 0x%" PRIx64 " 0x%zx %s\n", addr, size, bdata);
>>> qtest_rsp(s, 0);
>>> g_free(bdata);
>>> }
>>> --
>>> 2.23.0
>>
>> Cc John Snow, who added the b64write command.
>>
>> The downside to doing this is that sprintf-formatting needs to be
>> performed on the entire base64 buffer. This slows things down slightly
>> and a larger temporary buffer needs to be allocated, but I'm not sure it
>> matters.
>>
>
> *struggles to remember*
>
> I guess I wanted something that had some space savings while maintaining
> some semblance of debuggability. This is almost certainly meant for AHCI
> tests where it's writing various patterns to large blocks of memory.
>
> I doubt I really measured the performance of it, but it seemed like the
> way to go for transferring medium amounts of data at the time via the
> qtest protocol.
>
> Looks like I am the only user of it, still:
>
> tests/ahci-test.c: qtest_bufwrite(ahci->parent->qts, ptr, tx, bufsize);
> tests/ahci-test.c: qtest_bufwrite(ahci->parent->qts, ptr, tx, bufsize);
> tests/libqos/ahci.c: qtest_bufwrite(ahci->parent->qts, ptr,
> buffer, bufsize);
>
> The buffers can be quite large, so you might be re-buffering a decent
> amount of data from the sender now.
>
> 1, Are large transfers like this guaranteed to be atomic anyway? What
> kind of socket is it? we're probably eclipsing frame and packet sizes here.
>
> 2, I am not sure what being "atomic" affords us in terms of allowing the
> server to not wait for newlines, how does this change help?
>
> --js
>
I'm modifying qtest to allow the server and client to co-exist within
the same process (facilitating coverage-guided fuzzing). One of the
modifications is making qtest_sendf directly call a function in
qtest.c. All the other qtest commands are sent with a single
qtest_sendf call, so the qtest.c function could immediately call
qtest_process_command. This breaks if the command is sent with
different qtest_send/socket_send calls, as in b64write.
It should be simple to change qtest_server_inproc_recv (the qtest.c
receiver) to
wait for an "\n" prior to qtest_process_command, so I will probably do
that and
then normal(socket) qtest will keep the memory-reduction benefits of the
non-"atomic" approach.
As a side note, would qtest_memwrite, also benefit from splitting up the
send
command?
for (i = 0; i < size; i++) {
sprintf(&enc[i * 2], "%02x", ptr[i]);
}
qtest_sendf(s, "write 0x%" PRIx64 " 0x%zx 0x%s\n", addr, size, enc);
qtest_rsp(s, 0);
g_free(enc);
next prev parent reply other threads:[~2019-09-19 20:05 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-18 23:19 [Qemu-devel] [PATCH v3 00/22] Add virtual device fuzzing support Oleinik, Alexander
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 01/22] softmmu: split off vl.c:main() into main.c Oleinik, Alexander
2019-09-19 10:03 ` Stefan Hajnoczi
2019-09-19 13:01 ` Oleinik, Alexander
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 02/22] libqos: Rename i2c_send and i2c_recv Oleinik, Alexander
2019-09-19 6:01 ` Thomas Huth
2019-09-19 10:05 ` Stefan Hajnoczi
2019-09-19 11:15 ` Paolo Bonzini
2019-09-19 13:23 ` Oleinik, Alexander
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 03/22] fuzz: Add FUZZ_TARGET module type Oleinik, Alexander
2019-09-19 10:06 ` Stefan Hajnoczi
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 04/22] qtest: add qtest_server_send abstraction Oleinik, Alexander
2019-09-19 10:10 ` Stefan Hajnoczi
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 05/22] libqtest: Add a layer of abstraciton to send/recv Oleinik, Alexander
2019-09-19 10:24 ` Stefan Hajnoczi
2019-09-19 11:18 ` Paolo Bonzini
2019-09-19 13:27 ` Oleinik, Alexander
2019-09-19 14:27 ` Paolo Bonzini
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 06/22] fuzz: add configure flag --enable-fuzzing Oleinik, Alexander
2019-09-19 10:28 ` Stefan Hajnoczi
2019-09-19 13:07 ` Oleinik, Alexander
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 07/22] fuzz: Add target/fuzz makefile rules Oleinik, Alexander
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 08/22] module: check module wasn't already initialized Oleinik, Alexander
2019-09-19 10:30 ` Stefan Hajnoczi
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 09/22] qtest: add in-process incoming command handler Oleinik, Alexander
2019-09-19 10:31 ` Stefan Hajnoczi
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 10/22] tests: provide test variables to other targets Oleinik, Alexander
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 11/22] libqos: split qos-test and libqos makefile vars Oleinik, Alexander
2019-09-26 12:04 ` Thomas Huth
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 12/22] libqos: move useful qos-test funcs to qos_external Oleinik, Alexander
2019-09-19 10:34 ` Stefan Hajnoczi
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 13/22] libqtest: make qtest_bufwrite send "atomic" Oleinik, Alexander
2019-09-19 10:37 ` Stefan Hajnoczi
2019-09-19 18:56 ` John Snow
2019-09-19 19:36 ` Oleinik, Alexander
2019-09-20 0:49 ` John Snow
2019-09-19 19:50 ` Alexander Oleinik [this message]
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 14/22] libqtest: add in-process qtest.c tx/rx handlers Oleinik, Alexander
2019-09-19 10:42 ` Stefan Hajnoczi
2019-09-19 13:22 ` Oleinik, Alexander
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 15/22] fuzz: Add target/fuzz makefile rules Oleinik, Alexander
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 16/22] fuzz: add fuzzer skeleton Oleinik, Alexander
2019-09-19 12:48 ` Stefan Hajnoczi
2019-09-19 13:49 ` Oleinik, Alexander
2019-09-20 9:30 ` Stefan Hajnoczi
2019-09-23 14:55 ` Darren Kenny
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 17/22] fuzz: add support for fork-based fuzzing Oleinik, Alexander
2019-09-19 12:54 ` Stefan Hajnoczi
2019-09-19 14:01 ` Oleinik, Alexander
2019-09-20 9:33 ` Stefan Hajnoczi
2019-09-30 15:17 ` Alexander Oleinik
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 18/22] fuzz: expose fuzz target name Oleinik, Alexander
2019-09-24 7:49 ` Darren Kenny
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 19/22] fuzz: add support for qos-assisted fuzz targets Oleinik, Alexander
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 20/22] fuzz: add i440fx " Oleinik, Alexander
2019-09-19 13:08 ` Stefan Hajnoczi
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 21/22] fuzz: add virtio-net fuzz target Oleinik, Alexander
2019-09-18 23:19 ` [Qemu-devel] [PATCH v3 22/22] fuzz: add documentation to docs/devel/ Oleinik, Alexander
2019-09-23 14:54 ` Darren Kenny
2019-09-19 10:33 ` [Qemu-devel] [PATCH v3 00/22] Add virtual device fuzzing support Stefan Hajnoczi
2019-09-19 13:10 ` Stefan Hajnoczi
2019-09-20 0:19 ` no-reply
2019-09-20 0:19 ` no-reply
2019-09-20 0:21 ` no-reply
2019-09-20 0:24 ` no-reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3e6476e5-7632-5e2d-5270-b14599ffba35@bu.edu \
--to=alxndr@bu.edu \
--cc=bsd@redhat.com \
--cc=jsnow@redhat.com \
--cc=lvivier@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).