But I certainly do _not_ want to update the SCSI disk
emulation, as this is really quite tied to the SCSI parallel
interface used by the old lsi53c895a.c.
This is completely untrue. scsi-disk.c contains no transport-specific code. It
is deliberately designed to be independent of both the
On 10/30/09 09:12, Hannes Reinecke wrote:
Gerd Hoffmann wrote:
http://repo.or.cz/w/qemu/kraxel.git?a=shortlog;h=refs/heads/scsi.v1
It is far from being completed, will continue tomorrow. Should give a
idea of the direction I'm heading to though. Comments welcome.
Yep, this looks good.
Gerd Hoffmann wrote:
On 10/29/09 05:37, Christoph Hellwig wrote:
So something like
- Get next request
- Attach iovec/bounc-buffer
- handle request (command/write/read)
- complete request (callback)
Btw, from some previuous attempts to sort out this code here are some
thing that I think
Hi,
When they do, poke me and I'll make sure to process them quickly.
Just sent.
One of
my short term goals is to get better at handling easy patches more quickly.
Great. /me tests the new process ;)
cheers,
Gerd
On 10/29/09 05:37, Christoph Hellwig wrote:
- try to create generic scsi device/request structures that the hba
driver can access, and which contain additional private data for
scsi-disk/generic. Information in the generic one would include
the information about the data
On 10/29/09 05:37, Christoph Hellwig wrote:
So something like
- Get next request
- Attach iovec/bounc-buffer
- handle request (command/write/read)
- complete request (callback)
Btw, from some previuous attempts to sort out this code here are some
thing that I think would be beneficial:
On Thu, Oct 29, 2009 at 01:57:40PM +0100, Gerd Hoffmann wrote:
Trying to go forward in review+bisect friendly baby steps. Here is what
I have now:
http://repo.or.cz/w/qemu/kraxel.git?a=shortlog;h=refs/heads/scsi.v1
It is far from being completed, will continue tomorrow. Should give a
Christoph Hellwig wrote:
On Thu, Oct 29, 2009 at 01:57:40PM +0100, Gerd Hoffmann wrote:
Trying to go forward in review+bisect friendly baby steps. Here is what
I have now:
http://repo.or.cz/w/qemu/kraxel.git?a=shortlog;h=refs/heads/scsi.v1
It is far from being completed, will continue
On Thu, Oct 29, 2009 at 10:14:19AM -0500, Anthony Liguori wrote:
Which patches are those?
http://repo.or.cz/w/qemu/kraxel.git?a=commitdiff;h=1ee5ee08e4427c3db7e1322d30cc0e58e5ca48b9
and
http://repo.or.cz/w/qemu/kraxel.git?a=commitdiff;h=a6e6178185786c582141f993272e00521d3f125a
Christoph Hellwig wrote:
On Thu, Oct 29, 2009 at 10:14:19AM -0500, Anthony Liguori wrote:
Which patches are those?
http://repo.or.cz/w/qemu/kraxel.git?a=commitdiff;h=1ee5ee08e4427c3db7e1322d30cc0e58e5ca48b9
and
Am Tue 27 Oct 2009 05:47:21 PM CET schrieb Gerd Hoffmann kra...@redhat.com:
Hi,
The device can be accessed by
-drive if=raid,file=XXX
Don't extend that qemu automagic please. The new way to handle this is:
-drive if=none,id=mydisk,file=/path/to/some/disk.img
-device megasas,id=raid
On 10/28/2009 10:11 AM, Hannes Reinecke wrote:
The problem is I don't have any documentation for the LSI parallel
SCSI controller. So I don't know if and in what shape I/O is passed
down, nor anything else. And as the SCSI disk emulation is really
tied into the LSI parallel SCSI controller, any
On Wed, Oct 28, 2009 at 09:11:29AM +0100, Hannes Reinecke wrote:
The problem is I don't have any documentation for the LSI parallel
SCSI controller. So I don't know if and in what shape I/O is passed
down, nor anything else. And as the SCSI disk emulation is really
tied into the LSI parallel
Hi,
In order to support SCSI command emulation I had to update /
patch up the existing SCSI disk support. This might be
not to everyones taste, so I'm open to alternative
suggestions.
But I certainly do _not_ want to update the SCSI disk
emulation, as this is really quite tied to the SCSI
Hi,
From a really quick view fixing up the data xfer code paths doesn't
look too bad. Think I'll give it a try.
Oh well. The interface pretty obviously designed for the esp, which is
the oldest scsi adapter in qemu ...
ESP: There is no scatter-gather support in the hardware. So for
Am Wed 28 Oct 2009 02:58:33 PM CET schrieb Gerd Hoffmann kra...@redhat.com:
Hi,
From a really quick view fixing up the data xfer code paths doesn't
look too bad. Think I'll give it a try.
Oh well. The interface pretty obviously designed for the esp, which is
the oldest scsi adapter in
On Wed, Oct 28, 2009 at 08:25:22PM +0100, Hannes Reinecke wrote:
I don't think we really need two modes.
My preferred interface here is to pass down scatter-gather lists down
with every xfer; this way it'll be the responsibility of the driver to
create the lists in the first place. If it has
Hi all,
this patchset implements an emulation for the megaraid_sas HBA.
It provides emulates an LSI MegaRAID SAS 8708EM2 HBA, ie
presenting to the guest a virtual SCSI adapter.
Internally it is using aio for read/write requests and
either SG_IO or SCSI command emulation for everything else.
The
Hi,
The device can be accessed by
-drive if=raid,file=XXX
Don't extend that qemu automagic please. The new way to handle this is:
-drive if=none,id=mydisk,file=/path/to/some/disk.img
-device megasas,id=raid
-device scsi-disk,bus=raid.0,scsi-id=1,drive=mydisk
In order to support
19 matches
Mail list logo
