From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Zachary Amsden <zach@vmware.com>
Cc: Chris Wright <chrisw@sous-sol.org>,
Virtualization Mailing List <virtualization@lists.osdl.org>
Subject: Re: Handling PCI/ROM space
Date: Wed, 18 Oct 2006 15:24:38 -0700 [thread overview]
Message-ID: <4536A9A6.8040604@goop.org> (raw)
In-Reply-To: <4536A734.7030904@vmware.com>
Zachary Amsden wrote:
> Probably a config file difference - GOBIOS vs GODIRECT.
>
> These patches look fine, although is there a more general solution?
> Like bypassing the whole PCI ROM probing entirely? We don't really
> want to use the PCI ROM here either, although we have a slightly worse
> problem - the pages are mapped and do have a PCI ROM. Perhaps
> paravirt-ops should be able to flip a global switch to disable this
> (perhaps already there?).
There's a pci_probe variable, which has a bitmask of which PCI access
methods to use; if you mask out PCI_PROBE_BIOS then it won't bother. I
considered doing this, but it wasn't clear to me where this actually get
set up (it's a bit diffuse), and whether to add a new pv_op hook
intercept this.
I also thought that we don't necessarily want to unconditionally disable
PCI access for paravirt guests since even an unprivileged guest may have
a raw device exported to it, and we don't want to add too many special
cases when dom0 is migrated to operate in the pv_op world. So it seemed
more correct to actually allow the probe but deal with unmapped pci ROM
space.
J
prev parent reply other threads:[~2006-10-18 22:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-18 21:42 Handling PCI/ROM space Jeremy Fitzhardinge
2006-10-18 22:14 ` Zachary Amsden
2006-10-18 22:24 ` Jeremy Fitzhardinge [this message]
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=4536A9A6.8040604@goop.org \
--to=jeremy@goop.org \
--cc=chrisw@sous-sol.org \
--cc=virtualization@lists.osdl.org \
--cc=zach@vmware.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.