On 09.07.2012, at 11:41, Gleb Natapov wrote: > On Mon, Jul 09, 2012 at 11:36:47AM +0200, Alexander Graf wrote: >> >> On 09.07.2012, at 11:27, Kevin Wolf wrote: >> >>> Am 09.07.2012 11:13, schrieb Alexander Graf: >>>> >>>> On 09.07.2012, at 11:11, Kevin Wolf wrote: >>>> >>>>> Am 09.07.2012 10:50, schrieb Markus Armbruster: >>>>>> Alexander Graf <ag...@suse.de> writes: >>>>>> >>>>>>> We've had support for creating AHCI devices using -device for a while >>>>>>> now, >>>>>>> but it's cumbersome to users. We really should provide an easier way for >>>>>>> them to leverage the power of AHCI! >>>>>>> >>>>>>> So let's introduce a new if= option to -drive, giving users the same >>>>>>> command line experience as for scsi or ide. >>>>>>> >>>>>>> Signed-off-by: Alexander Graf <ag...@suse.de> >>>>>>> >>>>>>> --- >>>>>>> >>>>>>> v1 -> v2: >>>>>>> >>>>>>> - support more than a single drive per adapter >>>>>>> - support index= option >>>>>>> - treat IF_AHCI the same as IF_IDE >>>>>> >>>>>> Inhowfar? Not obvious to me from the patch, or the diff patch v1. >>>>>> >>>>>>> - add is_ata() helper to match AHCI || IDE >>>>>> >>>>>> Not addressed: >>>>>> >>>>>> Once we switch to q35, if=ahci will become a redundant wart: to add >>>>>> drives to the board's AHCI controller, you'll have to use if=ide. >>>>>> if=ahci will create new controllers, which is generally not what you >>>>>> want. Ugh. >>>>> >>>>> Can we even make it the default with q35 as long as our AHCI controller >>>>> doesn't also expose a legacy interface for compatibility? >>>> >>>> What legacy interface? The ICH-9 can be controlled by the _BIOS_ to switch >>>> between 2 PCI IDs. One for IDE mode, one for AHCI mode. I don't think that >>>> would help us here, would it? >>> >>> I didn't actually look into this much. I just supposed that the >>> existence of an AHCI Enable bit in the GHC register implies that some >>> compatibility mechanism can be implemented that is transparent to older >>> OSes. >> >> Yeah, I was hoping the same too when I read the spec back then. >> Unfortunately, it's really a firmware configuration bit which doesn't help >> us at all. >> >> I think there is a hack in some driver somewhere that on bootup checks if >> the AHCI bit is disabled and then forcefully enables it, so that the device >> during OS boot magically changes its ID and semantics. But I don't think we >> really want to rely on that. IIRC it never went upstream and I doubt Windows >> does it. >> > Doesn't enabling the bit change PCI bars size/number?
Don't remember, but I think so. It makes it a completely different device. Alex
