[Qemu-devel] [PATCH 1/4] add byteordered types to qemu.

[Qemu-devel] [PATCH 1/4] add byteordered types to qemu.

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 bswap.h      |    7 +++++++
 hw/usb-net.c |    2 --
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/bswap.h b/bswap.h
index 523d805..b294d96 100644
--- a/bswap.h
+++ b/bswap.h
@@ -206,4 +206,11 @@ static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)
 #undef le_bswaps
 #undef be_bswaps
 
+typedef uint16_t le16;
+typedef uint32_t le32;
+typedef uint64_t le64;
+typedef uint16_t be16;
+typedef uint32_t be32;
+typedef uint64_t be64;
+
 #endif /* BSWAP_H */
diff --git a/hw/usb-net.c b/hw/usb-net.c
index 27dea10..447c0ce 100644
--- a/hw/usb-net.c
+++ b/hw/usb-net.c
@@ -326,8 +326,6 @@ enum {
 #define OID_PNP_REMOVE_WAKE_UP_PATTERN	0xfd010104
 #define OID_PNP_ENABLE_WAKE_UP		0xfd010106
 
-typedef uint32_t le32;
-
 typedef struct rndis_init_msg_type {
     le32 MessageType;
     le32 MessageLength;
-- 
1.5.5.1

[Qemu-devel] [PATCH 2/4] pci: add config space struct (from qemu-xen).

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/pci.h |   26 ++++++++++++++++++++++++++
 1 files changed, 26 insertions(+), 0 deletions(-)

diff --git a/hw/pci.h b/hw/pci.h
index e870987..f518e5e 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -6,6 +6,32 @@
 
 /* PCI bus */
 
+struct pci_config_header {
+    le16    vendor_id;
+    le16    device_id;
+    le16    command;
+    le16    status;
+    uint8_t revision;
+    uint8_t api;
+    uint8_t subclass;
+    uint8_t class;
+    uint8_t cache_line_size; /* Units of 32 bit words */
+    uint8_t latency_timer;   /* In units of bus cycles */
+    uint8_t header_type;     /* Should be 0 */
+    uint8_t bist;            /* Built in self test */
+    le32    base_address_regs[6];
+    le32    reserved1;
+    le16    sub_vendor_id;
+    le16    sub_device_id;
+    le32    rom_addr;
+    le32    reserved3;
+    le32    reserved4;
+    uint8_t interrupt_line;
+    uint8_t interrupt_pin;
+    uint8_t min_gnt;
+    uint8_t max_lat;
+};
+
 extern target_phys_addr_t pci_mem_base;
 
 typedef void PCIConfigWriteFunc(PCIDevice *pci_dev,
-- 
1.5.5.1

[Qemu-devel] [PATCH 3/4] pci: add default pci subsystem id for all devices.

[Gerd Hoffmann]

This sets a default PCI subsystem ID for all emulated PCI devices.  PCI
specs require this, so do it.  The defaults are global variables so
they can easily be changed (before device creation) as Xen probably
wants to use the XenSource vendor ID instead of the qemu default.

The defaults are pre-filled by pci_register_device().  Individual
drivers can overwrite it of course when setting up the config space
for the emulated device.

TODO: get an official vendor ID assigned, or borrow one (maybe
      Qumranet which already sponsors the virtio IDs ???).

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/pci.c |   11 +++++++++++
 hw/pci.h |    2 ++
 2 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index bc55989..ffc90d7 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -50,6 +50,8 @@ static void pci_update_mappings(PCIDevice *d);
 static void pci_set_irq(void *opaque, int irq_num, int level);
 
 target_phys_addr_t pci_mem_base;
+uint16_t pci_default_sub_vendor_id = 0xfffa; /* FIXME: get one assigned */
+uint16_t pci_default_sub_device_id = 0x0001;
 static int pci_irq_index;
 static PCIBus *first_bus;
 
@@ -145,6 +147,14 @@ int pci_device_load(PCIDevice *s, QEMUFile *f)
     return 0;
 }
 
+static int pci_set_default_subsystem_id(PCIDevice *pci_dev)
+{
+    struct pci_config_header *conf = (void*)pci_dev->config;
+
+    conf->sub_vendor_id = cpu_to_le16(pci_default_sub_vendor_id);
+    conf->sub_device_id = cpu_to_le16(pci_default_sub_device_id);
+}
+
 /* -1 for devfn means auto assign */
 PCIDevice *pci_register_device(PCIBus *bus, const char *name,
                                int instance_size, int devfn,
@@ -171,6 +181,7 @@ PCIDevice *pci_register_device(PCIBus *bus, const char *name,
     pci_dev->devfn = devfn;
     pstrcpy(pci_dev->name, sizeof(pci_dev->name), name);
     memset(pci_dev->irq_state, 0, sizeof(pci_dev->irq_state));
+    pci_set_default_subsystem_id(pci_dev);
 
     if (!config_read)
         config_read = pci_default_read_config;
diff --git a/hw/pci.h b/hw/pci.h
index f518e5e..28e8fb5 100644
--- a/hw/pci.h
+++ b/hw/pci.h
@@ -33,6 +33,8 @@ struct pci_config_header {
 };
 
 extern target_phys_addr_t pci_mem_base;
+extern uint16_t pci_default_sub_vendor_id;
+extern uint16_t pci_default_sub_device_id;
 
 typedef void PCIConfigWriteFunc(PCIDevice *pci_dev,
                                 uint32_t address, uint32_t data, int len);
-- 
1.5.5.1

Re: [Qemu-devel] [PATCH 3/4] pci: add default pci subsystem id for all devices.

[Anthony Liguori]

Gerd Hoffmann wrote:
> This sets a default PCI subsystem ID for all emulated PCI devices.  PCI
> specs require this, so do it.  The defaults are global variables so
> they can easily be changed (before device creation) as Xen probably
> wants to use the XenSource vendor ID instead of the qemu default.
>
> The defaults are pre-filled by pci_register_device().  Individual
> drivers can overwrite it of course when setting up the config space
> for the emulated device.
>
> TODO: get an official vendor ID assigned, or borrow one (maybe
>       Qumranet which already sponsors the virtio IDs ???).
>   

Does the subvendor ID have to be an official vendor ID?  I thought that 
the subvendor ID could be defined by the vendor as whatever it wants..

> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  hw/pci.c |   11 +++++++++++
>  hw/pci.h |    2 ++
>  2 files changed, 13 insertions(+), 0 deletions(-)
>
> diff --git a/hw/pci.c b/hw/pci.c
> index bc55989..ffc90d7 100644
> --- a/hw/pci.c
> +++ b/hw/pci.c
> @@ -50,6 +50,8 @@ static void pci_update_mappings(PCIDevice *d);
>  static void pci_set_irq(void *opaque, int irq_num, int level);
>  
>  target_phys_addr_t pci_mem_base;
> +uint16_t pci_default_sub_vendor_id = 0xfffa; /* FIXME: get one assigned */
> +uint16_t pci_default_sub_device_id = 0x0001;
>   

Probably should just be a define.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH 3/4] pci: add default pci subsystem id for all devices.

[Gerd Hoffmann]

Anthony Liguori wrote:
>> TODO: get an official vendor ID assigned, or borrow one (maybe
>>       Qumranet which already sponsors the virtio IDs ???).
> 
> Does the subvendor ID have to be an official vendor ID?

I think so, as far I know there is no difference between vendor and
subvendor ID in that respect.

> I thought that
> the subvendor ID could be defined by the vendor as whatever it wants..

Each vendor can assign the device (and subdevice) IDs freely.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 3/4] pci: add default pci subsystem id for all devices.

[Anthony Liguori]

Gerd Hoffmann wrote:
> Anthony Liguori wrote:
>   
>>> TODO: get an official vendor ID assigned, or borrow one (maybe
>>>       Qumranet which already sponsors the virtio IDs ???).
>>>       
>> Does the subvendor ID have to be an official vendor ID?
>>     
>
> I think so, as far I know there is no difference between vendor and
> subvendor ID in that respect.
>
>   
>> I thought that
>> the subvendor ID could be defined by the vendor as whatever it wants..
>>     
>
> Each vendor can assign the device (and subdevice) IDs freely.
>   

It's worth looking into because in virtio, we currently define the 
subvendor ID to be not the PCI vendor ID space.  I'll try to dig up a 
copy of the PCI spec and confirm.  If it's not required to be the PCI 
vendor ID space, then this patch is unnecessary.  We can just set it to 
a non-0 value of our choosing.

Regards,

Anthony Liguori

> cheers,
>   Gerd
>
>
>   

Re: [Qemu-devel] [PATCH 3/4] pci: add default pci subsystem id for all devices.

[Gerd Hoffmann]

  Hi,

>> Each vendor can assign the device (and subdevice) IDs freely.
> 
> It's worth looking into because in virtio, we currently define the
> subvendor ID to be not the PCI vendor ID space.  I'll try to dig up a
> copy of the PCI spec and confirm.  If it's not required to be the PCI
> vendor ID space, then this patch is unnecessary.  We can just set it to
> a non-0 value of our choosing.

Ehrm, no.  I'll try a bit more verbose ...

Each PCI device has a PCI ID.  It should also have a PCI Subsystem ID.
The PCI subsystem ID wasn't mandatory in early PCI spec revisions, IIRC
2.0 added that requirement.  Thats why you usually get away without a
PCI subsystem ID, although it isn't correct.

Both IDs have a 16bit vendor and a 16bit device part.  The vendor IDs
are handed out by the PCI SIG.  The device IDs are assigned by the
vendor owning the vendor ID.

The PCI ID tells you which PCI chip is used, whereas the the PCI
Subsystem ID identifies the actual device (created using the PCI chip).

Example #1:  TV cards.  All TV cards using the bt878 chipset (first and
only one on the market for a few years in the 90-ies) have the same PCI
ID, the one of the bt878 chip.  But each TV card has different PCI
Subsystem IDs, which can be used to figure what the actual TV card is.

Example #2:  Laptops.  It is quite common to find the PCI Subsytem ID
pointing to the laptop vendor and model.  So the PCI ID says
'this is a intel ich7 ide controller', whereas the the PCI Subsystem ID
says 'this ich7 sits in a lenovo thinkpad', like this:

--------- cut here ----------
[root@zweiblum ~]# lspci -vs1f.1
00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE
Controller (rev 02) (prog-if 8a [Master SecP PriP])
        Subsystem: Lenovo ThinkPad T60/R60 series
        [ ... more stuff snipped ... ]
--------- cut here ----------

In many cases it is enougth to know the PCI ID to handle a device
correctly.  Sometimes a device driver must identify the exact piece of
hardware (via PCI Subsystem ID) though.


Ok, now to qemu.  Right now the emulated PCI devices have no PCI
subsystem ID, only the PCI ID.  The discussed patch sets a default PCI
subsystem ID for all emulated devices.  Which will make the qemu devices
look pretty much like in the laptop case: all PCI subsystem IDs will
point to qemu by default.

If a driver emulates a very specific piece of hardware where it has to
emulate more than just the PCI chip, it can overwrite the PCI subsystem
ID without problems.  The es1370 driver does that for example.


Right now the patch uses the vendor ID 0xfffa.  XenSource grabbed a
temporary ID (before they got one official assigned) from the 0xfffx
space too.  We'll better get something official though, to avoid
clashes.  We could try to get a vendor ID assigned (no idea how
difficuilt and/or expensive that would be).  Or we could try get get a
device ID range from a vendor (like the qumranet-sponsored IDs for
virtio ...).

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 3/4] pci: add default pci subsystem id for all devices.

