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 kraxel@redhat.com
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 :)
Without SMM, the only issue I've seen with "thunking" to 32bit mode was DOS-era programs (and in particular those that used emm386).
Anyway we support SSM now so all should be well, right?
With SMM, I haven't seen any problems. I don't doubt that some DOS-era programs might still have issues though. Also, I haven't tested Paolo's kvm smm support yet.
SeaBIOS already runs a number of drivers exclusively in 32bit mode: ahci, xhci, sdcard, ohci disks, pvscsi. Even without smm support, virtio is likely a good candidate to move to 32bit mode as I don't think there is a use case for running DOS-era programs on virtio disks. (Using 32bit only drivers results in smaller and easier to maintain code - indeed we'd like to move exclusively to 32bit drivers in the future.)
Cheers, -Kevin