QTest with TCG?

Hi,

I would like to use qtest for testing hw-models in combination with firmware.

At the moment I'm using the following patch to allow qtest to run without
accel=qtest. I'm mostly interested in the mem access functions and the
interrupt interception. I guess time stepping wouldnt work without
accel=qtest, but maybe that could be an acceptable limitation.

Is there anything in principle with such a setup that would cause problems?

Thanks,
Edgar


commit 947414a56e256139a510a034c02ac277ad577272
Author: Edgar E. Iglesias <edgar.iglesias@gmail.com>
Date:   Wed Apr 10 20:32:17 2013 +0200

    Allow qtest to be used together with a virtual CPU
    
    Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>

"Edgar E. Iglesias" <edgar.iglesias@gmail.com> writes:

> Hi,
>
> I would like to use qtest for testing hw-models in combination with firmware.
>
> At the moment I'm using the following patch to allow qtest to run without
> accel=qtest. I'm mostly interested in the mem access functions and the
> interrupt interception. I guess time stepping wouldnt work without
> accel=qtest, but maybe that could be an acceptable limitation.
>
> Is there anything in principle with such a setup that would cause
> problems?

Interesting.  No, I can't think of any problems in principle with doing
this.  It was not a use case I had considered.

Regards,

Anthony Liguori

>
> Thanks,
> Edgar
>
>
> commit 947414a56e256139a510a034c02ac277ad577272
> Author: Edgar E. Iglesias <edgar.iglesias@gmail.com>
> Date:   Wed Apr 10 20:32:17 2013 +0200
>
>     Allow qtest to be used together with a virtual CPU
>     
>     Signed-off-by: Edgar E. Iglesias <edgar.iglesias@gmail.com>
>
> diff --git a/vl.c b/vl.c
> index c566caf..0dbac29 100644
> --- a/vl.c
> +++ b/vl.c
> @@ -4143,6 +4143,10 @@ int main(int argc, char **argv, char **envp)
>  
>      configure_accelerator();
>  
> +    if (!qtest_enabled() && qtest_chrdev) {
> +        qtest_init();
> +    }
> +
>      machine_opts = qemu_opts_find(qemu_find_opts("machine"), 0);
>      if (machine_opts) {
>          kernel_filename = qemu_opt_get(machine_opts, "kernel");

Il 15/04/2013 21:03, Anthony Liguori ha scritto:
> "Edgar E. Iglesias" <edgar.iglesias@gmail.com> writes:
> 
>> Hi,
>>
>> I would like to use qtest for testing hw-models in combination with firmware.
>>
>> At the moment I'm using the following patch to allow qtest to run without
>> accel=qtest. I'm mostly interested in the mem access functions and the
>> interrupt interception. I guess time stepping wouldnt work without
>> accel=qtest, but maybe that could be an acceptable limitation.

Yes, but using "-icount" would provide more reproducibility perhaps.

>> Is there anything in principle with such a setup that would cause
>> problems?
> 
> Interesting.  No, I can't think of any problems in principle with doing
> this.  It was not a use case I had considered.

Just one thing, how would you synchronize between the firmware and the
testcase?

Paolo

On Tue, Apr 16, 2013 at 07:11:43AM +0200, Paolo Bonzini wrote:
> Il 15/04/2013 21:03, Anthony Liguori ha scritto:
> > "Edgar E. Iglesias" <edgar.iglesias@gmail.com> writes:
> > 
> >> Hi,
> >>
> >> I would like to use qtest for testing hw-models in combination with firmware.
> >>
> >> At the moment I'm using the following patch to allow qtest to run without
> >> accel=qtest. I'm mostly interested in the mem access functions and the
> >> interrupt interception. I guess time stepping wouldnt work without
> >> accel=qtest, but maybe that could be an acceptable limitation.
> 
> Yes, but using "-icount" would provide more reproducibility perhaps.

Yes, thanks.

> 
> >> Is there anything in principle with such a setup that would cause
> >> problems?
> > 
> > Interesting.  No, I can't think of any problems in principle with doing
> > this.  It was not a use case I had considered.
> 
> Just one thing, how would you synchronize between the firmware and the
> testcase?

I guess there are various ways depending on the hw/fw setup.

An example is an on chip subsystem with a remote CPU, FW and a collection
of local devices that expose an well defined interface to the rest
of the system. Maybe through specific IPC fifos or by shared
memory. Normally, other CPUs on the system would request operations
through this interface, but in my case I decouple it so that
qtest based testsuites can bang on the interface. So the interface
itself dictates the sync mechanism.

I'm still WIP with this, but currently I'm using a python based
test infrastrucutre and communicating with the DUT through
SHM. Something like a stripped down dumb version of virtio.

Best regards,
Edgar