From: Jeff D. <jd...@ka...> - 2002-12-30 01:59:37
|
Some problems with this one: I'm not too interested in merging suspicious-looking VM code when it's just going to get thrown out when I rewrite it. region->ioctl seems not to be initialized by anything. In any case, this is obscure enough to need documenting. I'm also not very interested in blindly copying i386 code into UML code which is supposed to be arch-independent, especially not when you haven't even looked at it to make sure it's right in UML, as this snippet demonstrates: + if (phys_addr >= 0xA0000 && last_addr < 0x100000) + return phys_to_virt(phys_addr); My recommendation would be to concentrate on making it work, not on getting it into the UML pool. It's not going in soon anyway. I've got a mile-long list of things that need doing before I start tossing in new functionality. Jeff |
From: Jeff D. <jd...@ka...> - 2002-12-30 02:57:50
|
jon...@ya... said: > 0xA0 - 0x100 should shadow the host exactly. Care to explain why? UML, as a process, should know nothing about physical addresses on the host. That memory should be mapped into the UML virtual address space (virtual as seen by the host - it may be into UML's "physical" memory area) at some arbitrary spot. Jeff |
From: Jon S. <jon...@ya...> - 2002-12-30 04:06:28
|
--- Jeff Dike <jd...@ka...> wrote: > jon...@ya... said: > > 0xA0 - 0x100 should shadow the host exactly. > > Care to explain why? UML, as a process, should know > nothing about physical > addresses on the host. That memory should be mapped > into the UML virtual > address space (virtual as seen by the host - it may > be into UML's "physical" > memory area) at some arbitrary spot. If you run X inside of UML, X is going to query the graphics hardware as to where it's ROM is located. The graphics hardware is going to respond with a physical address in the 0xA0-0x100 range in most cases. 0xA0-0x100 is the legal address space in the PC architecture for mapping boot ROMs. X is going to expect to find the ROM where the hardware says it is. This would be true even if the hardware was simulated in software. My understanding is that the kernel maintains a permanent mapping of the 0xA0-0x100 space. The test was checking for this case so it wouldn't redo the map. Since I thought UML was running the standard kernel I thought the mapping would be there too. What does UML do when the kernel tries to build this mapping? Up until now UML has been a very virtual machine with no relationship to a physical system. But when you start working on real device drivers the system has to be simulated in greater detail. For example the system BIOS rom is at 0xF0000, interrupt vectors are at 0, expansion ROMs need to appear where their hardware says they are, ioports need to work, etc... This is just part of the standard system description of an X86 PC. Compare the /proc entries of your host to the ones in UML. The UML machine has no bus, ioports, iomem, devices, interrupts, etc. There is no virtual hardware environment. All of this can be simulated, that's what vmware does. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
From: Jeff D. <jd...@ka...> - 2002-12-30 05:03:06
|
jon...@ya... said: > If you run X inside of UML, X is going to query the graphics hardware > as to where it's ROM is located. The graphics hardware is going to > respond with a physical address in the 0xA0-0x100 range in most cases. > 0xA0-0x100 is the legal address space in the PC architecture for > mapping boot ROMs. X is going to expect to find the ROM where the > hardware says it is. Hmmmm, so the kernel maps that memory into the 0xA0-0x100 range in the X server's address space? If so, there's no reason that UML can't do the same. > Up until now UML has been a very virtual machine with no relationship > to a physical system. But when you start working on real device > drivers the system has to be simulated in greater detail. For example > the system BIOS rom is at 0xF0000, interrupt vectors are at 0, > expansion ROMs need to appear where their hardware says they are, > ioports need to work, etc... Yup, it's just unclear to me at this point how much the addresses have to match what's on the host. If drivers "know" that they can find certain things at certain hard-coded addresses, then we don't have much choice. If they ask the kernel for the address first, then that gives UML the freedom to map it wherever it wants. Jeff |
From: Jon S. <jon...@ya...> - 2002-12-30 15:01:18
|
--- Jeff Dike <jd...@ka...> wrote: > Hmmmm, so the kernel maps that memory into the > 0xA0-0x100 range in the > X server's address space? If so, there's no reason > that UML can't do the > same. X was a bad example since it is a process (X uses a mmap to get to the ROM). The ROM doesn't have to be mapped to 0xA00 in kernel address space. There is just the assumption that the kernel has already mapped the ROM area to some virtual address before device drivers get loaded. Did you remove the code form the kernel that builds the mapping for 0xA0-0x100? If not, the map might be there and working. I didn't actually try to use it yet since the board I am working on doesn't depend on it. Thinking about this some more, the mapping must not be in the UML code since you would need to be root to do it. What happens when I call phys_to_virt() in UML? This must be a case where UML will fail a call that will always works in a normal X86 kernel. So I guess one solution is from me to go find where the normal kernel builds the mapping and then at the same place fix UML to build it if CONFIG_PCI is set. This has to be done such that UML's phys_to_virt() will find it. If this is done, then the code in ioremap will work right. Alternatively we could just change the rules for the UML platform and say that there is no prebuilt map for the ROM area. This is probably the better solution for UML. The prebuilt map is just an optimization, not a requirement. It was ioremap that knew about it, not the device driver. I keep assuming that UML is an X86 kernel when it really isn't. So you are right and the check for 0xA-0x10 in ioremap is a platform specific optimization and should be removed. It just took me ten minutes of thinking to figure it out. > Yup, it's just unclear to me at this point how much > the addresses have to > match what's on the host. If drivers "know" that > they can find certain > things at certain hard-coded addresses, then we > don't have much choice. If > they ask the kernel for the address first, then that > gives UML the freedom > to map it wherever it wants. The boot process has to start somewhere. At the lowest level of the PC architecture things are assigned to fixed places. Like your serial port at IO 0x3F8. Sticking the ROMs into 0xA0 - 0x100 is actually a legacy holder over from the ISA bus and the days of 640K memory. The drivers know fixed physical addresses but they ask the kernel to convert them to virtual address in kernel address space. Things will get much more interesting if I try to use the physical DMA hardware to transfer data between a UML and the physical device. To do that I need to lock a UML page into memory and get it's real physical address in the host. Anyway UML is a cool toy. I almost have my test driver working. All I need to do is find it's ROM. Using UML to work on a console device driver is a 1000 times better than two machines and a serial line. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |
From: Jon S. <jon...@ya...> - 2002-12-30 02:29:49
|
--- Jeff Dike <jd...@ka...> wrote: > region->ioctl seems not to be initialized by > anything. In any case, > this is obscure enough to need documenting. This is initialized in code I haven't sent you. None of the code I sent you references it either. > even looked at it to make sure it's right in UML, as > this snippet demonstrates: > > + if (phys_addr >= 0xA0000 && last_addr < 0x100000) > + return phys_to_virt(phys_addr); That needs to work. That is where Expansion ROMs on PCI cards live. I guess I am making too many assumptions about how UML is handling the memory space. 0xA0 - 0x100 should shadow the host exactly. ===== Jon Smirl jon...@ya... __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com |