From: Olaf Hering <olaf@aepfle.de>
To: xen-devel@lists.xen.org
Cc: Ondrej Holecek <oholecek@suse.com>,
Ian Jackson <Ian.Jackson@eu.citrix.com>,
Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [PATCH] libbxl: add support for pvscsi, iteration 1
Date: Fri, 2 May 2014 16:36:53 +0200 [thread overview]
Message-ID: <20140502143653.GA13295@aepfle.de> (raw)
In-Reply-To: <1398855802-29618-1-git-send-email-olaf@aepfle.de>
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
next prev parent reply other threads:[~2014-05-02 14:36 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-30 11:03 [PATCH] libbxl: add support for pvscsi, iteration 1 Olaf Hering
2014-05-02 14:36 ` Olaf Hering [this message]
2014-05-02 15:30 ` Ian Campbell
2014-05-02 15:11 ` Ian Campbell
2014-05-02 15:54 ` Olaf Hering
2014-05-02 16:35 ` Ian Campbell
2014-05-02 15:54 ` Ian Jackson
2014-05-02 16:00 ` Olaf Hering
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140502143653.GA13295@aepfle.de \
--to=olaf@aepfle.de \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=oholecek@suse.com \
--cc=xen-devel@lists.xen.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.