How is irq delivered in kvm?

How is irq delivered in kvm?

[Nguyen Thai Ngoc Duy]

Hi,

I have a specialized e1000 device driver that expects to receive a
single frame per interrupt, no more. It's by design and very hard to
change (and it does not serve IP traffic). -net socket or tap can
sometimes deliver more than one frame in a row and blow up the driver
in turn. I'd like to experiment with tap/socket to only call
qemu_send_packet..() once and leave pending frames in queue until next
time, with hope that guest will have time to process the frame.

The problem is I'm new to kvm and not sure how the main loop is run.
Will there be guest execution time between two tap/socket polls, how
long is it? Or is guest run in parallel with the event loop and
qemu_set_irq() somehow signals guest immediately?
-- 
Duy

Re: How is irq delivered in kvm?

[Avi Kivity]

On 04/21/2011 04:49 PM, Nguyen Thai Ngoc Duy wrote:
> Hi,
>
> I have a specialized e1000 device driver that expects to receive a
> single frame per interrupt, no more. It's by design and very hard to
> change (and it does not serve IP traffic). -net socket or tap can
> sometimes deliver more than one frame in a row and blow up the driver
> in turn. I'd like to experiment with tap/socket to only call
> qemu_send_packet..() once and leave pending frames in queue until next
> time, with hope that guest will have time to process the frame.

I don't understand how the driver can expect that.  The card is free to 
deliver multiple packets per interrupt.  Are you counting on fast timing 
to process the packet before the next packet arrives?

If you restrict the number of buffers you provide to the card to exactly 
one, you'll get one packet per interrupts (and dropped packets).

> The problem is I'm new to kvm and not sure how the main loop is run.
> Will there be guest execution time between two tap/socket polls, how
> long is it? Or is guest run in parallel with the event loop and
> qemu_set_irq() somehow signals guest immediately?

The latter, it's in parallel.

Are you using qemu-kvm or qemu?  qemu-kvm will deliver better interrupt 
performance.

-- 
error compiling committee.c: too many arguments to function

Re: How is irq delivered in kvm?

[Nguyen Thai Ngoc Duy]

On Thu, Apr 21, 2011 at 9:11 PM, Avi Kivity <avi@redhat.com> wrote:
> On 04/21/2011 04:49 PM, Nguyen Thai Ngoc Duy wrote:
>>
>> Hi,
>>
>> I have a specialized e1000 device driver that expects to receive a
>> single frame per interrupt, no more. It's by design and very hard to
>> change (and it does not serve IP traffic). -net socket or tap can
>> sometimes deliver more than one frame in a row and blow up the driver
>> in turn. I'd like to experiment with tap/socket to only call
>> qemu_send_packet..() once and leave pending frames in queue until next
>> time, with hope that guest will have time to process the frame.
>
> I don't understand how the driver can expect that.  The card is free to
> deliver multiple packets per interrupt.  Are you counting on fast timing to
> process the packet before the next packet arrives?

Yes. It uses ethernet as transport to "clone" memory from one machine
to another in a short, precalculated amount of time.

> If you restrict the number of buffers you provide to the card to exactly
> one, you'll get one packet per interrupts (and dropped packets).
>
>> The problem is I'm new to kvm and not sure how the main loop is run.
>> Will there be guest execution time between two tap/socket polls, how
>> long is it? Or is guest run in parallel with the event loop and
>> qemu_set_irq() somehow signals guest immediately?
>
> The latter, it's in parallel.
>
> Are you using qemu-kvm or qemu?  qemu-kvm will deliver better interrupt
> performance.

I'm using qemu-kvm. What function is used to deliver the interrupt
then, kvm_inject_irq?
-- 
Duy

Re: How is irq delivered in kvm?

[Avi Kivity]

On 04/21/2011 05:23 PM, Nguyen Thai Ngoc Duy wrote:
> On Thu, Apr 21, 2011 at 9:11 PM, Avi Kivity<avi@redhat.com>  wrote:
> >  On 04/21/2011 04:49 PM, Nguyen Thai Ngoc Duy wrote:
> >>
> >>  Hi,
> >>
> >>  I have a specialized e1000 device driver that expects to receive a
> >>  single frame per interrupt, no more. It's by design and very hard to
> >>  change (and it does not serve IP traffic). -net socket or tap can
> >>  sometimes deliver more than one frame in a row and blow up the driver
> >>  in turn. I'd like to experiment with tap/socket to only call
> >>  qemu_send_packet..() once and leave pending frames in queue until next
> >>  time, with hope that guest will have time to process the frame.
> >
> >  I don't understand how the driver can expect that.  The card is free to
> >  deliver multiple packets per interrupt.  Are you counting on fast timing to
> >  process the packet before the next packet arrives?
>
> Yes. It uses ethernet as transport to "clone" memory from one machine
> to another in a short, precalculated amount of time.

Well, anything time related will misbehave under virtualization.

> >  If you restrict the number of buffers you provide to the card to exactly
> >  one, you'll get one packet per interrupts (and dropped packets).
> >
> >>  The problem is I'm new to kvm and not sure how the main loop is run.
> >>  Will there be guest execution time between two tap/socket polls, how
> >>  long is it? Or is guest run in parallel with the event loop and
> >>  qemu_set_irq() somehow signals guest immediately?
> >
> >  The latter, it's in parallel.
> >
> >  Are you using qemu-kvm or qemu?  qemu-kvm will deliver better interrupt
> >  performance.
>
> I'm using qemu-kvm. What function is used to deliver the interrupt
> then, kvm_inject_irq?

No, kvm_set_irq_level().


-- 
error compiling committee.c: too many arguments to function