qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Jan Kiszka <jan.kiszka@siemens.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>
Subject: Re: [Qemu-devel] [RFC v2 6/6] Add C version of rtc-test
Date: Mon, 05 Dec 2011 09:51:38 +0100	[thread overview]
Message-ID: <4EDC861A.1020108@redhat.com> (raw)
In-Reply-To: <4ED91C46.1030804@codemonkey.ws>

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	other threads:[~2011-12-05  8:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-01 18:43 [Qemu-devel] [RFC v2 0/6] qtest unit test framework Anthony Liguori
2011-12-01 18:43 ` [Qemu-devel] [RFC v2 1/6] qtest: add " Anthony Liguori
2011-12-05 14:27   ` Luiz Capitulino
2011-12-01 18:43 ` [Qemu-devel] [RFC v2 2/6] qtest: add support for target-i386 -M pc Anthony Liguori
2011-12-02  7:52   ` Paolo Bonzini
2011-12-29 17:40   ` Peter Maydell
2011-12-29 18:47     ` Anthony Liguori
2011-12-01 18:43 ` [Qemu-devel] [RFC v2 3/6] Add core python test framework Anthony Liguori
2011-12-01 18:43 ` [Qemu-devel] [RFC v2 4/6] Add uart test case Anthony Liguori
2011-12-01 18:43 ` [Qemu-devel] [RFC v2 5/6] Add RTC " Anthony Liguori
2011-12-05 14:32   ` Luiz Capitulino
2011-12-01 18:43 ` [Qemu-devel] [RFC v2 6/6] Add C version of rtc-test Anthony Liguori
2011-12-02 17:25   ` Kevin Wolf
2011-12-02 17:26     ` Anthony Liguori
2011-12-02 17:45       ` Kevin Wolf
2011-12-02 18:20         ` Luiz Capitulino
2011-12-02 18:43         ` Anthony Liguori
2011-12-05  8:51           ` Kevin Wolf [this message]
2011-12-04 10:03 ` [Qemu-devel] [RFC v2 0/6] qtest unit test framework Dor Laor
2011-12-05 15:29   ` Anthony Liguori

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EDC861A.1020108@redhat.com \
    --to=kwolf@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=jan.kiszka@siemens.com \
    --cc=lcapitulino@redhat.com \
    --cc=mst@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).