Re: [Qemu-devel] qemu-kvm 1.2, after VM cloning, source_VM error

2013-04-29 Thread Shashaankar Reddy
Apologies for the late reply!!

Never mind, we figured it out,

Since we are doing cloning of VM, at the source(from where cloning is
initiated) we are redirecting the disk driver of the VM to a new
incremental image (qcow2). Also making the previous disk image as read
only, since the cloned VM will be using this read only image as the backing
file.

In a nutshell the backing file relation is as follows, with the entire
setup in NFS:

---src-VM---
before clonig
src_disk_driver-../src/rubis_ws.img  /home/shashaa/setup/rubis_ws.img
(base image)

after cloning
src_disk_driver../src/rubis_ws.img_clone 
/home/shashaa/setup/parent/rubis_ws.img

/home/shashaa/setup/parent/rubis_ws.img -- making it read only image

 ---Cloned-VM---
 ../cloned/rubis_ws.img - /home/shashaa/setup/parent/rubis_ws.img

So the actual issue was with re-directing of disk driver to the newly
created image ../src/rubis_ws.img_clone, where we are closing the driver
entries for old image and re-opening with the new one. Setting the correct
flags while opening the disk driver for
new image is the actual root cause.




Thanks,
-Shashaa
--Never let's schooling
 interfere with Education!!


On Wed, Apr 17, 2013 at 4:37 AM, Stefan Hajnoczi stefa...@gmail.com wrote:

 On Tue, Apr 16, 2013 at 08:02:27PM -0400, Shashaankar Reddy wrote:
  We have taken qemu-kvm version 1.2 for developing a patch that would do
  cloning of a VM using pre-copy based live VM migration in qemu-kvm code.
 
  After the migration is completed, we could see the cloned_Vm is up and
  running, also handled network configuration (assigning new mac and Ip
  addresses). But where as at the src_VM we see a strange error, when we
  logged into the src_VM via vnc viewer:
 
   ide: failed opcode was: unknown
  hdd: task_in_intr: status=0x41 { DriveReady Error }
   hdd: task_in_intr: error=0x04 { DriveStatusError }
   ide: failed opcode was: unknown
   hdd: task_in_intr: status=0x41 { DriveReady Error }
  hdd: task_in_intr: error=0x04 { DriveStatusError }
 
  --- these above messages are repeating infinitely making the CPU usage
  of the VM to 95-99% and it would not receive any further request to
  serve (we  have an rubis server inside the VM ). Though the VM is
  accessible to the host network (we are able to ping the VM).
 
  Could any one of you help us in this issue?

 Looks like your migration approach breaks IDE device save/load.

 How can we help without seeing the code?

 Stefan



Re: [Qemu-devel] [PATCH 2/3] block: add block_backup QMP command

2013-04-29 Thread Stefan Hajnoczi
On Fri, Apr 26, 2013 at 04:58:24PM -0600, Eric Blake wrote:
 On 04/23/2013 10:25 AM, Stefan Hajnoczi wrote:
  @block-backup
  
  Start a point-in-time copy of a block device to a new destination.
  
  @device:  the name of the device whose writes should be mirrored.
  
  @target: the target of the new image. If the file exists, or if it
   is a device, the existing file/device will be used as the new
   destination.  If it does not exist, a new file will be created.
  
  @format: #optional the format of the new destination, default is to
   probe if @mode is 'existing', else the format of the source
  
  @mode: #optional whether and how QEMU should create a new image, default is
 'absolute-paths'.
  
  @speed:  #optional the maximum speed, in bytes per second
  
  Returns: nothing on success
   If @device is not a valid block device, DeviceNotFound
 
 This starts a new block job type; I assume the existing block-job-cancel
 and query-block-jobs can track it.

Right.  I will update the documentation to be explicit about the block
job that this command creates.

 I'd really love to see us change 'BlockJobInfo' to use an enum for
 'type', instead of its open-coded 'str'.  Likewise, the block-job
 related events in QMP/qmp-events.txt should be updated to refer to the
 enum instead of also being open-coded 'str'.

Since the block job QMP API has been in released I'm not sure changing
this is worthwhile.  QEMU and libvirt would have to maintain
compatibility so the code will just be duplicated.

 Will this job be called backup?

Yes, it is called backup.



Re: [Qemu-devel] [PATCH 0/3] block: block-backup live backup command

2013-04-29 Thread Stefan Hajnoczi
On Sat, Apr 27, 2013 at 01:37:07PM +0800, Wenchao Xia wrote:
 于 2013-4-24 0:25, Stefan Hajnoczi 写道:
  This series adds a new QMP command, block-backup, which takes a 
  point-in-time
  snapshot of a block device.  The snapshot is copied out to a target block
  device.  A simple example is:
  
 block-backup device=virtio0 format=qcow2 target=backup-20130401.qcow2
  
  The original block-backup blockjob was written by Dietmar Maurer
  diet...@proxmox.com.  He is currently busy but I feel the feature is worth
  pushing into QEMU since there has been interest.  This is my version of his
  patch, plus the QMP command and qemu-iotests test case.
  
  How is this different from block-stream and drive-mirror?
  -
  Both block-stream and drive-mirror do not provide immediate point-in-time
  snapshots.  Instead they copy data into a new file and then switch to it.  
  In
  other words, the point at which the snapshot is taken cannot be controlled
  directly.
  
  block-backup intercepts guest writes and saves data into the target block
  device before it is overwritten.  The target block device can be a raw image
  file, backing files are not used to implement this feature.
  
   Besides, compared to snapshot-blkdev, it mainly brings better
 performance by avoid merging later, however, other tool may
 be needed to form an incremental backup, which may be not related to
 this patch.
   No objection to this patch, but perhaps a better way is using
 internal snapshot by adding base/delta data export support.

Yes, incremental backups would need to be added later.

Stefan



Re: [Qemu-devel] [oss-security] Re: [PATCH 1/3] virtio-pci: properly validate address before accessing config

