OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 6:18 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 8 posts ] 
Author Message
 Post subject: Who determines memory mapped IO addresses?
PostPosted: Mon Aug 19, 2019 6:50 pm 
Offline
Member
Member

Joined: Tue Apr 24, 2018 9:46 pm
Posts: 74
I am currently looking through the xv6 source code. They dedicate addresses 0xFE00_0000 to 0xFFFF_FFFF for memory mapped IO.
At first I thought the address 0xFE00_0000 was something agreed upon by the x86 architecture (Intel, AMD etc came together and chose it), however a Google search reveals there is nothing special about that particular address...

Who determines the range for memory mapped IO (and the size of the range)? How does a device driver writer know which address is free for them to use? Do different operating systems use some agreed upon range, or does each make up its own?

Attachment:
v2p.PNG
v2p.PNG [ 31.37 KiB | Viewed 2976 times ]


Top
 Profile  
 
 Post subject: Re: Who determines memory mapped IO addresses?
PostPosted: Tue Aug 20, 2019 1:10 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
There's a very comprehensive discussion of this here: https://resources.infosecinstitute.com/ ... d-systems/


Top
 Profile  
 
 Post subject: Re: Who determines memory mapped IO addresses?
PostPosted: Tue Aug 20, 2019 1:35 am 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 5099
quadrant wrote:
Who determines the range for memory mapped IO (and the size of the range)?

According to the picture you posted, you're asking about virtual addresses. The virtual address map is decided entirely by the OS.

quadrant wrote:
How does a device driver writer know which address is free for them to use?

It asks the OS.

quadrant wrote:
Do different operating systems use some agreed upon range, or does each make up its own?

Each OS does it differently. They don't have to use a single fixed address range.


Top
 Profile  
 
 Post subject: Re: Who determines memory mapped IO addresses?
PostPosted: Tue Aug 20, 2019 2:49 am 
Offline
Member
Member
User avatar

Joined: Sat Mar 31, 2012 3:07 am
Posts: 4591
Location: Chichester, UK
Behind the virtual address is a physical address. This is what the OP is asking about. Basically, the range is hard wired into the hardware.


Top
 Profile  
 
 Post subject: Re: Who determines memory mapped IO addresses?
PostPosted: Tue Aug 20, 2019 2:40 pm 
Offline
Member
Member

Joined: Tue Apr 24, 2018 9:46 pm
Posts: 74
Thank you for the responses!
Insight to both the virtual and physical side of things is desired :)

@Octocontrabass: Ah I see. Could you elaborate more on how a device driver would ask the OS for a virtual address it can use? Is there some type of standard protocol (to make the writing of device drivers easier), or does the person writing the driver need to tailor the ask to each OS? Also how does the OS know which address is associated with which physical device?

@iansjack: Thank you for the link. I will give it a read. I'm trying to wrap my head around the physical side of things. Whether it's the motherboard that determines the addresses... i.e. does the way the motherboard designer choose to wire peripherals to the CPU determine the physical addresses? Or do Intel and other CPU makers say that at physical address x, I expect device y to be connected.


Top
 Profile  
 
 Post subject: Re: Who determines memory mapped IO addresses?
PostPosted: Tue Aug 20, 2019 3:49 pm 
Offline
Member
Member

Joined: Wed Mar 09, 2011 3:55 am
Posts: 509
iansjack wrote:
Behind the virtual address is a physical address. This is what the OP is asking about. Basically, the range is hard wired into the hardware.


No, he's asking about the choice of address 0xFE000000 for MMIO devices. From the image he linked, this is the virtual address where the developers of the xv6 kernel have chosen to map the physical MMIO region.

@quadrant:

Note: I began writing this before you posted your last post, which seems to indicate a bit more understanding about the difference between physical and virtual memory than I had initially assumed. I'm posting it as is so that I don't have to rewrite the whole thing, and in the hope that it may be useful to others in the future.

Modern CPUs generally have a feature called paging. This divides the physical address space into small chunks (4kB on x86) called pages, and, when a program references a given address, the CPU consults a lookup table that tells the CPU which page of physical memory it should access. This allows the operating system to cause a given page of physical memory to be accessible at an address of its choosing. The address that a program uses is called a virtual address, because it's not the address that's directly used to access physical memory, the CPU has to check the lookup table first. The address the CPU gets from the lookup table is called the physical address, and is the address that the CPU actually places on the bus to get the attention of the appropriate RAM module or memory-mapped I/O device. The reason paging is useful is that it allows the OS to present a program with the illusion that it has the entire computer to itself: when a given program is running, all that program can see on the system, without asking the OS, is itself. The physical memory pages for other programs aren't mapped into the address space assigned to the currently running program (at least, not with permissions that anything but the OS can access), so a bug in one program can't cause another to crash. The OS generally maps itself, and the resources it needs, into the upper part of each program's address space, but with permissions set so that the program can't read from or write to that area, or interact with the OS in any way other than calling the system calls that the OS exposes to programs (sometimes OSes will expose a small area that programs can read, but not write, with useful, non-sensitive data like the system time in it, so that programs can access that data without needing to make a system call).

