qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] SVM support


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH] SVM support
Date: Tue, 18 Sep 2007 03:24:36 +0200
User-agent: Thunderbird 2.0.0.4 (X11/20070613)

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




reply via email to

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