diff mbox

[02/18] virtio: run drivers in 32bit mode

Message ID 1435568020-8669-3-git-send-email-kraxel@redhat.com
State New
Headers show

Commit Message

Gerd Hoffmann June 29, 2015, 8:53 a.m. UTC
virtio version 1.0 registers can (and actually do in the qemu
implementation) live in mmio space.  So we must run the blk and
scsi virtio drivers in 32bit mode, otherwise we can't access them.

This also allows to drop a bunch of GET_LOWFLAT calls from the virtio
code in the following patches.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 src/block.c         | 8 +++++---
 src/hw/virtio-blk.c | 2 +-
 2 files changed, 6 insertions(+), 4 deletions(-)

Comments

Paolo Bonzini July 3, 2015, 6:45 a.m. UTC | #1
On 29/06/2015 10:53, Gerd Hoffmann wrote:
> virtio version 1.0 registers can (and actually do in the qemu
> implementation) live in mmio space.  So we must run the blk and
> scsi virtio drivers in 32bit mode, otherwise we can't access them.
> 
> This also allows to drop a bunch of GET_LOWFLAT calls from the virtio
> code in the following patches.

This isn't really necessary though.  The config access capability exists
for this reason.  At least as a follow up it would be nice to add a switch.

Paolo
Gerd Hoffmann July 3, 2015, 7:12 a.m. UTC | #2
On Fr, 2015-07-03 at 08:45 +0200, Paolo Bonzini wrote:
> 
> On 29/06/2015 10:53, Gerd Hoffmann wrote:
> > virtio version 1.0 registers can (and actually do in the qemu
> > implementation) live in mmio space.  So we must run the blk and
> > scsi virtio drivers in 32bit mode, otherwise we can't access them.
> > 
> > This also allows to drop a bunch of GET_LOWFLAT calls from the virtio
> > code in the following patches.
> 
> This isn't really necessary though.  The config access capability exists
> for this reason.  At least as a follow up it would be nice to add a switch.

Just saw mst's patch implementing it in qemu.  I'll have a look. 

I think I want keep the virtio drivers as 32bit drivers.  The modern
virtio bar is a 64bit though, so accessing via config access capability
might be needed even for the 32bit drivers in case it is mapped above
4G ...

cheers,
  Gerd
diff mbox

Patch

diff --git a/src/block.c b/src/block.c
index 3f7ecb1..a9b9851 100644
--- a/src/block.c
+++ b/src/block.c
@@ -503,8 +503,10 @@  process_op(struct disk_op_s *op)
     case DTYPE_CDEMU:
         ret = process_cdemu_op(op);
         break;
-    case DTYPE_VIRTIO_BLK:
-        ret = process_virtio_blk_op(op);
+    case DTYPE_VIRTIO_BLK: ;
+        extern void _cfunc32flat_process_virtio_blk_op(void);
+        ret = call32(_cfunc32flat_process_virtio_blk_op
+                     , (u32)MAKE_FLATPTR(GET_SEG(SS), op), DISK_RET_EPARAM);
         break;
     case DTYPE_AHCI: ;
         extern void _cfunc32flat_process_ahci_op(void);
@@ -526,7 +528,6 @@  process_op(struct disk_op_s *op)
         break;
     case DTYPE_USB:
     case DTYPE_UAS:
-    case DTYPE_VIRTIO_SCSI:
     case DTYPE_LSI_SCSI:
     case DTYPE_ESP_SCSI:
     case DTYPE_MEGASAS:
@@ -534,6 +535,7 @@  process_op(struct disk_op_s *op)
         break;
     case DTYPE_USB_32:
     case DTYPE_UAS_32:
+    case DTYPE_VIRTIO_SCSI:
     case DTYPE_PVSCSI: ;
         extern void _cfunc32flat_scsi_process_op(void);
         ret = call32(_cfunc32flat_scsi_process_op
diff --git a/src/hw/virtio-blk.c b/src/hw/virtio-blk.c
index e2dbd3c..15ac171 100644
--- a/src/hw/virtio-blk.c
+++ b/src/hw/virtio-blk.c
@@ -77,7 +77,7 @@  virtio_blk_op(struct disk_op_s *op, int write)
     return status == VIRTIO_BLK_S_OK ? DISK_RET_SUCCESS : DISK_RET_EBADTRACK;
 }
 
-int
+int VISIBLE32FLAT
 process_virtio_blk_op(struct disk_op_s *op)
 {
     if (! CONFIG_VIRTIO_BLK)