Damien Zammit, le mar. 28 juil. 2020 20:08:37 +1000, a ecrit:
> NB: Not sure why this seems to have no effect on /dev/rumpdisk
> Am I setting the translator on the wrong port?
You are doing it too early. It's only after fsys_startup is handled that
you have access to the boostrapped FS. So we'
Damien Zammit, le mar. 28 juil. 2020 20:08:36 +1000, a ecrit:
> +++ b/libmachdev/startup.c
> --- a/libmachdev/trivfs_server.c
As mentioned previously, please keep it inside trivfs_server.c. The
bootstrap process is already hairy by happening in different
translators, let's not add complexity by ha
Applied, thanks!
Damien Zammit, le mar. 28 juil. 2020 20:08:34 +1000, a ecrit:
> ---
> libdiskfs/boot-start.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/libdiskfs/boot-start.c b/libdiskfs/boot-start.c
> index 29b8acc6..fa59e1b2 100644
> --- a/libdiskfs/boot-start.c
>
Applied, thanks!
Damien Zammit, le mar. 28 juil. 2020 20:08:35 +1000, a ecrit:
> ---
> libdiskfs/fsys-getroot.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libdiskfs/fsys-getroot.c b/libdiskfs/fsys-getroot.c
> index 735f359a..2c0d15dd 100644
> --- a/libdiskfs/fsys-
> You don't. Read about GDT and segments register, and segmentation in
> general. In the GDT you'd only store a pointer to the per-cpu data, and
> processors will load it.
> > Is there any way to avoid using an array for that?
> Yes, you'd just store the ID in the per-cpu data.
Thanks, I'll take
Almudena Garcia, le jeu. 30 juil. 2020 23:30:55 +0200, a ecrit:
> > As Richard said, we just want to have different GDTs on the different
> > processors, so that we wan use the fs segment register to implement TLS
> > in the kernel and have per-cpu data cost essentially the same as global
> > data.
> As Richard said, we just want to have different GDTs on the different
> processors, so that we wan use the fs segment register to implement TLS
> in the kernel and have per-cpu data cost essentially the same as global
> data.
Yes, but how can I store the relation APIC ID - Kernel ID in the GDT?
> Well, yes, though you probably don't want to be using a fancy hash
> table in such low-level code, so you'd either have an array of 2^16 CPU
> IDs which is a bit absurd.
The maximum number of cpus in xAPIC is 256, not 2^16. My array is indexed
by Kernel ID.
My array is refitted to the exact numbe
Samuel Thibault, le jeu. 30 juil. 2020 23:21:02 +0200, a ecrit:
> As Richard said, we just want to have different GDTs on the different
> processors, so that we wan use the fs segment register to implement TLS
> in the kernel and have per-cpu data cost essentially the same as global
> data.
(I don
As Richard said, we just want to have different GDTs on the different
processors, so that we wan use the fs segment register to implement TLS
in the kernel and have per-cpu data cost essentially the same as global
data.
Samuel
> You can build a CPU ID table on the BSP, and associate CPU IDs
> with all local APIC IDs discovered, and use that look-up table later
> to obtain a CPU ID from the local APIC ID of the CPU running the code.
It's my idea, of course. I don't know what you refer to exactly with "using
a segment reg
On 30 Jul 2020, at 22:12, Richard Braun wrote:
> On Thu, Jul 30, 2020 at 10:09:01PM +0100, Jessica Clarke wrote:
>>> It's physically memory mapped to the local APIC address space, but
>>> because of that, it's also not optimal. All systems I know use a scheme
>>> similar to TLS, i.e. using the fs
On Thu, Jul 30, 2020 at 10:09:01PM +0100, Jessica Clarke wrote:
> > It's physically memory mapped to the local APIC address space, but
> > because of that, it's also not optimal. All systems I know use a scheme
> > similar to TLS, i.e. using the fs or gs segment register, to fetch
> > a per-CPU str
On 30 Jul 2020, at 22:06, Richard Braun wrote:
> On Thu, Jul 30, 2020 at 10:44:40PM +0200, Samuel Thibault wrote:
I'm wondering: is it really *that* simple to get the current cpu number,
just read a memory location? I'm surprised that this would provide
different results on differe
Almudena Garcia, le jeu. 30 juil. 2020 22:59:02 +0200, a ecrit:
> The local APIC's registers are memory-mapped in physical page FEE00xxx (as
> seen
> in table 8-1 of Intel P4 SPG). This address is the same for each local APIC
> that exists in a configuration, meaning you are only able to directly
On Thu, Jul 30, 2020 at 10:44:40PM +0200, Samuel Thibault wrote:
> > > I'm wondering: is it really *that* simple to get the current cpu number,
> > > just read a memory location? I'm surprised that this would provide
> > > different results on different cpus.
> >
> > The APIC ID is stored in the
> That's alright while debugging. But before we commit the source code, we
> need it to be in a way which is the most readable, so people can easily
> work it out.
Ok, then I will modify my code this way.
> ? No. Introducing a variable, remembering that it holds a value, and
> eventually returning
Almudena Garcia, le mar. 28 juil. 2020 10:27:55 +0200, a ecrit:
> > Simply return rather than using a variable.
> I prefer using a temporary variable to ease debugging in case of error. Direct
> return can be difficult to debug in this case.
That's alright while debugging. But before we commit the
18 matches
Mail list logo
