qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Sanidhya Kashyap <sanidhya.iiith@gmail.com>
To: quintela@redhat.com
Cc: qemu list <qemu-devel@nongnu.org>,
	"Dr. David Alan Gilbert" <dgilbert@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC v2 05/12] VMstate test: basic VMState testing mechanism
Date: Tue, 29 Jul 2014 23:29:12 +0530	[thread overview]
Message-ID: <53D7E0F0.8050908@gmail.com> (raw)
In-Reply-To: <87d2cothad.fsf@troll.troll>

>> +{ 'command': 'test-vmstates',
>> +  'data': {'*iterations': 'int',
>> +           '*period':     'int',
>> +           'noqdev':      'bool',
> 
> Do we really care about "noqdev", or should we just "decree" that it is
> "false" always?
> 

Okay. Will remove it.

> 
>> +#define DEBUG_TEST_VMSTATES 1
>> +
>> +#ifndef DEBUG_TEST_VMSTATES
>> +#define DEBUG_TEST_VMSTATES 0
>> +#endif
> 
> If you have the previe line, this ones are not needed.
> 
> 
>> +
>> +#define DPRINTF(fmt, ...) \
>> +    do { \
>> +        if (DEBUG_TEST_VMSTATES) { \
>> +            printf("vmstate_test: " fmt, ## __VA_ARGS__); \
>> +        } \
>> +    } while (0)
> 
> DPRINTF is *so* last year O:-)
> It is considedered better to just add tracepoints to the code.  I think
> that all the DPRINTF's make sense to be a tracepoint, no?
> 
>

yup, tracepoints do make sense. Will incorporate that.

> We need a better preffix that test_vmstates_
> But I can't think of one right now.  Will think later about it.
> 
> 

I am really bad with naming conventions :-/. Whatever seems fit to you.
I'll use that.

>> +static inline bool check_device_name(VMStateLogState *v,
>> +                                     VMStatesQdevDevices *qdevices,
>> +                                     Error **errp)
> 
> Is "inline" needed?  I would expect the compiler to do a reasonable
> decision with an static function called only once?
> 

My mistake. Will correct it.

>> +{
>> +    VMStatesQdevResetEntry *qre;
>> +    strList *devices_name = qdevices->device;
>> +    QTAILQ_INIT(&v->qdev_list);
>> +    bool device_present;
>> +
>> +    /* now, checking against each one */
>> +    for (; devices_name; devices_name = devices_name->next) {
>> +        device_present = false;
>> +        VMStatesQdevResetEntry *new_qre;
>> +        QTAILQ_FOREACH(qre, &vmstate_reset_handlers, entry) {
>> +            if (!strcmp(qre->device_name, devices_name->value)) {
>> +
>> +                device_present = true;
>> +
>> +                new_qre = g_malloc0(sizeof(VMStatesQdevResetEntry));
>> +                new_qre->dev = qre->dev;
>> +                strcpy(new_qre->device_name, qre->device_name);
>> +                QTAILQ_INSERT_TAIL(&v->qdev_list, new_qre, entry);
>> +
>> +                break;
>                    return;
> 
> And remove the whole "device_present" variable and assignation?
> 

Actually, I have used this variable which will help us in deciding
whether the user has provided a sane list of vmstates name's or not. If
the names do not match, then we do not proceed. That is why I have used
the device_present variable. I'll change the variable name.

>> +    if (v->noqdev) {
>> +        DPRINTF("resetting all devices\n");
>> +        qemu_system_reset(VMRESET_SILENT);
> 
> What is diffe9rent between calling with "noqdev" and with an empty
> device list?  I would expect them to be the same list of devices.
> 

Well, they are not. Currently, when qemu_system_reset() is called the
mc->reset is NULL. So, the old way of resetting the device takes place
which has some different devices or might be bus registered. Therefore,
I have tried to provide whatever is there on the table i.e related to
the resetting. But, that is not required, I'll completely remove it.

>> +        f = qemu_bufopen("w", NULL);
>> +        if (!f) {
>> +            goto testing_end;
>> +        }
> 
> I think we can call qemu_bufopen() out of the timer, and then doing the
> free on the cleanup?
> 
> 

If I perform the cleanup at the end, then I will be eating the memory.
When I close the buffer, at least that memory is freed. The other issue
will be taking the read pointer back to the write pointer, of which I
don't know whether there is a support or not.

>> +
>> +        cpu_synchronize_all_states();
>> +
>> +        /* saving the vmsates to memory buffer */
>> +        ret = qemu_save_device_state(f);
>> +        if (ret < 0) {
>> +            goto testing_end;
>> +        }
>> +        save_vmstates_duration = qemu_clock_get_ms(QEMU_CLOCK_REALTIME) -
>> +                                 start_time;
>> +        DPRINTF("iteration: %ld, save time (ms): %ld\n",
>> +                v->current_iteration, save_vmstates_duration);
>> +
>> +        /* clearing the states of the guest */
>> +        test_vmstates_reset_devices(v);
>> +
>> +        start_time = qemu_clock_get_ms(QEMU_CLOCK_REALTIME);
>> +        qsb = qemu_buf_get(f);
>> +        f = qemu_bufopen("r", (QEMUSizedBuffer *)qsb);
> 
> We are only using this function once, can't we convince it to just be
> called "const"?
> 
> 
> ok what are we doing here:
> 
> 
> for(i=0; i< times; i++) {
>        .....
>        f = qemu_bufopen("r", ..);
>        .....
>        f = qemu_buf_get(f);
>        f = qemu_bufopen("w", ..)
>        ...
>        qemu_fclose(f);
> }
> 
> 
> What I propose is switching to something like:
> 
> f = qemu_bufopen("r", ..);
> 
> for(i=0; i< times; i++) {
>        ....
>        qemu_buf_set_ro(f);
>        .....
>        qemu_buf_set_rw(f)
>        ...
> }
> qemu_fclose(f);
> 
> 
> This makes qemu_bufopen() way simpler.  Once there, my understanding is
> that current code is leaking a QEMUBuffer each time that we call
>      qemu_bufopen("w", ...)
> 
> 

Yup, I have missed qemu_fclose(f) before

f = qemu_bufopen("r", ..);

I'll correct it. Now, regarding the qemu_buf_set_ro and qemu_buf_set_rw,
I guess, I'll have to rewind the pointer, for which I have to get some
idea before doing it, or extend the QEMUFile code for memory buffer.


-- 
-----

Sanidhya Kashyap

  reply	other threads:[~2014-07-29 17:59 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-25 15:39 [Qemu-devel] [PATCH RFC v2 00/12] VMState testing Sanidhya Kashyap
2014-07-25 15:39 ` [Qemu-devel] [PATCH RFC v2 01/12] QEMUSizedBuffer/QEMUFile Sanidhya Kashyap
2014-07-28 21:32   ` Eric Blake
2014-08-06 11:11     ` Dr. David Alan Gilbert
2014-07-25 15:39 ` [Qemu-devel] [PATCH RFC v2 02/12] reset handler for qdevified devices Sanidhya Kashyap
2014-07-29 12:43   ` Juan Quintela
2014-07-25 15:39 ` [Qemu-devel] [PATCH RFC v2 03/12] VMState test: query command to extract the qdevified device names Sanidhya Kashyap
2014-07-28 21:47   ` Eric Blake
2014-07-29 12:45   ` Juan Quintela
2014-07-29 15:14     ` Eric Blake
2014-07-29 17:37     ` Sanidhya Kashyap
2014-07-25 15:39 ` [Qemu-devel] [PATCH RFC v2 04/12] VMState test: hmp interface for showing qdevified devices Sanidhya Kashyap
2014-07-25 15:39 ` [Qemu-devel] [PATCH RFC v2 05/12] VMstate test: basic VMState testing mechanism Sanidhya Kashyap
2014-07-28 21:52   ` Eric Blake
2014-07-29 13:40   ` Juan Quintela
2014-07-29 17:59     ` Sanidhya Kashyap [this message]
2014-07-25 15:39 ` [Qemu-devel] [PATCH RFC v2 06/12] VMState test: hmp interface for vmstate testing Sanidhya Kashyap
2014-07-25 15:39 ` [Qemu-devel] [PATCH RFC v2 07/12] VMState test: qmp interface for querying the vmstate testing process Sanidhya Kashyap
2014-07-29 15:17   ` Eric Blake
2014-07-29 16:40     ` Eric Blake
2014-07-25 15:39 ` [Qemu-devel] [PATCH RFC v2 08/12] VMState test: hmp " Sanidhya Kashyap
2014-07-25 15:39 ` [Qemu-devel] [PATCH RFC v2 09/12] VMState test: update period of " Sanidhya Kashyap
2014-07-29 16:48   ` Eric Blake
2014-07-29 18:04     ` Sanidhya Kashyap
2014-07-29 19:42       ` Eric Blake
2014-07-25 15:39 ` [Qemu-devel] [PATCH RFC v2 10/12] VMState test: hmp interface for period update Sanidhya Kashyap
2014-07-25 15:39 ` [Qemu-devel] [PATCH RFC v2 11/12] VMState test: cancel mechanism for an already running vmstate testing process Sanidhya Kashyap
2014-07-29 16:50   ` Eric Blake
2014-07-25 15:39 ` [Qemu-devel] [PATCH RFC v2 12/12] VMState test: hmp interface for cancel mechanism Sanidhya Kashyap
2014-07-29 16:52   ` Eric Blake
2014-07-29 18:06     ` Sanidhya Kashyap
2014-07-30  5:48     ` Markus Armbruster

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=53D7E0F0.8050908@gmail.com \
    --to=sanidhya.iiith@gmail.com \
    --cc=dgilbert@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@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).