qemu-devel
[Top][All Lists]
Advanced

[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.


Alex




reply via email to

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