[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 10/14] pci: allow 0 address for PCI IO region
From: |
Michael Roth |
Subject: |
Re: [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
- [Qemu-devel] [PATCH v2 01/14] spapr: populate DRC entries for root dt node, (continued)
- [Qemu-devel] [PATCH v2 01/14] spapr: populate DRC entries for root dt node, Michael Roth, 2013/12/05
- [Qemu-devel] [PATCH v2 05/14] spapr_pci: add get/set-power-level RTAS interfaces, Michael Roth, 2013/12/05
- [Qemu-devel] [PATCH v2 08/14] memory: add memory_region_find_subregion, Michael Roth, 2013/12/05
- [Qemu-devel] [PATCH v2 11/14] spapr_pci: enable basic hotplug operations, Michael Roth, 2013/12/05
- [Qemu-devel] [PATCH v2 10/14] pci: allow 0 address for PCI IO regions, Michael Roth, 2013/12/05
- Re: [Qemu-devel] [PATCH v2 10/14] pci: allow 0 address for PCI IO regions, Michael S. Tsirkin, 2013/12/12
[Qemu-devel] [PATCH v2 12/14] spapr_events: re-use EPOW event infrastructure for hotplug events, Michael Roth, 2013/12/05
[Qemu-devel] [PATCH v2 13/14] spapr_events: event-scan RTAS interface, Michael Roth, 2013/12/05
[Qemu-devel] [PATCH v2 14/14] spapr_pci: emit hotplug add/remove events during hotplug, Michael Roth, 2013/12/05