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

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

[tosher 1]

I was trying to understand the following things regarding the PV driver.

1. Who create frontend and backend instances?
2. When are these instances created?
3. How xenbus directories are created? What is the hierarchy of the directories? 
4. What is the role of "vifname" and who sets it?

Please let me know if you can help with these questions or can direct me to some resources.

Thanks
Mehrab

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

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

[Roger Pau Monné]

On Sat, Oct 05, 2019 at 10:35:11AM +0000, tosher 1 wrote:
> I was trying to understand the following things regarding the PV driver.
> 
> 1. Who create frontend and backend instances?

That depends on where the frontend and backends run. For example
Linux blkback is implemented as a module of the Linux kernel. Linux
blkfront is also a Linux kernel module. OTOH there's also a block
backend in QEMU called qdisk, which is obviously implemented in QEMU.

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.

> 2. When are these instances created?

The xenstore entries are created at domain creation by the toolstack
(xl/libxl). The connection between the frontend and the backend
happens when the frontend driver loads and initializes the connection.

> 3. How xenbus directories are created? What is the hierarchy of the directories? 

They are created by the toolstack during domain creation: xl/libxl.
There are documents in the public headers that describe the expected
and optional xenstore nodes for each device, see:

http://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=xen/include/public/io

> 4. What is the role of "vifname" and who sets it?

That's set in the guest config file [0] and then it's the hotplug
script the one in charge of renaming the interface from it's original
name into the desired one [1].

Roger.

[0] https://xenbits.xen.org/docs/unstable/man/xl-network-configuration.5.html#vifname
[1] http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/hotplug/Linux/vif-common.sh#l67

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

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

[Anthony PERARD]

On Tue, Oct 08, 2019 at 10:39:11AM +0200, Roger Pau Monné wrote:
> On Sat, Oct 05, 2019 at 10:35:11AM +0000, tosher 1 wrote:
> > 3. How xenbus directories are created? What is the hierarchy of the directories? 
> 
> They are created by the toolstack during domain creation: xl/libxl.
> There are documents in the public headers that describe the expected
> and optional xenstore nodes for each device, see:
> 
> http://xenbits.xen.org/gitweb/?p=xen.git;a=tree;f=xen/include/public/io

The hierarchy of the directories can be found in this other document:

https://xenbits.xenproject.org/docs/unstable/misc/xenstore-paths.html

-- 
Anthony PERARD

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

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

[tosher 1]

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.

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.

Please let me know if I understood it wrong. Thanks!


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

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

[Roger Pau Monné]

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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel