On Mon, Jul 09, 2012 at 11:44:11AM +0200, Alexander Graf wrote:
>
> 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.
>
Yeah, so pci addr space should be reinitialized to. Definitely hacky.
--
Gleb.
