RE: [Xen-devel] FW: about VIRQ & PIRQ

["Petersson, Mats" <Mats.Petersson@xxxxxxx>]

> what is VIRQ  ?How VIRQ is different from PIRQ ?How VIRQ & 
> PIRQ are related each other ?

To explain this, we need to understand the entire processing of
interrupts and how that relates to the guest kernel. 

In a normal (bare-metal/non-virtual) system, interrupts are used to
"wake up" the kernel when some non-CPU hardware is finished with some
activity (such as counting a counter to it's final count [timer],
storing a sector or data to a disk or sending a network packet). Almost
all of these events happen completely asynchronously to the execution of
instructions in the CPU, and they may well wake the CPU from a HLT
instruction (which is the way to say "I've got nothing better to do than
to wait for the next interrupt"). 

It gets more complicated in a virtual environment. Let's say that guest
A sends off a packet of network data, then goes to a HLT - which is a
"magic" instruction in a virtual environment, and thus tells the
hypervisor that "This guest hasn't got any work to do, let's run another
guest". Let's now assume that this other guest, Guest B, is doing some
pure calculation activity (say calculating the first 5 million positions
of PI), so it's not interacting with any hardware and will run for quite
some time without "stopping". 

Now an interrupt comes in. This interrupt BELONGS to A, but B is
currently running. That wouldn't work very well, right? 

So the way to solve this is to have the "real" interrupt go to the
hypervisor. This is the Physical IRQ or PIRQ. The hypervisor keeps a
list of which physical IRQ belongs to which guest(s) and issues the
relevant Virtual IRQ to the guest - this is done using an event-channel.


Note also that HVM guests are also dealing with physical interrupts by
doing a VMExit and then letting the hypervisor take the interrupt as per
usual. For the same reason, the physical interrupt may not be for the
guest that is currently running. [In fact, in an IO-intensive system,
it's most likely NOT the guest that cuased the interrupt that is active
when the interrupt arrives to the processor]. 

--
Mats
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel