[Top][All Lists]

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

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

From: Kevin Wolf
Subject: Re: [Qemu-devel] [RFC v2 6/6] Add C version of rtc-test
Date: Fri, 02 Dec 2011 18:45:27 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

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) 
>>>   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.


reply via email to

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