qemu-devel
[Top][All Lists]
Advanced

[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: Mon, 05 Dec 2011 09:51:38 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

Am 02.12.2011 19:43, schrieb Anthony Liguori:
> On 12/02/2011 11:45 AM, Kevin Wolf wrote:
>> Am 02.12.2011 18:26, schrieb Anthony Liguori:
>>> On 12/02/2011 11:25 AM, Kevin Wolf wrote:
>>> 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.
> 
> No, right now we more or less create a fake I/O APIC.  We don't have to deal 
> with masking in the local APIC, boot strapping, or anything like that.
> 
> It makes writing tests easier but I think it makes supporting MSI a bit more 
> challenging.  I'm not sure how well it will generalize to other platforms 
> either.
> 
> That's one of the reasons I wanted to get an early version out to get some 
> feedback on this.

Hm, if it's useful to have a fake controller probably depends on what
you're trying to do. For writing test code for interrupt controllers
it's probably not helpful.

Now I'm not familiar enough with the interrupt code to say how tight
it's coupled with the actual CPU implementation and how difficult it is
to reuse in the context of a test environment, but I would say that we
should use as much of the real emulation as possible.

Also note that this isn't the only thing that test cases would share:
Most tests will probably want to find some PCI device, virtio tests will
probably want to share some code, and I don't even want to think about
testing USB devices...

Kevin



reply via email to

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