[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.