On Mon, 11 May 2009, Gregory Haskins wrote:
> Davide Libenzi wrote:
> > On Wed, 6 May 2009, Gregory Haskins wrote:
> >
> >
> >> If there isn't any more feedback on the series from Al, Avi,
> >> etc...please formally submit your eventfd patch so this series is
> >> available for Avi to pull in f
Davide Libenzi wrote:
> On Wed, 6 May 2009, Gregory Haskins wrote:
>
>
>> If there isn't any more feedback on the series from Al, Avi,
>> etc...please formally submit your eventfd patch so this series is
>> available for Avi to pull in for inclusion when/if he deems it fit.
>>
>
> Did you d
On Wed, 6 May 2009, Gregory Haskins wrote:
> If there isn't any more feedback on the series from Al, Avi,
> etc...please formally submit your eventfd patch so this series is
> available for Avi to pull in for inclusion when/if he deems it fit.
Did you decide you will be using those bits?
- Davi
Davide Libenzi wrote:
On Thu, 7 May 2009, Avi Kivity wrote:
What's your take on adding irq context safe callbacks to irqfd?
To give some background here, we would like to use eventfd as a generic
connector between components, so the components do not know about each other.
So far eventfd su
On Thu, 7 May 2009, Avi Kivity wrote:
> What's your take on adding irq context safe callbacks to irqfd?
>
> To give some background here, we would like to use eventfd as a generic
> connector between components, so the components do not know about each other.
> So far eventfd successfully abstrac
Davide Libenzi wrote:
On Thu, 7 May 2009, Avi Kivity wrote:
Davide Libenzi wrote:
What's your take on adding irq context safe callbacks to irqfd?
To give some background here, we would like to use eventfd as a generic
connector between components, so the components do not kn
On Thu, 7 May 2009, Avi Kivity wrote:
> Davide Libenzi wrote:
> >
> > > What's your take on adding irq context safe callbacks to irqfd?
> > >
> > > To give some background here, we would like to use eventfd as a generic
> > > connector between components, so the components do not know about ea
Davide Libenzi wrote:
What's your take on adding irq context safe callbacks to irqfd?
To give some background here, we would like to use eventfd as a generic
connector between components, so the components do not know about each other.
So far eventfd successfully abstracts among components in
Gregory Haskins wrote:
This is my preferred option. For a virtio-net-server in the kernel,
we'd service its eventfd in qemu, raising and lowering the pci
interrupt in the traditional way.
But we'd still need to know when to lower the interrupt. How?
IIUC, isn't that usually device/
Avi Kivity wrote:
> Gregory Haskins wrote:
>> One thing I was thinking here was that I could create a flag for the
>> kvm_irqfd() function for something like "KVM_IRQFD_MODE_CLEAR". This
>> flag when specified at creation time will cause the event to execute a
>> clear operation instead of a set w
On Thu, 7 May 2009, Avi Kivity wrote:
> What's your take on adding irq context safe callbacks to irqfd?
>
> To give some background here, we would like to use eventfd as a generic
> connector between components, so the components do not know about each other.
> So far eventfd successfully abstrac
Gregory Haskins wrote:
One thing I was thinking here was that I could create a flag for the
kvm_irqfd() function for something like "KVM_IRQFD_MODE_CLEAR". This
flag when specified at creation time will cause the event to execute a
clear operation instead of a set when triggered. That way, the
Marcelo Tosatti wrote:
> On Thu, May 07, 2009 at 12:48:21PM +0300, Avi Kivity wrote:
>
>> Davide Libenzi wrote:
>>
>>> On Wed, 6 May 2009, Gregory Haskins wrote:
>>>
>>>
>>>
I think we are ok in this regard (at least in v5) without the
callback. kvm holds irqfd, which h
On Thu, May 07, 2009 at 12:48:21PM +0300, Avi Kivity wrote:
> Davide Libenzi wrote:
>> On Wed, 6 May 2009, Gregory Haskins wrote:
>>
>>
>>> I think we are ok in this regard (at least in v5) without the
>>> callback. kvm holds irqfd, which holds eventfd. In a normal
>>> situation, we will
>>>
Davide Libenzi wrote:
On Wed, 6 May 2009, Gregory Haskins wrote:
I think we are ok in this regard (at least in v5) without the callback.
kvm holds irqfd, which holds eventfd. In a normal situation, we will
have eventfd with 2 references. If userspace closes the eventfd, it
will drop 1 of
Davide Libenzi wrote:
> On Wed, 6 May 2009, Gregory Haskins wrote:
>
>
>> I think we are ok in this regard (at least in v5) without the callback.
>> kvm holds irqfd, which holds eventfd. In a normal situation, we will
>> have eventfd with 2 references. If userspace closes the eventfd, it
>> w
On Wed, 6 May 2009, Gregory Haskins wrote:
> I think we are ok in this regard (at least in v5) without the callback.
> kvm holds irqfd, which holds eventfd. In a normal situation, we will
> have eventfd with 2 references. If userspace closes the eventfd, it
> will drop 1 of the 2 eventfd file r
Davide Libenzi wrote:
> On Wed, 6 May 2009, Gregory Haskins wrote:
>
>
>> Al, Davide,
>>
>> Gregory Haskins wrote:
>>
>>> +
>>> +int
>>> +kvm_irqfd(struct kvm *kvm, int gsi, int flags)
>>> +{
>>> + struct _irqfd *irqfd;
>>> + struct file *file = NULL;
>>> + int fd = -1;
>>> + int re
On Wed, 6 May 2009, Gregory Haskins wrote:
> Al, Davide,
>
> Gregory Haskins wrote:
> > +
> > +int
> > +kvm_irqfd(struct kvm *kvm, int gsi, int flags)
> > +{
> > + struct _irqfd *irqfd;
> > + struct file *file = NULL;
> > + int fd = -1;
> > + int ret;
> > +
> > + irqfd = kzalloc(sizeof(
Al, Davide,
Gregory Haskins wrote:
> +
> +int
> +kvm_irqfd(struct kvm *kvm, int gsi, int flags)
> +{
> + struct _irqfd *irqfd;
> + struct file *file = NULL;
> + int fd = -1;
> + int ret;
> +
> + irqfd = kzalloc(sizeof(*irqfd), GFP_KERNEL);
> + if (!irqfd)
> + re
Avi Kivity wrote:
> Gregory Haskins wrote:
>> Avi Kivity wrote:
>>
>>> Gregory Haskins wrote:
>>>
>>>
+int
+kvm_irqfd(struct kvm *kvm, int gsi, int flags)
+{
+struct _irqfd *irqfd;
+struct file *file = NULL;
+int fd = -1;
+int ret;
+
>>>
Gregory Haskins wrote:
Avi Kivity wrote:
Gregory Haskins wrote:
+int
+kvm_irqfd(struct kvm *kvm, int gsi, int flags)
+{
+struct _irqfd *irqfd;
+struct file *file = NULL;
+int fd = -1;
+int ret;
+
+irqfd = kzalloc(sizeof(*irqfd), GFP_KERNEL);
+if (!irqfd)
+
Avi Kivity wrote:
> Gregory Haskins wrote:
>
>> +int
>> +kvm_irqfd(struct kvm *kvm, int gsi, int flags)
>> +{
>> +struct _irqfd *irqfd;
>> +struct file *file = NULL;
>> +int fd = -1;
>> +int ret;
>> +
>> +irqfd = kzalloc(sizeof(*irqfd), GFP_KERNEL);
>> +if (!irqfd)
>> +
Gregory Haskins wrote:
+struct kvm_irqfd {
+__u32 gsi;
+__u32 flags;
+};
+
Please add some reserved space here.
Ack. Any rule of thumb here? How about a "__u8 pad[16]" ?
I'd round it up so the whole thing is 32 bytes (not that it matters).
--
Do not meddle in t
Avi Kivity wrote:
> Gregory Haskins wrote:
>> KVM provides a complete virtual system environment for guests, including
>> support for injecting interrupts modeled after the real
>> exception/interrupt
>> facilities present on the native platform (such as the IDT on x86).
>> Virtual interrupts can c
Gregory Haskins wrote:
KVM provides a complete virtual system environment for guests, including
support for injecting interrupts modeled after the real exception/interrupt
facilities present on the native platform (such as the IDT on x86).
Virtual interrupts can come from a variety of sources (em
KVM provides a complete virtual system environment for guests, including
support for injecting interrupts modeled after the real exception/interrupt
facilities present on the native platform (such as the IDT on x86).
Virtual interrupts can come from a variety of sources (emulated devices,
pass-thro
KVM provides a complete virtual system environment for guests, including
support for injecting interrupts modeled after the real exception/interrupt
facilities present on the native platform (such as the IDT on x86).
Virtual interrupts can come from a variety of sources (emulated devices,
pass-thro
28 matches
Mail list logo