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

[Blue Swirl]

On Wed, Apr 18, 2012 at 20:35, Anthony Liguori <address@hidden> wrote:
> On 04/18/2012 03:28 PM, Blue Swirl wrote:
>>
>> 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.
>
>
> So how does one test MIPS system emulation?

Maybe there are BIOS files which are not redistributable.

>
> Regards,
>
> Anthony Liguori
>
>
>>
>>>
>>> </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
>>>>
>>>
>>
>