On Fri, 2007-07-13 at 17:39 +0200, Luca wrote: > On 7/13/07, Gregory Haskins <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-07-13 at 16:46 +0200, Luca wrote: > > > On 7/13/07, Gregory Haskins <[EMAIL PROTECTED]> wrote: > > > > > Just to clarify: you are suggesting that the "old" IDE driver used to > > > see that the controller was disabled and reprogrammed it by itself > > > (fast mode); now it sees it's enabled and leaves whatever mode is > > > currently set. > > > I can't look at the sources right now but it's at least plausible ;-) > > > > > > > Yeah. As Im sure you are aware, those bits that your patch modifies are > > (IIUC) for enabling/disabling access to the legacy IDE. On real > > hardware, they can be used by the bios to enable/disable the legacy IDE > > function. It doesnt actually disable the chip IIUC.. > > Hum, are you *really* sure? Intel doc says:
Of course not! That was a long time ago and my memory is fuzzy :P > > "IDE Decode Enable (IDE). 1=Enable; 0=Disable. When enabled, I/O > transactions on PCI > targeting the IDE ATA register blocks (command block and control > block) are positively > decoded on PCI and driven on the IDE interface. When disabled, these > accesses are > subtractively decoded to ISA." > > Now, "subtractively decoded to ISA" means that if nobody wants them > then those accesses are left to ISA devices (the PCI-to-ISA bridge > forwards them). > So IIRC setting the decode enable to 0 really means "disable the controller". I think what you say is 100% accurate, but you are taking what I was saying too literally. All I meant was that I don't think setting those bits to enabled/disabled actually affects whether the IDE subsystem can still be *used* or not...but rather it affects the interface that can be used to access them. I could very well be totally wrong here, but the way I see it is that some of these chips like the ICH present multiple abstractions to a single subsystem. I.e. there might be ISA representation for a feature X, as well as a PCI representation. Both of these features end up at the same "IDE ribbon cable" so to speak, but the logical controller abstraction is overloaded on multiple interfaces (e.g. ISA and PCI) and can be independently manipulated. Those bits in question enable the presentation of the standard IDE interfaces. However, IIRC there are ways to access the ide without using the legacy IDE command/control blocks (e.g. via a PIIX3 mass storage controller in PCI space). > > > its just a flag to let higher layer software detect if the legacy IDE is > > usable. In our > > emulated environment, those bits were left undefined prior to your patch > > (neither qemu nor bochs was configuring them). > > Bochs *is* enabling the ports; it's just that it does that in the > emulated device (i.e. the equivalent of out hw/ide.c) and not in the > BIOS. I don't doubt you, but that is contrary to the observed behavior I saw. My SLED installed kept telling me I didnt have a valid hard-disk. Debugging, I found that the IDE subsystem was skipping the disks because they were disabled in bios..leading me to make a similar patch as yours which fixed the problem. If bochs was setting those bits, they were gone by the time the installer got to them ;) > > Btw, the original thread is there: > http://thread.gmane.org/gmane.comp.emulators.kvm.devel/3619 > > > So what I am thinking is that the drivers included with the FC7 kernel > > are defaulting to some kind of slower legacy mode when they see it is > > available and enabled. Otherwise, they probably load some direct > > non-legacy PCI driver and use that instead. > > Nope, FC7 with libata doesn't find anything at all. It doesn't even > try to touch the controller if the ports are not enabled. This makes a > lot of sense since with ports disabled all the access to the command > and control blocks are forwarded to the ISA worlds (since the IDE > controller is not claiming the transactions). > I guess that the old driver has some logic like "BIOS is stupid, we > really want to enable this port". > Still, I fail to see why enabling the ports should reduce the speed. > Dave, can you confirm that backing out my patch fixes your speed issue? I don't think this is what is happening. I think what happens is the legacy IDE driver tries its probe and fails due to the disabled bits. Later a different driver succeeds at its probe (e.g. say a PCI based PIIX3 or similar). Likewise, I am guessing that this other driver is more efficient at virtualization due to its interaction with the device. But, like I mentioned, I am guessing here. ;) ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
