Re: [Xen-devel] [PATCH 4/4] libxl: add support for vscsi

[Olaf Hering <olaf@xxxxxxxxx>]

On Mon, Mar 02, Ian Campbell wrote:

> On Mon, 2015-03-02 at 15:20 +0100, Olaf Hering wrote:
> > Its used as <domid>/<vhost>/vscsi-devs/dev-<vscsi_dev_id>/.  What name
> > should be used to reference the devices? Also just "devid" even if it
> > refers to devices "private" to the vscsi host?
> Not sure. PCI uses vdevfn, which by extension would be vdevid here
> (assuming I've understood what you are suggesting correctly and
> therefore the analogy is valid).

After a quick grep its not clear what vdevfn represents. Will study that
code later. libxl_device_pci indicates that single_host:many_devices is
not used for PCI.

> Or could it be the case that there is no need to expose this value to
> the user in the first place and libxl could just make up the index
> numbers internally? Why would they want to configure it or retrieve it?

I think the actual number is internal to the backend/frontend.
Lets see -- the layout in the backend node is:

 <domid>/<N>/vscsi-devs/dev-<M>/{p-dev,v-dev,state}

N is libxl_device_vscsi->devid, just as every other backend.
M is libxl_device_vscsi->vscsi_devs->vscsi_dev_id.
One N can have several M (single host, many devices) which is different
to all other backends.

I think the issue is that if two M exists and 'scsi-detach' removes M==0
the next time something walks <domid>/<N>/vscsi-devs/ it will find just
a single entry with M==1. So this number has to be recorded.

> Is it actually the same as the offset into the vscsi_devs array?

Per the above it can not be the offset, the code has to handle holes.

> How is it intended to be different from the vdev field?

The vdev field is used to group several devices into a virtual
controller. The HOST in HOST:CHN:TGT:LUN matters. In this sense the
vscsi_dev_id is unrelated to the vdev field.

Olaf

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel