[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] xen interrupt




Thank you very much for your reply, lan.

 In your reply, you said that there is no concept of multiple VMs being registered to receive a single interrupt. For disk interrupt or network interrupt, every virtual machine needs to read or write data from or to disk or network card. I can not understand why there is no concept of multiple VMs being registered to receive a single interrupt.

I am waiting and looking forward to your reply!




At 2013-03-18 19:36:12,"Ian Campbell" <Ian.Campbell@xxxxxxxxxx> wrote: >On Sun, 2013-03-17 at 13:18 +0000, zhangwqh wrote: >> Hi, all >>  >> These days I read the source code about xen interrupts. When physical >> interrupts arrive, in xen source code, do_IRQ will decide which will deal >> with the physical interrupt, by xen or the guest os. If the physical >> interrupt should be dealt with by guest os. Then the case __do_irq_guest() >> will be executed. In __do_irq_guest() function, the corresponding event >> channel will be delivered to the guests that are registered the irq. My >> question is that in the guest os, how to decide whether the irq is to >> itself? Eg, a guest A request a file from a disk, after the disk finished to >> get the file, will generate a disk interrupt. The disk interrupt should only >> be delivered to the guest A. Maybe all of the guest virtual machines >> registered the  disk interrupt. __do_irq_guest will deliver the disk >> interrupt to all of the virtual machines. In the virtual machine, how to >> decide the disk interrupt was generated by its requested file?  > >Even channels are per domain, so if a guest receives one then it knows >inherently that it is for itself. > >There is no concept of multiple VMs being registered to receive a single >interrupt. > >Ian. >


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.