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

[Anthony Liguori <anthony@codemonkey.ws>]

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.

Maybe over time, we'll have a good enough libOS for qtest that qemu-test won't 
be that useful anymore.  But in the short term, I think we'll get more test 
coverage by having both.

>>>
>>> You mention in the changelog replacing the APIC.  Why can't you do that?
>>
>>
>> I currently replace the I/O APIC which seems to be limited to 16
>> 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.

Ah, okay, I wasn't thinking of that.  I'll clean qtest up and resubmit next week.

>>> It looks great.  One thing I'd change is to use the qmp protocol
>>> (perhaps not the monitor, just the schema/codegen).  Does something
>>> prohibit this?
>>
>>
>> Yeah, I thought about using QMP.  But events are posted in QMP which
>> means that you never get an explicit ACK.  That may not be a problem
>> but it's something I had in mind.
>>
>> 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.

Regards,

Anthony Liguori