qemu-devel
[Top][All Lists]
Advanced

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

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 2/3] qtest: enable qtest for most targets
Date: Wed, 18 Apr 2012 15:35:50 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

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?

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







reply via email to

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