Re: re-writing on powerpc

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

 



Scott Wood wrote:
> On Tue, 14 Dec 2010 01:24:50 +0100
> Alexander Graf <alex@xxxxxxxxx> wrote:
>
>   
>> On 14.12.2010, at 01:18, Scott Wood wrote:
>>
>>     
>>> Right, but I'm not talking about an interrupt that happens when the
>>> virtual EE bit is zero.  I'm talking about an interrupt that happens
>>> right in the middle of the paravirt sequence -- after reading int_pending,
>>> but before setting critical to r2.
>>>
>>> It seems like the race window is just narrowed, not eliminated.
>>>       
>> Hrm, is that window really that important? There's usually plenty of interrupts and mmios coming through to always have some check going on.
>>     
>
> It could be important for realtime loads, tickless systems (especially
> if the Linux host eventually grows the ability to be tickless even
> when things are running), etc., and it makes me nervous in general.
>
> It's not something that's going to be causing problems all the time,
> though.
>   

I agree - it's certainly wrong.

>> If it really is important, we could also check int_pending right after the critical section and just do a nop exit.
>>     
>
> Doesn't checking int_pending require clobbering registers, which is why
> we have the critical section in the first place?
>   

The critical section is to prevent us from overwriting the scratch
registers, yeah. And I think you're right - I had a thinko last night.

If we see that we should inject an interrupt, but we're inside of a
critical section, we could set the magic page to r/o and try to find the
critical end at which point we can just inject.

>   
>> That way we worst case waste a few cycles for the useless guest exit,
>> but always fetch interrupts immediately when they occur.
>>     
>
> What useless guest exit?  Either we exit when we see an interrupt
> pending (in which case it's not useless), or we exit all the time, and
> then what's the point of the paravirt?
>   

I was thinking of a case where we get a few false positives. But again,
I probably just had a bad thought :)


Alex

--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM Development]     [KVM ARM]     [KVM ia64]     [Linux Virtualization]     [Linux USB Devel]     [Linux Video]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux