<sorear>
what's the rationale for using wrs.nto instead of wfi in an idle thread? they're both low power hints and you stop idling with an IPI, so wfi seems more appropriate
fuwei has joined #riscv
fuwei has quit [Client Quit]
usrnaem has quit [Ping timeout: 246 seconds]
usrnaem has joined #riscv
fuwei has joined #riscv
eshep has joined #riscv
eshep_ has joined #riscv
eshep has quit [Ping timeout: 260 seconds]
usrnaem2 has joined #riscv
usrnaem has quit [Ping timeout: 252 seconds]
eshep_ has quit [Ping timeout: 256 seconds]
eshep has joined #riscv
BootLayer has joined #riscv
atka has quit [Quit: WeeChat 4.3.3]
SpaceCoaster has quit [Ping timeout: 264 seconds]
SpaceCoaster has joined #riscv
eshep has quit [Ping timeout: 256 seconds]
jedix has quit [Ping timeout: 264 seconds]
eshep has joined #riscv
jedix has joined #riscv
Armand has quit [Remote host closed the connection]
Armand has joined #riscv
usrnaem has joined #riscv
eshep has quit [Ping timeout: 264 seconds]
usrnaem2 has quit [Ping timeout: 268 seconds]
eshep has joined #riscv
usrnaem2 has joined #riscv
usrnaem has quit [Ping timeout: 256 seconds]
usrnaem has joined #riscv
usrnaem2 has quit [Ping timeout: 256 seconds]
eshep has quit [Ping timeout: 256 seconds]
jacklsw has joined #riscv
eshep has joined #riscv
usrnaem2 has joined #riscv
usrnaem has quit [Ping timeout: 256 seconds]
Noisytoot has quit [Excess Flood]
Noisytoot has joined #riscv
fuwei has quit [Remote host closed the connection]
eshep has quit [Ping timeout: 255 seconds]
jedix has quit [Ping timeout: 256 seconds]
eshep has joined #riscv
jedix has joined #riscv
usrnaem has joined #riscv
usrnaem2 has quit [Ping timeout: 255 seconds]
usrnaem2 has joined #riscv
usrnaem has quit [Ping timeout: 272 seconds]
eshep_ has joined #riscv
eshep has quit [Ping timeout: 252 seconds]
usrnaem has joined #riscv
usrnaem2 has quit [Ping timeout: 272 seconds]
eshep_ has quit [Ping timeout: 246 seconds]
eshep has joined #riscv
frkzoid has quit [Ping timeout: 260 seconds]
frkazoid333 has joined #riscv
eshep has quit [Ping timeout: 268 seconds]
BootLayer has quit [Quit: Leaving]
eshep has joined #riscv
stolen has quit [Quit: Connection closed for inactivity]
<ardb>
but the point was that with ACPI, the expectation is that the firmware provides an abstraction that makes today's OS work as expected on today+2y systems
<ardb>
if RISC-V introduces Zkr2 in the mean time, the firmware will expose that via the existing protocols
<ardb>
but a kernel that has never heard of Zkr2 will never be able to make use of it
<conchuod>
ardb: Ye, I was just wanting to make sure that you had actually said it in this context and not something entirely unrelated.
<ardb>
it does require some degree of 'trust but verify' regarding the firmware implementation, of course
<sorear>
I'm skeptical of the patch on the grounds that nothing in the device tree binding requires the firmware to have set mseccfg.SSEED=1
<conchuod>
sorear: The binding does require it, no?
<sorear>
so it does
<conchuod>
At least, for riscv,isa-extensions it does. Maybe that's another reason not to allow it for riscv,isa though.
<sorear>
" today + 2y " is also embarrasingly poor ambition
<conchuod>
sorear: The alternative was waiting for FWFT to be ratified etc, and I thought that making sure that it was usable was more "helpful" information from the firmware.
<ardb>
whose ambition, and embarrassing to whom?
<sorear>
in the late 2010s the riscv principals were all claiming riscv would provide 50y software compatibility due to a lack of financial/economic risk associated with single-vendor ISAs
<sorear>
ours, me
<ardb>
right
<ardb>
well, it's two sides of the same coin
<ardb>
sw compatbility requires abstractions, and careful use of them
<conchuod>
ardb: The point you made makes sense (I didn't want blind running of the instruction in the first place, it was after discussion with palmer that I relented), what I've been wanting to find out is if it is actually possible to read the MADT from ACPI at that point in boot.
<ardb>
conchuod: it depends - edk2 based implementation will expose a ACPI SDT protocol that you can use to enumerate all ACPI tables
<ardb>
so it is easy to get to the table without having to chase all the pointers and parse unrelated tables
<ardb>
conchuod: this is for the extension string in general, right?
<conchuod>
Yea
ldevulder has joined #riscv
<ardb>
i'd expect that to be exposed by EFI in one way or another - it shouldn't depend on ACPI or DT
<ardb>
given that EFI or any app/loader/driver running in EFI context should care about either
<ardb>
ACPI/DT is how the firmware identifies the platform to the OS
<ardb>
if the firmware needs to parse that itself, it generally means you are doing something wrong
<ardb>
by extension, that means that if the EFI stub needs to reason about ACPI vs DT boot in order to determine something like the CPU capabilities, something needs fixing
<ardb>
maybe add this to the risc-v efi boot protocol that is used to discover the boot hartid?
<conchuod>
I'm not sure that I follow.. Are you saying that EFI would provide an interface to effectively get the isa string?
<ardb>
eys
<ardb>
yes
<ardb>
in your implementation, you can get it from the DT if you want (assuming a DT platform)
<ardb>
as long as the interface is ACPI/DT agnostic
<conchuod>
Some of the extensions, and not "nice to have" like the automagic kaslr-seed, will depend on being able to probe them really early as far as I understand. I've been "worrying" about how ugly that'd be in ACPI land but that seems promising...
<ardb>
just bump the version to 2 and add a method that returns the ISA string
<ardb>
if the kernel proper needs this info very early, we can pass it via a EFI config table
<sorear>
which specification for ISA string grammar? iirc there was talk about moving ACPI to a "unordered list of GUIDs" model to avoid the compatibility mess here
<conchuod>
We (read I I guess) kinda threw away the isa string for DT cos it was starting to be a bit problematic, but providing one is still supported. The new property could be trivially converted back to a more normal string if needed.
<ardb>
'list of GUIDs' sounds idiomatic for EFI
<conchuod>
That's probably why it was suggested by (IIRC) Drew.
<sorear>
should it provide boot cpu information or information about the current cpu (if anyone implements EFI_MP_SERVICES_PROTOCOL)
<ardb>
i'd expect the boot/system view to be capabilities that are supported by all CPUs
<ardb>
but you can make the protocol as fancy as you like
<conchuod>
At the moment we're defining meanings for the extensions for the new DT property and the "riscv,isa" property is effectively inheriting the defined meanings. For ACPI, the meanings are also tied to what they mean for the new DT property (which I don't think can last forever), cos the riscv part of the ACPI spec went for defining only a format for the string.
<ardb>
oh my
<conchuod>
I really don't like the ACPI situation, but everyone seems to be doing head-in-sand activities
<ardb>
ACPI requires EFI anyway, so there is no reason not to rely on it
<ardb>
iow, the ACPI spec could simply state 'at boot time, use protocol X to retrieve the ISA capabilities'
<ardb>
although deviating from the runtime view is problematic of course
eshep has quit [Ping timeout: 268 seconds]
<ardb>
but AIUI, that runtime view is problematic to begin with?
<ardb>
(the MADT property)
<xypron>
Please, stick to having only a single point of truth.
eshep has joined #riscv
<conchuod>
ardb: A format has been defined for the isa string, but meanings for what you find in it have not. That's my problem with it.
<ardb>
sorear: so which CPU does the MADT isa string describe?
<ardb>
ah never mind - it describes all CPUs
prabhakalad has joined #riscv
<sorear>
you've convinced me that the information needs to exist at the EFI layer and that it makes no sense to duplicate it in ACPI, since pure-EFI apps might use it for runtime instruction selection
<ardb>
xypron: there is no single point of truth, sadly, when the CPUs are not all identical
<xypron>
But please avoid that information being passed by a protocol. This would imply that firmware has to parse the ACPI tables which might come from a prior boot stage.
<xypron>
There should be either one device-tree entry or one ACPI table entry indicating the ISA string per hart?
<ardb>
xypron: parsing ACPI tables is what we are trying to avoid by exposing a EFI protocol
<sorear>
in the absence of MP_SERVICES there is only one hart relevant to EFI
raym has joined #riscv
<ardb>
MP_SERVICES is mostly used to discover CPU capabilities, by running CPUID instructions on other cores
<xypron>
If Linux needs an information it should parse the ACPI tables and we should not force every firmware to do Linux job.
<xypron>
E.g. U-Boot can pass through ACPI tables from QEMU. But why should U-Boot have to parse these?
<ardb>
it should not
<ardb>
who is saying it should?
<xypron>
If we have an EFI protocol to convey the ISA string, U-Boot would have to implement it?
<ardb>
yes
<xypron>
Why can't Linux' EFI stub retrieve ACPI information as early as needed?
<xypron>
Or why can't main Linux ACPI parser not run before initialising CPUs?
<ardb>
because that means the EFI stub (which is an EFI app) has to reason/predict whether the kernel proper is doing DT or ACPI boot
Andre_Z has joined #riscv
<ardb>
and today, it doesn't really care either way
<ardb>
the OS is generic, the bootloader is specific to the platform
<ardb>
so the latter should be able to inform the former about properties of the system
<ardb>
whether that involves parsing ACPI tables, calling QEMU fw_cfg or passing a compiled-in string is immaterial
<xypron>
Why do we allow both DT and ACPI at the same time. E.g. the EBBR explicitly forbids this scenario.
<ardb>
we do not
<ardb>
well
<ardb>
i try to be strict about that, but i don't know what happened in the riscv tree in the meantime
<conchuod>
I don't want that either.
<ardb>
in any case, even if DT and ACPI are not permitted at the same time, that does not mean we should add code to the EFI stub that reasons about this, and look for the MADT if the system happens to be ACPI
<xypron>
If we pass the ISA string both via ACPI and a protocol, we don't have a single point of truth for the OS and you may receive conflicting information.
<conchuod>
The people trying to add the acpi stuff via DT from ?bytedance? I think didn't get anywhere meaningful with the spec people.
<ardb>
good
<ardb>
the single point of truth for an EFI app/loader should not be buried in a ACPI table
<ardb>
or DT property
<ardb>
that implies that every EFI app would need to duplicate this logic if it needs to know the CPU capabilities
<xypron>
What EFI app are you thinking of? Where did EFI apps care about CPU capabilities on other architectures? - Every OS kernel is already is parsing DT and/or ACPI. My understanding is that simply Linux is parsing it too late.
<ardb>
anything that runs in the EFI context: - installers, factory tooling, etc etc