2008/757 SPARC support for AST graphics

[Terry (Sarito) Whatley]

Garrett D'Amore wrote:
> Eric Sultan wrote:
>   
>> I'd not realized that DDI_SUSPEND/DDI_RESUME was no longer a factor in 
>> Solaris 10.  I'll look into that, and am prepared to be surprised.  
>> Still, we like our source code to be as alike as possible across OS 
>> versions, so the team would deliver it into Solaris 10 anyway.
>>     
>
> Sounds reasonable. ;-)  On S10, SUSPEND/RESUME was only ever implemented 
> for SPARC workstations and certain high end servers.  (On the 
> workstations it was done for E*Star compliance.  On the E10K class 
> server -- and possibly others -- it was used to prevent changes to 
> kernel memory while performing a DR operation on the memory board 
> containing the kernel cage.)  I don't believe any "modern" SPARC server 
> still relies on it, although I suppose it might be used on the high end 
> M class or E25Kish systems.
>
>   
>> The x86 support for ast won't use the SPARC kernel device driver, nor 
>> an x86 kernel driver, so the quiesce question is not a factor for ast 
>> on x86.  At least, not as a part of this project.
>>     
>
> OK, that seems fair enough.  If you're not using a kernel driver on x86, 
> even the SUSPEND/RESUME support is probably deferrable.   I'd be 
> surprised if this driver were used on any SPARC system capable (at this 
> time) of suspend/resume.
>   

I believe that this has been correctly handled by the driver team (from 
a more recent email from
Eric stating that they would support DDI_SUSPEND/   DDI_RESUME), but I 
need to
put in a word to say that DDI_SUSPEND/DDI_RESUME is still very much 
alive on SPARC systems (there
is an LDoms migration prototype that uses the suspend to ram 
functionality that was introduced into the kernel
by the X64 team to suspend domains for migration, and that requires 
every driver to support DDI_SUSPEND/
DDI_RESUME.  This is a first class interface, and must be supported in 
all drivers on all platforms that the
driver will be used on.  We have had only grief every time a driver did 
not support these.

thanks,
sarito

>     -- Garrett
>   
>>  -- Eric
>>
>>
>> Garrett D'Amore wrote:
>>     
>>> Eric Sultan wrote:
>>>       
>>>> The project team agrees that quiesce and suspend/resume should be 
>>>> supported.
>>>>
>>>> Solaris 10 deliveries will include support for DDI_SUSPEND and 
>>>> DDI_RESUME.
>>>>
>>>> Post-Solaris 10 deliveries will also include support for 
>>>> quiesce(9e).  In the initial deliveries, the quiesce vector in the 
>>>> dev_ops struct will be set to ddi_quiesce_not_supported if the 
>>>> target OS doesn't yet have any quiesce users.  When the Fast Reboot 
>>>> team delivers code that uses quiesce, the ast driver will replace 
>>>> that vector with one to a device-specific quiesce entry point.
>>>>         
>>> I'm happy with this response.  Note that on x86, there are already 
>>> quiesce() users.  So on x86 at least, quiesce should be supported on 
>>> Nevada from the initial point of integration.
>>>
>>> (As an aside, I'm not sure there is any point in doing 
>>> DDI_SUSPEND/RESUME on Solaris 10.  None of the SPARC platforms in 
>>> question can SUSPEND/RESUME -- or at least I don't think they can -- 
>>> and x86 SUSPEND/RESUME is only supported on Solaris 
>>> Nevada/OpenSolaris.   So you might have a difficult time verifying 
>>> suspend/resume on S10.)
>>>
>>>    -- Garrett
>>>       
>>>>   -- Eric
>>>>
>>>>
>>>>
>>>>
>>>> Sherry Moore wrote:
>>>>         
>>>>> quiesce(9E) is a newly (since build 100) added dev_ops entry point
>>>>>     http://docs.sun.com/app/docs/doc/819-2255/quiesce-9e?l=en&a=view
>>>>>
>>>>> The Fast Reboot team would like the SPARC AST project team to state
>>>>> in the final case material
>>>>>
>>>>>     1. that quiesce(9E) will not be implemented at initial integration
>>>>>        and why.
>>>>>
>>>>>     2. their commitment to implement quiesce(9E) when SPARC Fast 
>>>>> Reboot
>>>>>        project is in progress.
>>>>>
>>>>> Thanks,
>>>>> Sherry
>>>>>
>>>>> On Wed, Dec 10, 2008 at 10:28:56AM -0800, Garrett D'Amore wrote:
>>>>>  
>>>>>           
>>>>>> At PSARC today, this was let run, because of the question of 
>>>>>> quiesce(9e) support.  PSARC would like to see either the project 
>>>>>> team agree to implement quiesce(9e)  or a written statement from 
>>>>>> the Fast Reboot team clarifying that quiesce() is not needed for 
>>>>>> this project.
>>>>>>
>>>>>> (Note that while I understand the project title indicates SPARC, 
>>>>>> earlier discussion has revealed that this project also shares code 
>>>>>> with x86.  I personally believe the quiesce question is more 
>>>>>> germane to x86 at the moment, but I'm not sure if that is 
>>>>>> tantamount to granting a blanket waiver for SPARC drivers.)
>>>>>>
>>>>>> The same questions can also be made of DDI_SUSPEND and DDI_RESUME, 
>>>>>> though I perceive that there is less urgency here (given that this 
>>>>>> is intended for server products).
>>>>>>
>>>>>> As a final personal note, I expect that if the project team simply 
>>>>>> agrees to implement both suspend/resume and quiesce, that this 
>>>>>> case will be approved with no further objections.
>>>>>>
>>>>>>    - -Garrett
>>>>>>     
>>>>>>             
>>>>>   
>>>>>           
>
> _______________________________________________
> opensolaris-arc mailing list
> opensolaris-arc at opensolaris.org
>