pci: pci_register_bar_simple

Signed-off-by Avi Kivity <[email protected]>

---
 hw/ide/ahci.c |    9 ---------
 hw/ide/ahci.h |    3 ---
 hw/ide/ich.c  |    3 +--
 3 files changed, 1 insertions(+), 14 deletions(-)

hw/ide/ahci.c +0 -9

index 98bdf70..c6e0c77 100644
@@ -1129,15 +1129,6 @@ void ahci_uninit(AHCIState *s)
     qemu_free(s->dev);
 }
 
-void ahci_pci_map(PCIDevice *pci_dev, int region_num,
-        pcibus_t addr, pcibus_t size, int type)
-{
-    struct AHCIPCIState *d = (struct AHCIPCIState *)pci_dev;
-    AHCIState *s = &d->ahci;
-
-    cpu_register_physical_memory(addr, size, s->mem);
-}
-
 void ahci_reset(void *opaque)
 {
     struct AHCIPCIState *d = opaque;

hw/ide/ahci.h +0 -3

index a4560c4..dc86951 100644
@@ -325,9 +325,6 @@ typedef struct NCQFrame {
 void ahci_init(AHCIState *s, DeviceState *qdev, int ports);
 void ahci_uninit(AHCIState *s);
 
-void ahci_pci_map(PCIDevice *pci_dev, int region_num,
-        pcibus_t addr, pcibus_t size, int type);
-
 void ahci_reset(void *opaque);
 
 #endif /* HW_IDE_AHCI_H */

hw/ide/ich.c +0 -0

index f242d7a..eb00f03 100644

Many PCI BARs that use the memory address space map a single MMIO region into the entire BAR range. Introduce an API pci_register_bar_simple() for that use case, and convert all users where this can be done trivially.

This will reduce the work required to introduce a PCI memory API; it's also a nice code reduction in its own right.

Avi Kivity (10):
pci: add pci_register_bar_simple() API
rtl8139: convert to pci_register_bar_simple()
cirrus-vga: convert to pci_register_bar_simple()
eepro100: convert to pci_register_bar_simple() ich/ahci: convert to pci_register_bar_simple()
hda-intel: convert to pci_register_bar_simple()
hda-intel: convert to pci_register_bar_simple() (partial)
pcnet-pci: convert to pci_register_bar_simple()
usb-ohci: convert to pci_register_bar_simple()
wdt_i6300esb: convert to pci_register_bar_simple()

 hw/cirrus_vga.c   |   13 ++-----------
 hw/eepro100.c     |   43 +++++++++++++------------------------------
 hw/ide/ahci.c     |    9 ---------
 hw/ide/ahci.h     |    3 ---
 hw/ide/ich.c      |    3 +--
 hw/intel-hda.c    |   11 +----------
 hw/lsi53c895a.c   |   12 +-----------
 hw/pci.c          |   17 +++++++++++++++++
 hw/pci.h          |    3 +++
 hw/pcnet-pci.c    |   16 +---------------
 hw/rtl8139.c      |   11 +----------
 hw/usb-ohci.c     |   10 +---------
 hw/wdt_i6300esb.c |   42 +++++++++++++++---------------------------
 13 files changed, 56 insertions(+), 137 deletions(-)

Quoted 4 lines · Avi Kivity

Many PCI BARs that use the memory address space map a single MMIO region into the entire BAR range. Introduce an API pci_register_bar_simple() for that use case, and convert all users where this can be done trivially.

Quoted 2 lines

This will reduce the work required to introduce a PCI memory API; it's also a nice code reduction in its own right.

This will save some code, so

Acked-by Michael S. Tsirkin<[email protected]>

I really hope the rest of devices will follow.

Quoted 6 lines · Avi Kivity

Many PCI BARs that use the memory address space map a single MMIO region into the entire BAR range. Introduce an API pci_register_bar_simple() for that use case, and convert all users where this can be done trivially.

This will reduce the work required to introduce a PCI memory API; it's also a nice code reduction in its own right.

This will save some code, so

Acked-by Michael S. Tsirkin<[email protected]>

I really hope the rest of devices will follow.

Quoted 26 lines

Avi Kivity (10):
pci: add pci_register_bar_simple() API
rtl8139: convert to pci_register_bar_simple()
cirrus-vga: convert to pci_register_bar_simple()
eepro100: convert to pci_register_bar_simple() ich/ahci: convert to pci_register_bar_simple()
hda-intel: convert to pci_register_bar_simple()
hda-intel: convert to pci_register_bar_simple() (partial)
pcnet-pci: convert to pci_register_bar_simple()
usb-ohci: convert to pci_register_bar_simple()
wdt_i6300esb: convert to pci_register_bar_simple()

  hw/cirrus_vga.c   |   13 ++-----------
  hw/eepro100.c     |   43 +++++++++++++------------------------------
  hw/ide/ahci.c     |    9 ---------
  hw/ide/ahci.h     |    3 ---
  hw/ide/ich.c      |    3 +--
  hw/intel-hda.c    |   11 +----------
  hw/lsi53c895a.c   |   12 +-----------
  hw/pci.c          |   17 +++++++++++++++++
  hw/pci.h          |    3 +++
  hw/pcnet-pci.c    |   16 +---------------
  hw/rtl8139.c      |   11 +----------
  hw/usb-ohci.c     |   10 +---------
  hw/wdt_i6300esb.c |   42 +++++++++++++++---------------------------
  13 files changed, 56 insertions(+), 137 deletions(-)

Quoted 5 lines · Michael S. Tsirkin

Quoted 4 lines · Avi Kivity

Many PCI BARs that use the memory address space map a single MMIO region into the entire BAR range. Introduce an API pci_register_bar_simple() for that use case, and convert all users where this can be done trivially.

Quoted 6 lines

Quoted 2 lines

This will reduce the work required to introduce a PCI memory API; it's also a nice code reduction in its own right.

This will save some code, so

Acked-by Michael S. Tsirkin<[email protected]>

I really hope the rest of devices will follow.

How complete is this?

Quoted 18 lines · Anthony Liguori

Quoted 16 lines · Michael S. Tsirkin

Quoted 10 lines · Avi Kivity

Many PCI BARs that use the memory address space map a single MMIO region into
the entire BAR range.  Introduce an API pci_register_bar_simple() for that use
case, and convert all users where this can be done trivially.

This will reduce the work required to introduce a PCI memory API; it's also
a nice code reduction in its own right.

This will save some code, so

Acked-by Michael S. Tsirkin<[email protected]>

Quoted 3 lines

Quoted 1 line

I really hope the rest of devices will follow.

How complete is this?

I converted all devices which were easy to convert.  There may be one or two more that can be converted with additional work (and perhaps with an additional pic_bar_get_current_address() API, and a pci_bar_set_coalescing() API).  The rest likely need to stick with the callback-based API.

Quoted 23 lines · Avi Kivity

Quoted 21 lines · Anthony Liguori

Quoted 9 lines · Michael S. Tsirkin

Quoted 7 lines · Avi Kivity

Many PCI BARs that use the memory address space map a single MMIO region into
the entire BAR range.  Introduce an API pci_register_bar_simple() for that use
case, and convert all users where this can be done trivially.

Quoted 8 lines

Quoted 3 lines

This will reduce the work required to introduce a PCI memory API; it's also
a nice code reduction in its own right.

This will save some code, so

Acked-by Michael S. Tsirkin<[email protected]>

I really hope the rest of devices will follow.

How complete is this?

Quoted 4 lines

I converted all devices which were easy to convert.  There may be one or two more that can be converted with additional work (and perhaps with an additional pic_bar_get_current_address() API, and a pci_bar_set_coalescing() API).  The rest likely need to stick with the callback-based API.

In my version which I sent earlier but didn't commit, also other BARs besides the first one and also tricky devices like VGA were handled.

But I didn't commit it because I felt it was not going to right direction. I think the BARs should be specified in PCIDeviceInfo instead of adding more function calls. The same applies to this patch set.

Quoted 29 lines · Blue Swirl

Quoted 27 lines · Avi Kivity

Quoted 15 lines · Anthony Liguori

Quoted 13 lines · Michael S. Tsirkin

Quoted 10 lines · Avi Kivity

Many PCI BARs that use the memory address space map a single MMIO region into
the entire BAR range.  Introduce an API pci_register_bar_simple() for that use
case, and convert all users where this can be done trivially.

This will reduce the work required to introduce a PCI memory API; it's also
a nice code reduction in its own right.

Quoted 6 lines

Quoted 4 lines

This will save some code, so

Acked-by Michael S. Tsirkin<[email protected]>

I really hope the rest of devices will follow.

How complete is this?

I converted all devices which were easy to convert.  There may be one or two more that can be converted with additional work (and perhaps with an additional pic_bar_get_current_address() API, and a pci_bar_set_coalescing() API).  The rest likely need to stick with the callback-based API.

Quoted 2 lines

In my version which I sent earlier but didn't commit, also other BARs besides the first one and also tricky devices like VGA were handled.

Yes, I liked that patchset too. What happened to it?

Quoted 4 lines

But I didn't commit it because I felt it was not going to right direction. I think the BARs should be specified in PCIDeviceInfo instead of adding more function calls. The same applies to this patch set.

Is that really that fundamental? What I do care about is making pci.c track and register all device memory so that we can finally implement pci bridge features such as master abort handling and unmapped memory.

Quoted 30 lines · Michael S. Tsirkin

Quoted 29 lines · Blue Swirl

Quoted 27 lines · Avi Kivity

Quoted 15 lines · Anthony Liguori

Quoted 13 lines · Michael S. Tsirkin

Quoted 10 lines · Avi Kivity

Many PCI BARs that use the memory address space map a single MMIO region into
the entire BAR range.  Introduce an API pci_register_bar_simple() for that use
case, and convert all users where this can be done trivially.

This will reduce the work required to introduce a PCI memory API; it's also
a nice code reduction in its own right.

Quoted 6 lines

Quoted 4 lines

This will save some code, so

Acked-by Michael S. Tsirkin<[email protected]>

I really hope the rest of devices will follow.

How complete is this?

I converted all devices which were easy to convert.  There may be one or two more that can be converted with additional work (and perhaps with an additional pic_bar_get_current_address() API, and a pci_bar_set_coalescing() API).  The rest likely need to stick with the callback-based API.

Quoted 4 lines

Quoted 2 lines

In my version which I sent earlier but didn't commit, also other BARs besides the first one and also tricky devices like VGA were handled.

Yes, I liked that patchset too. What happened to it?

Nothing, but I thought that there could be a "perfect" solution.

I like in Avi's version that unnecessary API changes are avoided.

Quoted 5 lines

Quoted 4 lines

But I didn't commit it because I felt it was not going to right direction. I think the BARs should be specified in PCIDeviceInfo instead of adding more function calls. The same applies to this patch set.

Quoted 4 lines

Is that really that fundamental? What I do care about is making pci.c track and register all device memory so that we can finally implement pci bridge features such as master abort handling and unmapped memory.

The structure version can be done later. Right, pci.c should manage the device mappings.

Quoted 31 lines · Blue Swirl

Quoted 30 lines · Michael S. Tsirkin

Quoted 29 lines · Blue Swirl

Quoted 27 lines · Avi Kivity

Quoted 15 lines · Anthony Liguori

Quoted 13 lines · Michael S. Tsirkin

Quoted 10 lines · Avi Kivity

Many PCI BARs that use the memory address space map a single MMIO region into
the entire BAR range.  Introduce an API pci_register_bar_simple() for that use
case, and convert all users where this can be done trivially.

This will reduce the work required to introduce a PCI memory API; it's also
a nice code reduction in its own right.

Quoted 6 lines

Quoted 4 lines

This will save some code, so

Acked-by Michael S. Tsirkin<[email protected]>

I really hope the rest of devices will follow.

How complete is this?

I converted all devices which were easy to convert.  There may be one or two more that can be converted with additional work (and perhaps with an additional pic_bar_get_current_address() API, and a pci_bar_set_coalescing() API).  The rest likely need to stick with the callback-based API.

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

In my version which I sent earlier but didn't commit, also other BARs besides the first one and also tricky devices like VGA were handled.

Yes, I liked that patchset too. What happened to it?

Nothing, but I thought that there could be a "perfect" solution.

I like in Avi's version that unnecessary API changes are avoided.

Yes, it's nice that it's incremental.

Quoted 10 lines

Quoted 9 lines

Quoted 4 lines

But I didn't commit it because I felt it was not going to right direction. I think the BARs should be specified in PCIDeviceInfo instead of adding more function calls. The same applies to this patch set.

Is that really that fundamental? What I do care about is making pci.c track and register all device memory so that we can finally implement pci bridge features such as master abort handling and unmapped memory.

Quoted 2 lines

The structure version can be done later. Right, pci.c should manage the device mappings.

OK, so applying Avi's patchset and building on that is your preferred approach too?

Quoted 56 lines · Michael S. Tsirkin

Quoted 31 lines · Blue Swirl

Quoted 30 lines · Michael S. Tsirkin

Quoted 29 lines · Blue Swirl

Quoted 27 lines · Avi Kivity

Quoted 15 lines · Anthony Liguori

Quoted 13 lines · Michael S. Tsirkin

Quoted 10 lines · Avi Kivity

Many PCI BARs that use the memory address space map a single MMIO region into
the entire BAR range.  Introduce an API pci_register_bar_simple() for that use
case, and convert all users where this can be done trivially.

This will reduce the work required to introduce a PCI memory API; it's also
a nice code reduction in its own right.

Quoted 6 lines

Quoted 4 lines

This will save some code, so

Acked-by Michael S. Tsirkin<[email protected]>

I really hope the rest of devices will follow.

How complete is this?

I converted all devices which were easy to convert.  There may be one or two more that can be converted with additional work (and perhaps with an additional pic_bar_get_current_address() API, and a pci_bar_set_coalescing() API).  The rest likely need to stick with the callback-based API.

Quoted 8 lines

Quoted 4 lines

Quoted 2 lines

In my version which I sent earlier but didn't commit, also other BARs besides the first one and also tricky devices like VGA were handled.

Yes, I liked that patchset too. What happened to it?

Nothing, but I thought that there could be a "perfect" solution.

I like in Avi's version that unnecessary API changes are avoided.

Yes, it's nice that it's incremental.

Quoted 12 lines

Quoted 9 lines

Quoted 4 lines

But I didn't commit it because I felt it was not going to right direction. I think the BARs should be specified in PCIDeviceInfo instead of adding more function calls. The same applies to this patch set.

Is that really that fundamental? What I do care about is making pci.c track and register all device memory so that we can finally implement pci bridge features such as master abort handling and unmapped memory.

The structure version can be done later. Right, pci.c should manage the device mappings.

Quoted 2 lines

OK, so applying Avi's patchset and building on that is your preferred approach too?

Avi's version is a bit too simple, at least multiple regions in a BAR should be handled (for example macio.c needs that). But also that can be added later (pci_register_bar_not_so_simple()?), so Avi's version could be used as the starting point.

Quoted 19 lines · Avi Kivity

Quoted 18 lines · Anthony Liguori

Quoted 16 lines · Michael S. Tsirkin

Quoted 10 lines · Avi Kivity

Many PCI BARs that use the memory address space map a single MMIO region into
the entire BAR range. Introduce an API pci_register_bar_simple() for that use
case, and convert all users where this can be done trivially.

This will reduce the work required to introduce a PCI memory API; it's also
a nice code reduction in its own right.

This will save some code, so

Acked-by Michael S. Tsirkin<[email protected]>

Quoted 8 lines

Quoted 3 lines

Quoted 1 line

I really hope the rest of devices will follow.

How complete is this?

I converted all devices which were easy to convert. There may be one or two more that can be converted with additional work (and perhaps with an additional pic_bar_get_current_address() API, and a pci_bar_set_coalescing() API). The rest likely need to stick with the callback-based API.

In my version which I sent earlier but didn't commit, also other BARs besides the first one and also tricky devices like VGA were handled.

But I didn't commit it because I felt it was not going to right direction. I think the BARs should be specified in PCIDeviceInfo instead of adding more function calls. The same applies to this patch set.

Quoted 38 lines · Blue Swirl

Quoted 24 lines · Avi Kivity

Quoted 23 lines · Anthony Liguori

Quoted 20 lines · Michael S. Tsirkin

Quoted 9 lines · Avi Kivity

 Many PCI BARs that use the memory address space map a single MMIO region
 into
 the entire BAR range.  Introduce an API pci_register_bar_simple() for
 that use
 case, and convert all users where this can be done trivially.

Quoted 4 lines

 This will reduce the work required to introduce a PCI memory API; it's
 also
 a nice code reduction in its own right.

 This will save some code, so

Acked-by Michael S. Tsirkin<[email protected]>

 I really hope the rest of devices will follow.

Quoted 8 lines

Quoted 1 line

 How complete is this?

 I converted all devices which were easy to convert.  There may be one or two
 more that can be converted with additional work (and perhaps with an additional pic_bar_get_current_address() API, and a pci_bar_set_coalescing()
 API).  The rest likely need to stick with the callback-based API.

In my version which I sent earlier but didn't commit, also other BARs besides the first one and also tricky devices like VGA were handled.

Quoted 4 lines

But I didn't commit it because I felt it was not going to right direction. I think the BARs should be specified in PCIDeviceInfo instead of adding more function calls. The same applies to this patch set.

The more complicated BARs cannot be described declaratively (at least without a lot of complicated infrastructure).  They can switch from RAM to MMIO mappings at runtime, and have different sub-regions.

Quoted 4 lines

The more complicated BARs cannot be described declaratively (at least without a lot of complicated infrastructure). They can switch from RAM to MMIO mappings at runtime, and have different sub-regions.

Subregions should be possible, but I agree run time switch will not. Those should be pretty rare, though.