2013-04-29 Thread Michael S. Tsirkin
On Mon, Apr 29, 2013 at 01:34:44AM -0600, Kurt Seifried wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 04/28/2013 05:29 AM, Petr Matousek wrote:
  On Sat, Apr 27, 2013 at 01:13:16PM +0800, Jason Wang wrote:
  On 04/26/2013 10:27 PM, Petr Matousek wrote:
  On Fri, Apr 26, 2013 at 04:34:02PM +0800, Jason Wang wrote:
  There are several several issues in the current checking:
  
  - The check was based on the minus of unsigned values which
  can overflow - It was done after .{set|get}_config() which
  can lead crash when config_len is zero since vdev-config is
  NULL
  
  Fix this by:
  
  - Validate the address in virtio_pci_config_{read|write}()
  before .{set|get}_config - Use addition instead minus to do
  the validation
  
  Cc: Michael S. Tsirkin m...@redhat.com Cc: Petr Matousek
  pmato...@redhat.com Signed-off-by: Jason Wang
  jasow...@redhat.com --- hw/virtio/virtio-pci.c |9
  + hw/virtio/virtio.c |   18 -- 2
  files changed, 9 insertions(+), 18 deletions(-)
  
  diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c 
  index a1f15a8..7f6c7d1 100644 --- a/hw/virtio/virtio-pci.c 
  +++ b/hw/virtio/virtio-pci.c @@ -400,6 +400,10 @@ static
  uint64_t virtio_pci_config_read(void *opaque, hwaddr addr, } 
  addr -= config;
  
  +if (addr + size  proxy-vdev-config_len) { +
  return (uint32_t)-1; +} +
  What is the range of values addr can be? I guess it's not
  arbitrary and not fully in guests hands. Can it be higher than
  corresponding pci config space size?
  
  Not fully in guests hands. It depends on size the config size. 
  Unfortunately, qemu will roundup the size to power of 2 in 
  virtio_pci_device_plugged():
  
  size = VIRTIO_PCI_REGION_SIZE(proxy-pci_dev) +
  virtio_bus_get_vdev_config_len(bus);
  
  if (size  (size - 1)) { size = 1  qemu_fls(size); }
  
  So, for virtio-rng, though its region size is 20, it will be
  rounded up to 32, which left guest the possibility to access
  beyond the config space. So some check is needs in
  virito_pci_config_read().
  
  Ok, in that case it would make sense to document the preconditions
  that assures that addr + size won't overflow. Or add the values in
  a safe way (check that the sum is not less than one of the
  addend).
  
  IOW, can guest touch anything interesting or will all accesses
  end in the first page in the qemu address space, considering
  vdev-config being NULL?
  
  
  There's another theoretical issue as pointed by Anthony, see 
  virtio_config_writew():
  
  void virtio_config_writew(VirtIODevice *vdev, uint32_t addr,
  uint32_t data) { uint16_t val = data;
  
  if (addr  (vdev-config_len - sizeof(val))) return;
  
  stw_p(vdev-config + addr, val);
  
  if (vdev-set_config) vdev-set_config(vdev, vdev-config); }
  
  If there's a device whose config_len is 1, the check will fail
  and we can access some other location.
  
  But since virtio-rng has zero config length and addr here should
  be less than 12, and all other device's config length is all
  greater than 4. Only first page could be access here.
  
  So the only practical attack (virtio-rng device that has config
  length 0) can only end in the first page of qemu address space
  which is on any not-so-much recent kernel protected by
  mmap_min_addr and will result in qemu process crash. Access to pci
  config space is privileged operation, so root user in the guest can
  crash the guest (something that root can do anyways).
  
  Don't get me wrong, we still need the fix to avoid any potential
  issues in the future, but I'm leaning towards not treating this
  issue as a security (CVE) one due to the lack of practical
  exploitability.
  
  @Kurt -- do we assign CVE identifiers to issues that rely on an
  option (or lack of) that when set in a way that would allow the
  issue in question to be exploited is known to be insecure?
  
  References: 
  https://lists.gnu.org/archive/html/qemu-devel/2013-04/msg05013.html
 
  
 https://bugzilla.redhat.com/show_bug.cgi?id=957155
  
  The option is mmap_min_addr which assures that no mapping can be
  present at the beginning of the address space and all accesses will
  result in sigsegv. Default setting of mmap_min_addr is enough to
  avoid this issue from having security consequences. Disabling
  mmap_min_addr (setting to 0) means that some if not all of the
  kernel NULL pointer dereferences out there could be used for
  privilege escalation.
  
  Thanks,
  
 
 Ok so this does NOT affect Linux systems using mmap_min_addr with a
 sane default value (e.g. larger than 0). However more than a few
 systems have shipped with mmap_min_addr set to 0, not picking on
 Debian, just the first result I found:
 
 http://wiki.debian.org/mmap_min_addr
 
 In Debian 5.0.0 through 5.0.3 inclusive, the 2.6.26 kernel is shipped
 with a default mmap_min_addr of '0'.
 
 Hopefully everyone has upgraded to 5.0.4 =).
 
 So there is a realistic potential for systems to be affected (e.g. if
 this had 

Re: [Qemu-devel] [RFC PATCH v5 01/14] util: introduce gsource event abstraction

2013-04-29 Thread Stefan Hajnoczi
On Sat, Apr 27, 2013 at 10:11:40AM +0800, liu ping fan wrote:
 On Fri, Apr 26, 2013 at 5:19 PM, Stefan Hajnoczi stefa...@redhat.com wrote:
  On Fri, Apr 26, 2013 at 10:47:22AM +0800, Liu Ping Fan wrote:
  +GPollFD *events_source_add_gfd(EventsGSource *src, int fd)
  +{
  +GPollFD *retfd;
  +
  +retfd = g_slice_alloc(sizeof(GPollFD));
  +retfd-events = 0;
  +retfd-fd = fd;
  +src-pollfds_list = g_list_append(src-pollfds_list, retfd);
  +if (fd  0) {
 
  0 (stdin) is a valid fd number.  Maybe just assert(fd = 0)?
 
 Yes, 0 should be allowed.   Here, the reason to use check instead of
 assert , is that socreate() in slirp is a good place to call
 _add_gfd,  but unfortunately, at that time, its socket handler so-s =
 -1;   So we create the GPollFD ahead, and delay to call
 g_source_add_poll()

ok

  +static gboolean events_source_check(GSource *src)
  +{
  +EventsGSource *nsrc = (EventsGSource *)src;
  +GList *cur;
  +GPollFD *gfd;
  +
  +cur = nsrc-pollfds_list;
  +while (cur) {
  +gfd = cur-data;
  +if (gfd-fd  0  (gfd-revents  gfd-events)) {
 
  revents will always be 0 if fd is invalid, since we didn't call
  g_source_add_poll().  Is there a reason to perform the fd  0 check
  again?
 
 As explained above, we should skip the case gfd-fd=-1, which may
 occur in pollfds_list.

ok

  +void events_source_release(EventsGSource *src)
  +{
 
  assert that pollfds_list is empty?  We don't g_slice_free() GPollFDs so
  it must be empty here.
 
 Do you mean that   events_source_add_gfd/events_source_remove_gfd are
 paired, so here, we ensure that pollfds_list==NULL ?

Yes.  It is an error to hold a GPollFD across events_source_release() so
you could place an assert() here to check.

Stefan



[Qemu-devel] dec.c - move to pci-bridge

2013-04-29 Thread Michael S. Tsirkin
Looks like dec.c is in pci-host by mistake.
I'll move it over to pci-bridge if not one
complains.



Re: [Qemu-devel] [PATCH 3/4] vfio: Move container list to iommu MemoryRegion

2013-04-29 Thread Paolo Bonzini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 28/04/2013 03:58, David Gibson ha scritto:
 Ok, knowing about changes that happen in the IOMMU mapping is
 indeed out of scope of MemoryListeners.  What about adding a
 NotifierList? Then VFIO can register a notifier and use it to
 learn about events in the IOMMU mapping.  The notifier data
 can be a MemoryRegionSection or IOMMUTableEntry, whatever you
 find more convenient.
 For the generic case a Notifier could work in principle.  Neither
 of those structures is suitable as the data though: constructing a 
 MemoryRegionSection for every page we map into the IOTLB is far
 too heavyweight, and the IOMMUTLBEntry doesn't contain the IOVA.

It did in Avi's patch set.  I removed it because it was unused.  I can
add it back if you need it.

 Thinking over, I think what that mostly amounts to, is that if the 
 VFIO aspects of the address space are already wired up by the host 
 bridge, then the individual vfio-pci devices need a way of going
 from their qemu iommu address space (which they get from
 pci_dev-iommu) to the vfio specific information about that address
 space.

That can be done with just a hash table, no?

Paolo
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRfisaAAoJEBvWZb6bTYby08gP/RcK8KfnW3bt4+sKui499rN0
N2YG+YOUySyrbChY2p9MQHmvQpHeJF+Qb6J2WkpqVHCewXox90uYaLMfUvHLGDuh
tYusHQj9ew1afNYqUR19UIhiV11W+2Zy3GIDV6hEA0/lUEtvFYkKe4qqjYL6XPNh
3ZjrgYoGVZeXeN9FAcefVhKrZNkeG+QBg1FtXeCjinz3ZtjAsaR5QT8y8/quV7/W
+i9IPh5bl7eMKPFKJl92uVnX7lF3IXkm+dBJGCMuTtp2e2uCGBiAop5FvvZdH25V
VsYUxh57Mk6CFER8h23qGt7evU5QU7CS6Lq7mJav1sVJARtVGqv2Nizd8557UCgq
EYsJx7iHFJrmxCiIx4yrzLO8fPtnvwcXsmthvLcC3N9FYYCNNgaMGAV3J2OSGHqC
OkgpWWxHWokp1i1qumKGJH3KNd/3Yzys/KmeBf3t8Uk4sXFzHZcYFqr6qKopAGVw
9wLA/wBDUF9TOGg/DLcQuQ7de95uJQs7yQislcuXUS8gQ87hnvk3STCLvnPJwcvt
WcsBJFj2H62cdKemoaMaDDtwwTNds/BwHNaiQp9DjIBj6Lq25c0tk4Xswv0lc/yn
InsGeDVtCIUkEBHu9T8PD9Te2T59CgvpXjQ/ZEJkXnI5fDm1i1vda2xQx6Erp2ah
UKPltbecB2Oj09Yul6XC
=16N8
-END PGP SIGNATURE-



Re: [Qemu-devel] [PATCH] memory: give name every AddressSpace

2013-04-29 Thread Paolo Bonzini
Il 29/04/2013 04:11, Alexey Kardashevskiy ha scritto:
 The info mtree command in QEMU console prints only memory and I/O
 address spaces while there are actually a lot more other AddressSpace
 structs created by PCI and VIO devices. Those devices do not normally
 have names and therefore not present in info qtree output.
 
 The patch fixes this.
 
 Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
 ---
 
 
 The number of AddressSpace structs is constantly growing (even without IOMMU)
 and it is getting harder to trace them so this is why I came up with this 
 patch.
 Or there is a reason to hide those AddressSpace structs which I do not see,
 is not it?
 
 
 ---
  exec.c|6 ++
  hw/pci/pci.c  |3 ++-
  hw/ppc/spapr_vio.c|2 +-
  include/exec/memory.h |2 +-
  memory.c  |7 ---
  5 files changed, 10 insertions(+), 10 deletions(-)
 
 diff --git a/exec.c b/exec.c
 index 180a345..0091272 100644
 --- a/exec.c
 +++ b/exec.c
 @@ -1839,13 +1839,11 @@ static void memory_map_init(void)
  {
  system_memory = g_malloc(sizeof(*system_memory));
  memory_region_init(system_memory, system, INT64_MAX);
 -address_space_init(address_space_memory, system_memory);
 -address_space_memory.name = memory;
 +address_space_init(address_space_memory, system_memory, memory);
  
  system_io = g_malloc(sizeof(*system_io));
  memory_region_init(system_io, io, 65536);
 -address_space_init(address_space_io, system_io);
 -address_space_io.name = I/O;
 +address_space_init(address_space_io, system_io, I/O);
  
  memory_listener_register(core_memory_listener, address_space_memory);
  memory_listener_register(io_memory_listener, address_space_io);
 diff --git a/hw/pci/pci.c b/hw/pci/pci.c
 index fe146dc..0a1acd6 100644
 --- a/hw/pci/pci.c
 +++ b/hw/pci/pci.c
 @@ -823,7 +823,8 @@ static PCIDevice *do_pci_register_device(PCIDevice 
 *pci_dev, PCIBus *bus,
  memory_region_init_alias(pci_dev-bus_master_enable_region, bus 
 master,
   pci_dev-iommu, 0, 
 memory_region_size(pci_dev-iommu));
  memory_region_set_enabled(pci_dev-bus_master_enable_region, false);
 -address_space_init(pci_dev-bus_master_as, 
 pci_dev-bus_master_enable_region);
 +address_space_init(pci_dev-bus_master_as, 
 pci_dev-bus_master_enable_region,
 +   name);
  
  pci_dev-devfn = devfn;
  pstrcpy(pci_dev-name, sizeof(pci_dev-name), name);
 diff --git a/hw/ppc/spapr_vio.c b/hw/ppc/spapr_vio.c
 index fbcbd6f..fadde20 100644
 --- a/hw/ppc/spapr_vio.c
 +++ b/hw/ppc/spapr_vio.c
 @@ -449,7 +449,7 @@ static int spapr_vio_busdev_init(DeviceState *qdev)
  if (pc-rtce_window_size) {
  uint32_t liobn = SPAPR_VIO_BASE_LIOBN | dev-reg;
  dev-tcet = spapr_tce_new_table(liobn, pc-rtce_window_size);
 -address_space_init(dev-as, spapr_tce_get_iommu(dev-tcet));
 +address_space_init(dev-as, spapr_tce_get_iommu(dev-tcet), 
 qdev-id);
  }
  
  return pc-init(dev);
 diff --git a/include/exec/memory.h b/include/exec/memory.h
 index 99d51b7..b4f1182 100644
 --- a/include/exec/memory.h
 +++ b/include/exec/memory.h
 @@ -840,7 +840,7 @@ void mtree_info(fprintf_function mon_printf, void *f);
   * @as: an uninitialized #AddressSpace
   * @root: a #MemoryRegion that routes addesses for the address space
   */
 -void address_space_init(AddressSpace *as, MemoryRegion *root);
 +void address_space_init(AddressSpace *as, MemoryRegion *root, const char 
 *name);
  
  

Please update the doc comment.

  /**
 diff --git a/memory.c b/memory.c
 index cee3e59..b50f5e6 100644
 --- a/memory.c
 +++ b/memory.c
 @@ -1002,7 +1002,7 @@ void memory_region_init_iommu(MemoryRegion *mr,
  mr-terminates = true;  /* then re-forwards */
  mr-destructor = memory_region_destructor_iommu;
  mr-iommu_target_as = g_new(AddressSpace, 1);
 -address_space_init(mr-iommu_target_as, target);
 +address_space_init(mr-iommu_target_as, target, name);
  }
  
  static uint64_t invalid_read(void *opaque, hwaddr addr,
 @@ -1599,7 +1599,7 @@ void memory_listener_unregister(MemoryListener 
 *listener)
  QTAILQ_REMOVE(memory_listeners, listener, link);
  }
  
 -void address_space_init(AddressSpace *as, MemoryRegion *root)
 +void address_space_init(AddressSpace *as, MemoryRegion *root, const char 
 *name)
  {
  memory_region_transaction_begin();
  as-root = root;
 @@ -1608,7 +1608,7 @@ void address_space_init(AddressSpace *as, MemoryRegion 
 *root)
  as-ioeventfd_nb = 0;
  as-ioeventfds = NULL;
  QTAILQ_INSERT_TAIL(address_spaces, as, address_spaces_link);
 -as-name = NULL;
 +as-name = g_strdup(name?name:anonymous);
  address_space_init_dispatch(as);
  memory_region_update_pending |= root-enabled;
  memory_region_transaction_commit();
 @@ -1623,6 +1623,7 @@ void address_space_destroy(AddressSpace *as)
  QTAILQ_REMOVE(address_spaces, as, address_spaces_link);
  

Re: [Qemu-devel] [PATCH v4 7/7] hw/i386: build ACPI MADT (APIC) for fw_cfg clients

2013-04-29 Thread Michael S. Tsirkin
On Fri, Apr 26, 2013 at 01:13:28PM +0200, Laszlo Ersek wrote:
 On 04/25/13 21:03, Anthony Liguori wrote:
  Laszlo Ersek ler...@redhat.com writes:
  
  This patch reuses some code from SeaBIOS, which was originally under
  LGPLv2 and then relicensed to GPLv3 or LGPLv3, in QEMU under GPLv2+. This
  relicensing has been acked by all contributors that had contributed to the
  code since the v2-v3 relicense. ACKs approving the v2+ relicensing are
  listed below. The list might include ACKs from people not holding
  copyright on any parts of the reused code, but it's better to err on the
  side of caution and include them.
 
  Affected SeaBIOS files (GPLv2+ license headers added)
  http://thread.gmane.org/gmane.comp.bios.coreboot.seabios/5949:
 
   src/acpi-dsdt-cpu-hotplug.dsl|   15 +++
   src/acpi-dsdt-dbug.dsl   |   15 +++
   src/acpi-dsdt-hpet.dsl   |   15 +++
   src/acpi-dsdt-isa.dsl|   15 +++
   src/acpi-dsdt-pci-crs.dsl|   15 +++
   src/acpi.c   |   14 +-
   src/acpi.h   |   14 ++
   src/ssdt-misc.dsl|   15 +++
   src/ssdt-pcihp.dsl   |   15 +++
   src/ssdt-proc.dsl|   15 +++
   tools/acpi_extract.py|   13 -
   tools/acpi_extract_preprocess.py |   13 -
   12 files changed, 171 insertions(+), 3 deletions(-)
 
  Each one of the listed people agreed to the following:
 
  If you allow the use of your contribution in QEMU under the
  terms of GPLv2 or later as proposed by this patch,
  please respond to this mail including the line:
 
  Acked-by: Name email address
 
Acked-by: Gerd Hoffmann kra...@redhat.com
Acked-by: Jan Kiszka jan.kis...@siemens.com
Acked-by: Jason Baron jba...@akamai.com
Acked-by: David Woodhouse david.woodho...@intel.com
Acked-by: Gleb Natapov g...@redhat.com
Acked-by: Marcelo Tosatti mtosa...@redhat.com
Acked-by: Dave Frodin dave.fro...@se-eng.com
Acked-by: Paolo Bonzini pbonz...@redhat.com
Acked-by: Kevin O'Connor ke...@koconnor.net
Acked-by: Laszlo Ersek ler...@redhat.com
Acked-by: Kenji Kaneshige kaneshige.ke...@jp.fujitsu.com
Acked-by: Isaku Yamahata yamah...@valinux.co.jp
Acked-by: Magnus Christensson magnus.christens...@intel.com
Acked-by: Hu Tao hu...@cn.fujitsu.com
Acked-by: Eduardo Habkost ehabk...@redhat.com
 
  The patch incorporates ideas/suggestions from Michael Tsirkin's prototype
  code:
  - hw/i386/pc.c is too big, create new file hw/i386/acpi.c with
i386-specific ACPI table stuff,
  - separate preparation of individual tables from their installation as
fw_cfg files,
  - install these fw_cfg files inside pc_memory_init(), which is shared by
piix4/q35,
  - add the above licensing-related block to the commit message.
 
  Signed-off-by: Laszlo Ersek ler...@redhat.com
  ---
   configure |   12 
   hw/i386/Makefile.objs |1 +
   hw/i386/acpi.h|9 +++
   hw/i386/acpi.c|  159 
  +
   hw/i386/pc.c  |   23 +++
   5 files changed, 204 insertions(+), 0 deletions(-)
   create mode 100644 hw/i386/acpi.h
   create mode 100644 hw/i386/acpi.c
 
  diff --git a/configure b/configure
  index ed49f91..45a5f55 100755
  --- a/configure
  +++ b/configure
  @@ -241,6 +241,7 @@ gtk=
   gtkabi=2.0
   tpm=no
   libssh2=
  +dynamic_acpi=no
   
   # parse CC options first
   for opt do
  @@ -928,6 +929,10 @@ for opt do
 ;;
 --enable-libssh2) libssh2=yes
 ;;
  +  --disable-dynamic-acpi) dynamic_acpi=no
  +  ;;
  +  --enable-dynamic-acpi) dynamic_acpi=yes
  +  ;;
 *) echo ERROR: unknown option $opt; show_help=yes
 ;;
 esac
  @@ -1195,6 +1200,8 @@ echo   --gcov=GCOV  use specified gcov 
  [$gcov_tool]
   echo   --enable-tpm enable TPM support
   echo   --disable-libssh2disable ssh block device support
   echo   --enable-libssh2 enable ssh block device support
  +echo   --disable-dynamic-acpi   disable dynamic ACPI table generation 
  (default)
  +echo   --enable-dynamic-acpienable dynamic ACPI table generation 
  (work in progress)
   echo 
   echo NOTE: The object files are built at the place where configure is 
  launched
   exit 1
  @@ -3573,6 +3580,7 @@ echo gcov enabled  $gcov
   echo TPM support   $tpm
   echo libssh2 support   $libssh2
   echo TPM passthrough   $tpm_passthrough
  +echo dynamic ACPI tables $dynamic_acpi
   
   if test $sdl_too_old = yes; then
   echo - Your SDL version is too old - please upgrade to have SDL support
  @@ -3958,6 +3966,10 @@ if test $virtio_blk_data_plane = yes ; then
 echo 'CONFIG_VIRTIO_BLK_DATA_PLANE=$(CONFIG_VIRTIO)'  $config_host_mak
   fi
   
  +if test $dynamic_acpi = yes; then
  +  echo CONFIG_DYN_ACPI=y  $config_host_mak
  +fi
  +
   # 

Re: [Qemu-devel] [PATCH 6/6] pc_sysfw: change rom_only default to 0

2013-04-29 Thread Paolo Bonzini
Il 28/04/2013 10:32, Jordan Justen ha scritto:
 Now KVM can support a flash memory. This feature depends on
 KVM_CAP_READONLY_MEM, which was introduced in Linux 3.7.

I don't think we can require such a new kernel to run KVM.  IIUC, an
older kernel would just fail to start, right?

Paolo



Re: [Qemu-devel] [PATCH] memory: give name every AddressSpace

2013-04-29 Thread Alexey Kardashevskiy
On 04/29/2013 06:16 PM, Paolo Bonzini wrote:
 Il 29/04/2013 04:11, Alexey Kardashevskiy ha scritto:
 The info mtree command in QEMU console prints only memory and I/O
 address spaces while there are actually a lot more other AddressSpace
 structs created by PCI and VIO devices. Those devices do not normally
 have names and therefore not present in info qtree output.

 The patch fixes this.

 Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
 ---


 The number of AddressSpace structs is constantly growing (even without IOMMU)
 and it is getting harder to trace them so this is why I came up with this 
 patch.
 Or there is a reason to hide those AddressSpace structs which I do not see,
 is not it?


 ---
  exec.c|6 ++
  hw/pci/pci.c  |3 ++-
  hw/ppc/spapr_vio.c|2 +-
  include/exec/memory.h |2 +-
  memory.c  |7 ---
  5 files changed, 10 insertions(+), 10 deletions(-)

 diff --git a/exec.c b/exec.c
 index 180a345..0091272 100644
 --- a/exec.c
 +++ b/exec.c
 @@ -1839,13 +1839,11 @@ static void memory_map_init(void)
  {
  system_memory = g_malloc(sizeof(*system_memory));
  memory_region_init(system_memory, system, INT64_MAX);
 -address_space_init(address_space_memory, system_memory);
 -address_space_memory.name = memory;
 +address_space_init(address_space_memory, system_memory, memory);
  
  system_io = g_malloc(sizeof(*system_io));
  memory_region_init(system_io, io, 65536);
 -address_space_init(address_space_io, system_io);
 -address_space_io.name = I/O;
 +address_space_init(address_space_io, system_io, I/O);
  
  memory_listener_register(core_memory_listener, address_space_memory);
  memory_listener_register(io_memory_listener, address_space_io);
 diff --git a/hw/pci/pci.c b/hw/pci/pci.c
 index fe146dc..0a1acd6 100644
 --- a/hw/pci/pci.c
 +++ b/hw/pci/pci.c
 @@ -823,7 +823,8 @@ static PCIDevice *do_pci_register_device(PCIDevice 
 *pci_dev, PCIBus *bus,
  memory_region_init_alias(pci_dev-bus_master_enable_region, bus 
 master,
   pci_dev-iommu, 0, 
 memory_region_size(pci_dev-iommu));
  memory_region_set_enabled(pci_dev-bus_master_enable_region, false);
 -address_space_init(pci_dev-bus_master_as, 
 pci_dev-bus_master_enable_region);
 +address_space_init(pci_dev-bus_master_as, 
 pci_dev-bus_master_enable_region,
 +   name);
  
  pci_dev-devfn = devfn;
  pstrcpy(pci_dev-name, sizeof(pci_dev-name), name);
 diff --git a/hw/ppc/spapr_vio.c b/hw/ppc/spapr_vio.c
 index fbcbd6f..fadde20 100644
 --- a/hw/ppc/spapr_vio.c
 +++ b/hw/ppc/spapr_vio.c
 @@ -449,7 +449,7 @@ static int spapr_vio_busdev_init(DeviceState *qdev)
  if (pc-rtce_window_size) {
  uint32_t liobn = SPAPR_VIO_BASE_LIOBN | dev-reg;
  dev-tcet = spapr_tce_new_table(liobn, pc-rtce_window_size);
 -address_space_init(dev-as, spapr_tce_get_iommu(dev-tcet));
 +address_space_init(dev-as, spapr_tce_get_iommu(dev-tcet), 
 qdev-id);
  }
  
  return pc-init(dev);
 diff --git a/include/exec/memory.h b/include/exec/memory.h
 index 99d51b7..b4f1182 100644
 --- a/include/exec/memory.h
 +++ b/include/exec/memory.h
 @@ -840,7 +840,7 @@ void mtree_info(fprintf_function mon_printf, void *f);
   * @as: an uninitialized #AddressSpace
   * @root: a #MemoryRegion that routes addesses for the address space
   */
 -void address_space_init(AddressSpace *as, MemoryRegion *root);
 +void address_space_init(AddressSpace *as, MemoryRegion *root, const char 
 *name);
  
  
 
 Please update the doc comment.
 
  /**
 diff --git a/memory.c b/memory.c
 index cee3e59..b50f5e6 100644
 --- a/memory.c
 +++ b/memory.c
 @@ -1002,7 +1002,7 @@ void memory_region_init_iommu(MemoryRegion *mr,
  mr-terminates = true;  /* then re-forwards */
  mr-destructor = memory_region_destructor_iommu;
  mr-iommu_target_as = g_new(AddressSpace, 1);
 -address_space_init(mr-iommu_target_as, target);
 +address_space_init(mr-iommu_target_as, target, name);
  }
  
  static uint64_t invalid_read(void *opaque, hwaddr addr,
 @@ -1599,7 +1599,7 @@ void memory_listener_unregister(MemoryListener 
 *listener)
  QTAILQ_REMOVE(memory_listeners, listener, link);
  }
  
 -void address_space_init(AddressSpace *as, MemoryRegion *root)
 +void address_space_init(AddressSpace *as, MemoryRegion *root, const char 
 *name)
  {
  memory_region_transaction_begin();
  as-root = root;
 @@ -1608,7 +1608,7 @@ void address_space_init(AddressSpace *as, MemoryRegion 
 *root)
  as-ioeventfd_nb = 0;
  as-ioeventfds = NULL;
  QTAILQ_INSERT_TAIL(address_spaces, as, address_spaces_link);
 -as-name = NULL;
 +as-name = g_strdup(name?name:anonymous);
  address_space_init_dispatch(as);
  memory_region_update_pending |= root-enabled;
  memory_region_transaction_commit();
 @@ -1623,6 +1623,7 @@ void address_space_destroy(AddressSpace *as)
  

Re: [Qemu-devel] [RFC PATCH v5 05/14] net: port socket to GSource

2013-04-29 Thread Stefan Hajnoczi
On Sat, Apr 27, 2013 at 03:09:10PM +0800, liu ping fan wrote:
 On Fri, Apr 26, 2013 at 5:48 PM, Stefan Hajnoczi stefa...@redhat.com wrote:
  On Fri, Apr 26, 2013 at 10:47:26AM +0800, Liu Ping Fan wrote:
  @@ -141,6 +134,59 @@ static ssize_t 
  net_socket_receive_dgram(NetClientState *nc, const uint8_t *buf,
   return ret;
   }
 
  +static gushort socket_connecting_readable(void *opaque)
  +{
  +return G_IO_IN;
  +}
  +
  +static gushort socket_listen_readable(void *opaque)
  +{
  +/* listen only handle in-req, no err */
  +return G_IO_IN;
 
  From the accept(2) man page:
 
  Linux accept() (and accept4()) passes already-pending network errors on
  the new socket as an error code from accept().
 
  So we must handle errors from accept(2), please use G_IO_IN | G_IO_HUP |
  G_IO_ERR.
 
 Here, we handle listen(2), not accept(2)

Look again, the handler invokes accept(2).  listen(2) was called to put
the socket into the listening state but now we are monitoring for
accept.

  +static gushort socket_establish_readable(void *opaque)
  +{
  +NetSocketState *s = opaque;
  +
  +/* rely on net_socket_send to handle err */
  +if (s-read_poll  net_socket_can_send(s)) {
  +return G_IO_IN|G_IO_HUP|G_IO_ERR;
  +}
  +return G_IO_HUP|G_IO_ERR;
  +}
 
  This new function always monitors G_IO_HUP | G_IO_ERR.  The old code
  only monitored it when read_poll == true and net_socket_can_send() ==
  true.
 
  Please preserve semantics.
 
 But the only the code in net_socket_send() will handle the err
 condition. See the code behind /* end of connection */.  And I think
 it is safely to handle err, even when the peer is not ready to
 receive.
 
  +static gushort socket_establish_writable(void *opaque)
  +{
  +NetSocketState *s = opaque;
  +
  +if (s-write_poll) {
  +return G_IO_OUT;
 
  Errors/hang up?
 
 As explained above, net_socket_writable() does not handle the err
 condition. But maybe we need the qemu_flush_queued_packets() in it?

net_socket_receive() does handle send(2) errors but it does so
differently from net_socket_send().  It fails the packet and resets
-send_index.

The change you made doesn't really solve this because an error could
still happen right when QEMU calls send(2) and therefore not be
processed by net_socket_send().

Changing the send/receive error handling is something that could be done
carefully in a separate patch.  But please preserve semantics in
conversion patches - it makes them easy to review and merge.

As explained above, I'm not convinced that the change you made is
useful.

Stefan



Re: [Qemu-devel] SCSI CD-ROM hotplug problem

2013-04-29 Thread Paolo Bonzini
Il 25/04/2013 15:40, Liuji (Jeremy) ha scritto:
 Hello, everyone
 
 I have a question about hotplug of cd-rom.
 
 version of qemu: Apr-22-2013   bb71623811686ce3c34ce724f073f5c5dd95f51b
 
 1) start the vm:
 qemu-kvm -enable-kvm -m 1024 -smp 2 -boot c -drive 
 file=/home/vm/winxp.qcow2,if=none,id=drive0,format=qcow2 
 -device virtio-blk-pci,scsi=off,drive=drive0,id=disk0 -monitor stdio -vnc 
 186.100.8.136:1 
 -device lsi,id=scsi0,bus=pci.0
 
 2) use drive_add and device_add commands to hotplug a cd-rom:
 (qemu) drive_add 0 
 file=/home/vm/aaa.iso,if=none,id=my-cdrom-drive,readonly=on,format=raw
 (qemu) device_add 
 scsi-cd,bus=scsi0.0,scsi-id=2,drive=my-cdrom-drive,id=my-cdrom
 
 3) but I can't find the new cd-rom in the WindowXP vm.

This is because Windows has not rescanned the SCSI bus.  To force a
rescan, open a command prompt, then type diskpart and then rescan.

 4) and then, I use pci_add command to hotplug another cd-rom:
 (qemu) pci_add auto storage 
 file=/home/vm/bbb.iso,if=scsi,readonly=on,format=raw,media=cdrom

This works because it adds an entirely new SCSI controller.

 5) I not only found the second cd-rom, but also found first cd-rom in the 
 WindowXP vm.

This is probably some oddity of Windows, which forces a rescan of all
SCSI buses when a new controller is hot-plugged---or something like that.

Paolo



Re: [Qemu-devel] [PATCH] Makefile: Fix build breakage

2013-04-29 Thread Paolo Bonzini
Il 28/04/2013 20:04, Dunrong Huang ha scritto:
 The following error occurs when building dtc module:
 
   CHK version_gen.h
CC libfdt/fdt.o
 cc1: error: dtc: No such file or directory [-Werror]
 cc1: all warnings being treated as errors
 make[1]: *** [libfdt/fdt.o] Error 1
 make: *** [subdir-dtc] Error 2
 
 In rules.mak, -I$(D) -I$(@D) was expanded to -Idtc -I. when
 building submodule dct. Due to the using of -Wmissing-include-dirs,
 a warning would be rarsed. To avoid it, use dtc as the first prerequisite
 so that $(^D) was expanded to .
 
 Cc: Peter Crosthwaite peter.crosthwa...@xilinx.com
 Cc: Blue Swirl blauwir...@gmail.com
 Signed-off-by: Dunrong Huang riegama...@gmail.com
 ---
  Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/Makefile b/Makefile
 index 8aca92f..64b0b1b 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -148,7 +148,7 @@ $(SRC_PATH)/pixman/configure:
  DTC_MAKE_ARGS=-I$(SRC_PATH)/dtc VPATH=$(SRC_PATH)/dtc -C dtc V=$(V) 
 LIBFDT_srcdir=$(SRC_PATH)/dtc/libfdt
  DTC_CFLAGS=$(CFLAGS) $(QEMU_CFLAGS) -I$(BUILD_DIR)/dtc -I$(SRC_PATH)/dtc 
 -I$(SRC_PATH)/dtc/libfdt
  
 -subdir-dtc:dtc/libfdt dtc/tests
 +subdir-dtc:dtc dtc/libfdt dtc/tests
   $(call quiet-command,$(MAKE) $(DTC_MAKE_ARGS) CFLAGS=$(DTC_CFLAGS) 
 LDFLAGS=$(LDFLAGS) ARFLAGS=$(ARFLAGS) CC=$(CC) AR=$(AR) LD=$(LD) 
 $(SUBDIR_MAKEFLAGS) libfdt/libfdt.a,)
  
  dtc/%:
 

Does it work if the -I$(D) -I$(@D) is added to QEMU_INCLUDES instead
of QEMU_CFLAGS?

Paolo



Re: [Qemu-devel] about the usbredirect lib problem run under Windows

2013-04-29 Thread Hans de Goede

Hi,

On 04/28/2013 04:09 AM, zhou link wrote:

Hans de Goede   Gerd Hoffmann:


theses  days   i  try  to migrate the usbredir  lib to  Windows

the  usbredir-0.6/usbredirserver/usbredirserver.c  connect to qemu's redirect 
channel and spicec connect to the guest

the usbredirserver  works smooth in Linux,  spicec show the usb disk works well.


when i compile usbredir on Windows,  usbredirserver connect and open usb device 
ok,


usbredirserver is not supported under Windows. It may compile, but it won't 
work, as it
depends on select() for usb event handling and libusb does not support select 
under
windows.

Regards,

Hans



Re: [Qemu-devel] [PATCH for-1.5 v2 08/20] mc146818rtc: QOM'ify

2013-04-29 Thread Igor Mammedov
On Sat, 27 Apr 2013 22:18:43 +0200
Andreas Färber afaer...@suse.de wrote:

 Introduce type constant and cast macro to obsolete DO_UPCAST().
 
 Prepares for ISA realizefn.
 
 Signed-off-by: Andreas Färber afaer...@suse.de
 ---
  hw/timer/mc146818rtc.c | 36 
  include/hw/timer/mc146818rtc.h |  2 ++
  2 files changed, 22 insertions(+), 16 deletions(-)
 
 diff --git a/hw/timer/mc146818rtc.c b/hw/timer/mc146818rtc.c
 index 69e6844..afbd0db 100644
 --- a/hw/timer/mc146818rtc.c
 +++ b/hw/timer/mc146818rtc.c
 @@ -57,8 +57,11 @@
  #define RTC_CLOCK_RATE32768
  #define UIP_HOLD_LENGTH   (8 * NSEC_PER_SEC / 32768)
  
 +#define MC146818_RTC(obj) OBJECT_CHECK(RTCState, (obj), TYPE_MC146818_RTC)
 +
  typedef struct RTCState {
 -ISADevice dev;
 +ISADevice parent_obj;
 +
  MemoryRegion io;
  uint8_t cmos_data[128];
  uint8_t cmos_index;
 @@ -672,14 +675,14 @@ static uint64_t cmos_ioport_read(void *opaque, hwaddr 
 addr,
  
  void rtc_set_memory(ISADevice *dev, int addr, int val)
  {
 -RTCState *s = DO_UPCAST(RTCState, dev, dev);
 +RTCState *s = MC146818_RTC(dev);
  if (addr = 0  addr = 127)
  s-cmos_data[addr] = val;
  }
  
  static void rtc_set_date_from_host(ISADevice *dev)
  {
 -RTCState *s = DO_UPCAST(RTCState, dev, dev);
 +RTCState *s = MC146818_RTC(dev);
  struct tm tm;
  
  qemu_get_timedate(tm, 0);
 @@ -741,7 +744,7 @@ static void rtc_notify_clock_reset(Notifier *notifier, 
 void *data)
  RTCState *s = container_of(notifier, RTCState, clock_reset_notifier);
  int64_t now = *(int64_t *)data;
  
 -rtc_set_date_from_host(s-dev);
 +rtc_set_date_from_host(ISA_DEVICE(s));
  periodic_timer_update(s, now);
  check_update_timer(s);
  #ifdef TARGET_I386
 @@ -756,7 +759,7 @@ static void rtc_notify_clock_reset(Notifier *notifier, 
 void *data)
  static void rtc_notify_suspend(Notifier *notifier, void *data)
  {
  RTCState *s = container_of(notifier, RTCState, suspend_notifier);
 -rtc_set_memory(s-dev, 0xF, 0xFE);
 +rtc_set_memory(ISA_DEVICE(s), 0xF, 0xFE);
  }
  
  static void rtc_reset(void *opaque)
 @@ -789,8 +792,7 @@ static const MemoryRegionOps cmos_ops = {
  static void rtc_get_date(Object *obj, Visitor *v, void *opaque,
   const char *name, Error **errp)
  {
 -ISADevice *isa = ISA_DEVICE(obj);
 -RTCState *s = DO_UPCAST(RTCState, dev, isa);
 +RTCState *s = MC146818_RTC(obj);
  struct tm current_tm;
  
  rtc_update_time(s);
 @@ -807,7 +809,7 @@ static void rtc_get_date(Object *obj, Visitor *v, void 
 *opaque,
  
  static int rtc_initfn(ISADevice *dev)
  {
 -RTCState *s = DO_UPCAST(RTCState, dev, dev);
 +RTCState *s = MC146818_RTC(dev);
  int base = 0x70;
  
  s-cmos_data[RTC_REG_A] = 0x26;
 @@ -866,19 +868,21 @@ static int rtc_initfn(ISADevice *dev)
  
  ISADevice *rtc_init(ISABus *bus, int base_year, qemu_irq intercept_irq)
  {
 -ISADevice *dev;
 +DeviceState *dev;
 +ISADevice *isadev;
  RTCState *s;
  
 -dev = isa_create(bus, mc146818rtc);
 -s = DO_UPCAST(RTCState, dev, dev);
 -qdev_prop_set_int32(dev-qdev, base_year, base_year);
 -qdev_init_nofail(dev-qdev);
 +isadev = isa_create(bus, TYPE_MC146818_RTC);
 +dev = DEVICE(isadev);
 +s = MC146818_RTC(isadev);
 +qdev_prop_set_int32(dev, base_year, base_year);
 +qdev_init_nofail(dev);
  if (intercept_irq) {
  s-irq = intercept_irq;
  } else {
 -isa_init_irq(dev, s-irq, RTC_ISA_IRQ);
 +isa_init_irq(isadev, s-irq, RTC_ISA_IRQ);
  }
 -return dev;
 +return isadev;
  }
  
  static Property mc146818rtc_properties[] = {
 @@ -899,7 +903,7 @@ static void rtc_class_initfn(ObjectClass *klass, void 
 *data)
  }
  
  static const TypeInfo mc146818rtc_info = {
 -.name  = mc146818rtc,
 +.name  = TYPE_MC146818_RTC,
  .parent= TYPE_ISA_DEVICE,
  .instance_size = sizeof(RTCState),
  .class_init= rtc_class_initfn,
 diff --git a/include/hw/timer/mc146818rtc.h b/include/hw/timer/mc146818rtc.h
 index 854ea3f..425bd17 100644
 --- a/include/hw/timer/mc146818rtc.h
 +++ b/include/hw/timer/mc146818rtc.h
 @@ -4,6 +4,8 @@
  #include hw/isa/isa.h
  #include hw/timer/mc146818rtc_regs.h
  
 +#define TYPE_MC146818_RTC mc146818rtc
 +
  ISADevice *rtc_init(ISABus *bus, int base_year, qemu_irq intercept_irq);
  void rtc_set_memory(ISADevice *dev, int addr, int val);
  void rtc_set_date(ISADevice *dev, const struct tm *tm);
 -- 
 1.8.1.4
 
 
Reviewed-By: Igor Mammedov imamm...@redhat.com

-- 
Regards,
  Igor



Re: [Qemu-devel] [PATCH] memory: give name every AddressSpace

2013-04-29 Thread Paolo Bonzini
Il 29/04/2013 10:21, Alexey Kardashevskiy ha scritto:
  +g_free((void *)as-name);
  
  No cast here.
 ?
 
   CCppc64-softmmu/memory.o
 /home/alexey/pcipassthru/qemu-impreza/memory.c: In function
 'address_space_destroy':
 /home/alexey/pcipassthru/qemu-impreza/memory.c:1626:5: warning: passing
 argument 1 of 'g_free' discards 'const' qualifier from pointer target type
 [enabled by default]
  g_free(/*(void *)*/as-name);
  ^

Please remove the const from as-name instead.  Since you are strdup-ing
it, and the field is meant to be private to memory.c anyway, you do not
need protection against changing it.

Paolo



Re: [Qemu-devel] [PATCH 2/3] block: add block_backup QMP command

2013-04-29 Thread Paolo Bonzini
Il 29/04/2013 09:21, Stefan Hajnoczi ha scritto:
  I'd really love to see us change 'BlockJobInfo' to use an enum for
  'type', instead of its open-coded 'str'.  Likewise, the block-job
  related events in QMP/qmp-events.txt should be updated to refer to the
  enum instead of also being open-coded 'str'.
 
 Since the block job QMP API has been in released I'm not sure changing
 this is worthwhile.  QEMU and libvirt would have to maintain
 compatibility so the code will just be duplicated.

I don't think this would change the actual data on the wire.  However,
it would let libvirt know the supported block job types by introspecting
the enum.

Paolo



[Qemu-devel] KVM call agenda for 2013-04-30

2013-04-29 Thread Juan Quintela

Hi

Please send in any agenda topics you are interested in.

Later, Juan.



Re: [Qemu-devel] [PATCH 17/21] introduce memory_region_get_address() and use it in kvm/ioapic

2013-04-29 Thread Paolo Bonzini
Il 27/04/2013 22:57, Blue Swirl ha scritto:
 The questions are, in order of importance:

 (1) what privileges would this require in the guest?  Answer: a lot.

 (2) is this likely to happen by chance?  Answer: no, not at all.

 (3) is there a workaround?  Answer: yes, disable in-kernel irqchip.
 
 These questions ask if there is a risk of benevolent guests performing
 these activities and I agree that the chances are close to zero.
 
 But the interesting question is to ask if a malevolent guest can bring
 down a VM uncontrollably this way and I think it only needs a few
 elevated privileges in a guest to do this.

If you have them, isn't it simpler to just turn off the VM (using APM or
ACPI)?  Also, killing your guest is not a very interesting thing to do
once you've gotten elevated privileges. ;)

 Simply setting IO_APIC_DEFAULT_ADDRESS is also flawed in my opinion.
 I'm not sure the in-kernel irqchip handles correctly an overlap between
 the IOAPIC and LAPIC regions, maybe an abort is predictable after all.
 
 At least the guest needs to be stopped. Perhaps we should have a
 common function which does this and logs the guest error so we can
 start replacing calls to abort() with it.

Yes, that's a good idea.  We can reuse the internal error runstate for that.

Paolo




Re: [Qemu-devel] [PATCH 17/21] introduce memory_region_get_address() and use it in kvm/ioapic

2013-04-29 Thread Igor Mammedov
On Sat, 27 Apr 2013 20:57:26 +
Blue Swirl blauwir...@gmail.com wrote:

 On Sat, Apr 27, 2013 at 12:12 PM, Paolo Bonzini pbonz...@redhat.com wrote:
  Il 27/04/2013 12:09, Blue Swirl ha scritto:
  On Fri, Apr 26, 2013 at 10:13 PM, Paolo Bonzini pbonz...@redhat.com 
  wrote:
  Il 26/04/2013 19:46, Igor Mammedov ha scritto:
  But as the address can't be changed (yet), the entire patch could be 
  simply:
  -kioapic-base_address = s-busdev.mmio[0].addr;
  +kioapic-base_address = IO_APIC_DEFAULT_ADDRESS;
  It's a bit fragile, but that for sure simpler and can work.
 
  Jan, Paolo,
  Are you ok with this approach?
 
 
  I think extending memory_region_find is a good idea anyway, and at this
  point I don't see a reason to do the above change...
 
  The reasoning was in the part that Igor cut off:
 
  Later, when it's possible to change the address via PIIX3 registers,
  we can adjust the base and pass that properly to kioapic and on to
  KVM.
 
  Resolving the base address every time when kvm_ioapic_put() is called
  is also less efficient, assuming of course that the base address
  changes less often than the KVM ioctl is used.
 
  I think the patch is a bit flawed. If the guest maps something else on
  top of IOAPIC, like LAPIC (which should be in CPU specific address
  spaces, but for now it lives in the global system memory space), the
  guest could trigger the abort() by resetting the system.
 
  The questions are, in order of importance:
 
  (1) what privileges would this require in the guest?  Answer: a lot.
 
  (2) is this likely to happen by chance?  Answer: no, not at all.
 
  (3) is there a workaround?  Answer: yes, disable in-kernel irqchip.
 
 These questions ask if there is a risk of benevolent guests performing
 these activities and I agree that the chances are close to zero.
 
 But the interesting question is to ask if a malevolent guest can bring
 down a VM uncontrollably this way and I think it only needs a few
 elevated privileges in a guest to do this.
 
 The fix is to avoid abort(), which is a separate issue to whether the
 address base should be resolved for each KVM ioctl or not.
 
 
  Simply setting IO_APIC_DEFAULT_ADDRESS is also flawed in my opinion.
  I'm not sure the in-kernel irqchip handles correctly an overlap between
  the IOAPIC and LAPIC regions, maybe an abort is predictable after all.
 
 At least the guest needs to be stopped. Perhaps we should have a
 common function which does this and logs the guest error so we can
 start replacing calls to abort() with it.
 
 
  Paolo
 

It looks like discussion got deviated from what patch does to another issue.

this patch doesn't address/change the way how/when base_address should be
set/updated but it has it's benefits as well:
 - removes/cleanups access to private field of parent, which allows to convert
   it to non SysBusDevice
 - extended memory_region_find() opens venue for cleaning-up/re-factoring
   devices that use framebuffer which are forced currently to access
   system_address_space directly.
 

-- 
Regards,
  Igor



[Qemu-devel] [PULL 1.5 v6 0/4] fix win32 compilation

2013-04-29 Thread Paolo Bonzini
Here is a fix for the Win32 compilation problem that Blue reported,
and another two nits I found while testing.  After these patches, a
cross libtool is not needed anymore to build on Win32.

The following changes since commit 75f6e8b0f121b6a95eb9e35d88ec1f01824f:

  virtio-rng-s390: add properties. (2013-04-26 20:18:25 +0200)

are available in the git repository at:

  git://github.com/bonzini/qemu.git migration-writev

for you to fetch changes up to 9adea5f7f7a23ef4a1231289a36a94c52347b142:

  win32: add readv/writev emulation (2013-04-29 10:52:36 +0200)

v5-v6: just include config-host.h in osdep.h [Peter]


Paolo Bonzini (4):
  win32: add generic RC rules to rules.mak
  win32: move Makefile dependencies on version-obj-y to rules.mak
  win32: generate console executable again
  win32: add readv/writev emulation

 Makefile  |  5 +
 Makefile.target   |  2 +-
 include/qemu-common.h | 22 ++
 include/qemu/osdep.h  | 17 +
 rules.mak |  7 +++
 util/iov.c|  2 +-
 util/osdep.c  | 43 +++
 7 files changed, 72 insertions(+), 26 deletions(-)
-- 
1.8.2




[Qemu-devel] [PATCH 1/4] win32: add generic RC rules to rules.mak

2013-04-29 Thread Paolo Bonzini
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
 Makefile  | 2 --
 rules.mak | 4 
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 8aca92f..58e3527 100644
--- a/Makefile
+++ b/Makefile
@@ -167,9 +167,7 @@ recurse-all: $(SUBDIR_RULES) $(ROMSUBDIR_RULES)
 bt-host.o: QEMU_CFLAGS += $(BLUEZ_CFLAGS)
 
 version.o: $(SRC_PATH)/version.rc config-host.h | version.lo
-   $(call quiet-command,$(WINDRES) -I. -o $@ $,  RC$(TARGET_DIR)$@)
 version.lo: $(SRC_PATH)/version.rc config-host.h
-   $(call quiet-command,$(LIBTOOL) --mode=compile --tag=RC $(WINDRES) -I. 
-o $@ $,lt RC   $(TARGET_DIR)$@)
 
 version-obj-$(CONFIG_WIN32) += version.o
 version-lobj-$(CONFIG_WIN32) += $(if $(LIBTOOL),version.lo)
diff --git a/rules.mak b/rules.mak
index 292a422..279525d 100644
--- a/rules.mak
+++ b/rules.mak
@@ -19,6 +19,8 @@ QEMU_CFLAGS += -I$(D) -I$(@D)
 
 %.o: %.c
$(call quiet-command,$(CC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) 
$(QEMU_DGFLAGS) $(CFLAGS) -c -o $@ $,  CC$(TARGET_DIR)$@)
+%.o: %.rc
+   $(call quiet-command,$(WINDRES) -I. -o $@ $,  RC$(TARGET_DIR)$@)
 
 ifeq ($(LIBTOOL),)
 LIBTOOL = /bin/false
@@ -29,6 +31,8 @@ else
 LIBTOOL += $(if $(V),,--quiet)
 %.lo: %.c
$(call quiet-command,$(LIBTOOL) --mode=compile --tag=CC $(CC) 
$(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) -c -o $@ $,  lt CC 
$@)
+%.lo: %.rc
+   $(call quiet-command,$(LIBTOOL) --mode=compile --tag=RC $(WINDRES) -I. 
-o $@ $,lt RC   $(TARGET_DIR)$@)
 %.lo: %.dtrace
$(call quiet-command,$(LIBTOOL) --mode=compile --tag=CC dtrace -o $@ -G 
-s $,  lt GEN $(TARGET_DIR)$@)
 
-- 
1.8.2





[Qemu-devel] [PATCH 2/4] win32: move Makefile dependencies on version-obj-y to rules.mak

2013-04-29 Thread Paolo Bonzini
This makes the test on $(LIBTOOL) work.  Otherwise, LIBTOOL
is /bin/false by the time the test is done.

Fixes Win32 compilation without a working cross-libtool.

Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
 Makefile  | 3 +--
 rules.mak | 3 +++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 58e3527..f91f3b0 100644
--- a/Makefile
+++ b/Makefile
@@ -170,8 +170,7 @@ version.o: $(SRC_PATH)/version.rc config-host.h | version.lo
 version.lo: $(SRC_PATH)/version.rc config-host.h
 
 version-obj-$(CONFIG_WIN32) += version.o
-version-lobj-$(CONFIG_WIN32) += $(if $(LIBTOOL),version.lo)
-Makefile: $(version-obj-y) $(version-lobj-y)
+version-lobj-$(CONFIG_WIN32) += version.lo
 
 
 ##
diff --git a/rules.mak b/rules.mak
index 279525d..197a9d7 100644
--- a/rules.mak
+++ b/rules.mak
@@ -22,12 +22,15 @@ QEMU_CFLAGS += -I$(D) -I$(@D)
 %.o: %.rc
$(call quiet-command,$(WINDRES) -I. -o $@ $,  RC$(TARGET_DIR)$@)
 
+Makefile: $(version-obj-y)
+
 ifeq ($(LIBTOOL),)
 LIBTOOL = /bin/false
 LINK = $(call quiet-command,$(CC) $(QEMU_CFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ \
$(sort $(filter %.o, $1)) $(filter-out %.o, $1) $(version-obj-y) \
$(LIBS),  LINK  $(TARGET_DIR)$@)
 else
+Makefile: $(version-lobj-y)
 LIBTOOL += $(if $(V),,--quiet)
 %.lo: %.c
$(call quiet-command,$(LIBTOOL) --mode=compile --tag=CC $(CC) 
$(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) -c -o $@ $,  lt CC 
$@)
-- 
1.8.2





[Qemu-devel] [PATCH 3/4] win32: generate console executable again

2013-04-29 Thread Paolo Bonzini
The -mwindows option is not anymore in LIBS at this point of the Makefile,
it is only in libs_softmmu.  Check the right variable.

Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
 Makefile.target | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.target b/Makefile.target
index 7e4c77a..6583b05 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -18,7 +18,7 @@ ifdef CONFIG_USER_ONLY
 QEMU_PROG=qemu-$(TARGET_ARCH2)
 else
 # system emulator name
-ifneq (,$(findstring -mwindows,$(LIBS)))
+ifneq (,$(findstring -mwindows,$(libs_softmmu)))
 # Terminate program name with a 'w' because the linker builds a windows 
executable.
 QEMU_PROGW=qemu-system-$(TARGET_ARCH2)w$(EXESUF)
 endif # windows executable
-- 
1.8.2





[Qemu-devel] [PATCH 4/4] win32: add readv/writev emulation

2013-04-29 Thread Paolo Bonzini
Commit e9d8fbf (qemu-file: do not use stdio for qemu_fdopen, 2013-03-27)
introduced a usage of writev, which mingw32 does not have.  Even though
qemu_fdopen itself is not used on mingw32, the future-proof solution is
to add an implementation of it.  This is simple and similar to how we
emulate sendmsg/recvmsg in util/iov.c.

Some files include osdep.h without qemu-common.h, so move the definition
of iovec to osdep.h too, and include osdep.h from qemu-common.h
unconditionally (protection against including files when NEED_CPU_H is
defined is not needed since the removal of AREG0).

Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
 include/qemu-common.h | 22 ++
 include/qemu/osdep.h  | 17 +
 util/iov.c|  2 +-
 util/osdep.c  | 43 +++
 4 files changed, 63 insertions(+), 21 deletions(-)

diff --git a/include/qemu-common.h b/include/qemu-common.h
index a39cdba..b399d85 100644
--- a/include/qemu-common.h
+++ b/include/qemu-common.h
@@ -84,20 +84,6 @@
 # error Unknown pointer size
 #endif
 
-#ifndef CONFIG_IOVEC
-#define CONFIG_IOVEC
-struct iovec {
-void *iov_base;
-size_t iov_len;
-};
-/*
- * Use the same value as Linux for now.
- */
-#define IOV_MAX1024
-#else
-#include sys/uio.h
-#endif
-
 typedef int (*fprintf_function)(FILE *f, const char *fmt, ...)
 GCC_FMT_ATTR(2, 3);
 
@@ -122,16 +108,12 @@ static inline char *realpath(const char *path, char 
*resolved_path)
 void configure_icount(const char *option);
 extern int use_icount;
 
-/* FIXME: Remove NEED_CPU_H.  */
-#ifndef NEED_CPU_H
-
 #include qemu/osdep.h
 #include qemu/bswap.h
 
-#else
-
+/* FIXME: Remove NEED_CPU_H.  */
+#ifdef NEED_CPU_H
 #include cpu.h
-
 #endif /* !defined(NEED_CPU_H) */
 
 /* main function, renamed */
diff --git a/include/qemu/osdep.h b/include/qemu/osdep.h
index 8b465fd..42545bc 100644
--- a/include/qemu/osdep.h
+++ b/include/qemu/osdep.h
@@ -1,6 +1,7 @@
 #ifndef QEMU_OSDEP_H
 #define QEMU_OSDEP_H
 
+#include config-host.h
 #include stdarg.h
 #include stddef.h
 #include stdbool.h
@@ -161,6 +162,22 @@ int qemu_close(int fd);
 int qemu_create_pidfile(const char *filename);
 int qemu_get_thread_id(void);
 
+#ifndef CONFIG_IOVEC
+struct iovec {
+void *iov_base;
+size_t iov_len;
+};
+/*
+ * Use the same value as Linux for now.
+ */
+#define IOV_MAX 1024
+
+ssize_t readv(int fd, const struct iovec *iov, int iov_cnt);
+ssize_t writev(int fd, const struct iovec *iov, int iov_cnt);
+#else
+#include sys/uio.h
+#endif
+
 #ifdef _WIN32
 static inline void qemu_timersub(const struct timeval *val1,
  const struct timeval *val2,
diff --git a/util/iov.c b/util/iov.c
index d32226d..78bbbe1 100644
--- a/util/iov.c
+++ b/util/iov.c
@@ -99,7 +99,7 @@ size_t iov_size(const struct iovec *iov, const unsigned int 
iov_cnt)
 static ssize_t
 do_send_recv(int sockfd, struct iovec *iov, unsigned iov_cnt, bool do_send)
 {
-#if defined CONFIG_IOVEC  defined CONFIG_POSIX
+#ifdef CONFIG_POSIX
 ssize_t ret;
 struct msghdr msg;
 memset(msg, 0, sizeof(msg));
diff --git a/util/osdep.c b/util/osdep.c
index 6ae5aaf..685c8ae 100644
--- a/util/osdep.c
+++ b/util/osdep.c
@@ -429,3 +429,46 @@ int socket_init(void)
 #endif
 return 0;
 }
+
+#ifndef CONFIG_IOVEC
+/* helper function for iov_send_recv() */
+static ssize_t
+readv_writev(int fd, const struct iovec *iov, int iov_cnt, bool do_write)
+{
+unsigned i = 0;
+ssize_t ret = 0;
+while (i  iov_cnt) {
+ssize_t r = do_write
+? write(fd, iov[i].iov_base, iov[i].iov_len)
+: read(fd, iov[i].iov_base, iov[i].iov_len);
+if (r  0) {
+ret += r;
+} else if (!r) {
+break;
+} else if (errno == EINTR) {
+continue;
+} else {
+/* else it is some other error,
+ * only return if there was no data processed. */
+if (ret == 0) {
+ret = -1;
+}
+break;
+}
+i++;
+}
+return ret;
+}
+
+ssize_t
+readv(int fd, const struct iovec *iov, int iov_cnt)
+{
+return readv_writev(fd, iov, iov_cnt, false);
+}
+
+ssize_t
+writev(int fd, const struct iovec *iov, int iov_cnt)
+{
+return readv_writev(fd, iov, iov_cnt, true);
+}
+#endif
-- 
1.8.2




Re: [Qemu-devel] [PATCH prep for-1.5] prep: Add ELF support for -bios

2013-04-29 Thread Fabien Chouteau
On 04/28/2013 12:16 PM, Andreas Färber wrote:
 Am 28.04.2013 11:44, schrieb Alexander Graf:

 On 28.04.2013, at 02:32, Andreas Färber wrote:

 This prepares for switching from OpenHack'Ware to OpenBIOS.

 Signed-off-by: Andreas Färber andreas.faer...@web.de
 ---
 hw/ppc/prep.c | 21 +
 1 file changed, 13 insertions(+), 8 deletions(-)

 diff --git a/hw/ppc/prep.c b/hw/ppc/prep.c
 index cceab3e..9bb0119 100644
 --- a/hw/ppc/prep.c
 +++ b/hw/ppc/prep.c
 @@ -41,6 +41,7 @@
 #include sysemu/blockdev.h
 #include sysemu/arch_init.h
 #include exec/address-spaces.h
 +#include elf.h

 //#define HARD_DEBUG_PPC_IO
 //#define DEBUG_PPC_IO
 @@ -502,18 +503,22 @@ static void ppc_prep_init(QEMUMachineInitArgs *args)
 bios_name = BIOS_FILENAME;
 filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
 if (filename) {
 -bios_size = get_image_size(filename);
 +bios_size = load_elf(filename, NULL, NULL, NULL,
 + NULL, NULL, 1, ELF_MACHINE, 0);

 This leaves bios_addr unset, no?
 
 bios_addr is not yet defined in this scope and doesn't seem needed here?
 It's been a while that I wrote this (extracted it from a larger patch
 since Fabien had a need for ELF support), thought I copied this from one
 of the other ppc machines at the time...

Thanks Andreas, that will be very useful.

-- 
Fabien Chouteau



Re: [Qemu-devel] dec.c - move to pci-bridge

2013-04-29 Thread Andreas Färber
Am 29.04.2013 10:10, schrieb Michael S. Tsirkin:
 Looks like dec.c is in pci-host by mistake.
 I'll move it over to pci-bridge if not one
 complains.

+1, matches my understanding from mac_newworld refactoring attempts.

Also I noticed that firmware_abi.h with structs for OpenBIOS landed in
hw/sparc/ - suggest hw/nvram/ alongside fw_cfg.h. In addition to sparc
it's included from ppc mac_nvram.c and will need to include it from
prep.c in the future.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] [PATCH 1/6] kvm: add kvm_readonly_mem_enabled

2013-04-29 Thread Jan Kiszka
On 2013-04-28 10:32, Jordan Justen wrote:
 Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
 ---
  include/sysemu/kvm.h |   10 ++
  kvm-all.c|6 ++
  kvm-stub.c   |1 +
  3 files changed, 17 insertions(+)
 
 diff --git a/include/sysemu/kvm.h b/include/sysemu/kvm.h
 index 75bd7d9..c83f51c 100644
 --- a/include/sysemu/kvm.h
 +++ b/include/sysemu/kvm.h
 @@ -45,6 +45,7 @@ extern bool kvm_async_interrupts_allowed;
  extern bool kvm_irqfds_allowed;
  extern bool kvm_msi_via_irqfd_allowed;
  extern bool kvm_gsi_routing_allowed;
 +extern bool kvm_readonly_mem_allowed;
  
  #if defined CONFIG_KVM || !defined NEED_CPU_H
  #define kvm_enabled()   (kvm_allowed)
 @@ -97,6 +98,14 @@ extern bool kvm_gsi_routing_allowed;
   */
  #define kvm_gsi_routing_enabled() (kvm_gsi_routing_allowed)
  
 +/**
 + * kvm_readonly_mem_enabled:
 + *
 + * Returns: true if KVM readonly memory is enabled (ie the kernel
 + * supports it and we're running in a configuration that permits it).
 + */
 +#define kvm_readonly_mem_enabled() (kvm_readonly_mem_allowed)
 +
  #else
  #define kvm_enabled()   (0)
  #define kvm_irqchip_in_kernel() (false)
 @@ -104,6 +113,7 @@ extern bool kvm_gsi_routing_allowed;
  #define kvm_irqfds_enabled() (false)
  #define kvm_msi_via_irqfd_enabled() (false)
  #define kvm_gsi_routing_allowed() (false)
 +#define kvm_readonly_mem_enabled() (false)
  #endif
  
  struct kvm_run;
 diff --git a/kvm-all.c b/kvm-all.c
 index 2d92721..f634c41 100644
 --- a/kvm-all.c
 +++ b/kvm-all.c
 @@ -109,6 +109,7 @@ bool kvm_async_interrupts_allowed;
  bool kvm_irqfds_allowed;
  bool kvm_msi_via_irqfd_allowed;
  bool kvm_gsi_routing_allowed;
 +bool kvm_readonly_mem_allowed;
  
  static const KVMCapabilityInfo kvm_required_capabilites[] = {
  KVM_CAP_INFO(USER_MEMORY),
 @@ -1423,6 +1424,11 @@ int kvm_init(void)
  s-irq_set_ioctl = KVM_IRQ_LINE_STATUS;
  }
  
 +#ifdef KVM_CAP_READONLY_MEM

Grr, someone needlessly defined the cap value conditionally in the
kernel header. Could you fix that, pull in updated headers, and avoid
the #ifdef here? Can be a follow-up to this series.

Thanks,
Jan

 +kvm_readonly_mem_allowed =
 +(kvm_check_extension(s, KVM_CAP_READONLY_MEM)  0);
 +#endif
 +
  ret = kvm_arch_init(s);
  if (ret  0) {
  goto err;
 diff --git a/kvm-stub.c b/kvm-stub.c
 index 5f52186..40dc368 100644
 --- a/kvm-stub.c
 +++ b/kvm-stub.c
 @@ -22,6 +22,7 @@ bool kvm_async_interrupts_allowed;
  bool kvm_irqfds_allowed;
  bool kvm_msi_via_irqfd_allowed;
  bool kvm_gsi_routing_allowed;
 +bool kvm_readonly_mem_allowed;
  
  int kvm_init_vcpu(CPUState *cpu)
  {
 

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux




Re: [Qemu-devel] [PATCH 3/6] kvm: workaround a possible KVM bug when using KVM_MEM_READONLY

2013-04-29 Thread Jan Kiszka
On 2013-04-28 10:32, Jordan Justen wrote:
 On a Linux 3.8.0 based kernel, I occasionally saw a situation
 where the memory region would continue to trap on memory
 read even though KVM_MEM_READONLY was set.

Only 3.8.0? Did you bisect the issue down to the causing commit? Is it
fixed in later versions?

Jan

 
 I found that if I set the slot to a size of 0, and before
 setting the slot, it would then behave as expected.
 
 Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
 Cc: Xiao Guangrong xiaoguangr...@linux.vnet.ibm.com
 ---
  kvm-all.c |7 +++
  1 file changed, 7 insertions(+)
 
 diff --git a/kvm-all.c b/kvm-all.c
 index 95e6bf2..e2ddbcb 100644
 --- a/kvm-all.c
 +++ b/kvm-all.c
 @@ -205,6 +205,13 @@ static int kvm_set_user_memory_region(KVMState *s, 
 KVMSlot *slot)
  if (s-migration_log) {
  mem.flags |= KVM_MEM_LOG_DIRTY_PAGES;
  }
 +if (mem.flags  KVM_MEM_READONLY  mem.memory_size != 0) {
 +/* Workaround an issue with setting a READONLY slot. Set the
 + * slot size to 0 before setting the slot to the desired value. */
 +mem.memory_size = 0;
 +kvm_vm_ioctl(s, KVM_SET_USER_MEMORY_REGION, mem);
 +mem.memory_size = slot-memory_size;
 +}
  return kvm_vm_ioctl(s, KVM_SET_USER_MEMORY_REGION, mem);
  }
  
 
-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux




Re: [Qemu-devel] [PATCH RFC qom-cpu-next] apic: QOM'ify APICCommonState casts

2013-04-29 Thread Igor Mammedov
On Sun, 28 Apr 2013 13:22:10 +0200
Andreas Färber afaer...@suse.de wrote:

 Necessary to change the name of ICCDevice's parent object field.
 
 Signed-off-by: Andreas Färber afaer...@suse.de
 ---
  Could any of the APIC experts please review whether I'm touching any hot 
 path?
  Not sure if this was a mix of pre- and post-QOM code or intentional... 
 Thanks.
 
  hw/i386/kvm/apic.c   |  4 ++--
  hw/intc/apic.c   | 20 +++-
  hw/intc/apic_common.c| 10 +-
  include/hw/cpu/icc_bus.h |  2 +-
  4 files changed, 19 insertions(+), 17 deletions(-)
 
[...]
  
 diff --git a/include/hw/cpu/icc_bus.h b/include/hw/cpu/icc_bus.h
 index b550070..f2c8a50 100644
 --- a/include/hw/cpu/icc_bus.h
 +++ b/include/hw/cpu/icc_bus.h
 @@ -51,7 +51,7 @@ typedef struct ICCBus {
   */
  typedef struct ICCDevice {
  /* private */
 -DeviceState qdev;
 +DeviceState parent_obj;
This hunk doesn't apply to qpm-cpu-next.
It looks like it's accidentally crept in 
https://github.com/afaerber/qemu-cpu/commit/a7ae7cd073cc2b20de3372edc84ec5a01e88e55d


  /* public */
  } ICCDevice;
  
 -- 
 1.8.1.4
 
 

-- 
Regards,
  Igor



Re: [Qemu-devel] SoftFloat licensing in Linux kernel

2013-04-29 Thread Peter Maydell
On 11 April 2013 07:49, Stefan Hajnoczi stefa...@gmail.com wrote:
 http://lwn.net/Articles/546840/

 QEMU uses the John Hauser's SoftFloat library.  It seems the matter
 isn't settled yet in Linux but the FSF says the license is
 incompatible with GPLv2.

So the resolution determined for the kernel is that they actually
took the softfloat code at a version before the indemnification
clause appeared in upstream-softfloat's license:
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163904.html

Given that that change only happened ~2010 it seems pretty
likely that QEMU's softfloat code also predates it; has
anybody done the necessary digging in our version control
history to confirm?

thanks
-- PMM



Re: [Qemu-devel] [PATCH 05/30] PPC: fix hreset_vector for 60x, 7x0, 7x5, G2, MPC8xx, MPC5xx, 7400 and 7450

2013-04-29 Thread Fabien Chouteau
On 04/28/2013 03:59 PM, Andreas Färber wrote:
 Am 26.04.2013 20:21, schrieb Alexander Graf:
 From: Fabien Chouteau chout...@adacore.com

 According to the different user's manuals, the vector offset for system
 reset (both /HRESET and /SRESET) is 0x00100.

 This patch may break support of some executables, as the power-on start
 address may change. For a specific board, if the power-on start address
 is different than HRESET vector (i.e. 0x0100 or 0xfff00100), this
 should be fixed in board's initialization code.

 Signed-off-by: Fabien Chouteau chout...@adacore.com
 Signed-off-by: Alexander Graf ag...@suse.de
 
 According to git-bisect, this commit broke the prep machine (602).
 Symptoms are a black screen with no VGA output from OHW or kernel.
 
 Please suggest a fix.
 

Can you hand me the binaries so I can try to fix this?

-- 
Fabien Chouteau



Re: [Qemu-devel] [PATCH v2 2/2] Add AT24Cxx I2C EEPROM device model

2013-04-29 Thread Jan Kiszka
On 2013-02-23 14:40, Andreas Färber wrote:
 +static int at24_init(I2CSlave *i2c)
 
 hw/i2c.c:i2c_slave_qdev_init() calls I2CSlaveClass::init only, so please
 use a realize function instead. Cf. hw/qdev-core.h.
 
 +{
 +AT24State *s = DO_UPCAST(AT24State, i2c, i2c);
 +unsigned int page_size;
 +int64_t image_size;
 +int device_bits;
 +int hi_addr_bits;
 +int dev_no;
 +
 +assert(AT24_MAX_PAGE_LEN = BDRV_SECTOR_SIZE);
 
 This should instead do error_setg(errp, ...) then.

I just noticed with my latest code that the messages set via error_setg
do not make it to the terminal when initializing the device from the
command line. Known issue?

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux



Re: [Qemu-devel] SoftFloat licensing in Linux kernel

2013-04-29 Thread Peter Maydell
On 29 April 2013 11:37, Peter Maydell peter.mayd...@linaro.org wrote:
 On 11 April 2013 07:49, Stefan Hajnoczi stefa...@gmail.com wrote:
 QEMU uses the John Hauser's SoftFloat library.  It seems the matter
 isn't settled yet in Linux but the FSF says the license is
 incompatible with GPLv2.

 So the resolution determined for the kernel is that they actually
 took the softfloat code at a version before the indemnification
 clause appeared in upstream-softfloat's license:
 http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163904.html

 Given that that change only happened ~2010 it seems pretty
 likely that QEMU's softfloat code also predates it; has
 anybody done the necessary digging in our version control
 history to confirm?

...rats, looks like (a) the license change was earlier, at
the upstream version 2-2b boundary and (b) QEMU's softfloat
is based on 2b, not 2 (as the kernel's is.)

-- PMM



Re: [Qemu-devel] [PATCH 3/4] vfio: Move container list to iommu MemoryRegion

2013-04-29 Thread David Gibson
On Mon, Apr 29, 2013 at 10:11:06AM +0200, Paolo Bonzini wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Il 28/04/2013 03:58, David Gibson ha scritto:
  Ok, knowing about changes that happen in the IOMMU mapping is
  indeed out of scope of MemoryListeners.  What about adding a
  NotifierList? Then VFIO can register a notifier and use it to
  learn about events in the IOMMU mapping.  The notifier data
  can be a MemoryRegionSection or IOMMUTableEntry, whatever you
  find more convenient.
  For the generic case a Notifier could work in principle.  Neither
  of those structures is suitable as the data though: constructing a 
  MemoryRegionSection for every page we map into the IOTLB is far
  too heavyweight, and the IOMMUTLBEntry doesn't contain the IOVA.
 
 It did in Avi's patch set.  I removed it because it was unused.  I can
 add it back if you need it.

Ok, I think I will need it.

  Thinking over, I think what that mostly amounts to, is that if the 
  VFIO aspects of the address space are already wired up by the host 
  bridge, then the individual vfio-pci devices need a way of going
  from their qemu iommu address space (which they get from
  pci_dev-iommu) to the vfio specific information about that address
  space.
 
 That can be done with just a hash table, no?

Well, yes it can.  But I think that having a whole parallel lookup
structure within vfio is a worse ugliness than having a single opaque
vfio pointer in the MemoryRegion strcuture.

It does also require making sure the lifetime handling is correct.
The entry from the hash table must be removed before the corresponding
MemoryRegion is free()ed; otherwise we could end up using the same
pointer for a newly constructed MemoryRegion, and get a false lookup
in the hash.  Whether that happens essentially never, or almost
immediately in practice depends on the malloc() implementation, of
course.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: Digital signature


Re: [Qemu-devel] [PATCH] mainloop.c: Keep unlocking BQL during busy-wait spin-out

2013-04-29 Thread Peter Lieven


On 21.04.2013 16:21, Peter Crosthwaite wrote:

Hi Peter,

On Fri, Apr 19, 2013 at 5:01 PM, Peter Lieven lieven-li...@dlhnet.de wrote:

On 18.04.2013 16:35, Peter Crosthwaite wrote:

Hi Peter,

On Fri, Apr 19, 2013 at 12:22 AM, Peter Lieven lieven-li...@dlhnet.de
wrote:

On 15.04.2013 15:08, Anthony Liguori wrote:

Peter Crosthwaite peter.crosthwa...@xilinx.com writes:


Modify Anthony's starvation detection logic to keep the BQL unlocked
until the starvation condition goes away. Otherwise the counter has to
count up to 1000 for each needed iteration until the busy-wait is
lifted.

Reset the counter back to zero once glib_pollfds_fill returns with a
non-zero timout, (indicating a return to normality). The 1000 iteration
wait now only happens once on the transition from normal operation to
busy-wait starvation.

Anthony's original patch fixed the serial paste bug, but this patch is
also needed to restore performance.

Signed-off-by: Peter Crosthwaite peter.crosthwa...@xilinx.com

I'm going through patches for 1.5 candidates.

I believe the paste performance issue has been resolved now and this
patch is no longer needed.  I can't find a definitive statement on the
list for that though.


I am also hitting a problem that occured first after Anthonys original
patch.
In my testing environment I had 3 vServers that indepently of the load
became
heavily unresponsive after reporting main-loop: WARNING: I/O thread spun
for 1000 iterations.
Even QMP is not responsing from time to time. But I am not using serial.
  From the load statistics
it seems that the vServers is using one complete core busy waiting.

I haven't seen this before this patch.

Are you referring to my patch or Anthonys patch here? Does this patch
introduce a regression (or even a change in behaviour) for you?

I only noticed that after Anthonys patch (or at that time) I got

Can you re-confirm with a quick test? bisect could work, or more
quickly a straight up git-revert of Anthonys patch ontop of whatever
your are currently building to see if it makes any difference. Also
try applying this patch. See if it clears up your issue as this patch
is designed to improve performance in the spin-out case.



With your patch I have not seen this unresponsiveness again.

Peter




Re: [Qemu-devel] [PATCH RFC qom-cpu-next] apic: QOM'ify APICCommonState casts

2013-04-29 Thread Andreas Färber
Am 29.04.2013 12:29, schrieb Igor Mammedov:
 On Sun, 28 Apr 2013 13:22:10 +0200
 Andreas Färber afaer...@suse.de wrote:
 
 Necessary to change the name of ICCDevice's parent object field.

 Signed-off-by: Andreas Färber afaer...@suse.de
 ---
  Could any of the APIC experts please review whether I'm touching any hot 
 path?
  Not sure if this was a mix of pre- and post-QOM code or intentional... 
 Thanks.

  hw/i386/kvm/apic.c   |  4 ++--
  hw/intc/apic.c   | 20 +++-
  hw/intc/apic_common.c| 10 +-
  include/hw/cpu/icc_bus.h |  2 +-
  4 files changed, 19 insertions(+), 17 deletions(-)

 [...]
  
 diff --git a/include/hw/cpu/icc_bus.h b/include/hw/cpu/icc_bus.h
 index b550070..f2c8a50 100644
 --- a/include/hw/cpu/icc_bus.h
 +++ b/include/hw/cpu/icc_bus.h
 @@ -51,7 +51,7 @@ typedef struct ICCBus {
   */
  typedef struct ICCDevice {
  /* private */
 -DeviceState qdev;
 +DeviceState parent_obj;
 This hunk doesn't apply to qpm-cpu-next.
 It looks like it's accidentally crept in 
 https://github.com/afaerber/qemu-cpu/commit/a7ae7cd073cc2b20de3372edc84ec5a01e88e55d

Yeah, sorry, forgot to push latest qom-cpu-next (but today that includes
preliminary APIC QOM'ification not yet ready for qom-cpu).

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] [PATCH 05/30] PPC: fix hreset_vector for 60x, 7x0, 7x5, G2, MPC8xx, MPC5xx, 7400 and 7450

2013-04-29 Thread Andreas Färber
Am 29.04.2013 12:38, schrieb Fabien Chouteau:
 On 04/28/2013 03:59 PM, Andreas Färber wrote:
 Am 26.04.2013 20:21, schrieb Alexander Graf:
 From: Fabien Chouteau chout...@adacore.com

 According to the different user's manuals, the vector offset for system
 reset (both /HRESET and /SRESET) is 0x00100.

 This patch may break support of some executables, as the power-on start
 address may change. For a specific board, if the power-on start address
 is different than HRESET vector (i.e. 0x0100 or 0xfff00100), this
 should be fixed in board's initialization code.

 Signed-off-by: Fabien Chouteau chout...@adacore.com
 Signed-off-by: Alexander Graf ag...@suse.de

 According to git-bisect, this commit broke the prep machine (602).
 Symptoms are a black screen with no VGA output from OHW or kernel.

 Please suggest a fix.

 
 Can you hand me the binaries so I can try to fix this?

The old ppc_rom.bin is still in qemu.git, so this should suffice:

./ppc-softmmu/qemu-system-ppc -M prep

Problem is, we can't really recompile that binary with changes - and to
switch to OpenBIOS after 1.5 to get rid of it, I need to test that my
incremental patches don't break anything. ;)

Andreas



Re: [Qemu-devel] [PATCH 3/4] vfio: Move container list to iommu MemoryRegion

2013-04-29 Thread Paolo Bonzini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 29/04/2013 13:00, David Gibson ha scritto:
 On Mon, Apr 29, 2013 at 10:11:06AM +0200, Paolo Bonzini wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
 
 Il 28/04/2013 03:58, David Gibson ha scritto:
 Ok, knowing about changes that happen in the IOMMU mapping
 is indeed out of scope of MemoryListeners.  What about
 adding a NotifierList? Then VFIO can register a notifier
 and use it to learn about events in the IOMMU mapping.
 The notifier data can be a MemoryRegionSection or
 IOMMUTableEntry, whatever you find more convenient.
 For the generic case a Notifier could work in principle.
 Neither of those structures is suitable as the data though:
 constructing a MemoryRegionSection for every page we map into
 the IOTLB is far too heavyweight, and the IOMMUTLBEntry doesn't
 contain the IOVA.
 
 It did in Avi's patch set.  I removed it because it was unused.
 I can add it back if you need it.
 
 Ok, I think I will need it.

Let me know. :)

 Thinking over, I think what that mostly amounts to, is that if
 the VFIO aspects of the address space are already wired up by
 the host bridge, then the individual vfio-pci devices need a
 way of going from their qemu iommu address space (which they
 get from pci_dev-iommu) to the vfio specific information about
 that address space.
 
 That can be done with just a hash table, no?
 
 Well, yes it can.  But I think that having a whole parallel lookup 
 structure within vfio is a worse ugliness than having a single
 opaque vfio pointer in the MemoryRegion strcuture.

Why should VFIO be any special in this?  It is reassuring to me that
the VFIO maintainer thinks the same. :)

 It does also require making sure the lifetime handling is correct. 
 The entry from the hash table must be removed before the
 corresponding MemoryRegion is free()ed; otherwise we could end up
 using the same pointer for a newly constructed MemoryRegion, and
 get a false lookup in the hash.  Whether that happens essentially
 never, or almost immediately in practice depends on the malloc()
 implementation, of course.

There is only one MemoryRegion per PCI host bridge, and the PCI host
bridge cannot disappear before the VFIO devices on it are torn down.
So the lifetime should not be a problem.

Paolo

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRflueAAoJEBvWZb6bTYbybdkP/A5jrip69S4OB6XyDen7GkFy
YdX1SSs23zrVJ/PjrSqGCw4caXUecqp4b+49NCMFOF9Sy7ypvPWZvR84qpSRnFD9
oXYBpKZ3HPI0j0i/Ga84Lhz0ylyhfjTBel2jpAlJJq+odjdaHBttrQbWJIOCikMD
/mPStcU3FoQRp8KysIv0rro56IR9L0sAz7MuuJT0to7NfZHC1HrwrwJJYanB3hGN
OTTYUwRf+l9jZv5JgqanK2YcyDo0j43bvri03rdiKpJ0bj8BCQqxVOhg5TjtK3P6
EK2ABspt/q2LKWkfiC6xeudQoqcdjq2CfjqM5zqFuYExbh80MlTo5/I9hGF3zebw
naCD4qxrV/KwcrbCEqU+ieAvY1rj0ALcdSizBDPp+zemF2QzS87uXS1wjYPIvFar
oMuKnPAuAqwu7+g6uIqOFc24AIPiLwoJbnSAkiZ89wSqySKIbQj7vYJYoodxPidC
rZUr0VmspAKTfaW6lsb08KiepFaj4jySpB6bgS++hZZtPPgZ7ApUc8Yr2oZlrw8r
N+IDwPDigvFOMNSCej2YyIfZfi1CvkG/sJacCF3z+uHPIjwAu5Fy3s/gM7f27WXW
k0Dfak5l/i8QPWD6kZly6meoc+vTwiOVfKZPhLowrFG+C6G36LRuSiaDvHzS5vvM
6rar2khtc7sB+20wWDSD
=bzBg
-END PGP SIGNATURE-



Re: [Qemu-devel] [PATCH RFC 2/3] acpi: load and link tables from /etc/acpi/

2013-04-29 Thread Laszlo Ersek
Not sure how much it counts, but I personally can agree with you on this
direction :)

One note below:

 @@ -603,8 +604,72 @@ acpi_setup(void)
  if (! CONFIG_ACPI)
  return;
  
 +int acpi_generate = 1;
 +
  dprintf(3, init ACPI tables\n);
  
 +struct romfile_s *file = NULL;
 +for (;;) {
 +file = romfile_findprefix(/etc/acpi/, file);
 +if (!file)
 +break;
 +
 +/*
 + * Disable ACPI table generation. All ACPI tables must come from
 + * etc/acpi/ romfile entries.
 + */
 +acpi_generate = 0;
 +

[...]

 +}
 +
 +linker_link(/etc/linker-script);
 +
 +if (!acpi_generate) {
 +return;
 +}
 +
 +dprintf(3, generate ACPI tables\n);
 +
  // This code is hardcoded for PIIX4 Power Management device.
  struct pci_device *pci = pci_find_init_device(acpi_find_tbl, NULL);
  if (!pci)

Are you deliberately calling linker_link() independently from
acpi_generate? My hunch is that linker_link() only makes sense if
acpi_generate == 0 (ie. qemu has passed down at least one table to
repoint some pointer to), but I may be missing a use case.

Thanks
Laszlo



Re: [Qemu-devel] dec.c - move to pci-bridge

2013-04-29 Thread Paolo Bonzini
Il 29/04/2013 12:17, Andreas Färber ha scritto:
  Looks like dec.c is in pci-host by mistake.
  I'll move it over to pci-bridge if not one
  complains.
 +1, matches my understanding from mac_newworld refactoring attempts.
 
 Also I noticed that firmware_abi.h with structs for OpenBIOS landed in
 hw/sparc/ - suggest hw/nvram/ alongside fw_cfg.h. In addition to sparc
 it's included from ppc mac_nvram.c and will need to include it from
 prep.c in the future.

Makes sense.

Paolo



Re: [Qemu-devel] [PATCH] memory: give name every AddressSpace

2013-04-29 Thread David Gibson
On Mon, Apr 29, 2013 at 11:25:16AM +0200, Paolo Bonzini wrote:
 Il 29/04/2013 10:21, Alexey Kardashevskiy ha scritto:
   +g_free((void *)as-name);
   
   No cast here.
  ?
  
CCppc64-softmmu/memory.o
  /home/alexey/pcipassthru/qemu-impreza/memory.c: In function
  'address_space_destroy':
  /home/alexey/pcipassthru/qemu-impreza/memory.c:1626:5: warning: passing
  argument 1 of 'g_free' discards 'const' qualifier from pointer target type
  [enabled by default]
   g_free(/*(void *)*/as-name);
   ^
 
 Please remove the const from as-name instead.  Since you are strdup-ing
 it, and the field is meant to be private to memory.c anyway, you do not
 need protection against changing it.

As a general rule, pointer variables that you malloc()ate should not
be const.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: Digital signature


Re: [Qemu-devel] [PATCH 3/4] vfio: Move container list to iommu MemoryRegion

2013-04-29 Thread David Gibson
On Mon, Apr 29, 2013 at 01:38:06PM +0200, Paolo Bonzini wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Il 29/04/2013 13:00, David Gibson ha scritto:
  On Mon, Apr 29, 2013 at 10:11:06AM +0200, Paolo Bonzini wrote:
  -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
  
  Il 28/04/2013 03:58, David Gibson ha scritto:
  Ok, knowing about changes that happen in the IOMMU mapping
  is indeed out of scope of MemoryListeners.  What about
  adding a NotifierList? Then VFIO can register a notifier
  and use it to learn about events in the IOMMU mapping.
  The notifier data can be a MemoryRegionSection or
  IOMMUTableEntry, whatever you find more convenient.
  For the generic case a Notifier could work in principle.
  Neither of those structures is suitable as the data though:
  constructing a MemoryRegionSection for every page we map into
  the IOTLB is far too heavyweight, and the IOMMUTLBEntry doesn't
  contain the IOVA.
  
  It did in Avi's patch set.  I removed it because it was unused.
  I can add it back if you need it.
  
  Ok, I think I will need it.
 
 Let me know. :)
 
  Thinking over, I think what that mostly amounts to, is that if
  the VFIO aspects of the address space are already wired up by
  the host bridge, then the individual vfio-pci devices need a
  way of going from their qemu iommu address space (which they
  get from pci_dev-iommu) to the vfio specific information about
  that address space.
  
  That can be done with just a hash table, no?
  
  Well, yes it can.  But I think that having a whole parallel lookup 
  structure within vfio is a worse ugliness than having a single
  opaque vfio pointer in the MemoryRegion strcuture.
 
 Why should VFIO be any special in this?  It is reassuring to me that
 the VFIO maintainer thinks the same. :)

Because device passthrough is a sufficiently special case, IMO.  It
introduces requirements that are fundamentally different from any
emulated device.

  It does also require making sure the lifetime handling is correct. 
  The entry from the hash table must be removed before the
  corresponding MemoryRegion is free()ed; otherwise we could end up
  using the same pointer for a newly constructed MemoryRegion, and
  get a false lookup in the hash.  Whether that happens essentially
  never, or almost immediately in practice depends on the malloc()
  implementation, of course.
 
 There is only one MemoryRegion per PCI host bridge, and the PCI host

That's true for existing examples, but it need not be true.  For
example the Intel IOMMU supports multiple iommu domains which are
different address spaces on the same host bridge.  When one of those
domains is reconfigured, we will again need to call into vfio by some
mechanism to readjust the host side iommu configuration accordingly.

 bridge cannot disappear before the VFIO devices on it are torn down.
 So the lifetime should not be a problem.

I think it is very risky to assume that existing constraints control
the lifetime for us, since we don't know what variety of iommus we may
have in future.  I really think we should have an explicit hook which
allows us to call vfio side cleanup code when a guest side iommu
region is destroyed.  Personally, I still think a special-purpose vfio
hook is the simplest way to do that, but a more general use Notifier
list or something in the right place could do the job too.

I do realise why we don't really want vfio specific hooks in the
generic code.  But we absolutely do need some kind of hooks which vfio
can use, and until we have a second potential user of those hooks, I
think general hooks are overengineering.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson


signature.asc
Description: Digital signature


Re: [Qemu-devel] [PATCH v2] virtio-net: unbreak the minix guest

2013-04-29 Thread Aurelien Jarno
On Fri, Apr 26, 2013 at 12:49:53PM +0200, Aurelien Jarno wrote:
 On Thu, Apr 25, 2013 at 03:24:23PM +0800, Jason Wang wrote:
  Multiqueue patchset conditionally add control vq only when guest negotiate 
  the
  feature. Though the spec is not clear on this but it breaks the minix guest
  since it will identify the ctrl vq even if it does not support it. Though 
  this
  behavior seems a violation on the spec If the VIRTIO_NET_F_CTRL_VQ feature 
  bit
  is negotiated, identify the control virtqueue., to keep the backward
  compatibility, always add the ctrl vq at end of the queues.
  
  Reported-by: Aurelien Jarno aurel...@aurel32.net
  Cc: Aurelien Jarno aurel...@aurel32.net
  Signed-off-by: Jason Wang jasow...@redhat.com
  
  ---
  Changes from V1:
  - Drop the unrelated cleanups
  - Drop the meaningless ctrl parameter of virtio_net_set_multiqueue()
  ---
   hw/net/virtio-net.c |   15 ---
   1 files changed, 8 insertions(+), 7 deletions(-)
 
 
 Thanks a lot for this patch. It fixes the issue observed on Minix. For
 the record it also fixes virtio-net with NetBSD 6.0.1, before it was
 triggering an assertion in QEMU.
 
 Now that the problem is clear, I will try to work on fixing the problem
 on the OS side when I find some time.
 

For the record, now that I understand the problem, I have been able to
fix the issue on the guest side. Here are the links to the bug reports
and patches:

- Minix: 
https://gforge.cs.vu.nl/gf/project/minix/tracker/?action=TrackerItemEdittracker_item_id=653

- NetBSD: http://gnats.netbsd.org/47780

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



Re: [Qemu-devel] [PATCH for-1.5 v3 08/15] xilinx_spips: Implement automatic CS

2013-04-29 Thread Peter Maydell
On 22 April 2013 06:16,  peter.crosthwa...@xilinx.com wrote:
 From: Peter Crosthwaite peter.crosthwa...@xilinx.com

 Implement the automatic CS control feature. If the MANUAL_CS bit is
 cleared then the chip select stay de-asserted as long as the tx FIFO
 is empty.

 Signed-off-by: Peter Crosthwaite peter.crosthwa...@xilinx.com
 Reviewed-by: Peter Maydell peter.mayd...@linaro.org

Doesn't compile:

hw/ssi/xilinx_spips.c: In function ‘xilinx_spips_update_cs_lines’:
hw/ssi/xilinx_spips.c:215:17: error: implicit declaration of function
‘DB_PRINT_L’ [-Werror=implicit-function-declaration]
hw/ssi/xilinx_spips.c:215:17: error: nested extern declaration of
‘DB_PRINT_L’ [-Werror=nested-externs]
cc1: all warnings being treated as errors

(you don't introduce that macro until later).

-- PMM



Re: [Qemu-devel] [PATCH for-1.5 v3 05/15] xilinx_spips: Fix QSPI FIFO size

2013-04-29 Thread Peter Maydell
On 22 April 2013 06:14,  peter.crosthwa...@xilinx.com wrote:
 @@ -630,6 +652,7 @@ static const TypeInfo xilinx_spips_info = {
  .parent = TYPE_SYS_BUS_DEVICE,
  .instance_size  = sizeof(XilinxSPIPS),
  .class_init = xilinx_spips_class_init,
 +.class_size = sizeof (XilinxSPIPSClass),

Checkpatch doesn't like the space after 'sizeof'.

-- PMM



[Qemu-devel] [PATCH] qdev: Report errors collected during device realization

2013-04-29 Thread Jan Kiszka
Better than just releasing the error object silently.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
 hw/core/qdev.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/hw/core/qdev.c b/hw/core/qdev.c
index 4eb0134..ab1d8f5 100644
--- a/hw/core/qdev.c
+++ b/hw/core/qdev.c
@@ -162,6 +162,7 @@ int qdev_init(DeviceState *dev)
 
 object_property_set_bool(OBJECT(dev), true, realized, local_err);
 if (local_err != NULL) {
+qerror_report_err(local_err);
 error_free(local_err);
 qdev_free(dev);
 return -1;
-- 
1.7.3.4



Re: [Qemu-devel] [PATCH v4 7/7] hw/i386: build ACPI MADT (APIC) for fw_cfg clients

2013-04-29 Thread Kevin O'Connor
On Mon, Apr 29, 2013 at 11:20:15AM +0300, Michael S. Tsirkin wrote:
 On Fri, Apr 26, 2013 at 01:13:28PM +0200, Laszlo Ersek wrote:
  
  I added this from v3 to v4 because Michael asked me for it
  http://thread.gmane.org/gmane.comp.emulators.qemu/206435/focus=207146.
  
  From the SeaBIOS side, I believe Kevin O'Connor also wants to keep out
  related code from SeaBIOS until a full set of tables is passed. I
  disagree with flipping a big switch in the end (ie. I agree a config
  option (let alone a separate SeaBIOS branch) is unwarranted, which is
  why I didn't add the former in v3), but I have no say in it.
  
  Do you want me to rip out these hunks (and adapt the dependencies)?
 
 Essentially, what seabios wants to do is operate in two
 modes:
 - (mostly) use builtin acpi tables
 - use acpi tables from hypervisor
 
 in particular, seabios wants to interpret presence
 of any file in etc/acpi as a signal not to generate
 its own tables.

Right.

 So merging this patch but without the config option will break
 this plan. The only two ways I see are:
 - merge this last patch with the config option, disabled by default
   the idea being we can improve it in-tree, gradually.
 - keep this patch out of tree until we have a complete
   set of tables.
 
 Both are fine with me.

Why?  As long as QEMU places the new tables under new fwcfg entries,
old seabios will totally ignore the new tables.  I don't see why a
QEMU config option is needed - it's safe for QEMU to always create
both old and new fwcfg entries.

-Kevin



Re: [Qemu-devel] [PATCH 2/2] s390: dump guest memory implementation

2013-04-29 Thread Ekaterina Tumanova

On 04/26/2013 09:12 PM, Alexander Graf wrote:

On 23.04.2013, at 17:30, Jens Freimann wrote:


Implement dump-guest-memory support for target s390x.

dump-guest-memory QEMU monitor command didn't work for s390 architecture.
The result of the command is supposed to be ELF format crash-readable
dump.
In order to implement this, the arch-specific part of dump-guest-memory
was added:
target-s390x/arch_dump.c contains the whole set of function for writing
Elf note sections of all types for s390x.

Signed-off-by: Ekaterina Tumanova tuman...@linux.vnet.ibm.com
Signed-off-by: Jens Freimann jf...@linux.vnet.ibm.com
---
configure  |   2 +-
include/elf.h  |   6 ++
target-s390x/Makefile.objs |   2 +-
target-s390x/arch_dump.c   | 231 +
target-s390x/cpu-qom.h |  21 +
target-s390x/cpu.c |   7 ++
6 files changed, 267 insertions(+), 2 deletions(-)
create mode 100644 target-s390x/arch_dump.c

diff --git a/configure b/configure
index ed49f91..90dc58b 100755
--- a/configure
+++ b/configure
@@ -4326,7 +4326,7 @@ fi
if test $target_softmmu = yes ; then
   echo CONFIG_SOFTMMU=y  $config_target_mak
   case $target_arch2 in
-i386|x86_64)
+i386|x86_64|s390x)
   echo CONFIG_HAVE_CORE_DUMP=y  $config_target_mak
   esac
fi
diff --git a/include/elf.h b/include/elf.h
index a21ea53..ba4b3a7 100644
--- a/include/elf.h
+++ b/include/elf.h
@@ -1219,11 +1219,17 @@ typedef struct elf64_shdr {

/* Notes used in ET_CORE */
#define NT_PRSTATUS 1
+#define NT_FPREGSET 2
#define NT_PRFPREG  2
#define NT_PRPSINFO 3
#define NT_TASKSTRUCT   4
#define NT_AUXV 6
#define NT_PRXFPREG 0x46e62b7f  /* copied from 
gdb5.1/include/elf/common.h */
+#define NT_S390_PREFIX  0x305   /* s390 prefix register */
+#define NT_S390_CTRS0x304   /* s390 control registers */
+#define NT_S390_TODPREG 0x303   /* s390 TOD programmable register */
+#define NT_S390_TODCMP  0x302   /* s390 TOD clock comparator register 
*/
+#define NT_S390_TIMER   0x301   /* s390 timer register */


/* Note header in a PT_NOTE section */
diff --git a/target-s390x/Makefile.objs b/target-s390x/Makefile.objs
index 4e63417..c34f654 100644
--- a/target-s390x/Makefile.objs
+++ b/target-s390x/Makefile.objs
@@ -1,4 +1,4 @@
obj-y += translate.o helper.o cpu.o interrupt.o
obj-y += int_helper.o fpu_helper.o cc_helper.o mem_helper.o misc_helper.o
-obj-$(CONFIG_SOFTMMU) += ioinst.o
+obj-$(CONFIG_SOFTMMU) += ioinst.o arch_dump.o
obj-$(CONFIG_KVM) += kvm.o
diff --git a/target-s390x/arch_dump.c b/target-s390x/arch_dump.c
new file mode 100644
index 000..f908257
--- /dev/null
+++ b/target-s390x/arch_dump.c
@@ -0,0 +1,231 @@
+/*
+ * writing ELF notes for s390x arch
+ *
+ *
+ * Copyright IBM Corp. 2012
+ *
+ * Ekaterina Tumanova tuman...@linux.vnet.ibm.com
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ *
+ */
+
+#include cpu.h
+#include elf.h
+#include exec/cpu-all.h
+#include sysemu/dump.h
+#include sysemu/kvm.h
+
+
+struct s390x_user_regs_struct {
+uint64_tpsw[2];
+uint64_tgprs[16];
+uint32_tacrs[16];
+} QEMU_PACKED;
+
+typedef struct s390x_user_regs_struct s390x_user_regs;
+
+struct s390x_elf_prstatus_struct {
+uint8_t pad1[32];
+uint32_t pid;
+uint8_t pad2[76];
+s390x_user_regs regs;
+uint8_t pad3[16];
+} QEMU_PACKED;
+
+typedef struct s390x_elf_prstatus_struct s390x_elf_prstatus;
+
+struct s390x_elf_fpregset_struct {
+uint32_tfpc;
+uint32_tpad;
+uint64_tfprs[16];
+} QEMU_PACKED;
+
+typedef struct s390x_elf_fpregset_struct s390x_elf_fpregset;
+
+typedef struct note_struct {
+Elf64_Nhdr hdr;
+char name[5];
+char pad3[3];
+union {
+s390x_elf_prstatus prstatus;
+s390x_elf_fpregset fpregset;
+uint32_t prefix;
+uint64_t timer;
+uint64_t todcmp;
+uint32_t todpreg;
+uint64_t ctrs[16];
+} contents;
+} QEMU_PACKED note_t;
+
+static int s390x_write_elf64_prstatus(note_t *note, CPUArchState *env)
+{
+int i;
+s390x_user_regs *regs;
+
+note-hdr.n_type = cpu_to_be32(NT_PRSTATUS);
+
+regs = (note-contents.prstatus.regs);
+regs-psw[0] =  cpu_to_be32(env-psw.mask);
+regs-psw[1] =  cpu_to_be32(env-psw.addr);
+for (i = 0; i = 15; i++) {
+regs-acrs[i] = cpu_to_be32(env-aregs[i]);
+regs-gprs[i] = cpu_to_be32(env-regs[i]);

be32? Please verify whether you produce proper dumps on a little endian host.


Alex

Hi,
I don't think I have an opportunity to test this on x86 host. But 
logically as far as I understand, the code is correct here, since we need
to produce big endian dump for s390 guest for any endian host had, and 
we use cpu_to_be32 in the arch-specific part of code.


Regards,

Re: [Qemu-devel] [PATCH 05/30] PPC: fix hreset_vector for 60x, 7x0, 7x5, G2, MPC8xx, MPC5xx, 7400 and 7450

2013-04-29 Thread Aurelien Jarno
On Mon, Apr 29, 2013 at 01:37:30PM +0200, Andreas Färber wrote:
 Am 29.04.2013 12:38, schrieb Fabien Chouteau:
  On 04/28/2013 03:59 PM, Andreas Färber wrote:
  Am 26.04.2013 20:21, schrieb Alexander Graf:
  From: Fabien Chouteau chout...@adacore.com
 
  According to the different user's manuals, the vector offset for system
  reset (both /HRESET and /SRESET) is 0x00100.
 
  This patch may break support of some executables, as the power-on start
  address may change. For a specific board, if the power-on start address
  is different than HRESET vector (i.e. 0x0100 or 0xfff00100), this
  should be fixed in board's initialization code.
 
  Signed-off-by: Fabien Chouteau chout...@adacore.com
  Signed-off-by: Alexander Graf ag...@suse.de
 
  According to git-bisect, this commit broke the prep machine (602).
  Symptoms are a black screen with no VGA output from OHW or kernel.
 
  Please suggest a fix.
 
  
  Can you hand me the binaries so I can try to fix this?
 
 The old ppc_rom.bin is still in qemu.git, so this should suffice:
 
 ./ppc-softmmu/qemu-system-ppc -M prep
 
 Problem is, we can't really recompile that binary with changes - and to
 switch to OpenBIOS after 1.5 to get rid of it, I need to test that my
 incremental patches don't break anything. ;)

You can't really recompile this exact version, but you can recompile a
slightly older version, the one which is in the Debian archive:

http://packages.debian.org/source/unstable/openhackware

I don't know what are the difference between this one and the one in
QEMU though.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net



Re: [Qemu-devel] SoftFloat licensing in Linux kernel

2013-04-29 Thread Anthony Liguori
Peter Maydell peter.mayd...@linaro.org writes:

 On 29 April 2013 11:37, Peter Maydell peter.mayd...@linaro.org wrote:
 On 11 April 2013 07:49, Stefan Hajnoczi stefa...@gmail.com wrote:
 QEMU uses the John Hauser's SoftFloat library.  It seems the matter
 isn't settled yet in Linux but the FSF says the license is
 incompatible with GPLv2.

 So the resolution determined for the kernel is that they actually
 took the softfloat code at a version before the indemnification
 clause appeared in upstream-softfloat's license:
 http://lists.infradead.org/pipermail/linux-arm-kernel/2013-April/163904.html

 Given that that change only happened ~2010 it seems pretty
 likely that QEMU's softfloat code also predates it; has
 anybody done the necessary digging in our version control
 history to confirm?

 ...rats, looks like (a) the license change was earlier, at
 the upstream version 2-2b boundary and (b) QEMU's softfloat
 is based on 2b, not 2 (as the kernel's is.)

The kernel code is quite different than the QEMU code too.  Looks like
it would be quite a lot of work to switch to the kernel implementation.

That said, I think it's our best long term option...

Regards,

Anthony Liguori


 -- PMM



[Qemu-devel] [PATCH v4 1/2] i2c: Introduce device address mask

2013-04-29 Thread Jan Kiszka
Some devices react on multiple addresses. To emulate this, we could
register them multiple times, but that is cumbersome. The AT24C16, e.g.
listens on 8 different addresses.

Instead, introduce a device address mask that is applied on the
transmitted address before matching it against the stored one. Moreover,
the transmitted address is passed as additional parameter to the event
callback of the device.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
 hw/arm/pxa2xx.c  |3 ++-
 hw/arm/tosa.c|2 +-
 hw/arm/z2.c  |2 +-
 hw/audio/wm8750.c|2 +-
 hw/display/ssd0303.c |2 +-
 hw/gpio/max7310.c|2 +-
 hw/i2c/core.c|   14 ++
 hw/i2c/smbus.c   |2 +-
 hw/input/lm832x.c|2 +-
 hw/misc/tmp105.c |2 +-
 hw/timer/ds1338.c|2 +-
 hw/timer/twl92230.c  |2 +-
 include/hw/i2c/i2c.h |4 +++-
 13 files changed, 25 insertions(+), 16 deletions(-)

diff --git a/hw/arm/pxa2xx.c b/hw/arm/pxa2xx.c
index 24b03a0..7d79805 100644
--- a/hw/arm/pxa2xx.c
+++ b/hw/arm/pxa2xx.c
@@ -1240,7 +1240,8 @@ static void pxa2xx_i2c_update(PXA2xxI2CState *s)
 }
 
 /* These are only stubs now.  */
-static void pxa2xx_i2c_event(I2CSlave *i2c, enum i2c_event event)
+static void pxa2xx_i2c_event(I2CSlave *i2c, enum i2c_event event,
+ uint8_t param)
 {
 PXA2xxI2CSlaveState *slave = FROM_I2C_SLAVE(PXA2xxI2CSlaveState, i2c);
 PXA2xxI2CState *s = slave-host;
diff --git a/hw/arm/tosa.c b/hw/arm/tosa.c
index 47818a5..8a89557 100644
--- a/hw/arm/tosa.c
+++ b/hw/arm/tosa.c
@@ -157,7 +157,7 @@ static int tosa_dac_send(I2CSlave *i2c, uint8_t data)
 return 0;
 }
 
-static void tosa_dac_event(I2CSlave *i2c, enum i2c_event event)
+static void tosa_dac_event(I2CSlave *i2c, enum i2c_event event, uint8_t param)
 {
 TosaDACState *s = FROM_I2C_SLAVE(TosaDACState, i2c);
 s-len = 0;
diff --git a/hw/arm/z2.c b/hw/arm/z2.c
index 07a127b..b42d330 100644
--- a/hw/arm/z2.c
+++ b/hw/arm/z2.c
@@ -216,7 +216,7 @@ static int aer915_send(I2CSlave *i2c, uint8_t data)
 return 0;
 }
 
-static void aer915_event(I2CSlave *i2c, enum i2c_event event)
+static void aer915_event(I2CSlave *i2c, enum i2c_event event, uint8_t param)
 {
 AER915State *s = FROM_I2C_SLAVE(AER915State, i2c);
 switch (event) {
diff --git a/hw/audio/wm8750.c b/hw/audio/wm8750.c
index 6b5a349..6181de7 100644
--- a/hw/audio/wm8750.c
+++ b/hw/audio/wm8750.c
@@ -297,7 +297,7 @@ static void wm8750_reset(I2CSlave *i2c)
 s-i2c_len = 0;
 }
 
-static void wm8750_event(I2CSlave *i2c, enum i2c_event event)
+static void wm8750_event(I2CSlave *i2c, enum i2c_event event, uint8_t param)
 {
 WM8750State *s = (WM8750State *) i2c;
 
diff --git a/hw/display/ssd0303.c b/hw/display/ssd0303.c
index beea5bf..cf73e93 100644
--- a/hw/display/ssd0303.c
+++ b/hw/display/ssd0303.c
@@ -173,7 +173,7 @@ static int ssd0303_send(I2CSlave *i2c, uint8_t data)
 return 0;
 }
 
-static void ssd0303_event(I2CSlave *i2c, enum i2c_event event)
+static void ssd0303_event(I2CSlave *i2c, enum i2c_event event, uint8_t param)
 {
 ssd0303_state *s = (ssd0303_state *)i2c;
 switch (event) {
diff --git a/hw/gpio/max7310.c b/hw/gpio/max7310.c
index 59b2877..6574436 100644
--- a/hw/gpio/max7310.c
+++ b/hw/gpio/max7310.c
@@ -123,7 +123,7 @@ static int max7310_tx(I2CSlave *i2c, uint8_t data)
 return 0;
 }
 
-static void max7310_event(I2CSlave *i2c, enum i2c_event event)
+static void max7310_event(I2CSlave *i2c, enum i2c_event event, uint8_t param)
 {
 MAX7310State *s = (MAX7310State *) i2c;
 s-len = 0;
diff --git a/hw/i2c/core.c b/hw/i2c/core.c
index 0c4fc1d..bb604e9 100644
--- a/hw/i2c/core.c
+++ b/hw/i2c/core.c
@@ -76,6 +76,11 @@ void i2c_set_slave_address(I2CSlave *dev, uint8_t address)
 dev-address = address;
 }
 
+void i2c_set_slave_address_mask(I2CSlave *dev, uint8_t mask)
+{
+dev-address_mask = mask;
+}
+
 /* Return nonzero if bus is busy.  */
 int i2c_bus_busy(i2c_bus *bus)
 {
@@ -93,7 +98,7 @@ int i2c_start_transfer(i2c_bus *bus, uint8_t address, int 
recv)
 QTAILQ_FOREACH(kid, bus-qbus.children, sibling) {
 DeviceState *qdev = kid-child;
 I2CSlave *candidate = I2C_SLAVE(qdev);
-if (candidate-address == address) {
+if (candidate-address == (address  candidate-address_mask)) {
 slave = candidate;
 break;
 }
@@ -108,7 +113,7 @@ int i2c_start_transfer(i2c_bus *bus, uint8_t address, int 
recv)
start condition.  */
 bus-current_dev = slave;
 if (sc-event) {
-sc-event(slave, recv ? I2C_START_RECV : I2C_START_SEND);
+sc-event(slave, recv ? I2C_START_RECV : I2C_START_SEND, address);
 }
 return 0;
 }
@@ -124,7 +129,7 @@ void i2c_end_transfer(i2c_bus *bus)
 
 sc = I2C_SLAVE_GET_CLASS(dev);
 if (sc-event) {
-sc-event(dev, I2C_FINISH);
+sc-event(dev, I2C_FINISH, 0);
 }
 
 bus-current_dev = NULL;
@@ -175,7 +180,7 @@ void 

[Qemu-devel] [PATCH v4 0/2] i2c: Add AT24Cxx EEPROM model

2013-04-29 Thread Jan Kiszka
Changes in v4:
 - instead of provide size property, register at24c1..1024 types to
   allow specifying the size via the device name

Jan Kiszka (2):
  i2c: Introduce device address mask
  Add AT24Cxx I2C EEPROM device model

 hw/arm/pxa2xx.c|3 +-
 hw/arm/tosa.c  |2 +-
 hw/arm/z2.c|2 +-
 hw/audio/wm8750.c  |2 +-
 hw/display/ssd0303.c   |2 +-
 hw/gpio/max7310.c  |2 +-
 hw/i2c/core.c  |   14 ++-
 hw/i2c/smbus.c |2 +-
 hw/input/lm832x.c  |2 +-
 hw/misc/tmp105.c   |2 +-
 hw/nvram/Makefile.objs |2 +-
 hw/nvram/at24.c|  391 
 hw/timer/ds1338.c  |2 +-
 hw/timer/twl92230.c|2 +-
 include/hw/i2c/i2c.h   |4 +-
 15 files changed, 417 insertions(+), 17 deletions(-)
 create mode 100644 hw/nvram/at24.c

-- 
1.7.3.4




[Qemu-devel] [PATCH v4 2/2] Add AT24Cxx I2C EEPROM device model

2013-04-29 Thread Jan Kiszka
This implements I2C EEPROMs of the AT24Cxx series. Sizes from 1Kbit to
1024Kbit are supported. Each EEPROM is backed by a block device. Its
size can be explicitly specified by selecting the exact device type
(required for sizes  512, the blockdev sector size) or implicitly by
providing a block device image of the corresponding size. Device
addresses are built from the device number property. Write protection
can be configured by declaring the block device read-only.

Signed-off-by: Jan Kiszka jan.kis...@siemens.com
---
 hw/nvram/Makefile.objs |2 +-
 hw/nvram/at24.c|  391 
 2 files changed, 392 insertions(+), 1 deletions(-)
 create mode 100644 hw/nvram/at24.c

diff --git a/hw/nvram/Makefile.objs b/hw/nvram/Makefile.objs
index e9a6694..8271cd6 100644
--- a/hw/nvram/Makefile.objs
+++ b/hw/nvram/Makefile.objs
@@ -1,5 +1,5 @@
 common-obj-$(CONFIG_DS1225Y) += ds1225y.o
-common-obj-y += eeprom93xx.o
+common-obj-y += eeprom93xx.o at24.o
 common-obj-y += fw_cfg.o
 common-obj-$(CONFIG_MAC_NVRAM) += mac_nvram.o
 obj-$(CONFIG_PSERIES) += spapr_nvram.o
diff --git a/hw/nvram/at24.c b/hw/nvram/at24.c
new file mode 100644
index 000..654a4e2
--- /dev/null
+++ b/hw/nvram/at24.c
@@ -0,0 +1,391 @@
+/*
+ * AT24Cxx EEPROM emulation
+ *
+ * Copyright (c) Siemens AG, 2012, 2013
+ * Author: Jan Kiszka
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the Software), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+#include hw/hw.h
+#include hw/i2c/i2c.h
+#include hw/block/block.h
+#include sysemu/blockdev.h
+
+#define TYPE_AT24 at24
+#define AT24(obj) OBJECT_CHECK(AT24State, (obj), TYPE_AT24)
+
+#define AT24_BASE_ADDRESS   0x50
+#define AT24_MAX_PAGE_LEN   256
+
+typedef struct AT24Parameters {
+const char *desc;
+unsigned int size;
+unsigned int page_size;
+unsigned int device_bits;
+unsigned int hi_addr_bits;
+bool addr16;
+} AT24Parameters;
+
+typedef enum AT24TransferState {
+AT24_IDLE,
+AT24_RD_ADDR,
+AT24_WR_ADDR_HI,
+AT24_WR_ADDR_LO,
+AT24_RW_DATA0,
+AT24_RD_DATA,
+AT24_WR_DATA,
+} AT24TransferState;
+
+typedef struct AT24State {
+I2CSlave parent_obj;
+
+BlockConf block_conf;
+BlockDriverState *bs;
+bool wp;
+unsigned int addr_mask;
+unsigned int page_mask;
+bool addr16;
+unsigned int hi_addr_mask;
+uint8_t device;
+AT24TransferState transfer_state;
+uint8_t sector_buffer[BDRV_SECTOR_SIZE];
+int cached_sector;
+bool cache_dirty;
+uint32_t transfer_addr;
+} AT24State;
+
+static void at24_flush_transfer_buffer(AT24State *s)
+{
+if (s-cached_sector  0 || !s-cache_dirty) {
+return;
+}
+bdrv_write(s-bs, s-cached_sector, s-sector_buffer, 1);
+s-cache_dirty = false;
+}
+
+static void at24_event(I2CSlave *i2c, enum i2c_event event, uint8_t param)
+{
+AT24State *s = AT24(i2c);
+
+switch (event) {
+case I2C_START_SEND:
+switch (s-transfer_state) {
+case AT24_IDLE:
+if (s-addr16) {
+s-transfer_addr = (param  s-hi_addr_mask)  16;
+s-transfer_state = AT24_WR_ADDR_HI;
+} else {
+s-transfer_addr = (param  s-hi_addr_mask)  8;
+s-transfer_state = AT24_WR_ADDR_LO;
+}
+break;
+default:
+s-transfer_state = AT24_IDLE;
+break;
+}
+break;
+case I2C_START_RECV:
+switch (s-transfer_state) {
+case AT24_IDLE:
+s-transfer_state = AT24_RD_ADDR;
+break;
+case AT24_RW_DATA0:
+s-transfer_state = AT24_RD_DATA;
+break;
+default:
+s-transfer_state = AT24_IDLE;
+break;
+}
+break;
+case I2C_FINISH:
+switch (s-transfer_state) {
+case AT24_WR_DATA:
+at24_flush_transfer_buffer(s);
+/* fall through */
+default:
+s-transfer_state = 

Re: [Qemu-devel] SoftFloat licensing in Linux kernel

2013-04-29 Thread Peter Maydell
On 29 April 2013 14:04, Anthony Liguori anth...@codemonkey.ws wrote:
 Peter Maydell peter.mayd...@linaro.org writes:
 ...rats, looks like (a) the license change was earlier, at
 the upstream version 2-2b boundary and (b) QEMU's softfloat
 is based on 2b, not 2 (as the kernel's is.)

 The kernel code is quite different than the QEMU code too.  Looks like
 it would be quite a lot of work to switch to the kernel implementation.

We don't necessarily need to switch to the kernel's code
and then unpick all the changes they've made over the years --
we could start with upstream v2 instead I guess.

(Ideally where there have been changes we've made since,
like the fused-multiply-add support and NaN handling
changes we could try to get those contributors to relicense
so we can just reapply that bit. I don't know how you do
the mechanics of this in a legally solid way, though.)

-- PMM



Re: [Qemu-devel] [PATCH V2 0/3] Virtio-9p live migration patchset

2013-04-29 Thread Benoît Canet


quintela: ping.

I really need your review to get this patchset in shape for merging.

Regards

Benoît

 Le Thursday 11 Apr 2013 à 16:41:05 (+0200), Benoît Canet a écrit :
 This patchset is a rework of the 9p live migration patchs made a few years ago
 by Aneesh.
 As the new vmstate API doesn't support linked list so the old API is used.
 
 v2:
 Drop pre migration flush hook code (Paolo)
 Use vmstate change notifier (Paolo)
 Use static variables instead of a struct in patch 2 (Paolo, Peter)
 Drop spurious root_id related code (Peter)
 Rename functions in patch two (Benoît)
 
 Benoît Canet (3):
   virtio-9p: Add support for 9p migration.
   virtio-9p: Wait for 9p operations to complete before migration and
 savevm.
   virtio-9p: Remove migration blockers.
 
  hw/9pfs/virtio-9p-device.c |  154 
 
  hw/9pfs/virtio-9p.c|   98 +---
  hw/9pfs/virtio-9p.h|4 +-
  3 files changed, 231 insertions(+), 25 deletions(-)
 
 -- 
 1.7.10.4
 



Re: [Qemu-devel] [PATCH v2] linux-user: improve target_to_host_sock_type conversion

2013-04-29 Thread Petar Jovanovic
ping

http://patchwork.ozlabs.org/patch/232770/

From: Petar Jovanovic
Sent: Tuesday, April 23, 2013 2:15 AM
To: Aurelien Jarno; Petar Jovanovic
Cc: qemu-devel@nongnu.org; riku.voi...@linaro.org; r...@twiddle.net; 
blauwir...@gmail.com
Subject: RE: [PATCH v2] linux-user: improve target_to_host_sock_type conversion

Thanks Aurelien for your comments.

What others think? Can we submit this version of the patch? Riku? Richard, Blue?

Petar

From: Aurelien Jarno [aurel...@aurel32.net]
Sent: Monday, April 15, 2013 3:47 PM
To: Petar Jovanovic
Cc: qemu-devel@nongnu.org; Petar Jovanovic; riku.voi...@linaro.org; 
r...@twiddle.net; blauwir...@gmail.com
Subject: Re: [PATCH v2] linux-user: improve target_to_host_sock_type conversion

On Mon, Apr 01, 2013 at 05:49:39PM +0200, Petar Jovanovic wrote:
 From: Petar Jovanovic petar.jovano...@imgtec.com

 Previous implementation has failed to take into account different value of
 SOCK_NONBLOCK on target and host, and existence of SOCK_CLOEXEC.
 The same conversion has to be applied both for do_socket and do_socketpair,
 so the code has been isolated in a static inline function.
 The change is valid for architectures that define ARCH_HAS_SOCKET_TYPES,
 these are MIPS, SPARC and ALPHA now.

 enum sock_type in linux-user/socket.h has been extended to include
 TARGET_SOCK_CLOEXEC and TARGET_SOCK_NONBLOCK, similar to definition in libc.
 The patch also includes necessary code style changes (tab to spaces) in the
 header file in the MIPS #ifdef block touched by the change.

 Signed-off-by: Petar Jovanovic petar.jovano...@imgtec.com
 ---
  v2:

  - the patch defines ARCH_HAS_SOCKET_TYPES for MIPS, SPARC and ALPHA
  - values for sock_type are defined for SPARC and ALPHA in socket.h

  linux-user/socket.h  |  248 
 +-
  linux-user/syscall.c |   45 +
  2 files changed, 195 insertions(+), 98 deletions(-)

 diff --git a/linux-user/socket.h b/linux-user/socket.h
 index 339cae5..d2b05dc 100644
 --- a/linux-user/socket.h
 +++ b/linux-user/socket.h
 @@ -1,91 +1,104 @@

  #if defined(TARGET_MIPS)
 - // MIPS special values for constants
 -
 - /*
 -  * For setsockopt(2)
 -  *
 -  * This defines are ABI conformant as far as Linux supports these ...
 -  */
 - #define TARGET_SOL_SOCKET  0x
 -
 - #define TARGET_SO_DEBUG0x0001  /* Record debugging information. 
  */
 - #define TARGET_SO_REUSEADDR0x0004  /* Allow reuse of local 
 addresses.  */
 - #define TARGET_SO_KEEPALIVE0x0008  /* Keep connections alive and 
 send
 -   SIGPIPE when they die.  */
 - #define TARGET_SO_DONTROUTE0x0010  /* Don't do local routing.  */
 - #define TARGET_SO_BROADCAST0x0020  /* Allow transmission of
 -   broadcast messages.  */
 - #define TARGET_SO_LINGER   0x0080  /* Block on close of a reliable
 -   socket to transmit pending data.  */
 - #define TARGET_SO_OOBINLINE 0x0100 /* Receive out-of-band data 
 in-band.  */
 - #if 0
 - To add: #define TARGET_SO_REUSEPORT 0x0200 /* Allow local address 
 and port reuse.  */
 - #endif
 -
 - #define TARGET_SO_TYPE 0x1008  /* Compatible name for SO_STYLE. 
  */
 - #define TARGET_SO_STYLESO_TYPE /* Synonym */
 - #define TARGET_SO_ERROR0x1007  /* get error status and clear */
 - #define TARGET_SO_SNDBUF   0x1001  /* Send buffer size. */
 - #define TARGET_SO_RCVBUF   0x1002  /* Receive buffer. */
 - #define TARGET_SO_SNDLOWAT 0x1003  /* send low-water mark */
 - #define TARGET_SO_RCVLOWAT 0x1004  /* receive low-water mark */
 - #define TARGET_SO_SNDTIMEO 0x1005  /* send timeout */
 - #define TARGET_SO_RCVTIMEO 0x1006  /* receive timeout */
 - #define TARGET_SO_ACCEPTCONN   0x1009
 -
 - /* linux-specific, might as well be the same as on i386 */
 - #define TARGET_SO_NO_CHECK 11
 - #define TARGET_SO_PRIORITY 12
 - #define TARGET_SO_BSDCOMPAT14
 +/* MIPS special values for constants */
 +
 +/*
 + * For setsockopt(2)
 + *
 + * This defines are ABI conformant as far as Linux supports these ...
 + */
 +#define TARGET_SOL_SOCKET  0x
 +
 +#define TARGET_SO_DEBUG0x0001  /* Record debugging information. 
 */
 +#define TARGET_SO_REUSEADDR0x0004  /* Allow reuse of local 
 addresses. */
 +#define TARGET_SO_KEEPALIVE0x0008  /* Keep connections alive and send
 +  SIGPIPE when they die. */
 +#define TARGET_SO_DONTROUTE0x0010  /* Don't do local routing. */
 +#define TARGET_SO_BROADCAST0x0020  /* Allow transmission of
 +  broadcast messages. */
 +#define TARGET_SO_LINGER 

Re: [Qemu-devel] [PATCH v4 7/7] hw/i386: build ACPI MADT (APIC) for fw_cfg clients

2013-04-29 Thread Laszlo Ersek
On 04/29/13 14:39, Kevin O'Connor wrote:
 On Mon, Apr 29, 2013 at 11:20:15AM +0300, Michael S. Tsirkin wrote:

 in particular, seabios wants to interpret presence
 of any file in etc/acpi as a signal not to generate
 its own tables.
 
 Right.

In that case,

 So merging this patch but without the config option will break
 this plan. The only two ways I see are:
 - merge this last patch with the config option, disabled by default
   the idea being we can improve it in-tree, gradually.
 - keep this patch out of tree until we have a complete
   set of tables.

 Both are fine with me.
 
 Why?  As long as QEMU places the new tables under new fwcfg entries,
 old seabios will totally ignore the new tables.  I don't see why a
 QEMU config option is needed - it's safe for QEMU to always create
 both old and new fwcfg entries.

the new-style fw_cfg entry for the MADT (= etc/acpi/APIC) would
prevent the generation of all other (yet unexported by qemu) ACPI tables
in *new* seabios.

[SeaBIOS] [PATCH RFC 2/3] acpi: load and link tables from /etc/acpi/
http://thread.gmane.org/gmane.comp.emulators.qemu/208457/focus=208458

Thanks,
Laszlo



Re: [Qemu-devel] [PATCH v4 7/7] hw/i386: build ACPI MADT (APIC) for fw_cfg clients

2013-04-29 Thread Michael S. Tsirkin
On Mon, Apr 29, 2013 at 08:39:26AM -0400, Kevin O'Connor wrote:
 On Mon, Apr 29, 2013 at 11:20:15AM +0300, Michael S. Tsirkin wrote:
  On Fri, Apr 26, 2013 at 01:13:28PM +0200, Laszlo Ersek wrote:
   
   I added this from v3 to v4 because Michael asked me for it
   http://thread.gmane.org/gmane.comp.emulators.qemu/206435/focus=207146.
   
   From the SeaBIOS side, I believe Kevin O'Connor also wants to keep out
   related code from SeaBIOS until a full set of tables is passed. I
   disagree with flipping a big switch in the end (ie. I agree a config
   option (let alone a separate SeaBIOS branch) is unwarranted, which is
   why I didn't add the former in v3), but I have no say in it.
   
   Do you want me to rip out these hunks (and adapt the dependencies)?
  
  Essentially, what seabios wants to do is operate in two
  modes:
  - (mostly) use builtin acpi tables
  - use acpi tables from hypervisor
  
  in particular, seabios wants to interpret presence
  of any file in etc/acpi as a signal not to generate
  its own tables.
 
 Right.
 
  So merging this patch but without the config option will break
  this plan. The only two ways I see are:
  - merge this last patch with the config option, disabled by default
the idea being we can improve it in-tree, gradually.
  - keep this patch out of tree until we have a complete
set of tables.
  
  Both are fine with me.
 
 Why?  As long as QEMU places the new tables under new fwcfg entries,
 old seabios will totally ignore the new tables.  I don't see why a
 QEMU config option is needed - it's safe for QEMU to always create
 both old and new fwcfg entries.
 
 -Kevin


Yes backwards compatibility is fine, but the problem here is forwards
compatibility.
Future BIOS will say:
there's something in etc/acpi/ therefore I won't generate any tables
so we should not release QEMU that puts only MADT under etc/acpi/madt.

-- 
MST



Re: [Qemu-devel] [PATCH RFC 2/3] acpi: load and link tables from /etc/acpi/

2013-04-29 Thread Michael S. Tsirkin
On Mon, Apr 29, 2013 at 01:41:01PM +0200, Laszlo Ersek wrote:
 Not sure how much it counts, but I personally can agree with you on this
 direction :)
 
 One note below:
 
  @@ -603,8 +604,72 @@ acpi_setup(void)
   if (! CONFIG_ACPI)
   return;
   
  +int acpi_generate = 1;
  +
   dprintf(3, init ACPI tables\n);
   
  +struct romfile_s *file = NULL;
  +for (;;) {
  +file = romfile_findprefix(/etc/acpi/, file);
  +if (!file)
  +break;
  +
  +/*
  + * Disable ACPI table generation. All ACPI tables must come from
  + * etc/acpi/ romfile entries.
  + */
  +acpi_generate = 0;
  +
 
 [...]
 
  +}
  +
  +linker_link(/etc/linker-script);
  +
  +if (!acpi_generate) {
  +return;
  +}
  +
  +dprintf(3, generate ACPI tables\n);
  +
   // This code is hardcoded for PIIX4 Power Management device.
   struct pci_device *pci = pci_find_init_device(acpi_find_tbl, NULL);
   if (!pci)
 
 Are you deliberately calling linker_link() independently from
 acpi_generate? My hunch is that linker_link() only makes sense if
 acpi_generate == 0 (ie. qemu has passed down at least one table to
 repoint some pointer to), but I may be missing a use case.
 
 Thanks
 Laszlo

In theory linker code is unrelated to acpi, and host
can the linker to patch any romfile.
I could add if (!acpi_generate) but it just seems
like adding code to remove something potentially useful.

-- 
MST



Re: [Qemu-devel] [PATCH 3/4] vfio: Move container list to iommu MemoryRegion

2013-04-29 Thread Paolo Bonzini
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Il 29/04/2013 13:56, David Gibson ha scritto:
 Why should VFIO be any special in this?  It is reassuring to me
 that the VFIO maintainer thinks the same. :)
 
 Because device passthrough is a sufficiently special case, IMO.
 It introduces requirements that are fundamentally different from
 any emulated device.
 
 It does also require making sure the lifetime handling is
 correct. The entry from the hash table must be removed before
 the corresponding MemoryRegion is free()ed; otherwise we could
 end up using the same pointer for a newly constructed
 MemoryRegion, and get a false lookup in the hash.  Whether that
 happens essentially never, or almost immediately in practice
 depends on the malloc() implementation, of course.
 
 There is only one MemoryRegion per PCI host bridge, and the PCI
 host
 
 That's true for existing examples, but it need not be true.  For 
 example the Intel IOMMU supports multiple iommu domains which
 are different address spaces on the same host bridge.  When one of
 those domains is reconfigured, we will again need to call into vfio
 by some mechanism to readjust the host side iommu configuration
 accordingly.
 
 bridge cannot disappear before the VFIO devices on it are torn
 down. So the lifetime should not be a problem.
 
 I think it is very risky to assume that existing constraints
 control the lifetime for us, since we don't know what variety of
 iommus we may have in future.  I really think we should have an
 explicit hook which allows us to call vfio side cleanup code when a
 guest side iommu region is destroyed.  Personally, I still think a
 special-purpose vfio hook is the simplest way to do that, but a
 more general use Notifier list or something in the right place
 could do the job too.

I think this is a different problem.  Basically the question is what
happens if a MemoryRegion 'disappears' while an AddressSpace is still
referring to it, and the answer right now is badness.

We should look at generic fixes before dropping hooks in the code.  At
the very least an assert(mr-parent == NULL); is missing in
memory_region_destroy.

Paolo

 I do realise why we don't really want vfio specific hooks in the 
 generic code.  But we absolutely do need some kind of hooks which
 vfio can use, and until we have a second potential user of those
 hooks, I think general hooks are overengineering.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRfnlKAAoJEBvWZb6bTYbyC5MP/2mq2mZ9Maov0bq+AZl4zrA+
li7I1/GWXyZewfWrtkQ8onTjt1jYBcEiWlIPEYpx9S39XZtXke80w5dO4L8gA0Ow
tvFbHx8LdZRSNIuMvcq8Gw22olWKfjDisqYGHhPTw0hrSGBV6K19Jfqv4RFqovRw
mzxY3CKF3G5hJVQJmBipd/1dn0kqS3+OFZI/6Q51b3VfAxRLbNmxW0kfIbVsKbGq
5ctcIMoBJwHiQ5uuUfm1FSgSAtU8hIzHZPRYg/FnAM08u6ERQbVCW54h5RA6ECcx
hfQzTmgHsIYZEMGhvsq9h9hsro9tehchN6u2ANzrFinFNAw8U4xaPQO5OQej2Le2
50f9VoqF7Y7hhnYVivHGQVol45SNdGKV8GJws9nVxJfAIHb7Tu6SYrr7FS+5EYPl
gwH5nUqbWZP8Ss4rLdCOt4hatHwARHv5XScxQWOyjAXC1tJO228i18e1QmsOxaBN
eYN4635InosNW7jtIl1f7zv+iqkcYqkecR26Dw5Qrcy3AlivqU1s/m4mtL1GCZvT
+xO+oFCROuwNLaNBN0if4FlQfPRkDnt5uoloZYLBr4BQJ8ZIUyp4lkiAxZM3OsYp
7r+A0gT4DomxolBF0xOHZCMfc3tSOFZEPPF7cwxqRPJf9uaMG5SfYK6IHUE0zyEg
OGG/l3wDDNtGz/ZEVTfW
=biGU
-END PGP SIGNATURE-



Re: [Qemu-devel] [PATCH] Makefile: Fix build breakage

2013-04-29 Thread Dunrong Huang
On Mon, Apr 29, 2013 at 4:19 PM, Paolo Bonzini pbonz...@redhat.com wrote:

 Il 28/04/2013 20:04, Dunrong Huang ha scritto:
  The following error occurs when building dtc module:
 
CHK version_gen.h
 CC libfdt/fdt.o
  cc1: error: dtc: No such file or directory [-Werror]
  cc1: all warnings being treated as errors
  make[1]: *** [libfdt/fdt.o] Error 1
  make: *** [subdir-dtc] Error 2
 
  In rules.mak, -I$(D) -I$(@D) was expanded to -Idtc -I. when
  building submodule dct. Due to the using of -Wmissing-include-dirs,
  a warning would be rarsed. To avoid it, use dtc as the first prerequisite
  so that $(^D) was expanded to .
 
  Cc: Peter Crosthwaite peter.crosthwa...@xilinx.com
  Cc: Blue Swirl blauwir...@gmail.com
  Signed-off-by: Dunrong Huang riegama...@gmail.com
  ---
   Makefile | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
 
  diff --git a/Makefile b/Makefile
  index 8aca92f..64b0b1b 100644
  --- a/Makefile
  +++ b/Makefile
  @@ -148,7 +148,7 @@ $(SRC_PATH)/pixman/configure:
   DTC_MAKE_ARGS=-I$(SRC_PATH)/dtc VPATH=$(SRC_PATH)/dtc -C dtc V=$(V)
 LIBFDT_srcdir=$(SRC_PATH)/dtc/libfdt
   DTC_CFLAGS=$(CFLAGS) $(QEMU_CFLAGS) -I$(BUILD_DIR)/dtc
 -I$(SRC_PATH)/dtc -I$(SRC_PATH)/dtc/libfdt
 
  -subdir-dtc:dtc/libfdt dtc/tests
  +subdir-dtc:dtc dtc/libfdt dtc/tests
$(call quiet-command,$(MAKE) $(DTC_MAKE_ARGS)
 CFLAGS=$(DTC_CFLAGS) LDFLAGS=$(LDFLAGS) ARFLAGS=$(ARFLAGS) CC=$(CC)
 AR=$(AR) LD=$(LD) $(SUBDIR_MAKEFLAGS) libfdt/libfdt.a,)
 
   dtc/%:
 

 Does it work if the -I$(D) -I$(@D) is added to QEMU_INCLUDES instead
 of QEMU_CFLAGS?

Yes,  this way works for me.

diff --git a/rules.mak b/rules.mak
index 292a422..2572070 100644
--- a/rules.mak
+++ b/rules.mak
@@ -15,7 +15,7 @@ MAKEFLAGS += -rR
 QEMU_DGFLAGS += -MMD -MP -MT $@ -MF $(*D)/$(*F).d

 # Same as -I$(SRC_PATH) -I., but for the nested source/object directories
-QEMU_CFLAGS += -I$(D) -I$(@D)
+QEMU_INCLUDES += -I$(D) -I$(@D)

but I don't know if it will break other build, e.g. mingw build.


 Paolo




-- 
Best Regards,

Dunrong Huang


Re: [Qemu-devel] Target-agnostic virtio?

2013-04-29 Thread Rob Landley

On 04/27/2013 03:00:06 PM, Artyom Tarasenko wrote:

 For a lot of the 64-bit targets, actual 64 bit userspace support is
 strangely lacking. For ppc64 they say to use ppc32, and I've been  
told that

 about sparc64 as well. I don't know if this is an optimization or a
 requirement. I have a 32 bit image, I'd like to test the 64 bit  
codepaths as

 well...

I guess it's rather an optimisation. At least I saw BusyBox working  
under

QEMU before the sparc v8plus was fixed.


If you mean http://busybox.net/downloads/binaries/busybox-sparc that's  
a 32-bit binary output from the Aboriginal Linux build. (I try to  
upload new ones each time Denys has a release, but I'm buried in todo  
items and don't always get to it. Right now I need to clean up and  
repost the inittmpfs patches for 3.9...)


Rob


[Qemu-devel] [PATCH] bsd-user: OS-agnostic 64-bit SYSCTL types

2013-04-29 Thread Ed Maste
Use existence of type as #ifdef condition rather than FreeBSD-specific
version check, as suggested by Patrick Welche.

Also handle the signed (CTLTYPE_S64) case identically to the unsigned
(CTLTYPE_U64) case, per later patches in the FreeBSD ports tree
(emulators/qemu-devel/files/patch-z-arm-bsd-user-001).

Signed-off-by: Ed Maste ema...@freebsd.org
---
 bsd-user/syscall.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/bsd-user/syscall.c b/bsd-user/syscall.c
index 69e3466..34b8dfc 100644
--- a/bsd-user/syscall.c
+++ b/bsd-user/syscall.c
@@ -211,10 +211,11 @@ static int sysctl_oldcvt(void *holdp, size_t holdlen, 
uint32_t kind)
 *(uint64_t *)holdp = tswap64(*(unsigned long *)holdp);
 break;
 #endif
-#if !defined(__FreeBSD_version) || __FreeBSD_version  900031
-case CTLTYPE_QUAD:
-#else
+#ifdef CTLTYPE_U64:
+case CTLTYPE_S64:
 case CTLTYPE_U64:
+#else
+case CTLTYPE_QUAD:
 #endif
 *(uint64_t *)holdp = tswap64(*(uint64_t *)holdp);
 break;
-- 
1.7.11.5




Re: [Qemu-devel] [PATCH 0/2] qom: make cpu_write_elfXX_ functions part of CPUClass

2013-04-29 Thread Andreas Färber
Am 19.04.2013 16:45, schrieb Jens Freimann:
 Hi Andreas,
 
 I have two patches to make dump-guest-memory related
 cpu_write_elfxx_note functions members of CPUClass and pass CPUstate
 as an argument instead of CPUArchState.
 
 This is preparation for s390 patches which will follow on Monday.
 
 Jens Freimann (2):
   qom: Convert cpu_write_elfXX_note functions to CPUState
   i386: use CPUClass-write_elf* functions

Thanks, squashed and applied to qom-cpu (with changes below):
https://github.com/afaerber/qemu-cpu/commits/qom-cpu

* squashed both for bisectability
* fixed argument indentation
* s/klass/cc/g in qom/cpu.c; TODO: class_init still uses k
* dropped including cpu-qom.h in target-i386/cpu.c
* dropped including qom/cpu.h in target-i386/arch_dump.c
* retained stubs from dump-stub.c in qom/cpu.c
* target-i386: reserve cpu for X86CPU and avoid env_ptr usage

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



Re: [Qemu-devel] [PATCH] Makefile: Fix build breakage

2013-04-29 Thread Paolo Bonzini
Il 29/04/2013 15:33, Dunrong Huang ha scritto:
 
 Yes,  this way works for me.
 
 diff --git a/rules.mak b/rules.mak
 index 292a422..2572070 100644
 --- a/rules.mak
 +++ b/rules.mak
 @@ -15,7 +15,7 @@ MAKEFLAGS += -rR
  QEMU_DGFLAGS += -MMD -MP -MT $@ -MF $(*D)/$(*F).d
  
  # Same as -I$(SRC_PATH) -I., but for the nested source/object directories
 -QEMU_CFLAGS += -I$(D) -I$(@D)
 +QEMU_INCLUDES += -I$(D) -I$(@D)
 
 but I don't know if it will break other build, e.g. mingw build.

Please submit it, it is a better fix.  Make sure you put 1.5 in the
subject.

Paolo



Re: [Qemu-devel] [PATCH 6/6] pc_sysfw: change rom_only default to 0

2013-04-29 Thread Markus Armbruster
Jordan Justen jordan.l.jus...@intel.com writes:

 Now KVM can support a flash memory. This feature depends on
 KVM_CAP_READONLY_MEM, which was introduced in Linux 3.7.

 Signed-off-by: Jordan Justen jordan.l.jus...@intel.com
 ---
  hw/block/pc_sysfw.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/hw/block/pc_sysfw.c b/hw/block/pc_sysfw.c
 index e88d67e..c5067c1 100644
 --- a/hw/block/pc_sysfw.c
 +++ b/hw/block/pc_sysfw.c
 @@ -258,7 +258,7 @@ void pc_system_firmware_init(MemoryRegion *rom_memory)
  }
  
  static Property pcsysfw_properties[] = {
 -DEFINE_PROP_UINT8(rom_only, PcSysFwDevice, rom_only, 1),
 +DEFINE_PROP_UINT8(rom_only, PcSysFwDevice, rom_only, 0),
  DEFINE_PROP_END_OF_LIST(),
  };

Do we still need the pc-sysfw.rom_only entry in include/hw/i386/pc.h
PC_COMPAT_1_4?



Re: [Qemu-devel] [PATCH] qdev: Report errors collected during device realization

2013-04-29 Thread Andreas Färber
Am 29.04.2013 14:35, schrieb Jan Kiszka:
 Better than just releasing the error object silently.
 
 Signed-off-by: Jan Kiszka jan.kis...@siemens.com

Reviewed-by: Andreas Färber afaer...@suse.de

but CC'ing monitor guys to verify this is the right print function.

Andreas

 ---
  hw/core/qdev.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/hw/core/qdev.c b/hw/core/qdev.c
 index 4eb0134..ab1d8f5 100644
 --- a/hw/core/qdev.c
 +++ b/hw/core/qdev.c
 @@ -162,6 +162,7 @@ int qdev_init(DeviceState *dev)
  
  object_property_set_bool(OBJECT(dev), true, realized, local_err);
  if (local_err != NULL) {
 +qerror_report_err(local_err);
  error_free(local_err);
  qdev_free(dev);
  return -1;
 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



[Qemu-devel] [PATCH v2] ppc: initialize GPRs as per epapr

2013-04-29 Thread Bharat Bhushan
ePAPR defines the initial values of cpu registers.
This patch initialize the GPRs as per ePAPR specification.

This resolves the issue of guest reboot/reset (guest hang on reboot).

Signed-off-by: Bharat Bhushan bharat.bhus...@freescale.com
---
v1--v2
 - Dynemic seting of initial map size in gpr[7]
 - For this the tlb size calculation is moved into a function.

 hw/ppc/e500.c |   29 ++---
 1 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
index c1bdb6b..decd86c 100644
--- a/hw/ppc/e500.c
+++ b/hw/ppc/e500.c
@@ -37,6 +37,7 @@
 #include qemu/host-utils.h
 #include hw/pci-host/ppce500.h
 
+#define EPAPR_MAGIC(0x45504150)
 #define BINARY_DEVICE_TREE_FILEmpc8544ds.dtb
 #define UIMAGE_LOAD_BASE   0
 #define DTC_LOAD_PAD   0x180
@@ -393,11 +394,10 @@ static inline hwaddr booke206_page_size_to_tlb(uint64_t 
size)
 return 63 - clz64(size  10);
 }
 
-static void mmubooke_create_initial_mapping(CPUPPCState *env)
+static int booke206_initial_map_tsize(CPUPPCState *env)
 {
 struct boot_info *bi = env-load_info;
-ppcmas_tlb_t *tlb = booke206_get_tlbm(env, 1, 0, 0);
-hwaddr size, dt_end;
+hwaddr dt_end;
 int ps;
 
 /* Our initial TLB entry needs to cover everything from 0 to
@@ -408,6 +408,23 @@ static void mmubooke_create_initial_mapping(CPUPPCState 
*env)
 /* e500v2 can only do even TLB size bits */
 ps++;
 }
+return ps;
+}
+static uint64_t mmubooke_initial_mapsize(CPUPPCState *env)
+{
+int tsize;
+
+tsize = booke206_initial_map_tsize(env);
+return (1ULL  10  tsize);
+}
+
+static void mmubooke_create_initial_mapping(CPUPPCState *env)
+{
+ppcmas_tlb_t *tlb = booke206_get_tlbm(env, 1, 0, 0);
+hwaddr size;
+int ps;
+
+ps = booke206_initial_map_tsize(env);
 size = (ps  MAS1_TSIZE_SHIFT);
 tlb-mas1 = MAS1_VALID | size;
 tlb-mas2 = 0;
@@ -444,6 +461,12 @@ static void ppce500_cpu_reset(void *opaque)
 cs-halted = 0;
 env-gpr[1] = (1620) - 8;
 env-gpr[3] = bi-dt_base;
+env-gpr[4] = 0;
+env-gpr[5] = 0;
+env-gpr[6] = EPAPR_MAGIC;
+env-gpr[7] = mmubooke_initial_mapsize(env);
+env-gpr[8] = 0;
+env-gpr[9] = 0;
 env-nip = bi-entry;
 mmubooke_create_initial_mapping(env);
 }
-- 
1.7.0.4





Re: [Qemu-devel] [PATCH] virtio-net: count VIRTIO_NET_F_MAC when calculating config_len

2013-04-29 Thread Jesse Larrew
On 04/25/2013 01:59 AM, Michael S. Tsirkin wrote:
 On Thu, Apr 25, 2013 at 02:21:29PM +0800, Jason Wang wrote:
 Commit 14f9b664 (hw/virtio-net.c: set config size using host features) tries 
 to
 calculate config size based on the host features. But it forgets the
 VIRTIO_NET_F_MAC were always set for qemu later. This will lead a zero config
 len for virtio-net device when both VIRTIO_NET_F_STATUS and VIRTIO_NET_F_MQ 
 were
 disabled form command line. Then qemu will crash when user tries to read the
 config of virtio-net.

 Fix this by counting VIRTIO_NET_F_MAC and make sure the config at least 
 contains
 the mac address.

 Cc: Jesse Larrew jlar...@linux.vnet.ibm.com
 Signed-off-by: Jason Wang jasow...@redhat.com
 ---
  hw/net/virtio-net.c |3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)

 diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
 index 70c8fce..33a70ef 100644
 --- a/hw/net/virtio-net.c
 +++ b/hw/net/virtio-net.c
 @@ -1264,7 +1264,8 @@ static void 
 virtio_net_guest_notifier_mask(VirtIODevice *vdev, int idx,
  
  void virtio_net_set_config_size(VirtIONet *n, uint32_t host_features)
  {
 -int i, config_size = 0;
 +/* VIRTIO_NET_F_MAC can't be disabled from qemu side */
 +int i, config_size = feature_sizes[0].end;
 
 This would be cleaner:
   host_features |= (1  VIRTIO_NET_F_MAC);
 
 no need for a comment then.
 

It seems to me that the real problem here is that host_features isn't
properly populated before virtio_net_set_config_size() is called. Looking
at virtio_device_init(), we can see why:

static int virtio_device_init(DeviceState *qdev)
{
VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(qdev);
assert(k-init != NULL);
if (k-init(vdev)  0) {
return -1;
}
virtio_bus_plug_device(vdev);
return 0;
}

virtio_net_set_config_size() is currently being called as part of the
k-init call, but the host_features aren't properly setup until the device
is plugged into the bus using virtio_bus_plug_device().

After talking with mdroth, I think the proper way to fix this would be to
extend VirtioDeviceClass to include a calculate_config_size() method that
can be called at the appropriate time during device initialization like so:

static int virtio_device_init(DeviceState *qdev)
{
VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(qdev);
assert(k-init != NULL);
if (k-init(vdev)  0) {
return -1;
}
virtio_bus_plug_device(vdev);
+   if (k-calculate_config_size  k-calculate_config_size(vdev)  0) {
+   return -1;
+   }
return 0;
}

This would ensure that host_features contains the proper data before any
devices try to make use of it to calculate the config size.

  for (i = 0; feature_sizes[i].flags != 0; i++) {
  if (host_features  feature_sizes[i].flags) {
  config_size = MAX(feature_sizes[i].end, config_size);
 -- 
 1.7.1
 

Jesse Larrew
Software Engineer, KVM Team
IBM Linux Technology Center
Phone: (512) 973-2052 (T/L: 363-2052)
jlar...@linux.vnet.ibm.com




[Qemu-devel] [PATCH for-1.5 v2] rules.mk: Fix build breakage

2013-04-29 Thread Dunrong Huang
The following error occurs when building dtc module:

CHK version_gen.h
 CC libfdt/fdt.o
cc1: error: dtc: No such file or directory [-Werror]
cc1: all warnings being treated as errors
make[1]: *** [libfdt/fdt.o] Error 1
make: *** [subdir-dtc] Error 2

In rules.mak, -I$(D) -I$(@D) was expanded to -Idtc -I. when
building submodule dct. Due to the using of -Wmissing-include-dirs,
a warning would be rarsed. To avoid it, add -I$(D) -I$(@D) to
QEMU_INCLUDES instead of QEMU_CFLAGS so that QEMU_CFLAGS does not
contain the -Idtc.

Cc: Peter Crosthwaite peter.crosthwa...@xilinx.com
Cc: Blue Swirl blauwir...@gmail.com
Cc: Paolo Bonzini pbonz...@redhat.com
Signed-off-by: Dunrong Huang riegama...@gmail.com
---
v1 - v2:
   * Fix it by adding -I$(D) -I$(@D) to QEMU_INCLUDES instead of
 QEMU_CFLAGS(thanks to Paolo Bonzini for correction)
   
 rules.mak | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rules.mak b/rules.mak
index 292a422..2572070 100644
--- a/rules.mak
+++ b/rules.mak
@@ -15,7 +15,7 @@ MAKEFLAGS += -rR
 QEMU_DGFLAGS += -MMD -MP -MT $@ -MF $(*D)/$(*F).d
 
 # Same as -I$(SRC_PATH) -I., but for the nested source/object directories
-QEMU_CFLAGS += -I$(D) -I$(@D)
+QEMU_INCLUDES += -I$(D) -I$(@D)
 
 %.o: %.c
$(call quiet-command,$(CC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) 
$(QEMU_DGFLAGS) $(CFLAGS) -c -o $@ $,  CC$(TARGET_DIR)$@)
-- 
1.8.1.5




[Qemu-devel] [PATCH v2 3/5] S390: BIOS create link to src folder for .img file

2013-04-29 Thread Dominik Dingel
For *.img files, there will be a link created directly to the src folder,
like for all other blobs.

Signed-off-by: Dominik Dingel din...@linux.vnet.ibm.com

diff --git a/configure b/configure
index cb29b69..2ab54ec 100755
--- a/configure
+++ b/configure
@@ -4389,6 +4389,7 @@ for bios_file in \
 $source_path/pc-bios/*.aml \
 $source_path/pc-bios/*.rom \
 $source_path/pc-bios/*.dtb \
+$source_path/pc-bios/*.img \
 $source_path/pc-bios/openbios-* \
 $source_path/pc-bios/palcode-*
 do
-- 
1.7.9.5




[Qemu-devel] [PATCH v2 2/5] S390: BIOS check for file

2013-04-29 Thread Dominik Dingel
Add a check if the BIOS blob exists before trying to load.

Signed-off-by: Dominik Dingel din...@linux.vnet.ibm.com

diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
index bcbba7c..f7a570e 100644
--- a/hw/s390x/ipl.c
+++ b/hw/s390x/ipl.c
@@ -93,6 +93,10 @@ static int s390_ipl_init(SysBusDevice *dev)
 }
 
 bios_filename = qemu_find_file(QEMU_FILE_TYPE_BIOS, bios_name);
+if (bios_filename == NULL) {
+hw_error(could not find stage1 bootloader\n);
+}
+
 bios_size = load_elf(bios_filename, NULL, NULL, ipl-start_addr, NULL,
  NULL, 1, ELF_MACHINE, 0);
 if (bios_size == -1UL) {
-- 
1.7.9.5




[Qemu-devel] [PATCH v2 0/5] Enhance s390 BIOS to enable boot device selection

2013-04-29 Thread Dominik Dingel
This patchset allows the s390 platform to boot from a specified virtio-ccw-blk 
device, passed on the commandline. 

v1 - v2
- no loadparm will be used
- the virtio devices will not be automatically inserted in the boot order
- if there is no boot device in the boot order we will fallback to the first 
device
- assign the boot value in the start block 
- refactoring of the s390_ipl_cpu function

Dominik Dingel (5):
  S390: Add virtio-blk boot
  S390: BIOS check for file
  S390: BIOS create link to src folder for .img file
  S390: BIOS boot from given device
  S390: Sync Blob with source changes

 configure|1 +
 hw/s390x/ipl.c   |   30 +++---
 pc-bios/s390-ccw.img |  Bin 9432 - 17528 bytes
 pc-bios/s390-ccw/main.c  |   25 +++--
 pc-bios/s390-ccw/start.S |2 ++
 5 files changed, 49 insertions(+), 9 deletions(-)

-- 
1.7.9.5




[Qemu-devel] [PATCH v2 1/5] S390: Add virtio-blk boot

2013-04-29 Thread Dominik Dingel
Check for a kernel IPL entry and load kernel image if one was specified.
If no kernel image was supplied and no boot device was specified or the boot 
device
is not of type virtio-blk-ccw, print an error message and exit.

Signed-off-by: Christian Paro cp...@us.ibm.com
Signed-off-by: Dominik Dingel din...@linux.vnet.ibm.com

diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
index ace5ff5..bcbba7c 100644
--- a/hw/s390x/ipl.c
+++ b/hw/s390x/ipl.c
@@ -16,6 +16,8 @@
 #include elf.h
 #include hw/loader.h
 #include hw/sysbus.h
+#include hw/s390x/virtio-ccw.h
+#include hw/s390x/css.h
 
 #define KERN_IMAGE_START0x01UL
 #define KERN_PARM_AREA  0x010480UL
@@ -57,13 +59,22 @@ typedef struct S390IPLState {
 } S390IPLState;
 
 
-static void s390_ipl_cpu(uint64_t pswaddr)
+static void s390_ipl_cpu(uint64_t pswaddr, VirtioCcwDevice *dev)
 {
 S390CPU *cpu = S390_CPU(qemu_get_cpu(0));
 CPUS390XState *env = cpu-env;
 
 env-psw.addr = pswaddr;
 env-psw.mask = IPL_PSW_MASK;
+
+if (dev) {
+env-regs[7] = dev-sch-cssid  24 |
+   dev-sch-ssid  16 |
+   dev-sch-devno;
+} else {
+env-regs[7] = -1;
+}
+
 s390_add_running_cpu(cpu);
 }
 
@@ -151,8 +162,17 @@ static Property s390_ipl_properties[] = {
 static void s390_ipl_reset(DeviceState *dev)
 {
 S390IPLState *ipl = S390_IPL(dev);
-
-s390_ipl_cpu(ipl-start_addr);
+
+if (ipl-kernel) {
+s390_ipl_cpu(ipl-start_addr, NULL);
+} else {
+/* is there a bootable device? */
+DeviceState *dev_st = get_boot_device(0);
+VirtioCcwDevice *ccw_dev = (VirtioCcwDevice *) object_dynamic_cast(
+OBJECT((dev_st-parent_obj)), virtio-blk-ccw);
+   
+s390_ipl_cpu(ipl-start_addr, ccw_dev);
+}
 }
 
 static void s390_ipl_class_init(ObjectClass *klass, void *data)
-- 
1.7.9.5




Re: [Qemu-devel] [RFC PATCH v2] Throttle-down guest when live migration does not converge.

2013-04-29 Thread Eric Blake
On 04/27/2013 02:50 PM, Chegu Vinod wrote:
 Busy enterprise workloads hosted on large sized VM's tend to dirty
 memory faster than the transfer rate achieved via live guest migration.
 Despite some good recent improvements ( using dedicated 10Gig NICs
 between hosts) the live migration does NOT converge.
 

 
 No exernal trigger is required (unlike option 1) and it can co-exist

s/exernal/external/

 with enhancements being pursued as part of Option 2 (e.g. RDMA).
 
 Thanks to Juan and Paolo for their useful suggestions.
 

 
 ---
 
 (qemu) info migrate
 capabilities: xbzrle: off auto-converge: on   

This part looks nice.

I'm not reviewing the entire patch (I'm not an expert on the internals
of migration), but just the interface:

 +++ b/qapi-schema.json
 @@ -599,10 +599,14 @@
  #  This feature allows us to minimize migration traffic for certain 
 work
  #  loads, by sending compressed difference of the pages
  #
 +# @auto-converge: Controls whether or not the we want the migration to
 +#  automaticially detect and force convergence by slowing

s/automaticially/automatically/

 +#  down the guest. Disabled by default.

Missing a (since 1.6) designation.

Also, use of first-person (us, we) in docs seems a bit unprofessional,
although you were copying pre-existing usage.  How about:

@xbzrle: Migration supports xbzrle (Xor Based Zero Run Length Encoding),
 which minimizes migration traffic for certain workloads by
 sending compressed differences of active pages

@auto-converge: Migration supports automatic throttling of guest
activity to force convergence (since 1.6)

-- 
Eric Blake   eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature


[Qemu-devel] [PATCH v2 4/5] S390: BIOS boot from given device

2013-04-29 Thread Dominik Dingel
Use the passed device, if there is no device, use the first applicable device.

Signed-off-by: Dominik Dingel din...@linux.vnet.ibm.com

diff --git a/pc-bios/s390-ccw/main.c b/pc-bios/s390-ccw/main.c
index fd40fa5..206979f 100644
--- a/pc-bios/s390-ccw/main.c
+++ b/pc-bios/s390-ccw/main.c
@@ -12,6 +12,7 @@
 
 struct subchannel_id blk_schid;
 char stack[PAGE_SIZE * 8] __attribute__((__aligned__(PAGE_SIZE)));
+uint64_t boot_value;
 
 void virtio_panic(const char *string)
 {
@@ -20,15 +21,20 @@ void virtio_panic(const char *string)
 while (1) { }
 }
 
-static void virtio_setup(void)
+static void virtio_setup(uint64_t dev_info)
 {
 struct schib schib;
 int i;
 int r;
 bool found = false;
-
+uint16_t dev_no;
 blk_schid.one = 1;
 
+if (dev_info != -1) {
+dev_no = dev_info  0x; 
+debug_print_int(device no. , dev_no);
+}
+
 for (i = 0; i  0x1; i++) {
 blk_schid.sch_no = i;
 r = stsch_err(blk_schid, schib);
@@ -36,9 +42,14 @@ static void virtio_setup(void)
 break;
 }
 if (schib.pmcw.dnv) {
-if (virtio_is_blk(blk_schid)) {
-found = true;
-break;
+if (dev_info != -1  schib.pmcw.dev != dev_no) {
+continue;
+}
+else {
+if (virtio_is_blk(blk_schid)) {
+found = true;
+break;
+}
 }
 }
 }
@@ -53,7 +64,9 @@ static void virtio_setup(void)
 int main(void)
 {
 sclp_setup();
-virtio_setup();
+debug_print_int(boot reg[7]\n, boot_value);
+virtio_setup(boot_value);
+
 if (zipl_load()  0)
 sclp_print(Failed to load OS from hard disk\n);
 disabled_wait();
diff --git a/pc-bios/s390-ccw/start.S b/pc-bios/s390-ccw/start.S
index 09deee7..5d5df0d 100644
--- a/pc-bios/s390-ccw/start.S
+++ b/pc-bios/s390-ccw/start.S
@@ -14,6 +14,8 @@
 _start:
 
 larl   %r15, stack + 0x8000/* Set up stack */
+larl%r6, boot_value
+stg %r7, 0(%r6) /* save the boot_value before any function calls */
 j  main/* And call C */
 
 /*
-- 
1.7.9.5




Re: [Qemu-devel] [PATCH] virtio-net: count VIRTIO_NET_F_MAC when calculating config_len

2013-04-29 Thread KONRAD Frédéric

On 29/04/2013 16:42, Jesse Larrew wrote:

On 04/25/2013 01:59 AM, Michael S. Tsirkin wrote:

On Thu, Apr 25, 2013 at 02:21:29PM +0800, Jason Wang wrote:

Commit 14f9b664 (hw/virtio-net.c: set config size using host features) tries to
calculate config size based on the host features. But it forgets the
VIRTIO_NET_F_MAC were always set for qemu later. This will lead a zero config
len for virtio-net device when both VIRTIO_NET_F_STATUS and VIRTIO_NET_F_MQ were
disabled form command line. Then qemu will crash when user tries to read the
config of virtio-net.

Fix this by counting VIRTIO_NET_F_MAC and make sure the config at least contains
the mac address.

Cc: Jesse Larrew jlar...@linux.vnet.ibm.com
Signed-off-by: Jason Wang jasow...@redhat.com
---
  hw/net/virtio-net.c |3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 70c8fce..33a70ef 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1264,7 +1264,8 @@ static void virtio_net_guest_notifier_mask(VirtIODevice 
*vdev, int idx,
  
  void virtio_net_set_config_size(VirtIONet *n, uint32_t host_features)

  {
-int i, config_size = 0;
+/* VIRTIO_NET_F_MAC can't be disabled from qemu side */
+int i, config_size = feature_sizes[0].end;

This would be cleaner:
host_features |= (1  VIRTIO_NET_F_MAC);

no need for a comment then.


It seems to me that the real problem here is that host_features isn't
properly populated before virtio_net_set_config_size() is called. Looking
at virtio_device_init(), we can see why:

static int virtio_device_init(DeviceState *qdev)
{
 VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
 VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(qdev);
 assert(k-init != NULL);
 if (k-init(vdev)  0) {
 return -1;
 }
 virtio_bus_plug_device(vdev);
 return 0;
}

virtio_net_set_config_size() is currently being called as part of the
k-init call, but the host_features aren't properly setup until the device
is plugged into the bus using virtio_bus_plug_device().

After talking with mdroth, I think the proper way to fix this would be to
extend VirtioDeviceClass to include a calculate_config_size() method that
can be called at the appropriate time during device initialization like so:

static int virtio_device_init(DeviceState *qdev)
{
 VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
 VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(qdev);
 assert(k-init != NULL);
 if (k-init(vdev)  0) {
 return -1;
 }
 virtio_bus_plug_device(vdev);
+   if (k-calculate_config_size  k-calculate_config_size(vdev)  0) {
+   return -1;
+   }
 return 0;
}

This would ensure that host_features contains the proper data before any
devices try to make use of it to calculate the config size.

Good point, I didn't saw that.

but this was not the case with commit 14f9b664 no?




  for (i = 0; feature_sizes[i].flags != 0; i++) {
  if (host_features  feature_sizes[i].flags) {
  config_size = MAX(feature_sizes[i].end, config_size);
--
1.7.1

Jesse Larrew
Software Engineer, KVM Team
IBM Linux Technology Center
Phone: (512) 973-2052 (T/L: 363-2052)
jlar...@linux.vnet.ibm.com







[Qemu-devel] [PATCH v2 5/5] S390: Sync Blob with source changes

2013-04-29 Thread Dominik Dingel
Signed-off-by: Dominik Dingel din...@linux.vnet.ibm.com

diff --git a/pc-bios/s390-ccw.img b/pc-bios/s390-ccw.img
index 
149cf70140e9e690960b49337b4e5f419c452a86..4d2145ecb8d658e3a766272a15e15749afb01705
 100644
GIT binary patch
literal 17528
zcmeHPe{37qeSbWjL`sGv*SASk2$AUNR`BqDcNbG(c#{QI*bd6h|H8Hi0dhvPDD|
zHHvm!BiNKxz+5!xf^6u5qAi3@DveZa#H@nrDl|8P-v)wXoWh5*$-C($e~W)n4Y
zYgxC?_xs)*?^va=f%K07JV1PR?|pydf#^^yd%lY1OoVa4$`)$30Jk|2b?J|@TJ
zCLUv=NtBD2s1RX16Kt7WH+Trm$tPzNVry2;I3vRmUbo)@es(CufvT^f@f~3Kvh8
zYrCGOaZm(Bc^KQx-8!;oKyi(BtVh+6#DhPZHhG+(zFB6YQb+!pL}!VIsuSH~vBP
zEL|lFlq^uPK*6n3zRHSvOviKB@2`+P_jVD0woK4=oVO*$#;s{T;6W8|8zhGwr4|
zmWx`$qPEkp#xixbjhTsD3^O{z#NW-x(F-cL?*eDK^tOU?-;5i8Y{5lZ0L6Z*o;
zSwrZdMVEfNq@OdbGvLP@0BJI0m@$T7q-)dgeD@9Z0R$zagusRHr5E3!D@4^A
zNN;#CG7%x#4QoDYi14Fd?KBNBdbbF)W6T*uD|5STXNJUW@+oFmZ@1xZVU382)%;nN
zHNod+(54~#hHcx!isBqNcS6^NDb5OiJ685*zlu=0lO))NsM)xrf~5(aJLqcTm;U=
z%oY@*BI`t4r4aFb`75H@kwN;H9b-@dZ!R1)hOP^Y^cek#YdRqcG8Be5Fy%3qXNe
zNMA^|HX=yA%toGqx=2FtjL_Rzm3%(ug(K2EyAp07wgx`v;z+9%3gTpAbY0G=fi{2
z%EUkTW5U^+%NcmLqBE_UA@D+_6xa*60@7vX89l6yo+@F30VTUnNdDasLHxn~A
z1FK@4Bdb=0H26U$Sqb?;NC*q(F~%UqsGD=G=(Q*+|UZ1r`C%#qiH%uI?lJe2Fw(
z{u+7a1M;G-C~{4Batv~WmhW@rK+NVK2Yp(TEExhMua}CEaWB`UPe|;Ql=ncyLg`c
zQaS0$_9u)_c?^BX;uVi6Zw!gmOknT3V_%KZ7@K?NRFjFo6TA7sNW`h%QzGvvDdc
z8h|mGPx@(ceqGmNH(PjiusQrD#tP#ZF@hc;kg0uv!okq$oIka4xEzvh(o1!dJ^
zBy;%lBs1$rKB85bl@@+XXbuHK8=g^nTU`v4=9Iw+8(4_#{8;?V2zuIrk2Y@Y}?~0
z#62ol)LWOR)O9S^4DWtkAXJ%f@OzXR0GanMBRX--`Zu2XEU3w*zMBM3-lsGh+Gg
zNfXZDG(+euhM}W22+q)BatxnR|qpGsh8?ko-=*V?QtdQc6~_5Io0)Lb5UkaN
zurac1nN6CQssY7X(IO$h^ETp%`lMxs?0@^6*#N3Vlx$V;J+{5q`)NNu7o)MJ{
z@y%Qm_fj^*FWs;HFJxD*dJB=S;3#j)xfcG*jQ=_rwq2gN2zNM0|B9s_GE3Wa(S%
zfm-5$%$dy82?IOQG%`q3^kMBhY8Crh*J28ID}r6J|oLeu3Z0LWy7?nWULN_wJ1g
zBs4XEOBQ$pu)HT+x4dgiD+*~o#~i+`C=Mx#pKvKY4Jx6fHseMSQopPzlHpx?aft
zX|XO#)VHa8Lo6W;Ag5(_(TQZPux?^s66{4?9`JP-ubLa=nvS;Cq;no2p|KLKvSG
zB4W4wAD(!NBV~U+ts%TSv$$Gx`A}K_NJtOb*BoD6ei^(*S;Ro4)ox4ru1{NOkg`8
zPzW8?A3p5N;C`q!gU!6Dq3Ox!@W`EXFt%R1cW6{S=u@zm3aoRvvf{p|dPw=jr
z7Ue`A(p0NC4KYn~%b3$Cc09Qcu1@#j_wFO;V(b})tSIQ;b1o`KdmADeA;#bOTO@
z0UCI!bk}0J|e!SDG@%0`ZCHB}gM@f}!fSxSl_Q9T_QxiIhRmE1iUReuanh}4A{
zuMoivh9%lcF11XAtANOmoeyXDBhb88?2G6)h+b$u-mn(P6Z6U9vCHy2oB7%M~t?
zt579rFQw?C`nL{#8Bx5a!JBL%IqCIN8TbPsY496n5JlkJ;7^Qbu-g+k3C}qk@_Yy
z;p--DcFPj6#8xQb3D5qi4g=nE7(6gA{QZ3x^Uozk~DQp3;WIr5_=^cRGosnv4N
zs~Sug^lcC3AYMdaED4=4csy45hag;-!Asx3D89;tcs)=(Yp6{P=z_2Mh``qD~L
zhVUC`gm{c|7is+U?m_rpY#tl*jM;aA+`5=om+CVVE@@rO8*SaTL!HY9r6kPI
zvN{oO%T8S=_=%+;+#)QR2SfB%%5G`HQt)WxjDU(NgaUR4Qegtr|XOB3YCibx)
z{GFQ;+VUil-_RP3(gbNS`G+$D+9s|Tzx^jy40o~=UO;Uu7_Q~e}P@}#o~cifTK
zziKh8AF5ttNQ9|=wi}FFjg-2F;t;{JwAVo%r)a$spH-9dg^s;jP46X3NKwvv_M
zBaqYLaYR3wP7uZ+E-Uuc`L8voF*STaxNdsL}CIbxBpym^((;73w?B800(hA6aq
z^sl}!XuXG=wwl2MtMCqFr#dqNddmtj@8iaO8lcegpVhfHTSeagEnBGqR2Im_9t2U
zgQWfY=LqtMnIC672lUZcP#S(SYYnf)TbJmSQI_g+4=l{M4s)u(PGhCpuw^mb6p
zfS!z-2Udz3#B!l#qn`uMTcvk$?Nmi!y9wH{%c!!!Y9zz*lh9z2PD$1TpRZ-K^Bj8O
zFxOs+f8dJsf8`U^g9p+@1LL`do1vzUbg@rzRt#-Ttr$%T?Q!R+|dqeZ!#2CWl_c
zLl2pO{WL(;oaEN0AvZX+yPi1${qq#VgG;)Jo!hqW9XglW3R$F(!0lztUm*U@^Qo
z2w;5hB2LAvx6q?kBlopgur6z0EYWNaN_o5c#}|@LPoS;GfWn?db9R_k-61qhR
zzcU)uv2w@49r*3VR6*e_9D7uadnTHp;I)vHeahM5!kVfJ`kR?hfmdB_xouBc6juo
z%QkFHea#2bcD1CvmiEgJ#ApK?^|A$c(lAm(a}po2QYRO1t?kfdYXe_X_?qG;(Ds%
zNfOPUQEuLm4g!hJlNWrAS;UCaC`iK8Gmsc4d4Ti7M41Z)EU!rrMoT7yr6*Yt6
zQFd;g{iVr0ZOS@%E7eGfO8X~}Wkjq4w$p(lYcYp!?gz5jdev@8?kQZJpPXnu}r
z9aodJOlK4n=sZ11X8@}7-1!ksgw~gyku(vt$dxw3(B#`G#R*=Zw7kx%4cMpAWyhB
zh)5{~M-tZpic*53Xn`!}JXN!abJFzYB-vDZ3pOphDe-2Tx1-EL_QSBxIdG?l;?p0r
zquQTE4G2H*Lb4+({O6*@@BHemkd!sQZURjvc3Tl6*v%Nn^h(GYrwMs06UC(fak@
z@OJVR#w=pS@f3=Jwbk88{P*DN{Tnw^!Kq`U?STrp2kXeaeppp7jME$kbtf6}Kv
z`8f=YrXXu+MD@v`6NfqKbNFdWVSl^U^AqkBTZhU%)eB8K1M17FB(FE`38~Ci$
z1f7JojpYCBH*=^+|$k~yHecAUQQL)@)e+)Plc4$H3Utg#GLF(E7Y%V^9JORP`FZ
zt7ZO9MtQXNUrx%f*gS6vZtq5qI-Hf#QWs(C6dHrOT-aQOo%qm925_s?V|?;u9oi
z)Y2gtl{nqVnBm?CK5Zmj5iz`XTA!bDeT69zat$NNAR}xdt_#PB6UtNx(IX?k$gH
z_R~9CWYXTzE#)!j3(sZh4CD#U=jh4McT5vD#($)^*S20m)@09{|2;IjB;Q9C#0I
z+tChInts+txNfSy7JyeaTGX=4oq2-EbyvLeWBvwXnRp|39!u9?j$bgZ^qF3jIq|}
z_xKH31Tue@G|p^kYQ%ZE68`_bI?BEiTXl@EmWn3Qpp$~b!^6w2mt*2`uO;`2wj
z{)5?GK-5pffdkbjE`f`L|_mPK2)IkvQCK_9g30u{UX+NTkwh_S_pEA|Tkv5d
zcul1PF9a$jF8Y?p=2^`rn--Q?D8ly|pXR+Z{L4NwYWE6*nJ!+q#9y5EoQgJh$
z7fvOIQ4Kle%qJmJJHpfh?~c{jwTKZf=~1vH3zzn9_#K)n_X%1P;c_^Q$lpb0DI
zNXn^h33jMIH2@fQz6iZiREmM_vXHg;X@*q!tuU7Vst9e-@eg7J?=YurOwW5dEp-
z(NxzlGu?Hlw_8Y)93bvqxW*zl6OyMA-2)CUM=BzHzbVakl7H6;e(E|QpIeg0d*g6H
z+WdSfk?uAJ(p~A}17yjbUpEipXf`Z3-kWfJx+aOLGi2cD;Cb`=jPVsZ^3z;k=`
zumhXY@#f)V-;u=8EbuqxlfsZq2#Gep3D365mn1(T4jTjAt;ui18JS=WY8unXjE
z`kFC65!r?9by~xbJ%V%+*!kEQ4XWN$m7c^{pVG(1SZU4_@j3;gT?H-J0Z2Jo6
z1p#*jzc1ARcjZNlG26}~Q1yO{;Hv}fSDrEhVeAQIE)c|%bINaod+=XUAD~$obA7
z#z~B`80TK-F5g$Yy_i)u^m-q3?tHHO*TX_h1D7_uBEE1N`568YB2$jbjA=tIuN`
z#yE#@*0z6h5$}EkNkzxe~m`KEk!W`?)o;2vrvjI@PM^W?Gu5M)qzb_w+tg?=mLz`
zjIR4Nj0eS@zbgAm`E#LX!(XnbeofoGdX=`9K!5(vKfCZ#f|l@mZ2KZ?EbjKfk}rR
z5jg)w_i4cEjO(R;p5TcjU$Chdk#qySUb?N-j$e*40Keww3`cfwZMBFF#+3)J}+K%
z)++D26Vs;0q#cRCitCzAG`_pIN;$k@vKh{X~$Ep@BqL?^#2C%uzTPoAN*C4I~aJ;

Re: [Qemu-devel] [PATCH v2] linux-user: improve target_to_host_sock_type conversion

2013-04-29 Thread Andreas Färber
Am 23.04.2013 02:15, schrieb Petar Jovanovic:
 Thanks Aurelien for your comments.
 
 What others think? Can we submit this version of the patch? Riku? Richard, 
 Blue?

No objection but isn't that a frequent issue that mappings may need to
be extended from time to time? The way I've seen that handled is on a
case by case basis mapping from one known value to another, with
defaulting to whatever form of error reporting appropriate. Here it
seems that some cases were dropped and we are now defaulting to taking
the literal value where no difference is known. This may lead to silent
errors, whereas an abort as other extreme may prohibit use cases with no
value difference between host and target.

Andreas

 
 From: Aurelien Jarno [aurel...@aurel32.net]
 Sent: Monday, April 15, 2013 3:47 PM
 To: Petar Jovanovic
 Cc: qemu-devel@nongnu.org; Petar Jovanovic; riku.voi...@linaro.org; 
 r...@twiddle.net; blauwir...@gmail.com
 Subject: Re: [PATCH v2] linux-user: improve target_to_host_sock_type 
 conversion
 
 On Mon, Apr 01, 2013 at 05:49:39PM +0200, Petar Jovanovic wrote:
 From: Petar Jovanovic petar.jovano...@imgtec.com

 Previous implementation has failed to take into account different value of
 SOCK_NONBLOCK on target and host, and existence of SOCK_CLOEXEC.
 The same conversion has to be applied both for do_socket and do_socketpair,
 so the code has been isolated in a static inline function.
 The change is valid for architectures that define ARCH_HAS_SOCKET_TYPES,
 these are MIPS, SPARC and ALPHA now.

 enum sock_type in linux-user/socket.h has been extended to include
 TARGET_SOCK_CLOEXEC and TARGET_SOCK_NONBLOCK, similar to definition in libc.
 The patch also includes necessary code style changes (tab to spaces) in the
 header file in the MIPS #ifdef block touched by the change.

 Signed-off-by: Petar Jovanovic petar.jovano...@imgtec.com
 ---
  v2:

  - the patch defines ARCH_HAS_SOCKET_TYPES for MIPS, SPARC and ALPHA
  - values for sock_type are defined for SPARC and ALPHA in socket.h

  linux-user/socket.h  |  248 
 +-
  linux-user/syscall.c |   45 +
  2 files changed, 195 insertions(+), 98 deletions(-)

 diff --git a/linux-user/socket.h b/linux-user/socket.h
 index 339cae5..d2b05dc 100644
 --- a/linux-user/socket.h
 +++ b/linux-user/socket.h
 @@ -1,91 +1,104 @@

  #if defined(TARGET_MIPS)
 - // MIPS special values for constants
 -
 - /*
 -  * For setsockopt(2)
 -  *
 -  * This defines are ABI conformant as far as Linux supports these ...
 -  */
 - #define TARGET_SOL_SOCKET  0x
 -
 - #define TARGET_SO_DEBUG0x0001  /* Record debugging 
 information.  */
 - #define TARGET_SO_REUSEADDR0x0004  /* Allow reuse of local 
 addresses.  */
 - #define TARGET_SO_KEEPALIVE0x0008  /* Keep connections alive and 
 send
 -   SIGPIPE when they die.  */
 - #define TARGET_SO_DONTROUTE0x0010  /* Don't do local routing.  */
 - #define TARGET_SO_BROADCAST0x0020  /* Allow transmission of
 -   broadcast messages.  */
 - #define TARGET_SO_LINGER   0x0080  /* Block on close of a reliable
 -   socket to transmit pending data.  */
 - #define TARGET_SO_OOBINLINE 0x0100 /* Receive out-of-band data 
 in-band.  */
 - #if 0
 - To add: #define TARGET_SO_REUSEPORT 0x0200 /* Allow local address 
 and port reuse.  */
 - #endif
 -
 - #define TARGET_SO_TYPE 0x1008  /* Compatible name for 
 SO_STYLE.  */
 - #define TARGET_SO_STYLESO_TYPE /* Synonym */
 - #define TARGET_SO_ERROR0x1007  /* get error status and clear */
 - #define TARGET_SO_SNDBUF   0x1001  /* Send buffer size. */
 - #define TARGET_SO_RCVBUF   0x1002  /* Receive buffer. */
 - #define TARGET_SO_SNDLOWAT 0x1003  /* send low-water mark */
 - #define TARGET_SO_RCVLOWAT 0x1004  /* receive low-water mark */
 - #define TARGET_SO_SNDTIMEO 0x1005  /* send timeout */
 - #define TARGET_SO_RCVTIMEO 0x1006  /* receive timeout */
 - #define TARGET_SO_ACCEPTCONN   0x1009
 -
 - /* linux-specific, might as well be the same as on i386 */
 - #define TARGET_SO_NO_CHECK 11
 - #define TARGET_SO_PRIORITY 12
 - #define TARGET_SO_BSDCOMPAT14
 +/* MIPS special values for constants */
 +
 +/*
 + * For setsockopt(2)
 + *
 + * This defines are ABI conformant as far as Linux supports these ...
 + */
 +#define TARGET_SOL_SOCKET  0x
 +
 +#define TARGET_SO_DEBUG0x0001  /* Record debugging information. 
 */
 +#define TARGET_SO_REUSEADDR0x0004  /* Allow reuse of local 
 addresses. */
 +#define TARGET_SO_KEEPALIVE0x0008  /* Keep connections alive and 
 send
 +  SIGPIPE when they die. */
 +  

[Qemu-devel] [PATCH 0/7 v7 for 1.5] target-i386: CPU hot-add with cpu-add QMP command

2013-04-29 Thread Igor Mammedov
Implements alternative way for hot-adding CPU using cpu-add QMP command,
which could be useful until it would be possible to add CPUs via device_add.

To hot-add CPU use following command from qmp-shell:
 cpu-add id=[0..max-cpus - 1)

git tree for testing: https://github.com/imammedo/qemu/tree/cpu_add.v7

based on qom-cpu tree

v7-v6:
  * skip already applied patches
  * rename icc-bus instance name to icc
  * pass icc_bridge from board as argument down CPU creation call chain,
instead of dynamically resolving it for each CPU.

v6-v5:
  * override hot_add_cpu hook statically
  * extend and use memory_region_find() in IOAPIC
  * s/signal_cpu_creation/tcg_signal_cpu_creation/
  * add since 1.5 to cpu-addQAPI schema description

v5-v4:
  * style fixes
  * new helper qemu_for_each_cpu()
  * switch to qemu_for_each_cpu() in cpu_exists()
  * pc: update rtc ... patch make depend it on mc146818rtc: QOM'ify
and use QOM cast style
  * call CPU added notifier right before CPU becomes runable
  * s/resume_vcpu/cpu_resume/
  * acpi/piix4: add spec documentation for QEMU-Seabios CPU hotplug
interface
  * use error_propagate() in pc_new_cpu()
  * skip cpu_exists() check in apic-id property setter if new value is
the same as current
  * embed icc-bus inside icc-bridge and use qbus_create_inplace()
  * move include/hw/i386/icc_bus.h into include/hw/cpu/
  * make missing icc-bus fatal error for softmmu target
  * split move APIC to ICC bus and move IOAPIC to ICC bus on smaller
patches
  * use qdev_get_parent_bus() to get parent bus
  * split add cpu-add command... on smaller patches

v4-v3:
  * 'id' in cpu-add command will be a thread number instead of APIC ID
  * split off resume_vcpu() into separate patch
  * move notifier from rtc code into pc.c

v2-v3:
  * use local error  propagate_error() instead of operating on
passed in errp in several places
  * replace CPUClass.get_firmware_id() with CPUClass.get_arch_id()
  * leave IOAPIC creation to board and just set bus to icc-bus
  * include kvm-stub.o in cpu libary if no KVM is configured
  * create resume_vcpu() stub and include it in libqemustub,
and use it directly instead of CPU method
  * acpi_piix4: s/cpu_add_notifier/cpu_added_notifier/

v1-v2:
  * generalize cpu sync to KVM, resume and hot-plug notification and
invoke them form CPUClass, to make available to all targets.
  * introduce cpu_exists() and CPUClass.get_firmware_id() and use
the last one in acpi_piix to make code target independent.
  * move IOAPIC to ICC bus, it was suggested and easy to convert.
  * leave kvmvapic as SysBusDevice, it doesn't affect hot-plug and
created only once for all APIC instances. I haven't found yet
good/clean enough way to convert it to ICCDevice. May be follow-up
though.
  * split one big ICC patch into several, one per converted device
  * add cpu_hot_add hook to machine and implement it for target-i386,
instead of adding stabs. Could be used by other targets to
implement cpu-add.
  * pre-allocate linksCPU for all possible CPUs and make them available
at /machine/icc-bridge/cpu[0..N] QOM path, so users could find out
possible/free CPU IDs to use in cpu-add command.


Igor Mammedov (7):
  target-i386: Introduce ICC bus/device/bridge
  target-i386: Attach ICC bus to CPU on its creation
  target-i386: Move APIC to ICC bus
  pc: pass QEMUMachineInitArgs down to pc_cpus_init()
  add hot_add_cpu hook to QEMUMachine and export machine_args
  target-i386: implement machine-hot_add_cpu hook
  QMP: add cpu-add command

 MAINTAINERS|   6 ++
 default-configs/i386-softmmu.mak   |   1 +
 default-configs/x86_64-softmmu.mak |   1 +
 hw/cpu/Makefile.objs   |   1 +
 hw/cpu/icc_bus.c   | 119 +
 hw/i386/pc.c   |  47 ---
 hw/i386/pc_piix.c  |  74 ---
 hw/i386/pc_q35.c   |  31 +-
 hw/intc/apic_common.c  |  18 --
 include/hw/boards.h|   3 +
 include/hw/cpu/icc_bus.h   |  82 +
 include/hw/i386/apic_internal.h|   6 +-
 include/hw/i386/pc.h   |   4 +-
 qapi-schema.json   |  13 
 qmp-commands.hx|  23 +++
 qmp.c  |  10 
 target-i386/cpu.c  |  27 -
 target-i386/cpu.h  |   3 +-
 vl.c   |   8 ++-
 19 files changed, 378 insertions(+), 99 deletions(-)
 create mode 100644 hw/cpu/icc_bus.c
 create mode 100644 include/hw/cpu/icc_bus.h

-- 
1.8.2.1




[Qemu-devel] [PATCH 1/7] target-i386: Introduce ICC bus/device/bridge

2013-04-29 Thread Igor Mammedov
Provides a hotpluggable bus for APIC and CPU.

* icc-bridge will serve as a parent for icc-bus and provide
  mmio mapping services to child icc-devices.
* icc-device will replace SysBusDevice as a parent of APIC
  and IOAPIC devices.

Signed-off-by: Igor Mammedov imamm...@redhat.com
[AF: QOM cleanups]
Signed-off-by: Andreas Färber afaer...@suse.de
---
v2:
 - rename instance name of icc-bus to icc

Signed-off-by: Igor Mammedov imamm...@redhat.com
---
 MAINTAINERS|   6 ++
 default-configs/i386-softmmu.mak   |   1 +
 default-configs/x86_64-softmmu.mak |   1 +
 hw/cpu/Makefile.objs   |   1 +
 hw/cpu/icc_bus.c   | 109 +
 hw/i386/pc_piix.c  |   7 +++
 hw/i386/pc_q35.c   |   7 +++
 include/hw/cpu/icc_bus.h   |  79 +++
 8 files changed, 211 insertions(+)
 create mode 100644 hw/cpu/icc_bus.c
 create mode 100644 include/hw/cpu/icc_bus.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 4dfd8bf..be02724 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -644,6 +644,12 @@ F: qom/cpu.c
 F: include/qemu/cpu.h
 F: target-i386/cpu.c
 
+ICC Bus
+M: Igor Mammedov imamm...@redhat.com
+S: Supported
+F: include/hw/cpu/icc_bus.h
+F: hw/cpu/icc_bus.c
+
 Device Tree
 M: Peter Crosthwaite peter.crosthwa...@petalogix.com
 M: Alexander Graf ag...@suse.de
diff --git a/default-configs/i386-softmmu.mak b/default-configs/i386-softmmu.mak
index 368a776..833e722 100644
--- a/default-configs/i386-softmmu.mak
+++ b/default-configs/i386-softmmu.mak
@@ -44,3 +44,4 @@ CONFIG_LPC_ICH9=y
 CONFIG_PCI_Q35=y
 CONFIG_APIC=y
 CONFIG_IOAPIC=y
+CONFIG_ICC_BUS=y
diff --git a/default-configs/x86_64-softmmu.mak 
b/default-configs/x86_64-softmmu.mak
index 2711b83..b749eb7 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -44,3 +44,4 @@ CONFIG_LPC_ICH9=y
 CONFIG_PCI_Q35=y
 CONFIG_APIC=y
 CONFIG_IOAPIC=y
+CONFIG_ICC_BUS=y
diff --git a/hw/cpu/Makefile.objs b/hw/cpu/Makefile.objs
index a49ca04..4461ece 100644
--- a/hw/cpu/Makefile.objs
+++ b/hw/cpu/Makefile.objs
@@ -1,4 +1,5 @@
 obj-$(CONFIG_ARM11MPCORE) += arm11mpcore.o
 obj-$(CONFIG_ARM9MPCORE) += a9mpcore.o
 obj-$(CONFIG_ARM15MPCORE) += a15mpcore.o
+obj-$(CONFIG_ICC_BUS) += icc_bus.o
 
diff --git a/hw/cpu/icc_bus.c b/hw/cpu/icc_bus.c
new file mode 100644
index 000..3ac8eeb
--- /dev/null
+++ b/hw/cpu/icc_bus.c
@@ -0,0 +1,109 @@
+/* icc_bus.c
+ * emulate x86 ICC (Interrupt Controller Communications) bus
+ *
+ * Copyright (c) 2013 Red Hat, Inc
+ *
+ * Authors:
+ * Igor Mammedov imamm...@redhat.com
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see http://www.gnu.org/licenses/
+ */
+#include hw/cpu/icc_bus.h
+#include hw/sysbus.h
+
+/* icc-bridge implementation */
+
+static void icc_bus_init(Object *obj)
+{
+BusState *b = BUS(obj);
+
+b-allow_hotplug = true;
+}
+
+static const TypeInfo icc_bus_info = {
+.name = TYPE_ICC_BUS,
+.parent = TYPE_BUS,
+.instance_size = sizeof(ICCBus),
+.instance_init = icc_bus_init,
+};
+
+
+/* icc-device implementation */
+
+static void icc_device_realize(DeviceState *dev, Error **errp)
+{
+ICCDevice *id = ICC_DEVICE(dev);
+ICCDeviceClass *idc = ICC_DEVICE_GET_CLASS(id);
+
+if (idc-init) {
+if (idc-init(id)  0) {
+error_setg(errp, %s initialization failed.,
+   object_get_typename(OBJECT(dev)));
+}
+}
+}
+
+static void icc_device_class_init(ObjectClass *oc, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(oc);
+
+dc-realize = icc_device_realize;
+dc-bus_type = TYPE_ICC_BUS;
+}
+
+static const TypeInfo icc_device_info = {
+.name = TYPE_ICC_DEVICE,
+.parent = TYPE_DEVICE,
+.abstract = true,
+.instance_size = sizeof(ICCDevice),
+.class_size = sizeof(ICCDeviceClass),
+.class_init = icc_device_class_init,
+};
+
+
+/*  icc-bridge implementation */
+
+typedef struct ICCBridgeState {
+/* private */
+SysBusDevice parent_obj;
+/* public */
+
+ICCBus icc_bus;
+} ICCBridgeState;
+
+#define ICC_BRIGDE(obj) OBJECT_CHECK(ICCBridgeState, (obj), TYPE_ICC_BRIDGE)
+
+static void icc_bridge_init(Object *obj)
+{
+ICCBridgeState *s = ICC_BRIGDE(obj);
+
+qbus_create_inplace(s-icc_bus, TYPE_ICC_BUS, DEVICE(s), icc);
+}
+
+static const TypeInfo icc_bridge_info = {
+.name  = 

[Qemu-devel] [PATCH 5/7] add hot_add_cpu hook to QEMUMachine and export machine_args

2013-04-29 Thread Igor Mammedov
hot_add_cpu hook should be overriden by target that implements
cpu hot-add via cpu-add QMP command.

Make machine_args available globaly, it allows to reuse
machine_args-cpu_model during hotplug, instead of adding target
specific globals to keep a copy of cpu_model.

Signed-off-by: Igor Mammedov imamm...@redhat.com
---
v2:
  * convert stack veriable args to global machine_args
  * don't move current_machine before machine-init(), override hot_add_cpu
staticaly instead.
---
 include/hw/boards.h | 3 +++
 vl.c| 8 ++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/include/hw/boards.h b/include/hw/boards.h
index 425bdc7..657f379 100644
--- a/include/hw/boards.h
+++ b/include/hw/boards.h
@@ -18,6 +18,8 @@ typedef struct QEMUMachineInitArgs {
 const char *cpu_model;
 } QEMUMachineInitArgs;
 
+extern QEMUMachineInitArgs machine_args;
+
 typedef void QEMUMachineInitFunc(QEMUMachineInitArgs *args);
 
 typedef void QEMUMachineResetFunc(void);
@@ -43,6 +45,7 @@ typedef struct QEMUMachine {
 GlobalProperty *compat_props;
 struct QEMUMachine *next;
 const char *hw_version;
+void (*hot_add_cpu)(const int64_t id, Error **errp);
 } QEMUMachine;
 
 int qemu_register_machine(QEMUMachine *m);
diff --git a/vl.c b/vl.c
index 1e7d474..3fe5e94 100644
--- a/vl.c
+++ b/vl.c
@@ -179,6 +179,8 @@ int main(int argc, char **argv)
 #define MAX_VIRTIO_CONSOLES 1
 #define MAX_SCLP_CONSOLES 1
 
+QEMUMachineInitArgs machine_args;
+
 static const char *data_dir[16];
 static int data_dir_idx;
 const char *bios_name = NULL;
@@ -4291,7 +4293,8 @@ int main(int argc, char **argv, char **envp)
 
 qdev_machine_init();
 
-QEMUMachineInitArgs args = { .ram_size = ram_size,
+machine_args = (QEMUMachineInitArgs){
+ .ram_size = ram_size,
  .boot_device = (boot_devices[0] == '\0') ?
 machine-boot_order :
 boot_devices,
@@ -4299,7 +4302,8 @@ int main(int argc, char **argv, char **envp)
  .kernel_cmdline = kernel_cmdline,
  .initrd_filename = initrd_filename,
  .cpu_model = cpu_model };
-machine-init(args);
+
+machine-init(machine_args);
 
 cpu_synchronize_all_post_init();
 
-- 
1.8.2.1




[Qemu-devel] [PATCH 4/7] pc: pass QEMUMachineInitArgs down to pc_cpus_init()

2013-04-29 Thread Igor Mammedov
It allows to store default cpu_model if none was specified.

As side effect reduces size of the pc_piix.c code.

Signed-off-by: Igor Mammedov imamm...@redhat.com
---
 hw/i386/pc.c | 13 ++-
 hw/i386/pc_piix.c| 66 +---
 hw/i386/pc_q35.c | 23 +++---
 include/hw/i386/pc.h |  3 ++-
 4 files changed, 34 insertions(+), 71 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index ce9357e..26644a1 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -915,23 +915,23 @@ static X86CPU *pc_new_cpu(const char *cpu_model, int64_t 
apic_id,
 return cpu;
 }
 
-void pc_cpus_init(const char *cpu_model, DeviceState *icc_bridge)
+void pc_cpus_init(QEMUMachineInitArgs *args, DeviceState *icc_bridge)
 {
 int i;
 X86CPU *cpu = NULL;
 Error *error = NULL;
 
 /* init CPUs */
-if (cpu_model == NULL) {
+if (args-cpu_model == NULL) {
 #ifdef TARGET_X86_64
-cpu_model = qemu64;
+args-cpu_model = qemu64;
 #else
-cpu_model = qemu32;
+args-cpu_model = qemu32;
 #endif
 }
 
 for (i = 0; i  smp_cpus; i++) {
-cpu = pc_new_cpu(cpu_model, x86_cpu_apic_id_from_index(i),
+cpu = pc_new_cpu(args-cpu_model, x86_cpu_apic_id_from_index(i),
  icc_bridge, error);
 if (error) {
 fprintf(stderr, %s\n, error_get_pretty(error));
@@ -943,7 +943,8 @@ void pc_cpus_init(const char *cpu_model, DeviceState 
*icc_bridge)
 /* map APIC MMIO area if CPU has APIC */
 if (cpu  cpu-env.apic_state) {
 /* XXX: what if the base changes? */
-sysbus_mmio_map_overlap(icc_bridge, 0, APIC_DEFAULT_ADDRESS, 0x1000);
+sysbus_mmio_map_overlap(SYS_BUS_DEVICE(icc_bridge), 0,
+APIC_DEFAULT_ADDRESS, 0x1000);
 }
 }
 
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 2190f0a..bdfac59 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -59,12 +59,7 @@ static const int ide_irq[MAX_IDE_BUS] = { 14, 15 };
 /* PC hardware initialisation */
 static void pc_init1(MemoryRegion *system_memory,
  MemoryRegion *system_io,
- ram_addr_t ram_size,
- const char *boot_device,
- const char *kernel_filename,
- const char *kernel_cmdline,
- const char *initrd_filename,
- const char *cpu_model,
+ QEMUMachineInitArgs *args,
  int pci_enabled,
  int kvmclock_enabled)
 {
@@ -93,19 +88,19 @@ static void pc_init1(MemoryRegion *system_memory,
 object_property_add_child(qdev_get_machine(), icc-bridge,
   OBJECT(icc_bridge), NULL);
 
-pc_cpus_init(cpu_model, icc_bridge);
+pc_cpus_init(args, icc_bridge);
 pc_acpi_init(acpi-dsdt.aml);
 
 if (kvmclock_enabled) {
 kvmclock_create();
 }
 
-if (ram_size = 0xe000 ) {
-above_4g_mem_size = ram_size - 0xe000;
+if (args-ram_size = 0xe000 ) {
+above_4g_mem_size = args-ram_size - 0xe000;
 below_4g_mem_size = 0xe000;
 } else {
 above_4g_mem_size = 0;
-below_4g_mem_size = ram_size;
+below_4g_mem_size = args-ram_size;
 }
 
 if (pci_enabled) {
@@ -120,9 +115,9 @@ static void pc_init1(MemoryRegion *system_memory,
 /* allocate ram and load rom/bios */
 if (!xen_enabled()) {
 fw_cfg = pc_memory_init(system_memory,
-   kernel_filename, kernel_cmdline, initrd_filename,
-   below_4g_mem_size, above_4g_mem_size,
-   rom_memory, ram_memory);
+args-kernel_filename, args-kernel_cmdline,
+args-initrd_filename, below_4g_mem_size,
+above_4g_mem_size, rom_memory, ram_memory);
 }
 
 gsi_state = g_malloc0(sizeof(*gsi_state));
@@ -136,7 +131,7 @@ static void pc_init1(MemoryRegion *system_memory,
 
 if (pci_enabled) {
 pci_bus = i440fx_init(i440fx_state, piix3_devfn, isa_bus, gsi,
-  system_memory, system_io, ram_size,
+  system_memory, system_io, args-ram_size,
   below_4g_mem_size,
   0x1ULL - below_4g_mem_size,
   0x1ULL + above_4g_mem_size,
@@ -203,7 +198,7 @@ static void pc_init1(MemoryRegion *system_memory,
 
 audio_init(isa_bus, pci_enabled ? pci_bus : NULL);
 
-pc_cmos_init(below_4g_mem_size, above_4g_mem_size, boot_device,
+pc_cmos_init(below_4g_mem_size, above_4g_mem_size, args-boot_device,
  floppy, idebus[0], idebus[1], rtc_state);
 
 if (pci_enabled  usb_enabled(false)) {
@@ -229,17 +224,7 @@ static void pc_init1(MemoryRegion *system_memory,
 
 static void pc_init_pci(QEMUMachineInitArgs 

[Qemu-devel] [PATCH 3/7] target-i386: Move APIC to ICC bus

2013-04-29 Thread Igor Mammedov
It allows APIC to be hotplugged.

 * map APIC's mmio at board level if it is present
 * do not register mmio region for each APIC, since
   only one is used/mapped

Signed-off-by: Igor Mammedov imamm...@redhat.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
v2:
  - use icc-bridge from args instead of resolving it
---
 hw/cpu/icc_bus.c| 10 ++
 hw/i386/pc.c| 12 ++--
 hw/intc/apic_common.c   | 18 --
 include/hw/cpu/icc_bus.h|  3 +++
 include/hw/i386/apic_internal.h |  6 +++---
 target-i386/cpu.c   | 16 +++-
 6 files changed, 41 insertions(+), 24 deletions(-)

diff --git a/hw/cpu/icc_bus.c b/hw/cpu/icc_bus.c
index 3ac8eeb..73a1dc9 100644
--- a/hw/cpu/icc_bus.c
+++ b/hw/cpu/icc_bus.c
@@ -80,6 +80,7 @@ typedef struct ICCBridgeState {
 /* public */
 
 ICCBus icc_bus;
+MemoryRegion apic_container;
 } ICCBridgeState;
 
 #define ICC_BRIGDE(obj) OBJECT_CHECK(ICCBridgeState, (obj), TYPE_ICC_BRIDGE)
@@ -87,8 +88,17 @@ typedef struct ICCBridgeState {
 static void icc_bridge_init(Object *obj)
 {
 ICCBridgeState *s = ICC_BRIGDE(obj);
+SysBusDevice *sb = SYS_BUS_DEVICE(obj);
 
 qbus_create_inplace(s-icc_bus, TYPE_ICC_BUS, DEVICE(s), icc);
+
+/* Do not change order of registering regions,
+ * APIC must be first registered region, board maps it by 0 index
+ */
+memory_region_init(s-apic_container, icc-apic-container,
+   APIC_SPACE_SIZE);
+sysbus_init_mmio(sb, s-apic_container);
+s-icc_bus.apic_address_space = s-apic_container;
 }
 
 static const TypeInfo icc_bridge_info = {
diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 658ff6c..ce9357e 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -53,6 +53,7 @@
 #include qemu/bitmap.h
 #include qemu/config-file.h
 #include hw/acpi/acpi.h
+#include hw/cpu/icc_bus.h
 
 /* debug PC/ISA interrupts */
 //#define DEBUG_IRQ
@@ -917,6 +918,7 @@ static X86CPU *pc_new_cpu(const char *cpu_model, int64_t 
apic_id,
 void pc_cpus_init(const char *cpu_model, DeviceState *icc_bridge)
 {
 int i;
+X86CPU *cpu = NULL;
 Error *error = NULL;
 
 /* init CPUs */
@@ -929,14 +931,20 @@ void pc_cpus_init(const char *cpu_model, DeviceState 
*icc_bridge)
 }
 
 for (i = 0; i  smp_cpus; i++) {
-pc_new_cpu(cpu_model, x86_cpu_apic_id_from_index(i),
-   icc_bridge, error);
+cpu = pc_new_cpu(cpu_model, x86_cpu_apic_id_from_index(i),
+ icc_bridge, error);
 if (error) {
 fprintf(stderr, %s\n, error_get_pretty(error));
 error_free(error);
 exit(1);
 }
 }
+
+/* map APIC MMIO area if CPU has APIC */
+if (cpu  cpu-env.apic_state) {
+/* XXX: what if the base changes? */
+sysbus_mmio_map_overlap(icc_bridge, 0, APIC_DEFAULT_ADDRESS, 0x1000);
+}
 }
 
 void pc_acpi_init(const char *default_dsdt)
diff --git a/hw/intc/apic_common.c b/hw/intc/apic_common.c
index e0ae07a..b03e904 100644
--- a/hw/intc/apic_common.c
+++ b/hw/intc/apic_common.c
@@ -21,6 +21,8 @@
 #include hw/i386/apic_internal.h
 #include trace.h
 #include sysemu/kvm.h
+#include hw/qdev.h
+#include hw/sysbus.h
 
 static int apic_irq_delivered;
 bool apic_report_tpr_access;
@@ -282,12 +284,13 @@ static int apic_load_old(QEMUFile *f, void *opaque, int 
version_id)
 return 0;
 }
 
-static int apic_init_common(SysBusDevice *dev)
+static int apic_init_common(ICCDevice *dev)
 {
 APICCommonState *s = APIC_COMMON(dev);
 APICCommonClass *info;
 static DeviceState *vapic;
 static int apic_no;
+static bool mmio_registered;
 
 if (apic_no = MAX_APICS) {
 return -1;
@@ -296,8 +299,11 @@ static int apic_init_common(SysBusDevice *dev)
 
 info = APIC_COMMON_GET_CLASS(s);
 info-init(s);
-
-sysbus_init_mmio(dev, s-io_memory);
+if (!mmio_registered) {
+ICCBus *b = ICC_BUS(qdev_get_parent_bus(DEVICE(dev)));
+memory_region_add_subregion(b-apic_address_space, 0, s-io_memory);
+mmio_registered = true;
+}
 
 /* Note: We need at least 1M to map the VAPIC option ROM */
 if (!vapic  s-vapic_control  VAPIC_ENABLE_MASK 
@@ -375,19 +381,19 @@ static Property apic_properties_common[] = {
 
 static void apic_common_class_init(ObjectClass *klass, void *data)
 {
-SysBusDeviceClass *sc = SYS_BUS_DEVICE_CLASS(klass);
+ICCDeviceClass *idc = ICC_DEVICE_CLASS(klass);
 DeviceClass *dc = DEVICE_CLASS(klass);
 
 dc-vmsd = vmstate_apic_common;
 dc-reset = apic_reset_common;
 dc-no_user = 1;
 dc-props = apic_properties_common;
-sc-init = apic_init_common;
+idc-init = apic_init_common;
 }
 
 static const TypeInfo apic_common_type = {
 .name = TYPE_APIC_COMMON,
-.parent = TYPE_SYS_BUS_DEVICE,
+.parent = TYPE_ICC_DEVICE,
 .instance_size = sizeof(APICCommonState),
 .class_size = sizeof(APICCommonClass),
 .class_init = 

[Qemu-devel] [PATCH 7/7] QMP: add cpu-add command

2013-04-29 Thread Igor Mammedov
Adds cpu-add id=xxx QMP command.

cpu-add's id argument is a CPU number in a range [0..max-cpus)

Example QMP command:
 - { execute: cpu-add, arguments: { id: 2 } }
 - { return: {} }

Signed-off-by: Igor Mammedov imamm...@redhat.com
Acked-by: Luiz Capitulino lcapitul...@redhat.com
Reviewed-by: Eric Blake ebl...@redhat.com
---
v7:
  * added Since 1.5 to cpu-add qapi schema definition
v6:
  * added valid values description to qapi schema
  * split out cpu_hot_add hooks introduction into separate patch
  * split out implementation of cpu_hot_add for target-i386
v5:
  * accept id=[0..max_cpus) range in cpu-add command
v4:
  * merge qmp: add cpu-add qmp command  target-i386: implement CPU hot-add 
patches
  * move notifier call to CPUCLass.realize()
  * add hook cpu_hot_add to QEMUMachine
  * make QEMUMachineInitArgs global and keep default cpu_model there

v3:
  * it appears that 'online/offline' in cpu-set are confusing people
with what command actually does and users might have to distinguish
if 'offline' is not implemented by parsing error message. To simplify
things replace cpu-set with cpu-add command to show more clear what
command does and just add cpu-del when CPU remove is implemented.

v2:
  * s/cpu_set/cpu-set/
  * qmp doc style fix
  * use bool type instead of opencodding online/offline string
 suggested-by: Eric Blake ebl...@redhat.com
---
 qapi-schema.json | 13 +
 qmp-commands.hx  | 23 +++
 qmp.c| 10 ++
 3 files changed, 46 insertions(+)

diff --git a/qapi-schema.json b/qapi-schema.json
index 5b0fb3b..6f58b0f 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1387,6 +1387,19 @@
 { 'command': 'cpu', 'data': {'index': 'int'} }
 
 ##
+# @cpu-add
+#
+# Adds CPU with specified ID
+#
+# @id: ID of CPU to be created, valid values [0..max_cpus)
+#
+# Returns: Nothing on success
+#
+# Since 1.5
+##
+{ 'command': 'cpu-add', 'data': {'id': 'int'} }
+
+##
 # @memsave:
 #
 # Save a portion of guest memory to a file.
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 0e89132..ed99eb8 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -385,6 +385,29 @@ Note: CPUs' indexes are obtained with the 'query-cpus' 
command.
 EQMP
 
 {
+.name   = cpu-add,
+.args_type  = id:i,
+.mhandler.cmd_new = qmp_marshal_input_cpu_add,
+},
+
+SQMP
+cpu-add
+---
+
+Adds virtual cpu
+
+Arguments:
+
+- id: cpu id (json-int)
+
+Example:
+
+- { execute: cpu-add, arguments: { id: 2 } }
+- { return: {} }
+
+EQMP
+
+{
 .name   = memsave,
 .args_type  = val:l,size:i,filename:s,cpu:i?,
 .mhandler.cmd_new = qmp_marshal_input_memsave,
diff --git a/qmp.c b/qmp.c
index ed6c7ef..dd34be6 100644
--- a/qmp.c
+++ b/qmp.c
@@ -24,6 +24,7 @@
 #include hw/qdev.h
 #include sysemu/blockdev.h
 #include qom/qom-qobject.h
+#include hw/boards.h
 
 NameInfo *qmp_query_name(Error **errp)
 {
@@ -108,6 +109,15 @@ void qmp_cpu(int64_t index, Error **errp)
 /* Just do nothing */
 }
 
+void qmp_cpu_add(int64_t id, Error **errp)
+{
+if (current_machine-hot_add_cpu) {
+current_machine-hot_add_cpu(id, errp);
+} else {
+error_setg(errp, Not supported);
+}
+}
+
 #ifndef CONFIG_VNC
 /* If VNC support is enabled, the true query-vnc command is
defined in the VNC subsystem */
-- 
1.8.2.1




[Qemu-devel] [PATCH for-1.5 0/2] more tcg-arm cleanups

2013-04-29 Thread Richard Henderson
The first patch really ought to get into 1.5.

The second patch is a re-done version of the 19/19 patch from version 5
of the previous patch series.  We had dropped that due to wanting to
avoid 16MB assumption changes.  The revised patch merely changes how we
handle the constant that needs loading.

Please apply.


r~


Richard Henderson (2):
  tcg-arm: Fix 64-bit tlb load for pre-v6
  tcg-arm: Use movi32 in exit_tb

 tcg/arm/tcg-target.c | 18 --
 1 file changed, 8 insertions(+), 10 deletions(-)

-- 
1.8.1.4




[Qemu-devel] [PATCH for-1.5 1/2] tcg-arm: Fix 64-bit tlb load for pre-v6

2013-04-29 Thread Richard Henderson
Found by inspection, since the effect of the bug was simply to
send all memory ops through the slow path.

Signed-off-by: Richard Henderson r...@twiddle.net
---
 tcg/arm/tcg-target.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tcg/arm/tcg-target.c b/tcg/arm/tcg-target.c
index 7216f7a..12edad4 100644
--- a/tcg/arm/tcg-target.c
+++ b/tcg/arm/tcg-target.c
@@ -1190,7 +1190,7 @@ static void tcg_out_tlb_read(TCGContext *s, TCGReg 
addrlo, TCGReg addrhi,
 tcg_out_memop_12(s, COND_AL, INSN_LDR_IMM, TCG_REG_R0,
  TCG_REG_R2, tlb_offset, 1, 1);
 if (TARGET_LONG_BITS == 64) {
-tcg_out_memop_12(s, COND_AL, INSN_LDR_IMM, TCG_REG_R0,
+tcg_out_memop_12(s, COND_AL, INSN_LDR_IMM, TCG_REG_R1,
  TCG_REG_R2, 4, 1, 0);
 }
 }
-- 
1.8.1.4




[Qemu-devel] [PATCH for-1.5 2/2] tcg-arm: Use movi32 in exit_tb

2013-04-29 Thread Richard Henderson
Avoid the mini constant pool for armv7, and avoid replicating
the test for pre-v7.

Signed-off-by: Richard Henderson r...@twiddle.net
---
 tcg/arm/tcg-target.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/tcg/arm/tcg-target.c b/tcg/arm/tcg-target.c
index 12edad4..3d43412 100644
--- a/tcg/arm/tcg-target.c
+++ b/tcg/arm/tcg-target.c
@@ -1611,17 +1611,15 @@ static inline void tcg_out_op(TCGContext *s, TCGOpcode 
opc,
 
 switch (opc) {
 case INDEX_op_exit_tb:
-{
+if (use_armv7_instructions || check_fit_imm(args[0])) {
+tcg_out_movi32(s, COND_AL, TCG_REG_R0, args[0]);
+tcg_out_goto(s, COND_AL, (tcg_target_ulong) tb_ret_addr);
+} else {
 uint8_t *ld_ptr = s-code_ptr;
-if (args[0]  8)
-tcg_out_ld32_12(s, COND_AL, TCG_REG_R0, TCG_REG_PC, 0);
-else
-tcg_out_dat_imm(s, COND_AL, ARITH_MOV, TCG_REG_R0, 0, args[0]);
+tcg_out_ld32_12(s, COND_AL, TCG_REG_R0, TCG_REG_PC, 0);
 tcg_out_goto(s, COND_AL, (tcg_target_ulong) tb_ret_addr);
-if (args[0]  8) {
-*ld_ptr = (uint8_t) (s-code_ptr - ld_ptr) - 8;
-tcg_out32(s, args[0]);
-}
+*ld_ptr = (uint8_t) (s-code_ptr - ld_ptr) - 8;
+tcg_out32(s, args[0]);
 }
 break;
 case INDEX_op_goto_tb:
-- 
1.8.1.4




[Qemu-devel] [PATCH for-1.5 0/4] virtio: fix bus command line compatibility.

2013-04-29 Thread fred . konrad
From: KONRAD Frederic fred.kon...@greensocs.com

Cc: Libaiqing libaiq...@huawei.com
Cc: Michal Privoznik mpriv...@redhat.com

This series fix the bus name for virtio-serial-device and virtio-scsi-device.

The bus name for virtio-serial-device and virtio-scsi-device is not id.0 as it
was the case before the refactoring.

This trigger the error:

qemu-system-xxx -device virtio-serial-pci,id=virtio-serial0
-device virtserialport,bus=virtio-serial0.0

Bus 'virtio-serial0.0' is full
Bus 'virtio-serial0.0' not found

So this series set the name of those bus before the virtio-device's init.

KONRAD Frederic (4):
  virtio-x-bus: force bus name to virtio-bus.
  virtio-serial: fix command line compatibility.
  scsi: add scsi_named_bus_new().
  virtio-scsi: fix the command line compatibility.

 hw/char/virtio-serial-bus.c   | 16 +++-
 hw/s390x/s390-virtio-bus.c| 22 +-
 hw/s390x/virtio-ccw.c | 22 +-
 hw/scsi/scsi-bus.c| 12 +---
 hw/scsi/virtio-scsi.c | 14 +-
 hw/virtio/virtio-pci.c| 23 ++-
 include/hw/scsi/scsi.h|  2 ++
 include/hw/virtio/virtio-scsi.h   |  7 +++
 include/hw/virtio/virtio-serial.h |  8 
 9 files changed, 118 insertions(+), 8 deletions(-)

-- 
1.8.1.4




[Qemu-devel] [PATCH for-1.5 1/4] virtio-x-bus: force bus name to virtio-bus.

2013-04-29 Thread fred . konrad
From: KONRAD Frederic fred.kon...@greensocs.com

When the proxy id is set, this bus take the name id.0 which is expected
to be the virtio-device's first bus.

So force this name to virtio-bus as it is an internal bus.

Signed-off-by: KONRAD Frederic fred.kon...@greensocs.com
---
 hw/s390x/s390-virtio-bus.c | 5 -
 hw/s390x/virtio-ccw.c  | 4 +++-
 hw/virtio/virtio-pci.c | 5 -
 3 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/hw/s390x/s390-virtio-bus.c b/hw/s390x/s390-virtio-bus.c
index 2cff6b7..d52a547 100644
--- a/hw/s390x/s390-virtio-bus.c
+++ b/hw/s390x/s390-virtio-bus.c
@@ -669,7 +669,10 @@ static void virtio_s390_bus_new(VirtioBusState *bus, 
VirtIOS390Device *dev)
 {
 DeviceState *qdev = DEVICE(dev);
 BusState *qbus;
-qbus_create_inplace((BusState *)bus, TYPE_VIRTIO_S390_BUS, qdev, NULL);
+char virtio_bus_name[] = virtio-bus;
+
+qbus_create_inplace((BusState *)bus, TYPE_VIRTIO_S390_BUS, qdev,
+virtio_bus_name);
 qbus = BUS(bus);
 qbus-allow_hotplug = 1;
 }
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index c0f2646..ef99080 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -1062,8 +1062,10 @@ static void virtio_ccw_bus_new(VirtioBusState *bus, 
VirtioCcwDevice *dev)
 {
 DeviceState *qdev = DEVICE(dev);
 BusState *qbus;
+char virtio_bus_name[] = virtio-bus;
 
-qbus_create_inplace((BusState *)bus, TYPE_VIRTIO_CCW_BUS, qdev, NULL);
+qbus_create_inplace((BusState *)bus, TYPE_VIRTIO_CCW_BUS, qdev,
+virtio_bus_name);
 qbus = BUS(bus);
 qbus-allow_hotplug = 1;
 }
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 41bb41e..070df44 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1474,7 +1474,10 @@ static void virtio_pci_bus_new(VirtioBusState *bus, 
VirtIOPCIProxy *dev)
 {
 DeviceState *qdev = DEVICE(dev);
 BusState *qbus;
-qbus_create_inplace((BusState *)bus, TYPE_VIRTIO_PCI_BUS, qdev, NULL);
+char virtio_bus_name[] = virtio-bus;
+
+qbus_create_inplace((BusState *)bus, TYPE_VIRTIO_PCI_BUS, qdev,
+virtio_bus_name);
 qbus = BUS(bus);
 qbus-allow_hotplug = 1;
 }
-- 
1.8.1.4




[Qemu-devel] [PATCH for-1.5 4/4] virtio-scsi: fix the command line compatibility.

2013-04-29 Thread fred . konrad
From: KONRAD Frederic fred.kon...@greensocs.com

The bus name is wrong since the refactoring.

This keep the behaviour of the command line.

Signed-off-by: KONRAD Frederic fred.kon...@greensocs.com
---
 hw/s390x/s390-virtio-bus.c  |  9 +
 hw/s390x/virtio-ccw.c   |  9 +
 hw/scsi/virtio-scsi.c   | 14 +-
 hw/virtio/virtio-pci.c  |  9 +
 include/hw/virtio/virtio-scsi.h |  7 +++
 5 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/hw/s390x/s390-virtio-bus.c b/hw/s390x/s390-virtio-bus.c
index 6620d29..e1fd937 100644
--- a/hw/s390x/s390-virtio-bus.c
+++ b/hw/s390x/s390-virtio-bus.c
@@ -232,6 +232,15 @@ static int s390_virtio_scsi_init(VirtIOS390Device 
*s390_dev)
 {
 VirtIOSCSIS390 *dev = VIRTIO_SCSI_S390(s390_dev);
 DeviceState *vdev = DEVICE(dev-vdev);
+DeviceState *qdev = DEVICE(s390_dev);
+
+/*
+ * For command line compatibility, this set the virtio-scsi-device bus
+ * name as before.
+ */
+if (qdev-id) {
+set_virtio_scsi_bus_name(vdev, qdev-id);
+}
 
 qdev_set_parent_bus(vdev, BUS(s390_dev-bus));
 if (qdev_init(vdev)  0) {
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index daa94d6..9d69df5 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -677,6 +677,15 @@ static int virtio_ccw_scsi_init(VirtioCcwDevice *ccw_dev)
 {
 VirtIOSCSICcw *dev = VIRTIO_SCSI_CCW(ccw_dev);
 DeviceState *vdev = DEVICE(dev-vdev);
+DeviceState *qdev = DEVICE(ccw_dev);
+
+/*
+ * For command line compatibility, this set the virtio-scsi-device bus
+ * name as before.
+ */
+if (qdev-id) {
+set_virtio_scsi_bus_name(vdev, qdev-id);
+}
 
 qdev_set_parent_bus(vdev, BUS(ccw_dev-bus));
 if (qdev_init(vdev)  0) {
diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
index 84b3ac7..fc27131 100644
--- a/hw/scsi/virtio-scsi.c
+++ b/hw/scsi/virtio-scsi.c
@@ -587,6 +587,15 @@ static struct SCSIBusInfo virtio_scsi_scsi_info = {
 .load_request = virtio_scsi_load_request,
 };
 
+void set_virtio_scsi_bus_name(DeviceState *dev, const char *bus_name)
+{
+VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(dev);
+if (bus_name) {
+vs-bus_name = g_malloc(strlen(bus_name) + 3);
+snprintf(vs-bus_name, strlen(bus_name) + 3, %s.0, bus_name);
+}
+}
+
 int virtio_scsi_common_init(VirtIOSCSICommon *s)
 {
 VirtIODevice *vdev = VIRTIO_DEVICE(s);
@@ -624,7 +633,7 @@ static int virtio_scsi_device_init(VirtIODevice *vdev)
 return ret;
 }
 
-scsi_bus_new(s-bus, qdev, virtio_scsi_scsi_info);
+scsi_named_bus_new(s-bus, qdev, virtio_scsi_scsi_info, vs-bus_name);
 if (!qdev-hotplugged) {
 scsi_bus_legacy_handle_cmdline(s-bus);
 }
@@ -639,6 +648,9 @@ int virtio_scsi_common_exit(VirtIOSCSICommon *vs)
 {
 VirtIODevice *vdev = VIRTIO_DEVICE(vs);
 
+if (vs-bus_name) {
+g_free(vs-bus_name);
+}
 g_free(vs-cmd_vqs);
 virtio_cleanup(vdev);
 return 0;
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 598876f..14fb8dd 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1106,11 +1106,20 @@ static int virtio_scsi_pci_init_pci(VirtIOPCIProxy 
*vpci_dev)
 VirtIOSCSIPCI *dev = VIRTIO_SCSI_PCI(vpci_dev);
 DeviceState *vdev = DEVICE(dev-vdev);
 VirtIOSCSICommon *vs = VIRTIO_SCSI_COMMON(vdev);
+DeviceState *proxy = DEVICE(vpci_dev);
 
 if (vpci_dev-nvectors == DEV_NVECTORS_UNSPECIFIED) {
 vpci_dev-nvectors = vs-conf.num_queues + 3;
 }
 
+/*
+ * For command line compatibility, this set the virtio-scsi-device bus
+ * name as before.
+ */
+if (proxy-id) {
+set_virtio_scsi_bus_name(vdev, proxy-id);
+}
+
 qdev_set_parent_bus(vdev, BUS(vpci_dev-bus));
 if (qdev_init(vdev)  0) {
 return -1;
diff --git a/include/hw/virtio/virtio-scsi.h b/include/hw/virtio/virtio-scsi.h
index 4db346b..c356d54 100644
--- a/include/hw/virtio/virtio-scsi.h
+++ b/include/hw/virtio/virtio-scsi.h
@@ -164,6 +164,9 @@ typedef struct VirtIOSCSICommon {
 VirtQueue *ctrl_vq;
 VirtQueue *event_vq;
 VirtQueue **cmd_vqs;
+
+/* bus_name, for command line compatibility */
+char *bus_name;
 } VirtIOSCSICommon;
 
 typedef struct {
@@ -189,5 +192,9 @@ typedef struct {
 int virtio_scsi_common_init(VirtIOSCSICommon *vs);
 int virtio_scsi_common_exit(VirtIOSCSICommon *vs);
 
+/*
+ * For command line back compatibility, set the bus name before initialisation.
+ */
+void set_virtio_scsi_bus_name(DeviceState *dev, const char *bus_name);
 
 #endif /* _QEMU_VIRTIO_SCSI_H */
-- 
1.8.1.4




[Qemu-devel] [PATCH for-1.5 2/4] virtio-serial: fix command line compatibility.

2013-04-29 Thread fred . konrad
From: KONRAD Frederic fred.kon...@greensocs.com

The bus name is wrong since the refactoring.

This keep the behaviour of the command line.

Signed-off-by: KONRAD Frederic fred.kon...@greensocs.com
---
 hw/char/virtio-serial-bus.c   | 16 +++-
 hw/s390x/s390-virtio-bus.c|  8 
 hw/s390x/virtio-ccw.c |  9 +
 hw/virtio/virtio-pci.c|  9 +
 include/hw/virtio/virtio-serial.h |  8 
 5 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/hw/char/virtio-serial-bus.c b/hw/char/virtio-serial-bus.c
index 3787ad2..0817041 100644
--- a/hw/char/virtio-serial-bus.c
+++ b/hw/char/virtio-serial-bus.c
@@ -889,6 +889,15 @@ static int virtser_port_qdev_exit(DeviceState *qdev)
 return 0;
 }
 
+void set_virtio_serial_bus_name(DeviceState *dev, const char *bus_name)
+{
+VirtIOSerial *vser = VIRTIO_SERIAL(dev);
+if (bus_name) {
+vser-bus_name = g_malloc(strlen(bus_name) + 3);
+snprintf(vser-bus_name, strlen(bus_name) + 3, %s.0, bus_name);
+}
+}
+
 static int virtio_serial_device_init(VirtIODevice *vdev)
 {
 DeviceState *qdev = DEVICE(vdev);
@@ -911,7 +920,8 @@ static int virtio_serial_device_init(VirtIODevice *vdev)
 sizeof(struct virtio_console_config));
 
 /* Spawn a new virtio-serial bus on which the ports will ride as devices */
-qbus_create_inplace(vser-bus.qbus, TYPE_VIRTIO_SERIAL_BUS, qdev, NULL);
+qbus_create_inplace(vser-bus.qbus, TYPE_VIRTIO_SERIAL_BUS, qdev,
+vser-bus_name);
 vser-bus.qbus.allow_hotplug = 1;
 vser-bus.vser = vser;
 QTAILQ_INIT(vser-ports);
@@ -992,6 +1002,10 @@ static int virtio_serial_device_exit(DeviceState *dev)
 
 unregister_savevm(dev, virtio-console, vser);
 
+if (vser-bus_name) {
+g_free(vser-bus_name);
+}
+
 g_free(vser-ivqs);
 g_free(vser-ovqs);
 g_free(vser-ports_map);
diff --git a/hw/s390x/s390-virtio-bus.c b/hw/s390x/s390-virtio-bus.c
index d52a547..6620d29 100644
--- a/hw/s390x/s390-virtio-bus.c
+++ b/hw/s390x/s390-virtio-bus.c
@@ -200,6 +200,14 @@ static int s390_virtio_serial_init(VirtIOS390Device 
*s390_dev)
 
 bus = DO_UPCAST(VirtIOS390Bus, bus, qdev-parent_bus);
 
+/*
+ * For command line compatibility, this set the virtio-serial-device bus
+ * name as before.
+ */
+if (qdev-id) {
+set_virtio_serial_bus_name(vdev, qdev-id);
+}
+
 qdev_set_parent_bus(vdev, BUS(s390_dev-bus));
 if (qdev_init(vdev)  0) {
 return -1;
diff --git a/hw/s390x/virtio-ccw.c b/hw/s390x/virtio-ccw.c
index ef99080..daa94d6 100644
--- a/hw/s390x/virtio-ccw.c
+++ b/hw/s390x/virtio-ccw.c
@@ -593,6 +593,15 @@ static int virtio_ccw_serial_init(VirtioCcwDevice *ccw_dev)
 {
 VirtioSerialCcw *dev = VIRTIO_SERIAL_CCW(ccw_dev);
 DeviceState *vdev = DEVICE(dev-vdev);
+DeviceState *proxy = DEVICE(ccw_dev);
+
+/*
+ * For command line compatibility, this set the virtio-serial-device bus
+ * name as before.
+ */
+if (proxy-id) {
+set_virtio_serial_bus_name(vdev, proxy-id);
+}
 
 qdev_set_parent_bus(vdev, BUS(ccw_dev-bus));
 if (qdev_init(vdev)  0) {
diff --git a/hw/virtio/virtio-pci.c b/hw/virtio/virtio-pci.c
index 070df44..598876f 100644
--- a/hw/virtio/virtio-pci.c
+++ b/hw/virtio/virtio-pci.c
@@ -1297,6 +1297,7 @@ static int virtio_serial_pci_init(VirtIOPCIProxy 
*vpci_dev)
 {
 VirtIOSerialPCI *dev = VIRTIO_SERIAL_PCI(vpci_dev);
 DeviceState *vdev = DEVICE(dev-vdev);
+DeviceState *proxy = DEVICE(vpci_dev);
 
 if (vpci_dev-class_code != PCI_CLASS_COMMUNICATION_OTHER 
 vpci_dev-class_code != PCI_CLASS_DISPLAY_OTHER  /* qemu 0.10 */
@@ -1310,6 +1311,14 @@ static int virtio_serial_pci_init(VirtIOPCIProxy 
*vpci_dev)
 vpci_dev-nvectors = dev-vdev.serial.max_virtserial_ports + 1;
 }
 
+/*
+ * For command line compatibility, this set the virtio-serial-device bus
+ * name as before.
+ */
+if (proxy-id) {
+set_virtio_serial_bus_name(vdev, proxy-id);
+}
+
 qdev_set_parent_bus(vdev, BUS(vpci_dev-bus));
 if (qdev_init(vdev)  0) {
 return -1;
diff --git a/include/hw/virtio/virtio-serial.h 
b/include/hw/virtio/virtio-serial.h
index 1d2040b..786e76b 100644
--- a/include/hw/virtio/virtio-serial.h
+++ b/include/hw/virtio/virtio-serial.h
@@ -194,6 +194,9 @@ typedef struct VirtIOSerialPostLoad {
 struct VirtIOSerial {
 VirtIODevice parent_obj;
 
+/* bus_name, for command line compatibility */
+char *bus_name;
+
 VirtQueue *c_ivq, *c_ovq;
 /* Arrays of ivqs and ovqs: one per port */
 VirtQueue **ivqs, **ovqs;
@@ -244,6 +247,11 @@ size_t virtio_serial_guest_ready(VirtIOSerialPort *port);
  */
 void virtio_serial_throttle_port(VirtIOSerialPort *port, bool throttle);
 
+/*
+ * For command line back compatibility, set the bus name before initialisation.
+ */
+void set_virtio_serial_bus_name(DeviceState *dev, const char 

[Qemu-devel] [PATCH for-1.5 3/4] scsi: add scsi_named_bus_new().

2013-04-29 Thread fred . konrad
From: KONRAD Frederic fred.kon...@greensocs.com

This add the possibility to create a scsi-bus with a specified name.

Signed-off-by: KONRAD Frederic fred.kon...@greensocs.com
---
 hw/scsi/scsi-bus.c | 12 +---
 include/hw/scsi/scsi.h |  2 ++
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/hw/scsi/scsi-bus.c b/hw/scsi/scsi-bus.c
index 6239ee1..0364749 100644
--- a/hw/scsi/scsi-bus.c
+++ b/hw/scsi/scsi-bus.c
@@ -71,15 +71,21 @@ static void scsi_device_unit_attention_reported(SCSIDevice 
*s)
 }
 }
 
-/* Create a scsi bus, and attach devices to it.  */
-void scsi_bus_new(SCSIBus *bus, DeviceState *host, const SCSIBusInfo *info)
+void scsi_named_bus_new(SCSIBus *bus, DeviceState *host,
+const SCSIBusInfo *info, const char *bus_name)
 {
-qbus_create_inplace(bus-qbus, TYPE_SCSI_BUS, host, NULL);
+qbus_create_inplace(bus-qbus, TYPE_SCSI_BUS, host, bus_name);
 bus-busnr = next_scsi_bus++;
 bus-info = info;
 bus-qbus.allow_hotplug = 1;
 }
 
+/* Create a scsi bus, and attach devices to it.  */
+void scsi_bus_new(SCSIBus *bus, DeviceState *host, const SCSIBusInfo *info)
+{
+scsi_named_bus_new(bus, host, info, NULL);
+}
+
 static void scsi_dma_restart_bh(void *opaque)
 {
 SCSIDevice *s = opaque;
diff --git a/include/hw/scsi/scsi.h b/include/hw/scsi/scsi.h
index 3bda1c4..ddcb07c 100644
--- a/include/hw/scsi/scsi.h
+++ b/include/hw/scsi/scsi.h
@@ -153,6 +153,8 @@ struct SCSIBus {
 };
 
 void scsi_bus_new(SCSIBus *bus, DeviceState *host, const SCSIBusInfo *info);
+void scsi_named_bus_new(SCSIBus *bus, DeviceState *host,
+const SCSIBusInfo *info, const char *bus_name);
 
 static inline SCSIBus *scsi_bus_from_device(SCSIDevice *d)
 {
-- 
1.8.1.4




Re: [Qemu-devel] [PATCH] virtio-net: count VIRTIO_NET_F_MAC when calculating config_len

2013-04-29 Thread Jesse Larrew
On 04/29/2013 09:55 AM, KONRAD Frédéric wrote:
 On 29/04/2013 16:42, Jesse Larrew wrote:
 On 04/25/2013 01:59 AM, Michael S. Tsirkin wrote:
 On Thu, Apr 25, 2013 at 02:21:29PM +0800, Jason Wang wrote:
 Commit 14f9b664 (hw/virtio-net.c: set config size using host features) 
 tries to
 calculate config size based on the host features. But it forgets the
 VIRTIO_NET_F_MAC were always set for qemu later. This will lead a zero 
 config
 len for virtio-net device when both VIRTIO_NET_F_STATUS and 
 VIRTIO_NET_F_MQ were
 disabled form command line. Then qemu will crash when user tries to read 
 the
 config of virtio-net.

 Fix this by counting VIRTIO_NET_F_MAC and make sure the config at least 
 contains
 the mac address.

 Cc: Jesse Larrew jlar...@linux.vnet.ibm.com
 Signed-off-by: Jason Wang jasow...@redhat.com
 ---
   hw/net/virtio-net.c |3 ++-
   1 files changed, 2 insertions(+), 1 deletions(-)

 diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
 index 70c8fce..33a70ef 100644
 --- a/hw/net/virtio-net.c
 +++ b/hw/net/virtio-net.c
 @@ -1264,7 +1264,8 @@ static void 
 virtio_net_guest_notifier_mask(VirtIODevice *vdev, int idx,
 void virtio_net_set_config_size(VirtIONet *n, uint32_t host_features)
   {
 -int i, config_size = 0;
 +/* VIRTIO_NET_F_MAC can't be disabled from qemu side */
 +int i, config_size = feature_sizes[0].end;
 This would be cleaner:
 host_features |= (1  VIRTIO_NET_F_MAC);

 no need for a comment then.

 It seems to me that the real problem here is that host_features isn't
 properly populated before virtio_net_set_config_size() is called. Looking
 at virtio_device_init(), we can see why:

 static int virtio_device_init(DeviceState *qdev)
 {
  VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
  VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(qdev);
  assert(k-init != NULL);
  if (k-init(vdev)  0) {
  return -1;
  }
  virtio_bus_plug_device(vdev);
  return 0;
 }

 virtio_net_set_config_size() is currently being called as part of the
 k-init call, but the host_features aren't properly setup until the device
 is plugged into the bus using virtio_bus_plug_device().

 After talking with mdroth, I think the proper way to fix this would be to
 extend VirtioDeviceClass to include a calculate_config_size() method that
 can be called at the appropriate time during device initialization like so:

 static int virtio_device_init(DeviceState *qdev)
 {
  VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
  VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(qdev);
  assert(k-init != NULL);
  if (k-init(vdev)  0) {
  return -1;
  }
  virtio_bus_plug_device(vdev);
 +   if (k-calculate_config_size  k-calculate_config_size(vdev)  0) {
 +   return -1;
 +   }
  return 0;
 }

 This would ensure that host_features contains the proper data before any
 devices try to make use of it to calculate the config size.
 Good point, I didn't saw that.
 
 but this was not the case with commit 14f9b664 no?
 

I suspect this bug was present in 14f9b664 as well. We just hadn't triggered
it yet. I'll confirm this afternoon.


   for (i = 0; feature_sizes[i].flags != 0; i++) {
   if (host_features  feature_sizes[i].flags) {
   config_size = MAX(feature_sizes[i].end, config_size);
 -- 
 1.7.1

Jesse Larrew
Software Engineer, KVM Team
IBM Linux Technology Center
Phone: (512) 973-2052 (T/L: 363-2052)
jlar...@linux.vnet.ibm.com




[Qemu-devel] [PATCH 2/7] target-i386: Attach ICC bus to CPU on its creation

2013-04-29 Thread Igor Mammedov
X86CPU should have parent bus so it could provide bus for child APIC.

Signed-off-by: Igor Mammedov imamm...@redhat.com
Signed-off-by: Andreas Färber afaer...@suse.de
---
TODO: fix unplug of bus-less devices in device-del

v2:
  - pass icc_bridge to cpu_x86_create instead of resolving it each time
---
 hw/i386/pc.c | 10 ++
 hw/i386/pc_piix.c|  2 +-
 hw/i386/pc_q35.c |  2 +-
 include/hw/i386/pc.h |  2 +-
 target-i386/cpu.c| 11 +--
 target-i386/cpu.h|  3 ++-
 6 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 7c7dd86..658ff6c 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -890,12 +890,13 @@ void pc_acpi_smi_interrupt(void *opaque, int irq, int 
level)
 }
 }
 
-static X86CPU *pc_new_cpu(const char *cpu_model, int64_t apic_id, Error **errp)
+static X86CPU *pc_new_cpu(const char *cpu_model, int64_t apic_id,
+  DeviceState *icc_bridge, Error **errp)
 {
 X86CPU *cpu;
 Error *local_err = NULL;
 
-cpu = cpu_x86_create(cpu_model, errp);
+cpu = cpu_x86_create(cpu_model, icc_bridge, errp);
 if (!cpu) {
 return cpu;
 }
@@ -913,7 +914,7 @@ static X86CPU *pc_new_cpu(const char *cpu_model, int64_t 
apic_id, Error **errp)
 return cpu;
 }
 
-void pc_cpus_init(const char *cpu_model)
+void pc_cpus_init(const char *cpu_model, DeviceState *icc_bridge)
 {
 int i;
 Error *error = NULL;
@@ -928,7 +929,8 @@ void pc_cpus_init(const char *cpu_model)
 }
 
 for (i = 0; i  smp_cpus; i++) {
-pc_new_cpu(cpu_model, x86_cpu_apic_id_from_index(i), error);
+pc_new_cpu(cpu_model, x86_cpu_apic_id_from_index(i),
+   icc_bridge, error);
 if (error) {
 fprintf(stderr, %s\n, error_get_pretty(error));
 error_free(error);
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index 51b738a..2190f0a 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -93,7 +93,7 @@ static void pc_init1(MemoryRegion *system_memory,
 object_property_add_child(qdev_get_machine(), icc-bridge,
   OBJECT(icc_bridge), NULL);
 
-pc_cpus_init(cpu_model);
+pc_cpus_init(cpu_model, icc_bridge);
 pc_acpi_init(acpi-dsdt.aml);
 
 if (kvmclock_enabled) {
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index 317dd0c..a926e38 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -80,7 +80,7 @@ static void pc_q35_init(QEMUMachineInitArgs *args)
 object_property_add_child(qdev_get_machine(), icc-bridge,
   OBJECT(icc_bridge), NULL);
 
-pc_cpus_init(cpu_model);
+pc_cpus_init(cpu_model, icc_bridge);
 pc_acpi_init(q35-acpi-dsdt.aml);
 
 kvmclock_create();
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index 14b504c..8a6e76c 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -78,7 +78,7 @@ extern int fd_bootchk;
 void pc_register_ferr_irq(qemu_irq irq);
 void pc_acpi_smi_interrupt(void *opaque, int irq, int level);
 
-void pc_cpus_init(const char *cpu_model);
+void pc_cpus_init(const char *cpu_model, DeviceState *icc_bridge);
 void pc_acpi_init(const char *default_dsdt);
 void *pc_memory_init(MemoryRegion *system_memory,
 const char *kernel_filename,
diff --git a/target-i386/cpu.c b/target-i386/cpu.c
index 0d9493d..94856ec 100644
--- a/target-i386/cpu.c
+++ b/target-i386/cpu.c
@@ -41,6 +41,7 @@
 #endif
 
 #include sysemu/sysemu.h
+#include hw/cpu/icc_bus.h
 #ifndef CONFIG_USER_ONLY
 #include hw/xen/xen.h
 #include hw/sysbus.h
@@ -1618,7 +1619,8 @@ static void cpu_x86_register(X86CPU *cpu, const char 
*name, Error **errp)
 object_property_set_str(OBJECT(cpu), def-model_id, model-id, errp);
 }
 
-X86CPU *cpu_x86_create(const char *cpu_model, Error **errp)
+X86CPU *cpu_x86_create(const char *cpu_model, DeviceState *icc_bridge,
+   Error **errp)
 {
 X86CPU *cpu = NULL;
 CPUX86State *env;
@@ -1635,6 +1637,10 @@ X86CPU *cpu_x86_create(const char *cpu_model, Error 
**errp)
 features = model_pieces[1];
 
 cpu = X86_CPU(object_new(TYPE_X86_CPU));
+#ifndef CONFIG_USER_ONLY
+qdev_set_parent_bus(DEVICE(cpu), qdev_get_child_bus(icc_bridge, icc));
+object_unref(OBJECT(cpu));
+#endif
 env = cpu-env;
 env-cpu_model_str = cpu_model;
 
@@ -1659,7 +1665,7 @@ X86CPU *cpu_x86_init(const char *cpu_model)
 Error *error = NULL;
 X86CPU *cpu;
 
-cpu = cpu_x86_create(cpu_model, error);
+cpu = cpu_x86_create(cpu_model, NULL, error);
 if (error) {
 goto out;
 }
@@ -2346,6 +2352,7 @@ static void x86_cpu_common_class_init(ObjectClass *oc, 
void *data)
 
 xcc-parent_realize = dc-realize;
 dc-realize = x86_cpu_realizefn;
+dc-bus_type = TYPE_ICC_BUS;
 
 xcc-parent_reset = cc-reset;
 cc-reset = x86_cpu_reset;
diff --git a/target-i386/cpu.h b/target-i386/cpu.h
index ab151d5..f193752 100644
--- a/target-i386/cpu.h
+++ b/target-i386/cpu.h
@@ -897,7 

Re: [Qemu-devel] [PATCH] Trivial grammar and spelling fixes

2013-04-29 Thread Richard Henderson

On 2013-04-28 10:49, Stefan Weil wrote:

similiar - similar
recieve - receive
transfered - transferred
preperation - preparation

Most changes are in comments, one modifies a parameter name in a function
prototype.

The spelling fixes were made using codespell.

Signed-off-by: Stefan Weils...@weilnetz.de


Acked-by: Richard Henderson r...@twiddle.net


r~



Re: [Qemu-devel] [PATCH] virtio-net: count VIRTIO_NET_F_MAC when calculating config_len

2013-04-29 Thread KONRAD Frédéric

On 29/04/2013 17:14, Jesse Larrew wrote:

On 04/29/2013 09:55 AM, KONRAD Frédéric wrote:

On 29/04/2013 16:42, Jesse Larrew wrote:

On 04/25/2013 01:59 AM, Michael S. Tsirkin wrote:

On Thu, Apr 25, 2013 at 02:21:29PM +0800, Jason Wang wrote:

Commit 14f9b664 (hw/virtio-net.c: set config size using host features) tries to
calculate config size based on the host features. But it forgets the
VIRTIO_NET_F_MAC were always set for qemu later. This will lead a zero config
len for virtio-net device when both VIRTIO_NET_F_STATUS and VIRTIO_NET_F_MQ were
disabled form command line. Then qemu will crash when user tries to read the
config of virtio-net.

Fix this by counting VIRTIO_NET_F_MAC and make sure the config at least contains
the mac address.

Cc: Jesse Larrew jlar...@linux.vnet.ibm.com
Signed-off-by: Jason Wang jasow...@redhat.com
---
   hw/net/virtio-net.c |3 ++-
   1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 70c8fce..33a70ef 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1264,7 +1264,8 @@ static void virtio_net_guest_notifier_mask(VirtIODevice 
*vdev, int idx,
 void virtio_net_set_config_size(VirtIONet *n, uint32_t host_features)
   {
-int i, config_size = 0;
+/* VIRTIO_NET_F_MAC can't be disabled from qemu side */
+int i, config_size = feature_sizes[0].end;

This would be cleaner:
 host_features |= (1  VIRTIO_NET_F_MAC);

no need for a comment then.


It seems to me that the real problem here is that host_features isn't
properly populated before virtio_net_set_config_size() is called. Looking
at virtio_device_init(), we can see why:

static int virtio_device_init(DeviceState *qdev)
{
  VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
  VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(qdev);
  assert(k-init != NULL);
  if (k-init(vdev)  0) {
  return -1;
  }
  virtio_bus_plug_device(vdev);
  return 0;
}

virtio_net_set_config_size() is currently being called as part of the
k-init call, but the host_features aren't properly setup until the device
is plugged into the bus using virtio_bus_plug_device().

After talking with mdroth, I think the proper way to fix this would be to
extend VirtioDeviceClass to include a calculate_config_size() method that
can be called at the appropriate time during device initialization like so:

static int virtio_device_init(DeviceState *qdev)
{
  VirtIODevice *vdev = VIRTIO_DEVICE(qdev);
  VirtioDeviceClass *k = VIRTIO_DEVICE_GET_CLASS(qdev);
  assert(k-init != NULL);
  if (k-init(vdev)  0) {
  return -1;
  }
  virtio_bus_plug_device(vdev);
+   if (k-calculate_config_size  k-calculate_config_size(vdev)  0) {
+   return -1;
+   }
  return 0;
}

This would ensure that host_features contains the proper data before any
devices try to make use of it to calculate the config size.

Good point, I didn't saw that.

but this was not the case with commit 14f9b664 no?


I suspect this bug was present in 14f9b664 as well. We just hadn't triggered
it yet. I'll confirm this afternoon.


Ok, I think there is a problem with your patch:

virtio_init(VIRTIO_DEVICE(n), virtio-net, VIRTIO_ID_NET,
  n-config_size);

is called in virtio_net_device_init (k-init).

Is there a way to resize the config after that?




   for (i = 0; feature_sizes[i].flags != 0; i++) {
   if (host_features  feature_sizes[i].flags) {
   config_size = MAX(feature_sizes[i].end, config_size);
--
1.7.1

Jesse Larrew
Software Engineer, KVM Team
IBM Linux Technology Center
Phone: (512) 973-2052 (T/L: 363-2052)
jlar...@linux.vnet.ibm.com






[Qemu-devel] [PATCH 6/7] target-i386: implement machine-hot_add_cpu hook

2013-04-29 Thread Igor Mammedov
Signed-off-by: Igor Mammedov imamm...@redhat.com
---
v2:
  * override .hot_add_cpu staticaly starting with 1.5 machine
---
 hw/i386/pc.c | 22 ++
 hw/i386/pc_piix.c|  1 +
 hw/i386/pc_q35.c |  1 +
 include/hw/i386/pc.h |  1 +
 4 files changed, 25 insertions(+)

diff --git a/hw/i386/pc.c b/hw/i386/pc.c
index 26644a1..2bdad17 100644
--- a/hw/i386/pc.c
+++ b/hw/i386/pc.c
@@ -915,6 +915,28 @@ static X86CPU *pc_new_cpu(const char *cpu_model, int64_t 
apic_id,
 return cpu;
 }
 
+void pc_hot_add_cpu(const int64_t id, Error **errp)
+{
+DeviceState *icc_bridge;
+int64_t apic_id = x86_cpu_apic_id_from_index(id);
+
+if (cpu_exists(apic_id)) {
+error_setg(errp, Unable to add CPU: % PRIi64
+   , it already exists, id);
+return;
+}
+
+if (id = max_cpus) {
+error_setg(errp, Unable to add CPU: % PRIi64
+   , max allowed: %d, id, max_cpus - 1);
+return;
+}
+
+icc_bridge = DEVICE(object_resolve_path_type(icc-bridge,
+ TYPE_ICC_BRIDGE, NULL));
+pc_new_cpu(machine_args.cpu_model, apic_id, icc_bridge, errp);
+}
+
 void pc_cpus_init(QEMUMachineInitArgs *args, DeviceState *icc_bridge)
 {
 int i;
diff --git a/hw/i386/pc_piix.c b/hw/i386/pc_piix.c
index bdfac59..ccb230e 100644
--- a/hw/i386/pc_piix.c
+++ b/hw/i386/pc_piix.c
@@ -291,6 +291,7 @@ static QEMUMachine pc_i440fx_machine_v1_5 = {
 .alias = pc,
 .desc = Standard PC (i440FX + PIIX, 1996),
 .init = pc_init_pci,
+.hot_add_cpu = pc_hot_add_cpu,
 .max_cpus = 255,
 .is_default = 1,
 DEFAULT_MACHINE_OPTIONS,
diff --git a/hw/i386/pc_q35.c b/hw/i386/pc_q35.c
index a6f0960..24dc34f 100644
--- a/hw/i386/pc_q35.c
+++ b/hw/i386/pc_q35.c
@@ -209,6 +209,7 @@ static QEMUMachine pc_q35_machine_v1_5 = {
 .alias = q35,
 .desc = Standard PC (Q35 + ICH9, 2009),
 .init = pc_q35_init,
+.hot_add_cpu = pc_hot_add_cpu,
 .max_cpus = 255,
 DEFAULT_MACHINE_OPTIONS,
 };
diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h
index c86059f..89bf4e1 100644
--- a/include/hw/i386/pc.h
+++ b/include/hw/i386/pc.h
@@ -80,6 +80,7 @@ void pc_register_ferr_irq(qemu_irq irq);
 void pc_acpi_smi_interrupt(void *opaque, int irq, int level);
 
 void pc_cpus_init(QEMUMachineInitArgs *args, DeviceState *icc_bridge);
+void pc_hot_add_cpu(const int64_t id, Error **errp);
 void pc_acpi_init(const char *default_dsdt);
 void *pc_memory_init(MemoryRegion *system_memory,
 const char *kernel_filename,
-- 
1.8.2.1




  1   2   3   >