On 9/11/25 1:04 PM, Alexandre Courbot wrote:
> +/// Attempt to start the GSP.
> +///
> +/// This is a GPU-dependent and complex procedure that involves loading
> firmware files from
> +/// user-space, patching them with signatures, and building
> firmware-specific intricate data
>
On 9/11/25 2:17 PM, Alexandre Courbot wrote:
> On Thu Sep 11, 2025 at 8:22 PM JST, Danilo Krummrich wrote:
>> On 9/11/25 1:04 PM, Alexandre Courbot wrote:
>>> +/// Attempt to start the GSP.
>>> +///
>>> +/// This is a GPU-dependent and complex procedure that involves
>>> loading firmwa
On Thu Sep 11, 2025 at 9:46 PM JST, Danilo Krummrich wrote:
> On 9/11/25 2:17 PM, Alexandre Courbot wrote:
>> On Thu Sep 11, 2025 at 8:22 PM JST, Danilo Krummrich wrote:
>>> On 9/11/25 1:04 PM, Alexandre Courbot wrote:
+/// Attempt to start the GSP.
+///
+/// This is a GP
On Sun Sep 14, 2025 at 1:02 AM CEST, Joel Fernandes wrote:
> On Sat, Sep 13, 2025 at 09:53:16PM +0200, Danilo Krummrich wrote:
>> On Sat Sep 13, 2025 at 7:13 PM CEST, Joel Fernandes wrote:
>> > On Sat, Sep 13, 2025 at 03:30:31PM +0200, Danilo Krummrich wrote:
>> >> However, we should never do such
On Mon Sep 15, 2025 at 6:59 AM CEST, Alexandre Courbot wrote:
> On Sun Sep 14, 2025 at 11:42 PM JST, Benno Lossin wrote:
>> On Sun Sep 14, 2025 at 3:49 AM CEST, Alexandre Courbot wrote:
>>> On Sun Sep 14, 2025 at 7:06 AM JST, Joel Fernandes wrote:
On Sat, Sep 13, 2025 at 02:29:54PM -0700, John
On Sun Sep 14, 2025 at 11:42 PM JST, Benno Lossin wrote:
> On Sun Sep 14, 2025 at 3:49 AM CEST, Alexandre Courbot wrote:
>> On Sun Sep 14, 2025 at 7:06 AM JST, Joel Fernandes wrote:
>>> On Sat, Sep 13, 2025 at 02:29:54PM -0700, John Hubbard wrote:
Yes. It's only "paranoia" if the code is bug-f
On Sun Sep 14, 2025 at 3:49 AM CEST, Alexandre Courbot wrote:
> On Sun Sep 14, 2025 at 7:06 AM JST, Joel Fernandes wrote:
>> On Sat, Sep 13, 2025 at 02:29:54PM -0700, John Hubbard wrote:
>>> Yes. It's only "paranoia" if the code is bug-free. So Rust itself
>>> naturally will look "a little" paranoi
On Sun Sep 14, 2025 at 7:06 AM JST, Joel Fernandes wrote:
> On Sat, Sep 13, 2025 at 02:29:54PM -0700, John Hubbard wrote:
> [..]
>
>> >
>> > I would suggest taking a look at our website and the links there (like
>> > issue #2) -- what we are doing upstream Rust is documented.
>>
>> ...and my ques
Hi Danilo,
On Sat, Sep 13, 2025 at 09:53:16PM +0200, Danilo Krummrich wrote:
> On Sat Sep 13, 2025 at 7:13 PM CEST, Joel Fernandes wrote:
> > On Sat, Sep 13, 2025 at 03:30:31PM +0200, Danilo Krummrich wrote:
> >> On Sat Sep 13, 2025 at 3:02 AM CEST, Joel Fernandes wrote:
> >> > Any chance we can i
On Sat, Sep 13, 2025 at 02:29:54PM -0700, John Hubbard wrote:
[..]
> >
> > I would suggest taking a look at our website and the links there (like
> > issue #2) -- what we are doing upstream Rust is documented.
>
> ...and my question was asked before reading through issue #2. So your
> and Danilo
On 9/13/25 1:37 PM, Miguel Ojeda wrote:
On Sat, Sep 13, 2025 at 7:14 PM Joel Fernandes wrote:
I am not alone in that opinion.
Hmm... I am not sure how to read this.
This should be first-class in a (systems) language, built into
the language itself?
On this particular point, and *only* th
Hi Miguel,
On Sat, Sep 13, 2025 at 10:37:34PM +0200, Miguel Ojeda wrote:
> On Sat, Sep 13, 2025 at 7:14 PM Joel Fernandes wrote:
> >
> > I am not alone in that opinion.
>
> Hmm... I am not sure how to read this.
I don't follow? I am just saying that pinning seems to be a rather odd thing
to do
On Sat, Sep 13, 2025 at 7:14 PM Joel Fernandes wrote:
>
> I am not alone in that opinion.
Hmm... I am not sure how to read this.
> This should be first-class in a (systems) language, built into
> the language itself?
I would suggest taking a look at our website and the links there (like
issue #
On Sat Sep 13, 2025 at 7:13 PM CEST, Joel Fernandes wrote:
> On Sat, Sep 13, 2025 at 03:30:31PM +0200, Danilo Krummrich wrote:
>> On Sat Sep 13, 2025 at 3:02 AM CEST, Joel Fernandes wrote:
>> > Any chance we can initialize the locks later? We don't need locking until
>> > after the boot process is
On Sat, Sep 13, 2025 at 03:30:31PM +0200, Danilo Krummrich wrote:
> On Sat Sep 13, 2025 at 3:02 AM CEST, Joel Fernandes wrote:
> > Any chance we can initialize the locks later? We don't need locking until
> > after the boot process is completed, and if there's a way we can dynamically
> > "pin", wh
On Sat Sep 13, 2025 at 3:02 AM CEST, Joel Fernandes wrote:
> Any chance we can initialize the locks later? We don't need locking until
> after the boot process is completed, and if there's a way we can dynamically
> "pin", where we hypothetically pin after the boot process completed, that
> might a
On Thu, Sep 11, 2025 at 10:26:08PM +0900, Alexandre Courbot wrote:
> On Thu Sep 11, 2025 at 9:46 PM JST, Danilo Krummrich wrote:
[..]
> >> By keeping the initialization in the GPU, we can keep the GSP object
> >> architecture-independent, and I think it makes sense from a design point
> >> of view
On Thu Sep 11, 2025 at 3:26 PM CEST, Alexandre Courbot wrote:
> On Thu Sep 11, 2025 at 9:46 PM JST, Danilo Krummrich wrote:
>> On 9/11/25 2:17 PM, Alexandre Courbot wrote:
>>> You can see the whole process on [1]. `libos` is the object that is
>>> returned (although its name and type will change).
On Thu Sep 11, 2025 at 8:22 PM JST, Danilo Krummrich wrote:
> On 9/11/25 1:04 PM, Alexandre Courbot wrote:
>> +/// Attempt to start the GSP.
>> +///
>> +/// This is a GPU-dependent and complex procedure that involves loading
>> firmware files from
>> +/// user-space, patching them
Right now the GSP boot code is very incomplete and limited to running
FRTS, so having it in `Gpu::new` is not a big constraint.
However, this will change as we add more steps of the GSP boot process,
and not all GPU families follow the same procedure, so having these
steps in a dedicated method is
20 matches
Mail list logo