All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Anthony Liguori" <aliguori@us.ibm.com>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Andreas Färber" <afaerber@suse.de>,
	"Marcel Apfelbaum" <marcel.a@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC 3/3] hw/pci-host: catch acesses to unassigned pci addresses
Date: Mon, 2 Sep 2013 19:00:13 +0300	[thread overview]
Message-ID: <20130902160013.GC4691@redhat.com> (raw)
In-Reply-To: <CAFEAcA-xZqiFudd75qjdGz_RTD2jsOa-ei53BQYyXoiA_PC2RA@mail.gmail.com>

On Mon, Sep 02, 2013 at 04:53:50PM +0100, Peter Maydell wrote:
> On 2 September 2013 16:42, Marcel Apfelbaum <marcel.a@redhat.com> wrote:
> > On Mon, 2013-09-02 at 15:39 +0100, Peter Maydell wrote:
> >> This is happening at the wrong layer -- you want this memory
> >> region to be created and managed in the PCI core code so that
> >> we get correct PCI-spec behaviour for all our PCI controllers,
> >> not just the two x86 ones you've changed here.pci_address_space
> > I saw that the memory regions are part of the Host state and
> > duplicated for each host type(like pci_address_space).
> > Question, why are not pci_address_space and pci_hole present
> > in a core layer?
> >
> > I followed the existing code; from what you are saying
> > I understand that also the existing memory regions
> > like the one mentioned above should be moved in
> > the core layer, right?
> 
> Ideally, yes, I think so. However that's not particularly
> a requirement for the changes you're trying to make here:
> at the moment what happens is that the pci controller
> creates the PCI memory and io memory regions (or cheats
> by reusing the system memory space[*]), passes them to
> the PCI core code (via pci_bus_new) and then they're
> the PCI code's responsibility to manage. So in the PCI
> code you can ignore where they came from when you're
> deciding how to manage these containers (and in this case
> what you do is just create your default region and map
> it in to the container at a suitable priority).
> 
> [*] I'm pretty sure this is a bug in all platforms that do it.
> 
> -- PMM

Well as usual this cheat originated with PIIX.
AFAIK PIIX actually has a shared bus for memory and PCI
so this is not a bug there, I think.

-- 
MST

  parent reply	other threads:[~2013-09-02 15:58 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-02 14:13 [Qemu-devel] [PATCH RFC 0/3] pci: complete master abort protocol Marcel Apfelbaum
2013-09-02 14:13 ` [Qemu-devel] [PATCH RFC 1/3] memory: allow MemoryRegion's priority field to accept negative values Marcel Apfelbaum
2013-09-02 14:38   ` Peter Maydell
2013-09-02 14:46     ` Marcel Apfelbaum
2013-09-09 12:16     ` Marcel Apfelbaum
2013-09-02 14:13 ` [Qemu-devel] [PATCH RFC 2/3] hw/pci: add MemoryRegion ops for unassigned pci addresses Marcel Apfelbaum
2013-09-02 14:42   ` Peter Maydell
2013-09-02 15:46     ` Marcel Apfelbaum
2013-09-02 14:48   ` Michael S. Tsirkin
2013-09-02 14:51     ` Marcel Apfelbaum
2013-09-02 14:13 ` [Qemu-devel] [PATCH RFC 3/3] hw/pci-host: catch acesses to " Marcel Apfelbaum
2013-09-02 14:39   ` Peter Maydell
2013-09-02 15:42     ` Marcel Apfelbaum
2013-09-02 15:48       ` Andreas Färber
2013-09-02 15:53       ` Peter Maydell
2013-09-02 15:58         ` Peter Maydell
2013-09-02 16:00         ` Michael S. Tsirkin [this message]
2013-09-02 16:05           ` Peter Maydell
2013-09-02 16:17             ` Michael S. Tsirkin
2013-09-02 16:02         ` Marcel Apfelbaum
2013-09-02 15:57       ` Michael S. Tsirkin
2013-09-02 14:30 ` [Qemu-devel] [PATCH RFC 0/3] pci: complete master abort protocol Peter Maydell
2013-09-02 14:39   ` Marcel Apfelbaum
2013-09-02 14:43     ` Peter Maydell
2013-09-02 15:49       ` Marcel Apfelbaum

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=20130902160013.GC4691@redhat.com \
    --to=mst@redhat.com \
    --cc=afaerber@suse.de \
    --cc=aliguori@us.ibm.com \
    --cc=marcel.a@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.