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 po
>>> 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 t
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
>>> 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
>
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
>>> 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 interr
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-HO
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
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
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 irqdevi
>>> On Sun, Apr 8, 2007 at 2:47 AM, in message <[EMAIL PROTECTED]>,
Avi Kivity <[EMAIL PROTECTED]> wrote:
> Gregory Haskins wrote:
>> 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 abstra
>>> 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
>>
On Sun, Apr 08, 2007 at 01:23:15PM +0300, Avi Kivity wrote:
> Christoph Hellwig wrote:
> >>+/*--
> >>+ * optimized bitarray object - works like bitarrays in bitops, but uses
> >>+ * a summary field to accelerate lookups. Assumes
Christoph Hellwig wrote:
>> +/*--
>> + * optimized bitarray object - works like bitarrays in bitops, but uses
>> + * a summary field to accelerate lookups. Assumes external locking
>> + *-
> 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 @@
> +/*
> + * kvm_irqdevice.h
No need to mention the file name in the top of file comment. Quite contrary,
Gregory Haskins wrote:
> 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"
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 sy
17 matches
Mail list logo
