Gregory Haskins wrote:
I still have not converted over to kerneldoc format as I cannot find an
example anywhere yet, and the documentation under
Documentation/kernel-doc-nano-HOWTO was a little vague. Pointers appreciated.
see lib/kref.c for an example.
--
Do not meddle in the
Gregory Haskins wrote:
+
+struct kvm_irqdevice;
+
+struct kvm_irqsink {
+ void (*raise_intr)(struct kvm_irqsink *this,
+ struct kvm_irqdevice *dev);
+
+ void *private;
+};
+
+struct kvm_irqdevice {
+ int (*pending)(struct kvm_irqdevice *this, int flags);
+
On Mon, Apr 09, 2007 at 04:27:54PM -0400, Gregory Haskins wrote:
Here is the next pass of the patch with changes based on feedback.
I still have not converted over to kerneldoc format as I cannot find an
example anywhere yet, and the documentation under
Documentation/kernel-doc-nano-HOWTO
On Tue, Apr 10, 2007 at 3:52 AM, in message [EMAIL PROTECTED],
Avi Kivity [EMAIL PROTECTED] wrote:
Hmm. The current code is synchronous in nature (the vcpu is never
executing while we raise an interrupt, so the INTA is never needed, as
we can ensure the cpu can process the interrupt when
Gregory Haskins wrote:
The NIC raises an interrupt, we have to interrupt the guest to see if its
current IF/cr8 permit interrupt injection, and if not, we have to keep
the interrupt in the irqdevice and request an exit when IF/cr8 permit
injection.
Exactly. The INTR really just
On Tue, Apr 10, 2007 at 8:01 AM, in message [EMAIL PROTECTED],
Avi Kivity [EMAIL PROTECTED] wrote:
Gregory Haskins wrote:
And if we replace read_vector() with ack(), how do we learn of the vector in
the first place? I am guessing that you are thinking that both pending and
read_vector
Gregory Haskins wrote:
On Tue, Apr 10, 2007 at 8:01 AM, in message [EMAIL PROTECTED],
Avi Kivity [EMAIL PROTECTED] wrote:
Gregory Haskins wrote:
And if we replace read_vector() with ack(), how do we learn of the vector
in
the first place? I am guessing that
On Tue, Apr 10, 2007 at 10:46 AM, in message [EMAIL PROTECTED],
Avi Kivity [EMAIL PROTECTED] wrote:
Both the vcpu and the irqdevice are involved in the decision:
- the vcpu holds the IF (or rather, the interrupt window)
- the lapic holds the tpr
- but the vcpu contains the controls
Gregory Haskins wrote:
where - pending() has to program a tpr exit if current tpr masks an
interrupt.
I wasn't planning on the irqdevice having this type of control because I
assumed we would always have these exit types set, but you have highlighted
an interesting point. If we
On Sun, Apr 8, 2007 at 5:58 AM, in message
[EMAIL PROTECTED], Christoph Hellwig [EMAIL PROTECTED]
wrote:
diff -- git a/drivers/kvm/kvm_irqdevice.h b/drivers/kvm/kvm_irqdevice.h
new file mode 100644
index 000..9c91d15
--- /dev/null
+++ b/drivers/kvm/kvm_irqdevice.h
@@ - 0,0 +1,206 @@
Here is the next pass of the patch with changes based on feedback.
I still have not converted over to kerneldoc format as I cannot find an example
anywhere yet, and the documentation under Documentation/kernel-doc-nano-HOWTO
was a little vague. Pointers appreciated.
-Greg
---
KVM: Add
Christoph Hellwig wrote:
+/*--
+ * optimized bitarray object - works like bitarrays in bitops, but uses
+ * a summary field to accelerate lookups. Assumes external locking
+
Hi All,
The following is another patch that I broke out of the in-kernel-apic patch
that I sent earlier. This focuses purely on the irqdevice abstraction without
introducing the concept of the in-kernel LAPIC. It also provides an
implementation of a userint model, which should support a
13 matches
Mail list logo
