On 30/11/2017 13:51, Peter Maydell wrote: > On 30 November 2017 at 12:40, Paolo Bonzini <pbonz...@redhat.com> wrote: >> On 30/11/2017 13:14, Peter Maydell wrote: >>> On 30 November 2017 at 08:53, Thomas Huth <th...@redhat.com> wrote: >>>> +static const uint8_t kernel_mcf5208[] = { >>>> + 0x41, 0xf9, 0xfc, 0x06, 0x00, 0x00, /* lea 0xfc060000,%a0 */ >>>> + 0x10, 0x3c, 0x00, 0x54, /* move.b #'T',%d0 */ >>>> + 0x11, 0x7c, 0x00, 0x04, 0x00, 0x08, /* move.b #4,8(%a0) >>>> Enable TX */ >>>> + 0x11, 0x40, 0x00, 0x0c, /* move.b %d0,12(%a0) Print >>>> 'T' */ >>>> + 0x60, 0xfa /* bra.s loop */ >>>> +}; >>> >>> This approach doesn't seem to be scalable to me -- are we >>> really going to have 50 or more fragments of hand-coded hex in >>> this file to cover the various board models? >>> >>> I'd much rather see us have a framework for being able >>> to build test blobs from source using a cross compiler >>> setup (and docker or similar so anybody can rebuild >>> the test blobs). That will be much easier to maintain >>> and easier to extend to having tests that test other >>> parts of the board or other aspects of TCG emulation. >> >> It seems a bit overkill, as these snippets are ~16 bytes long. > > They're 16 bytes long because that's about the limit of > what you can do with this approach. The consequence is that > they barely test anything at all.
Certainly they are an awful test for boards, but they are a great smoke test for TCG changes that require modifications in all target/ subdirectories. The infrastructure you want for integration tests is already provided by kvm-unit-tests, which satisfies at least bullets 2-4 from your list below (the first is unclear to me). Thanks, Paolo > A more sensible framework > would allow: > * better testing of TCG instructions more generally > * writing your test cases in C > * more interesting board dependent tests > * "integration test" setups like 'boot entire kernel' > * etc > > thanks > -- PMM >