Re: [Qemu-devel] [RFC v2 6/6] Add C version of rtc-test

[Kevin Wolf]

Am 02.12.2011 18:26, schrieb Anthony Liguori:
> On 12/02/2011 11:25 AM, Kevin Wolf wrote:
>> Am 01.12.2011 19:43, schrieb Anthony Liguori:
>>> ---
>>>   Makefile   |    4 +
>>>   rtc-test.c |  201 
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>   2 files changed, 205 insertions(+), 0 deletions(-)
>>>   create mode 100644 rtc-test.c
>>>
>>> diff --git a/Makefile b/Makefile
>>> index 301c75e..838cb01 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -215,6 +215,10 @@ $(qga-obj-y) qemu-ga.o: $(QGALIB_GEN) 
>>> $(GENERATED_HEADERS)
>>>
>>>   qemu-ga$(EXESUF): qemu-ga.o $(qga-obj-y) $(qapi-obj-y) $(tools-obj-y) 
>>> $(qobject-obj-y) $(version-obj-y) $(QGALIB_OBJ)
>>>
>>> +libqtest.o: libqtest.c
>>
>> Did you forget to commit libqtest.c?
> 
> Probably, sorry about that.
> 
>> I think your series is a good start, but the examples only use port I/O.
>> Most other tests would probably need to access RAM (not sure if it's
>> convenient to do explicit read/write commands for that), interrupts and
>> some even QMP.
> 
> libqtest.h has:
> 
> bool qtest_get_irq(QTestState *s, int num);
> 
> void qtest_outb(QTestState *s, uint16_t addr, uint8_t value);
> 
> void qtest_outw(QTestState *s, uint16_t addr, uint16_t value);
> 
> void qtest_outl(QTestState *s, uint16_t addr, uint32_t value);
> 
> uint8_t qtest_inb(QTestState *s, uint16_t addr);
> 
> uint16_t qtest_inw(QTestState *s, uint16_t addr);
> 
> uint32_t qtest_inl(QTestState *s, uint16_t addr);
> 
> void qtest_memread(QTestState *s, uint64_t addr, void *data, size_t size);
> 
> void qtest_memwrite(QTestState *s, uint64_t addr, const void *data, size_t 
> size);
> 
> So that's how you read/write memory.  Likewise, for IRQs, you can poll the 
> status of a given IRQ.  I thought about doing some sort of signal magic 
> around 
> but when writing tests, polling the IRQ seems easier to deal with.

Okay, polling interrupts should be good enough for tests.

I guess the test still needs to do everything that a guest OS would have
to do, for example send an EOI to the PIC? We'll probably want to have a
library for such things then, but we can add it with the first test that
uses interrupts.

>> Should the framework and the tests live in the tests/ directory?
> 
> Probably, except that tests/ has it's own Makefile which is sort of awkward. 
> Any objections to moving tests/* to tests/tcg-test and then moving all of the 
> various gtest/check tests to tests/ along with qtest?

No objection, I think this is exactly what we should do.

Kevin