[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1194988653.28605.4.camel@pasglop>
Date: Wed, 14 Nov 2007 08:17:33 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: David Miller <davem@...emloft.net>
Cc: gregkh@...e.de, barak@...cleus.com, linux-kernel@...r.kernel.org,
linux-pci@...ey.karlin.mff.cuni.cz, guy@...cleus.com
Subject: Re: [PATCH] Align PCI memory regions to page size (4K) - Fix
On Sun, 2007-10-28 at 18:08 -0700, David Miller wrote:
> From: Greg KH <gregkh@...e.de>
> 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 majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists