Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@petalogix.com>

As stated before, devices can be little, big or native endian. The
target endianness is not of their concern, so we need to push things
down a level.

This patch adds a parameter to cpu_register_io_memory that allows a
device to choose its endianness. For now, all devices simply choose
native endian, because that's the same behavior as before.
Signed-off-by: NAlexander Graf <agraf@suse.de>
Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Signed-off-by: NMark McLoughlin <markmc@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

In the very least, a change like this requires discussion on the list.

The naming convention is goofy and it causes a massive merge problem.  Something
like this _must_ be presented on the list first so people can provide input
and cope with it.

This reverts commit 99a0949b.
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Some not so obvious bits, slirp and Xen were left alone for the time
being.
Signed-off-by: Nmalc <av1474@comtv.ru>

Sorry folks, but it has to be.  One more of these invasive qdev patches.

We have a serious design bug in the qdev interface:  device init
callbacks can't signal failure because the init() callback has no
return value.  This patch fixes it.

We have already one case in-tree where this is needed:
Try -device virtio-blk-pci (without drive= specified) and watch qemu
segfault.  This patch fixes it.

With usb+scsi being converted to qdev we'll get more devices where the
init callback can fail for various reasons.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NBlue Swirl <blauwirbel@gmail.com>

Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>
Message-Id: 

This patch is a major overhaul of the device properties.  The properties
are saved directly in the device state struct now, the linked list of
property values is gone.

Advantages:
  * We don't have to maintain the list with the property values.
  * The value in the property list and the value actually used by
    the device can't go out of sync any more (used to happen for
    the pci.devfn == -1 case) because there is only one place where
    the value is stored.
  * A record describing the property is required now, you can't set
    random properties any more.

There are bus-specific and device-specific properties.  The former
should be used for properties common to all bus drivers.  Typical
use case is bus addressing, i.e. pci.devfn and i2c.address.

Properties have a PropertyInfo struct attached with name, size and
function pointers to parse and print properties.  A few common property
types have PropertyInfos defined in qdev-properties.c.  Drivers are free
to implement their own very special property parsers if needed.

Properties can have default values.  If unset they are zero-filled.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@gmail.com>

The parameter is always zero except when registering the three internal
io regions (ROM, unassigned, notdirty).  Remove the parameter to reduce
the API's power, thus facilitating future change.
Signed-off-by: NAvi Kivity <avi@redhat.com>
Signed-off-by: NAnthony Liguori <aliguori@us.ibm.com>

Namely the new xilinx_ethlite used by mircoblaze.
Signed-off-by: NJan Kiszka <jan.kiszka@siemens.com>

Signed-off-by: NEdgar E. Iglesias <edgar.iglesias@gmail.com>