[Gerd Hoffmann]

Gerd Hoffmann wrote:
>   Hi,
> 
>>> Each vendor can assign the device (and subdevice) IDs freely.
>> It's worth looking into because in virtio, we currently define the
>> subvendor ID to be not the PCI vendor ID space.  I'll try to dig up a
>> copy of the PCI spec and confirm.  If it's not required to be the PCI
>> vendor ID space, then this patch is unnecessary.  We can just set it to
>> a non-0 value of our choosing.

Ping.  What is the status of this?  Did you find time to check the PCI
specs?  Did the explanation I've tried below the trick?  Any other
outstanding issues with the patches?  I'm not aware of any ...

cheers,
  Gerd

> Ehrm, no.  I'll try a bit more verbose ...
> 
> Each PCI device has a PCI ID.  It should also have a PCI Subsystem ID.
> The PCI subsystem ID wasn't mandatory in early PCI spec revisions, IIRC
> 2.0 added that requirement.  Thats why you usually get away without a
> PCI subsystem ID, although it isn't correct.
> 
> Both IDs have a 16bit vendor and a 16bit device part.  The vendor IDs
> are handed out by the PCI SIG.  The device IDs are assigned by the
> vendor owning the vendor ID.
> 
> The PCI ID tells you which PCI chip is used, whereas the the PCI
> Subsystem ID identifies the actual device (created using the PCI chip).
> 
> Example #1:  TV cards.  All TV cards using the bt878 chipset (first and
> only one on the market for a few years in the 90-ies) have the same PCI
> ID, the one of the bt878 chip.  But each TV card has different PCI
> Subsystem IDs, which can be used to figure what the actual TV card is.
> 
> Example #2:  Laptops.  It is quite common to find the PCI Subsytem ID
> pointing to the laptop vendor and model.  So the PCI ID says
> 'this is a intel ich7 ide controller', whereas the the PCI Subsystem ID
> says 'this ich7 sits in a lenovo thinkpad', like this:
> 
> --------- cut here ----------
> [root@zweiblum ~]# lspci -vs1f.1
> 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE
> Controller (rev 02) (prog-if 8a [Master SecP PriP])
>         Subsystem: Lenovo ThinkPad T60/R60 series
>         [ ... more stuff snipped ... ]
> --------- cut here ----------
> 
> In many cases it is enougth to know the PCI ID to handle a device
> correctly.  Sometimes a device driver must identify the exact piece of
> hardware (via PCI Subsystem ID) though.
> 
> 
> Ok, now to qemu.  Right now the emulated PCI devices have no PCI
> subsystem ID, only the PCI ID.  The discussed patch sets a default PCI
> subsystem ID for all emulated devices.  Which will make the qemu devices
> look pretty much like in the laptop case: all PCI subsystem IDs will
> point to qemu by default.
> 
> If a driver emulates a very specific piece of hardware where it has to
> emulate more than just the PCI chip, it can overwrite the PCI subsystem
> ID without problems.  The es1370 driver does that for example.
> 
> 
> Right now the patch uses the vendor ID 0xfffa.  XenSource grabbed a
> temporary ID (before they got one official assigned) from the 0xfffx
> space too.  We'll better get something official though, to avoid
> clashes.  We could try to get a vendor ID assigned (no idea how
> difficuilt and/or expensive that would be).  Or we could try get get a
> device ID range from a vendor (like the qumranet-sponsored IDs for
> virtio ...).
> 
> cheers,
>   Gerd
> 

