From: Alexander Graf <agraf@suse.de>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] SVM support
Date: Tue, 18 Sep 2007 03:24:36 +0200 [thread overview]
Message-ID: <46EF28D4.4060406@suse.de> (raw)
In-Reply-To: <46EF23BA.10208@suse.de>
Alexander Graf wrote:
> Jocelyn Mayer wrote:
>
>>>
>>> I don't see any practical reason not to do it this way. We could define
>>> a CPU_INTERRUPT_TARGET interrupt, that stores the information in a the
>>> target specific CPUState, but this would hit performance (marginally
>>> though) and does not improve the situation. I don't think that we should
>>> should forcefully try to seperate targets where we are not even close to
>>> running out of constants. If everyone on this list sees the situation as
>>> Jocelyn does, I would be fine with writing a patch that puts target
>>> specific interrupts to the specific targets.
>>>
>>>
>> I was to do the same to add some functionality to the PowerPC target,
>> long time ago, and Fabrice Bellard convinced me not to do and agreed it
>> has been a bad idea to add the target specific CPU_INTERRUPT_xxx flags.
>> Then I did manage the PowerPC target to use only generic
>> CPU_INTERRUPT_xxx and put all other target specific informations in the
>> CPUState structure. It absolutelly changes nothing in terms of
>> functionality nor performance. The only thing is that it makes the
>> generic parts simpler and could even allow the cpu_exec function to
>> contain almost no target specific code, which would really great imho.
>>
>>
>
> I can give that a try :-). Sounds reasonable for me.
>
>
Oh well I just thought about this a bit more and while stumbling across
CPU_INTERRUPT_FIQ which does the same thing one major problem came to me
on that one: Priority. Real interrupts have priority over virtual
interrupts so the VIRQs have to be processed after HARD IRQs, whereas
SMIs and NMIs have to be taken care of before the HARD IRQs. It simply
wouldn't work out to generalize the IRQs, just as it would not work with
the VIRQ, as it has to be handled as a real IRQ but without accessing
the APIC which has to be done for HARD IRQs.
I guess we're stuck with what's there now.
Greetings,
Alex
next prev parent reply other threads:[~2007-09-18 1:23 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-30 14:54 [Qemu-devel] [PATCH] SVM support Alexander Graf
2007-08-30 15:26 ` Bernhard Kauer
2007-08-30 16:01 ` Alexander Graf
2007-09-02 14:48 ` Alexander Graf
2007-09-13 2:49 ` Thiemo Seufer
2007-09-13 15:27 ` Alexander Graf
2007-09-17 8:08 ` J. Mayer
2007-09-17 10:02 ` Alexander Graf
2007-09-17 14:16 ` Jocelyn Mayer
2007-09-18 1:02 ` Alexander Graf
2007-09-18 1:24 ` Alexander Graf [this message]
2007-09-18 10:09 ` J. Mayer
2007-09-18 16:14 ` Blue Swirl
2007-09-17 14:07 ` Thiemo Seufer
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=46EF28D4.4060406@suse.de \
--to=agraf@suse.de \
--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).