qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2 4/7] scripts/qemu.py: set predefined machine


From: Cleber Rosa
Subject: Re: [Qemu-devel] [PATCH v2 4/7] scripts/qemu.py: set predefined machine type based on arch
Date: Wed, 10 Oct 2018 13:52:25 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0


On 10/10/18 12:23 PM, Peter Maydell wrote:
> On 10 October 2018 at 16:47, Cleber Rosa <address@hidden> wrote:
>> To make sure we're on the same page, we're still going to have default
>> machine types, based on the arch, for those targets that don't provide
>> one (aarch64 is one example).  Right?
> 
> Does it make sense to define a default? The reason arm
> doesn't specify a default machine type is because you
> can't just run any old guest on any old machine type.
> You need to know "this guest image will run on machine
> type X", and run it on machine type X. This is like
> knowing you need to run a test on x86 PC and not
> on PPC spapr.
> 

While requiring tests to specify every single aspect of the environment
that will be used may be OK for low level unit tests, it puts a lot of
burden on higher level tests (which is supposed to be the vast majority
under tests/acceptance).

>From a test writer perspective, working on these higher level tests, it
may want to make sure that feature "X", unrelated to the target arch,
machine type, etc, "just works".  You man want to look at the "vnc.py"
test for a real world example.

Eduardo has suggested that "make check-acceptance" runs all (possible)
tests on all target archs by default.

> Would it make more sense for each test to specify
> which machine types it can work on?
> 

I think it does, but I believe in the black list approach, instead of
the white list.

The reason for that is that I believe that majority of the tests under
"tests/acceptance" can be made to work on every target (which would be
the default).  So far, I've made sure tests behave correctly on the 5
arches included in the "archs.json" file in this series (x86_64, ppc64,
ppc, aarch64, s390x).

To give a full disclosure, "boot_linux.py" (boots a linux kernel) is
x86_64 specific, and CANCELS when asked to be run on other archs.  But,
on the work I've done top of these series, it already works with ppc64
and aarch64.  Also, "boot_linux.py" sent in another series, (which boots
a full linux guest) is also being adapted to work on most of the target
archs.

And, as an exception, you can still define/check the arch and machine
type *in the test*, if it's not supposed to work on most.

Does that make sense?
- Cleber.

> thanks
> -- PMM
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]