Re: [PATCH 3/3] megasas: LSI Megaraid SAS emulation
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'm more than willing to fixup the scsi-generic backend. I am certainly going to get it upstream, but maintainers would like it to have users at the time it is committed. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] megasas: LSI Megaraid SAS emulation
On 07/04/2011 12:29 PM, Paolo Bonzini wrote: 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 hope that megasas will come before pvscsi or eliminate the need for it altogether. So, feel free to pick up patches 5-8 from that series. Hmm. My goal was actually to get the megasas HBA emulation upstream. When sticking it behind another set of patches chances are not exactly increasing. However, it would certainly make my life easier. That said, note that scsi-generic does *not* support scatter/gather in that series, so you should still make sure the fallback paths work well. :) In pvscsi I added a qdev property to toggle scatter/gather, it was useful for benchmarking. Have to check. My patchset did, so it should be reasonably easy to port that one to your infrastructure. 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. But if you promise to merge the iovec infrastructure I'm more than willing to fixup the scsi-generic backend. Just say the word. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] megasas: LSI Megaraid SAS emulation
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 hope that megasas will come before pvscsi or eliminate the need for it altogether. So, feel free to pick up patches 5-8 from that series. That said, note that scsi-generic does *not* support scatter/gather in that series, so you should still make sure the fallback paths work well. :) In pvscsi I added a qdev property to toggle scatter/gather, it was useful for benchmarking. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] megasas: LSI Megaraid SAS emulation
On 07/04/2011 08:34 AM, Paolo Bonzini wrote: 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 bounce buffers.) I agree, but I do see why a SCSI device might prefer to rely on bounce buffers for non-I/O commands. This is why in my last RFC series for vmw_pvscsi I let the device choose whether to force a bounce buffer or get an external iovec from the HBA. Yes, sure, for non-I/O commands it's perfectly okay. Most of which will be emulated anyway. It's bounce buffers for I/O which kills performance. But I seem to have missed your last RFC (I'm not reading qemu-devel on a regular basis ...). Care to send me a pointer to it? Sure, http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg00668.html Cool. Exactly what I need. FWIW, feel free to add my 'Acked-by' to it. Any chance of getting them included? Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] megasas: LSI Megaraid SAS emulation
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 bounce buffers.) I agree, but I do see why a SCSI device might prefer to rely on bounce buffers for non-I/O commands. This is why in my last RFC series for vmw_pvscsi I let the device choose whether to force a bounce buffer or get an external iovec from the HBA. Yes, sure, for non-I/O commands it's perfectly okay. Most of which will be emulated anyway. It's bounce buffers for I/O which kills performance. But I seem to have missed your last RFC (I'm not reading qemu-devel on a regular basis ...). Care to send me a pointer to it? Sure, http://lists.gnu.org/archive/html/qemu-devel/2011-06/msg00668.html Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] megasas: LSI Megaraid SAS emulation
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 bounce buffers.) I agree, but I do see why a SCSI device might prefer to rely on bounce buffers for non-I/O commands. This is why in my last RFC series for vmw_pvscsi I let the device choose whether to force a bounce buffer or get an external iovec from the HBA. Yes, sure, for non-I/O commands it's perfectly okay. Most of which will be emulated anyway. It's bounce buffers for I/O which kills performance. But I seem to have missed your last RFC (I'm not reading qemu-devel on a regular basis ...). Care to send me a pointer to it? Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] megasas: LSI Megaraid SAS emulation
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 buffers for non-I/O commands. This is why in my last RFC series for vmw_pvscsi I let the device choose whether to force a bounce buffer or get an external iovec from the HBA. Paolo -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] megasas: LSI Megaraid SAS emulation
On Fri, Jul 01, 2011 at 11:16:03AM +0200, Alexander Graf wrote:
>
> On 01.07.2011, at 09:42, Hannes Reinecke wrote:
>
> > This patch adds an emulation for the LSI Megaraid SAS 8708EM2 HBA.
> >
> > Signed-off-by: Hannes Reinecke
> > ---
> > Makefile.objs |1 +
> > default-configs/pci.mak |1 +
> > hw/megasas.c| 1923
> > +++
> > hw/mfi.h| 1197 +
> > hw/pci_ids.h|3 +-
> > 5 files changed, 3124 insertions(+), 1 deletions(-)
> > create mode 100644 hw/megasas.c
> > create mode 100644 hw/mfi.h
> >
> > diff --git a/Makefile.objs b/Makefile.objs
> > index cea15e4..6f5d113 100644
> > --- a/Makefile.objs
> > +++ b/Makefile.objs
> > @@ -258,6 +258,7 @@ hw-obj-$(CONFIG_AHCI) += ide/ich.o
> >
> > # SCSI layer
> > hw-obj-$(CONFIG_LSI_SCSI_PCI) += lsi53c895a.o
> > +hw-obj-$(CONFIG_MEGASAS_SCSI_PCI) += megasas.o
> > hw-obj-$(CONFIG_ESP) += esp.o
> >
> > hw-obj-y += dma-helpers.o sysbus.o isa-bus.o
> > diff --git a/default-configs/pci.mak b/default-configs/pci.mak
> > index 22bd350..fabb56c 100644
> > --- a/default-configs/pci.mak
> > +++ b/default-configs/pci.mak
> > @@ -9,6 +9,7 @@ CONFIG_EEPRO100_PCI=y
> > CONFIG_PCNET_PCI=y
> > CONFIG_PCNET_COMMON=y
> > CONFIG_LSI_SCSI_PCI=y
> > +CONFIG_MEGASAS_SCSI_PCI=y
> > CONFIG_RTL8139_PCI=y
> > CONFIG_E1000_PCI=y
> > CONFIG_IDE_CORE=y
> > diff --git a/hw/megasas.c b/hw/megasas.c
> > new file mode 100644
> > index 000..75f9be3
> > --- /dev/null
> > +++ b/hw/megasas.c
> > @@ -0,0 +1,1923 @@
> > +/*
> > + * QEMU MegaRAID SAS 8708EM2 Host Bus Adapter emulation
> > + *
> > + * Copyright (c) 2009-2011 Hannes Reinecke, SUSE Labs
> > + *
> > + * This code is licenced under the LGPL.
>
> Please take a look at the license header of other LGPL code and just copy it
> :).
>
> > + */
> > +
> > +#include
> > +#include
>
> Are you sure you need to manually include those?
>
> > +
> > +#include "hw.h"
> > +#include "pci.h"
> > +#include "dma.h"
> > +#include "iov.h"
> > +#include "scsi.h"
> > +#include "scsi-defs.h"
> > +#include "block_int.h"
> > +#ifdef __linux__
> > +# include
>
> Is this really necessary? Device code shouldn't be host dependent IMHO. I
> also haven't found any user of this in the actual code, so it might be as
> easy as merely removing the include :).
>
> > +#endif
> > +
> > +#include "mfi.h"
> > +
> > +#define DEBUG_MEGASAS
> > +#undef DEBUG_MEGASAS_REG
> > +#undef DEBUG_MEGASAS_QUEUE
> > +#undef DEBUG_MEGASAS_MFI
> > +#undef DEBUG_MEGASAS_IO
> > +#undef DEBUG_MEGASAS_DCMD
> > +
> > +#ifdef DEBUG_MEGASAS
> > +#define DPRINTF(fmt, ...) \
> > +do { printf("megasas: " fmt , ## __VA_ARGS__); } while (0)
> > +#define BADF(fmt, ...) \
> > +do { fprintf(stderr, "megasas: error: " fmt , ## __VA_ARGS__); exit(1);}
> > while (0)
> > +#ifdef DEBUG_MEGASAS_REG
> > +#define DPRINTF_REG DPRINTF
> > +#else
> > +#define DPRINTF_REG(fmt, ...) do {} while(0)
> > +#endif
> > +#ifdef DEBUG_MEGASAS_QUEUE
> > +#define DPRINTF_QUEUE DPRINTF
> > +#else
> > +#define DPRINTF_QUEUE(fmt, ...) do {} while(0)
> > +#endif
> > +#ifdef DEBUG_MEGASAS_MFI
> > +#define DPRINTF_MFI DPRINTF
> > +#else
> > +#define DPRINTF_MFI(fmt, ...) do {} while(0)
> > +#endif
> > +#ifdef DEBUG_MEGASAS_IO
> > +#define DPRINTF_IO DPRINTF
> > +#else
> > +#define DPRINTF_IO(fmt, ...) do {} while(0)
> > +#endif
> > +#ifdef DEBUG_MEGASAS_DCMD
> > +#define DPRINTF_DCMD DPRINTF
> > +#else
> > +#define DPRINTF_DCMD(fmt, ...) do {} while(0)
> > +#endif
> > +#else
> > +#define DPRINTF(fmt, ...) do {} while(0)
> > +#define DPRINTF_REG DPRINTF
> > +#define DPRINTF_QUEUE DPRINTF
> > +#define DPRINTF_MFI DPRINTF
> > +#define DPRINTF_IO DPRINTF
> > +#define DPRINTF_DCMD DPRINTF
> > +#define BADF(fmt, ...) \
> > +do { fprintf(stderr, "megasas: error: " fmt , ## __VA_ARGS__);} while (0)
> > +#endif
> > +
> > +/* Static definitions */
> > +#define MEGASAS_VERSION "1.20"
> > +#define MEGASAS_MAX_FRAMES 2048 /* Firmware limit at 65535 */
> > +#define MEGASAS_DEFAULT_FRAMES 1000 /* Windows requires this */
> > +#define MEGASAS_MAX_SGE 256 /* Firmware limit */
> > +#define MEGASAS_DEFAULT_SGE 80
> > +#define MEGASAS_MAX_SECTORS 0x /* No real limit */
> > +#define MEGASAS_MAX_ARRAYS 128
> > +
> > +const char *mfi_frame_desc[] = {
> > +"MFI init", "LD Read", "LD Write", "LD SCSI", "PD SCSI",
> > +"MFI Doorbell", "MFI Abort", "MFI SMP", "MFI Stop"};
> > +
> > +struct megasas_cmd_t {
> > +int index;
> > +int context;
> > +int count;
> > +
> > +target_phys_addr_t pa;
> > +target_phys_addr_t pa_size;
> > +union mfi_frame *frame;
> > +SCSIRequest *req;
> > +struct iovec *iov;
> > +void *iov_buf;
> > +long iov_cnt;
> > +long iov_size;
> > +long iov_offset;
>
> Why would anything be a long? It's either target_ulong or uintXX_t for device
> code usually :).
>
> > +SCSIDevice *sdev;
> > +struct megasas_state
Re: [PATCH 3/3] megasas: LSI Megaraid SAS emulation
Am 02.07.2011 um 15:50 schrieb Hannes Reinecke : > On 07/01/2011 06:42 PM, Alexander Graf wrote: >> >> On 01.07.2011, at 17:35, Hannes Reinecke wrote: >> >>> This patch adds an emulation for the LSI Megaraid SAS 8708EM2 HBA. >> >> Have you tried to execute the current version of megasas and actually > > do something with it? I just booted up openSUSE 11.4 rescue from DVD > > with a megasas adapter that contained a raw file backed by tmpfs. > > Creating a partition worked fine, but when running mkfs.ext3 and > > mounting afterwards, the mount fails saying there is no ext3 on the disk. >> >> Sounds like data corruption to me :). I know that this used to work > > a while back, so it might be a regression recently? >> > It worked here, in the sense that I've booted up an existing openSUSE 11.4 > installation. But I wouldn't be surprised if the degradation to use > bounce-buffers has some flaws. > > My guess here is that we have problems when the transfersizes larger as the > internal bounce buffer. Ah, might be a good idea to have some check for that. Just assert() out when the bounce buffer is too small - or at least tell the user about it. Can the iov functions tell you if you exceed the write/read side? > > (I probably should be putting in some more references to 'bounce buffers' > here to alert people that using bounce buffers in SCSI is the best way of > killing performance) > (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.) My hope is that by approaching this incrementally, we can move to a 0-copy approach later on. But for now, let's focus on getting the device emulation part well working an in. > > But enough of this, Yeah, bugfixing is needed here. I see what I can do. Thanks :) Alex > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] megasas: LSI Megaraid SAS emulation
On 07/01/2011 06:42 PM, Alexander Graf wrote: On 01.07.2011, at 17:35, Hannes Reinecke wrote: This patch adds an emulation for the LSI Megaraid SAS 8708EM2 HBA. Have you tried to execute the current version of megasas and actually > do something with it? I just booted up openSUSE 11.4 rescue from DVD > with a megasas adapter that contained a raw file backed by tmpfs. > Creating a partition worked fine, but when running mkfs.ext3 and > mounting afterwards, the mount fails saying there is no ext3 on the disk. Sounds like data corruption to me :). I know that this used to work > a while back, so it might be a regression recently? It worked here, in the sense that I've booted up an existing openSUSE 11.4 installation. But I wouldn't be surprised if the degradation to use bounce-buffers has some flaws. My guess here is that we have problems when the transfersizes larger as the internal bounce buffer. (I probably should be putting in some more references to 'bounce buffers' here to alert people that using bounce buffers in SCSI is the best way of killing performance) (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.) But enough of this, Yeah, bugfixing is needed here. I see what I can do. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] megasas: LSI Megaraid SAS emulation
On 01.07.2011, at 17:35, Hannes Reinecke wrote: > This patch adds an emulation for the LSI Megaraid SAS 8708EM2 HBA. Have you tried to execute the current version of megasas and actually do something with it? I just booted up openSUSE 11.4 rescue from DVD with a megasas adapter that contained a raw file backed by tmpfs. Creating a partition worked fine, but when running mkfs.ext3 and mounting afterwards, the mount fails saying there is no ext3 on the disk. Sounds like data corruption to me :). I know that this used to work a while back, so it might be a regression recently? Alex -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] megasas: LSI Megaraid SAS emulation
On 01.07.2011, at 09:42, Hannes Reinecke wrote:
> This patch adds an emulation for the LSI Megaraid SAS 8708EM2 HBA.
>
> Signed-off-by: Hannes Reinecke
> ---
> Makefile.objs |1 +
> default-configs/pci.mak |1 +
> hw/megasas.c| 1923 +++
> hw/mfi.h| 1197 +
> hw/pci_ids.h|3 +-
> 5 files changed, 3124 insertions(+), 1 deletions(-)
> create mode 100644 hw/megasas.c
> create mode 100644 hw/mfi.h
>
> diff --git a/Makefile.objs b/Makefile.objs
> index cea15e4..6f5d113 100644
> --- a/Makefile.objs
> +++ b/Makefile.objs
> @@ -258,6 +258,7 @@ hw-obj-$(CONFIG_AHCI) += ide/ich.o
>
> # SCSI layer
> hw-obj-$(CONFIG_LSI_SCSI_PCI) += lsi53c895a.o
> +hw-obj-$(CONFIG_MEGASAS_SCSI_PCI) += megasas.o
> hw-obj-$(CONFIG_ESP) += esp.o
>
> hw-obj-y += dma-helpers.o sysbus.o isa-bus.o
> diff --git a/default-configs/pci.mak b/default-configs/pci.mak
> index 22bd350..fabb56c 100644
> --- a/default-configs/pci.mak
> +++ b/default-configs/pci.mak
> @@ -9,6 +9,7 @@ CONFIG_EEPRO100_PCI=y
> CONFIG_PCNET_PCI=y
> CONFIG_PCNET_COMMON=y
> CONFIG_LSI_SCSI_PCI=y
> +CONFIG_MEGASAS_SCSI_PCI=y
> CONFIG_RTL8139_PCI=y
> CONFIG_E1000_PCI=y
> CONFIG_IDE_CORE=y
> diff --git a/hw/megasas.c b/hw/megasas.c
> new file mode 100644
> index 000..75f9be3
> --- /dev/null
> +++ b/hw/megasas.c
> @@ -0,0 +1,1923 @@
> +/*
> + * QEMU MegaRAID SAS 8708EM2 Host Bus Adapter emulation
> + *
> + * Copyright (c) 2009-2011 Hannes Reinecke, SUSE Labs
> + *
> + * This code is licenced under the LGPL.
Please take a look at the license header of other LGPL code and just copy it :).
> + */
> +
> +#include
> +#include
Are you sure you need to manually include those?
> +
> +#include "hw.h"
> +#include "pci.h"
> +#include "dma.h"
> +#include "iov.h"
> +#include "scsi.h"
> +#include "scsi-defs.h"
> +#include "block_int.h"
> +#ifdef __linux__
> +# include
Is this really necessary? Device code shouldn't be host dependent IMHO. I also
haven't found any user of this in the actual code, so it might be as easy as
merely removing the include :).
> +#endif
> +
> +#include "mfi.h"
> +
> +#define DEBUG_MEGASAS
> +#undef DEBUG_MEGASAS_REG
> +#undef DEBUG_MEGASAS_QUEUE
> +#undef DEBUG_MEGASAS_MFI
> +#undef DEBUG_MEGASAS_IO
> +#undef DEBUG_MEGASAS_DCMD
> +
> +#ifdef DEBUG_MEGASAS
> +#define DPRINTF(fmt, ...) \
> +do { printf("megasas: " fmt , ## __VA_ARGS__); } while (0)
> +#define BADF(fmt, ...) \
> +do { fprintf(stderr, "megasas: error: " fmt , ## __VA_ARGS__); exit(1);}
> while (0)
> +#ifdef DEBUG_MEGASAS_REG
> +#define DPRINTF_REG DPRINTF
> +#else
> +#define DPRINTF_REG(fmt, ...) do {} while(0)
> +#endif
> +#ifdef DEBUG_MEGASAS_QUEUE
> +#define DPRINTF_QUEUE DPRINTF
> +#else
> +#define DPRINTF_QUEUE(fmt, ...) do {} while(0)
> +#endif
> +#ifdef DEBUG_MEGASAS_MFI
> +#define DPRINTF_MFI DPRINTF
> +#else
> +#define DPRINTF_MFI(fmt, ...) do {} while(0)
> +#endif
> +#ifdef DEBUG_MEGASAS_IO
> +#define DPRINTF_IO DPRINTF
> +#else
> +#define DPRINTF_IO(fmt, ...) do {} while(0)
> +#endif
> +#ifdef DEBUG_MEGASAS_DCMD
> +#define DPRINTF_DCMD DPRINTF
> +#else
> +#define DPRINTF_DCMD(fmt, ...) do {} while(0)
> +#endif
> +#else
> +#define DPRINTF(fmt, ...) do {} while(0)
> +#define DPRINTF_REG DPRINTF
> +#define DPRINTF_QUEUE DPRINTF
> +#define DPRINTF_MFI DPRINTF
> +#define DPRINTF_IO DPRINTF
> +#define DPRINTF_DCMD DPRINTF
> +#define BADF(fmt, ...) \
> +do { fprintf(stderr, "megasas: error: " fmt , ## __VA_ARGS__);} while (0)
> +#endif
> +
> +/* Static definitions */
> +#define MEGASAS_VERSION "1.20"
> +#define MEGASAS_MAX_FRAMES 2048 /* Firmware limit at 65535 */
> +#define MEGASAS_DEFAULT_FRAMES 1000 /* Windows requires this */
> +#define MEGASAS_MAX_SGE 256 /* Firmware limit */
> +#define MEGASAS_DEFAULT_SGE 80
> +#define MEGASAS_MAX_SECTORS 0x /* No real limit */
> +#define MEGASAS_MAX_ARRAYS 128
> +
> +const char *mfi_frame_desc[] = {
> +"MFI init", "LD Read", "LD Write", "LD SCSI", "PD SCSI",
> +"MFI Doorbell", "MFI Abort", "MFI SMP", "MFI Stop"};
> +
> +struct megasas_cmd_t {
> +int index;
> +int context;
> +int count;
> +
> +target_phys_addr_t pa;
> +target_phys_addr_t pa_size;
> +union mfi_frame *frame;
> +SCSIRequest *req;
> +struct iovec *iov;
> +void *iov_buf;
> +long iov_cnt;
> +long iov_size;
> +long iov_offset;
Why would anything be a long? It's either target_ulong or uintXX_t for device
code usually :).
> +SCSIDevice *sdev;
> +struct megasas_state_t *state;
> +};
> +
> +typedef struct megasas_state_t {
> +PCIDevice dev;
> +int mmio_io_addr;
> +int io_addr;
> +int queue_addr;
> +uint32_t frame_hi;
> +
> +int fw_state;
> +uint32_t fw_sge;
> +uint32_t fw_cmds;
> +int fw_luns;
> +int intr_mask;
> +int doorbell;
> +int busy;
> +char *raid_mode_str;
> +int is_jbod;
> +
> +int event_co
