This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Frontend/Backend model

On Sat, 2007-03-17 at 21:15 +0200, David Shwatrz wrote:
> Hello,


> A question about frontend/backend model:
> I had looked in the code of netfront (and blockfront) and I wonder 
> : do these modules operate in soft_irq or interrupt context? 
> For exmaple, methods like network_start_xmit() (for trasmitting
> frames 
> in nerfront ) or network_tx_buf_gc() (for receiving frames in
> netfront) ?
> I see that the netif_int() calls network_tx_buf_gc(). But is domU
> network_tx_buf_gc() method called from a regular interrupt context 
> (like in the ususal case, when we deal with ordinary 
> drivers) ? Am I permitted to call a method that may sleep in these
> methods ? 


frontend drivers are regular netdevs and therefore have to adhere to the
context the protocol stack calls the methods. xen linux doesn't change
much about that.

> As I understood, interrrupt handling in Xen is different, because
> interrupts are 
> handled by domain 0, and as I understood there are events channels and
> pending
> events, and the interrupts are in fact handled first by domain 0,
> which activates
> some event channel messages.

while hardware interrupts are caught by xen and dom0, there are still
interrupts involved here, though 'virtual' ones. indeed, these are
managed by event channels, but the resulting execution model in the
guest doesn't differ much a hardware irq. xen builds a custom interrupt
frame on the guest kernel stack (grep the xen code for 'trap_bounce')
and transfers guest control to the registered handler.

yes, the virtual cpu where this is happening becomes a preemptible
resource. but that's fully transparent for the guest system and doesn't
change much about the kernel works. interrupt handlers won't turn into
threads. cannot.

> I want to verify this point for better understanding the
> frontend/backend model. 

hope that helped.


Daniel Stodden
LRR     -      Lehrstuhl für Rechnertechnik und Rechnerorganisation
Institut für Informatik der TU München             D-85748 Garching
http://www.lrr.in.tum.de/~stodden         mailto:stodden@xxxxxxxxxx
PGP Fingerprint: F5A4 1575 4C56 E26A 0B33  3D80 457E 82AE B0D8 735B

Xen-devel mailing list