On 23/04/2015 20:10, Christoph Hellwig wrote:
> T10 PI is just another optional feature, LLDDs should work without
> the infrastructure.
>
> Signed-off-by: Christoph Hellwig
> ---
> drivers/scsi/Kconfig | 1 -
> drivers/scsi/virtio_scsi.c | 11 ++-
> 2 files changed, 10 insertio
ost, SHOST_DIX_GUARD_CRC);
> }
> +#endif
>
> err = scsi_add_host(shost, &vdev->dev);
> if (err)
> @@ -1090,7 +1097,9 @@ static struct virtio_device_id id_table[] = {
> static unsigned int features[] = {
> VIRTIO_SCSI_F_HOTPLUG,
> VIRTIO_SCSI_F_
} else
> + } else {
> + unsigned int flags = FOLL_TOUCH | FOLL_HWPOISON;
> +
> + if (write_fault)
> + flags |= FOLL_WRITE;
> +
> npages = __get_user_pages_unlocked(current, current->mm, addr,
> 1,
> -write_fault, 0, page,
> -FOLL_TOUCH|FOLL_HWPOISON);
> +page, flags);
> + }
> if (npages != 1)
> return npages;
>
>
Acked-by: Paolo Bonzini
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 08/12/2016 00:31, Tyrel Datwyler wrote:
> The first byte of each CRQ entry is used to indicate whether an entry is
> a valid response or free for the VIOS to use. After processing a
> response the driver sets the valid byte to zero to indicate the entry is
> now free to be reused. Add a memory
On 16/01/2017 17:04, Fam Zheng wrote:
> + node_name = virtio_cread64(vdev,
> + offsetof(struct virtio_scsi_config, primary_wwnn));
> + port_name = virtio_cread64(vdev,
> + offsetof(struct virtio_scsi_config, primary_wwpn));
> + }
> How it this supposed to work?
> You do export the WWPN/WWNN of the associated host to the guest (nb:
> will get interesting for non NPIV setups ...), but virtio scsi will
> still do a LUN remapping.
> IE the LUNs you see on the host will be different from the LUNs
> presented to the guest.
This
On 16/01/2017 18:26, Fam Zheng wrote:
>> Is the endianness correct for big-endian host here?
>
> I think so. The fc_host sysfs uses u64 to represent port_name and node_name,
> this patch does the same, so using virtio_* helpers for these fields should
> handle the endianness correctly.
I was sus
- Original Message -
> From: "Michael S. Tsirkin"
> To: "Fam Zheng"
> Cc: linux-ker...@vger.kernel.org, "Paolo Bonzini" ,
> linux-scsi@vger.kernel.org, "James E.J.
> Bottomley" , "Jason Wang" ,
> "M
Il 18/07/2014 16:57, Ming Lei ha scritto:
> - if (sc->sense_buffer) {
> + if (resp->sense_len) {
In the (unlikely) case that sc->sense_buffer == NULL, you'd pass a NULL
to memcpy.
If you want, you can change this if to
if (sc->sense_buffer && resp->sense_len)
but frankly it seem
Il 23/08/2014 16:52, Hans de Goede ha scritto:
> Hi All,
>
> Now that the UAS driver is no longer marked as CONFIG_BROKEN,
> I'm getting quite a few bug reports about issues with UAS drives.
>
> One if the issues is that there might be a number of bugs in the
> abort handling path, as I don't thi
Il 25/08/2014 12:28, Bart Van Assche ha scritto:
>
> From SPC-4: "7.5.8 Control mode page [ ... ] A task aborted status (TAS)
> bit set to zero specifies that aborted commands shall be terminated by
> the device server without any response to the application client. A TAS
> bit set to one specifie
Il 25/08/2014 13:26, Hans de Goede ha scritto:
> Thanks Bart and Paolo, your insights into this are greatly appreciated.
>
> So with uas there are separate usb transaction for cmd, data in, data out
> and sense for each tag. At the time of abort, usually one of data in / data
> out and a sense usb
Il 28/08/2014 14:04, Hannes Reinecke ha scritto:
>>
>> Setting TASK ABORTED aside, the important part is that an abort can do
>> one of two things:
>>
>> - complete the command, and then eh_abort should return after the driver
>> has noticed the completion and called the ->scsi_done callback for th
Il 28/08/2014 14:26, Hans de Goede ha scritto:
>> > Then, blk_complete_request will do nothing because its call to
>> > blk_mark_rq_complete returns true.
>> >
>> > All this, of course, as long as ->scsi_done is called _before_ eh_abort
>> > returns.
> What about calling scsi_done after eh_abort i
Il 28/08/2014 16:17, Hannes Reinecke ha scritto:
>>
> As mentioned earlier, as soon as SCSI EH is invoked control
> is assumed to be transferred back to the SCSI midlayer.
> How the midlayer interprets any return value from the various eh_XX
> callbacks is immaterial to the LLDD.
>
> So even if th
Il 28/08/2014 17:50, Elliott, Robert (Server Storage) ha scritto:
> Is the block layer prevented from issuing a new command with the
> same tag before the error handling is finished?
Tags are chosen by the LLDs, so it's up to it to pick the right tags.
Paolo
--
To unsubscribe from this list: send
Il 29/08/2014 08:08, Hannes Reinecke ha scritto:
>>
> No.
> FAILED for any eh_abort_cmd() means that the TMF hasn't been sent.
> So the midlayer escalates to the next EH step.
> The command will only ever be re-issued once EH completes.
Then the answer to Hans's question is yes. It is legal to ca
Il 09/10/2014 06:14, Nicholas A. Bellinger ha scritto:
> AFAICT from qemu code, the ioctl VHOST_SCSI_CLEAR_ENDPOINT is always
> called during shutdown in order to release the endpoint and drop this
> new configfs dependency.
As far as I can see, the only path leading to the ioctl is
vhost_scsi_set
Il 09/10/2014 10:49, Paolo Bonzini ha scritto:
>
> It does not happen if you close QEMU with SIGTERM, ctrl-c, or with the
> "quit" command, because no attempt is done to bring down the VM data
> structures (or free memory, or close file descriptors) in case of a
> fatal
On 10/05/2016 16:16, James Bottomley wrote:
> > If "is performed" just means "completes", maybe with an error, the
> > application would have to resubmit write requests and then try to
> > flush the write cache again.
> >
> > I'm not aware of applications that keep acknowledged write data
> >
On 10/05/2016 19:31, James Bottomley wrote:
> > What about a SPACE ALLOCATION FAILED error or a similar error that
> > can be fixed by administrator actions (or just by a concurrent
> > process doing an UNMAP)? Would a subsequent cache flush cause data
> > loss?
>
> You're now asking about how
On 06/06/2016 16:22, Hannes Reinecke wrote:
> So either we dig into what went wrong with qemu 0.8, or we figure out
> from which qemu version things start to behave nicely, and blacklist
> earlier versions.
>
> > > Either way, this patch is wrong.
> >
> > If we can identify which versions work,
On 06/06/2016 17:41, John Snow wrote:
> On 06/06/2016 11:05 AM, Paolo Bonzini wrote:
>> For ATAPI, you have to blacklist all versions up to 2.2 inclusive.
>>
>> This gives:
>>
>> - QEMU / QEMU CD-ROM / 0.8.(this is IDE and SCSI)
>> - QEMU / QEMU
On 06/06/2016 17:47, John Snow wrote:
> > > Various downstreams may have backported the VPD fix to older versions,
> > > we need to be careful not to block those, too ... so targeting the core
> > > behavior seems like the more strictly correct, easily maintainable
> > > solution.
> >
> > I thi
I'm not sure what is more ridiculous, whether the seven pings or the
lack of review...
Paolo
Il 06/02/2013 16:15, Paolo Bonzini ha scritto:
> This series regards the whitelist that is used for the SG_IO ioctl. This
> whitelist has three problems:
>
> * the bitmap of al
Il 22/05/2013 11:32, Tejun Heo ha scritto:
> On Wed, May 22, 2013 at 08:35:54AM +0200, Paolo Bonzini wrote:
>> I'm not sure what is more ridiculous, whether the seven pings or the
>> lack of review...
>
> So, ummm, I don't know what Jens is thinking but at this po
Il 22/05/2013 12:02, Tejun Heo ha scritto:
> On Wed, May 22, 2013 at 11:53:30AM +0200, Paolo Bonzini wrote:
>> Il 22/05/2013 11:32, Tejun Heo ha scritto:
>>> On Wed, May 22, 2013 at 08:35:54AM +0200, Paolo Bonzini wrote:
>>>> I'm not sure what is more ridicul
> OK, let me try. I did draw straws with Jens at LSF to see who would
> look at this and he lost, but the complexity of the patch set probably
> makes it hard for him to find the time.
Thanks.
> The first problem, which Tejun already pointed out is that you've
> combined a "bug fix" with a larg
Il 22/05/2013 15:41, Tejun Heo ha scritto:
> On Wed, May 22, 2013 at 12:23:56PM +0200, Paolo Bonzini wrote:
>> Yes, because I have no idea what _your_ point is.
>
> Isolate the actual fixes and just submit them as it seems impossible
> for you to provide proper justifications
Il 22/05/2013 16:30, Tejun Heo ha scritto:
> * Separate fixes from additions. Transform existing code so that the
> visible behavior doesn't change but the required fix can be
> implemented on top. Explicitly note what's going on in the commit
> messages.
Been there, done that. Have you r
Il 22/05/2013 17:03, Theodore Ts'o ha scritto:
> Paolo,
>
> I'll probably regret butting my head into this, but it might be
> helpful if you talk about your particular use case which is driving
> your desire to make these changes.
Ted,
thank you very much. I understand that my discussion with T
Il 22/05/2013 16:07, Paolo Bonzini ha scritto:
>> Finally, the patch for the feature I think you actually want, which is
>> 13/14, could have been implemented fairly simply as a single patch and
>> doesn't have to be part of this series.
>
> It was, and it was ignored
Il 22/05/2013 18:32, Martin K. Petersen ha scritto:
>>>>>> "Paolo" == Paolo Bonzini writes:
>
> Paolo> First of all, I'll note that SG_IO and block-device-specific
> Paolo> ioctls both have their place. My usecase for SG_IO is
> Paolo> vir
Il 22/05/2013 20:11, Theodore Ts'o ha scritto:
> On Wed, May 22, 2013 at 07:00:14PM +0200, Paolo Bonzini wrote:
>> You have hardware providers selling cloud services that want to run
>> their own custom backup services from within a VM, which entails having
>> vendor-
Il 22/05/2013 22:19, Theodore Ts'o ha scritto:
> On Wed, May 22, 2013 at 09:37:54PM +0200, Paolo Bonzini wrote:
>>> If it's not theoretical, how does the cloud service control who has
>>> access to the CD burner, and how are the disks loaded into the CD
>>>
Il 22/05/2013 22:39, Tejun Heo ha scritto:
> Hey,
>
> On Wed, May 22, 2013 at 05:53:34PM +0200, Paolo Bonzini wrote:
>> I do listen to review feedback, but I also expect the other side to
>> listen to me, ask me what is not clear, and possess some knowledge of
>> the
Il 22/05/2013 21:30, Tejun Heo ha scritto:
> The thing is that the behavior change is now implemented in an
> inactive form by #2 and then flipped on by #3. #2 both change the
> format and the content of the table. This should have been like the
> following.
>
> #2: Convert to the new table for
Il 23/05/2013 00:17, Tejun Heo ha scritto:
> Then let's make it fit the use case better. I really can't see much
> point in crafting the cdb filter when you basically have to entrust
> the device to the user anyway. Let's either trust the user with the
> device or not. I'm very doubtful that the
Il 23/05/2013 11:02, Tejun Heo ha scritto:
> On Thu, May 23, 2013 at 09:45:42AM +0200, Paolo Bonzini wrote:
>> Il 23/05/2013 00:17, Tejun Heo ha scritto:
>>> Then let's make it fit the use case better. I really can't see much
>>> point in crafting the cdb filt
still the same, so there is no semantic change
in this patch.
Cc: sta...@gnu.org
Cc: "James E.J. Bottomley"
Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe
Signed-off-by: Paolo Bonzini
---
block/scsi_ioctl.c | 14 +-
drivers/scsi/scsi_scan.c | 2 ++
include/linu
e five
commands. This is the smallest change that fixes this bug.
Cc: sta...@gnu.org
Cc: "James E.J. Bottomley"
Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe
Signed-off-by: Paolo Bonzini
---
block/scsi_ioctl.c | 26 ++
1 file changed, 26 insertions(+)
-standard spacing. IMO the improved readability trumps the problems
reported by checkpatch.
Cc: "James E.J. Bottomley"
Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe
Signed-off-by: Paolo Bonzini
---
block/scsi_ioctl.c | 207 +++-
include/s
Bottomley"
Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe
Signed-off-by: Paolo Bonzini
---
block/scsi_ioctl.c | 41 -
1 file changed, 32 insertions(+), 9 deletions(-)
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 8f0344f..41bbd93 1006
n old pre-standard command
for "INITIALIZE ELEMENT STATUS WITH RANGE", which is enabled as well.
This makes media changers usable by unprivileged users that have access
to the device node.
Cc: "James E.J. Bottomley"
Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe
Signed-off-by: Paol
-byte CDBs for READ and WRITE. For this reason I'm
separating block devices for tapes entirely.
Cc: "James E.J. Bottomley"
Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe
Signed-off-by: Paolo Bonzini
---
block/scsi_ioctl.c | 47 ---
1 f
si@vger.kernel.org
Cc: Jens Axboe
Signed-off-by: Paolo Bonzini
---
block/scsi_ioctl.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 0bf0820..216cd17 100644
--- a/block/scsi_ioctl.c
+++ b/block/scs
s E.J. Bottomley"
Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe
Signed-off-by: Paolo Bonzini
---
block/scsi_ioctl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index 41bbd93..b11ad49 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -21
read-write.
The other four conflicting commands have their bitmap entries split in
two parts, one read-only for MMC and one read-write for the other classes.
Cc: "James E.J. Bottomley"
Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe
Signed-off-by: Paolo Bonzini
---
block/scsi_io
To prepare for the next patches, abstract setting of an entry in the
command filter behind a macro.
The next patch will change the implementation of the macro.
Cc: sta...@gnu.org
Cc: "James E.J. Bottomley"
Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe
Signed-off-by: Paolo Bonzini
t any filtering. This queue flag can then be set on
selected devices.
This patch depends on, and conflicts with, the CVE-2012-4542 fix that
I have just sent.
Cc: "James E.J. Bottomley"
Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe
Signed-off-by: Paolo Bonzini
---
Documentation/block/
Adjust the blk_verify_command function to let it look at per-queue
data. This will be done in the next patch.
Acked-by: Tejun Heo
Cc: sta...@gnu.org
Cc: FUJITA Tomonori
Cc: Doug Gilbert
Cc: "James E.J. Bottomley"
Cc: linux-scsi@vger.kernel.org
Cc: Jens Axboe
Signed-off-by: Pao
Il 24/05/2013 03:44, Tejun Heo ha scritto:
> On Thu, May 23, 2013 at 11:47:25AM +0200, Paolo Bonzini wrote:
>>> No no, I'm not talking about it not working for the users - it's just
>>> passing the commands, it of course works. I'm doubting about it being
&
Il 24/05/2013 09:36, James Bottomley ha scritto:
> On Thu, 2013-05-23 at 15:58 +0200, Paolo Bonzini wrote:
>> Adjust the blk_verify_command function to let it look at per-queue
>> data. This will be done in the next patch.
>
> This is not a bug fix. This is an enabler for y
Il 24/05/2013 09:50, James Bottomley ha scritto:
> On Fri, 2013-05-24 at 09:43 +0200, Paolo Bonzini wrote:
>> Il 24/05/2013 09:36, James Bottomley ha scritto:
>>> On Thu, 2013-05-23 at 15:58 +0200, Paolo Bonzini wrote:
>>>> Adjust the blk_verify_command functi
Il 24/05/2013 10:02, Tejun Heo ha scritto:
> On Fri, May 24, 2013 at 4:13 PM, Paolo Bonzini wrote:
>>> The same filtering table being applied to different classes of
>>> hardware is a software bug, but my point is that the practive
>>> essentially entrusts non-
Il 24/05/2013 10:03, James Bottomley ha scritto:
> > >>> Does anyone in the real world actually care about this bug?
> >>
> >> Yes, or I would move on and not waste so much time on this.
>>> > >
>>> > > Fine, so produce a simple fix for this bug which we can discuss that's
>>> > > no
Il 24/05/2013 11:07, Tejun Heo ha scritto:
> On Fri, May 24, 2013 at 5:31 PM, Paolo Bonzini wrote:
>> I agree intuition may not count, and it's perfectly possible that
>> firmware writers forgot a "break;" or put the wrong location in a jump
>> table,
Il 24/05/2013 10:32, Paolo Bonzini ha scritto:
> Il 24/05/2013 10:03, James Bottomley ha scritto:
>>>>>>>>>> Does anyone in the real world actually care about this bug?
>>>>>>>>
>>>>>>>> Yes, or I would move on an
Il 25/05/2013 06:14, James Bottomley ha scritto:
> On Fri, 2013-05-24 at 10:32 +0200, Paolo Bonzini wrote:
>> Il 24/05/2013 10:03, James Bottomley ha scritto:
>>>>>>>>>>> Does anyone in the real world actually care about this bug?
>>>>>>
Il 25/05/2013 07:27, Christoph Hellwig ha scritto:
> On Fri, May 24, 2013 at 09:35:02PM -0700, James Bottomley wrote:
>> I'll go along with this. I'm also wondering what the problem would be
>> if we just allowed all commands on either CAP_SYS_RAWIO or opening the
>> device for write, so we just d
Il 25/05/2013 09:11, Christoph Hellwig ha scritto:
> > Linus wanted to keep that for CAP_SYS_RAWIO. We found two uses of SG_IO
> > on partitions: zfs-fuse used SYNCHRONIZE CACHE; some proprietary driver
> > used TEST UNIT READY.
> >
> > Really, the solution is to make the bitmaps configurable in
Il 25/05/2013 10:37, Tejun Heo ha scritto:
> Hey, James.
>
> On Fri, May 24, 2013 at 09:35:02PM -0700, James Bottomley wrote:
>>> Well, I'd actually much prefer disabling CDB whitelisting for all !MMC
>>> devices if at all possible.
>>
>> I'll go along with this. I'm also wondering what the probl
Il 25/05/2013 14:48, Tejun Heo ha scritto:
>>> * Merge the patch to give out SG_IO access along with write access, so
>>> > > the use cases which want to give out SG_IO access can do so
>>> > > explicitly and be fully responsible for the device. This makes
>>> > > sense to me. If one wants
anyway never really
enabled, the different API is not a problem.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini
---
Documentation/block/queue-sysfs.txt | 16 ++
block/Kconfig | 10
block/blk-sysfs.c | 41 ++
block
ecial filtering is desired.
This is a partial (and massaged) revert of commit 018e044 (block: get
rid of queue-private command filter, 2009-06-26).
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini
---
block/blk-sysfs.c | 2 ++
block/bsg.c| 2 +-
block/scsi_ioctl.c
Using /dev/sg for scanners is blocked from unprivileged users. Reimplement
this using customizable command filters, so that the sysfs knobs will work
in this case too.
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Paolo Bonzini
---
drivers/scsi/scsi_scan.c | 8 +++-
drivers/scsi/sg.c
/9/25/397 (short thread).
Rebased just fine, this one is compile-tested only.
Paolo
Paolo Bonzini (4):
block: add back queue-private command filter
scsi: create an all-zero filter for scanners
block: add back command filter modification via sysfs
scsi: lock out SG_IO by default to unprivi
regression for those who are using Unix
permissions, security modules or the device cgroup to confine programs.
A meaningful whitelist can then be set by udev, for example.
Signed-off-by: Paolo Bonzini
---
This is not yet usable, because sg devices do not have a link
to the queue
@@ static struct scsi_host_template
> virtscsi_host_template_multi = {
> .queuecommand = virtscsi_queuecommand_multi,
> .eh_abort_handler = virtscsi_abort,
> .eh_device_reset_handler = virtscsi_device_reset,
> + .eh_timed_out = virtscsi_timedout,
>
> .can_queue = 10
Il 10/06/2013 03:40, Hannes Reinecke ha scritto:
> Any TMF might be take longer as expected, or not return at all.
> So we need to use 'wait_for_completion_timeout' when sending
> a TMF to protect against these cases.
>
> Cc: Paolo Bonzini
> Signed-off-by: Hannes Rei
Il 27/05/2013 15:50, Paolo Bonzini ha scritto:
>
> We've been running in circles for nine months now. Let's restart from
> the maintainer's suggestion, which was probably dismissed too quickly.
>
> This is still not a complete solution, because /dev/sgN does
Il 09/05/2013 22:20, Matthew Wilcox ha scritto:
> NVMe: Add nvme-scsi.c
I couldn't find the original patch on LKML, so I'll just quote the
relevant piece of code.
> +int nvme_sg_io(struct nvme_ns *ns, struct sg_io_hdr __user *u_hdr)
> +{
> + struct sg_io_hdr hdr;
> + int retcode;
>
Il 25/06/2013 23:19, Paolo Bonzini ha scritto:
> Il 27/05/2013 15:50, Paolo Bonzini ha scritto:
>>
>> We've been running in circles for nine months now. Let's restart from
>> the maintainer's suggestion, which was probably dismissed too quickly.
>>
> vscsi->num_queues counts the number of request virtqueue which does not
> include the control and event virtqueue. It is wrong to subtract
> VIRTIO_SCSI_VQ_BASE from vscsi->num_queues.
Reviewed-by: Paolo Bonzini
> This patch fixes the following panic.
>
> (qemu) de
Il 04/09/2013 16:32, Alan Stern ha scritto:
> On Wed, 4 Sep 2013, Dmitry Vyukov wrote:
>
>> Hi,
>>
>> We are working on a memory error detector AddressSanitizer for Linux
>> kernel
>> (https://code.google.com/p/address-sanitizer/wiki/AddressSanitizerForKernel),
>> it can detect use-after-free and
ge was found. In theory it may be present, but the buffer size
> is limited to 512 bytes.
>
> Signed-off-by: Alan Stern
> Reported-by: Dmitry Vyukov
> CC:
Reviewed-by: Paolo Bonzini
>
> ---
>
>
> [as1709]
>
>
> drivers/scsi/sd.c | 11 +++
Il 21/09/2013 00:03, Martin K. Petersen ha scritto:
>
> The major headache here of course is that WRITE SAME is inherently
> destructive. We can't just fire off one during discovery and see if it
> works. For WRITE you can issue a command with a transfer length of 0 to
> see if things work. But un
blk_queue_max_hw_sectors(sdkp->disk->queue, max_xfer);
> set_capacity(disk, sdkp->capacity);
> sd_config_write_same(sdkp);
> _
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to major
On 29/01/2015 00:00, Christoph Hellwig wrote:
> Lock the device embedded in the scsi_device to protect against
> concurrent calls to ->remove.
>
> Signed-off-by: Christoph Hellwig
I wonder if this makes this problem: https://lkml.org/lkml/2015/1/5/9 go
away.
Paolo
> ---
> drivers/scsi/scsi_
gt;
> This is useful for vhost ANY_LAYOUT support when guests are allowed to
> generate
> incoming virtio request headers combined with subsequent SGL payloads into a
> single iovec.
>
> Cc: Michael S. Tsirkin
> Cc: Paolo Bonzini
> Signed-off-by: Nicholas Bellinger
On 30/01/2015 02:08, Fam Zheng wrote:
> On Fri, 01/30 00:11, Paolo Bonzini wrote:
>>
>>
>> On 29/01/2015 00:00, Christoph Hellwig wrote:
>>> Lock the device embedded in the scsi_device to protect against
>>> concurrent calls to ->remove.
>>>
&
On 02/02/2015 13:59, Christoph Hellwig wrote:
> On Fri, Jan 30, 2015 at 10:46:17AM +0100, Paolo Bonzini wrote:
>> > Great, we might want to revert that patch in 3.21.
> Is that fix in any tree yet? Seems like I missed it for the scsi
> tree at least. So unless you want it
fail try_module_get if we're doing SCSI operations
> - * from module exit (like cache flush) */
> - __module_get(sdev->host->hostt->module);
> -
> + goto fail;
> + if (!try_module_get(sdev->host->hostt->module))
> + goto fail_put_device;
>
struct scsi_driver *drv = to_scsi_driver(dev->driver);
>
> if (drv->rescan)
> drv->rescan(dev);
> module_put(dev->driver->owner);
> }
> + device_unlock(dev);
> }
> EXPORT_SYMBOL(scsi_rescan_devic
On 05/03/2015 14:33, Christoph Hellwig wrote:
> Any chance to get reviews for this series? Also we should at least
> expedite this first patch into 4.0-rc as it fixes scanning races
> in virtio_scsi.
I reviewed 1 and 3, but I'm not really qualified for patch 2.
Paolo
> On Mon, Feb 02, 2015 at
On 05/03/2015 14:37, Paolo Bonzini wrote:
>
>
> On 05/03/2015 14:33, Christoph Hellwig wrote:
>> Any chance to get reviews for this series? Also we should at least
>> expedite this first patch into 4.0-rc as it fixes scanning races
>> in virtio_scsi.
>
>
sd_revalidate_disk if read capacity failed
> sd: Return -EIO if read capacity failed
>
> block/partition-generic.c | 6 +++---
> drivers/scsi/sd.c | 22 +-
> 2 files changed, 16 insertions(+), 12 deletions(-)
>
Reviewed-by: Paolo Bonzini
Though p
Il 05/12/2012 17:45, Kirill A. Shutemov ha scritto:
> From: "Kirill A. Shutemov"
>
> This driver is intended to run as fast as possible, hence the options to
> discard writes and reads. It's designed to let us find latency issues
> elsewhere in the storage stack (eg filesystem, block layer, scsi
Il 07/12/2012 12:20, Kirill A. Shutemov ha scritto:
>> > Is this that much faster than scsi-debug? The discarding options surely
>> > can be added there.
> scsi_ram is about 9% faster (without fake_rw/throw_away_*) on my machine:
There are two main differences in the data path:
- scsi_debug uses
Il 13/11/2012 18:25, Paolo Bonzini ha scritto:
> Privilege restrictions for SG_IO right now apply without distinction to
> all devices, based on the single capability CAP_SYS_RAWIO. This is a very
> broad capability, and makes it difficult to give SG_IO access to trusted
> clien
sent a request. This
is less appealing because we do not set the affinity directly---we only
provide a hint to the irqbalanced running in userspace. Dynamically
changing the affinity only works if the userspace applies the hint
fast enough.
Signed-off-by: Paolo Bonzini
---
v1->v2: impr
this patches and in the next ones.
Signed-off-by: Wanlong Gao
Signed-off-by: Paolo Bonzini
---
v1->v2: new
drivers/scsi/virtio_scsi.c | 94 +++
1 files changed, 42 insertions(+), 52 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/driv
not needed in virtio-blk, because it does all the
work of the upper SCSI layers itself in the blk_map_rq_sg call. Then
it simply hands the resulting scatterlist to virtqueue_add_buf.
Signed-off-by: Paolo Bonzini
---
v1->v2: new
drivers/virtio/virtio_ring.c |
This will be needed soon in order to retrieve the per-target
struct.
Signed-off-by: Paolo Bonzini
---
drivers/scsi/virtio_scsi.c | 17 +
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 4a3abaf
array member at the end of struct virtio_scsi, because
we will place the virtqueues there in the next patches.
Signed-off-by: Paolo Bonzini
---
v1->v2: new
drivers/scsi/virtio_scsi.c | 43 ++-
1 files changed, 14 insertions(+), 29 deletions(-)
d
g these patches.
Paolo Bonzini (5):
virtio: add functions for piecewise addition of buffers
virtio-scsi: use functions for piecewise composition of buffers
virtio-scsi: redo allocation of target data
virtio-scsi: pass struct virtio_scsi to virtqueue completion function
virtio-scsi: intro
Il 18/12/2012 14:37, Michael S. Tsirkin ha scritto:
> On Tue, Dec 18, 2012 at 01:32:49PM +0100, Paolo Bonzini wrote:
>> Using the new virtio_scsi_add_sg function lets us simplify the queueing
>> path. In particular, all data protected by the tgt_lock is just gone
>> (multi
Il 18/12/2012 14:36, Michael S. Tsirkin ha scritto:
> Some comments without arguing about whether the performance
> benefit is worth it.
>
> On Tue, Dec 18, 2012 at 01:32:48PM +0100, Paolo Bonzini wrote:
>> diff --git a/include/linux/virtio.h b/include/linux/virtio.h
>>
Il 18/12/2012 14:57, Michael S. Tsirkin ha scritto:
>> -static int virtscsi_queuecommand(struct Scsi_Host *sh, struct scsi_cmnd *sc)
>> +static int virtscsi_queuecommand(struct virtio_scsi *vscsi,
>> + struct virtio_scsi_target_state *tgt,
>> +
Il 18/12/2012 14:59, Michael S. Tsirkin ha scritto:
>>> Can't we track state internally to the virtqueue? Exposing it
>>> seems to buy us nothing since you can't call add_buf between
>>> start and end anyway.
>>
>> I wanted to keep the state for these functions separate from the
>> rest. I don't t
1 - 100 of 428 matches
Mail list logo