artifact download for qtest

artifact download for qtest

[Ani Sinha]

Hi,

I am trying to write a qtest for which I need an IGVM file. I have the
file, about 54 MiB in size. Instead of committing this IGVM binary
file with the test, I wanted to check if I can put it somewhere, say
in a gitlab repo and then make the test download it. This would be
similar to asset downloads for functional tests. No this test cannot
be a python functional test.  I am wondering if anyone has faced this
situation before and what the best way to solve this problem is.

I am very much aware that bios-tabes-test has a bunch of master acpi
blobs checked in. If I recall correctly people dislike this approach
for future tests.

Thanks
Ani

Re: artifact download for qtest

[Thomas Huth]

On 30/05/2026 16.56, Ani Sinha wrote:
> Hi,
> 
> I am trying to write a qtest for which I need an IGVM file. I have the
> file, about 54 MiB in size.

54 MiB is quite big, I agree that we likely don't want to check that into 
the main repository, especially if it is for a test only...
(BTW, what's its compressed size?)

> Instead of committing this IGVM binary
> file with the test, I wanted to check if I can put it somewhere, say
> in a gitlab repo and then make the test download it. This would be
> similar to asset downloads for functional tests. No this test cannot
> be a python functional test.  I am wondering if anyone has faced this
> situation before and what the best way to solve this problem is.

I'm not maintaining the qtests anymore, but I assume that there is no 
interest in duplicating all the asset downloading logic there.

What's the exact reason why you cannot do it as a functional test instead? 
You could maybe also start the qemu binary there with "-accel qtest -qtest 
..." to fake a qtest environment - a little bit cumbersome, but certainly 
doable, I think.

  Thomas

Re: artifact download for qtest

[Fabiano Rosas]

Thomas Huth <thuth@redhat.com> writes:

> On 30/05/2026 16.56, Ani Sinha wrote:
>> Hi,
>> 
>> I am trying to write a qtest for which I need an IGVM file. I have the
>> file, about 54 MiB in size.
>
> 54 MiB is quite big, I agree that we likely don't want to check that into 
> the main repository, especially if it is for a test only...
> (BTW, what's its compressed size?)
>
>> Instead of committing this IGVM binary
>> file with the test, I wanted to check if I can put it somewhere, say
>> in a gitlab repo and then make the test download it. This would be
>> similar to asset downloads for functional tests. No this test cannot
>> be a python functional test.  I am wondering if anyone has faced this
>> situation before and what the best way to solve this problem is.
>
> I'm not maintaining the qtests anymore, but I assume that there is no 
> interest in duplicating all the asset downloading logic there.
>

It would be nice if we could extract the existing code into a little
asset library that could be invoked from the other test frameworks.

> What's the exact reason why you cannot do it as a functional test instead? 
> You could maybe also start the qemu binary there with "-accel qtest -qtest 
> ..." to fake a qtest environment - a little bit cumbersome, but certainly 
> doable, I think.
>
>   Thomas

Re: artifact download for qtest

[Daniel P. Berrangé]

On Mon, Jun 08, 2026 at 04:13:02PM -0300, Fabiano Rosas wrote:
> Thomas Huth <thuth@redhat.com> writes:
> 
> > On 30/05/2026 16.56, Ani Sinha wrote:
> >> Hi,
> >> 
> >> I am trying to write a qtest for which I need an IGVM file. I have the
> >> file, about 54 MiB in size.
> >
> > 54 MiB is quite big, I agree that we likely don't want to check that into 
> > the main repository, especially if it is for a test only...
> > (BTW, what's its compressed size?)
> >
> >> Instead of committing this IGVM binary
> >> file with the test, I wanted to check if I can put it somewhere, say
> >> in a gitlab repo and then make the test download it. This would be
> >> similar to asset downloads for functional tests. No this test cannot
> >> be a python functional test.  I am wondering if anyone has faced this
> >> situation before and what the best way to solve this problem is.
> >
> > I'm not maintaining the qtests anymore, but I assume that there is no 
> > interest in duplicating all the asset downloading logic there.
> >
> 
> It would be nice if we could extract the existing code into a little
> asset library that could be invoked from the other test frameworks.

IMHO that isn't really practical, all the asset handling is in python.
It'd be mad to re-implement that in C and then call it from python,
and the C isn't really going to call the current python either....

> > What's the exact reason why you cannot do it as a functional test instead? 
> > You could maybe also start the qemu binary there with "-accel qtest -qtest 
> > ..." to fake a qtest environment - a little bit cumbersome, but certainly 
> > doable, I think.

..if we didn't have the historical baggage already, then I'd that
qtests should conceptually just be a subset of the functional
tests. Writing them in python would be nicer than doing them in C.

The qtest service is integrated in QEMU, what's missing is

 * the client side to talk the qtest protocol
 * the various bus specific helper APIs

I don't know how hard it would be to bootstrap the client side in
python, but the general qtest protocol is 2000 lines of C, so
probably more like 500 lines of python to replace it, plus whatever
helpers you might want on top. Probably not terribly much work to
get something useful kickstarted.

NB, I am *not* sugggesting re-writing the actual existing tests,
just make it possible to write new qtests in python.

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|

Re: artifact download for qtest

[Fabiano Rosas]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Mon, Jun 08, 2026 at 04:13:02PM -0300, Fabiano Rosas wrote:
>> Thomas Huth <thuth@redhat.com> writes:
>> 
>> > On 30/05/2026 16.56, Ani Sinha wrote:
>> >> Hi,
>> >> 
>> >> I am trying to write a qtest for which I need an IGVM file. I have the
>> >> file, about 54 MiB in size.
>> >
>> > 54 MiB is quite big, I agree that we likely don't want to check that into 
>> > the main repository, especially if it is for a test only...
>> > (BTW, what's its compressed size?)
>> >
>> >> Instead of committing this IGVM binary
>> >> file with the test, I wanted to check if I can put it somewhere, say
>> >> in a gitlab repo and then make the test download it. This would be
>> >> similar to asset downloads for functional tests. No this test cannot
>> >> be a python functional test.  I am wondering if anyone has faced this
>> >> situation before and what the best way to solve this problem is.
>> >
>> > I'm not maintaining the qtests anymore, but I assume that there is no 
>> > interest in duplicating all the asset downloading logic there.
>> >
>> 
>> It would be nice if we could extract the existing code into a little
>> asset library that could be invoked from the other test frameworks.
>
> IMHO that isn't really practical, all the asset handling is in python.
> It'd be mad to re-implement that in C and then call it from python,
> and the C isn't really going to call the current python either....
>

What about a standalone downloader? I'm still thinking about reusing
more of the common operations between test frameworks. Is it feasible to
have a cmdline app that can be invoked by qtest and place artifacts in a
common place?

>> > What's the exact reason why you cannot do it as a functional test instead? 
>> > You could maybe also start the qemu binary there with "-accel qtest -qtest 
>> > ..." to fake a qtest environment - a little bit cumbersome, but certainly 
>> > doable, I think.
>
> ..if we didn't have the historical baggage already, then I'd that
> qtests should conceptually just be a subset of the functional
> tests. Writing them in python would be nicer than doing them in C.
>

But could we make _working_ with them in python be equivalent to C? I
agree it's nice to write tests in a higher level language, but python
specifically is a big pain when it comes to actually finding out why a
test is failing. And debugging is even worse.

The tradeoff is that unittest is clearly superior to glib as a test
runner. Having a more modern way of generating command-lines would be
nice too.

> The qtest service is integrated in QEMU, what's missing is
>
>  * the client side to talk the qtest protocol

python/qemu/machine/qtest.py?

>  * the various bus specific helper APIs
>
> I don't know how hard it would be to bootstrap the client side in
> python, but the general qtest protocol is 2000 lines of C, so
> probably more like 500 lines of python to replace it, plus whatever
> helpers you might want on top. Probably not terribly much work to
> get something useful kickstarted.
>
> NB, I am *not* sugggesting re-writing the actual existing tests,
> just make it possible to write new qtests in python.
>
> With regards,
> Daniel

Re: artifact download for qtest

[Ani Sinha]

On Mon, Jun 8, 2026 at 10:43 PM Thomas Huth <thuth@redhat.com> wrote:
>
> On 30/05/2026 16.56, Ani Sinha wrote:
> > Hi,
> >
> > I am trying to write a qtest for which I need an IGVM file. I have the
> > file, about 54 MiB in size.
>
> 54 MiB is quite big,

I was able to reduce the combined size of 2 files to about 400K
https://gitlab.com/anisinha/qemu/-/commit/6aef476b59443dd1bc570c29e8e5ca43140cfed4

Re: artifact download for qtest

[Ani Sinha]

On Tue, Jun 9, 2026 at 7:54 AM Ani Sinha <anisinha@redhat.com> wrote:
>
> On Mon, Jun 8, 2026 at 10:43 PM Thomas Huth <thuth@redhat.com> wrote:
> >
> > On 30/05/2026 16.56, Ani Sinha wrote:
> > > Hi,
> > >
> > > I am trying to write a qtest for which I need an IGVM file. I have the
> > > file, about 54 MiB in size.
> >
> > 54 MiB is quite big,
>
> I was able to reduce the combined size of 2 files to about 400K
> https://gitlab.com/anisinha/qemu/-/commit/6aef476b59443dd1bc570c29e8e5ca43140cfed4

Compressed size is about 100K but I don't want to introduce dependency
on libarchive preferrably if 400K size is ok.