Gregory Haskins wrote:
>
>> Ah, ok -- I misunderstood the whole thing. The way to avoid the race is
>> to disable interrupts before entering the guest. This way the IPI is
>> delayed until you enter guest mode:
>>
>> irq_disable();
>>
>> spin_lock();
>> vcpu- >guest_mode = 1;
>> check_whether_an_irq_is_pending_and_if_so_inject_it();
>> spin_unlock();
>>
>> asm ("vm_entry_sequence");
>>
>> vcpu- >guest_mode = 0;
>>
>> irq_enable(); // currently in the vm entry sequence
>>
>> // recheck here?
>>
>> If the interrupt happens before the spin_lock(), we'll get a non- ipi
>> wakeup and then see it in check_whether(). If it happens after it we'll
>> get an IPI which will be ignored until we're snugly in guest mode.
>>
>
> When I first read this I thought "whoa! you want to disable interrupts during
> the whole time we are in GUEST mode?" But then it dawned on me what you are
> suggesting: Interrupts would be re-enabled after the context switch because
> we re-load the processor state? Cool! The thing I can't wrap my head around
> is what happens when the guest has IF=0 and and external interrupt comes in?
> Would we still exit?
>
It's really subtle.
With respect to interrupts, VT^H^Hthe hardware provides an override over
IF. If an interrupt happens while this override is enabled, we exit
guest mode regardless of the state of IF. In effect interrupts are
enabled but _delivery_ is disabled. Once we exit guest mode, interrupts
become disabled again until we set IF explicitly.
> But that aside, a problem that I see is that (IIUC) IPIs use NMIs not
> EXT-INTs. Assuming that is right, I suppose we might be able to do a similar
> trick except we also disable NMIs first (is this
> possible/recommended/forbidden?).
>
>
IPIs are maskable, but are not exactly EXT-INT, I think.
>> It's best not to use signals internally. Qemu relies on them and we
>> have to support them, but in kernel we should use existing kernel
>> mechanisms.
>>
>
> But Avi, this was *your* idea to use signals ;) But in all seriousness, I
> don't know if I have a choice. I have two requirements which constrain me:
>
> 1) I need an IPI to cause a VMEXIT
>
kick_process() can do that in guest mode. Or even
smp_call_function_single(). Outside guest mode, we do need a signal,
but having it requested via fcntl() seems more flexible to me.
Starting out with a hardcoded signal (and no special treatment for guest
mode) is okay to get things rolling.
> 2) I need to support 2.6.16, strongly preferable as a loadable module.
>
> According to my research (which is undoubtedly not 100% definitive), 2.6.16
> or even the newer kernels do not export most of the IPI facilities.
> send_sig() happens to be exported and it happens to invoke a reschedule_IPI
> under the hood, so its convenient. If there is another way to get access to
> the IPI facility without playing games with signals, I am all ears. But
> until then I don't know what else to do. If I had the luxury of modifying
> the kernel source, we could just export what we needed and be done with it.
>
>
Look at the magic that is kernel/external-module-compat.h and the 'sync'
target of kernel/Makefile.
The idea is that mainline kernel code is as clear and as
use-the-bleedingest-edge-apis as we want, with the external module code
brutally hacked into something that will compile on older kernels. We
go as far back as 2.6.9 IIRC.
>> I was interested in how - >pending() and - >read_vector() and the raise
>> callback interact, but got distracted by the, err, uniqueness of the
>> signal thing.
>>
>
> You still haven't weighed in here ;) Hopefully you have a clearer picture of
> what I was trying to do now at least. Whether you agree or not is another
> matter.
>
My eyes were clouded by the signal thing :)
--
error compiling committee.c: too many arguments to function
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
kvm-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
