All of lore.kernel.org
 help / color / mirror / Atom feed
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

      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.