[Qemu-devel] [PATCH 4/4] pci: use pci_config_header in pci.c

[Gerd Hoffmann]

This makes use of the new pci_config_header struct in pci.c,
squashing a bunch of casts and hard-coded magic numbers.

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/pci.c |   64 +++++++++++++++++++++++++++++++-------------------------------
 1 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/hw/pci.c b/hw/pci.c
index ffc90d7..4212e1f 100644
--- a/hw/pci.c
+++ b/hw/pci.c
@@ -199,8 +199,9 @@ void pci_register_io_region(PCIDevice *pci_dev, int region_num,
                             uint32_t size, int type,
                             PCIMapIORegionFunc *map_func)
 {
+    struct pci_config_header *conf = (void*)pci_dev->config;
     PCIIORegion *r;
-    uint32_t addr;
+    le32 *addr;
 
     if ((unsigned int)region_num >= PCI_NUM_REGIONS)
         return;
@@ -210,11 +211,11 @@ void pci_register_io_region(PCIDevice *pci_dev, int region_num,
     r->type = type;
     r->map_func = map_func;
     if (region_num == PCI_ROM_SLOT) {
-        addr = 0x30;
+        addr = &conf->rom_addr;
     } else {
-        addr = 0x10 + region_num * 4;
+        addr = conf->base_address_regs + region_num;
     }
-    *(uint32_t *)(pci_dev->config + addr) = cpu_to_le32(type);
+    *addr = cpu_to_le32(type);
 }
 
 static target_phys_addr_t pci_to_cpu_addr(target_phys_addr_t addr)
@@ -224,23 +225,24 @@ static target_phys_addr_t pci_to_cpu_addr(target_phys_addr_t addr)
 
 static void pci_update_mappings(PCIDevice *d)
 {
+    struct pci_config_header *conf = (void*)d->config;
     PCIIORegion *r;
     int cmd, i;
-    uint32_t last_addr, new_addr, config_ofs;
+    uint32_t last_addr, new_addr;
+    le32 *config_addr;
 
-    cmd = le16_to_cpu(*(uint16_t *)(d->config + PCI_COMMAND));
+    cmd = le16_to_cpu(conf->command);
     for(i = 0; i < PCI_NUM_REGIONS; i++) {
         r = &d->io_regions[i];
         if (i == PCI_ROM_SLOT) {
-            config_ofs = 0x30;
+            config_addr = &conf->rom_addr;
         } else {
-            config_ofs = 0x10 + i * 4;
+            config_addr = conf->base_address_regs + i;
         }
         if (r->size != 0) {
             if (r->type & PCI_ADDRESS_SPACE_IO) {
                 if (cmd & PCI_COMMAND_IO) {
-                    new_addr = le32_to_cpu(*(uint32_t *)(d->config +
-                                                         config_ofs));
+                    new_addr = le32_to_cpu(*config_addr);
                     new_addr = new_addr & ~(r->size - 1);
                     last_addr = new_addr + r->size - 1;
                     /* NOTE: we have only 64K ioports on PC */
@@ -253,8 +255,7 @@ static void pci_update_mappings(PCIDevice *d)
                 }
             } else {
                 if (cmd & PCI_COMMAND_MEMORY) {
-                    new_addr = le32_to_cpu(*(uint32_t *)(d->config +
-                                                         config_ofs));
+                    new_addr = le32_to_cpu(*config_addr);
                     /* the ROM slot has a specific enable bit */
                     if (i == PCI_ROM_SLOT && !(new_addr & 1))
                         goto no_mem_map;
@@ -568,13 +569,14 @@ static pci_class_desc pci_class_descriptions[] =
 
 static void pci_info_device(PCIDevice *d)
 {
+    struct pci_config_header *conf = (void*)d->config;
     int i, class;
     PCIIORegion *r;
     pci_class_desc *desc;
 
     term_printf("  Bus %2d, device %3d, function %d:\n",
            d->bus->bus_num, d->devfn >> 3, d->devfn & 7);
-    class = le16_to_cpu(*((uint16_t *)(d->config + PCI_CLASS_DEVICE)));
+    class = conf->class << 8 | conf->subclass;
     term_printf("    ");
     desc = pci_class_descriptions;
     while (desc->desc && class != desc->class)
@@ -585,11 +587,11 @@ static void pci_info_device(PCIDevice *d)
         term_printf("Class %04x", class);
     }
     term_printf(": PCI device %04x:%04x\n",
-           le16_to_cpu(*((uint16_t *)(d->config + PCI_VENDOR_ID))),
-           le16_to_cpu(*((uint16_t *)(d->config + PCI_DEVICE_ID))));
+                le16_to_cpu(conf->vendor_id),
+                le16_to_cpu(conf->device_id));
 
-    if (d->config[PCI_INTERRUPT_PIN] != 0) {
-        term_printf("      IRQ %d.\n", d->config[PCI_INTERRUPT_LINE]);
+    if (conf->interrupt_line != 0) {
+        term_printf("      IRQ %d.\n", conf->interrupt_line);
     }
     if (class == 0x0604) {
         term_printf("      BUS %d.\n", d->config[0x19]);
@@ -686,25 +688,23 @@ static void pci_bridge_write_config(PCIDevice *d,
 PCIBus *pci_bridge_init(PCIBus *bus, int devfn, uint32_t id,
                         pci_map_irq_fn map_irq, const char *name)
 {
+    struct pci_config_header *conf;
     PCIBridge *s;
     s = (PCIBridge *)pci_register_device(bus, name, sizeof(PCIBridge),
                                          devfn, NULL, pci_bridge_write_config);
-    s->dev.config[0x00] = id >> 16;
-    s->dev.config[0x01] = id >> 24;
-    s->dev.config[0x02] = id; // device_id
-    s->dev.config[0x03] = id >> 8;
-    s->dev.config[0x04] = 0x06; // command = bus master, pci mem
-    s->dev.config[0x05] = 0x00;
-    s->dev.config[0x06] = 0xa0; // status = fast back-to-back, 66MHz, no error
-    s->dev.config[0x07] = 0x00; // status = fast devsel
-    s->dev.config[0x08] = 0x00; // revision
-    s->dev.config[0x09] = 0x00; // programming i/f
-    s->dev.config[0x0A] = 0x04; // class_sub = PCI to PCI bridge
-    s->dev.config[0x0B] = 0x06; // class_base = PCI_bridge
-    s->dev.config[0x0D] = 0x10; // latency_timer
-    s->dev.config[0x0E] = 0x81; // header_type
-    s->dev.config[0x1E] = 0xa0; // secondary status
+    conf = (void*)s->dev.config;
+    conf->vendor_id = cpu_to_le16(id >> 16);
+    conf->device_id = cpu_to_le16(id & 0xffff);
+    conf->command   = cpu_to_le16(0x0006); // bus master, pci mem
+    conf->status    = cpu_to_le16(0x00a0); // fast back-to-back, 66MHz, no error, fast devsel
+    conf->revision      = 0x00;
+    conf->api           = 0x00;
+    conf->subclass      = 0x04; // PCI to PCI bridge
+    conf->class         = 0x06; // PCI_bridge
+    conf->latency_timer = 0x10;
+    conf->header_type   = 0x81;
 
+    s->dev.config[0x1E] = 0xa0; // secondary status
     s->bus = pci_register_secondary_bus(&s->dev, map_irq);
     return s->bus;
 }
-- 
1.5.5.1

Re: [Qemu-devel] [PATCH 1/4] add byteordered types to qemu.

[Anthony Liguori]

Is there a 4/4 in the series?

Regards,

Anthony Liguori

Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  bswap.h      |    7 +++++++
>  hw/usb-net.c |    2 --
>  2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/bswap.h b/bswap.h
> index 523d805..b294d96 100644
> --- a/bswap.h
> +++ b/bswap.h
> @@ -206,4 +206,11 @@ static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)
>  #undef le_bswaps
>  #undef be_bswaps
>  
> +typedef uint16_t le16;
> +typedef uint32_t le32;
> +typedef uint64_t le64;
> +typedef uint16_t be16;
> +typedef uint32_t be32;
> +typedef uint64_t be64;
> +
>  #endif /* BSWAP_H */
> diff --git a/hw/usb-net.c b/hw/usb-net.c
> index 27dea10..447c0ce 100644
> --- a/hw/usb-net.c
> +++ b/hw/usb-net.c
> @@ -326,8 +326,6 @@ enum {
>  #define OID_PNP_REMOVE_WAKE_UP_PATTERN	0xfd010104
>  #define OID_PNP_ENABLE_WAKE_UP		0xfd010106
>  
> -typedef uint32_t le32;
> -
>  typedef struct rndis_init_msg_type {
>      le32 MessageType;
>      le32 MessageLength;
>   

Re: [Qemu-devel] [PATCH 1/4] add byteordered types to qemu.

[Anthony Liguori]

Anthony Liguori wrote:
> Is there a 4/4 in the series?

Apparently so.  Sorry, my mail delivery is quite lagged today.

Regards,

Anthony Liguori

[Qemu-devel] [PATCH 1/4] add byteordered types to qemu.

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 bswap.h      |    7 +++++++
 hw/usb-net.c |    2 --
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/bswap.h b/bswap.h
index 523d805..b294d96 100644
--- a/bswap.h
+++ b/bswap.h
@@ -206,4 +206,11 @@ static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)
 #undef le_bswaps
 #undef be_bswaps
 
+typedef uint16_t le16;
+typedef uint32_t le32;
+typedef uint64_t le64;
+typedef uint16_t be16;
+typedef uint32_t be32;
+typedef uint64_t be64;
+
 #endif /* BSWAP_H */
diff --git a/hw/usb-net.c b/hw/usb-net.c
index 63edfd5..23ae805 100644
--- a/hw/usb-net.c
+++ b/hw/usb-net.c
@@ -326,8 +326,6 @@ enum {
 #define OID_PNP_REMOVE_WAKE_UP_PATTERN	0xfd010104
 #define OID_PNP_ENABLE_WAKE_UP		0xfd010106
 
-typedef uint32_t le32;
-
 typedef struct rndis_init_msg_type {
     le32 MessageType;
     le32 MessageLength;
-- 
1.5.5.1

[Qemu-devel] [PATCH 1/4] add byteordered types to qemu.

[Gerd Hoffmann]

Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 bswap.h      |    7 +++++++
 hw/usb-net.c |    2 --
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/bswap.h b/bswap.h
index 523d805..b294d96 100644
--- a/bswap.h
+++ b/bswap.h
@@ -206,4 +206,11 @@ static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)
 #undef le_bswaps
 #undef be_bswaps
 
+typedef uint16_t le16;
+typedef uint32_t le32;
+typedef uint64_t le64;
+typedef uint16_t be16;
+typedef uint32_t be32;
+typedef uint64_t be64;
+
 #endif /* BSWAP_H */
diff --git a/hw/usb-net.c b/hw/usb-net.c
index 82005af..569cd7d 100644
--- a/hw/usb-net.c
+++ b/hw/usb-net.c
@@ -326,8 +326,6 @@ enum {
 #define OID_PNP_REMOVE_WAKE_UP_PATTERN	0xfd010104
 #define OID_PNP_ENABLE_WAKE_UP		0xfd010106
 
-typedef uint32_t le32;
-
 typedef struct rndis_init_msg_type {
     le32 MessageType;
     le32 MessageLength;
-- 
1.5.5.1

Re: [Qemu-devel] [PATCH 1/4] add byteordered types to qemu.

[Christoph Hellwig]

On Wed, Oct 01, 2008 at 04:12:52PM +0200, Gerd Hoffmann wrote:
> 
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
>  bswap.h      |    7 +++++++
>  hw/usb-net.c |    2 --
>  2 files changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/bswap.h b/bswap.h
> index 523d805..b294d96 100644
> --- a/bswap.h
> +++ b/bswap.h
> @@ -206,4 +206,11 @@ static inline void cpu_to_be32wu(uint32_t *p, uint32_t v)
>  #undef le_bswaps
>  #undef be_bswaps
>  
> +typedef uint16_t le16;
> +typedef uint32_t le32;
> +typedef uint64_t le64;
> +typedef uint16_t be16;
> +typedef uint32_t be32;
> +typedef uint64_t be64;

Any chance you could add sparse __bitwise__ declarations so one could
use spare to check for using these types correctly?

Re: [Qemu-devel] [PATCH 1/4] add byteordered types to qemu.

[Gerd Hoffmann]

Christoph Hellwig wrote:

>> +typedef uint16_t le16;
>> +typedef uint32_t le32;
>> +typedef uint64_t le64;
>> +typedef uint16_t be16;
>> +typedef uint32_t be32;
>> +typedef uint64_t be64;
> 
> Any chance you could add sparse __bitwise__ declarations so one could
> use spare to check for using these types correctly?

Is there any good documentation on that?

Looking at the linux kernel sources I find the bitwise stuff depend on
the __CHECKER__ and __CHECK_ENDIAN__ defines.  I can't find references
to these in the sparse man page and sparse FAQ (sparse 0.4.1 as shipped
by fedora 9).

I can somehow guess what these two defines do.  __CHECKER__ probably is
set by sparse, and __CHECK_ENDIAN__ by the -Wbitwise switch.  But I
can't see any obvious reason why include/linux/types.h defines both
__bitwise__ and __bitwise.  I'd simply use something along the lines ...

  #if defined(__CHECKER__) && defined(__CHECK_ENDIAN__)
  # define __bitwise__ __attribute__((bitwise))
  #else
  # define __bitwise__
  #endif

  typedef uint16_t __bitwise__ le16;
  [ ... ]

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 1/4] add byteordered types to qemu.

[Christoph Hellwig]

On Thu, Oct 02, 2008 at 02:46:41PM +0200, Gerd Hoffmann wrote:
> Christoph Hellwig wrote:
> 
> >> +typedef uint16_t le16;
> >> +typedef uint32_t le32;
> >> +typedef uint64_t le64;
> >> +typedef uint16_t be16;
> >> +typedef uint32_t be32;
> >> +typedef uint64_t be64;
> > 
> > Any chance you could add sparse __bitwise__ declarations so one could
> > use spare to check for using these types correctly?
> 
> Is there any good documentation on that?

I don't think so.  But I've recently added support for it in the XFS
userspace tools, so I have some experience.

> 
> Looking at the linux kernel sources I find the bitwise stuff depend on
> the __CHECKER__ and __CHECK_ENDIAN__ defines.  I can't find references
> to these in the sparse man page and sparse FAQ (sparse 0.4.1 as shipped
> by fedora 9).
> 
> I can somehow guess what these two defines do.  __CHECKER__ probably is
> set by sparse, and __CHECK_ENDIAN__ by the -Wbitwise switch.  But I
> can't see any obvious reason why include/linux/types.h defines both
> __bitwise__ and __bitwise.  I'd simply use something along the lines ...

Actually __CHECKER__ is set by sparse.  __CHECK_ENDIAN__ is set on the
make command line when checking for endianess bugs.  For xfsprogs I
defined the bitwise annotations unconditionally because we made sure
to not have any of this warnings left (this was quite easy becaus a lot
of the code came from the kernel and was already properly annotated)

These are the snipplets from xfsprogs that would be useful for qemu:

#ifdef __CHECKER__
#define __bitwise	__attribute__((bitwise))
#define __force		__attribute__((force))
#else
#define __bitwise
#define __force
#endif

The __force is needed for the actual swab macros to turn the __bitwise
annotated type back into the normal so it doesn't warn.  For XFS these
conversion macros looks the same as the kernel ones:

#ifdef XFS_NATIVE_HOST
#define cpu_to_be16(val)       ((__force __be16)(__u16)(val))
#define cpu_to_be32(val)       ((__force __be32)(__u32)(val))
#define cpu_to_be64(val)       ((__force __be64)(__u64)(val))
#define be16_to_cpu(val)       ((__force __u16)(__be16)(val))
#define be32_to_cpu(val)       ((__force __u32)(__be32)(val))
#define be64_to_cpu(val)       ((__force __u64)(__be64)(val))
#else
#define cpu_to_be16(val)       ((__force __be16)__swab16((__u16)(val)))
#define cpu_to_be32(val)       ((__force __be32)__swab32((__u32)(val)))
#define cpu_to_be64(val)       ((__force __be64)__swab64((__u64)(val)))
#define be16_to_cpu(val)       (__swab16((__force __u16)(__be16)(val)))
#define be32_to_cpu(val)       (__swab32((__force __u32)(__be32)(val)))
#define be64_to_cpu(val)       (__swab64((__force __u64)(__be64)(val)))
#endif

and then you define the types as __bitwise:

typedef __u16 __bitwise                __be16;
typedef __u32 __bitwise                __be32;
typedef __u64 __bitwise                __be64;

for qemu you'll need slight changes in the names, and also little
endian variants which we don't have in XFS.

Note that the biggest hurdle for xfsprogs was to convince libtool
that cgcc, the gcc wrapper for invoking sparse actually is a C compiler,
but that should be mood for qemu.

Note that sparse will probably complain about a lot of things in
qemu, so you'll have to add a lot -Wno-foo options in addition to
-Wbitwise.

Re: [Qemu-devel] [PATCH 1/4] add byteordered types to qemu.

[Gerd Hoffmann]

Christoph Hellwig wrote:
> Actually __CHECKER__ is set by sparse.  __CHECK_ENDIAN__ is set on the
> make command line when checking for endianess bugs.  For xfsprogs I
> defined the bitwise annotations unconditionally because we made sure
> to not have any of this warnings left (this was quite easy becaus a lot
> of the code came from the kernel and was already properly annotated)

Thanks.  I still can't see the point of __CHECK_ENDIAN__ though, as
-W(no-)bitwise should have the very same effect.  Historical reasons?

> These are the snipplets from xfsprogs that would be useful for qemu:
> 
> #ifdef __CHECKER__
> #define __bitwise	__attribute__((bitwise))
> #define __force		__attribute__((force))
> #else
> #define __bitwise
> #define __force
> #endif

> The __force is needed for the actual swab macros to turn the __bitwise
> annotated type back into the normal so it doesn't warn.  For XFS these
> conversion macros looks the same as the kernel ones:
> 
> #ifdef XFS_NATIVE_HOST
> #define cpu_to_be16(val)       ((__force __be16)(__u16)(val))
[ ... ]
> #else
> #define cpu_to_be16(val)       ((__force __be16)__swab16((__u16)(val)))
[ ... ]
> #endif
> 
> and then you define the types as __bitwise:
> 
> typedef __u16 __bitwise                __be16;
[ ... ]

I see.

> for qemu you'll need slight changes in the names, and also little
> endian variants which we don't have in XFS.

Sure.

> Note that the biggest hurdle for xfsprogs was to convince libtool
> that cgcc, the gcc wrapper for invoking sparse actually is a C compiler,
> but that should be mood for qemu.

Nevertheless it must be winded up in configure and the build system.
Shouldn't be hard though.  How fast is sparse?  Would it be sane to run
it by default in case we find cgcc installed on the system?  Or should
it better be opt-in?

> Note that sparse will probably complain about a lot of things in
> qemu, so you'll have to add a lot -Wno-foo options in addition to
> -Wbitwise.

Even -Wbitwise will probably generate tons of warnings initially.

cheers,
  Gerd

Re: [Qemu-devel] [PATCH 1/4] add byteordered types to qemu.

[Christoph Hellwig]

On Thu, Oct 02, 2008 at 03:15:19PM +0200, Gerd Hoffmann wrote:
> > Actually __CHECKER__ is set by sparse.  __CHECK_ENDIAN__ is set on the
> > make command line when checking for endianess bugs.  For xfsprogs I
> > defined the bitwise annotations unconditionally because we made sure
> > to not have any of this warnings left (this was quite easy becaus a lot
> > of the code came from the kernel and was already properly annotated)
> 
> Thanks.  I still can't see the point of __CHECK_ENDIAN__ though, as
> -W(no-)bitwise should have the very same effect.  Historical reasons?

Me neither.  I guess it simply predates -Wbitwise.

> > Note that the biggest hurdle for xfsprogs was to convince libtool
> > that cgcc, the gcc wrapper for invoking sparse actually is a C compiler,
> > but that should be mood for qemu.
> 
> Nevertheless it must be winded up in configure and the build system.
> Shouldn't be hard though.  How fast is sparse?  Would it be sane to run
> it by default in case we find cgcc installed on the system?  Or should
> it better be opt-in?

cgcc is a drop-in wrapper that calls both gcc and sparse.  So you just
set your compiler to cgcc before configure or in the Makefile and then
both sparse and gcc get run.

sparse is extremly fast and barely noticeable compared to the speed
gcc takes to compile a file, but of course you have two fork exec
wait circles instead of one so some overhead is noticeable when
compiling lots of small files.

Re: [Qemu-devel] [PATCH 1/4] add byteordered types to qemu.

[Gerd Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

Christoph Hellwig wrote:
> cgcc is a drop-in wrapper that calls both gcc and sparse.  So you just
> set your compiler to cgcc before configure or in the Makefile and then
> both sparse and gcc get run.

The attached configure patch enabled that in case sparse is installed.
Should also get cross-builds right.  Only buildsystem stuff for now, no
bitwise annotations (yet).

Oh joy, I get sparse warnings and errors(!) for the system headers then.
Disabled the most noisy stuff for now.

Comments?
  Gerd


[-- Attachment #2: qemu-sparse.diff --]
[-- Type: text/plain, Size: 1887 bytes --]

diff --git a/configure b/configure
index 9c8ed81..3f3e0f7 100755
--- a/configure
+++ b/configure
@@ -85,6 +85,7 @@ case "$cpu" in
   ;;
 esac
 gprof="no"
+sparse="yes"
 bigendian="no"
 mingw32="no"
 EXESUF=""
@@ -286,6 +287,8 @@ for opt do
   ;;
   --audio-drv-list=*) audio_drv_list="$optarg"
   ;;
+  --disable-sparse) sparse="no"
+  ;;
   --disable-vnc-tls) vnc_tls="no"
   ;;
   --disable-slirp) slirp="no"
@@ -425,6 +428,7 @@ echo "  --host-cc=CC             use C compiler CC [$host_cc] for dyngen etc."
 echo "  --make=MAKE              use specified make [$make]"
 echo "  --install=INSTALL        use specified install [$install]"
 echo "  --static                 enable static build [$static]"
+echo "  --disable-sparse         disable sparse checker"
 echo "  --disable-werror         disable compilation abort on warning"
 echo "  --disable-sdl            disable SDL"
 echo "  --enable-cocoa           enable COCOA (Mac OS X only)"
@@ -536,6 +540,10 @@ EOF
     fi
 fi
 
+if test ! -x "$(which cgcc 2>/dev/null)"; then
+    sparse="no"
+fi
+
 #
 # Solaris specific configure tool chain decisions
 #
@@ -1007,6 +1015,7 @@ echo "host CPU          $cpu"
 echo "host big endian   $bigendian"
 echo "target list       $target_list"
 echo "gprof enabled     $gprof"
+echo "sparse enabled    $sparse"
 echo "profiler          $profiler"
 echo "static build      $static"
 echo "-Werror enabled   $werror"
@@ -1156,6 +1165,11 @@ case "$cpu" in
     exit 1
   ;;
 esac
+if test "$sparse" = "yes" ; then
+  echo "CC      := REAL_CC=\"\$(CC)\" cgcc"       >> $config_mak
+  echo "HOST_CC := REAL_CC=\"\$(HOST_CC)\" cgcc"  >> $config_mak
+  echo "CFLAGS  += -Wbitwise -Wno-transparent-union -Wno-old-initializer -Wno-non-pointer-null" >> $config_mak
+fi
 if test "$bigendian" = "yes" ; then
   echo "WORDS_BIGENDIAN=yes" >> $config_mak
   echo "#define WORDS_BIGENDIAN 1" >> $config_h

Re: [Qemu-devel] [PATCH 1/4] add byteordered types to qemu.

[Anthony Liguori]

Gerd Hoffmann wrote:
> Christoph Hellwig wrote:
>   
>> cgcc is a drop-in wrapper that calls both gcc and sparse.  So you just
>> set your compiler to cgcc before configure or in the Makefile and then
>> both sparse and gcc get run.
>>     
>
> The attached configure patch enabled that in case sparse is installed.
> Should also get cross-builds right.  Only buildsystem stuff for now, no
> bitwise annotations (yet).
>
> Oh joy, I get sparse warnings and errors(!) for the system headers then.
> Disabled the most noisy stuff for now.
>
> Comments?
>   

Good idea, but perhaps it should be disabled by default instead of 
enabled by default?

Regards,

Anthony Liguori

>   Gerd
>
>   

Re: [Qemu-devel] [PATCH 1/4] add byteordered types to qemu.

[Gerd Hoffmann]

Anthony Liguori wrote:
> Gerd Hoffmann wrote:
> Good idea, but perhaps it should be disabled by default instead of
> enabled by default?

I'd try default-enabled first.  Given that sparse isn't installed by
default by distros I think it is ok:  When people installed it
intentionally they probably welcome seeing it used automatically ;)

cheers,
  Gerd