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

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



 

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> pradeep singh rautela
> Sent: 06 June 2007 09:19
> To: Mark Williamson
> Cc: Gautham Kampalapur Shankar, TLS, Chennai; 
> xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-devel] FW: about VIRQ & PIRQ
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Hi Mark,
> [snip]
> >
> > If I recall correctly, PIRQs are mapped one-to-one onto the 
> lower numbered
> > event channels (I'm not sure if this is specific to 
> XenLinux or part of the
> > Xen API).
> >
> > A VIRQ is a interrupt-like event that originates from Xen 
> itself.  An example
> > would be notifications from the Xen virtual timer device.  
> Again, the guest
> > sees it as an event channel notification but this time we 
> call it a VIRQ to
> > show that it comes from an entirely *virtual* source.
> Does this means if hypervisor recieves an interrupt from an external
> card on the behalf of a domU, it actually buffers it like a an APIC
> before eventually generating a VIRQ to the respective domU?


Yes, essentially so. There is a bitmap for each guest of "pending
interrupts", which is read based on an event to the guest. 

> 
> The above question is more obvious when we have an external hardware
> device which generates interrupts are a very high rate e.g a busy
> network card.
> 
> So, does Xen buffers the recieved IRQs if it is unable to send the IRQ
> to the correct domU?

It is "never unable" to send the IRQ to the guest. The guest may be
unable to TAKE the interrupt at this point, but it's never unable for
the hypervisor to "send" the IRQ to the guest. 

To understand better, have a look at .../xen/arch/x86/irq.c, and in
particular the function __do_IRQ_guest(). 

> 
> I hope same holds true while handling interrupts on the 
> behalf of dom0.
> Or is it that, Xen just forwards the interrupt to dom0 which then
> handles the actual creation of a VIRQ using event channels to notify a
> domU?

I think I've told you before, Dom0 is no different from any other domain
when it comes to how it interacts with the hypervisor, aside from having
a bit set that says "You're allowed to do things like
creating/destroying other guests". Interrupt handling in Dom0 is exactly
identical to any other guest - there is nothing in the above irq.c file
that says "if (domain is dom0) ..." (in fact, the only domain_id usage
is for a printk in the "dump_irqs" function, which is for dumping the
current IRQ state on the console when in Xen console-mode. 

--
Mats
> 
> Thank you
> - --psr
> 
> >
> > There are actually more variations to event channels: 
> events might also come
> > from another domain we are communicating with, or (I think) 
> from another VCPU
> > in the same domain.
> >
> > Hope this helps,
> > Cheers,
> > Mark
> >
> > --
> > Dave: Just a question. What use is a unicyle with no seat?  
> And no pedals!
> > Mark: To answer a question with a question: What use is a 
> skateboard?
> > Dave: Skateboards have wheels.
> > Mark: My wheel has a wheel!
> >
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxx
> > http://lists.xensource.com/xen-devel
> >
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: http://firegpg.tuxfamily.org
> 
> iD8DBQFGZm36ky6Gd9lpXlERApaLAJ9PHCvWMG8a16m3gNhb2P/dlJMi2QCfbFkN
> b7sUQ0B9sswcA2gxxsQTdBo=
> =YlzF
> -----END PGP SIGNATURE-----
> -- 
> ---
> pradeep singh rautela
> 
> "Genius is 1% inspiration, and 99% perspiration" - not me :)
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 
> 



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


 


Rackspace

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