The *physical* address that I/O devices appear at is generally determined by the computer manufacturer, not the CPU manufacturer (although before personal computers took off, when computers were desk- or room-sized affairs with price tags that only businesses could afford, these were often the same company). For markets like the modern PC market, where a bunch of different manufacturers are building a bunch of different models that are all compatible with each other, what the manufacturer can choose to do is constrained by industry standards, whether formal (i.e, a written document), or informal (i.e, everybody's already doing A, so we have to do A too, if we do B we won't be compatible). So it's not AMD and Intel, primarily, that determine the MMIO layout on PCs, its Dell, HP, Acer, etc. And, because it was the IBM PC that started the whole PC-compatible market, the decisions that IBM made when they were still making PC-architecture systems had a huge impact on the layout of later PCs from other manufacturers.

The address of 0xfe000000 that you're asking about, though, is not a physical address, it's a virtual address. xv6 sets it up as one of the reserved addresses for the OS that programs can't access, and has reserved that area to map the physical memory for MMIO devices, so that the OS and drivers can interact with the devices.

quadrant wrote:
How does a device driver writer know which address is free for them to use?


This depends on the OS, and the nature of the device and the platform. For OSes designed for platforms where the available virtual address space vastly exceeds the amount of physical address space the motherboard can provide (typical these days on 64-bit systems, typical 30 years ago on 32-bit systems), and where devices have hard-coded physical MMIO addresses (I'm not sure how many such platforms exist anymore), The OS might just map the whole physical address space into its reserved area of the virtual address space at an ABI-specified offset, and then the driver will know, from the ABI of the OS and the hard-coded physical address of its own device, what address to use. This has the potential disadvantage, however, that as a platform develops over the years and more physical address space becomes available, there might not be enough space is the OS's reserved region to map all of physical memory. If an OS does not map all of physical memory at once, it might only map one MMIO device at a time at a pre-set address, in which case a driver would know directly from the ABI what address to use. Alternatively, if the OS maps all of physical memory, but the platform allows the OS to assign devices to respond to a given physical address, the driver may have to ask the OS where the device is before it can access it. If the space that the operating system has reserved for MMIO is especially small, and you have a device like a video card that may present a physical region of several gigabytes for MMIO, the OS may not be able to map the whole device at once: The driver may be able to access the device at a fixed address, but it may have to periodically ask the operating system to map a different part of that device's physical MMIO region to the virtual address for MMIO. And this does not exhaust the set of possibilities.


Top
 Profile  
 
 Post subject: Re: Who determines memory mapped IO addresses?
PostPosted: Tue Aug 20, 2019 5:32 pm 
Offline
Member
Member

Joined: Tue Apr 24, 2018 9:46 pm
Posts: 74
@linguofreak: Thank you for the detailed response!

Quote:
where devices have hard-coded physical MMIO addresses (I'm not sure how many such platforms exist anymore)

Does this mean that for most devices, you get a chance to choose the physical address associated with it through software commands at startup?

Quote:
ABI-specified offset

What is meant by ABI here? Is it a reference to System V ABI, specifically the ELF file format?


Top
 Profile  
 
 Post subject: Re: Who determines memory mapped IO addresses?
PostPosted: Fri Aug 23, 2019 5:36 am 
Offline
Member
Member

Joined: Wed Mar 09, 2011 3:55 am
Posts: 509
quadrant wrote:
@linguofreak: Thank you for the detailed response!

Quote:
where devices have hard-coded physical MMIO addresses (I'm not sure how many such platforms exist anymore)

Does this mean that for most devices, you get a chance to choose the physical address associated with it through software commands at startup?

It's entirely platform dependent, but on many platforms, yes.

Quote:
ABI-specified offset

What is meant by ABI here? Is it a reference to System V ABI, specifically the ELF file format?


ABI means "Application Binary Interface". It basically specifies how a software component (for example, your kernel) expects other software to communicate with it at the machine-code level. The System V ABI is an example of an ABI (or rather, a set of ABIs, one for each of a large number of architectures). On a typical OS, the kernel will typically expose an external ABI to userspace programs, and an internal ABI to drivers and other kernel components. Then, in userspace, the runtime library for a given language will generally have an ABI that it expects programs written in that language to use.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 8 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot] and 72 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group