On Tue, Mar 15, 2011 at 9:16 AM, Alexander Graf <[email protected]> wrote: > > On 15.03.2011, at 10:03, Stefan Hajnoczi wrote: > >> On Tue, Mar 15, 2011 at 7:47 AM, Alexander Graf <[email protected]> wrote: >>> >>> On 15.03.2011, at 08:09, Stefan Hajnoczi wrote: >>> >>>> On Mon, Mar 14, 2011 at 10:57 PM, Guido Winkelmann >>>> <[email protected]> wrote: >>>>> On Monday 14 March 2011 20:32:23 Stefan Hajnoczi wrote: >>>>>> On Mon, Mar 14, 2011 at 6:05 PM, Guido Winkelmann >>>>>> >>>>>> <[email protected]> wrote: >>>>>>> Does anybody have an idea what might cause this or what might be done >>>>>>> about it? >>>>>> >>>>>> The lsi_scsi emulation code is incomplete. It does not handle some >>>>>> situations like the ORDERED commands or message 0x0c. >>>>>> >>>>>> There is a patch to address the message 0xc issue, it has not been >>>>>> applied to qemu.git or qemu-kvm.git yet: >>>>>> http://patchwork.ozlabs.org/patch/63926/ >>>>>> >>>>>> Basically there is no one actively maintaining or reviewing patches >>>>>> for the lsi53c895a SCSI controller. >>>>> >>>>> Does that mean that using the SCSI transport for virtual disks is >>>>> officially >>>>> unsupported or deprecated or that it should be? >>>> >>>> The LSI SCSI emulation in particular has not seen much attention. As >>>> for the wider SCSI emulation there has been work over the past few >>>> months so it's alive and being used. >>>> >>>>> Are things better with the IDE driver? >>>> >>>> IDE is commonly used for compatibility with guests that do not have >>>> virtio-blk drivers. It should work fine although performance is poor >>>> due to the IDE interface. >>>> >>>>>> virtio-blk works very will with Linux guests. Is there a reason you >>>>>> need to use SCSI emulation instead of virtio-blk? >>>>> >>>>> I can probably use virtio-blk most of the time, I was just hoping to be >>>>> able >>>>> to virtualize a wider array of operating systems, like the *BSDs, >>>>> (Open)Solaris, Windows, or even just some linux distributions whose >>>>> installers >>>>> don't anticipate KVM and thus don't support virtio-<anything>. >>>> >>>> Windows virtio-blk drivers are available and should be used: >>>> http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers >>>> >>>> BSD and Solaris don't ship with virtio-blk AFAIK. >>> >>> This is pretty much the gap that AHCI is trying to fill. It's a >>> well-supported HBA that pretty much every OS supports, but is still simple >>> enough to implement. Unfortunately, 0.14 ships without BIOS support for it, >>> so you can't boot off an AHCI disk yet. But as of 0.15, AHCI is pretty much >>> the adapter of choice for your use case. >>> >>> Please keep in mind that I didn't get FreeBSD rolling with AHCI emulation >>> yet. OpenBSD works just fine. >> >> I think one missing AHCI feature was legacy PATA mode? Perhaps that >> is a good GSoC project if you're willing to mentor it, Alex. I'm >> thinking that with complete AHCI and legacy mode it would be a good >> choice as the default non-virtio-blk disk interface. > > Or two be more precise: There are two different dimensions > > SATA / PATA > IDE / AHCI > > The first is the link model - the type of connection the disk/cd-rom is > connected to the hba with. The second is the OS interface. > > AHCI can handle SATA and PATA devices in AHCI mode. IIUC both link models > also work in IDE (legacy) mode. > The ICH-HBA can be BIOS configured to either operate in AHCI mode or in > legacy mode, but not both at the same time. You can split between channels > though. So you can have channels 1,2 operate through legacy while channels > 3,4 go through AHCI. The same disk still can only be accessed either through > IDE _or_ AHCI. > > Since we already have properly working PIIX3 IDE emulation code, I don't see > the point in implementing ICH-7 AHCI IDE legacy compatibility mode. > > There are SATA controllers out there that apparently can expose the same disk > through the legacy IDE interface and a faster SATA interface. I'm not sure > any of those is AHCI compatible - the spec doesn't forbid you to do this.
Okay, I was thinking that having just the AHCI device which is guest (BIOS?) configurable to work with legacy guests is nicer than having to switch QEMU command-line options on the host. But then we don't have non-volatile storage for the BIOS AFAIK, so it currently doesn't make much difference which AHCI supports IDE emulation or whether you explicitly use the piix IDE emulation. Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
