Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU

[Avi Kivity <avi@redhat.com>]

On 12/29/2011 07:10 PM, Anthony Liguori wrote:
> On 12/29/2011 11:03 AM, Avi Kivity wrote:
>> On 12/29/2011 06:49 PM, Anthony Liguori wrote:
>>>> However, I don't think it's even necessary.  From a quick read of the
>>>> manual, SMBIOS is just a set of static tables in memory which are
>>>> picked
>>>> up using a signature.  So all we need to do is boot an empty guest,
>>>> read
>>>> its memory, and look for the tables.
>>>
>>> Doesn't it sound a whole nicer use linux.git to parse this information
>>> for us in a friendly, easy to consume fashion?
>>
>> Run 'dmidecode -d /path/to/memory/dump', if you must.
>>
>> I don't think the qemu-test approach is bad, per se, it's just that
>> qtest is better.  It gives you full control over what to fingerprint and
>> is not reliant on Linux not changing.
>
> Maybe.  But I feel a lot more comfortable asking people to write
> qemu-test's than writing low level logic to do this stuff in qtest.

Writing the libOS is definitely a job for the (sub-)maintainers.  The
work to code a unit test for patch X should be O(X).

>>> IRQs.  I think MSI takes a side channel directly to the local APIC, no?
>>
>> Yes, writes to the 1MB @ 0xfee00000 gets translated to MSIs.  So you
>> just translate them to events.
> I currently replace the I/O APIC which seems to be limited to 16
>
> Ah, okay, I wasn't thinking of that.  I'll clean qtest up and resubmit
> next week.

Great.  I'll be happy to help writing libOS.

>>> It also seemed to be reasonably complicated without a clear
>>> advantage.  qtest isn't going to be a supported protocol so we can
>>> certainly change it down the road if we want to.
>>
>> It's a pity not to reuse all the tooling?  Seems like self-NIH.
>
>
> No, it's just going to be more work to reuse things.   I was careful
> to make sure that it was possible down the road.
>
> We have a bit of way to go before the QAPI infrastructure is generic
> enough to be used for something like this.

I've started to simplify the build procedure, maybe it will help a tiny bit.

-- 
error compiling committee.c: too many arguments to function