From: Jeff Cody <jcody@redhat.com>
To: ashish mittal <ashmit602@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Kevin Wolf <kwolf@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
"Daniel P. Berrange" <berrange@redhat.com>,
Fam Zheng <famz@redhat.com>,
Ashish Mittal <ashish.mittal@veritas.com>,
Stefan Hajnoczi <stefanha@gmail.com>,
John Ferlan <jferlan@redhat.com>,
Buddhi Madhav <Buddhi.Madhav@veritas.com>,
Suraj Singh <Suraj.Singh@veritas.com>,
Nitin Jerath <Nitin.Jerath@veritas.com>,
Peter Maydell <peter.maydell@linaro.org>,
Ketan Nilangekar <Ketan.Nilangekar@veritas.com>,
Abhijit Dey <Abhijit.Dey@veritas.com>,
"Venkatesha M.G." <Venkatesha.Mg@veritas.com>,
Rakesh Ranjan <Rakesh.Ranjan@veritas.com>
Subject: Re: [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs"
Date: Tue, 14 Feb 2017 22:54:57 -0500 [thread overview]
Message-ID: <20170215035457.GA19045@localhost.localdomain> (raw)
In-Reply-To: <CAAo6VWPUL7=jotUzgbA7ko-9+WjeqL7kxWF_1LVLQxs8Y6ajbg@mail.gmail.com>
On Tue, Feb 14, 2017 at 07:02:32PM -0800, ashish mittal wrote:
> On Tue, Feb 14, 2017 at 2:34 PM, ashish mittal <ashmit602@gmail.com> wrote:
> > On Tue, Feb 14, 2017 at 12:51 PM, Jeff Cody <jcody@redhat.com> wrote:
> >> On Thu, Feb 09, 2017 at 01:24:58AM -0800, ashish mittal wrote:
> >>> On Wed, Feb 8, 2017 at 10:29 PM, Jeff Cody <jcody@redhat.com> wrote:
> >>> > On Wed, Feb 08, 2017 at 09:23:33PM -0800, Ashish Mittal wrote:
> >>> >> From: Ashish Mittal <ashish.mittal@veritas.com>
> >>> >>
> >>> >> Source code for the qnio library that this code loads can be downloaded from:
> >>> >> https://github.com/VeritasHyperScale/libqnio.git
> >>> >>
> >>> >> Sample command line using JSON syntax:
> >>> >> ./x86_64-softmmu/qemu-system-x86_64 -name instance-00000008 -S -vnc 0.0.0.0:0
> >>> >> -k en-us -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x5
> >>> >> -msg timestamp=on
> >>> >> 'json:{"driver":"vxhs","vdisk-id":"c3e9095a-a5ee-4dce-afeb-2a59fb387410",
> >>> >> "server":{"host":"172.172.17.4","port":"9999"}}'
> >>> >>
> >>> >> Sample command line using URI syntax:
> >>> >> qemu-img convert -f raw -O raw -n
> >>> >> /var/lib/nova/instances/_base/0c5eacd5ebea5ed914b6a3e7b18f1ce734c386ad
> >>> >> vxhs://192.168.0.1:9999/c6718f6b-0401-441d-a8c3-1f0064d75ee0
> >>> >>
> >>
> >> [...]
> >>
> >>> >> +#define VXHS_OPT_FILENAME "filename"
> >>> >> +#define VXHS_OPT_VDISK_ID "vdisk-id"
> >>> >> +#define VXHS_OPT_SERVER "server"
> >>> >> +#define VXHS_OPT_HOST "host"
> >>> >> +#define VXHS_OPT_PORT "port"
> >>> >> +#define VXHS_UUID_DEF "12345678-1234-1234-1234-123456789012"
> >>> >
> >>> > What is this? It is not a valid UUID; is the value significant?
> >>> >
> >>>
> >>> This value gets passed to libvxhs for binaries like qemu-io, qemu-img
> >>> that do not have an Instance ID. We can use this default ID to control
> >>> access to specific vdisks by these binaries. qemu-kvm will pass the
> >>> actual instance ID, and therefore will not use this default value.
> >>>
> >>> Will reply to other queries soon.
> >>>
> >>
> >> If you are going to call it a UUID, it should adhere to the RFC 4122 spec.
> >> You can easily generate a compliant UUID with uuidgen. However:
> >>
> >> Can you explain more about how you are using this to control access by
> >> qemu-img and qemu-io? Looking at libqnio, it looks like this is used to
> >> determine at runtime which TLS certs to use based off of a
> >> pathname/filename, which is then how I presume you are controlling access.
> >> See Daniel's email regarding TLS certificates.
> >>
> >
> > (1) The default behavior would be to disallow access to any vdisks by
> > the non qemu-kvm binaries. qemu-kvm would use the actual instance ID
> > for authentication.
> > (2) Depending on the workflow, HyperScale controller can choose to
> > grant *temporary* access to specific vdisks by qemu-img, qemu-io
> > binaries (identified by the default VXHS_UUID_DEF above).
> > (3) This information, described in #2, would be communicated by the
> > HyperScale controller to the actual proprietary VxHS server (running
> > on each compute) that does the authentication/SSL.
> > (4) The HyperScale controller, in this way, can grant/revoke access
> > for specific vdisks not just to clients with VXHS_UUID_DEF instance
> > ID, but also the actual VM instances.
> >
> >> [...]
> >>
> >>> >> +
> >>> >> +static void bdrv_vxhs_init(void)
> >>> >> +{
> >>> >> + char out[37];
> >>
> >> Additional point: this should be sized as UUID_FMT_LEN + 1, not 37, but I
> >> suspect this code is changing anyways.
> >>
> >>> >> +
> >>> >> + if (qemu_uuid_is_null(&qemu_uuid)) {
> >>> >> + lib_init_failed = iio_init(QNIO_VERSION, vxhs_iio_callback, VXHS_UUID_DEF);
> >>> >> + } else {
> >>> >> + qemu_uuid_unparse(&qemu_uuid, out);
> >>> >> + lib_init_failed = iio_init(QNIO_VERSION, vxhs_iio_callback, out);
> >>> >> + }
> >>> >> +
> >>> >
> >>> > [1]
> >>> >
> >>> > Can you explain what is going on here with the qemu_uuid check?
> >>> >
> >
> > (1) qemu_uuid_is_null(&qemu_uuid) is true for qemu-io, qemu-img that
> > do not define a instance ID. We end up using the default VXHS_UUID_DEF
> > ID for them, and authenticating them as described above.
> >
> > (2) For the other case 'else', we convert the uuid to a char * using
> > qemu_uuid_unparse(), and pass the resulting char * uuid in variable
> > 'out' to libvxhs.
> >
> >>> >
> >>> > You also can't do this here. This init function is just to register the
> >>> > driver (e.g. populate the BlockDriver list). You shouldn't be doing
> >>> > anything other than the bdrv_register() call here.
> >>> >
> >>> > Since you want to run this iio_init only once, I would recommend doing it in
> >>> > the vxhs_open() call, and using a ref counter. That way, you can also call
> >>> > iio_fini() to finish releasing resources once the last device is closed.
> >>> >
> >>> > This was actually a suggestion I had before, which you then incorporated
> >>> > into v6, but it appears all the refcnt code has gone away for v7/v8.
> >>> >
> >>> >
> >>> >> + bdrv_register(&bdrv_vxhs);
> >>> >> +}
> >>> >> +
> >
>
> Per my understanding, device open and close are serialized, therefore
> I would not need to use the refcnt under a lock.
Correct.
> Does the following diff look ok for the refcnt and iio_fini() change?
>
Disclaimer, the following was compiled in my mind only.
Create a wrapper for the ref, and initialize automatically when appropriate.
For instance:
/* Only refs after successful init */
int vxhs_init_and_ref() {
if (vxhs_ref == 0) {
char out[UUID_FMT_LEN + 1];
if (qemu_uuid_is_null(&qemu_uuid)) {
if (iio_init(QNIO_VERSION, vxhs_iio_callback, VXHS_UUID_DEF))
return -ENODEV;
} else {
qemu_uuid_unparse(&qemu_uuid, out);
if (iio_init(QNIO_VERSION, vxhs_iio_callback, out))
return -ENODEV;
}
}
vxhs_ref++;
return 0;
}
And then another wrapper to unref it, and then call iio_fini() as
appropriate:
void vxhs_unref() {
if (vxhs_ref && --vxhs_ref == 0) {
iio_fini();
}
}
Now whenever you ref or unref the usage counter, everything happens
correctly automatically.
Then the rest of the patch becomes:
> diff --git a/block/vxhs.c b/block/vxhs.c
> index f1b5f1c..d07a461 100644
> --- a/block/vxhs.c
> +++ b/block/vxhs.c
> @@ -27,7 +27,7 @@
>
> QemuUUID qemu_uuid __attribute__ ((weak));
>
> -static int lib_init_failed;
> +static uint32_t refcnt;
Minor nit: I'd call it vxhs_ref (just a preference).
>
> typedef enum {
> VDISK_AIO_READ,
> @@ -232,9 +232,24 @@ static int vxhs_open(BlockDriverState *bs, QDict *options,
> char *str = NULL;
> int ret = 0;
>
> - if (lib_init_failed) {
> - return -ENODEV;
> + if (refcnt == 0) {
> + char out[UUID_FMT_LEN + 1];
> + if (qemu_uuid_is_null(&qemu_uuid)) {
> + if (iio_init(QNIO_VERSION, vxhs_iio_callback, VXHS_UUID_DEF))
> + return -ENODEV;
> + } else {
> + qemu_uuid_unparse(&qemu_uuid, out);
> + if (iio_init(QNIO_VERSION, vxhs_iio_callback, out))
> + return -ENODEV;
> + }
> + }
> +
> + /*
> + * Increment refcnt before actual open.
> + * We will decrement it if there is an error.
> + */
> + refcnt++;
> +
This block then just becomes:
ret = vxhs_init_and_ref();
if (ret < 0) {
return ret;
}
> opts = qemu_opts_create(&runtime_opts, NULL, 0, &error_abort);
> qemu_opts_absorb_qdict(opts, options, &local_err);
> if (local_err) {
> @@ -323,6 +338,13 @@ out:
> qemu_opts_del(opts);
>
> if (ret < 0) {
> + if (refcnt == 1) {
> + /*
> + * First device open resulted in error.
> + */
> + iio_fini();
> + }
> + refcnt--;
This hunk can just be replaced with:
vxhs_unref();
> error_propagate(errp, local_err);
> g_free(s->vdisk_hostinfo.host);
> g_free(s->vdisk_guid);
> @@ -428,6 +450,10 @@ static void vxhs_close(BlockDriverState *bs)
> s->vdisk_hostinfo.dev_handle = NULL;
> }
>
> + if (--refcnt == 0) {
> + iio_fini();
> + }
> +
Same here:
vxhs_unref();
> /*
> * Free the dynamically allocated host string
> */
> @@ -484,15 +510,6 @@ static BlockDriver bdrv_vxhs = {
>
> static void bdrv_vxhs_init(void)
> {
> - char out[37];
> -
> - if (qemu_uuid_is_null(&qemu_uuid)) {
> - lib_init_failed = iio_init(QNIO_VERSION, vxhs_iio_callback,
> VXHS_UUID_DEF);
> - } else {
> - qemu_uuid_unparse(&qemu_uuid, out);
> - lib_init_failed = iio_init(QNIO_VERSION, vxhs_iio_callback, out);
> - }
> -
> bdrv_register(&bdrv_vxhs);
> }
>
> Thanks,
> Ashish
>
-Jeff
next prev parent reply other threads:[~2017-02-15 3:55 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-09 5:23 [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs" Ashish Mittal
2017-02-09 5:23 ` [Qemu-devel] [PATCH v8 2/2] block/vxhs.c: Add qemu-iotests for new block device type "vxhs" Ashish Mittal
2017-02-09 6:29 ` [Qemu-devel] [PATCH v8 1/2] block/vxhs.c: Add support for a new block device type called "vxhs" Jeff Cody
2017-02-09 9:24 ` ashish mittal
2017-02-09 14:32 ` Jeff Cody
2017-02-09 16:14 ` ashish mittal
2017-02-09 16:50 ` Jeff Cody
2017-02-09 18:08 ` ashish mittal
2017-02-09 18:45 ` ashish mittal
2017-02-10 0:27 ` ashish mittal
2017-02-10 2:18 ` Jeff Cody
2017-02-14 20:51 ` Jeff Cody
2017-02-14 22:34 ` ashish mittal
2017-02-15 3:02 ` ashish mittal
2017-02-15 3:54 ` Jeff Cody [this message]
2017-02-15 20:34 ` ashish mittal
-- strict thread matches above, loose matches on Subject: below --
2017-02-16 22:24 ashish mittal
2017-02-17 21:42 ` Jeff Cody
2017-02-18 0:30 ` Ketan Nilangekar
2017-02-20 9:50 ` Daniel P. Berrange
2017-02-20 11:02 ` Stefan Hajnoczi
2017-02-20 11:34 ` ashish mittal
2017-02-21 10:59 ` Stefan Hajnoczi
2017-02-21 11:33 ` Daniel P. Berrange
2017-02-22 14:09 ` Stefan Hajnoczi
2017-02-22 14:22 ` Daniel P. Berrange
2017-02-22 14:44 ` Jeff Cody
2017-02-24 4:19 ` ashish mittal
2017-02-24 9:19 ` Daniel P. Berrange
2017-02-24 23:30 ` ashish mittal
2017-02-27 9:22 ` Daniel P. Berrange
2017-02-28 22:51 ` ashish mittal
2017-03-01 9:18 ` Daniel P. Berrange
2017-03-06 0:26 ` ashish mittal
2017-03-06 9:23 ` Daniel P. Berrange
2017-03-08 1:27 ` ashish mittal
2017-03-08 9:13 ` Daniel P. Berrange
2017-03-08 13:04 ` Ketan Nilangekar
2017-03-08 17:59 ` ashish mittal
2017-03-08 18:11 ` Daniel P. Berrange
2017-03-11 3:04 ` ashish mittal
2017-03-13 9:56 ` Daniel P. Berrange
2017-03-13 9:57 ` Daniel P. Berrange
2017-03-17 0:29 ` ashish mittal
2017-03-18 1:44 ` ashish mittal
2017-03-20 12:55 ` Daniel P. Berrange
2017-03-23 0:03 ` ashish mittal
2017-03-27 3:07 ` ashish mittal
2017-02-21 17:21 ` Ketan Nilangekar
2017-02-21 17:39 ` Daniel P. Berrange
2017-02-21 18:06 ` Jeff Cody
2017-02-21 18:56 ` Daniel P. Berrange
2017-02-21 19:25 ` Jeff Cody
2017-02-22 10:12 ` Daniel P. Berrange
2017-02-22 14:25 ` Stefan Hajnoczi
2017-02-20 9:44 ` Daniel P. Berrange
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=20170215035457.GA19045@localhost.localdomain \
--to=jcody@redhat.com \
--cc=Abhijit.Dey@veritas.com \
--cc=Buddhi.Madhav@veritas.com \
--cc=Ketan.Nilangekar@veritas.com \
--cc=Nitin.Jerath@veritas.com \
--cc=Rakesh.Ranjan@veritas.com \
--cc=Suraj.Singh@veritas.com \
--cc=Venkatesha.Mg@veritas.com \
--cc=armbru@redhat.com \
--cc=ashish.mittal@veritas.com \
--cc=ashmit602@gmail.com \
--cc=berrange@redhat.com \
--cc=famz@redhat.com \
--cc=jferlan@redhat.com \
--cc=kwolf@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
/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.