Re: [Xen-devel] [PATCH] libbxl: add support for pvscsi, iteration 1

[Olaf Hering <olaf@xxxxxxxxx>]

On Wed, Apr 30, Olaf Hering wrote:

> Add support for vscsi= in domU.cfg, add new xl commands scsi-attach,
> scsi-list, scsi-detach. The syntax follows what xend understood.
> 
> pvscsi provides a dom0 SCSI device as-is to a domU. The backend and
> frontend drivers can be found in xen-linux, or its forward-ported
> variants. This patch was tested with an openSUSE dom0 and a SLES12
> guest. Any openSUSE/SLE11/SLE12 dom0/domU combination will work.

One question regarding device index handling in xenstore:

If devices get removed and added at runtime, they will appear as
/local/domain/0/backend/<devtype>/<domid>/<index>, like
/local/domain/0/backend/vif/3/0.

What is supposed to happen with index if, in this example,
network-attach adds another device, network-detach removes it again,
later network-attach adds yet another device? The first attach will most
likely use index==1. network-detach will remove the device with index 1.
Is the last network-attach supposed to use index 2, or is it allowed to
reuse index 1? Right now I'm not seeing an index counter for
/local/domain/0/backend/vif/3, so I assume it will pick 1.

While working on scsi-attach/scsi-detach I was wondering if the new code
should maintain some counter so that new vscsi hosts get a new number
which was not in use before. Same for vscsi devs. It looks like xend
maintained an internal global counter for (at least) all devs. Surely
such counter was easy to maintain for xend as it controls everything.

If no such counter is required I have to assume that by the time the
toolstack reuses index 1 everything in backend/frontend has released all
references to index 1. No races should happen.

Is that assumption correct for all kind of backend devices?

Olaf

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