On 04/21/2011 05:23 PM, Nguyen Thai Ngoc Duy wrote:
On Thu, Apr 21, 2011 at 9:11 PM, Avi Kivity<a...@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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
