From: Paolo Bonzini
KVM's optimization of guest port 80 accesses was removed last May 11
in commit 99f85a. However, this probably has speed penalties. I don't
have a machine to test but the equivalent VMX patch (fdef3ad) reported
a speedup of 3-5%, and on the Xen mailing list it was
Avi Kivity wrote:
On 06/19/2009 01:15 PM, Paolo Bonzini wrote:
From: Paolo Bonzini
KVM's optimization of guest port 80 accesses was removed last May 11
in commit 99f85a. However, this probably has speed penalties. I don't
have a machine to test but the equivalent VMX patch (fdef3ad
+ * Design note: We create one PIO/MMIO device (iosignalfd_group) which
+ * aggregates one or more iosignalfd_items. Each item points to exactly one
+ * eventfd, and can be registered to trigger on any write to the group
+ * (wildcard), or to a write of a specific value. If more than one item
Marcelo Tosatti wrote:
Paolo,
As said in private email you can change the port 80 passthrough to
disabled only on those hosts that have broken port 80 (you can find the
blacklist at arch/x86/kernel/io_delay.c).c
Actually I read the code more and, since pv_ops is actually disabling
outs to por
Marcelo Tosatti wrote:
On Mon, Jun 22, 2009 at 07:57:22PM +0200, Paolo Bonzini wrote:
Marcelo Tosatti wrote:
Paolo,
As said in private email you can change the port 80 passthrough to
disabled only on those hosts that have broken port 80 (you can find the
blacklist at arch/x86/kernel
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 about
the o
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
identifi
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 requests are
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 than one queue it is responsibility of the
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 you could
On 07/01/2011 09:42 AM, Hannes Reinecke wrote:
size_t iov_from_buf(struct iovec *iov, unsigned int iovcnt,
-const void *buf, size_t size)
+const void *buf, size_t offset, size_t size)
Wrong commit subject, it seems. :)
Paolo
--
To unsubscribe from this
On 07/01/2011 09:42 AM, Hannes Reinecke wrote:
'tag' is just an abstraction to identify the command
from the driver. So we should make that explicit by
replacing 'tag' with a driver-defined pointer 'hba_private'.
This saves the lookup for driver handling several commands
in parallel.
This makes
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 de
On 07/01/2011 03:11 PM, Hannes Reinecke wrote:
On 07/01/2011 10:27 AM, Paolo Bonzini wrote:
On 07/01/2011 09:42 AM, Hannes Reinecke wrote:
'tag' is just an abstraction to identify the command
from the driver. So we should make that explicit by
replacing 'tag' with a dr
\n", req->tag);
-}
DPRINTF("Command complete %d\n", status);
s->residue = s->data_len;
s->result = status != 0;
@@ -387,7 +380,7 @@ static int usb_msd_handle_data(USBDevice *dev, USBPacket *p)
s->tag, cbw.flags, cbw.cmd_len, s->data_len);
s-
On 07/02/2011 03:50 PM, Hannes Reinecke wrote:
(And no, I will not getting into another dog-fight with Paul B. here.
Virtio can do without bounce buffers. AHCI can. So I fail to see why
SCSI has to rely on bounce buffers.)
I agree, but I do see why a SCSI device might prefer to rely on bounce
On 07/04/2011 08:13 AM, Hannes Reinecke wrote:
On 07/03/2011 04:36 PM, Paolo Bonzini wrote:
On 07/02/2011 03:50 PM, Hannes Reinecke wrote:
(And no, I will not getting into another dog-fight with Paul B. here.
Virtio can do without bounce buffers. AHCI can. So I fail to see why
SCSI has to rely
On 07/04/2011 09:26 AM, Hannes Reinecke wrote:
Cool.
Exactly what I need.
FWIW, feel free to add my 'Acked-by' to it.
Any chance of getting them included?
I'm not very tied to pvscsi; I just needed an HBA that is not a joke by
modern standards :) to play with the SCSI layer. There may be
On 07/04/2011 02:52 PM, Hannes Reinecke wrote:
However, I probably will see to fixup the megasas emulation with the
current infrastructure, get that in, and then move over to the iovec
infrastructure.
Makes sense also for ease of review.
But if you promise to merge the iovec infrastructure I'
On 07/04/2011 09:52 AM, Juan Quintela wrote:
Hi
Please send in any agenda items you are interested in covering.
SCSI without bounce buffers: talk now, or forever hold your peace.
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger
On 07/05/2011 09:49 AM, Markus Armbruster wrote:
> If 'ret' has been used to silence compiler warnings about functions
> which have been declared with attribute __warn_unused_result__
> (eg write() and various other libc functions) then "(void)write()"
> is insufficient -- gcc requires the va
INTF("Command: lun=%d tag=0x%x data=0x%02x", req->lun, req->tag,
buf[0]);
if (scsi_req_parse(&r->req, buf) != 0) {
BADF("Unsupported command length, command %x\n", command);
Acked-by: Paolo Bonzini
--
To unsubscribe from this list: send the line &
>bs);
-s->serial = qemu_strdup(*dinfo->serial ? dinfo->serial : "0");
+if (*dinfo->serial) {
+s->serial = qemu_strdup(dinfo->serial);
+}
}
if (!s->version) {
Acked-by: Paolo Bonzini
Paolo
--
To unsubsc
On 07/05/2011 03:38 PM, Alexander Graf wrote:
>>
>> +if (is_sgl64) {
>> +iov_pa = ldq_phys(pa);
>> +} else {
>> +iov_pa = ldl_phys(pa);
>
> These load data from memory in target endianness. Are you sure that's
> what you want? I'd expect this to be defined
On 07/06/2011 08:20 AM, Hannes Reinecke wrote:
We cannot map control structures from guest memory and treating them
as valid request state later on.
Yes, I've been working on that one already.
What I'll be doing is to read in the sge count during 'map_sgl' and
store this value internally (in -
On 07/14/2011 06:07 PM, Avi Kivity wrote:
Maybe we can do this via a magic subsection whose contents are the
hotplug event.
What about making the device list is just another "thing" to be migrated
live, together with block and ram?
Paolo
--
To unsubscribe from this list: send the line "uns
On 07/14/2011 06:07 PM, Avi Kivity wrote:
Maybe we can do this via a magic subsection whose contents are the
hotplug event.
What about making the device list just another "thing" that has to be
migrated live, together with block and ram?
Paolo
--
To unsubscribe from this list: send the line
On 07/25/2011 09:50 AM, Sasha Levin wrote:
Anthony had a talk on last years KVM forum regarding the QEMU threading
model (slide:
http://www.linux-kvm.org/wiki/images/7/70/2010-forum-threading-qemu.pdf) .
It was suggested that the KVM part of QEMU is having a hard time
achieving the ideal threadi
On 07/25/2011 04:23 PM, Blue Swirl wrote:
> Yes. We can just make qemu_malloc use g_malloc.
It would be also possible to make g_malloc() use qemu_malloc(). That
way we could keep the tracepoints which would lose their value with
g_malloc() otherwise.
qemu_malloc uses g_malloc => you keep tra
On 07/25/2011 04:56 PM, Blue Swirl wrote:
> qemu_malloc uses g_malloc => you keep tracepoints, you just do not trace
> memory allocated by glib
Unless the plan is to replace all qemu_malloc() calls with calls to g_malloc().
We can worry when the day comes... there is already another task
bloc
On 07/22/2011 09:58 PM, Umesh Deshapnde wrote:
-qemu_mod_timer(s->timer, qemu_get_clock_ms(rt_clock) + 100);
+qemu_mod_timer(s->timer, qemu_get_clock_ms(migration_clock) + 100);
if (s->freeze_output)
return;
@@ -246,8 +246,10 @@ static void buffered_rate_tick(void *opaque
On 07/26/2011 01:26 PM, Avi Kivity wrote:
+while (i < view->nr) {
+j = i + 1;
+while (j < view->nr
+ && can_merge(&view->ranges[j-1], &view->ranges[j])) {
+view->ranges[i].addr.size += view->ranges[j].addr.size;
+++j;
+}
++
On 07/26/2011 01:38 PM, Avi Kivity wrote:
if (j != i) {
+memmove(&view->ranges[i], &view->ranges[j],
+(view->nr - j) * sizeof(view->ranges[j]));
+view->nr -= j - i;
+}
}
Seems to work both ways?
Sure, but you're pointlessly memmove-ing memory over itse
On 07/07/2011 07:26 AM, André Weidemann wrote:
Hi,
I am running Windows7 x64 in a VM which crashes after starting a certain
game. Actually there are two games both from the same company, that make
the VM crash after starting them.
Windows crashes right after starting the game. With the 1st game t
On 07/28/2011 03:21 PM, Avi Kivity wrote:
I haven't used debuggers very much, so I hope I grabbed the correct
lines from the disassembly:
http://pastebin.com/t3sfvmTg
That's the bug check routine. Can you go up a frame?
Or just do what Gleb suggested. Open the dump, type "!analyze -v" and
On 07/28/2011 07:44 PM, André Weidemann wrote:
Hi,
On 28.07.2011 15:49, Paolo Bonzini wrote:
On 07/28/2011 03:21 PM, Avi Kivity wrote:
I haven't used debuggers very much, so I hope I grabbed the correct
lines from the disassembly:
http://pastebin.com/t3sfvmTg
That's the bug che
On 07/29/2011 10:57 PM, Umesh Deshpande wrote:
This patch creates a separate thread for the guest migration on the source side.
Signed-off-by: Umesh Deshpande
Looks pretty good!
One thing that shows, is that the interface separation between
buffered_file.c is migration.c is pretty weird. Yo
On 07/29/2011 10:57 PM, Umesh Deshpande wrote:
+qemu_mutex_unlock_iothread();
while (s->state == MIG_STATE_ACTIVE) {
if (migrate_fd_check_expire()) {
+qemu_mutex_lock_iothread();
buffered_rate_tick(s->file);
+qemu_mutex_unlock_iothread();
On 08/01/2011 11:00 PM, Umesh Deshpande wrote:
I kept this in migration.c to call qemu_savevm_state_begin. (The way it
is done currently. i.e. to keep access to FdMigrationState in migration.c)
Calling it from buffered_file.c would be inconsistent in that sense. or
we will have to call it from
On 08/11/2011 05:32 PM, Umesh Deshpande wrote:
This patch creates a separate thread for the guest migration on the source side.
migrate_cancel request from the iothread is handled asynchronously. That is,
iothread submits migrate_cancel to the migration thread and returns, while the
migration thr
diff --git a/buffered_file.c b/buffered_file.c
index b64ada7..5735e18 100644
--- a/buffered_file.c
+++ b/buffered_file.c
@@ -243,7 +243,9 @@ static void *migrate_vm(void *opaque)
while (!s->closed) {
if (s->freeze_output) {
+qemu_mutex_unlock_iothread();
On 08/11/2011 05:32 PM, Umesh Deshpande wrote:
Following patch series deals with VCPU and iothread starvation during the
migration of
a guest. Currently the iothread is responsible for performing the guest
migration. It holds qemu_mutex during the migration and doesn't allow VCPU to
enter the qem
On 08/11/2011 07:36 PM, Umesh Deshpande wrote:
Now, migrate_fd_cleanup, buffured_close is just executed by the
migration thread.
I am not letting iothread call any migration cancellation related
functions. In stead it just submits the request and waits for the
migration thread to terminate itse
On 08/11/2011 06:20 PM, Paolo Bonzini wrote:
+qemu_mutex_lock_ramlist();
QLIST_REMOVE(block, next);
QLIST_INSERT_HEAD(&ram_list.blocks, block, next);
+qemu_mutex_unlock_ramlist();
Theoretically qemu_get_ram_ptr shoul
On 08/14/2011 11:45 PM, Umesh Deshpande wrote:
That's not too good because qemu_get_ram_ptr is a hot path for TCG.
Looks like qemu_get_ram_ptr isn't called from the source side code of
guest migration.
Right, but since you are accessing the list from both migration and
non-migration threads,
r an untested patch.
Paolo
>From 8579b821a2c7c4da55a4208c5df3c86e8ce2cc87 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini
Date: Fri, 12 Aug 2011 13:08:04 +0200
Subject: [PATCH] split MRU ram list
Outside the execution threads the normal, non-MRU-ized order of
the RAM blocks should always be enough. So manage two separate
lis
On 08/15/2011 01:27 PM, Umesh Deshpande wrote:
Yes, the mru list patch would obviate the need of holding the ram_list
mutex in qemu_get_ram_ptr.
Feel free to take it and complete it with locking then!
Also, I was planning to protect the whole migration thread with iothread
mutex, and ram_list
On 08/15/2011 11:15 PM, Paolo Bonzini wrote:
On 08/15/2011 01:27 PM, Umesh Deshpande wrote:
Yes, the mru list patch would obviate the need of holding the ram_list
mutex in qemu_get_ram_ptr.
Feel free to take it and complete it with locking then!
Also, I was planning to protect the whole
On 08/16/2011 03:57 AM, Michael Tokarev wrote:
Each time I build qemu-kvm, my build script complains
that it is needlessly linked against libglib-2.0 without
using any symbols from that library. So is glib really
needed for qemu-kvm? How it's different from qemu-0.15?
glib is only needed for
On 08/16/2011 08:56 PM, Umesh Deshpande wrote:
@@ -3001,8 +3016,10 @@ void qemu_ram_free_from_ptr(ram_addr_t addr)
QLIST_FOREACH(block,&ram_list.blocks, next) {
if (addr == block->offset) {
+qemu_mutex_lock_ramlist();
QLIST_REMOVE(block, next);
On 08/16/2011 08:56 PM, Umesh Deshpande wrote:
+qemu_mutex_lock_ramlist();
Taken locks: iothread, ramlist
+qemu_mutex_unlock_iothread();
Taken locks: ramlist
+s->wait_for_unfreeze(s);
+qemu_mutex_lock_iothread();
Taken locks: ramlist, ioth
On 08/16/2011 08:56 PM, Umesh Deshpande wrote:
diff --git a/qemu-thread-posix.c b/qemu-thread-posix.c
index 2bd02ef..0d18b35 100644
--- a/qemu-thread-posix.c
+++ b/qemu-thread-posix.c
@@ -115,6 +115,16 @@ void qemu_cond_wait(QemuCond *cond, QemuMutex *mutex)
error_exit(err, __func__);
On 08/19/2011 08:20 AM, Umesh Deshpande wrote:
Or, is it okay to convert all the ramblock list traversals in exec.c
(under iothread) to mru traversals, and probably it makes sense as the
original list was also maintained in the mru order, whereas the sequence
of blocks doesn't matter for the migr
Il 11/07/2012 14:08, Avi Kivity ha scritto:
> specific command line or guest?
>>>
>>> qemu-system-x86_64
>>> >>
>>> >> Just did the same, but it's all fine here.
>> >
>> > Ok, I'll debug it. Probably something stupid like a miscompile.
> Indeed, a simple clean build fixed it up.
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 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 11:10, Avi Kivity ha scritto:
> On 07/05/2012 06:16 PM, Paolo Bonzini wrote:
>> This is broken; since the eventfd is used in nonblocking mode there
>> is a race between reading and writing.
>>
>
>> diff --git a/event_notifier.c b/event_notifier.c
&g
Il 12/07/2012 13:04, Avi Kivity ha scritto:
> Right, it's useless. I'll adjust the comment (and the whitespace fix)
> and apply.
Ok, thanks very much!
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
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
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
, 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
This series adds support for block_resize to virtio-scsi. Events
are reported via a new event type. Patches to the spec are on the
list.
Paolo Bonzini (5):
scsi-disk: removable hard disks support START/STOP
scsi-disk: report resized disk via sense codes
scsi: establish precedence levels
Support for START/STOP UNIT right now is limited to CD-ROMs. This is wrong,
since removable hard disks (in the real world: SD card readers) also support
it in pretty much the same way.
Signed-off-by: Paolo Bonzini
---
hw/scsi-disk.c |2 +-
1 file changed, 1 insertion(+), 1 deletion
Linux will not use these, but a very similar mechanism will be used to
report the condition via virtio-scsi events.
Signed-off-by: Paolo Bonzini
---
hw/scsi-bus.c |5 +
hw/scsi-disk.c | 15 +++
hw/scsi.h |2 ++
3 files changed, 18 insertions(+), 4 deletions
When a device is resized, we will report a unit attention condition
for CAPACITY DATA HAS CHANGED. However, we should ensure that this
condition does not override a more important unit attention condition.
Signed-off-by: Paolo Bonzini
---
hw/scsi-bus.c | 52
Signed-off-by: Paolo Bonzini
---
hw/scsi-bus.c | 10 ++
hw/scsi-disk.c |2 +-
hw/scsi.h |2 ++
3 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/hw/scsi-bus.c b/hw/scsi-bus.c
index d5e1fb0..77aa946 100644
--- a/hw/scsi-bus.c
+++ b/hw/scsi-bus.c
@@ -1072,6
Signed-off-by: Paolo Bonzini
---
hw/virtio-scsi.c | 16
1 file changed, 16 insertions(+)
diff --git a/hw/virtio-scsi.c b/hw/virtio-scsi.c
index 83dbabd..80a47d7 100644
--- a/hw/virtio-scsi.c
+++ b/hw/virtio-scsi.c
@@ -27,6 +27,7 @@
/* Feature Bits */
#define
Il 17/07/2012 10:29, Asias He ha scritto:
> So, vhost-blk at least saves ~6 syscalls for us in each request.
Are they really 6? If I/O is coalesced by a factor of 3, for example
(i.e. each exit processes 3 requests), it's really 2 syscalls per request.
Also, is there anything we can improve? P
Il 17/07/2012 11:21, Asias He ha scritto:
>> It depends. Like vhost-scsi, vhost-blk has the problem of a crippled
>> feature set: no support for block device formats, non-raw protocols,
>> etc. This makes it different from vhost-net.
>
> Data-plane qemu also has this cripppled feature set proble
Il 17/07/2012 11:45, Michael S. Tsirkin ha scritto:
>> So it begs the question, is it going to be used in production, or just a
>> useful reference tool?
>
> Sticking to raw already makes virtio-blk faster, doesn't it?
> In that vhost-blk looks to me like just another optimization option.
> Ideall
Il 17/07/2012 12:49, Michael S. Tsirkin ha scritto:
>> Ok, that would make more sense. One difference between vhost-blk and
>> vhost-net is that for vhost-blk there are also management actions that
>> would trigger the switch, for example a live snapshot.
>> So a prerequisite for vhost-blk would b
Il 17/07/2012 13:14, Kevin Wolf ha scritto:
>> > -if (s->features & (1 << SCSI_DISK_F_REMOVABLE)) {
>> > -bdrv_set_dev_ops(s->qdev.conf.bs, &scsi_cd_block_ops, s);
>> > -}
>> > +bdrv_set_dev_ops(s->qdev.conf.bs, &scsi_disk_block_ops, s);
> Are you aware of this code?
>
> bool b
Il 17/07/2012 14:48, Michael S. Tsirkin ha scritto:
> On Tue, Jul 17, 2012 at 01:03:39PM +0100, Stefan Hajnoczi wrote:
>> On Tue, Jul 17, 2012 at 12:54 PM, Michael S. Tsirkin wrote:
Knowing the answer to that is important before anyone can say whether
this approach is good or not.
>
Il 18/07/2012 15:42, Anthony Liguori ha scritto:
> If you add support for a new command, you need to provide userspace a
> way to disable this command. If you change what gets reported for VPD,
> you need to provide userspace a way to make VPD look like what it did in
> a previous version.
The QE
Il 18/07/2012 21:12, Anthony Liguori ha scritto:
> Is that true for all OSes? Linux may handle things gracefully if UNMAP
> starts throwing errors but that doesn't mean that Windows will.
There is so much USB crap (not just removable, think of ATA-to-USB
enclosures) that they have to deal with pr
Il 19/07/2012 09:28, James Bottomley ha scritto:
>> > INQUIRY responses (at least vendor/product/type) should not change.
> INQUIRY responses often change for arrays because a firmware upgrade
> enables new features and new features have to declare themselves,
> usually in the INQUIRY data. What y
Il 03/07/2012 15:20, Paolo Bonzini ha scritto:
> These patches let virtio-blk use the new support for toggling the cache
> mode between writethrough and writeback.
>
> The first patch introduces a new feature bit and configuration field to
> do this. The second patch disables wr
Il 23/07/2012 18:44, Blue Swirl ha scritto:
>> > Support for START/STOP UNIT right now is limited to CD-ROMs. This is
>> > wrong,
>> > since removable hard disks (in the real world: SD card readers) also
>> > support
>> > it in pretty much the same way.
> I remember vaguely tuning a set of large
achieve, simply fall back
> to notifying the host notifier manually from qemu if KVM mode is
> disabled.
>
> Signed-off-by: Stefan Hajnoczi
> Cc: Anthony Liguori
> Cc: Paolo Bonzini
> Signed-off-by: Nicholas Bellinger
> ---
> hw/virtio-pci.c | 23 +++
Il 25/07/2012 00:33, Nicholas A. Bellinger ha scritto:
> +int event_notifier_notify(EventNotifier *e)
> +{
> +uint64_t value = 1;
> +int r;
> +
> +assert(event_notifier_valid(e));
> +r = write(e->fd, &value, sizeof(value));
> +if (r < 0) {
> +return -errno;
> +}
> +
i)
> - clear vhost-scsi endpoint on stopped (Zhi)
> - Add CONFIG_VHOST_SCSI for QEMU build configure (nab)
> - Rename vhost_vring_target -> vhost_scsi_target (mst + nab)
> - Add support for VHOST_SCSI_GET_ABI_VERSION ioctl (aliguori + nab)
>
> Signed-off-by: Stefan Hajnoczi
>
which means the
> virtqueues have been set up by the guest.
>
> (v2: Squash virtio-scsi: use the vhost-scsi host device from stefan)
>
> Signed-off-by: Stefan Hajnoczi
> Signed-off-by: Zhi Yong Wu
> Cc: Michael S. Tsirkin
> Cc: Paolo Bonzini
> Signed-off-by: Nicholas Bellin
Il 25/07/2012 09:01, Paolo Bonzini ha scritto:
>> > From: Stefan Hajnoczi
>> >
>> > This patch starts and stops vhost as the virtio device transitions
>> > through its status phases. Vhost can only be started once the guest
>> > reports its driver
Il 25/07/2012 00:34, Nicholas A. Bellinger ha scritto:
> From: Stefan Hajnoczi
>
> Begin adding vhost support by opening /dev/vhost-scsi.
>
> (v2: Drop legacy ->vhost_vqs[] usage)
>
> Signed-off-by: Stefan Hajnoczi
> Signed-off-by: Zhi Yong Wu
> Cc: Michael S
Il 25/07/2012 09:03, Stefan Hajnoczi ha scritto:
> From: Liu Ping Fan
>
> iohandler/bh/timer may use DeviceState when its refcnt=0,
It's not clear how to me. The only reference to devices from an
iohandler/bh/timer can be in the opaque. Now, if you have a
iohandler/bh/timer whose opaque is a De
Il 25/07/2012 10:16, liu ping fan ha scritto:
> > It's not clear how to me. The only reference to devices from an
> > iohandler/bh/timer can be in the opaque. Now, if you have a
> > iohandler/bh/timer whose opaque is a DeviceState, you should bump the
> > refcount before setting it up, and unref
Il 25/07/2012 05:31, Liu Ping Fan ha scritto:
> From: Liu Ping Fan
>
> rwlock:
> qemu_device_tree_mutex
>
> rd side:
> --device_del(destruction of device will be postphoned until unplug
> ack from guest),
> --pci hot-unplug
> --iteration (qdev_reset_all)
>
> wr side:
> --device_ad
Il 25/07/2012 10:12, liu ping fan ha scritto:
>>> >> +qemu_rwlock_rdlock_devtree();
>>> >> section = phys_page_find(page >> TARGET_PAGE_BITS);
>>> >> +if (!(memory_region_is_ram(section->mr) ||
>>> >> +memory_region_is_romd(section->mr)) && !is_write) {
>>> >> +
Il 25/07/2012 15:26, Boaz Harrosh ha scritto:
>>> In SCSI land most LLDs should support chaining just by virtu of using the
>>> for_each_sg macro. That all it takes. Your code above does support it.
>>
>> Yes, it supports it but still has to undo them before passing to virtio.
>>
>> What my LLD doe
Il 25/07/2012 17:28, Boaz Harrosh ha scritto:
>> 1) what I get is a scsi_cmnd which contains an N-element scatterlist.
>>
>> 2) virtio-scsi has to build the "packet" that is passed to the hardware
>> (it does not matter that the hardware is virtual). This packet (per
>> virtio-scsi spec) has an N+
Il 25/07/2012 21:16, Boaz Harrosh ha scritto:
> The picture confused me. It looked like the first element is the
> virtio_scsi_cmd_req
> not an sgilist-element that points to the struct's buffer.
>
> In that case then yes your plan of making a two-elements fragment that points
> to the
> origina
Il 25/07/2012 23:04, Boaz Harrosh ha scritto:
>> That not all architectures have ARCH_HAS_SG_CHAIN (though all those I
>> care about do). So I need to go through all architectures and make sure
>> they use for_each_sg, or at least to change ARCH_HAS_SG_CHAIN to a
>> Kconfig define so that dependen
Il 26/07/2012 09:56, Boaz Harrosh ha scritto:
>> > In the meanwhile, we still have a bug to fix, and we need to choose
>> > between Sen Wang's v1 (sg_set_page) or v2 (value assignment). I'm still
>> > leaning more towards v2, if only because I already tested that one myself.
>
> It's your call, y
Il 05/07/2012 13:40, Sasha Levin ha scritto:
> @@ -275,7 +274,7 @@ static void vm_del_vq(struct virtqueue *vq)
> vring_del_virtqueue(vq);
>
> /* Select and deactivate the queue */
> - writel(info->queue_index, vm_dev->base + VIRTIO_MMIO_QUEUE_SEL);
> + writel(virtqueue
Il 26/07/2012 09:58, Paolo Bonzini ha scritto:
>
>> > Please CC me on the "convert to sg copy-less" patches, It looks interesting
> Sure.
Well, here is the gist of it (note it won't apply on any public tree,
hence no SoB yet). It should be split in multiple ch
capacity change from 22548578304 to 23622320128
Signed-off-by: Paolo Bonzini
---
drivers/scsi/virtio_scsi.c | 31 ++-
include/linux/virtio_scsi.h |2 ++
2 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi
irtio-scsi
LUNs, which needs to be rebased.
LUNs above 255 now work for all of scanning, hotplug, hotunplug and
resize.
Thanks,
Paolo
Paolo Bonzini (2):
virtio-scsi: fix LUNs greater than 255
virtio-scsi: support online resizing of disks
drivers/scsi/virtio_scsi
d with the "flat" format.
Cc:
Signed-off-by: Paolo Bonzini
---
drivers/scsi/virtio_scsi.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index c7030fb..8b6b927 100644
--- a/drivers/scsi/virtio_scsi.
Il 27/07/2012 08:27, Rusty Russell ha scritto:
>> > +int virtqueue_add_buf_sg(struct virtqueue *_vq,
>> > + struct scatterlist *sg_out,
>> > + unsigned int out,
>> > + struct scatterlist *sg_in,
>> > + unsigned int in,
>> > +
Il 05/07/2012 12:29, Jason Wang ha scritto:
> Sometimes, virtio device need to configure irq affiniry hint to maximize the
> performance. Instead of just exposing the irq of a virtqueue, this patch
> introduce an API to set the affinity for a virtqueue.
>
> The api is best-effort, the affinity hin
1 - 100 of 4462 matches
Mail list logo
