[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v2] ahci: add -drive support

From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH v2] ahci: add -drive support
Date: Mon, 9 Jul 2012 11:44:11 +0200

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 <address@hidden> 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 <address@hidden>
>>>>>>> ---
>>>>>>> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]