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

[Anthony Liguori]

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