Re: [Xen-devel] How PV frontend and backend initializes?

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Wed, Oct 16, 2019 at 10:47:09PM +0000, tosher 1 wrote:
> 
> Anthony and Roger, thanks for your informative responses. It helped a lot.
> 
> 
> > I'm however unsure by what you mean with instance, so you might have
> > to clarify exactly what you mean in order to get a more concise
> > reply.
> 
> Let's say there are two DomU's, and their respective network interfaces are 
> xenbr0 and xenbr1. Therefore, there supposed to be two PV netback drivers 
> running in Dom0 (or driver domain): one for xenbr0 and another for xenbr1. By 
> the term instance, I am refering to these drivers. If later there comes 
> another interface xenbr3, there will be the third instance of the backend 
> driver. I was wondering how these multiple instances are created and when.

I would avoid using xenbr* as the nomenclature here. xenbr0 is usually
a bridge with a physical network interface that provides outside
access to guests. The network interfaces you are refereeing to are
usually called vifs, and have vif<domid>.<instance> nomenclature by
default (you can change the interface name on the xl.cfg config file).

> Now, as you pointed to the xen toolstack, I explored xl/libxl a little bit. I 
> realized for two separate devices, libxl creates two different paths both for 
> the frontend and backend. The OSes keeps watching xenstore paths. If an OS 
> finds a device of the type it is interested in, it creates the instance of 
> the corresponding driver (frontend or backend) if the device is not 
> initialized already. The path is the parameter which make one instance 
> different from the others.

Those instances are ultimately created by netback as a response to
device data being populated on xenstore, see xenvif_alloc in the Linux
kernel.

Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel