Hacker News new | ask | show | jobs
by offmycloud 468 days ago
Just to be clear, it is not the Base Address Register (BAR) itself that gets resized, it is the mapped region of video memory which is pointed to by the BAR.
1 comments

I'm not sure what you're saying?

When I think of the BAR, I think of how the OS uses it. Read the address (32 or 64 bits as the case may be), write the flag so the card is not active, write all 1s to the BAR, read the address which tells you how big the mapped region is (the adress will be 0s for bits that are within the mapped region), write back the original address, and finally re-enable the card.

Resizable bar doesn't change the bar from a 32-bit bar to a 64-bit bar, it just changes the number of bits used in the mapped region.

But if the os firmware mapped the gpu somewhere where there's no room to expand the bar, the OS shouldn't expand it.

> But if the os firmware mapped the gpu somewhere where there's no room to expand the bar, the OS shouldn't expand it.

Is there some reason the kernel can't remap devices after the fact? Why is the firmware involved in this once the kernel takes over?

As I mentioned in my first reply, the firmware is expected to have complete knowledge of the address mapping of the system, and the OS isn't.

There are lots of ways for the firmware to convey information about the address map to the OS, but it may not always be complete. Mapping two devices to the same address is a recipe for trouble.

That's not to say an OS can't change these things. PCI/PCIe hotplug rely on the OS to set the BAR address for newly connected devices. And that may require rearranging existing device mappings so that things fit. And so, OSes that are capable of hotplug can often do address reallocation for all the devices, but firmware would need to have allocated the devices used to boot the OS already, and you may as well use those if they're there, right?