Re: [Qemu-devel] [PATCH 2/3] qtest: enable qtest for most targets

[Blue Swirl]

On Tue, Apr 17, 2012 at 21:33, Anthony Liguori <address@hidden> wrote:
> On 04/17/2012 03:59 PM, Peter Maydell wrote:
>>
>> On 17 April 2012 21:43, Blue Swirl<address@hidden>  wrote:
>>>
>>> On Tue, Apr 17, 2012 at 20:31, Peter Maydell<address@hidden>
>>>  wrote:
>>>>
>>>> Well, it could. But we should make that decision based on whether it
>>>> makes sense and has a use case for actual users of the board, not
>>>> because we're trying to get away with not having a setup that lets
>>>> us properly unit test devices.
>>>
>>>
>>> I disagree. I see many benefits in qtest and very little downsides in
>>> changes like these.
>>>
>>> qtest is a tool to let developers test the changes they make to
>>> devices, so breakages shouldn't be so common. This should improve the
>>> development process in QEMU tremendously.
>>
>>
>> I'm entirely in favour of having a decent testing framework so we
>> can easily write unit tests for device models. What I don't understand
>> is why a developer only unit testing tool seems to require changes
>> to user visible behaviour across dozens of board models. Something
>> is wrong in its design somewhere, and I think that's what I'm
>> objecting to as much as to the specific detail of what's being
>> changed in this patch.
>
>
> <rant>
>
> Kernel loading is a hack.  I'll go out on a limb and say that most non-x86
> boards are doing it completely wrong.  Messing around with CPU state has no
> business in machine init.  It creates horrible dependencies about RAM
> initialization order and problems for reset/live migration.
>
> The kernel should be presented as a virtual device (an emulated flash or
> whatever) and there should be firmware that loads the kernel appropriately.
> Then we wouldn't need changes like this in the first place.

BIOS is no hack, it is not used by qtest, MIPS refuses to start without one and
we don't have any.

>
> </rant>
>
> But now that that's out of my system, I don't think we should change every
> board that's doing direct kernel loading.  But this is why we need to make a
> change like this.  The boards are "wrong in its design somewhere".
>
>
>> (And I don't want us to add lots of tests
>> and/or changes to the code before we fix whatever the problem is.)
>
>
> If you'd like to change all of the boards to behave in a way that's sensibly
> similar to how actual hardware would work, that's fine by me :-)
>
>
> Regards,
>
> Anthony Liguori
>
>> -- PMM
>>
>