[Top][All Lists]

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

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [ANNOUNCE] qemu-test: a set of tests scripts for QEMU
Date: Thu, 29 Dec 2011 11:10:16 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15

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 

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.


Anthony Liguori

reply via email to

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