All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	David Gibson <david@gibson.dropbear.id.au>
Cc: QEMU Devel Mailing List <qemu-devel@nongnu.org>,
	Marcel Apfelbaum <marcel@redhat.com>
Subject: Re: [Qemu-devel] A question about PCI device address spaces
Date: Mon, 26 Dec 2016 14:53:16 +0800	[thread overview]
Message-ID: <20161226065316.GB4295@pxdev.xzpeter.org> (raw)
In-Reply-To: <CAFEAcA-6CtHq7w-i=_X9zbBsKeKD1sLsWGze4hgw14er_sd9Vw@mail.gmail.com>

On Fri, Dec 23, 2016 at 11:21:53AM +0000, Peter Maydell wrote:
> On 22 December 2016 at 09:42, Peter Xu <peterx@redhat.com> wrote:
> > Hello,
> >
> > Since this is a general topic, I picked it out from the VT-d
> > discussion and put it here, just want to be more clear of it.
> >
> > The issue is, whether we have exposed too much address spaces for
> > emulated PCI devices?
> >
> > Now for each PCI device, we are having PCIDevice::bus_master_as for
> > the device visible address space, which derived from
> > pci_device_iommu_address_space():
> >
> > AddressSpace *pci_device_iommu_address_space(PCIDevice *dev)
> > {
> >     PCIBus *bus = PCI_BUS(dev->bus);
> >     PCIBus *iommu_bus = bus;
> >
> >     while(iommu_bus && !iommu_bus->iommu_fn && iommu_bus->parent_dev) {
> >         iommu_bus = PCI_BUS(iommu_bus->parent_dev->bus);
> >     }
> >     if (iommu_bus && iommu_bus->iommu_fn) {
> >         return iommu_bus->iommu_fn(bus, iommu_bus->iommu_opaque, dev->devfn);
> >     }
> >     return &address_space_memory;
> > }
> >
> > By default (for no-iommu case), it's pointed to system memory space,
> > which includes MMIO, and looks wrong - PCI device should not be able to
> > write to MMIO regions.
> 
> This is just legacy, I think, ie a combination of "this used to
> be system memory space so let's not break things" and "PC works
> mostly like this". It should be possible for the PCI host bridge
> emulation to set things up so that the device's visible address
> space is whatever it feels like. The PCI APIs we have for doing
> this have "iommu" in the name but they work just as well even
> if the host bridge doesn't actually have an iommu and is just
> setting up a fixed or slightly configurable mapping.
> I think it just hasn't been implemented because for guests which
> aren't misbehaving it doesn't make any difference.

Hmm, yes I see ppc e500 is using that for setting up its own address
space, possibly x86 can leverage it too when we really need this. For
now, I see no strong reason for this enhancement, so let me keep it as
it is, and wait until we have both a strong reason and a PCI guru.

Thank you for your answer! (to Paolo/David as well)

-- peterx

  reply	other threads:[~2016-12-26  6:53 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-22  9:42 [Qemu-devel] A question about PCI device address spaces Peter Xu
2016-12-22 10:24 ` Paolo Bonzini
2016-12-23  0:02 ` David Gibson
2016-12-23 11:21 ` Peter Maydell
2016-12-26  6:53   ` Peter Xu [this message]
2016-12-26 11:01 ` Marcel Apfelbaum
2016-12-26 11:40   ` David Gibson

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=20161226065316.GB4295@pxdev.xzpeter.org \
    --to=peterx@redhat.com \
    --cc=david@gibson.dropbear.id.au \
    --cc=marcel@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /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.