On Sun, Sep 15, 2013 at 03:08:38PM +0100, Peter Maydell wrote:
> On 15 September 2013 15:08, Michael S. Tsirkin <m...@redhat.com> wrote:
> > On Sun, Sep 15, 2013 at 02:49:32PM +0100, Peter Maydell wrote:
> >> Yes, but if we were applying a sensible set of priorities
> >> then you don't need to care at all about the contents
> >> of the pci hole container, because the pci hole will
> >> be at a lower priority then mcfg; so you don't get into
> >> this odd corner case of "what happens if the high
> >> priority container turns out not to have anything there".
>
> > So setting sensible priorities in this case would require figuring out
> > what happens on real hardware.
> > As long as no one investigated, I think we are better off
> > leaving this as undefined behaviour.
>
> Well, that's your choice, but I'd be really surprised if the
> PCI controller allowed PCI BARs to get mapped over the
> top of builtin devices like that.
Well it has no way not to allow this, what happens
in this configuration is another matter.
> > Again, the changes you proposed yourself to support MA status bit
> > means we will be using this weird feature on each and every
> > PCI bus :)
>
> It's still an odd corner case that only the PCI controller
> core code needs to care about
Actually you previosly wrote:
> the versatilePB's PCI controller only responds to accesses
> within its programmed MMIO BAR ranges, so if the device
> or the controller have been misconfigured you can get an
> abort when the device tries to do DMA.
Doesn't this mean versatilePB will have to have
similar code in it's PCI controller implementation -
outside PCI controller core?
Also, PCI bridge core code will care about this as well.
> (compared to the much
> larger set of container uses in random other boards and
> devices we have).
>
> -- PMM
Right. I guess that's because most boards are not
as configurable as PCI.
--
MST
