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

[Anthony Liguori]

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.

</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