Re: [Qemu-devel] [PATCH RFC v2 2/2] hw/pci: handle unassigned pci addresses

[Michael S. Tsirkin]

On Sun, Sep 15, 2013 at 03:08:38PM +0100, Peter Maydell wrote:
> On 15 September 2013 15:08, Michael S. Tsirkin <address@hidden> 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