On Wed, Jan 25, 2023 at 1:34 AM Jessica Clarke <jrt...@jrtc27.com> wrote:
> On 25 Jan 2023, at 06:27, Flávio Cruz <flavioc...@gmail.com> wrote: > >> On Tue, Jan 24, 2023 at 2:54 AM Samuel Thibault < > samuel.thiba...@gnu.org> wrote: > >> Flávio Cruz, le mar. 24 janv. 2023 01:15:15 -0500, a ecrit: > >> > + int kernel_id; > >> > + unsigned long flags; > >> > + > >> > + cpu_intr_save(&flags); > >> > + > >> > + kernel_id = > apic_get_cpu_kernel_id(apic_get_current_cpu()); > >> > + > >> > + cpu_intr_restore(flags); > >> > + > >> > + return kernel_id; > >> > > >> > > >> > Might be unrelated to this change, but will this be portable for > x86_64? It > >> > seems we either should use uint32_t to store EFLAGS or use > pushfq/popfq to get > >> > RFLAGS instead. > >> > >> cpu_get_eflags will already use pushfq/popfq, won't it? (since it takes > >> the unsigned long output parameter. > > > > I tried it in compiler explorer and it shows we have to use pushfq > explicitly: https://godbolt.org/z/MYjPaEh31 > > Not sure what you’re trying to show? pushf assembles to the same thing as > pushfq. > I think you are right - just looked at the objdump output. Sorry for the noise > Jess > > >> Samuel > >
