, so that
the OS will see the unit attention code and react. Of course a mix of
the three is also possible, depending on how the driver writer prefers
to have his layering violations served.
Signed-off-by: Paolo Bonzini
---
virtio-spec.lyx | 95
All currently defined event structs have the same fields. Simplify the
driver by enforcing this also for future structs.
Signed-off-by: Paolo Bonzini
---
virtio-spec.lyx | 69 +++
1 file changed, 65 insertions(+), 4 deletions(-)
diff --git
This makes some changes to the virtio-scsi event specification, so that
it is now possible to use virtio-scsi events in the implementation of
the QEMU "block_resize" command.
Thanks to Cong Meng for finally implementing virtio-scsi hotplug, which
made me look at block_resize again!
Pao
Il 12/07/2012 09:23, James Bottomley ha scritto:
>> > Cc: Paolo Bonzini
>> > Cc: Stefan Hajnoczi
>> > Cc: Zhi Yong Wu
>> > Cc: Christoph Hellwig
>> > Cc: Hannes Reinecke
>> > Cc: James Bottomley
>> > Signed-off-by: Nicholas Bel
Il 12/07/2012 07:34, Zhi Yong Wu ha scritto:
> HI,
>
> Do we need to maintain one QEMU branch to collect all useful latest
> patches for tcm_vhost support? You know, those patches will not get
> merged into qemu.git/master.
Never say never, but the answer to your question is yes: please apply
th
Il 06/07/2012 05:38, Nicholas A. Bellinger ha scritto:
> So I imagine that setting inquiry/vpd/mode via configfs attribs to match
> whatever the guest wants to see (or expects to see) can be enabled
> via /sys/kernel/config/target/core/$HBA/$DEV/[wwn,attrib]/ easily to
> whatever is required.
>
>
Il 05/07/2012 16:40, Michael S. Tsirkin ha scritto:
>> virtio-scsi is brand new. It's not as if we've had any significant
>> time to make virtio-scsi-qemu faster. In fact, tcm_vhost existed
>> before virtio-scsi-qemu did if I understand correctly.
Yes.
> Can't same can be said about virtio scsi
Il 05/07/2012 15:53, Michael S. Tsirkin ha scritto:
> On Thu, Jul 05, 2012 at 12:22:33PM +0200, Paolo Bonzini wrote:
>> Il 05/07/2012 03:52, Nicholas A. Bellinger ha scritto:
>>>
>>> fio randrw workload | virtio-scsi-raw | virtio-scsi+tcm_vhost
Il 05/07/2012 03:52, Nicholas A. Bellinger ha scritto:
>
> fio randrw workload | virtio-scsi-raw | virtio-scsi+tcm_vhost | bare-metal
> raw block
>
> 25 Write / 75 Read | ~15K | ~45K
The old name is part of the userspace API, add it back for compatibility.
Reported-by: Sasha Levin
Signed-off-by: Paolo Bonzini
---
include/linux/virtio_blk.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/linux/virtio_blk.h b/include/linux/virtio_blk.h
ill likely touch Xen or KVM files as well and
the respective mailing list will usually be reached as well.
Signed-off-by: Paolo Bonzini
---
MAINTAINERS |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 14bc707..e265f2e 100644
--- a/MAINTAI
;
> v2: handle no_event event
> v3: add handle event dropped, and typo fix
> v4: Cancel event works when exit. Coding type fix.
>
> Signed-off-by: Sen Wang
> Signed-off-by: Cong Meng
Reviewed-by: Paolo Bonzini
> ---
&
Il 05/07/2012 09:09, Cong Meng ha scritto:
> This patch implements the hotplug support for virtio-scsi.
> When there is a device attached/detached, the virtio-scsi driver will be
> signaled via event virtual queue and it will add/remove the scsi device
> in question automatically.
>
> v2: handle
Il 04/07/2012 23:30, Michael S. Tsirkin ha scritto:
>> +static int virtblk_get_cache_mode(struct virtio_device *vdev)
>
> Why are you converting u8 to int here?
The fact that it is a u8 is really an internal detail. Perhaps the bug
is using u8 in the callers.
>>>
>>> Mak
Il 05/07/2012 04:05, Nicholas A. Bellinger ha scritto:
>> > But that's what the config field is for... why can't tcm_vhost (or QEMU)
>> > set max_id to 0?
>> >
> So this patch was carried forward from Stefan's original code that I
> thought was required due to other limitations..
>
> If that's no
Il 04/07/2012 18:02, Michael S. Tsirkin ha scritto:
> On Wed, Jul 04, 2012 at 05:54:16PM +0200, Paolo Bonzini wrote:
>> Il 04/07/2012 17:42, Michael S. Tsirkin ha scritto:
>>> On Tue, Jul 03, 2012 at 03:19:37PM +0200, Paolo Bonzini wrote:
>>>> This
Il 04/07/2012 17:42, Michael S. Tsirkin ha scritto:
> On Tue, Jul 03, 2012 at 03:19:37PM +0200, Paolo Bonzini wrote:
>> This patch adds support for the new VIRTIO_BLK_F_CONFIG_WCE feature,
>> which exposes the cache mode in the configuration space and lets the
>> driver modif
Il 04/07/2012 16:02, Michael S. Tsirkin ha scritto:
> On Wed, Jul 04, 2012 at 04:24:00AM +, Nicholas A. Bellinger wrote:
>> From: Nicholas Bellinger
>>
>> Hi folks,
>>
>> This series contains patches required to update tcm_vhost <-> virtio-scsi
>> connected hosts <-> guests to run on v3.5-rc2
field is for... why can't tcm_vhost (or QEMU)
set max_id to 0?
Paolo
> Cc: Paolo Bonzini
> Cc: Stefan Hajnoczi
> Cc: Zhi Yong Wu
> Cc: Christoph Hellwig
> Cc: Hannes Reinecke
> Signed-off-by: Nicholas Bellinger
> ---
> drivers/scsi/virtio_scsi.c |5 -
_BAD_TARGET to occur. This fixes a bug
> with virtio-scsi/tcm_vhost where LUN scan was not detecting LUNs.
>
> Tested with virtio-scsi-raw + virtio-scsi/tcm_vhost w/ IBLOCK on 3.5-rc2 code.
>
> Cc: Paolo Bonzini
> Cc: Stefan Hajnoczi
> Cc: Zhi Yong Wu
> Cc: Christoph
Il 03/07/2012 16:28, Dor Laor ha scritto:
Users using a spinning disk still get IO scheduling in the host though.
What benefit is there in doing it in the guest as well?
>>>
>>> The io scheduler waits for requests to merge and thus batch IOs
>>> together. It's not important w.r.t spinning
Il 04/07/2012 10:11, m...@linux.vnet.ibm.com ha scritto:
>>>
>>>
>>> Signed-off-by: Cong Meng
>>> Signed-off-by: Sen Wang
>>
>> The SoB lines are swapped. Otherwise looks good. Since you have to
>> respin, please add dropped event support too, it shouldn't be hard.
>
> What does "The SoB lines
Il 02/07/2012 08:41, Rusty Russell ha scritto:
>> With the same workload in guest, the guest fires 200K requests to host
>> with merges enabled in guest (echo 0 > /sys/block/vdb/queue/nomerges),
>> while the guest fires 4K requests to host with merges disabled in
>> guest (echo 2 > /sys/bloc
Il 03/07/2012 07:41, Cong Meng ha scritto:
> This patch implements the hotplug support for virtio-scsi.
> When there is a device attached/detached, the virtio-scsi driver will be
> signaled via event virtual queue and it will add/remove the scsi device
> in question automatically.
>
> v2: handle
Il 21/06/2012 09:54, Cong Meng ha scritto:
> Add two interfaces hotplug() and hot_unplug() to scsi bus info.
> The embody scsi bus can implement these two interfaces to signal the HBA
> driver
> of guest kernel to add/remove the scsi device in question.
>
> Signed-off-by: Cong Meng
> Signed-off-
Il 02/07/2012 09:20, m...@linux.vnet.ibm.com ha scritto:
>>> +static void virtscsi_handle_event(struct work_struct *work)
>>> +{
>>> +struct virtio_scsi_event_node *event_node =
>>> +container_of(work, struct virtio_scsi_event_node, work);
>>> +struct virtio_scsi *vscsi = event_node
Il 20/06/2012 08:55, Cong Meng ha scritto:
> This patch implements the hotplug support for virtio-scsi.
> When there is a device attached/detached, the virtio-scsi driver will be
> signaled via event virtual queue and it will add/remove the scsi device
> in question automatically.
>
> Signed-off-
> And it's not a problem if virtqueue is exactly at start of
> vring_virtqueue: we just need to allocate a bit more at start, and
> offset when we free. Here's how I would do this: first apply patch
> below that adds the offset parameter, then update all transports, one
> patch at a time to not us
> How bad would be it to get rid of the current ->priv and use
> container_of() instead? ie. have virtio_pci, virtio_mmio, lguest_bus
> and s390's kvm_virtio embed the struct virtqueue?
Something like the following, compile-tested only...
The layout of vring_virtqueue gets a bit complex, with pr
Il 08/05/2012 04:11, Rusty Russell ha scritto:
>> > For virtio-scsi multiqueue support I would like to have an easy and
>> > fast way to go from a virtqueue to the internal struct for that
>> > queue.
>> >
>> > It turns out that virtio-serial has the same need, but it gets
>> > by with a simple li
Il 18/04/2012 18:10, Michael S. Tsirkin ha scritto:
> On Wed, Apr 18, 2012 at 04:34:12PM +0200, Paolo Bonzini wrote:
>> Il 18/04/2012 16:21, Michael S. Tsirkin ha scritto:
>>>> @@ -1872,6 +1864,8 @@ static int virtcons_restore(struct virtio_device
>>>> *vdev)
Il 18/04/2012 16:21, Michael S. Tsirkin ha scritto:
>> @@ -1872,6 +1864,8 @@ static int virtcons_restore(struct virtio_device *vdev)
>> list_for_each_entry(port, &portdev->ports, list) {
>> port->in_vq = portdev->in_vqs[port->id];
>> port->out_vq = portdev->out_vqs[po
the virtio device, and uses it in virtio-serial.
Cc: Amit Shah
Cc: Rusty Russell
Cc: "Michael S. Tsirkin"
Signed-off-by: Paolo Bonzini
---
Untested; what do you think? Would this patch be acceptable
as is, or only with a more pressing need in virtio-scsi, or never?
Hi Rusty,
here is the specification for a virtio-based SCSI host (controller, HBA,
you name it) so that you can apply it to the spec document and publish it.
I changed the index from 7 to 8 to account for the rpmsg device,
and added a feature bit to tell the guest in advance whether the host
supp
Hi all,
here is the specification for a virtio-based SCSI host (controller, HBA,
you name it). The virtio SCSI host is the basis of an alternative
storage stack for KVM. This stack would overcome several limitations of
the current solution, virtio-blk:
1) scalability limitations: virtio-blk-over
For simplicity, instead of including the whole spec, I am just including
the diff from v1.
--- virtio-spec.txt.v1 2011-11-30 12:21:01.472479754 +0100
+++ virtio-spec.txt 2011-12-05 14:07:02.645044924 +0100
@@ -1,10 +1,9 @@
Appendix H: SCSI Host Device
-The virtio SCSI host device groups to
On 12/01/2011 04:14 AM, Rusty Russell wrote:
I'd prefer to see the spec only cover things
which are implemented and tested, otherwise the risk of a flaw in the
spec is really high in my experience.
In general I agree, and I did that for virtio-specific things such as
the eventq and the configu
On 12/01/2011 10:52 AM, Hannes Reinecke wrote:
I would like to have the other request_queue limitations exposed
here, too.
Most notably we're missing the maximum size of an individual segment
and the maximum size of the overall I/O request.
The virtio transport does not put any limit, as far
On 11/30/2011 03:17 PM, Hannes Reinecke wrote:
seg_max is the maximum number of segments that can be in a
command. A bidirectional command can include seg_max input
segments and seg_max output segments.
I would like to have the other request_queue limitations exposed
here, too.
Most n
Appendix H: SCSI Host Device
The virtio SCSI host device groups together one or more simple
virtual devices (ie. disk), and allows communicating to these
devices using the SCSI protocol. An instance of the device
represents a SCSI host with possibly many buses (also known as
channels or paths), ta
Hi all,
here is the specification for a virtio-based SCSI host (controller, HBA,
you name it). The virtio SCSI host is the basis of an alternative
storage stack for KVM. This stack would overcome several limitations of
the current solution, virtio-blk:
1) scalability limitations: virtio-blk-over
On 07/01/2011 09:14 AM, Hannes Reinecke wrote:
> Actually, the kernel does _not_ do a LUN remapping.
Not the kernel, the in-kernel target. The in-kernel target can and will
map hardware LUNs (target_lun in drivers/target/*) to arbitrary LUNs
(mapped_lun).
>> Put in another way: the virtio-scsi d
On 06/29/2011 11:39 AM, Stefan Hajnoczi wrote:
> > > Of course, when doing so we would be lose the ability to freely remap
> > > LUNs. But then remapping LUNs doesn't gain you much imho.
> > > Plus you could always use qemu block backend here if you want
> > > to hide the details.
> >
> > And
On 06/29/2011 12:31 PM, Michael S. Tsirkin wrote:
> On Wed, Jun 29, 2011 at 12:06:29PM +0200, Paolo Bonzini wrote:
>> On 06/29/2011 12:03 PM, Christoph Hellwig wrote:
>>>> I agree here, in fact I misread Hannes's comment as "if a driver
>>>> uses more
On 06/29/2011 12:03 PM, Christoph Hellwig wrote:
> > I agree here, in fact I misread Hannes's comment as "if a driver
> > uses more than one queue it is responsibility of the driver to
> > ensure strict request ordering". If you send requests to different
> > queues, you know that those reques
On 06/14/2011 10:39 AM, Hannes Reinecke wrote:
> If, however, we decide to expose some details about the backend, we
> could be using the values from the backend directly.
> EG we could be forwarding the SCSI target port identifier here
> (if backed by real hardware) or creating our own SAS-type
>
On 06/12/2011 09:51 AM, Michael S. Tsirkin wrote:
>> >
>> > If a device uses more than one queue it is the responsibility of the
>> > device to ensure strict request ordering.
> Maybe I misunderstand - how can this be the responsibility of
> the device if the device does not get the information a
> If requests are placed on arbitrary queues you'll inevitably run on
> locking issues to ensure strict request ordering.
> I would add here:
>
> If a device uses more than one queue it is the responsibility of the
> device to ensure strict request ordering.
Applied with s/device/guest/g.
> Plea
On 06/10/2011 02:14 PM, Stefan Hajnoczi wrote:
> Paolo, I'll switch the Linux guest LLD and QEMU virtio-scsi skeleton
> that I have to comply with the spec. Does this sound good or did you
> want to write these from scratch?
Why should I want to write things from scratch? :) Just send me again a
On 06/09/2011 01:28 AM, Rusty Russell wrote:
>> > after some preliminary discussion on the QEMU mailing list, I present a
>> > draft specification for a virtio-based SCSI host (controller, HBA, you
>> > name it).
>
> OK, I'm impressed. This is very well written and it doesn't make any of
> the
Hi all,
after some preliminary discussion on the QEMU mailing list, I present a
draft specification for a virtio-based SCSI host (controller, HBA, you
name it).
The virtio SCSI host is the basis of an alternative storage stack for
KVM. This stack would overcome several limitations of the current
On 11/13/2010 11:05 AM, Américo Wang wrote:
> On Wed, Nov 03, 2010 at 10:59:44AM -0400, Jeremy Fitzhardinge wrote:
>> * On PPro SMP or if we are using OOSTORE, we use a locked operation to
>> unlock
>> * (PPro errata 66, 92)
>> */
>> -# define UNLOCK_LOCK_PREFIX LOCK_PREFIX
>> +static __alwa
501 - 552 of 552 matches
Mail list logo
