From: Stefan Hajnoczi <stefanha@gmail.com>
To: Lin Ma <LMa@suse.com>
Cc: qemu-block@nongnu.org,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Jon Maloy <jmaloy@redhat.com>, "hare@suse.de" <hare@suse.de>,
"pbonzini@redhat.com" <pbonzini@redhat.com>
Subject: Re: [Question] About GET LBA STATUS(16) support in qemu scsi emulation layer
Date: Tue, 10 Mar 2020 09:24:46 +0000 [thread overview]
Message-ID: <20200310092446.GA140737@stefanha-x1.localdomain> (raw)
In-Reply-To: <DM6PR18MB3322E8AF16F20D91557C3335C5FF0@DM6PR18MB3322.namprd18.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 991 bytes --]
On Tue, Mar 10, 2020 at 06:18:00AM +0000, Lin Ma wrote:
> First of all, Thanks for your reply, Stefan.
>
> We know that the GET LBA STATUS works well under scsi lun passthrough due to the vm directly talks to the scsi target.
> I'm curious that if I use file backend image(say qcow2) + qemu scsi emulation, Does it make sense if I issue sg_get_lba_status in vm to get the lba status?
> If it doesn't make sense, That could explain why qemu scsi emulation layer lack of this support for a long time and no user complains.
It does make sense to implement GET LBA STATUS because QEMU emulates the
UNMAP command.
Be careful though because there is no asynchronous bdrv_block_status()
API yet. Internally the BlockDriver->bdrv_co_block_status() function is
already asynchronous because it runs in a coroutine. It will be
necessary to expose a new bdrv_aio_get_block_status() or similar API so
the device models (i.e. SCSI emulation code) can take advantage of that.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-03-10 9:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-10 6:18 [Question] About GET LBA STATUS(16) support in qemu scsi emulation layer Lin Ma
2020-03-10 9:24 ` Stefan Hajnoczi [this message]
-- strict thread matches above, loose matches on Subject: below --
2020-03-10 13:51 Lin Ma
2020-03-01 13:01 Lin Ma
2020-03-06 13:01 ` Stefan Hajnoczi
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=20200310092446.GA140737@stefanha-x1.localdomain \
--to=stefanha@gmail.com \
--cc=LMa@suse.com \
--cc=hare@suse.de \
--cc=jmaloy@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.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.