Re: [Qemu-devel] [PATCH v2 02/22] virtio: run drivers in 32bit mode
Hi, > > Not really any more. Switching from 32bit mode back to > > whatever-was-active-before used to be problematic before we had smm mode > > support. In theory. Because you can't save/restore the complete x86 > > processor state. In practice we had surprisingly few problems, > > appearently linux boot loaders simply don't play dirty tricks. > > > Interesting. Might not be true for non-linux loaders :) No problems with modern windows too. DOS with emm386 being active could be more challenging. Didn't dig that deep though, and as the ide driver runs in 16bit mode still there is an easy way around any isses should they pop up. > Anyway we support SSM now so all should be well, right? Yes, with smm this issue is gone. cheers, Gerd
Re: [Qemu-devel] [PATCH v2 02/22] virtio: run drivers in 32bit mode
On Wed, Jul 01, 2015 at 03:50:50PM +0200, Michael S. Tsirkin wrote: > On Wed, Jul 01, 2015 at 02:30:29PM +0200, Gerd Hoffmann wrote: > > On Mi, 2015-07-01 at 10:08 +0200, Michael S. Tsirkin wrote: > > > On Tue, Jun 30, 2015 at 10:38:53AM +0200, 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. > > > > > > > > Signed-off-by: Gerd Hoffmann > > > > > > Is there an advantage to running them in a 16 bit mode? > > > > Not really any more. Switching from 32bit mode back to > > whatever-was-active-before used to be problematic before we had smm mode > > support. In theory. Because you can't save/restore the complete x86 > > processor state. In practice we had surprisingly few problems, > > appearently linux boot loaders simply don't play dirty tricks. > > > > cheers, > > Gerd > > > > Interesting. Might not be true for non-linux loaders :) > > Anyway we support SSM now so all should be well, right? Also a question: what's cheaper on kvm: use SMM to save/restore or access device through the config cap? > -- > MST
Re: [Qemu-devel] [PATCH v2 02/22] virtio: run drivers in 32bit mode
On Wed, Jul 01, 2015 at 02:30:29PM +0200, Gerd Hoffmann wrote: > On Mi, 2015-07-01 at 10:08 +0200, Michael S. Tsirkin wrote: > > On Tue, Jun 30, 2015 at 10:38:53AM +0200, 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. > > > > > > Signed-off-by: Gerd Hoffmann > > > > Is there an advantage to running them in a 16 bit mode? > > Not really any more. Switching from 32bit mode back to > whatever-was-active-before used to be problematic before we had smm mode > support. In theory. Because you can't save/restore the complete x86 > processor state. In practice we had surprisingly few problems, > appearently linux boot loaders simply don't play dirty tricks. > > cheers, > Gerd > Interesting. Might not be true for non-linux loaders :) Anyway we support SSM now so all should be well, right? -- MST
Re: [Qemu-devel] [PATCH v2 02/22] virtio: run drivers in 32bit mode
On Mi, 2015-07-01 at 10:08 +0200, Michael S. Tsirkin wrote: > On Tue, Jun 30, 2015 at 10:38:53AM +0200, 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. > > > > Signed-off-by: Gerd Hoffmann > > Is there an advantage to running them in a 16 bit mode? Not really any more. Switching from 32bit mode back to whatever-was-active-before used to be problematic before we had smm mode support. In theory. Because you can't save/restore the complete x86 processor state. In practice we had surprisingly few problems, appearently linux boot loaders simply don't play dirty tricks. cheers, Gerd
Re: [Qemu-devel] [PATCH v2 02/22] virtio: run drivers in 32bit mode
On Tue, Jun 30, 2015 at 10:38:53AM +0200, 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.
>
> Signed-off-by: Gerd Hoffmann
Is there an advantage to running them in a 16 bit mode?
If yes - it's actually possible to access virtio in 16 bit mode because
all virtio devices have a special capability which maps memory into pci
config space. So you can poke memory (slowly) through the cf8/cfc
registers.
It's missing in QEMU but that's a clear spec violation: spec
says it's mandatory.
I'll code it up and send an RFC shortly.
> ---
> src/block.c | 8 +---
> src/hw/virtio-blk.c | 2 +-
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> 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)
> --
> 1.8.3.1
[Qemu-devel] [PATCH v2 02/22] virtio: run drivers in 32bit mode
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
---
src/block.c | 8 +---
src/hw/virtio-blk.c | 2 +-
2 files changed, 6 insertions(+), 4 deletions(-)
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)
--
1.8.3.1
