Message ID | 1435568020-8669-3-git-send-email-kraxel@redhat.com |
---|---|
State | New |
Headers | show |
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
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 --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)
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(-)