From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: David Miller <davem@davemloft.net>
Cc: gregkh@suse.de, barak@neocleus.com, linux-kernel@vger.kernel.org,
linux-pci@atrey.karlin.mff.cuni.cz, guy@neocleus.com
Subject: Re: [PATCH] Align PCI memory regions to page size (4K) - Fix
Date: Wed, 14 Nov 2007 08:17:33 +1100 [thread overview]
Message-ID: <1194988653.28605.4.camel@pasglop> (raw)
In-Reply-To: <20071028.180807.165828961.davem@davemloft.net>
On Sun, 2007-10-28 at 18:08 -0700, David Miller wrote:
> From: Greg KH <gregkh@suse.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.
next prev parent reply other threads:[~2007-11-13 21:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-28 17:27 [PATCH] Align PCI memory regions to page size (4K) - Fix Barak Fargoun
2007-10-28 19:31 ` Greg KH
2007-10-28 19:53 ` Barak Fargoun
2007-10-28 20:03 ` Greg KH
2007-10-28 20:44 ` Barak Fargoun
2007-10-29 1:08 ` David Miller
2007-11-13 21:17 ` Benjamin Herrenschmidt [this message]
2007-11-14 6:21 ` Grant Grundler
2007-11-14 8:16 ` Benjamin Herrenschmidt
2007-11-14 21:55 ` Grant Grundler
2007-11-14 22:16 ` Benjamin Herrenschmidt
2007-10-29 5:52 ` Grant Grundler
2007-11-08 23:24 ` Linas Vepstas
2007-11-12 23:43 ` Grant Grundler
2007-10-28 19:48 ` Arjan van de Ven
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1194988653.28605.4.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=barak@neocleus.com \
--cc=davem@davemloft.net \
--cc=gregkh@suse.de \
--cc=guy@neocleus.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox