5 ms·

That's only true up to a certain point. ARM is a very weird target, because a lot of standardized stuff we take for granted in x86/PC land aren't standardized o

That's only true up to a certain point. ARM is a very weird target, because a lot of standardized stuff we take for granted in x86/PC land aren't standardized on ARM. In particular, take the Interrupt Controller: x86 has a standard for it (well, technically has two, the PIC and APIC). The "standard" in ARM-land is the GICv3 or GICv4, but many different CPU vendors have their own. Apple has the "Apple Interrupt Controller", or AIC. The thing is, AFAIK, how to talk to the interrupt controller isn't part of the drivers, but part of the kernel. So you can't just "write a driver" for it. So if Windows doesn't support apple's interrupt controllers, I guess a lot of shenanigans will be needed.

mlyle 4y ago
> The thing is, AFAIK, how to talk to the interrupt controller isn't part of the drivers, but part of the kernel. So you can't just "write a driver" for it. So if Windows doesn't support apple's interrupt controllers, I guess a lot of shenanigans will be needed. He's planning on a thin hypervisor layer to map GIC to AIC.
AshamedCaptain 4y ago
Actually you might be surprised. Windows NT is _older_ than many of the "standards we take for granted in x86/PC land", and for example it does support multiple types of pre-ACPI ways of bringing up multiprocessor systems and specifically multiple types of interrupt controllers. Heck, x86 Windows even supports non-PC servers from Compaq and others; ever tried to press F5 during (old) Windows NT setup ? As the OP said, all of this is abstracted by the Windows HAL, so it's just a matter of replacing the HAL (a separate binary). The problem is that the HAL is closed source. Outside of simple binary patches, I don't think anyone has come close to writing a new one.
- monocasa 4y ago
  ReactOS has written their own HALs.
- amarioguy 4y ago
  Generally speaking part of the issue with a custom HAL nowadays is that Microsoft moved the HAL from being a DLL to being a statically linked library within the kernel (likely as a performance optimization and because there's no real need for a new HAL in most instances when HAL Extensions exist) This merger of the kernel and HAL invariably means patching the HAL is now equivalent to patching the kernel
- xattt 4y ago
  > x86 Windows even supports non-PC servers from Compaq Were there x86 but non-IBM compatible models or did you mean the alternate instruction sets (Alpha, PPC, RISC)?
  - zinekeller 4y ago
    Not GP. I'm not sure if there's a special Compaq version but there's a version (until Windows 2000, https://winworldpc.com/download/5204c39d-c3a9-5a68-11c3-a7c29d255254 https://winworldpc.com/download/5204c39d-c3a9-5a68-11c3-a7c2...) for NEC PC-98 architecture which is x86-based but IBM PC-incompatible, so it's likely that a Compaq version exists.
    - yuhong 4y ago
      The Compaq is IBM PC compatible but uses a different HAL for SMP support. You can see all of them by looking at what NT4 shipped with for example.
      - zinekeller 4y ago
        Ah, Uniprocessor versus Multiprocessor HALs, I remember now!
  - deleted 4y ago
    [deleted]
- DeathArrow 4y ago
  >Outside of simple binary patches, I don't think anyone has come close to writing a new one. What about ReactOS, do they use a HAL implementation or not?
emptysongglass 4y ago
This part is why I hope x86 has a long life ahead of it. Everybody and their dog have their own standard for things in ARM-land.
- jhgb 4y ago
  One can hope that RISC-V in the future will not follow ARM's past mistakes.
  - als0 4y ago
    The mistakes are already happening. There are RISC-V processors being shipped with unfinished extensions and weird MMUs and now Linux has to decide whether to support those or only support finished standards
- amarioguy 4y ago
  for what it's worth amd64 is not going anywhere outside of Macs for at least the next decade, possibly two. Despite the benefits ARM provides amd64 undeniably has advantages and non-trivial ones at that. personally, I'm of the opinion it'll come to a coexistence for a time rather than one dominating the other immediately.
  - avianes 4y ago
    Are you confusing "amd64" with "Aarch64"? "amd64" has nothing to do with Macs/Apple products. Anyway, both amd64 and Aarch64 are already being used outside of Macs/Apple products.
    - 14u2c 4y ago
      Apple still sells many computers that execute the amd64 insurrection set.
- avianes 4y ago
  This is not true. Most manufacturers take standardized IP and IP-providers provide an appropriate linux drivers. Few manufacturers are willing to develop and maintain their own GIC hardware and GIC driver, most of the time they just take the ARM standard GIC. The fact that Apple does not provide drivers is a consequence of the Apple business model. And the fact that the ARM ISA does not stipulate a unique GIC is actually a strength. It makes the architecture more versatile and suitable for evolution (maybe Apple found out that the ARM standard GIC is not complete enough for them).
conradev 4y ago
The author plans on using this feature to help bridge the interrupt controller: “There’s an somewhat obscure feature on M1 (and M1 Pro/Max/Ultra, henceforth referred to as M1 v2) chips where part of the GICv3 can be virtualized to guest OSes to enable faster interrupt handling.” Seemingly implementing it in a hypervisor?

mlyle 4y ago

> The thing is, AFAIK, how to talk to the interrupt controller isn't part of the drivers, but part of the kernel. So you can't just "write a driver" for it. So if Windows doesn't support apple's interrupt controllers, I guess a lot of shenanigans will be needed. He's planning on a thin hypervisor layer to map GIC to AIC.

AshamedCaptain 4y ago

Actually you might be surprised. Windows NT is _older_ than many of the "standards we take for granted in x86/PC land", and for example it does support multiple types of pre-ACPI ways of bringing up multiprocessor systems and specifically multiple types of interrupt controllers. Heck, x86 Windows even supports non-PC servers from Compaq and others; ever tried to press F5 during (old) Windows NT setup ? As the OP said, all of this is abstracted by the Windows HAL, so it's just a matter of replacing the HAL (a separate binary). The problem is that the HAL is closed source. Outside of simple binary patches, I don't think anyone has come close to writing a new one.

monocasa 4y ago
ReactOS has written their own HALs.
amarioguy 4y ago
Generally speaking part of the issue with a custom HAL nowadays is that Microsoft moved the HAL from being a DLL to being a statically linked library within the kernel (likely as a performance optimization and because there's no real need for a new HAL in most instances when HAL Extensions exist) This merger of the kernel and HAL invariably means patching the HAL is now equivalent to patching the kernel
xattt 4y ago
> x86 Windows even supports non-PC servers from Compaq Were there x86 but non-IBM compatible models or did you mean the alternate instruction sets (Alpha, PPC, RISC)?
- zinekeller 4y ago
  Not GP. I'm not sure if there's a special Compaq version but there's a version (until Windows 2000, https://winworldpc.com/download/5204c39d-c3a9-5a68-11c3-a7c29d255254 https://winworldpc.com/download/5204c39d-c3a9-5a68-11c3-a7c2...) for NEC PC-98 architecture which is x86-based but IBM PC-incompatible, so it's likely that a Compaq version exists.
  - yuhong 4y ago
    The Compaq is IBM PC compatible but uses a different HAL for SMP support. You can see all of them by looking at what NT4 shipped with for example.
    - zinekeller 4y ago
      Ah, Uniprocessor versus Multiprocessor HALs, I remember now!
- deleted 4y ago
  [deleted]
DeathArrow 4y ago
>Outside of simple binary patches, I don't think anyone has come close to writing a new one. What about ReactOS, do they use a HAL implementation or not?

emptysongglass 4y ago

This part is why I hope x86 has a long life ahead of it. Everybody and their dog have their own standard for things in ARM-land.

jhgb 4y ago
One can hope that RISC-V in the future will not follow ARM's past mistakes.
- als0 4y ago
  The mistakes are already happening. There are RISC-V processors being shipped with unfinished extensions and weird MMUs and now Linux has to decide whether to support those or only support finished standards
amarioguy 4y ago
for what it's worth amd64 is not going anywhere outside of Macs for at least the next decade, possibly two. Despite the benefits ARM provides amd64 undeniably has advantages and non-trivial ones at that. personally, I'm of the opinion it'll come to a coexistence for a time rather than one dominating the other immediately.
- avianes 4y ago
  Are you confusing "amd64" with "Aarch64"? "amd64" has nothing to do with Macs/Apple products. Anyway, both amd64 and Aarch64 are already being used outside of Macs/Apple products.
  - 14u2c 4y ago
    Apple still sells many computers that execute the amd64 insurrection set.
avianes 4y ago
This is not true. Most manufacturers take standardized IP and IP-providers provide an appropriate linux drivers. Few manufacturers are willing to develop and maintain their own GIC hardware and GIC driver, most of the time they just take the ARM standard GIC. The fact that Apple does not provide drivers is a consequence of the Apple business model. And the fact that the ARM ISA does not stipulate a unique GIC is actually a strength. It makes the architecture more versatile and suitable for evolution (maybe Apple found out that the ARM standard GIC is not complete enough for them).

conradev 4y ago

The author plans on using this feature to help bridge the interrupt controller: “There’s an somewhat obscure feature on M1 (and M1 Pro/Max/Ultra, henceforth referred to as M1 v2) chips where part of the GICv3 can be virtualized to guest OSes to enable faster interrupt handling.” Seemingly implementing it in a hypervisor?