On 04/21/2011 05:23 PM, Nguyen Thai Ngoc Duy wrote:
On Thu, Apr 21, 2011 at 9:11 PM, Avi Kivity<avi@xxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
