From: Grant Grundler <grundler@parisc-linux.org>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: David Miller <davem@davemloft.net>,
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: Tue, 13 Nov 2007 23:21:57 -0700 [thread overview]
Message-ID: <20071114062157.GA30203@colo.lackof.org> (raw)
In-Reply-To: <1194988653.28605.4.camel@pasglop>
On Wed, Nov 14, 2007 at 08:17:33AM +1100, Benjamin Herrenschmidt wrote:
...
> 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.
We already have that "something": pci_enable_device().
The guest OS "Arch" code can then do the reassignment.
See "3.1 Enable the PCI device" in Documentation/pci.txt.
> 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.
The Hypervisor could be responsible for making the right devices
visible to the appropriate partitions/guests by intercepting the
PCI bus walk and/or hotplug support. I don't think you
should need any dummy resource/drivers in the guest OS.
hth,
grant
next prev parent reply other threads:[~2007-11-14 6:22 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
2007-11-14 6:21 ` Grant Grundler [this message]
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=20071114062157.GA30203@colo.lackof.org \
--to=grundler@parisc-linux.org \
--cc=barak@neocleus.com \
--cc=benh@kernel.crashing.org \
--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