interrupt preemption support
PATCH 1/1 interrupt preemption support
This patch adds baseline support for interrupt preemption. This lets one context (virtual SMP vcpu, PV driver, etc) preempt another vcpu which is currently in guest context when an interrupt is posted. The patch consists of the following:
1) Re-worked the vcpu mutex with a new "MPL" construct. This allows updates to the vcpu structure even if the vcpu is currently executing in guest mode. The previous code held a mutex during guest execution.
2) Exposed the previously static kvm_vcpu_ioctl_interrupt() as kvm_vcpu_interrupt so that other mechanisms (PV drivers) can issue interrupts just as the ioctl interface can
3) Utilizes the signal facility to interrupt an executing guest by virtue of the scheduler's IPI facility. All external interrupts (including IPI) will cause a VMEXIT (thanks for the hints, Avi)
Whats missing:
1) SVN support- shouldnt break SVN..it just will serialize access if you try to post an interrupt.
2) IPI currently delivers SIGUSR1, which will cause QEMU to exit on reception. Note however that the code does not currently invoke the send_sig since there are not any parallel vcpu/PV tasks running, thus there is not an issue. Next step is to identify a good signal to use (perhaps we should start defining some RT-SIGS (e.g. KVM_SIG_VIRTUAL_INT = 33) in a header file somewhere.
Signed-off by: Gregory Haskins <[email protected]>
kernel/kvm.h +77 -1
@@ -12,6 +12,8 @@#include <linux/spinlock.h> #include <linux/mm.h> +#include "mpl.h" +#include "vmx.h" #include <linux/kvm.h> #include <linux/kvm_para.h>
@@ -219,15 +221,87 @@ enum { VCPU_SREG_LDTR, }; +typedef enum +{ +KVM_MPL_FREE , +KVM_MPL_VMCS , +KVM_MPL_VCPU , +KVM_MPL_FULL =KVM_MPL_VCPU /* Must be equal to the last entry */ +}kvm_mpl_locktypes_t ; + +#define __KVM_MPL_LOCK (lock, min, max) \ + mpl_lock(lock, min, max) +#define __KVM_MPL_TRYLOCK (lock, min, max) \ + mpl_trylock(lock, min, max) +#define __KVM_MPL_UNLOCK (lock, restore) \ + mpl_unlock(lock, restore) + +// #define MPL_DEBUG + +#ifdef MPL_DEBUG +#define _KVM_MPL_LOCK (lock, min, max) \ +({ \ + int _ret; \ + printk(KERN_CRIT "MPL: Aquire lock %d:%d at %s:%d\n", \ + min, max, __FILE__, __LINE__); \ + dump_stack(); \ + _ret = __KVM_MPL_LOCK(lock, min, max); \ + printk(KERN_CRIT "MPL: Aquired with %d\n", _ret); \ + _ret; \ +}) + +#define _KVM_MPL_TRYLOCK (lock, min, max) \ +({ \ + int _ret; \ + printk(KERN_CRIT "MPL: Aquire trylock %d:%d at %s:%d\n", \ + min, max, __FILE__, __LINE__); \ + dump_stack(); \ + _ret = __KVM_MPL_TRYLOCK(lock, min, max); \ + printk(KERN_CRIT "MPL: Done with %d\n", _ret); \ + _ret; \ +}) +#define _KVM_MPL_UNLOCK (lock, restore) \ +({ \ + int _ret; \ + printk(KERN_CRIT "MPL: Unlock to %d at %s:%d\n", \ + restore, __FILE__, __LINE__); \ + dump_stack(); \ + _ret = __KVM_MPL_UNLOCK(lock, restore); \ + printk(KERN_CRIT "MPL: Unlocked with %d\n", _ret); \ + _ret; \ +}) +#else +#define _KVM_MPL_LOCK __KVM_MPL_LOCK +#define _KVM_MPL_TRYLOCK __KVM_MPL_TRYLOCK +#define _KVM_MPL_UNLOCK __KVM_MPL_UNLOCK +#endif + +/* These macros make the MPL lock behave like a standard mutex +* (which is the behavior we want in all but a few special cases) +*/ +#define KVM_MPL_LOCK (lock) _KVM_MPL_LOCK(lock, KVM_MPL_FREE, KVM_MPL_FULL) +#define KVM_MPL_TRYLOCK (lock) \ +( (_KVM_MPL_TRYLOCK(lock, KVM_MPL_FREE, KVM_MPL_FULL) >= 0) ? 1 : 0 ) +#define KVM_MPL_UNLOCK (lock) _KVM_MPL_UNLOCK(lock, KVM_MPL_FREE) + +/* We use a seperate struct so that we can expand the task related info +* without adding noise to the main kvm_vcpu struct +*/ +struct kvm_vcpu_task { +int running; +struct task_struct *owner; +}; +struct kvm_vcpu {struct kvm *kvm;union {struct vmcs *vmcs;struct vcpu_svm *svm; }; -struct mutex mutex; +mpl_t mpl;int cpu;int launched; +struct kvm_vcpu_task task;int interrupt_window_open;unsigned long irq_summary;/* bit vector: 1 per word in irq_pending */ #define NR_IRQ_WORDS KVM_IRQ_BITMAP_SIZE(unsigned long)
@@ -485,6 +559,8 @@ void kvm_mmu_free_some_pages(struct kvm_int kvm_hypercall (struct kvm_vcpu *vcpu,struct kvm_run *run); +int kvm_vcpu_interrupt (struct kvm_vcpu *vcpu,struct kvm_interrupt *intr); +static inline int kvm_mmu_page_fault (struct kvm_vcpu *vcpu,gva_t gva,u32 error_code) {
kernel/kvm_main.c +46 -16
137 lines not on this page · raw message
kernel/vmx.c +6 -0
@@ -1769,6 +1769,9 @@ again:save_msrs (vcpu->host_msrs, vcpu->nmsrs);load_msrs (vcpu->guest_msrs,NR_BAD_MSRS ); + vcpu->task.running =1 ; +_KVM_MPL_UNLOCK (&vcpu->mpl,KVM_MPL_VMCS );/* Downgrade the lock */ + asm (/* Store host registers */ "pushf \n\t"
@@ -1888,6 +1891,9 @@ again: [cr2]"i"(offsetof(struct kvm_vcpu, cr2)) : "cc", "memory" ); + _KVM_MPL_LOCK(&vcpu->mpl,KVM_MPL_VMCS ,KVM_MPL_FULL );/* Reaquire */ + vcpu->task.running =0 ; + ++kvm_stat.exits;save_msrs (vcpu->guest_msrs,NR_BAD_MSRS );
kernel/mpl.h new file +147 -0
147 lines not on this page · raw message
-------------------------------------------------------------------------
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Gregory Haskins
This patch adds baseline support for interrupt preemption. This lets one context (virtual SMP vcpu, PV driver, etc) preempt another vcpu which is currently in guest context when an interrupt is posted. The patch consists of the following:
1) Re-worked the vcpu mutex with a new "MPL" construct. This allows updates to the vcpu structure even if the vcpu is currently executing in guest mode. The previous code held a mutex during guest execution.
Whoa there. kvm can't just add new locking constructs to the kernel. It has to be added to the kernel _first_, you need to justify it with more than just kvm as a user, show correctness, performance, and scalability.
Once it's accepted, kvm can use it.
Formal issues aside, why is this different from taking nested locks? The paravirt network code congealing in Dor's repo has a spinlock protecting the interrupt bits. The main execution path takes both the vcpu mutex and the irq lock (when necessary), other paths take just the irq lock. This has the added advantage of not requiring a mutex to inject an interrupt, which is often necessary from (host) irq context.
Quoted 2 lines
2) Exposed the previously static
kvm_vcpu_ioctl_interrupt()askvm_vcpu_interruptso that other mechanisms (PV drivers) can issue interrupts just as the ioctl interface can
It's not enough to issue an interrupt, there is a whole dance involved in the guest side to ack it. You need to go through the apic, which is currently emulated in userspace. We may push it to the kernel later.
Quoted 3 lines
Index:
kvm-12/kernel/kvm.h
Please base things off trunk. For kernel code, off the git repository, not the bundled kernel module (which is mangled by the release process in order to accommodate older kernels).
kernel/kvm.h enum { · line 230
Quoted 9 lines
kernel/kvm.h +7
-0+typedef enum +{ +KVM_MPL_FREE , +KVM_MPL_VMCS , +KVM_MPL_VCPU , +KVM_MPL_FULL =KVM_MPL_VCPU /* Must be equal to the last entry */ +}kvm_mpl_locktypes_t ;
Either you or your mailer mangle whitespace horribly.
Signature · 8 lines
Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- 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
A message that is not in the archive (sent off-list or not yet received): 45FA414C.1040703-atKUWr5tajBWk0Htik3J/[email protected]
Quoted 1 line
Quoted 1 line
Quoted 1 line
On Fri, Mar 16, 2007 at 3:03 AM, in message <45FA414C.1040703-atKUWr5tajBWk0Htik3J/[email protected]>,
Quoted 6 lines · Avi Kivity
Quoted 1 line · Gregory Haskins
This patch adds baseline support for interrupt preemption. This lets one
context (virtual SMP vcpu, PV driver, etc) preempt another vcpu which is currently in guest context when an interrupt is posted. The patch consists of the following:
Quoted 1 line
Quoted 7 lines
Quoted 1 line
1) Re- worked the vcpu mutex with a new "MPL" construct. This allows updates
to the vcpu structure even if the vcpu is currently executing in guest mode. The previous code held a mutex during guest execution.
Quoted 2 lines
Whoa there. kvm can't just add new locking constructs to the kernel.
With all due respect, why not? ;) Of course it can. We arent really adding anything exposed to the kernel outside of KVM or even adding a new one from scratch. Its simply derivative from the existing mutex/semphore that we already use. As a philosophical point, surely not ever construct we utilize in KVM has to be trickled down from the upstream kernel, or KVM itself would not exist ;)
Quoted 5 lines
It has to be added to the kernel _first_, you need to justify it with more than just kvm as a user, show correctness, performance, and scalability.
Once it's accepted, kvm can use it.
I understand if what I said may not change your argument against proving the construct against a larger audience, but I thought I would point it out that its really just a struct+mutex in case you only read the comment and not the code. I think it just sounds worse than it is.
Quoted 2 lines
Formal issues aside, why is this different from taking nested locks?
This essentially *is* a set of nested locks, except that it also automatically protects against deadlock. Alternatively I could have written the code to simply have replaced the original vcpu->mutex with something like vcpu->vcms_mutex + vcpu->vcpu_mutex, and then replaced all the calls to mutex_lock(&vcpu->mutex) with a macro that grabs both (in proper order). However, I felt as though my solution was better for two reasons:
1) Its impossible to bungle the lock-ordering to induce deadlock, regardless of nesting depth
2) Its non-contended acquisition overhead is O(1) regardless of nesting depth, whereas true nested locks are O(n) (where n = depth)
In my experience, nested locks work ok if there is only one developer on the project. When you get project newbies (like me w.r.t. KVM ;) ) hacking code in after the fact, bad things can happen pretty easily. I thought this might perhaps be a good way to prevent that. If it turns out you guys dont like it, its no big deal to rip it out and go the more traditional route. I wanted your feedback. Thats why I submitted this now before I had all the issues worked out. ;)
Quoted 6 lines
The paravirt network code congealing in Dor's repo has a spinlock protecting the interrupt bits. The main execution path takes both the vcpu mutex and the irq lock (when necessary), other paths take just the irq lock. This has the added advantage of not requiring a mutex to inject an interrupt, which is often necessary from (host) irq context.
Keep in mind that my primary intention was to fix the kvm_vcpu_(ioctl)_interrupt() function to use finer grained locking than the previous vcpu->mutex that it used to use. Because the old lock was a mutex, the new nested lock was also based on a mutex. So its true that its not interrupt friendly, but it wasn't to begin with. Whether it actually needs to be is something that I do not yet know (see my comments below).
Quoted 9 lines
Quoted 2 lines
2) Exposed the previously static
kvm_vcpu_ioctl_interrupt()as
kvm_vcpu_interruptso that other mechanisms (PV drivers) can issue interrupts just as the ioctl interface canQuoted 1 line
It's not enough to issue an interrupt, there is a whole dance involved in the guest side to ack it. You need to go through the apic, which is currently emulated in userspace. We may push it to the kernel later.
I added this interface as a stab at accommodating your request for PV driver support without fully understanding your requirements. Based on your comments, I assume that the code that invokes the INTERRUPT ioctl must have already updated the APIC model? I will revert this change to make it a static ioctl function again until I can understand how the PV drivers can update the apic (userspace or kernel, whichever it ends up being).
Quoted 8 lines
Quoted 4 lines
Index: kvm-
12/kernel/kvm.hPlease base things off trunk. For kernel code, off the git repository, not the bundled kernel module (which is mangled by the release process in order to accommodate older kernels).
Note that it actually is based off of (approx) trunk, but my quilt series starts with the kvm-12 tarball and thus the directory name. I think my series was patched up to r4524. You comment about git vs tarball is legitimate. I will have to refactor my workflow to utilize git instead of the tarball somehow.
Quoted 12 lines
kernel/kvm.h enum { · line 230
Quoted 10 lines
kernel/kvm.h +7
-0+typedef enum +{ +KVM_MPL_FREE , +KVM_MPL_VMCS , +KVM_MPL_VCPU , +KVM_MPL_FULL =KVM_MPL_VCPU /* Must be equal to the last entry */ +}kvm_mpl_locktypes_t ;Either you or your mailer mangle whitespace horribly.
Its probably a combination of both. Do you guys just use the standard "linux/linus" settings for emacs (or equivalent). Sorry about that. I recently rebuilt my devel machine and don't have my .emacs brought over yet. I will fix this.
-Greg
-------------------------------------------------------------------------
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 4 lines · Gregory Haskins
Quoted 2 lines
Whoa there. kvm can't just add new locking constructs to the kernel.
With all due respect, why not? ;) Of course it can. We arent really adding anything exposed to the kernel outside of KVM or even adding a new one from scratch. Its simply derivative from the existing mutex/semphore that we already use.
Still it's not good practice IMO. If the locking construct is useful, the entire kernel should benefit. If it isn't, we don't want it. And we want all the locking gurus to have a look, not just one.
Quoted 3 lines
As a philosophical point, surely not ever construct we utilize in KVM has to be trickled down from the upstream kernel, or KVM itself would not exist ;)
We try not to introduce anything new, unless it is directly related to virtualization. We want to make our code as boring as possible (but not boringer :)
That's important in not raising the barrier of entry above the minimum possible.
Quoted 9 lines
Quoted 6 lines
It has to be added to the kernel _first_, you need to justify it with more than just kvm as a user, show correctness, performance, and scalability.
Once it's accepted, kvm can use it.
I understand if what I said may not change your argument against proving the construct against a larger audience, but I thought I would point it out that its really just a struct+mutex in case you only read the comment and not the code. I think it just sounds worse than it is.
This will happen to anyone reading the code. People are used to seeing nested locks. If they see something new, they have to drop whatever exciting feature they were developing and go understand it.
Quoted 5 lines
Quoted 3 lines
Formal issues aside, why is this different from taking nested locks?
This essentially *is* a set of nested locks, except that it also automatically protects against deadlock. Alternatively I could have written the code to simply have replaced the original
vcpu->mutexwith something likevcpu->vcms_mutex+vcpu->vcpu_mutex, and then replaced all the calls tomutex_lock(&vcpu->mutex)with a macro that grabs both (in proper order).
Won't that lock out the interrupt user? We want only access to the vcpu to be blocked during guest execution, except for the interrupt area (which is just mutually excluded) and for the mmu area (likewise).
Quoted 5 lines
However, I felt as though my solution was better for two reasons:
1) Its impossible to bungle the lock-ordering to induce deadlock, regardless of nesting depth
2) Its non-contended acquisition overhead is O(1) regardless of nesting depth, whereas true nested locks are O(n) (where n = depth)
First I need to understand how it fits.
Quoted 1 line
In my experience, nested locks work ok if there is only one developer on the project. When you get project newbies (like me w.r.t. KVM ;) ) hacking code in after the fact, bad things can happen pretty easily.
Right, we need to document the mess.
Quoted 2 lines
I thought this might perhaps be a good way to prevent that. If it turns out you guys dont like it, its no big deal to rip it out and go the more traditional route. I wanted your feedback. Thats why I submitted this now before I had all the issues worked out. ;)
Sure, early & often.
Quoted 3 lines
Keep in mind that my primary intention was to fix the kvm_vcpu_(ioctl)_interrupt() function to use finer grained locking than the previous
vcpu->mutexthat it used to use. Because the old lock was a mutex, the new nested lock was also based on a mutex. So its true that its not interrupt friendly, but it wasn't to begin with. Whether it actually needs to be is something that I do not yet know (see my comments below).
It's needed all right.
Quoted 7 lines
Quoted 4 lines
It's not enough to issue an interrupt, there is a whole dance involved in the guest side to ack it. You need to go through the apic, which is currently emulated in userspace. We may push it to the kernel later.
I added this interface as a stab at accommodating your request for PV driver support without fully understanding your requirements. Based on your comments, I assume that the code that invokes the INTERRUPT ioctl must have already updated the APIC model?
Yes.
Quoted 2 lines
Its probably a combination of both. Do you guys just use the standard "linux/linus" settings for emacs (or equivalent).
I use the script suggested in Documentation/CodingStyle, plus the show-trailing-whitespace customization variable, which saves me from committing the sin of leaving trailing whitespace every now and then.
Signature · 8 lines
Do not meddle in the internals of kernels, for they are subtle and quick to panic. ------------------------------------------------------------------------- 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
A message that is not in the archive (sent off-list or not yet received): 45FCD226.2010603-atKUWr5tajBWk0Htik3J/[email protected]
Hi Avi,
You make good points. I will convert to a nest lock design and resubmit. Should I use two mutexes, or a mutex and spinlock?
Also, do you have any suggestions on the signum I should use to IPI the running guest? Should I use one of the normal signals (SIGUSR) or should I start a block of defined signals in the RT range (>32)?
-Greg
Quoted 1 line
Quoted 1 line
Quoted 1 line
On Sun, Mar 18, 2007 at 1:46 AM, in message <45FCD226.2010603-atKUWr5tajBWk0Htik3J/[email protected]>,
Quoted 108 lines · Avi Kivity
Quoted 4 lines · Gregory Haskins
Quoted 2 lines
Whoa there. kvm can't just add new locking constructs to the kernel.
With all due respect, why not? ;) Of course it can. We arent really adding
anything exposed to the kernel outside of KVM or even adding a new one from scratch. Its simply derivative from the existing mutex/semphore that we already use.
Still it's not good practice IMO. If the locking construct is useful, the entire kernel should benefit. If it isn't, we don't want it. And we want all the locking gurus to have a look, not just one.
Quoted 1 line
As a philosophical point, surely not ever construct we utilize in KVM has to
be trickled down from the upstream kernel, or KVM itself would not exist ;)
Quoted 2 lines
We try not to introduce anything new, unless it is directly related to virtualization. We want to make our code as boring as possible (but not boringer :)
That's important in not raising the barrier of entry above the minimum possible.
Quoted 8 lines
Quoted 6 lines
It has to be added to the kernel _first_, you need to justify it with more than just kvm as a user, show correctness, performance, and scalability.
Once it's accepted, kvm can use it.
I understand if what I said may not change your argument against proving the
construct against a larger audience, but I thought I would point it out that its really just a struct+mutex in case you only read the comment and not the code. I think it just sounds worse than it is.
Quoted 1 line
This will happen to anyone reading the code. People are used to seeing nested locks. If they see something new, they have to drop whatever exciting feature they were developing and go understand it.
Quoted 5 lines
Quoted 3 lines
Formal issues aside, why is this different from taking nested locks?
This essentially *is* a set of nested locks, except that it also
automatically protects against deadlock. Alternatively I could have written the code to simply have replaced the original vcpu- >mutex with something like vcpu- >vcms_mutex + vcpu- >vcpu_mutex, and then replaced all the calls to
mutex_lock(&vcpu- >mutex)with a macro that grabs both (in proper order).Won't that lock out the interrupt user? We want only access to the vcpu to be blocked during guest execution, except for the interrupt area (which is just mutually excluded) and for the mmu area (likewise).
Quoted 3 lines
However, I felt as though my solution was better for two reasons:
1) Its impossible to bungle the lock- ordering to induce deadlock, regardless
of nesting depth
Quoted 1 line
2) Its non- contended acquisition overhead is O(1) regardless of nesting
depth, whereas true nested locks are O(n) (where n = depth)
Quoted 1 line
First I need to understand how it fits.
Quoted 1 line
In my experience, nested locks work ok if there is only one developer on the
project. When you get project newbies (like me w.r.t. KVM ;) ) hacking code in after the fact, bad things can happen pretty easily.
Right, we need to document the mess.
Quoted 1 line
I thought this might perhaps be a good way to prevent that. If it turns out
you guys dont like it, its no big deal to rip it out and go the more traditional route. I wanted your feedback. Thats why I submitted this now before I had all the issues worked out. ;)
Quoted 1 line
Sure, early & often.
Quoted 1 line
Keep in mind that my primary intention was to fix the
kvm_vcpu_(ioctl)_interrupt() function to use finer grained locking than the previous vcpu- >mutex that it used to use. Because the old lock was a mutex, the new nested lock was also based on a mutex. So its true that its not interrupt friendly, but it wasn't to begin with. Whether it actually needs to be is something that I do not yet know (see my comments below).
Quoted 2 lines
It's needed all right.
Quoted 6 lines
Quoted 4 lines
It's not enough to issue an interrupt, there is a whole dance involved in the guest side to ack it. You need to go through the apic, which is currently emulated in userspace. We may push it to the kernel later.
I added this interface as a stab at accommodating your request for PV driver
support without fully understanding your requirements. Based on your comments, I assume that the code that invokes the INTERRUPT ioctl must have already updated the APIC model?
Quoted 1 line
Yes.
Quoted 8 lines
Quoted 1 line
Its probably a combination of both. Do you guys just use the standard
"linux/linus" settings for emacs (or equivalent).
Quoted 1 line
I use the script suggested in
Documentation/CodingStyle, plus the show- trailing- whitespace customization variable, which saves me from committing the sin of leaving trailing whitespace every now and then.
-------------------------------------------------------------------------
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines · Gregory Haskins
Hi Avi,
You make good points. I will convert to a nest lock design and resubmit. Should I use two mutexes, or a mutex and spinlock?Also, do you have any suggestions on the signum I should use to IPI the running guest? Should I use one of the normal signals (SIGUSR) or should I start a block of defined signals in the RT range (>32)?
For a short term solution, where the apic is in userspace, we can just say ipi == signal, and not require any locking. Qemu will catch the signal and call the appropriate apic function. The signal number should be set from userspace.
Longer term, with the apic in the kernel, we'll need to protect the apic/interrupt data structures with a spinlock, and use kick_process() or similar instead of a signal.
Signature · 8 lines
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
A message that is not in the archive (sent off-list or not yet received): 45FE9793.3060204-atKUWr5tajBWk0Htik3J/[email protected]
Quoted 10 lines · Avi Kivity
Quoted 8 lines · Gregory Haskins
Hi Avi,
You make good points. I will convert to a nest lock design and
resubmit. Should I use two mutexes, or a mutex and spinlock?Also, do you have any suggestions on the signum I should use to IPI the running guest? Should I use one of the normal signals (SIGUSR) or should I start a block of defined signals in the RT range (>32)?
Quoted 5 lines
For a short term solution, where the apic is in userspace, we can just say ipi == signal, and not require any locking. Qemu will catch the signal and call the appropriate apic function. The signal number should be set from userspace.
Note that as long as the apic code is in userspace, the sending side is also in userspace, so all the IPI related stuff doesn't touch the kernel.
Signature · 8 lines
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
A message that is not in the archive (sent off-list or not yet received): 45FE9827.5030200-atKUWr5tajBWk0Htik3J/[email protected]
Quoted 1 line
Quoted 1 line
Quoted 1 line
On Mon, Mar 19, 2007 at 10:03 AM, in message <45FE9827.5030200-atKUWr5tajBWk0Htik3J/[email protected]>,
Quoted 11 lines · Avi Kivity
Quoted 10 lines · Avi Kivity
Quoted 8 lines · Gregory Haskins
Hi Avi,
You make good points. I will convert to a nest lock design and
resubmit. Should I use two mutexes, or a mutex and spinlock?Also, do you have any suggestions on the signum I should use to IPI the running guest? Should I use one of the normal signals (SIGUSR) or should I start a block of defined signals in the RT range (>32)?
Quoted 8 lines
Quoted 5 lines
For a short term solution, where the apic is in userspace, we can just say ipi == signal, and not require any locking. Qemu will catch the signal and call the appropriate apic function. The signal number should be set from userspace.
Note that as long as the apic code is in userspace, the sending side is also in userspace, so all the IPI related stuff doesn't touch the kernel.
I see. So really the entire approach I took (against the kernel code) is wrong, and I should focus on the QEMU side?
-Greg
-------------------------------------------------------------------------
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
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 7 lines · Gregory Haskins
Quoted 3 lines
Note that as long as the apic code is in userspace, the sending side is also in userspace, so all the IPI related stuff doesn't touch the kernel.
I see. So really the entire approach I took (against the kernel code) is wrong, and I should focus on the QEMU side?
Well, eventually we do want to have the apic in the kernel, and we do want inexpensive inter-vcpu (and driver->vcpu) interrupts. But it seems that the simplest way to get things going is in qemu.
Note that it's not enough; there's the mmu to harden for smp and basic support for creating > 1 vcpus.
Signature · 8 lines
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
Quoted 6 lines
Quoted 5 lines · Avi Kivity
Quoted 4 lines · Gregory Haskins
Hi Avi,
You make good points. I will convert to a nest lock design and
resubmit. Should I use two mutexes, or a mutex and spinlock?
Quoted 6 lines
Quoted 6 lines
Quoted 4 lines
Also, do you have any suggestions on the signum I should use to IPI the running guest? Should I use one of the normal signals (SIGUSR) or should I start a block of defined signals in the RT range (>32)?
For a short term solution, where the apic is in userspace, we can
just
Quoted 7 lines
Quoted 4 lines
say ipi == signal, and not require any locking. Qemu will catch the signal and call the appropriate apic function. The signal number should be set from userspace.
Note that as long as the apic code is in userspace, the sending side is also in userspace, so all the IPI related stuff doesn't touch the
kernel.
You can look at a working copy for the PV network code in my git treegit://kvm.qumranet.com/home/dor/src/linux-2.6, pick the pv-network-driver
And the matching paravirt-network svn branch.
It's working but far from perfect ;)
Quoted 6 lines
--
error compilingcommittee.c: too many arguments to function-----------------------------------------------------------------------
--
Quoted 5 lines
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=DEVD
EV
Quoted 4 lines
_______________________________________________
kvm-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel
-------------------------------------------------------------------------
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