qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PATCH v2 10/14] pci: allow 0 address for PC


From: Michael Roth
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH v2 10/14] pci: allow 0 address for PCI IO regions
Date: Tue, 10 Dec 2013 15:42:39 -0600
User-agent: alot/0.3.4

Quoting Peter Maydell (2013-12-05 17:33:48)
> On 5 December 2013 22:33, Michael Roth <address@hidden> wrote:
> > Some kernels program a 0 address for io regions. PCI 3.0 spec
> > sectio 6.2.5.1 doesn't seem to disallow this.
> 
> Hmm. The last PCI spec I looked at said 0 wasn't a valid MMIO
> address, so the variant of this patch I wrote a while back made it
> a per PCI device flag whether a particular device let you get away
> with it:
>  http://patchwork.ozlabs.org/patch/269133/
> 
> (the device in question for me was the versatile-pci host bridge).
> 
> And presumably whoever put that specific check for 0 into
> QEMU had a reason for it.
> 
> On the other hand I can't now find whatever document it was
> that I was reading that claimed 0 wasn't valid :-(

Can't seem to find anything either, checked the 2.3 spec as well. I tried to
look up the git history for the new_addr == 0 check but unfortunately it seemed
to be part of the initial check-in.

The only clue I've found regarding special-casing for a 0-bar is this:

"Power-up software can determine how much address space the device requires by
writing a value of all 1's to the register and then reading the value back. The
device will return 0's in all don't-care address bits, effectively specifying
the address space required. Unimplemented Base Address registers are hardwired
to zero." - PCI 3.0, 6.2.5.1

But that's only applicable in cases where we're sizing the bar. However, the
way things are implemented in pci_bar_address(), update hooks for
unimplemented/zero-sized bars as well as zero-address bars would be handled
by the same code, so I wonder if that was initially added to check the former?
It's a bit of a stretch, since QEMU sets the reported sizes and not the guest,
but maybe?

Does that seem familiar wrt the documentation you mentioned, or was it something
else?

> 
> thanks
> -- PMM




reply via email to

[Prev in Thread] Current Thread [Next in Thread]