On Sun, 2007-10-28 at 18:08 -0700, David Miller wrote: > From: Greg KH <[EMAIL PROTECTED]> > Date: Sun, 28 Oct 2007 13:03:36 -0700 > > > But doesn't aligning such regions on that alignment break some devices > > as that is not what the device is asking for in the BIOS? > > There are also platforms where bootup firmware chooses the > allocations, and that is what we use no matter what. This is so that > when breaking into the firmware for debugging the firmware can still > access the console device where it had mapped it in the first place. > > We really can't do things this way.
Agreed. Though he's trying to fix a real issue, his patch is not the right approach imho. A better approach would be to have a mechanism to be triggered by the hypervisor administration tools that will attempt to reassign -that- specific device if it happens to share pages with another. The remapping would thus only happen for that single device, after it's been put in control of the hypervisor (no host driver is bound, maybe just an HV specific "bridging" driver is), and only when the action of assigning it to the partition is performed, so that if the machine crashes as a result, at least you know why :-) So something like your hypervisor binds a special driver to a device that is to be reflected to a partition, at which point we are sure no other driver is using it, then that driver can call something in the pci layer that attempts to re-assign the device resources to keep it in a separate page. A patch implementing such a helper, and maybe reserving the rest of the MMIO page via some dummy resource to make sure nobody else gets in, that would make more sense. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/