All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.