From: Michael Moese <michael.moese@gmail.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] PCI device waiting for some external (shared memory) events
Date: Tue, 10 Sep 2013 18:10:43 +0200 [thread overview]
Message-ID: <CAP8HZJfssZSLPy9V7mT7WtrxgTMC8r2GzBwy3VZXzjDzZKZO_g@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]
Hello dear Qemu developers,
I have some weird issues with a PCI device I have developed.
I am using shared memory to create an abstraction from the Qemu-PCI device
I developed and forward all requests to another process running a SystemC
device (this should not matter here).
In my pci-read and write implementations I lock a mutex on the shared
memory, then write address, data and r/w-flag to the shared memory, then I
poll for a completion-flag.
This seems to work quite fine while writing data, which happen in some kind
of posted writes, so I finish the operation as soon as possible.
When I execute a pci memory read from inside the guest the read-function
still gets executed, but Qemu gets stuck then.
Using gdb I could find out Qemu claims some pthread mutexes (I don't use
pthreads-mutexes myself, so there won't be any conflicts with that) - which
seems to take forever (gave it like 30 minutes).
I hope I could describe my situation somewhat understandable.
Now my question is, am I doing something I must not when just busy-waiting
for the completion flag?
Is there another way to "stop" the simulated CPU during this transfer and
resume afterwards?
Thanks for your time reading this. I'd be happy to get any suggestions, and
if required I could add some code of my experiments.
Michael
--
Michael Moese
Baumgartenweg 1
91452 Wilhermsdorf
Mobil: +49 176 61 05 94 99
Fax: +49 3212 11 42 49 7
[-- Attachment #2: Type: text/html, Size: 1776 bytes --]
next reply other threads:[~2013-09-10 16:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-10 16:10 Michael Moese [this message]
2013-09-10 16:47 ` [Qemu-devel] PCI device waiting for some external (shared memory) events Peter Maydell
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=CAP8HZJfssZSLPy9V7mT7WtrxgTMC8r2GzBwy3VZXzjDzZKZO_g@mail.gmail.com \
--to=michael.moese@gmail.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).