Re: [Qemu-devel] [PATCH v2] utils: Add pow2ceil()

2015-03-13 Thread Markus Armbruster
Richard Henderson  writes:

> On 02/25/2015 02:45 AM, Markus Armbruster wrote:
>> return 0x8000u >> (clz64(value - 1) - 1);
>
> I realize this was weeks ago, but it would certainly be preferable to shift a
> small constant left than a large constant right.
>
> Most RISC machines can't form 0x8000ull without loading 1 and then
> left shifting to start with.  So end the end you're better off with
>
>   return 1ull << (63 - clz64(value));

I intend to respin my own "[PATCH 0/2] Proactive pow2floor() fix, and
dead code removal", and I'll keep your advice in mind for that.



Re: [Qemu-devel] Dummy question for setting up a serial connection between host and guest

2015-03-13 Thread Markus Armbruster
Christopher Covington  writes:

> Hi Alex,
>
> On 03/10/2015 09:12 PM, Alex Sun wrote:
>> I downloaded QEMU 2.2.0, and built a qemu-system-arm from there.
>> I loaded a versatile kernel 2.6.32.5 and my own file system.
>> 
>> #qemu-system-arm -pidfile /tmp/qemu_0_pids/0.pid -M versatilepb -option-rom
>> efi-rtl8139.rom -initrd newinitrd -kernel vmlinuz-2.6.32-5-versatile -append
>> "root=/dev/sda1 console=ttyAMA0" -hda new.qcow2 -drive file=fat:rw:./data
>> -nographic -no-reboot
>> 
>> I see following message while the kernel is booting:
>> 
>> [3.873429] dev:f1: ttyAMA0 at MMIO 0x101f1000 (irq = 12) is a AMBA/PL011
>> [3.884631] console [ttyAMA0] enabled
>> [3.889783] dev:f2: ttyAMA1 at MMIO 0x101f2000 (irq = 13) is a AMBA/PL011
>> [3.890646] dev:f3: ttyAMA2 at MMIO 0x101f3000 (irq = 14) is a AMBA/PL011
>> 
>> I think the serial ports of ttyAMA[0-2] are enabled.
>> Then I try to do serial redirection:
>> 
>> #qemu-system-arm -pidfile /tmp/qemu_0_pids/0.pid -M versatilepb -option-rom
>> efi-rtl8139.rom -initrd newinitrd -kernel vmlinuz-2.6.32-5-versatile -append
>> "root=/dev/sda1 console=ttyAMA0" -hda new.qcow2 -drive file=fat:rw:./data
>> -nographic -no-reboot *-serial stdio -serial pty*
>>
>> However, I get error message:
>> QEMU 2.2.0 monitor - type 'help' for more information
>> *(qemu) qemu-system-arm: -serial stdio: cannot use stdio by multiple 
>> character
>> devices*
>> 
>> It's weired to me. I don't think there is another one other than qemu itself
>> holding the stdio. 

You can connect multiple users to a character device in multiplexing
mode.  Quoting the fine manual:

A character device may be used in multiplexing mode by multiple
front-ends.  The key sequence of @key{Control-a} and @key{c} will
rotate the input focus between attached front-ends. Specify
@option{mux=on} to enable this mode.

> I think the conflict is that when you specify -nographic, the QEMU monitor
> uses stdio. I find it necessary to add "-monitor none" to all of my
> command lines.

I use -nodefault.  One stone, many annoying birds.



[Qemu-devel] [PATCH] virtio-scsi: Fix assert in virtio_scsi_push_event

2015-03-13 Thread Fam Zheng
Hotplugging a scsi-disk may trigger the assertion in qemu_sgl_concat.

qemu-system-x86_64: qemu/hw/scsi/virtio-scsi.c:115: qemu_sgl_concat:
Assertion `skip == 0' failed.

This is introduced by commit 55783a55 (virtio-scsi: work around bug in
old BIOSes) which didn't check out_num when accessing out_sg[0].iov_len
(the same to in sg). For virtio_scsi_push_event, looking into out_sg
doesn't make sense because 0 req_size is intended.

Cc: qemu-sta...@nongnu.org
[Cc'ing qemu-stable because 55783a55 did it too]
Signed-off-by: Fam Zheng 
---
 hw/scsi/virtio-scsi.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
index da0cff8..c9bea06 100644
--- a/hw/scsi/virtio-scsi.c
+++ b/hw/scsi/virtio-scsi.c
@@ -146,8 +146,12 @@ static int virtio_scsi_parse_req(VirtIOSCSIReq *req,
  * TODO: always disable this workaround for virtio 1.0 devices.
  */
 if (!virtio_has_feature(vdev, VIRTIO_F_ANY_LAYOUT)) {
-req_size = req->elem.out_sg[0].iov_len;
-resp_size = req->elem.in_sg[0].iov_len;
+if (req->elem.out_num) {
+req_size = req->elem.out_sg[0].iov_len;
+}
+if (req->elem.in_num) {
+resp_size = req->elem.in_sg[0].iov_len;
+}
 }
 
 out_size = qemu_sgl_concat(req, req->elem.out_sg,
-- 
1.9.3




Re: [Qemu-devel] [PATCH] virtio-pci: fix host notifiers on bi-endian architectures

2015-03-13 Thread Greg Kurz
On Thu, 12 Mar 2015 17:25:15 +0100
Paolo Bonzini  wrote:
> 
> 
> On 12/03/2015 08:08, Michael S. Tsirkin wrote:
> > But common header format is simple, it's always LE.
> > It does not depend on target.
> > To me this looks like a bug in memory_region_add_eventfd,
> > it should do the right thing depending on device
> > endian-ness.
> 
> I agree it seems to be a QEMU bug.
> 
> Paolo
> 

Yes you're right ! QEMU swaps the virtqueue id (adjust_endianness) according
to TARGET_WORDS, like it was coming from the guest but in fact it comes from
the host. The id should be fixed according to HOST_WORDS instead. Of course
this went unnoticed until TARGET_WORDS_BIGENDIAN != HOST_WORDS_BIGENDIAN,
which we have now with ppc64le hosts.

Patches to follow.

Thanks.

--
Greg




Re: [Qemu-devel] [PATCH] block/throttle: Use host clock type

2015-03-13 Thread Paolo Bonzini


On 13/03/2015 07:35, Fam Zheng wrote:
> Throttle timers won't make any progress when VCPU is not running, which
> is prone to stall the request queue in cases like utils, qtest,
> suspending, and live migration, unless carefully handled. What we do now
> is crude. For example in bdrv_drain_all, requests are resumed
> immediately without consulting throttling timer. Unfortunately
> bdrv_drain_all is so widely used that there may be too many holes that
> guest could bypass throttling.
> 
> If we use the host clock, we can just trust the nested poll when waiting
> for requests.
> 
> Signed-off-by: Fam Zheng 
> ---
>  block.c   |  2 +-
>  tests/test-throttle.c | 14 +++---

I think test-throttle.c should use the vm_clock.  At some point it was
managing the clock manually (by overriding cpu_get_clock from
libqemustub.a), and that's only possible with QEMU_CLOCK_VIRTUAL.

As to block.c, I'll leave the review to the block folks.  But I think
QEMU_CLOCK_REALTIME is preferrable.

>  2 files changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/block.c b/block.c
> index 191a847..11f9065 100644
> --- a/block.c
> +++ b/block.c
> @@ -184,7 +184,7 @@ void bdrv_io_limits_enable(BlockDriverState *bs)
>  assert(!bs->io_limits_enabled);
>  throttle_init(&bs->throttle_state,
>bdrv_get_aio_context(bs),
> -  QEMU_CLOCK_VIRTUAL,
> +  QEMU_CLOCK_HOST,
>bdrv_throttle_read_timer_cb,
>bdrv_throttle_write_timer_cb,
>bs);
> diff --git a/tests/test-throttle.c b/tests/test-throttle.c
> index d8ba415..1fb1792 100644
> --- a/tests/test-throttle.c
> +++ b/tests/test-throttle.c
> @@ -107,11 +107,11 @@ static void test_init(void)
>  memset(&ts, 1, sizeof(ts));
>  
>  /* init the structure */
> -throttle_init(&ts, ctx, QEMU_CLOCK_VIRTUAL,
> +throttle_init(&ts, ctx, QEMU_CLOCK_HOST,
>read_timer_cb, write_timer_cb, &ts);
>  
>  /* check initialized fields */
> -g_assert(ts.clock_type == QEMU_CLOCK_VIRTUAL);
> +g_assert(ts.clock_type == QEMU_CLOCK_HOST);
>  g_assert(ts.timers[0]);
>  g_assert(ts.timers[1]);
>  
> @@ -130,7 +130,7 @@ static void test_init(void)
>  static void test_destroy(void)
>  {
>  int i;
> -throttle_init(&ts, ctx, QEMU_CLOCK_VIRTUAL,
> +throttle_init(&ts, ctx, QEMU_CLOCK_HOST,
>read_timer_cb, write_timer_cb, &ts);
>  throttle_destroy(&ts);
>  for (i = 0; i < 2; i++) {
> @@ -170,7 +170,7 @@ static void test_config_functions(void)
>  
>  orig_cfg.op_size = 1;
>  
> -throttle_init(&ts, ctx, QEMU_CLOCK_VIRTUAL,
> +throttle_init(&ts, ctx, QEMU_CLOCK_HOST,
>read_timer_cb, write_timer_cb, &ts);
>  /* structure reset by throttle_init previous_leak should be null */
>  g_assert(!ts.previous_leak);
> @@ -330,7 +330,7 @@ static void test_have_timer(void)
>  g_assert(!throttle_have_timer(&ts));
>  
>  /* init the structure */
> -throttle_init(&ts, ctx, QEMU_CLOCK_VIRTUAL,
> +throttle_init(&ts, ctx, QEMU_CLOCK_HOST,
>read_timer_cb, write_timer_cb, &ts);
>  
>  /* timer set by init should return true */
> @@ -345,7 +345,7 @@ static void test_detach_attach(void)
>  memset(&ts, 0, sizeof(ts));
>  
>  /* init the structure */
> -throttle_init(&ts, ctx, QEMU_CLOCK_VIRTUAL,
> +throttle_init(&ts, ctx, QEMU_CLOCK_HOST,
>read_timer_cb, write_timer_cb, &ts);
>  
>  /* timer set by init should return true */
> @@ -387,7 +387,7 @@ static bool do_test_accounting(bool is_ops, /* are we 
> testing bps or ops */
>  
>  cfg.op_size = op_size;
>  
> -throttle_init(&ts, ctx, QEMU_CLOCK_VIRTUAL,
> +throttle_init(&ts, ctx, QEMU_CLOCK_HOST,
>read_timer_cb, write_timer_cb, &ts);
>  throttle_config(&ts, &cfg);
>  
> 



Re: [Qemu-devel] [PATCH v2 1/4] exec: Atomic access to bounce buffer

2015-03-13 Thread Paolo Bonzini


On 13/03/2015 02:38, Fam Zheng wrote:
> There could be a race condition when two processes call
> address_space_map concurrently and both want to use the bounce buffer.
> 
> Add an in_use flag in BounceBuffer to sync it.
> 
> Signed-off-by: Fam Zheng 
> ---
>  exec.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/exec.c b/exec.c
> index 60b9752..8d4e134 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -2481,6 +2481,7 @@ typedef struct {
>  void *buffer;
>  hwaddr addr;
>  hwaddr len;
> +bool in_use;
>  } BounceBuffer;
>  
>  static BounceBuffer bounce;
> @@ -2569,9 +2570,10 @@ void *address_space_map(AddressSpace *as,
>  l = len;
>  mr = address_space_translate(as, addr, &xlat, &l, is_write);
>  if (!memory_access_is_direct(mr, is_write)) {
> -if (bounce.buffer) {
> +if (atomic_cmpxchg(&bounce.in_use, false, true)) {

atomic_or is enough...

>  return NULL;
>  }
> +smp_mb();

... and it already includes a memory barrier.

Paolo

>  /* Avoid unbounded allocations */
>  l = MIN(l, TARGET_PAGE_SIZE);
>  bounce.buffer = qemu_memalign(TARGET_PAGE_SIZE, l);
> @@ -2639,6 +2641,7 @@ void address_space_unmap(AddressSpace *as, void 
> *buffer, hwaddr len,
>  qemu_vfree(bounce.buffer);
>  bounce.buffer = NULL;
>  memory_region_unref(bounce.mr);
> +atomic_mb_set(&bounce.in_use, false);
>  cpu_notify_map_clients();
>  }
>  
> 



[Qemu-devel] [PATCH v5 for-2.3 2/4] hmp: Rename 'MigrationStatus' to 'HMPMigrationStatus'

2015-03-13 Thread zhanghailiang
We will use the typename 'MigrationStatus' for publicly exported typename,
So here we rename the internal-only 'MigrationStatus' to
'HMPMigrationStatus'.

Signed-off-by: zhanghailiang 
Reviewed-by: Eric Blake 
---
 hmp.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/hmp.c b/hmp.c
index 71c28bc..7300ddc 100644
--- a/hmp.c
+++ b/hmp.c
@@ -1331,16 +1331,16 @@ void hmp_block_job_complete(Monitor *mon, const QDict 
*qdict)
 hmp_handle_error(mon, &error);
 }
 
-typedef struct MigrationStatus
+typedef struct HMPMigrationStatus
 {
 QEMUTimer *timer;
 Monitor *mon;
 bool is_block_migration;
-} MigrationStatus;
+} HMPMigrationStatus;
 
 static void hmp_migrate_status_cb(void *opaque)
 {
-MigrationStatus *status = opaque;
+HMPMigrationStatus *status = opaque;
 MigrationInfo *info;
 
 info = qmp_query_migrate(NULL);
@@ -1388,7 +1388,7 @@ void hmp_migrate(Monitor *mon, const QDict *qdict)
 }
 
 if (!detach) {
-MigrationStatus *status;
+HMPMigrationStatus *status;
 
 if (monitor_suspend(mon) < 0) {
 monitor_printf(mon, "terminal does not allow synchronous "
-- 
1.7.12.4





[Qemu-devel] [PATCH v5 for-2.3 1/4] migration: Rename abbreviated macro MIG_STATE_* to MIGRATION_STATUS_*

2015-03-13 Thread zhanghailiang
Rename all macro MIG_STATE_* to  MIGRATION_STATUS_* except "MIG_STATE_ERROR",
we rename it to "MIGRATION_STATUS_FAILED" which will match the migration status
string 'failed'.

Signed-off-by: zhanghailiang 
Reviewed-by: Eric Blake 
---
 migration/migration.c | 93 +++
 1 file changed, 50 insertions(+), 43 deletions(-)

diff --git a/migration/migration.c b/migration/migration.c
index b3adbc6..f6c998b 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -27,13 +27,13 @@
 #include "trace.h"
 
 enum {
-MIG_STATE_ERROR = -1,
-MIG_STATE_NONE,
-MIG_STATE_SETUP,
-MIG_STATE_CANCELLING,
-MIG_STATE_CANCELLED,
-MIG_STATE_ACTIVE,
-MIG_STATE_COMPLETED,
+MIGRATION_STATUS_FAILED = -1,
+MIGRATION_STATUS_NONE,
+MIGRATION_STATUS_SETUP,
+MIGRATION_STATUS_CANCELLING,
+MIGRATION_STATUS_CANCELLED,
+MIGRATION_STATUS_ACTIVE,
+MIGRATION_STATUS_COMPLETED,
 };
 
 #define MAX_THROTTLE  (32 << 20)  /* Migration speed throttling */
@@ -56,7 +56,7 @@ static NotifierList migration_state_notifiers =
 MigrationState *migrate_get_current(void)
 {
 static MigrationState current_migration = {
-.state = MIG_STATE_NONE,
+.state = MIGRATION_STATUS_NONE,
 .bandwidth_limit = MAX_THROTTLE,
 .xbzrle_cache_size = DEFAULT_MIGRATE_CACHE_SIZE,
 .mbps = -1,
@@ -184,16 +184,16 @@ MigrationInfo *qmp_query_migrate(Error **errp)
 MigrationState *s = migrate_get_current();
 
 switch (s->state) {
-case MIG_STATE_NONE:
+case MIGRATION_STATUS_NONE:
 /* no migration has happened ever */
 break;
-case MIG_STATE_SETUP:
+case MIGRATION_STATUS_SETUP:
 info->has_status = true;
 info->status = g_strdup("setup");
 info->has_total_time = false;
 break;
-case MIG_STATE_ACTIVE:
-case MIG_STATE_CANCELLING:
+case MIGRATION_STATUS_ACTIVE:
+case MIGRATION_STATUS_CANCELLING:
 info->has_status = true;
 info->status = g_strdup("active");
 info->has_total_time = true;
@@ -227,7 +227,7 @@ MigrationInfo *qmp_query_migrate(Error **errp)
 
 get_xbzrle_cache_stats(info);
 break;
-case MIG_STATE_COMPLETED:
+case MIGRATION_STATUS_COMPLETED:
 get_xbzrle_cache_stats(info);
 
 info->has_status = true;
@@ -251,11 +251,11 @@ MigrationInfo *qmp_query_migrate(Error **errp)
 info->ram->mbps = s->mbps;
 info->ram->dirty_sync_count = s->dirty_sync_count;
 break;
-case MIG_STATE_ERROR:
+case MIGRATION_STATUS_FAILED:
 info->has_status = true;
 info->status = g_strdup("failed");
 break;
-case MIG_STATE_CANCELLED:
+case MIGRATION_STATUS_CANCELLED:
 info->has_status = true;
 info->status = g_strdup("cancelled");
 break;
@@ -270,7 +270,8 @@ void 
qmp_migrate_set_capabilities(MigrationCapabilityStatusList *params,
 MigrationState *s = migrate_get_current();
 MigrationCapabilityStatusList *cap;
 
-if (s->state == MIG_STATE_ACTIVE || s->state == MIG_STATE_SETUP) {
+if (s->state == MIGRATION_STATUS_ACTIVE ||
+s->state == MIGRATION_STATUS_SETUP) {
 error_set(errp, QERR_MIGRATION_ACTIVE);
 return;
 }
@@ -306,12 +307,13 @@ static void migrate_fd_cleanup(void *opaque)
 s->file = NULL;
 }
 
-assert(s->state != MIG_STATE_ACTIVE);
+assert(s->state != MIGRATION_STATUS_ACTIVE);
 
-if (s->state != MIG_STATE_COMPLETED) {
+if (s->state != MIGRATION_STATUS_COMPLETED) {
 qemu_savevm_state_cancel();
-if (s->state == MIG_STATE_CANCELLING) {
-migrate_set_state(s, MIG_STATE_CANCELLING, MIG_STATE_CANCELLED);
+if (s->state == MIGRATION_STATUS_CANCELLING) {
+migrate_set_state(s, MIGRATION_STATUS_CANCELLING,
+  MIGRATION_STATUS_CANCELLED);
 }
 }
 
@@ -322,8 +324,8 @@ void migrate_fd_error(MigrationState *s)
 {
 trace_migrate_fd_error();
 assert(s->file == NULL);
-s->state = MIG_STATE_ERROR;
-trace_migrate_set_state(MIG_STATE_ERROR);
+s->state = MIGRATION_STATUS_FAILED;
+trace_migrate_set_state(MIGRATION_STATUS_FAILED);
 notifier_list_notify(&migration_state_notifiers, s);
 }
 
@@ -335,11 +337,12 @@ static void migrate_fd_cancel(MigrationState *s)
 
 do {
 old_state = s->state;
-if (old_state != MIG_STATE_SETUP && old_state != MIG_STATE_ACTIVE) {
+if (old_state != MIGRATION_STATUS_SETUP &&
+old_state != MIGRATION_STATUS_ACTIVE) {
 break;
 }
-migrate_set_state(s, old_state, MIG_STATE_CANCELLING);
-} while (s->state != MIG_STATE_CANCELLING);
+migrate_set_state(s, old_state, MIGRATION_STATUS_CANCELLING);
+} while (s->state != MIGRATION_STATUS_CANCELLING);
 
 /*
  * If we're unlucky the migration code might be stuck somewhere in a
@@ -348,7 +351,7 @@ static void mi

[Qemu-devel] [PATCH v5 for-2.3 0/4] Convert 'status' of MigrationInfo from open-coded 'str' to enum type

2015-03-13 Thread zhanghailiang
Hi Juan & Amit,

This series has been reviewed, and could you help merging them ? 

Thanks,
zhanghailiang

This series converts open-coded 'str' type to enum type for 'status'.

This conversion will be more convenient for future extensibility.
Actually, I will add a MIG_STATE_COLO state for COLO, and i also
saw Dave added MIG_STATE_POSTCOPY_ACTIVE for postcopy.

Patch 1 and 2 are preparation for the conversion, patch 3 completes the 
conversion.
Besides, i add a additional patch (patch 4) to expose 'cancelling' to user,
it will influence libvirt side. And i have CC libvirt development. 

One more thing, i have to replace MIG_STATE_ERROR with MIGRATION_STATUS_FAILED,
and it begin from 0, not its original -1. I think it has no side effect.

Please review.

v5:
- Move 'failed' to the behind of 'completed'
- s/MigState/MigrationStatus/ (Eric) 
- Add Reviewd-by for patch 1 and 3

v4:
- Rename _ERROR to _FAILED in patch 1 instead of patch 4 (Eric)
- Add Reviewd-by for patch 2 and 4
- Fix some grammar in commit message of patch 4 (Eric)

v3:
- Use longer name for Migration status macro. (Eric Blake)
- Rename internal-only typename 'MigrationStatus' (Eric, Dave, Markus)
- Expose 'cancelling' state (Eric Blake)

v2:
- Remove '(since xyz)' strings. (Eric Blake)

Thanks for their comments. ;)

zhanghailiang (4):
  migration: Rename abbreviated macro MIG_STATE_* to 
MIGRATION_STATUS_*
  hmp: Rename 'MigrationStatus' to 'HMPMigrationStatus'
  migration: Convert 'status' of MigrationInfo to use an enum type
  migration: Expose 'cancelling' status to user

 hmp.c | 15 
 migration/migration.c | 95 ---
 qapi-schema.json  | 34 +++---
 3 files changed, 81 insertions(+), 63 deletions(-)

-- 
1.7.12.4





[Qemu-devel] [PATCH v5 for-2.3 4/4] migration: Expose 'cancelling' status to user

2015-03-13 Thread zhanghailiang
'cancelling' status was introduced by commit 51cf4c1a, mainly to avoid a
possible start of a new migration process while the previous one still exists.
But we didn't expose this status to user, instead we returned the 'active' 
state.

Here, we expose it to the user (such as libvirt), 'cancelling' status only
occurs for a short window before the migration aborts, so for users,
if they cancel a migration process, it will observe 'cancelling' status
occasionally.

Testing revealed that with older libvirt (anything 1.2.13 or less) will
print an odd error message if the state is seen, but that the migration
is still properly cancelled. Newer libvirt will be patched to recognize
the new state without the odd error message.

Signed-off-by: zhanghailiang 
Reviewed-by: Eric Blake 
Cc: libvir-l...@redhat.com
---
 migration/migration.c | 6 +-
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/migration/migration.c b/migration/migration.c
index 035e005..a57928d 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -179,13 +179,11 @@ MigrationInfo *qmp_query_migrate(Error **errp)
 break;
 case MIGRATION_STATUS_SETUP:
 info->has_status = true;
-info->status = MIGRATION_STATUS_SETUP;
 info->has_total_time = false;
 break;
 case MIGRATION_STATUS_ACTIVE:
 case MIGRATION_STATUS_CANCELLING:
 info->has_status = true;
-info->status = MIGRATION_STATUS_ACTIVE;
 info->has_total_time = true;
 info->total_time = qemu_clock_get_ms(QEMU_CLOCK_REALTIME)
 - s->total_time;
@@ -221,7 +219,6 @@ MigrationInfo *qmp_query_migrate(Error **errp)
 get_xbzrle_cache_stats(info);
 
 info->has_status = true;
-info->status = MIGRATION_STATUS_COMPLETED;
 info->has_total_time = true;
 info->total_time = s->total_time;
 info->has_downtime = true;
@@ -243,13 +240,12 @@ MigrationInfo *qmp_query_migrate(Error **errp)
 break;
 case MIGRATION_STATUS_FAILED:
 info->has_status = true;
-info->status = MIGRATION_STATUS_FAILED;
 break;
 case MIGRATION_STATUS_CANCELLED:
 info->has_status = true;
-info->status = MIGRATION_STATUS_CANCELLED;
 break;
 }
+info->status = s->state;
 
 return info;
 }
-- 
1.7.12.4





[Qemu-devel] [PATCH 2/2] memory: fix the eventfd data endianness according to the host

2015-03-13 Thread Greg Kurz
The data argument is a host entity. It is not related to the target
endianness. Let's introduce a HOST_WORDS_BIGENDIAN based helper for
that.

This patch fixes ioeventfd and vhost for a ppc64le host running a ppc64le
guest (only virtqueue 0 was handled, all others being byteswapped because
of TARGET_WORDS_BIGENDIAN). It doesn't change functionnality for fixed
endian architectures (i.e. doesn't break x86).

Reported-by: Cédric Le Goater 
Signed-off-by: Greg Kurz 
---
 memory.c |   13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/memory.c b/memory.c
index 6291cc0..1e29d40 100644
--- a/memory.c
+++ b/memory.c
@@ -1549,6 +1549,15 @@ void memory_region_clear_flush_coalesced(MemoryRegion 
*mr)
 }
 }
 
+static bool eventfd_wrong_endianness(MemoryRegion *mr)
+{
+#ifdef HOST_WORDS_BIGENDIAN
+return mr->ops->endianness == DEVICE_LITTLE_ENDIAN;
+#else
+return mr->ops->endianness == DEVICE_BIG_ENDIAN;
+#endif
+}
+
 void memory_region_add_eventfd(MemoryRegion *mr,
hwaddr addr,
unsigned size,
@@ -1565,7 +1574,7 @@ void memory_region_add_eventfd(MemoryRegion *mr,
 };
 unsigned i;
 
-adjust_endianness(&mrfd.data, size, memory_region_wrong_endianness(mr));
+adjust_endianness(&mrfd.data, size, eventfd_wrong_endianness(mr));
 memory_region_transaction_begin();
 for (i = 0; i < mr->ioeventfd_nb; ++i) {
 if (memory_region_ioeventfd_before(mrfd, mr->ioeventfds[i])) {
@@ -1598,7 +1607,7 @@ void memory_region_del_eventfd(MemoryRegion *mr,
 };
 unsigned i;
 
-adjust_endianness(&mrfd.data, size, memory_region_wrong_endianness(mr));
+adjust_endianness(&mrfd.data, size, eventfd_wrong_endianness(mr));
 memory_region_transaction_begin();
 for (i = 0; i < mr->ioeventfd_nb; ++i) {
 if (memory_region_ioeventfd_equal(mrfd, mr->ioeventfds[i])) {




[Qemu-devel] [PATCH 1/2] memory: make adjust_endianness() generic

2015-03-13 Thread Greg Kurz
This patch just moves the decision to swap up to the callers. It changes no
functionnality and will allow a subsequent patch to perform host endianness
based swapping.

Signed-off-by: Greg Kurz 
---
 memory.c |   12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/memory.c b/memory.c
index 20f6d9e..6291cc0 100644
--- a/memory.c
+++ b/memory.c
@@ -347,9 +347,9 @@ static bool memory_region_wrong_endianness(MemoryRegion *mr)
 #endif
 }
 
-static void adjust_endianness(MemoryRegion *mr, uint64_t *data, unsigned size)
+static void adjust_endianness(uint64_t *data, unsigned size, bool need_swap)
 {
-if (memory_region_wrong_endianness(mr)) {
+if (need_swap) {
 switch (size) {
 case 1:
 break;
@@ -1083,7 +1083,7 @@ static bool memory_region_dispatch_read(MemoryRegion *mr,
 }
 
 *pval = memory_region_dispatch_read1(mr, addr, size);
-adjust_endianness(mr, pval, size);
+adjust_endianness(pval, size, memory_region_wrong_endianness(mr));
 return false;
 }
 
@@ -1097,7 +1097,7 @@ static bool memory_region_dispatch_write(MemoryRegion *mr,
 return true;
 }
 
-adjust_endianness(mr, &data, size);
+adjust_endianness(&data, size, memory_region_wrong_endianness(mr));
 
 if (mr->ops->write) {
 access_with_adjusted_size(addr, &data, size,
@@ -1565,7 +1565,7 @@ void memory_region_add_eventfd(MemoryRegion *mr,
 };
 unsigned i;
 
-adjust_endianness(mr, &mrfd.data, size);
+adjust_endianness(&mrfd.data, size, memory_region_wrong_endianness(mr));
 memory_region_transaction_begin();
 for (i = 0; i < mr->ioeventfd_nb; ++i) {
 if (memory_region_ioeventfd_before(mrfd, mr->ioeventfds[i])) {
@@ -1598,7 +1598,7 @@ void memory_region_del_eventfd(MemoryRegion *mr,
 };
 unsigned i;
 
-adjust_endianness(mr, &mrfd.data, size);
+adjust_endianness(&mrfd.data, size, memory_region_wrong_endianness(mr));
 memory_region_transaction_begin();
 for (i = 0; i < mr->ioeventfd_nb; ++i) {
 if (memory_region_ioeventfd_equal(mrfd, mr->ioeventfds[i])) {




Re: [Qemu-devel] [PATCH v2 4/4] dma-helpers: Move reschedule_dma BH to blk's AioContext

2015-03-13 Thread Paolo Bonzini


On 13/03/2015 02:38, Fam Zheng wrote:
> That if the dbs' owner is an iothread, dma should be resumed on the right
> thread. In this case it is the AioContext of the block device.
> 
> Signed-off-by: Fam Zheng 
> ---
>  dma-helpers.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/dma-helpers.c b/dma-helpers.c
> index 6918572..84f61a7 100644
> --- a/dma-helpers.c
> +++ b/dma-helpers.c
> @@ -95,8 +95,10 @@ static void reschedule_dma(void *opaque)
>  static void continue_after_map_failure(void *opaque)
>  {
>  DMAAIOCB *dbs = (DMAAIOCB *)opaque;
> +AioContext *ctx;
>  
> -dbs->bh = qemu_bh_new(reschedule_dma, dbs);
> +ctx = blk_get_aio_context(dbs->blk);
> +dbs->bh = aio_bh_new(ctx, reschedule_dma, dbs);
>  qemu_bh_schedule(dbs->bh);
>  }
>  
> 

This looks good.  However, I wonder if dma_aio_cancel should also call
cpu_unregister_map_client.  In this case, it's much better to just use a
lock for the list (though you can still use atomics for the in-use flag).

Paolo



[Qemu-devel] [PATCH v5 for-2.3 3/4] migration: Convert 'status' of MigrationInfo to use an enum type

2015-03-13 Thread zhanghailiang
The original 'status' is an open-coded 'str' type, convert it to use an
enum type.
This conversion is backwards compatible, better documented and
more convenient for future extensibility.

In addition, Fix a typo for qapi-schema.json (just remove the typo) :
s/'completed'. 'comppleted' (since 1.2)/'completed' (since 1.2)

Signed-off-by: zhanghailiang 
Reviewed-by: Eric Blake 
---
 hmp.c |  7 ---
 migration/migration.c | 20 +---
 qapi-schema.json  | 34 +-
 3 files changed, 38 insertions(+), 23 deletions(-)

diff --git a/hmp.c b/hmp.c
index 7300ddc..cffc94f 100644
--- a/hmp.c
+++ b/hmp.c
@@ -162,7 +162,8 @@ void hmp_info_migrate(Monitor *mon, const QDict *qdict)
 }
 
 if (info->has_status) {
-monitor_printf(mon, "Migration status: %s\n", info->status);
+monitor_printf(mon, "Migration status: %s\n",
+   MigrationStatus_lookup[info->status]);
 monitor_printf(mon, "total time: %" PRIu64 " milliseconds\n",
info->total_time);
 if (info->has_expected_downtime) {
@@ -1344,8 +1345,8 @@ static void hmp_migrate_status_cb(void *opaque)
 MigrationInfo *info;
 
 info = qmp_query_migrate(NULL);
-if (!info->has_status || strcmp(info->status, "active") == 0 ||
-strcmp(info->status, "setup") == 0) {
+if (!info->has_status || info->status == MIGRATION_STATUS_ACTIVE ||
+info->status == MIGRATION_STATUS_SETUP) {
 if (info->has_disk) {
 int progress;
 
diff --git a/migration/migration.c b/migration/migration.c
index f6c998b..035e005 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -26,16 +26,6 @@
 #include "qmp-commands.h"
 #include "trace.h"
 
-enum {
-MIGRATION_STATUS_FAILED = -1,
-MIGRATION_STATUS_NONE,
-MIGRATION_STATUS_SETUP,
-MIGRATION_STATUS_CANCELLING,
-MIGRATION_STATUS_CANCELLED,
-MIGRATION_STATUS_ACTIVE,
-MIGRATION_STATUS_COMPLETED,
-};
-
 #define MAX_THROTTLE  (32 << 20)  /* Migration speed throttling */
 
 /* Amount of time to allocate to each "chunk" of bandwidth-throttled
@@ -189,13 +179,13 @@ MigrationInfo *qmp_query_migrate(Error **errp)
 break;
 case MIGRATION_STATUS_SETUP:
 info->has_status = true;
-info->status = g_strdup("setup");
+info->status = MIGRATION_STATUS_SETUP;
 info->has_total_time = false;
 break;
 case MIGRATION_STATUS_ACTIVE:
 case MIGRATION_STATUS_CANCELLING:
 info->has_status = true;
-info->status = g_strdup("active");
+info->status = MIGRATION_STATUS_ACTIVE;
 info->has_total_time = true;
 info->total_time = qemu_clock_get_ms(QEMU_CLOCK_REALTIME)
 - s->total_time;
@@ -231,7 +221,7 @@ MigrationInfo *qmp_query_migrate(Error **errp)
 get_xbzrle_cache_stats(info);
 
 info->has_status = true;
-info->status = g_strdup("completed");
+info->status = MIGRATION_STATUS_COMPLETED;
 info->has_total_time = true;
 info->total_time = s->total_time;
 info->has_downtime = true;
@@ -253,11 +243,11 @@ MigrationInfo *qmp_query_migrate(Error **errp)
 break;
 case MIGRATION_STATUS_FAILED:
 info->has_status = true;
-info->status = g_strdup("failed");
+info->status = MIGRATION_STATUS_FAILED;
 break;
 case MIGRATION_STATUS_CANCELLED:
 info->has_status = true;
-info->status = g_strdup("cancelled");
+info->status = MIGRATION_STATUS_CANCELLED;
 break;
 }
 
diff --git a/qapi-schema.json b/qapi-schema.json
index 8141f71..5708c99 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -410,19 +410,43 @@
'cache-miss': 'int', 'cache-miss-rate': 'number',
'overflow': 'int' } }
 
+# @MigrationStatus:
+#
+# An enumeration of migration status.
+#
+# @none: no migration has ever happened.
+#
+# @setup: migration process has been initiated.
+#
+# @cancelling: in the process of cancelling migration.
+#
+# @cancelled: cancelling migration is finished.
+#
+# @active: in the process of doing migration.
+#
+# @completed: migration is finished.
+#
+# @failed: some error occurred during migration process.
+#
+# Since: 2.3
+#
+##
+{ 'enum': 'MigrationStatus',
+  'data': [ 'none', 'setup', 'cancelling', 'cancelled',
+'active', 'completed', 'failed' ] }
+
 ##
 # @MigrationInfo
 #
 # Information about current migration process.
 #
-# @status: #optional string describing the current migration status.
-#  As of 0.14.0 this can be 'setup', 'active', 'completed', 'failed' or
-#  'cancelled'. If this field is not returned, no migration process
+# @status: #optional @MigrationStatus describing the current migration status.
+#  If this field is not returned, no migration process
 #  has been initiated
 #
 # @ram: #optional @MigrationStats containing detailed migration
 #   status, 

Re: [Qemu-devel] [PATCH v2 3/4] exec: Notify cpu_register_map_client caller if the bounce buffer is available

2015-03-13 Thread Paolo Bonzini


On 13/03/2015 02:38, Fam Zheng wrote:
> The caller's workflow is like
> 
> if (!address_space_map()) {
> ...
> cpu_register_map_client();
> }
> 
> If bounce buffer became available after address_space_map() but before
> cpu_register_map_client(), the caller could miss it and has to wait for the
> next bounce buffer uesr to release, which may never happen in the worse case.
> 
> Just notify the caller with the passed callback in cpu_register_map_client().
> 
> Signed-off-by: Fam Zheng 
> ---
>  exec.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/exec.c b/exec.c
> index 93ccd5a..82781e4 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -2502,6 +2502,9 @@ void *cpu_register_map_client(void *opaque, void 
> (*callback)(void *opaque))
>  client->opaque = opaque;
>  client->callback = callback;
>  QSLIST_INSERT_HEAD_ATOMIC(&map_client_list, client, link);
> +if (!atomic_read(&bounce.in_use)) {
> +callback(opaque);

This should call cpu_notify_map_clients instead, otherwise you get two
calls.

Paolo

> +}
>  return client;
>  }
>  
> 



Re: [Qemu-devel] [PATCH v2 2/4] exec: Atomic access to map_client_list

2015-03-13 Thread Paolo Bonzini


On 13/03/2015 02:38, Fam Zheng wrote:
> Change map_client_list to QSLIST which supports atomic operations.
> 
> There are two access points to map_client_list. One is
> cpu_register_map_client, the other is cpu_notify_map_clients called
> after releasing the global bounce buffer in address_space_unmap. Each
> is now converted to a single atomic operation.
> 
> Signed-off-by: Fam Zheng 
> ---
>  exec.c | 27 ---
>  1 file changed, 12 insertions(+), 15 deletions(-)
> 
> diff --git a/exec.c b/exec.c
> index 8d4e134..93ccd5a 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -2489,11 +2489,11 @@ static BounceBuffer bounce;
>  typedef struct MapClient {
>  void *opaque;
>  void (*callback)(void *opaque);
> -QLIST_ENTRY(MapClient) link;
> +QSLIST_ENTRY(MapClient) link;
>  } MapClient;
>  
> -static QLIST_HEAD(map_client_list, MapClient) map_client_list
> -= QLIST_HEAD_INITIALIZER(map_client_list);
> +static QSLIST_HEAD(map_client_list, MapClient) map_client_list
> += QSLIST_HEAD_INITIALIZER(map_client_list);
>  
>  void *cpu_register_map_client(void *opaque, void (*callback)(void *opaque))
>  {
> @@ -2501,26 +2501,23 @@ void *cpu_register_map_client(void *opaque, void 
> (*callback)(void *opaque))
>  
>  client->opaque = opaque;
>  client->callback = callback;
> -QLIST_INSERT_HEAD(&map_client_list, client, link);
> +QSLIST_INSERT_HEAD_ATOMIC(&map_client_list, client, link);
>  return client;
>  }
>  
> -static void cpu_unregister_map_client(void *_client)
> -{
> -MapClient *client = (MapClient *)_client;
> -
> -QLIST_REMOVE(client, link);
> -g_free(client);
> -}
> -
>  static void cpu_notify_map_clients(void)
>  {
>  MapClient *client;
> +QSLIST_HEAD(, MapClient) mclist;
>  
> -while (!QLIST_EMPTY(&map_client_list)) {
> -client = QLIST_FIRST(&map_client_list);
> +/* Only the bounce buffer owner thread could possibly call this, but we
> + * should also coordinate with cpu_register_map_client. */
> +QSLIST_MOVE_ATOMIC(&mclist, &map_client_list);
> +while (!QSLIST_EMPTY(&mclist)) {
> +client = QSLIST_FIRST(&mclist);
>  client->callback(client->opaque);
> -cpu_unregister_map_client(client);
> +QSLIST_REMOVE_HEAD(&mclist, link);
> +g_free(client);
>  }
>  }
>  
> 

Looks good.

Paolo



Re: [Qemu-devel] [PATCH v2 1/4] exec: Atomic access to bounce buffer

2015-03-13 Thread Fam Zheng
On Fri, 03/13 09:09, Paolo Bonzini wrote:
> 
> 
> On 13/03/2015 02:38, Fam Zheng wrote:
> > There could be a race condition when two processes call
> > address_space_map concurrently and both want to use the bounce buffer.
> > 
> > Add an in_use flag in BounceBuffer to sync it.
> > 
> > Signed-off-by: Fam Zheng 
> > ---
> >  exec.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/exec.c b/exec.c
> > index 60b9752..8d4e134 100644
> > --- a/exec.c
> > +++ b/exec.c
> > @@ -2481,6 +2481,7 @@ typedef struct {
> >  void *buffer;
> >  hwaddr addr;
> >  hwaddr len;
> > +bool in_use;
> >  } BounceBuffer;
> >  
> >  static BounceBuffer bounce;
> > @@ -2569,9 +2570,10 @@ void *address_space_map(AddressSpace *as,
> >  l = len;
> >  mr = address_space_translate(as, addr, &xlat, &l, is_write);
> >  if (!memory_access_is_direct(mr, is_write)) {
> > -if (bounce.buffer) {
> > +if (atomic_cmpxchg(&bounce.in_use, false, true)) {
> 
> atomic_or is enough...

atomic_cmpxchg is here to take the ownership of bounce iff it is not in use, so
I think it is necessary.

Fam

> 
> >  return NULL;
> >  }
> > +smp_mb();
> 
> ... and it already includes a memory barrier.
> 
> Paolo
> 
> >  /* Avoid unbounded allocations */
> >  l = MIN(l, TARGET_PAGE_SIZE);
> >  bounce.buffer = qemu_memalign(TARGET_PAGE_SIZE, l);
> > @@ -2639,6 +2641,7 @@ void address_space_unmap(AddressSpace *as, void 
> > *buffer, hwaddr len,
> >  qemu_vfree(bounce.buffer);
> >  bounce.buffer = NULL;
> >  memory_region_unref(bounce.mr);
> > +atomic_mb_set(&bounce.in_use, false);
> >  cpu_notify_map_clients();
> >  }
> >  
> > 



Re: [Qemu-devel] [PATCH v4 14/17] ahci: Migrate IDEStatus

2015-03-13 Thread Kevin Wolf
Am 13.03.2015 um 07:01 hat Amit Shah geschrieben:
> On (Mon) 23 Feb 2015 [11:18:03], John Snow wrote:
> > Amazingly, we weren't doing this before.
> > 
> > Make sure we migrate the IDEState structure that belongs to
> > the AHCIDevice.IDEBus structure during migrations.
> > 
> > No version numbering changes because AHCI is not officially
> > migratable (and we can all see with good reason why) so we
> > do not impact any official builds by altering the stream and
> > leaving it at version 1.
> > 
> > This fixes the rerror=stop/werror=stop test case where we wish
> > to migrate a halted job. Previously, the error code would not
> > migrate, so even if the job completed successfully, AHCI would
> > report an error because it would still have the placeholder
> > error code from initialization time.
> > 
> > Reviewed-by: Paolo Bonzini 
> > Signed-off-by: John Snow 
> > ---
> >  hw/ide/ahci.c | 1 +
> >  hw/ide/internal.h | 3 +++
> >  2 files changed, 4 insertions(+)
> > 
> > diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
> > index bc6d5ce..3f4fc77 100644
> > --- a/hw/ide/ahci.c
> > +++ b/hw/ide/ahci.c
> > @@ -1321,6 +1321,7 @@ static const VMStateDescription vmstate_ahci_device = 
> > {
> >  .version_id = 1,
> >  .fields = (VMStateField[]) {
> >  VMSTATE_IDE_BUS(port, AHCIDevice),
> > +VMSTATE_IDE_DRIVE(port.ifs[0], AHCIDevice),
> 
> This adds a new field to the struct without bumping up the version
> number.
> 
> Flagged by the static checker.

AHCI is still marked unmigratable, so it doesn't matter (and actually,
I just see that the commit message above explicitly states this).

Kevin



Re: [Qemu-devel] [PATCH RFC 0/2] Limit support for encrypted images to qemu-img

2015-03-13 Thread Kevin Wolf
Am 12.03.2015 um 17:58 hat Paolo Bonzini geschrieben:
> > For cold plug, have a command line arg '--add-keys prompt' to
> > indicate the user should be prompted on TTY to enter keys,
> 
> This can even be the default if you have a human monitor open.
> (Downside: the default human monitor, accessible with Ctrl-Alt-2, is not
> easily discovered; same for Ctrl-A c for -nographic).

In some ancient version this actually worked as expected: When you
started a VM with an encrypted image, the HMP monitor was active, and
after providing the password, it switched to the graphical output.

> > For managed usage we could allow
> > '--add-keys fd=FDNUM' and just read keys from the file descriptor.
> 
> For managed usage, options can also be passed via -readconfig like
> 
>[object "mykey1"]
>type=secret
>secret=SECRETDATA

Hopefully not using a real file, but /dev/fdset/something.

Kevin



Re: [Qemu-devel] [PATCH] block/throttle: Use host clock type

2015-03-13 Thread Fam Zheng
On Fri, 03/13 09:08, Paolo Bonzini wrote:
> 
> 
> On 13/03/2015 07:35, Fam Zheng wrote:
> > Throttle timers won't make any progress when VCPU is not running, which
> > is prone to stall the request queue in cases like utils, qtest,
> > suspending, and live migration, unless carefully handled. What we do now
> > is crude. For example in bdrv_drain_all, requests are resumed
> > immediately without consulting throttling timer. Unfortunately
> > bdrv_drain_all is so widely used that there may be too many holes that
> > guest could bypass throttling.
> > 
> > If we use the host clock, we can just trust the nested poll when waiting
> > for requests.
> > 
> > Signed-off-by: Fam Zheng 
> > ---
> >  block.c   |  2 +-
> >  tests/test-throttle.c | 14 +++---
> 
> I think test-throttle.c should use the vm_clock.  At some point it was
> managing the clock manually (by overriding cpu_get_clock from
> libqemustub.a), and that's only possible with QEMU_CLOCK_VIRTUAL.

Ah! That is in iotests 093 (hint: authord by Fam Zheng :-/), which WILL be
complicated if block.c switches away from QEMU_CLOCK_VIRTUAL. But I'll do the
work if we decide to make this change.

As to tests/test-throttle.c, I don't see its dependency on clock type, so
either way should work and I don't mind keeping it as-is at all.

> 
> As to block.c, I'll leave the review to the block folks.  But I think
> QEMU_CLOCK_REALTIME is preferrable.

Real time clock should be fine, but we should review that the code handles
clock reversing.

Fam

> 
> >  2 files changed, 8 insertions(+), 8 deletions(-)
> > 
> > diff --git a/block.c b/block.c
> > index 191a847..11f9065 100644
> > --- a/block.c
> > +++ b/block.c
> > @@ -184,7 +184,7 @@ void bdrv_io_limits_enable(BlockDriverState *bs)
> >  assert(!bs->io_limits_enabled);
> >  throttle_init(&bs->throttle_state,
> >bdrv_get_aio_context(bs),
> > -  QEMU_CLOCK_VIRTUAL,
> > +  QEMU_CLOCK_HOST,
> >bdrv_throttle_read_timer_cb,
> >bdrv_throttle_write_timer_cb,
> >bs);
> > diff --git a/tests/test-throttle.c b/tests/test-throttle.c
> > index d8ba415..1fb1792 100644
> > --- a/tests/test-throttle.c
> > +++ b/tests/test-throttle.c
> > @@ -107,11 +107,11 @@ static void test_init(void)
> >  memset(&ts, 1, sizeof(ts));
> >  
> >  /* init the structure */
> > -throttle_init(&ts, ctx, QEMU_CLOCK_VIRTUAL,
> > +throttle_init(&ts, ctx, QEMU_CLOCK_HOST,
> >read_timer_cb, write_timer_cb, &ts);
> >  
> >  /* check initialized fields */
> > -g_assert(ts.clock_type == QEMU_CLOCK_VIRTUAL);
> > +g_assert(ts.clock_type == QEMU_CLOCK_HOST);
> >  g_assert(ts.timers[0]);
> >  g_assert(ts.timers[1]);
> >  
> > @@ -130,7 +130,7 @@ static void test_init(void)
> >  static void test_destroy(void)
> >  {
> >  int i;
> > -throttle_init(&ts, ctx, QEMU_CLOCK_VIRTUAL,
> > +throttle_init(&ts, ctx, QEMU_CLOCK_HOST,
> >read_timer_cb, write_timer_cb, &ts);
> >  throttle_destroy(&ts);
> >  for (i = 0; i < 2; i++) {
> > @@ -170,7 +170,7 @@ static void test_config_functions(void)
> >  
> >  orig_cfg.op_size = 1;
> >  
> > -throttle_init(&ts, ctx, QEMU_CLOCK_VIRTUAL,
> > +throttle_init(&ts, ctx, QEMU_CLOCK_HOST,
> >read_timer_cb, write_timer_cb, &ts);
> >  /* structure reset by throttle_init previous_leak should be null */
> >  g_assert(!ts.previous_leak);
> > @@ -330,7 +330,7 @@ static void test_have_timer(void)
> >  g_assert(!throttle_have_timer(&ts));
> >  
> >  /* init the structure */
> > -throttle_init(&ts, ctx, QEMU_CLOCK_VIRTUAL,
> > +throttle_init(&ts, ctx, QEMU_CLOCK_HOST,
> >read_timer_cb, write_timer_cb, &ts);
> >  
> >  /* timer set by init should return true */
> > @@ -345,7 +345,7 @@ static void test_detach_attach(void)
> >  memset(&ts, 0, sizeof(ts));
> >  
> >  /* init the structure */
> > -throttle_init(&ts, ctx, QEMU_CLOCK_VIRTUAL,
> > +throttle_init(&ts, ctx, QEMU_CLOCK_HOST,
> >read_timer_cb, write_timer_cb, &ts);
> >  
> >  /* timer set by init should return true */
> > @@ -387,7 +387,7 @@ static bool do_test_accounting(bool is_ops, /* are we 
> > testing bps or ops */
> >  
> >  cfg.op_size = op_size;
> >  
> > -throttle_init(&ts, ctx, QEMU_CLOCK_VIRTUAL,
> > +throttle_init(&ts, ctx, QEMU_CLOCK_HOST,
> >read_timer_cb, write_timer_cb, &ts);
> >  throttle_config(&ts, &cfg);
> >  
> > 



Re: [Qemu-devel] [PATCH v2 1/4] exec: Atomic access to bounce buffer

2015-03-13 Thread Paolo Bonzini


On 13/03/2015 09:16, Fam Zheng wrote:
>>> > > +if (atomic_cmpxchg(&bounce.in_use, false, true)) {
>> > 
>> > atomic_or is enough...
> atomic_cmpxchg is here to take the ownership of bounce iff it is not in use, 
> so
> I think it is necessary.

It's changing false to true and true to true, so you can do

if (atomic_or(&bounce.in_use, 1)) {
// was true already
}

Paolo



Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-posix-acl: Fix out-of-bounds access

2015-03-13 Thread Aneesh Kumar K.V
Shannon Zhao  writes:

> It's detected by coverity. Fix out-of-bounds access of the function 
> mp_dacl_listxattr.
>
> Signed-off-by: Shannon Zhao 
> Signed-off-by: Shannon Zhao 
> ---
>  hw/9pfs/virtio-9p-posix-acl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/9pfs/virtio-9p-posix-acl.c b/hw/9pfs/virtio-9p-posix-acl.c
> index 803d9d9..09dad07 100644
> --- a/hw/9pfs/virtio-9p-posix-acl.c
> +++ b/hw/9pfs/virtio-9p-posix-acl.c
> @@ -114,7 +114,7 @@ static ssize_t mp_dacl_listxattr(FsContext *ctx, const 
> char *path,
>  }
>
>  /* len includes the trailing NUL */
> -memcpy(value, ACL_ACCESS, len);
> +memcpy(value, ACL_DEFAULT, len);
>  return 0;
>  }

Applied.

Thanks
-aneesh




Re: [Qemu-devel] [PATCH v2 1/4] exec: Atomic access to bounce buffer

2015-03-13 Thread Fam Zheng
On Fri, 03/13 09:32, Paolo Bonzini wrote:
> 
> 
> On 13/03/2015 09:16, Fam Zheng wrote:
> >>> > > +if (atomic_cmpxchg(&bounce.in_use, false, true)) {
> >> > 
> >> > atomic_or is enough...
> > atomic_cmpxchg is here to take the ownership of bounce iff it is not in 
> > use, so
> > I think it is necessary.
> 
> It's changing false to true and true to true, so you can do
> 
> if (atomic_or(&bounce.in_use, 1)) {
> // was true already
> }

I see, we have the old value! Thanks!

Fam



Re: [Qemu-devel] [PATCH v2 1/4] exec: Atomic access to bounce buffer

2015-03-13 Thread Paolo Bonzini


On 13/03/2015 09:32, Paolo Bonzini wrote:
> 
> 
> On 13/03/2015 09:16, Fam Zheng wrote:
>> +if (atomic_cmpxchg(&bounce.in_use, false, true)) {

 atomic_or is enough...
>> atomic_cmpxchg is here to take the ownership of bounce iff it is not in use, 
>> so
>> I think it is necessary.
> 
> It's changing false to true and true to true, so you can do
> 
> if (atomic_or(&bounce.in_use, 1)) {
> // was true already
> }

... and actually, atomic_xchg is even better (on x86, atomic_or is
compiled into a cmpxchg loop, but atomic_xchg is a single instruction).

Paolo



Re: [Qemu-devel] [PATCH v4 14/17] ahci: Migrate IDEStatus

2015-03-13 Thread Amit Shah
On (Fri) 13 Mar 2015 [09:21:19], Kevin Wolf wrote:
> Am 13.03.2015 um 07:01 hat Amit Shah geschrieben:
> > On (Mon) 23 Feb 2015 [11:18:03], John Snow wrote:
> > > Amazingly, we weren't doing this before.
> > > 
> > > Make sure we migrate the IDEState structure that belongs to
> > > the AHCIDevice.IDEBus structure during migrations.
> > > 
> > > No version numbering changes because AHCI is not officially
> > > migratable (and we can all see with good reason why) so we
> > > do not impact any official builds by altering the stream and
> > > leaving it at version 1.
> > > 
> > > This fixes the rerror=stop/werror=stop test case where we wish
> > > to migrate a halted job. Previously, the error code would not
> > > migrate, so even if the job completed successfully, AHCI would
> > > report an error because it would still have the placeholder
> > > error code from initialization time.
> > > 
> > > Reviewed-by: Paolo Bonzini 
> > > Signed-off-by: John Snow 
> > > ---
> > >  hw/ide/ahci.c | 1 +
> > >  hw/ide/internal.h | 3 +++
> > >  2 files changed, 4 insertions(+)
> > > 
> > > diff --git a/hw/ide/ahci.c b/hw/ide/ahci.c
> > > index bc6d5ce..3f4fc77 100644
> > > --- a/hw/ide/ahci.c
> > > +++ b/hw/ide/ahci.c
> > > @@ -1321,6 +1321,7 @@ static const VMStateDescription vmstate_ahci_device 
> > > = {
> > >  .version_id = 1,
> > >  .fields = (VMStateField[]) {
> > >  VMSTATE_IDE_BUS(port, AHCIDevice),
> > > +VMSTATE_IDE_DRIVE(port.ifs[0], AHCIDevice),
> > 
> > This adds a new field to the struct without bumping up the version
> > number.
> > 
> > Flagged by the static checker.
> 
> AHCI is still marked unmigratable, so it doesn't matter (and actually,
> I just see that the commit message above explicitly states this).

I missed that.  Thanks.


Amit



Re: [Qemu-devel] [RFC PATCH 01/14] docs: block replication's description

2015-03-13 Thread Wen Congyang
On 03/11/2015 02:49 PM, Fam Zheng wrote:
> On Wed, 03/11 14:44, Wen Congyang wrote:
>> On 03/03/2015 03:59 PM, Fam Zheng wrote:
>>> On Tue, 03/03 15:53, Wen Congyang wrote:
 I test qcow2_make_empty()'s performance. The result shows that it may
 take about 100ms(normal sata disk). It is not acceptable for COLO. So
 I think disk buff is necessary(just use it to replace qcow2).
>>>
>>> Why not tmpfs or ramdisk?
>>
>> Another problem:
>> After failover, secondary write request will be written in (active disk)?
>> It is better to write request to (nbd target). Is there any feature can
>> be reused to implement it?
> 
> You can use block commit or stream to move the data.

Can the job stream move the data? I don't find the write ops in block/stream.c.

Thanks
Wen Congyang

> 
> Fam
> 
> .
> 




[Qemu-devel] [PATCH v4] hmp: add info iothreads command

2015-03-13 Thread Ting Wang
Make "info iothreads" available on the HMP monitor.

The results are as follows:
id1: thread_id=thread_id1
id2: thread_id=thread_id2

Signed-off-by: Ting Wang 
---
v4: use the PRId64 format specifier macro for the int64_t thread_id
v3: fix comment and the trailing whitespace
v2: add braces for if
---
 hmp-commands.hx |  2 ++
 hmp.c   | 22 ++
 hmp.h   |  1 +
 monitor.c   |  7 +++
 4 files changed, 32 insertions(+)

diff --git a/hmp-commands.hx b/hmp-commands.hx
index d5022d8..67d76ed 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1746,6 +1746,8 @@ show roms
 show the TPM device
 @item info memory-devices
 show the memory devices
+@item info iothreads
+show iothreads
 @end table
 ETEXI
 
diff --git a/hmp.c b/hmp.c
index 71c28bc..445a8ad 100644
--- a/hmp.c
+++ b/hmp.c
@@ -821,6 +821,28 @@ void hmp_info_tpm(Monitor *mon, const QDict *qdict)
 qapi_free_TPMInfoList(info_list);
 }
 
+void hmp_info_iothreads(Monitor *mon, const QDict *qdict)
+{
+IOThreadInfoList *head = NULL, *elem = NULL;
+
+head = qmp_query_iothreads(NULL);
+if (!head) {
+monitor_printf(mon, "No iothread has been added\n");
+return;
+}
+
+elem = head;
+while (elem) {
+if (elem->value) {
+monitor_printf(mon, "%s: thread_id=%" PRId64 "\n", elem->value->id,
+elem->value->thread_id);
+}
+elem = elem->next;
+}
+
+qapi_free_IOThreadInfoList(head);
+}
+
 void hmp_quit(Monitor *mon, const QDict *qdict)
 {
 monitor_suspend(mon);
diff --git a/hmp.h b/hmp.h
index 81177b2..d99090e 100644
--- a/hmp.h
+++ b/hmp.h
@@ -38,6 +38,7 @@ void hmp_info_balloon(Monitor *mon, const QDict *qdict);
 void hmp_info_pci(Monitor *mon, const QDict *qdict);
 void hmp_info_block_jobs(Monitor *mon, const QDict *qdict);
 void hmp_info_tpm(Monitor *mon, const QDict *qdict);
+void hmp_info_iothreads(Monitor *mon, const QDict *qdict);
 void hmp_quit(Monitor *mon, const QDict *qdict);
 void hmp_stop(Monitor *mon, const QDict *qdict);
 void hmp_system_reset(Monitor *mon, const QDict *qdict);
diff --git a/monitor.c b/monitor.c
index c86a89e..076a306 100644
--- a/monitor.c
+++ b/monitor.c
@@ -2924,6 +2924,13 @@ static mon_cmd_t info_cmds[] = {
 .mhandler.cmd = hmp_info_memory_devices,
 },
 {
+.name   = "iothreads",
+.args_type  = "",
+.params = "",
+.help   = "show iothreads",
+.mhandler.cmd = hmp_info_iothreads,
+},
+{
 .name   = NULL,
 },
 };
-- 
1.8.5





Re: [Qemu-devel] [PATCH v2 4/4] dma-helpers: Move reschedule_dma BH to blk's AioContext

2015-03-13 Thread Fam Zheng
On Fri, 03/13 09:13, Paolo Bonzini wrote:
> 
> 
> On 13/03/2015 02:38, Fam Zheng wrote:
> > That if the dbs' owner is an iothread, dma should be resumed on the right
> > thread. In this case it is the AioContext of the block device.
> > 
> > Signed-off-by: Fam Zheng 
> > ---
> >  dma-helpers.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/dma-helpers.c b/dma-helpers.c
> > index 6918572..84f61a7 100644
> > --- a/dma-helpers.c
> > +++ b/dma-helpers.c
> > @@ -95,8 +95,10 @@ static void reschedule_dma(void *opaque)
> >  static void continue_after_map_failure(void *opaque)
> >  {
> >  DMAAIOCB *dbs = (DMAAIOCB *)opaque;
> > +AioContext *ctx;
> >  
> > -dbs->bh = qemu_bh_new(reschedule_dma, dbs);
> > +ctx = blk_get_aio_context(dbs->blk);
> > +dbs->bh = aio_bh_new(ctx, reschedule_dma, dbs);
> >  qemu_bh_schedule(dbs->bh);
> >  }
> >  
> > 
> 
> This looks good.  However, I wonder if dma_aio_cancel should also call
> cpu_unregister_map_client.  In this case, it's much better to just use a
> lock for the list (though you can still use atomics for the in-use flag).

The other possibility is grab a reference for the cpu_register_map_client call,
and release it in reschedule_dma. This way the atomics can keep, but we'll need
a "finished" flag in DMAAIOCB to avoid double completion.

Fam



Re: [Qemu-devel] [RFC PATCH 01/14] docs: block replication's description

2015-03-13 Thread Fam Zheng
On Fri, 03/13 17:01, Wen Congyang wrote:
> On 03/11/2015 02:49 PM, Fam Zheng wrote:
> > On Wed, 03/11 14:44, Wen Congyang wrote:
> >> On 03/03/2015 03:59 PM, Fam Zheng wrote:
> >>> On Tue, 03/03 15:53, Wen Congyang wrote:
>  I test qcow2_make_empty()'s performance. The result shows that it may
>  take about 100ms(normal sata disk). It is not acceptable for COLO. So
>  I think disk buff is necessary(just use it to replace qcow2).
> >>>
> >>> Why not tmpfs or ramdisk?
> >>
> >> Another problem:
> >> After failover, secondary write request will be written in (active disk)?
> >> It is better to write request to (nbd target). Is there any feature can
> >> be reused to implement it?
> > 
> > You can use block commit or stream to move the data.
> 
> Can the job stream move the data? I don't find the write ops in 
> block/stream.c.

It is bdrv_co_copy_on_readv that moves data.

Fam



Re: [Qemu-devel] [PATCH v4] hmp: add info iothreads command

2015-03-13 Thread Fam Zheng
On Fri, 03/13 16:58, Ting Wang wrote:
> Make "info iothreads" available on the HMP monitor.
> 
> The results are as follows:
> id1: thread_id=thread_id1
> id2: thread_id=thread_id2
> 
> Signed-off-by: Ting Wang 
> ---
> v4: use the PRId64 format specifier macro for the int64_t thread_id
> v3: fix comment and the trailing whitespace
> v2: add braces for if
> ---
>  hmp-commands.hx |  2 ++
>  hmp.c   | 22 ++
>  hmp.h   |  1 +
>  monitor.c   |  7 +++
>  4 files changed, 32 insertions(+)
> 
> diff --git a/hmp-commands.hx b/hmp-commands.hx
> index d5022d8..67d76ed 100644
> --- a/hmp-commands.hx
> +++ b/hmp-commands.hx
> @@ -1746,6 +1746,8 @@ show roms
>  show the TPM device
>  @item info memory-devices
>  show the memory devices
> +@item info iothreads
> +show iothreads
>  @end table
>  ETEXI
>  
> diff --git a/hmp.c b/hmp.c
> index 71c28bc..445a8ad 100644
> --- a/hmp.c
> +++ b/hmp.c
> @@ -821,6 +821,28 @@ void hmp_info_tpm(Monitor *mon, const QDict *qdict)
>  qapi_free_TPMInfoList(info_list);
>  }
>  
> +void hmp_info_iothreads(Monitor *mon, const QDict *qdict)
> +{
> +IOThreadInfoList *head = NULL, *elem = NULL;
> +
> +head = qmp_query_iothreads(NULL);
> +if (!head) {
> +monitor_printf(mon, "No iothread has been added\n");
> +return;
> +}
> +
> +elem = head;
> +while (elem) {
> +if (elem->value) {
> +monitor_printf(mon, "%s: thread_id=%" PRId64 "\n", 
> elem->value->id,
> +elem->value->thread_id);
> +}
> +elem = elem->next;
> +}
> +
> +qapi_free_IOThreadInfoList(head);
> +}
> +
>  void hmp_quit(Monitor *mon, const QDict *qdict)
>  {
>  monitor_suspend(mon);
> diff --git a/hmp.h b/hmp.h
> index 81177b2..d99090e 100644
> --- a/hmp.h
> +++ b/hmp.h
> @@ -38,6 +38,7 @@ void hmp_info_balloon(Monitor *mon, const QDict *qdict);
>  void hmp_info_pci(Monitor *mon, const QDict *qdict);
>  void hmp_info_block_jobs(Monitor *mon, const QDict *qdict);
>  void hmp_info_tpm(Monitor *mon, const QDict *qdict);
> +void hmp_info_iothreads(Monitor *mon, const QDict *qdict);
>  void hmp_quit(Monitor *mon, const QDict *qdict);
>  void hmp_stop(Monitor *mon, const QDict *qdict);
>  void hmp_system_reset(Monitor *mon, const QDict *qdict);
> diff --git a/monitor.c b/monitor.c
> index c86a89e..076a306 100644
> --- a/monitor.c
> +++ b/monitor.c
> @@ -2924,6 +2924,13 @@ static mon_cmd_t info_cmds[] = {
>  .mhandler.cmd = hmp_info_memory_devices,
>  },
>  {
> +.name   = "iothreads",
> +.args_type  = "",
> +.params = "",
> +.help   = "show iothreads",
> +.mhandler.cmd = hmp_info_iothreads,
> +},
> +{
>  .name   = NULL,
>  },
>  };
> -- 
> 1.8.5

Looks good, thanks!

Reviewed-by: Fam Zheng 



Re: [Qemu-devel] [PATCH v4] hmp: add info iothreads command

2015-03-13 Thread Patchew Tool

This series failed Patchew automatic testing.

Find the log fragments below (grepped lines around keywords "error" and
"warning"), or open the following URL to see the full log:

http://qemu.patchew.org/testing/log/<1426237119-110112-1-git-send-email-kathy.wangt...@huawei.com>

--8<-

  CCqobject/qerror.o
  GEN   trace/generated-events.c
  CCtrace/control.o
  CCtrace/qmp.o
  CCutil/osdep.o
  CCutil/cutils.o
  CCutil/unicode.o
  CCutil/qemu-timer-common.o
  CCutil/oslib-posix.o
  CCutil/qemu-thread-posix.o
  CCutil/event_notifier-posix.o
  CCutil/qemu-openpty.o
  CCutil/envlist.o
  CCutil/path.o
  CCutil/module.o
  CCutil/bitmap.o
  CCutil/bitops.o
  CCutil/hbitmap.o
  CCutil/fifo8.o
  CCutil/acl.o
  CCutil/error.o
  CCutil/qemu-error.o
  CCutil/compatfd.o
  CCutil/id.o
  CCutil/iov.o
  CCutil/aes.o
  CCutil/qemu-config.o
  CCutil/qemu-sockets.o
  CCutil/uri.o
  CCutil/notify.o
  CCutil/qemu-option.o
  CCutil/qemu-progress.o
  CCutil/hexdump.o
  CCutil/crc32c.o
  CCutil/throttle.o
  CCutil/getauxval.o
  CCutil/readline.o
  CCutil/rfifolock.o
  CCutil/rcu.o
  CCstubs/arch-query-cpu-def.o
  CCstubs/bdrv-commit-all.o
  CCstubs/chr-baum-init.o
  CCstubs/chr-msmouse.o
  CCstubs/chr-testdev.o
  CCstubs/clock-warp.o
  CCstubs/cpu-get-clock.o
  CCstubs/cpu-get-icount.o
  CCstubs/fdset-add-fd.o
  CCstubs/fdset-find-fd.o
  CCstubs/dump.o
  CCstubs/fdset-get-fd.o
  CCstubs/fdset-remove-fd.o
  CCstubs/gdbstub.o
  CCstubs/get-fd.o
  CCstubs/get-next-serial.o
  CCstubs/iothread-lock.o
  CCstubs/get-vm-name.o
  CCstubs/is-daemonized.o
  CCstubs/machine-init-done.o
  CCstubs/mon-is-qmp.o
  CCstubs/migr-blocker.o
  CCstubs/mon-printf.o
  CCstubs/mon-set-error.o
  CCstubs/monitor-init.o
  CCstubs/notify-event.o
  CCstubs/qtest.o
  CCstubs/reset.o
  CCstubs/runstate-check.o
  CCstubs/set-fd-handler.o
  CCstubs/slirp.o
  CCstubs/sysbus.o
  CCstubs/uuid.o
  CCstubs/vc-init.o
  CCstubs/vm-stop.o
  CCstubs/vmstate.o
  CCstubs/cpus.o
  CCstubs/kvm.o
  CCstubs/qmp_pc_dimm_device_list.o
  CCqemu-nbd.o
  CCasync.o
  CCthread-pool.o
  CCnbd.o
  CCblock.o
--
GTESTER tests/test-mul64
GTESTER tests/test-int128
GTESTER tests/rcutorture
GTESTER tests/test-rcu-list
GTESTER tests/test-bitops
GTESTER tests/check-qom-interface
GTESTER tests/test-qemu-opts
GTESTER tests/test-write-threshold
GTESTER check-qtest-x86_64
GTESTER tests/test-qmp-output-visitor
GTESTER tests/test-qmp-input-visitor
GTESTER tests/test-qmp-input-strict
GTESTER tests/test-qmp-commands
GTESTER tests/test-string-input-visitor
GTESTER tests/test-string-output-visitor
GTESTER tests/test-qmp-event
GTESTER tests/test-opts-visitor
GTESTER tests/test-visitor-serialization
socket_accept failed: Resource temporarily unavailable
**
ERROR:/var/tmp/patchew-test/git/tests/libqtest.c:192:qtest_init: assertion 
failed: (s->fd >= 0 && s->qmp_fd >= 0)
GTester: last random seed: R02Sa6e2a5d48f79c1916f52824e1b74ecc5
socket_accept failed: Resource temporarily unavailable
**
ERROR:/var/tmp/patchew-test/git/tests/libqtest.c:192:qtest_init: assertion 
failed: (s->fd >= 0 && s->qmp_fd >= 0)
GTester: last random seed: R02Sd05e2b63284437ca347a3e639d127a65
blkdebug: Suspended request 'A'
blkdebug: Resuming request 'A'
main-loop: WARNING: I/O thread spun for 1000 iterations
main-loop: WARNING: I/O thread spun for 1000 iterations
main-loop: WARNING: I/O thread spun for 1000 iterations
main-loop: WARNING: I/O thread spun for 1000 iterations
[vmxnet3][WR][vmxnet3_peer_has_vnet_hdr]: Peer has no virtio extension. Task 
offloads will be emulated.
make: *** [check-qtest-x86_64] Error 1

Test failed.




Re: [Qemu-devel] [PATCH v10 2/7] hw/vfio/platform: vfio-platform skeleton

2015-03-13 Thread Eric Auger
Hi Alex,

Thank you for your review and the R-b on 5/7 & 7/7.

Please apologize for the long delay in response, mostly due to my
vacation :-(

I took into account all the comments below

Best Regards

Eric
On 02/17/2015 11:56 AM, Alex Bennée wrote:
> 
> Eric Auger  writes:
> 
>> Minimal VFIO platform implementation supporting register space
>> user mapping but not IRQ assignment.
>>
>> Signed-off-by: Kim Phillips 
>> Signed-off-by: Eric Auger 
> 
> See comments inline.
> 
> 
>> +/**
>> + * vfio_populate_device - initialize MMIO region and IRQ
>> + * @vbasedev: the VFIO device
>> + *
>> + * query the VFIO device for exposed MMIO regions and IRQ and
>> + * populate the associated fields in the device struct
>> + */
>> +static int vfio_populate_device(VFIODevice *vbasedev)
>> +{
>> +struct vfio_region_info reg_info = { .argsz = sizeof(reg_info) };
> 
> This could be inside the for block.
> 
>> +int i, ret = -1;
>> +VFIOPlatformDevice *vdev =
>> +container_of(vbasedev, VFIOPlatformDevice, vbasedev);
>> +
>> +if (!(vbasedev->flags & VFIO_DEVICE_FLAGS_PLATFORM)) {
>> +error_report("vfio: Um, this isn't a platform device");
>> +goto error;
>> +}
>> +
>> +vdev->regions = g_malloc0(sizeof(VFIORegion *) *
>> vbasedev->num_regions);
> 
> I may have considered a g_malloc0_n but I see that's not actually used
> in the rest of the code (newer glib?).
> 
>> +
>> +for (i = 0; i < vbasedev->num_regions; i++) {
>> +vdev->regions[i] = g_malloc0(sizeof(VFIORegion));
> 
> An intermediate VFIORegion *ptr here would have saved a bunch of typing
> later on ;-) 
> 
>> +reg_info.index = i;
>> +ret = ioctl(vbasedev->fd, VFIO_DEVICE_GET_REGION_INFO, ®_info);
>> +if (ret) {
>> +error_report("vfio: Error getting region %d info: %m", i);
>> +goto error;
>> +}
>> +vdev->regions[i]->flags = reg_info.flags;
>> +vdev->regions[i]->size = reg_info.size;
>> +vdev->regions[i]->fd_offset = reg_info.offset;
>> +vdev->regions[i]->nr = i;
>> +vdev->regions[i]->vbasedev = vbasedev;
>> +
>> +trace_vfio_platform_populate_regions(vdev->regions[i]->nr,
>> +(unsigned long)vdev->regions[i]->flags,
>> +(unsigned long)vdev->regions[i]->size,
>> +vdev->regions[i]->vbasedev->fd,
>> +(unsigned long)vdev->regions[i]->fd_offset);
>> +}
>> +
>> +return 0;
>> +error:
>> +for (i = 0; i < vbasedev->num_regions; i++) {
>> +g_free(vdev->regions[i]);
>> +}
>> +g_free(vdev->regions);
>> +return ret;
>> +}
>> +
>> +/* specialized functions ofr VFIO Platform devices */
>> +static VFIODeviceOps vfio_platform_ops = {
>> +.vfio_compute_needs_reset = vfio_platform_compute_needs_reset,
>> +.vfio_hot_reset_multi = vfio_platform_hot_reset_multi,
>> +.vfio_populate_device = vfio_populate_device,
>> +};
>> +
>> +/**
>> + * vfio_base_device_init - implements some of the VFIO mechanics
>> + * @vbasedev: the VFIO device
>> + *
>> + * retrieves the group the device belongs to and get the device fd
>> + * returns the VFIO device fd
>> + * precondition: the device name must be initialized
>> + */
>> +static int vfio_base_device_init(VFIODevice *vbasedev)
>> +{
>> +VFIOGroup *group;
>> +VFIODevice *vbasedev_iter;
>> +char path[PATH_MAX], iommu_group_path[PATH_MAX], *group_name;
>> +ssize_t len;
>> +struct stat st;
>> +int groupid;
>> +int ret;
>> +
>> +/* name must be set prior to the call */
>> +if (!vbasedev->name) {
>> +return -EINVAL;
>> +}
>> +
>> +/* Check that the host device exists */
>> +snprintf(path, sizeof(path), "/sys/bus/platform/devices/%s/",
>> + vbasedev->name);
>> +
>> +if (stat(path, &st) < 0) {
>> +error_report("vfio: error: no such host device: %s", path);
>> +return -errno;
>> +}
>> +
>> +strncat(path, "iommu_group", sizeof(path) - strlen(path) - 1);
> 
> Consider g_strlcat which has nicer max length semantics.
> 
>> +len = readlink(path, iommu_group_path, sizeof(path));
>> +if (len <= 0 || len >= sizeof(path)) {
> 
> readlink should never report more than sizeof(path) although that will
> indicate a ENAMETOOLONG.
> 
>> +error_report("vfio: error no iommu_group for device");
>> +return len < 0 ? -errno : ENAMETOOLONG;
>> +}
>> +
>> +iommu_group_path[len] = 0;
>> +group_name = basename(iommu_group_path);
>> +
>> +if (sscanf(group_name, "%d", &groupid) != 1) {
>> +error_report("vfio: error reading %s: %m", path);
>> +return -errno;
>> +}
>> +
>> +trace_vfio_platform_base_device_init(vbasedev->name, groupid);
>> +
>> +group = vfio_get_group(groupid, &address_space_memory);
>> +if (!group) {
>> +error_report("vfio: failed to get group %d", groupid);
>> +return -ENOENT;
>> +  

Re: [Qemu-devel] [PATCH v4] hmp: add info iothreads command

2015-03-13 Thread Fam Zheng
On Fri, 03/13 02:16, Patchew Tool wrote:
> socket_accept failed: Resource temporarily unavailable
> **
> ERROR:/var/tmp/patchew-test/git/tests/libqtest.c:192:qtest_init: assertion 
> failed: (s->fd >= 0 && s->qmp_fd >= 0)
> GTester: last random seed: R02Sa6e2a5d48f79c1916f52824e1b74ecc5
> socket_accept failed: Resource temporarily unavailable
> **
> ERROR:/var/tmp/patchew-test/git/tests/libqtest.c:192:qtest_init: assertion 
> failed: (s->fd >= 0 && s->qmp_fd >= 0)
> GTester: last random seed: R02Sd05e2b63284437ca347a3e639d127a65
> blkdebug: Suspended request 'A'
> blkdebug: Resuming request 'A'
> main-loop: WARNING: I/O thread spun for 1000 iterations
> main-loop: WARNING: I/O thread spun for 1000 iterations
> main-loop: WARNING: I/O thread spun for 1000 iterations
> main-loop: WARNING: I/O thread spun for 1000 iterations
> [vmxnet3][WR][vmxnet3_peer_has_vnet_hdr]: Peer has no virtio extension. Task 
> offloads will be emulated.
> make: *** [check-qtest-x86_64] Error 1

Hmm.. looks like a false alarm, the socket initialization failed but that's
definitely not related to this patch.

Fam



Re: [Qemu-devel] [PATCH v10 6/7] hw/arm/sysbus-fdt: enable vfio-calxeda-xgmac dynamic instantiation

2015-03-13 Thread Eric Auger
Alex,
On 02/17/2015 12:36 PM, Alex Bennée wrote:
> 
> Eric Auger  writes:
> 
>> vfio-calxeda-xgmac now can be instantiated using the -device option.
>> The node creation function generates a very basic dt node composed
>> of the compat, reg and interrupts properties
>>
>> Signed-off-by: Eric Auger 
>>
>> ---
>> v8 -> v9:
>> - properly free resources in case of errors in
>>   add_calxeda_midway_xgmac_fdt_node
>>
>> v7 -> v8:
>> - move the add_fdt_node_functions array declaration between the device
>>   specific code and the generic code to avoid forward declarations of
>>   decice specific functions
>> - rename add_basic_vfio_fdt_node into
>>   add_calxeda_midway_xgmac_fdt_node
>>
>> v6 -> v7:
>> - compat string re-formatting removed since compat string is not exposed
>>   anymore as a user option
>> - VFIO IRQ kick-off removed from sysbus-fdt and moved to VFIO platform
>>   device
>> ---
>>  hw/arm/sysbus-fdt.c | 83 
>> +
>>  1 file changed, 83 insertions(+)
>>
>> diff --git a/hw/arm/sysbus-fdt.c b/hw/arm/sysbus-fdt.c
>> index 3038b94..d4f97f5 100644
>> --- a/hw/arm/sysbus-fdt.c
>> +++ b/hw/arm/sysbus-fdt.c
>> @@ -26,6 +26,8 @@
>>  #include "sysemu/device_tree.h"
>>  #include "hw/platform-bus.h"
>>  #include "sysemu/sysemu.h"
>> +#include "hw/vfio/vfio-platform.h"
>> +#include "hw/vfio/vfio-calxeda-xgmac.h"
>>  
>>  /*
>>   * internal struct that contains the information to create dynamic
>> @@ -53,11 +55,92 @@ typedef struct NodeCreationPair {
>>  int (*add_fdt_node_fn)(SysBusDevice *sbdev, void *opaque);
>>  } NodeCreationPair;
>>  
>> +/* Device Specific Code */
>> +
>> +/**
>> + * add_calxeda_midway_xgmac_fdt_node
>> + *
>> + * Generates a very simple node with following properties:
>> + * compatible string, regs, interrupts
>> + */
>> +static int add_calxeda_midway_xgmac_fdt_node(SysBusDevice *sbdev, void 
>> *opaque)
>> +{
>> +PlatformBusFDTData *data = opaque;
>> +PlatformBusDevice *pbus = data->pbus;
>> +void *fdt = data->fdt;
>> +const char *parent_node = data->pbus_node_name;
>> +int compat_str_len;
>> +char *nodename;
>> +int i, ret = -1;
>> +uint32_t *irq_attr;
>> +uint64_t *reg_attr;
>> +uint64_t mmio_base;
>> +uint64_t irq_number;
>> +VFIOPlatformDevice *vdev = VFIO_PLATFORM_DEVICE(sbdev);
>> +VFIODevice *vbasedev = &vdev->vbasedev;
>> +Object *obj = OBJECT(sbdev);
>> +
>> +mmio_base = object_property_get_int(obj, "mmio[0]", NULL);
>> +
>> +nodename = g_strdup_printf("%s/%s@%" PRIx64, parent_node,
>> +   vbasedev->name,
>> +   mmio_base);
>> +
>> +qemu_fdt_add_subnode(fdt, nodename);
>> +
>> +compat_str_len = strlen(vdev->compat) + 1;
>> +qemu_fdt_setprop(fdt, nodename, "compatible",
>> +  vdev->compat, compat_str_len);
>> +
>> +reg_attr = g_new(uint64_t, vbasedev->num_regions*4);
>> +
>> +for (i = 0; i < vbasedev->num_regions; i++) {
>> +mmio_base = platform_bus_get_mmio_addr(pbus, sbdev, i);
>> +reg_attr[4*i] = 1;
>> +reg_attr[4*i+1] = mmio_base;
>> +reg_attr[4*i+2] = 1;
>> +reg_attr[4*i+3] = memory_region_size(&vdev->regions[i]->mem);
>> +}
>> +
>> +ret = qemu_fdt_setprop_sized_cells_from_array(fdt, nodename, "reg",
>> + vbasedev->num_regions*2, reg_attr);
> 
> Could we use qemu_fdt_setprop_sized_cells() like everyone else to hide
> the uglyness of the _from_array?

Due to the fact I need to handle 'num_regions' regions, I need to setup
the array programmatically. I could use qemu_fdt_setprop instead since
the cell size always is 1 but I currently do not see how I could easily
take benefit from qemu_fdt_setprop_sized_cells.
> 
>> +if (ret) {
>> +error_report("could not set reg property of node %s", nodename);
>> +goto fail_reg;
>> +}
>> +
>> +irq_attr = g_new(uint32_t, vbasedev->num_irqs*3);
>> +
>> +for (i = 0; i < vbasedev->num_irqs; i++) {
>> +irq_number = platform_bus_get_irqn(pbus, sbdev , i)
>> + + data->irq_start;
>> +irq_attr[3*i] = cpu_to_be32(0);
>> +irq_attr[3*i+1] = cpu_to_be32(irq_number);
>> +irq_attr[3*i+2] = cpu_to_be32(0x4);
>> +}
>> +
>> +   ret = qemu_fdt_setprop(fdt, nodename, "interrupts",
>> + irq_attr,
>> vbasedev->num_irqs*3*sizeof(uint32_t));
> 
> Ditto.
Here also I need to handle num_irqs. But maybe I misunderstand your
comment here.

Best Regards

Eric
> 
>> +if (ret) {
>> +error_report("could not set interrupts property of node %s",
>> + nodename);
>> +}
>> +
>> +g_free(irq_attr);
>> +fail_reg:
>> +g_free(reg_attr);
>> +g_free(nodename);
>> +return ret;
>> +}
>> +
>>  /* list of supported dynamic sysbus devices */
>>  static const NodeCreationPair add_fdt_node_functions[] = {
>> +{TYPE_VFIO_CALXEDA_XGMAC, add_calxe

Re: [Qemu-devel] [PATCH v2] s390x/kvm: Guest Migration TOD clock synchronization

2015-03-13 Thread Cornelia Huck
On Mon,  9 Mar 2015 15:56:08 +0100
Jens Freimann  wrote:

> From: "Jason J. Herne" 
> 
> Synchronizes the guest TOD clock across a migration by sending the guest TOD
> clock value to the destination system. If the guest TOD clock is not preserved
> across a migration then the guest's view of time will snap backwards if the
> destination host clock is behind the source host clock. This will cause the
> guest to hang immediately upon resuming on the destination system.
> 
> Reviewed-by: David Hildenbrand 
> Signed-off-by: Jason J. Herne 
> Signed-off-by: Jens Freimann 
> 
> ---
> v1->v2:
>  * removed unrelated change in linux-headers
> 
> ---
>  hw/s390x/s390-virtio-ccw.c |  4 
>  hw/s390x/s390-virtio.c | 52 
> ++
>  target-s390x/cpu.h | 34 ++
>  target-s390x/kvm.c | 39 ++
>  4 files changed, 129 insertions(+)

Applied to my s390-next branch.




Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-posix-acl: Fix out-of-bounds access

2015-03-13 Thread Shannon Zhao
On 2015/3/13 16:31, Aneesh Kumar K.V wrote:
> Shannon Zhao  writes:
> 
>> It's detected by coverity. Fix out-of-bounds access of the function 
>> mp_dacl_listxattr.
>>
>> Signed-off-by: Shannon Zhao 
>> Signed-off-by: Shannon Zhao 
>> ---
>>  hw/9pfs/virtio-9p-posix-acl.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/hw/9pfs/virtio-9p-posix-acl.c b/hw/9pfs/virtio-9p-posix-acl.c
>> index 803d9d9..09dad07 100644
>> --- a/hw/9pfs/virtio-9p-posix-acl.c
>> +++ b/hw/9pfs/virtio-9p-posix-acl.c
>> @@ -114,7 +114,7 @@ static ssize_t mp_dacl_listxattr(FsContext *ctx, const 
>> char *path,
>>  }
>>
>>  /* len includes the trailing NUL */
>> -memcpy(value, ACL_ACCESS, len);
>> +memcpy(value, ACL_DEFAULT, len);
>>  return 0;
>>  }
> 
> Applied.
> 
Thanks :-)

> Thanks
> -aneesh
> 
> 
> .
> 




Re: [Qemu-devel] [PATCH 1/2] virtio-ccw: assure BE accesses

2015-03-13 Thread Cornelia Huck
On Wed, 11 Mar 2015 10:57:50 +0100
Cornelia Huck  wrote:

> All fields in structures transmitted by ccws are big endian; assure
> we handle them as such.
> 
> Reviewed-by: Thomas Huth 
> Reviewed-by: David Hildenbrand 
> Signed-off-by: Cornelia Huck 
> ---
>  hw/s390x/virtio-ccw.c | 22 +-
>  1 file changed, 13 insertions(+), 9 deletions(-)

Applied to my s390-next branch.




[Qemu-devel] [PATCH 0/9] add virtio-gpu with 2d support

2015-03-13 Thread Gerd Hoffmann
  Hi,

Next round of virtio-gpu patches.  Patches 1-8 are meant to be merged,
patch 9 is a hack to simplify testing with libvirt and will not be
merged.

Changes since the RfC submission earlier this month are a bunch of
sanity checks being added (mostly pointed out by max) and the
virtio-1.0 adaptions are squashed in now.

This series depends on virtio 1.0 patches still not merged.

This series is also available via git:
  git://git.kraxel.org/qemu tags/virtio-gpu-2015-03-13

The virtio patches are here (mst's virtio-1.0 branch, rebased to master):
  git://git.kraxel.org/qemu tags/virtio-mst-rebased-2015-03-13

Guest kernel driver is here:
  git://git.kraxel.org/linux virtio-gpu

Usage:
  qemu-system-x86_64 -vga virtio [ ... ]
  qemu-system-x86_64 -device virtio-vga [ ... ]
  qemu-system-ppc64 -M pseries -device virtio-gpu-pci [ ... ]
  qemu-system-arm -M virt -device virtio-gpu-device [ ... ]

Gerd Hoffmann (9):
  virtio-gpu/2d: add hardware spec include file
  virtio-gpu/2d: add virtio gpu core code
  virtio-gpu-pci: add virtio pci support
  virtio-vga: add virtio gpu device with vga compatibility
  virtio-vga: add '-vga virtio' support
  virtio-vga: add vgabios configuration
  virtio-vga: add vgabios binary
  virtio-gpu: add to display-vga test
  [hack] virtio-gpu: maskerade as -device VGA

 Makefile   |   2 +-
 default-configs/x86_64-softmmu.mak |   1 +
 hw/display/Makefile.objs   |   4 +
 hw/display/vga-pci.c   |   2 +-
 hw/display/virtio-gpu-pci.c|  68 +++
 hw/display/virtio-gpu.c| 923 +
 hw/display/virtio-vga.c| 152 ++
 hw/pci/pci.c   |   2 +
 hw/virtio/virtio-pci.h |  15 +
 include/hw/virtio/virtgpu_hw.h | 203 
 include/hw/virtio/virtio-gpu.h | 147 ++
 include/sysemu/sysemu.h|   2 +-
 pc-bios/vgabios-virtio.bin | Bin 0 -> 37376 bytes
 qemu-options.hx|   4 +-
 roms/Makefile  |   2 +-
 roms/config.vga-virtio |   6 +
 tests/Makefile |   3 +
 tests/display-vga-test.c   |  18 +
 trace-events   |  14 +
 vl.c   |  13 +
 20 files changed, 1576 insertions(+), 5 deletions(-)
 create mode 100644 hw/display/virtio-gpu-pci.c
 create mode 100644 hw/display/virtio-gpu.c
 create mode 100644 hw/display/virtio-vga.c
 create mode 100644 include/hw/virtio/virtgpu_hw.h
 create mode 100644 include/hw/virtio/virtio-gpu.h
 create mode 100644 pc-bios/vgabios-virtio.bin
 create mode 100644 roms/config.vga-virtio

-- 
1.8.3.1




[Qemu-devel] [PATCH 5/9] virtio-vga: add '-vga virtio' support

2015-03-13 Thread Gerd Hoffmann
Some convinience fluff:  Add support for '-vga virtio', also add
virtio-vga to the list of vga cards so '-device virtio-vga' will
turn off the default vga.

Written by Dave Airlie and Gerd Hoffmann.

Signed-off-by: Dave Airlie 
Signed-off-by: Gerd Hoffmann 
---
 hw/pci/pci.c|  2 ++
 include/sysemu/sysemu.h |  2 +-
 qemu-options.hx |  4 +++-
 vl.c| 13 +
 4 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/hw/pci/pci.c b/hw/pci/pci.c
index 6941a82..f6eeaa9 100644
--- a/hw/pci/pci.c
+++ b/hw/pci/pci.c
@@ -1677,6 +1677,8 @@ PCIDevice *pci_vga_init(PCIBus *bus)
 return pci_create_simple(bus, -1, "VGA");
 case VGA_VMWARE:
 return pci_create_simple(bus, -1, "vmware-svga");
+case VGA_VIRTIO:
+return pci_create_simple(bus, -1, "virtio-vga");
 case VGA_NONE:
 default: /* Other non-PCI types. Checking for unsupported types is already
 done in vl.c. */
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 6e85097..4ee32bf 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -104,7 +104,7 @@ extern int autostart;
 
 typedef enum {
 VGA_NONE, VGA_STD, VGA_CIRRUS, VGA_VMWARE, VGA_XENFB, VGA_QXL,
-VGA_TCX, VGA_CG3, VGA_DEVICE
+VGA_TCX, VGA_CG3, VGA_DEVICE, VGA_VIRTIO,
 } VGAInterfaceType;
 
 extern int vga_interface_type;
diff --git a/qemu-options.hx b/qemu-options.hx
index 837624d..49b0f8f 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1089,7 +1089,7 @@ Rotate graphical output some deg left (only PXA LCD).
 ETEXI
 
 DEF("vga", HAS_ARG, QEMU_OPTION_vga,
-"-vga [std|cirrus|vmware|qxl|xenfb|tcx|cg3|none]\n"
+"-vga [std|cirrus|vmware|qxl|xenfb|tcx|cg3|virtio|none]\n"
 "select video card type\n", QEMU_ARCH_ALL)
 STEXI
 @item -vga @var{type}
@@ -1122,6 +1122,8 @@ fixed resolution of 1024x768.
 (sun4m only) Sun cgthree framebuffer. This is a simple 8-bit framebuffer
 for sun4m machines available in both 1024x768 (OpenBIOS) and 1152x900 (OBP)
 resolutions aimed at people wishing to run older Solaris versions.
+@item virtio
+Virtio VGA card.
 @item none
 Disable VGA card.
 @end table
diff --git a/vl.c b/vl.c
index eba5d4c..7f903a5 100644
--- a/vl.c
+++ b/vl.c
@@ -231,6 +231,7 @@ static struct {
 { .driver = "isa-cirrus-vga",   .flag = &default_vga   },
 { .driver = "vmware-svga",  .flag = &default_vga   },
 { .driver = "qxl-vga",  .flag = &default_vga   },
+{ .driver = "virtio-vga",   .flag = &default_vga   },
 };
 
 static QemuOptsList qemu_rtc_opts = {
@@ -1871,6 +1872,11 @@ static bool cg3_vga_available(void)
 return object_class_by_name("cgthree");
 }
 
+static bool virtio_vga_available(void)
+{
+return object_class_by_name("virtio-vga");
+}
+
 static void select_vgahw (const char *p)
 {
 const char *opts;
@@ -1897,6 +1903,13 @@ static void select_vgahw (const char *p)
 fprintf(stderr, "Error: VMWare SVGA not available\n");
 exit(0);
 }
+} else if (strstart(p, "virtio", &opts)) {
+if (virtio_vga_available()) {
+vga_interface_type = VGA_VIRTIO;
+} else {
+fprintf(stderr, "Error: Virtio VGA not available\n");
+exit(0);
+}
 } else if (strstart(p, "xenfb", &opts)) {
 vga_interface_type = VGA_XENFB;
 } else if (strstart(p, "qxl", &opts)) {
-- 
1.8.3.1




[Qemu-devel] [PATCH 6/9] virtio-vga: add vgabios configuration

2015-03-13 Thread Gerd Hoffmann
Add seavgabios configuration for virtio-vga,
hook up the new vgabios in the makefiles.

Signed-off-by: Gerd Hoffmann 
---
 Makefile   | 2 +-
 roms/Makefile  | 2 +-
 roms/config.vga-virtio | 6 ++
 3 files changed, 8 insertions(+), 2 deletions(-)
 create mode 100644 roms/config.vga-virtio

diff --git a/Makefile b/Makefile
index 884b59d..16899cc 100644
--- a/Makefile
+++ b/Makefile
@@ -340,7 +340,7 @@ bepocz
 
 ifdef INSTALL_BLOBS
 BLOBS=bios.bin bios-256k.bin sgabios.bin vgabios.bin vgabios-cirrus.bin \
-vgabios-stdvga.bin vgabios-vmware.bin vgabios-qxl.bin \
+vgabios-stdvga.bin vgabios-vmware.bin vgabios-qxl.bin vgabios-virtio.bin \
 acpi-dsdt.aml q35-acpi-dsdt.aml \
 ppc_rom.bin openbios-sparc32 openbios-sparc64 openbios-ppc QEMU,tcx.bin 
QEMU,cgthree.bin \
 pxe-e1000.rom pxe-eepro100.rom pxe-ne2k_pci.rom \
diff --git a/roms/Makefile b/roms/Makefile
index 610b534..c76cd5b 100644
--- a/roms/Makefile
+++ b/roms/Makefile
@@ -1,5 +1,5 @@
 
-vgabios_variants := stdvga cirrus vmware qxl isavga
+vgabios_variants := stdvga cirrus vmware qxl isavga virtio
 vgabios_targets  := $(subst -isavga,,$(patsubst 
%,vgabios-%.bin,$(vgabios_variants)))
 pxerom_variants  := e1000 eepro100 ne2k_pci pcnet rtl8139 virtio
 pxerom_targets   := 8086100e 80861209 10500940 10222000 10ec8139 1af41000
diff --git a/roms/config.vga-virtio b/roms/config.vga-virtio
new file mode 100644
index 000..aa7a15b
--- /dev/null
+++ b/roms/config.vga-virtio
@@ -0,0 +1,6 @@
+CONFIG_BUILD_VGABIOS=y
+CONFIG_VGA_BOCHS=y
+CONFIG_VGA_PCI=y
+CONFIG_OVERRIDE_PCI_ID=y
+CONFIG_VGA_VID=0x1af4
+CONFIG_VGA_DID=0x1050
-- 
1.8.3.1




[Qemu-devel] [PATCH 1/9] virtio-gpu/2d: add hardware spec include file

2015-03-13 Thread Gerd Hoffmann
This patch adds the header file with structs and defines for
the virtio based gpu device.  Covers 2d operations only.

Written by Dave Airlie and Gerd Hoffmann.

Signed-off-by: Dave Airlie 
Signed-off-by: Gerd Hoffmann 
---
 include/hw/virtio/virtgpu_hw.h | 203 +
 1 file changed, 203 insertions(+)
 create mode 100644 include/hw/virtio/virtgpu_hw.h

diff --git a/include/hw/virtio/virtgpu_hw.h b/include/hw/virtio/virtgpu_hw.h
new file mode 100644
index 000..d6641e8
--- /dev/null
+++ b/include/hw/virtio/virtgpu_hw.h
@@ -0,0 +1,203 @@
+/*
+ * Virtio GPU Device
+ *
+ * Copyright Red Hat, Inc. 2013-2014
+ *
+ * Authors:
+ * Dave Airlie 
+ * Gerd Hoffmann 
+ *
+ * This header is BSD licensed so anyone can use the definitions
+ * to implement compatible drivers/servers:
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of IBM nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL IBM OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+ * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
+ * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#ifndef VIRTIO_GPU_HW_H
+#define VIRTIO_GPU_HW_H
+
+enum virtio_gpu_ctrl_type {
+VIRTIO_GPU_UNDEFINED = 0,
+
+/* 2d commands */
+VIRTIO_GPU_CMD_GET_DISPLAY_INFO = 0x0100,
+VIRTIO_GPU_CMD_RESOURCE_CREATE_2D,
+VIRTIO_GPU_CMD_RESOURCE_UNREF,
+VIRTIO_GPU_CMD_SET_SCANOUT,
+VIRTIO_GPU_CMD_RESOURCE_FLUSH,
+VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D,
+VIRTIO_GPU_CMD_RESOURCE_ATTACH_BACKING,
+VIRTIO_GPU_CMD_RESOURCE_DETACH_BACKING,
+
+/* cursor commands */
+VIRTIO_GPU_CMD_UPDATE_CURSOR = 0x0300,
+VIRTIO_GPU_CMD_MOVE_CURSOR,
+
+/* success responses */
+VIRTIO_GPU_RESP_OK_NODATA = 0x1100,
+VIRTIO_GPU_RESP_OK_DISPLAY_INFO,
+
+/* error responses */
+VIRTIO_GPU_RESP_ERR_UNSPEC = 0x1200,
+VIRTIO_GPU_RESP_ERR_OUT_OF_MEMORY,
+VIRTIO_GPU_RESP_ERR_INVALID_SCANOUT_ID,
+VIRTIO_GPU_RESP_ERR_INVALID_RESOURCE_ID,
+VIRTIO_GPU_RESP_ERR_INVALID_CONTEXT_ID,
+VIRTIO_GPU_RESP_ERR_INVALID_PARAMETER,
+};
+
+#define VIRTIO_GPU_FLAG_FENCE (1 << 0)
+
+struct virtio_gpu_ctrl_hdr {
+uint32_t type;
+uint32_t flags;
+uint64_t fence_id;
+uint32_t ctx_id;
+uint32_t padding;
+};
+
+/* data passed in the cursor vq */
+
+struct virtio_gpu_cursor_pos {
+uint32_t scanout_id;
+uint32_t x, y;
+uint32_t padding;
+};
+
+/* VIRTIO_GPU_CMD_UPDATE_CURSOR, VIRTIO_GPU_CMD_MOVE_CURSOR */
+struct virtio_gpu_update_cursor {
+struct virtio_gpu_ctrl_hdr hdr;
+struct virtio_gpu_cursor_pos pos;  /* update & move */
+uint32_t resource_id;   /* update only */
+uint32_t hot_x; /* update only */
+uint32_t hot_y; /* update only */
+uint32_t padding;
+};
+
+/* data passed in the control vq, 2d related */
+
+struct virtio_gpu_rect {
+uint32_t x, y;
+uint32_t width;
+uint32_t height;
+};
+
+/* VIRTIO_GPU_CMD_RESOURCE_UNREF */
+struct virtio_gpu_resource_unref {
+struct virtio_gpu_ctrl_hdr hdr;
+uint32_t resource_id;
+uint32_t padding;
+};
+
+/* VIRTIO_GPU_CMD_RESOURCE_CREATE_2D: create a 2d resource with a format */
+struct virtio_gpu_resource_create_2d {
+struct virtio_gpu_ctrl_hdr hdr;
+uint32_t resource_id;
+uint32_t format;
+uint32_t width;
+uint32_t height;
+};
+
+/* VIRTIO_GPU_CMD_SET_SCANOUT */
+struct virtio_gpu_set_scanout {
+struct virtio_gpu_ctrl_hdr hdr;
+struct virtio_gpu_rect r;
+uint32_t scanout_id;
+uint32_t resource_id;
+};
+
+/* VIRTIO_GPU_CMD_RESOURCE_FLUSH */
+struct virtio_gpu_resource_flush {
+struct virtio_gpu_ctrl_hdr hdr;
+struct virtio_gpu_rect r;
+uint32_t resource_id;
+uint32_t padding;
+};
+
+/* VIRTIO_G

[Qemu-devel] [PATCH 8/9] virtio-gpu: add to display-vga test

2015-03-13 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann 
---
 tests/Makefile   |  3 +++
 tests/display-vga-test.c | 18 ++
 2 files changed, 21 insertions(+)

diff --git a/tests/Makefile b/tests/Makefile
index 588f438..55ad89f 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -133,6 +133,9 @@ check-qtest-pci-y += tests/display-vga-test$(EXESUF)
 gcov-files-pci-y += hw/display/vga.c
 gcov-files-pci-y += hw/display/cirrus_vga.c
 gcov-files-pci-y += hw/display/vga-pci.c
+gcov-files-pci-y += hw/display/virtio-gpu.c
+gcov-files-pci-y += hw/display/virtio-gpu-pci.c
+gcov-files-pci-y += hw/display/virtio-vga.c
 check-qtest-pci-y += tests/intel-hda-test$(EXESUF)
 gcov-files-pci-y += hw/audio/intel-hda.c hw/audio/hda-codec.c
 
diff --git a/tests/display-vga-test.c b/tests/display-vga-test.c
index 17f5910..cd0b873 100644
--- a/tests/display-vga-test.c
+++ b/tests/display-vga-test.c
@@ -36,6 +36,20 @@ static void pci_multihead(void)
 qtest_end();
 }
 
+#ifdef CONFIG_VIRTIO_GPU
+static void pci_virtio_gpu(void)
+{
+qtest_start("-vga none -device virtio-gpu-pci");
+qtest_end();
+}
+
+static void pci_virtio_vga(void)
+{
+qtest_start("-vga none -device virtio-vga");
+qtest_end();
+}
+#endif
+
 int main(int argc, char **argv)
 {
 int ret;
@@ -46,6 +60,10 @@ int main(int argc, char **argv)
 qtest_add_func("/display/pci/stdvga", pci_stdvga);
 qtest_add_func("/display/pci/secondary", pci_secondary);
 qtest_add_func("/display/pci/multihead", pci_multihead);
+#ifdef CONFIG_VIRTIO_GPU
+qtest_add_func("/display/pci/virtio-gpu", pci_virtio_gpu);
+qtest_add_func("/display/pci/virtio-vga", pci_virtio_vga);
+#endif
 ret = g_test_run();
 
 return ret;
-- 
1.8.3.1




[Qemu-devel] [PATCH 9/9] [hack] virtio-gpu: maskerade as -device VGA

2015-03-13 Thread Gerd Hoffmann
Newer libvirt versions start looking up VGA in the QOM tree.
So tricking libvirt this way ...




... to test virtio-vga stopped working.

Lets rename VGA to stdvga and virtio-vga to VGA to get things going
again.  A simple ...

  

... will give you virtio-vga when building qemu with this patch applied.

Signed-off-by: Gerd Hoffmann 
---
 hw/display/vga-pci.c| 2 +-
 hw/display/virtio-vga.c | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/hw/display/vga-pci.c b/hw/display/vga-pci.c
index aabfc23..8ed1ebd 100644
--- a/hw/display/vga-pci.c
+++ b/hw/display/vga-pci.c
@@ -349,7 +349,7 @@ static void secondary_class_init(ObjectClass *klass, void 
*data)
 }
 
 static const TypeInfo vga_info = {
-.name  = "VGA",
+.name  = "stdvga",
 .parent= TYPE_PCI_DEVICE,
 .instance_init = pci_std_vga_init,
 .instance_size = sizeof(PCIVGAState),
diff --git a/hw/display/virtio-vga.c b/hw/display/virtio-vga.c
index bbde750..ded28c1 100644
--- a/hw/display/virtio-vga.c
+++ b/hw/display/virtio-vga.c
@@ -7,7 +7,7 @@
 /*
  * virtio-vga: This extends VirtioPCIProxy.
  */
-#define TYPE_VIRTIO_VGA "virtio-vga"
+#define TYPE_VIRTIO_VGA "VGA"
 #define VIRTIO_VGA(obj) \
 OBJECT_CHECK(VirtIOVGA, (obj), TYPE_VIRTIO_VGA)
 
@@ -15,6 +15,7 @@ typedef struct VirtIOVGA {
 VirtIOPCIProxy parent_obj;
 VirtIOGPU  vdev;
 VGACommonState vga;
+uint32_t   dummy;
 } VirtIOVGA;
 
 static void virtio_vga_invalidate_display(void *opaque)
@@ -108,6 +109,7 @@ static void virtio_vga_reset(DeviceState *dev)
 static Property virtio_vga_properties[] = {
 DEFINE_VIRTIO_GPU_PROPERTIES(VirtIOVGA, vdev.conf),
 DEFINE_VIRTIO_GPU_PCI_PROPERTIES(VirtIOPCIProxy),
+DEFINE_PROP_UINT32("vgamem_mb", VirtIOVGA, dummy, 16),
 DEFINE_PROP_END_OF_LIST(),
 };
 
-- 
1.8.3.1




[Qemu-devel] [PATCH 7/9] virtio-vga: add vgabios binary

2015-03-13 Thread Gerd Hoffmann
Add prebuilt vgabios-virtio.bin binary.

Signed-off-by: Gerd Hoffmann 
---
 pc-bios/vgabios-virtio.bin | Bin 0 -> 37376 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 pc-bios/vgabios-virtio.bin

diff --git a/pc-bios/vgabios-virtio.bin b/pc-bios/vgabios-virtio.bin
new file mode 100644
index 
..7febcb660b23ba1fb6d0d52d9f08458b86cd8c15
GIT binary patch
literal 37376
zcmeHwe|%I$mhbH(B%RRYb|7GbE%Z2m$Otxy7_=pU5D=MQYYaL%Xdt8-H400*NgP86
zCed_47M@Ql%i>P*C+fP;t8>0
zUxLE2Toiaj;|jCzpY}AYu!!bPt4Q4^W(BqerV9T!i%IxwXOTa(y8?mYwjWXA!0rk1*x+dc>s_7LTaeXw|$kw(bK=z8OD0wEARA$JUQ8{CsPNM-1g#
zJtC0+8}smkcHs}iW8Cdivg1cVV&!DBs5#RI@bUr4GD%5I_iSPmxS?r7V)JK1LqnSI
zpAfT#g#PnOR?*yL75?)g^@`Yh2vr)WE<7qWf1v%PPR}cTBmAvma~HRs!i{GgN6UR^
zNz6MTMyXbL9b)rg)yj8D91CqZx-}qnX|E8@CSTz4zmM%75I+--i7A2|r;~X4{u3j@7O{5(s1m>AU;pn!^SMM(a~4y0
zR2&Op;t~L88BMd$4IY9q-_>iz`1?l}_xeD8@_m=1l%Ba^`A
z#=N)P!Mg|1CRyY{Vtw00%@wonlP$+lm%mLkf0~Fsj*I5c&{F)xCAM?@yiFXGN42WOSyb;J^yO`UeH~oYQ4`Q_vEbuH&!V@^w
zSon@G9d!r)azNyU4^xY$CZgsvEzF-|ISbPV5)Co;ZGL1VdFT)`bMK0G%El4pZ$qW%
z@3zt^2ErC`2^eZNzO8vD3jbx{|CnIFklR4_P(JXOFc8y)@W&7ZcZ?{=+4nb#y1)xJ
zh&}ruHDXtSu4(7C9~QfkFsSgiu=FrGh?}TsOOPxG@^2$hIgiu?DTx{U+~?>oZ_juy9~VAg>E^Okq11
zNOO}3nEPp+9+cg&PKja=QVTv*-y&*0&t|PPN$ko&ODI(TX|T?Ww#OjsQ~l$L@N#Oy
zI6vJQ=hSJ{pP9Um)(o0AJY0P_r98j-%A|6L9D0(PGuI^MHWSyq<46$2`?SEQf9R~H
z$A-dCye&|O@1mD0P^aMpF(0MFqWN;7Sc1vP$EvzCNLCG|Rfx;12%9puyCs{)u&(
zJ2(mWTDFbGG9;V-A}mRNH$dCArO+!X@r;nYI4PPxhi+~9{&*9*&LM;-C4sP=0UF1k
z_+<_{-U`*xC6Or4ONuIdiL~8@)G+Js*>(
zZ4Y#N>hp%`+j_P)ch@&>{}^vP4S7R7^=-o69V0i)<5n{Fk%slnSa?149f0i_#!Q0d
ze&So8t4q`deThpSif?s*rP~8N=<-osiSL1y%bxn&
zvAFl+J|6cgxZ5CyD+c0Oay5BvG2{_l4T+M-9xmjX)I9-%y$*Q~dm7whJ@tj(;65Jr
zLELS)50RzQcic}D?^6_i;|}^j@wJG02xA0fe`K;C5;462qc2GP{Jr#Z>o;{vVPkHCX(}ACmz?0=h`GR;hUq{(W_g9-0TSgmXjXLlNS(IcQOoe0|kqNe;twkm`n8+t|G?uf
z1iXJm@NJV``)tC+{U+adxVw30G-yD*_Q3=(>!4KAp|K`+@aO$3I%LSCp5NL^5<_c_
zpP;r_KdVv#uK`s^+%Bli57ac<4)0m6kNM?jy|Tu$_tXi#cLf22H)cAByxK2A$y@8^M_-(a}&P
z#__)23uV}9ItMoo{RU=hpGZ9__Uywjde9I|YRJ7&>E{fI_M$@g2-pDS%DgGNqB!!o
zYP1v!OzAOF3$qSxKOCXsZbgSABGuQ0VflJ#%4u2BO!jaA^N&f9k8oy)&8kGc~IK`$rhwKGg&^I39Uyj4Vw*lj1C>|H`jfLsY_0t{z@K!~wG()5B|
z>?Y$O_SWLpfWXAPv4@-XvRmQ{Vj>sajA=v-9P~2KYxsd~I{>K}7l-+*e;t^g6=OlyL90@HkYuldEAIp}jVMx_v1~2q0~A
zG=@{;Cy}i-nZ)E4tG%d8ZH|f-%HSHiQ(@UVnAAiB!`?`KL9;Q
zz3e;zH~6UG`yQ3P@8e8+)ZLBvbMD~ouZ`}#PFAxwgK2OOr4(}ynCGP5qbr%BV5ecv
z5f0m~<44zYn`4Jn=nme5VKr~F2>&5cs4zNY1?%&Aw~eA#s)Q&KgBVSq?1c0pqBrxn
z&moycRQy$hitsZG>?6-Qj#y^L0g6`1`uJ8_+UWB)IpOD
zA7uT$!GLd+VJi>}u7YAio>Z&uPbt5}cuyh@)$-lZZlI`dYYv&~+c9(GtOm%?$BUf`
zUl3A0z>&*D1S#a2awPfgN4N)QrgI4^Dh>-1B246DO-Ca#jQCT3rCw!TrI%PB-p|2+
zVGr~jaAy6K=|mFub6S7BB9)RmKKL2_@6T~V;WtcNrDc8ObGd^8!rtNzRspX&{Rm5QhPIPF64oGk%dZ(AC4z}sFi3y>%Mz~=4jwiX2
z^}3&o078s3>iC8>kQppUf{T?-DMx)LLT7zvE*ObqA7>2VL^R}DkV3BQ)(F)KlMAj$
z16iYj(Nf}(3T{n8TDmUa``Yj-r}bdkDBl6rLfyj$(gY=2Wje20yw4FWl;N$%2%uYh
zNKOtGDd!!{3&)HW3!t>kzLV^MCHelrNQA_thR%id!BLiu?7x0V@-&M^u;Y%0h8+N-SD3qSfBcm@a0N$lEzD5qQ0{L
zAxYzlaM}DD&wzguJpPT{p62Je6Y+W@JTE^Svby8mZ%6Y!`c6*#Yz$ubg?NCV5Mh`$
z2E!ey*B^!^NcK}Y4(x}gAxCx+vxHf(3pY|}Wtgqp3C%&8t$=XDpa2!(6tG)E;J+}4
zz}BKLHiy~>w7e{J&Ae-{%a=c6-pDFJKR`to^h0xF(u8x%FoSP9V$KBY~LOhlB(aS2C0q5Ea;&
z|NTm)3MMpvL90?Ms_9n_GDf>yGQS>r4AW0CXCdEzNUAIE0#}mv2QG5s%SL-`ynmyTbC-Yunh9=Kcns17yID;&8}7^R
zww&Z-?8)%ca?#OB>7_BjkL?EX(b%~|bDD)-&AX7&VzjU!rE&t0lRqE+l-treZWShS
zEqL{c<@_`OEK#fV$7d8PqB=QZ?%88%A@6WE*rXw4*_t#GTK1stYtVEj+wN(|IQwZq
z!w)#e&*q5DlCCG^#U?}ekdF7~W3zyqn!Ho);NJ|vRwa7;E4~0tJFt%jHxDDcXqeck
zZ`2Ws(FA5vf42<@bkagQ3a#+*`E(K=l6oWBN0)6yqRosnAdaRAH_24N)-mfpV2Zg
zD2S{OL#%Sh`>D@A3gqU9{7Tw(^v}Jd*F0uIYJheWu$kZ+S9|b<(N4~Byip0Ov=2t6
zIy?$iN2NLF6$|}gFne|eh(CnzkBnj7F5cH_%KHuF%|!EAESZg;MY_b20XMKR{2SY8
zP=!b3@_u`j5#rLhk%|M`7#HWM>}j-sZiBZ8l%K-t@W#
zhU~%w=Di17YEMSOiS*7<&HDg^q0>ad08-BXfhrmnj_QJ#91^>#(GxjT`i?7P3hVm3
zSSp2xUq9RAxufuqr~Z*qT^xIxeFwu+0d_LlhTuEANdzAYcbfVmZA$&U^aruXGn98G
z^ym=gCFiPnDZuvbILccb_aQp9e-F{=tzyspg&H<>8)>N>#Kw(}_8b-@gy$eqO&6Q{
z32gl*;UjoF^#pQUH^Qy~9Q&R7ZbOrk*wplWjwbUHV7p-FWA%&LP@;5}m@;I-=vRcw
z;$m-7f~0#+2>%gxux*GUnKhVb=Dix$E6^mgvDXKo{0tL&CYHxrzplmhaAW?_7p7wN
z=41BCv8CUI82j^09_RP(>WXF1%CEyCsnS!AiZGcw(uW+%M}${ySvVwB?%-Wa63#cU
zf<{n!`7-G>Nlh1IFo+J$@QkAp@p%n4Z5kHd^o8U`&3*^>aJA00(&9iS`waHeNwY%p
zVwZt6Yyq@w?$}6jts%V@@{8>?Y?JNioqKparCa6?Md};VdCTX#s(A>ZKW#!mH(n68
zLT;OWKt2zv(ZciMR(Lc`Zj-1R(zo`*Y#rCPUVugM7Y5zI`)Ow#PQOfSMb^*j2=<_%
zfh3o8Kloi3gc!hY13bI=+0>N9(g+4KzNk{n)lR1dSn
z={wdTLeh6skTKnnlYxv3G`&>!JD;$Lx|3cTct>uzA5+ql2f{z2t(v7_TIT;{?C)di
zb~tv3Qw(-&HT@s47l3x;(7fZzQ;>1+-W8r)-Jj+iU)?{-H^I{iMfPo;0IwZEZ+&8T
ztY;8=;W`*?h6GVA2^+7E8JU5puh(kz&1%h=vYN}Dp;o!rBU*d~f=)W5t%moY%R=>z0-b|q#04Ju}=Ysi~)Ck9phK8=sInW>AU^B=CY85p-PI#Ktms87caXF#!
zkV_biEz&e_YcF^wnjT3z8pe9eJLe=y7l*O12O%)7Qr|eSm@wgqqO7U}6c#1?v&psE
z`}n4tTr>6B9?ey(*Zxj(P0{OSn3$ezQ+h(PO|CM%)@0f=&9zRi%cMnKmLzMPJ@Q_G
z%|J^0f%e2uwdV49XSyo9xuLW4=FZxKzGUnrB!!U;Z!yE8dtsz(Hlqi}gCNIrdZ95f
z9?TtlVKB6tG4cwog^zsxckrEHgaVq$U~Y!cI^EJAVoo};E^Uz~_hQbRqi;dozIZcSr>^zdl_
zKA?bn5AF9>YnpEX8c`HHX0XjSnYfrnyRBLd?9t6}MX}3)04$6=umOYS@Rl$9BVoW<
zwAz3#*WjvES&!Y!!9A75#FjnqIrm$_6UC

[Qemu-devel] [PATCH 4/9] virtio-vga: add virtio gpu device with vga compatibility

2015-03-13 Thread Gerd Hoffmann
This patch adds a virtio-vga device.  It is simliar to virtio-gpu-pci,
but it also adds in vga compatibility, so guests without native
virtio-gpu support can drive the device in vga mode.

Written by Dave Airlie and Gerd Hoffmann.

Signed-off-by: Dave Airlie 
Signed-off-by: Gerd Hoffmann 
---
 default-configs/x86_64-softmmu.mak |   1 +
 hw/display/Makefile.objs   |   1 +
 hw/display/virtio-vga.c| 150 +
 3 files changed, 152 insertions(+)
 create mode 100644 hw/display/virtio-vga.c

diff --git a/default-configs/x86_64-softmmu.mak 
b/default-configs/x86_64-softmmu.mak
index 46b87dd..9a313d9 100644
--- a/default-configs/x86_64-softmmu.mak
+++ b/default-configs/x86_64-softmmu.mak
@@ -7,6 +7,7 @@ CONFIG_QXL=$(CONFIG_SPICE)
 CONFIG_VGA_ISA=y
 CONFIG_VGA_CIRRUS=y
 CONFIG_VMWARE_VGA=y
+CONFIG_VIRTIO_VGA=y
 CONFIG_VMMOUSE=y
 CONFIG_SERIAL=y
 CONFIG_PARALLEL=y
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index ab6b791..3da3f6c 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -36,3 +36,4 @@ common-obj-$(CONFIG_QXL) += qxl.o qxl-logger.o qxl-render.o
 
 obj-$(CONFIG_VIRTIO) += virtio-gpu.o
 obj-$(CONFIG_VIRTIO_PCI) += virtio-gpu-pci.o
+obj-$(CONFIG_VIRTIO_VGA) += virtio-vga.o
diff --git a/hw/display/virtio-vga.c b/hw/display/virtio-vga.c
new file mode 100644
index 000..bbde750
--- /dev/null
+++ b/hw/display/virtio-vga.c
@@ -0,0 +1,150 @@
+#include "hw/hw.h"
+#include "hw/pci/pci.h"
+#include "ui/console.h"
+#include "vga_int.h"
+#include "hw/virtio/virtio-pci.h"
+
+/*
+ * virtio-vga: This extends VirtioPCIProxy.
+ */
+#define TYPE_VIRTIO_VGA "virtio-vga"
+#define VIRTIO_VGA(obj) \
+OBJECT_CHECK(VirtIOVGA, (obj), TYPE_VIRTIO_VGA)
+
+typedef struct VirtIOVGA {
+VirtIOPCIProxy parent_obj;
+VirtIOGPU  vdev;
+VGACommonState vga;
+} VirtIOVGA;
+
+static void virtio_vga_invalidate_display(void *opaque)
+{
+VirtIOVGA *vvga = opaque;
+
+if (vvga->vdev.enable) {
+virtio_gpu_ops.invalidate(&vvga->vdev);
+} else {
+vvga->vga.hw_ops->invalidate(&vvga->vga);
+}
+}
+
+static void virtio_vga_update_display(void *opaque)
+{
+VirtIOVGA *vvga = opaque;
+
+if (vvga->vdev.enable) {
+virtio_gpu_ops.gfx_update(&vvga->vdev);
+} else {
+vvga->vga.hw_ops->gfx_update(&vvga->vga);
+}
+}
+
+static void virtio_vga_text_update(void *opaque, console_ch_t *chardata)
+{
+VirtIOVGA *vvga = opaque;
+
+if (vvga->vdev.enable) {
+if (virtio_gpu_ops.text_update) {
+virtio_gpu_ops.text_update(&vvga->vdev, chardata);
+}
+} else {
+if (vvga->vga.hw_ops->text_update) {
+vvga->vga.hw_ops->text_update(&vvga->vga, chardata);
+}
+}
+}
+
+static int virtio_vga_ui_info(void *opaque, uint32_t idx, QemuUIInfo *info)
+{
+VirtIOVGA *vvga = opaque;
+
+if (virtio_gpu_ops.ui_info) {
+return virtio_gpu_ops.ui_info(&vvga->vdev, idx, info);
+}
+return -1;
+}
+
+static const GraphicHwOps virtio_vga_ops = {
+.invalidate = virtio_vga_invalidate_display,
+.gfx_update = virtio_vga_update_display,
+.text_update = virtio_vga_text_update,
+.ui_info = virtio_vga_ui_info,
+};
+
+/* VGA device wrapper around PCI device around virtio GPU */
+static void virtio_vga_realize(VirtIOPCIProxy *vpci_dev, Error **errp)
+{
+VirtIOVGA *vvga = VIRTIO_VGA(vpci_dev);
+VirtIOGPU *g = &vvga->vdev;
+VGACommonState *vga = &vvga->vga;
+
+/* init vga compat bits */
+vga->vram_size_mb = 8;
+vga_common_init(vga, OBJECT(vpci_dev), false);
+vga_init(vga, OBJECT(vpci_dev), pci_address_space(&vpci_dev->pci_dev),
+ pci_address_space_io(&vpci_dev->pci_dev), true);
+pci_register_bar(&vpci_dev->pci_dev, 2,
+ PCI_BASE_ADDRESS_MEM_PREFETCH, &vga->vram);
+
+/* init virtio bits */
+qdev_set_parent_bus(DEVICE(g), BUS(&vpci_dev->bus));
+/* force virtio-1.0 */
+vpci_dev->flags &= ~VIRTIO_PCI_FLAG_DISABLE_MODERN;
+vpci_dev->flags |= VIRTIO_PCI_FLAG_DISABLE_LEGACY;
+object_property_set_bool(OBJECT(g), true, "realized", errp);
+
+vga->con = g->scanout[0].con;
+graphic_console_set_hwops(vga->con, &virtio_vga_ops, vvga);
+}
+
+static void virtio_vga_reset(DeviceState *dev)
+{
+VirtIOVGA *vvga = VIRTIO_VGA(dev);
+vvga->vdev.enable = 0;
+
+vga_dirty_log_start(&vvga->vga);
+}
+
+static Property virtio_vga_properties[] = {
+DEFINE_VIRTIO_GPU_PROPERTIES(VirtIOVGA, vdev.conf),
+DEFINE_VIRTIO_GPU_PCI_PROPERTIES(VirtIOPCIProxy),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void virtio_vga_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
+PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
+
+set_bit(DEVICE_CATEGORY_DISPLAY, dc->categories);
+dc->props = virtio_vga_properties;
+dc->reset = virtio_vga_reset;
+dc->hotp

[Qemu-devel] [PATCH 2/9] virtio-gpu/2d: add virtio gpu core code

2015-03-13 Thread Gerd Hoffmann
This patch adds the core code for virtio gpu emulation,
covering 2d support.

Written by Dave Airlie and Gerd Hoffmann.

Signed-off-by: Dave Airlie 
Signed-off-by: Gerd Hoffmann 
---
 hw/display/Makefile.objs   |   2 +
 hw/display/virtio-gpu.c| 923 +
 include/hw/virtio/virtio-gpu.h | 147 +++
 trace-events   |  14 +
 4 files changed, 1086 insertions(+)
 create mode 100644 hw/display/virtio-gpu.c
 create mode 100644 include/hw/virtio/virtio-gpu.h

diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 7ed76a9..6990634 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -33,3 +33,5 @@ obj-$(CONFIG_CG3) += cg3.o
 obj-$(CONFIG_VGA) += vga.o
 
 common-obj-$(CONFIG_QXL) += qxl.o qxl-logger.o qxl-render.o
+
+obj-$(CONFIG_VIRTIO) += virtio-gpu.o
diff --git a/hw/display/virtio-gpu.c b/hw/display/virtio-gpu.c
new file mode 100644
index 000..ab71291
--- /dev/null
+++ b/hw/display/virtio-gpu.c
@@ -0,0 +1,923 @@
+/*
+ * Virtio GPU Device
+ *
+ * Copyright Red Hat, Inc. 2013-2014
+ *
+ * Authors:
+ * Dave Airlie 
+ * Gerd Hoffmann 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.
+ * See the COPYING file in the top-level directory.
+ */
+
+#include "qemu-common.h"
+#include "qemu/iov.h"
+#include "ui/console.h"
+#include "trace.h"
+#include "hw/virtio/virtio.h"
+#include "hw/virtio/virtio-gpu.h"
+#include "hw/virtio/virtio-bus.h"
+
+static struct virtio_gpu_simple_resource*
+virtio_gpu_find_resource(VirtIOGPU *g, uint32_t resource_id);
+
+static void update_cursor_data_simple(VirtIOGPU *g,
+  struct virtio_gpu_scanout *s,
+  uint32_t resource_id)
+{
+struct virtio_gpu_simple_resource *res;
+uint32_t pixels;
+
+res = virtio_gpu_find_resource(g, resource_id);
+if (!res) {
+return;
+}
+
+if (pixman_image_get_width(res->image)  != s->current_cursor->width ||
+pixman_image_get_height(res->image) != s->current_cursor->height) {
+return;
+}
+
+pixels = s->current_cursor->width * s->current_cursor->height;
+memcpy(s->current_cursor->data,
+   pixman_image_get_data(res->image),
+   pixels * sizeof(uint32_t));
+}
+
+static void update_cursor(VirtIOGPU *g, struct virtio_gpu_update_cursor 
*cursor)
+{
+struct virtio_gpu_scanout *s;
+
+if (cursor->pos.scanout_id >= g->conf.max_outputs) {
+return;
+}
+s = &g->scanout[cursor->pos.scanout_id];
+
+if (cursor->hdr.type != VIRTIO_GPU_CMD_MOVE_CURSOR) {
+if (!s->current_cursor) {
+s->current_cursor = cursor_alloc(64, 64);
+}
+
+s->current_cursor->hot_x = cursor->hot_x;
+s->current_cursor->hot_y = cursor->hot_y;
+
+if (cursor->resource_id > 0) {
+update_cursor_data_simple(g, s, cursor->resource_id);
+}
+dpy_cursor_define(s->con, s->current_cursor);
+}
+dpy_mouse_set(s->con, cursor->pos.x, cursor->pos.y,
+  cursor->resource_id ? 1 : 0);
+}
+
+static void virtio_gpu_get_config(VirtIODevice *vdev, uint8_t *config)
+{
+VirtIOGPU *g = VIRTIO_GPU(vdev);
+memcpy(config, &g->virtio_config, sizeof(g->virtio_config));
+}
+
+static void virtio_gpu_set_config(VirtIODevice *vdev, const uint8_t *config)
+{
+VirtIOGPU *g = VIRTIO_GPU(vdev);
+struct virtio_gpu_config vgconfig;
+
+memcpy(&vgconfig, config, sizeof(g->virtio_config));
+
+if (vgconfig.events_clear) {
+g->virtio_config.events_read &= ~vgconfig.events_clear;
+}
+}
+
+static uint64_t virtio_gpu_get_features(VirtIODevice *vdev, uint64_t features)
+{
+return features;
+}
+
+static void virtio_gpu_set_features(VirtIODevice *vdev, uint64_t features)
+{
+}
+
+static void virtio_gpu_notify_event(VirtIOGPU *g, uint32_t event_type)
+{
+g->virtio_config.events_read |= event_type;
+virtio_notify_config(&g->parent_obj);
+}
+
+static struct virtio_gpu_simple_resource *
+virtio_gpu_find_resource(VirtIOGPU *g, uint32_t resource_id)
+{
+struct virtio_gpu_simple_resource *res;
+
+QTAILQ_FOREACH(res, &g->reslist, next) {
+if (res->resource_id == resource_id) {
+return res;
+}
+}
+return NULL;
+}
+
+void virtio_gpu_ctrl_response(VirtIOGPU *g,
+  struct virtio_gpu_ctrl_command *cmd,
+  struct virtio_gpu_ctrl_hdr *resp,
+  size_t resp_len)
+{
+size_t s;
+
+if (cmd->cmd_hdr.flags & VIRTIO_GPU_FLAG_FENCE) {
+resp->flags |= VIRTIO_GPU_FLAG_FENCE;
+resp->fence_id = cmd->cmd_hdr.fence_id;
+resp->ctx_id = cmd->cmd_hdr.ctx_id;
+}
+s = iov_from_buf(cmd->elem.in_sg, cmd->elem.in_num, 0, resp, resp_len);
+if (s != resp_len) {
+qemu_log_mask(LOG_GUEST_ERROR,
+  "%s: response size incorrect %zu vs %zu\n",
+ 

[Qemu-devel] [PATCH] opengl: require glx

2015-03-13 Thread Gerd Hoffmann
hw/display/milkymist-tmu2.c uses glx.  That will be replaced with egl in
the future, with qemu getting more opengl support.  But we are not there
yet, so put it back into configure to fix build failures on machines
without glx (i.e. macos, possibly windows too).

Signed-off-by: Gerd Hoffmann 
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index bd55786..ed49990 100755
--- a/configure
+++ b/configure
@@ -3120,7 +3120,7 @@ libs_softmmu="$libs_softmmu $fdt_libs"
 ##
 # opengl probe (for sdl2, milkymist-tmu2)
 if test "$opengl" != "no" ; then
-  opengl_pkgs="egl gl glesv2"
+  opengl_pkgs="glx egl gl glesv2"
   if $pkg_config $opengl_pkgs x11; then
 opengl_cflags="$($pkg_config --cflags $opengl_pkgs) $x11_cflags"
 opengl_libs="$($pkg_config --libs $opengl_pkgs) $x11_libs"
-- 
1.8.3.1




Re: [Qemu-devel] [PATCH] ui/cocoa.m: Give laptop users ability to scroll in monitor

2015-03-13 Thread Peter Maydell
On 13 March 2015 at 04:35, Programmingkid  wrote:
> Laptop users usually have keyboards that are missing the page up and page 
> down keys. This means they cannot scroll in the monitor. This patch gives 
> laptop users the ability to scroll in the monitor by having the user push the 
> Control + Up/Down arrow keys to scroll one line at a time. Use ALT/Option in 
> place of Control to be able to scroll at 10 lines at a time.

Don't the standard OSX function+up/down for pageup/down work?
If they don't we should probably figure out why rather than
adding a non-standard key combo.

-- PMM



[Qemu-devel] [PATCH 3/9] virtio-gpu-pci: add virtio pci support

2015-03-13 Thread Gerd Hoffmann
This patch adds virtio-gpu-pci, which is the pci proxy for the virtio
gpu device.  With this patch in place virtio-gpu is functional.  You
need a linux guest with a virtio-gpu driver though, and output will
appear pretty late in boot, once the kernel initialized drm and fbcon.

Written by Dave Airlie and Gerd Hoffmann.

Signed-off-by: Dave Airlie 
Signed-off-by: Gerd Hoffmann 
---
 hw/display/Makefile.objs|  1 +
 hw/display/virtio-gpu-pci.c | 68 +
 hw/virtio/virtio-pci.h  | 15 ++
 3 files changed, 84 insertions(+)
 create mode 100644 hw/display/virtio-gpu-pci.c

diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 6990634..ab6b791 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -35,3 +35,4 @@ obj-$(CONFIG_VGA) += vga.o
 common-obj-$(CONFIG_QXL) += qxl.o qxl-logger.o qxl-render.o
 
 obj-$(CONFIG_VIRTIO) += virtio-gpu.o
+obj-$(CONFIG_VIRTIO_PCI) += virtio-gpu-pci.o
diff --git a/hw/display/virtio-gpu-pci.c b/hw/display/virtio-gpu-pci.c
new file mode 100644
index 000..f0f25c7
--- /dev/null
+++ b/hw/display/virtio-gpu-pci.c
@@ -0,0 +1,68 @@
+/*
+ * Virtio video device
+ *
+ * Copyright Red Hat
+ *
+ * Authors:
+ *  Dave Airlie
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2.  See
+ * the COPYING file in the top-level directory.
+ *
+ */
+#include "hw/pci/pci.h"
+#include "hw/virtio/virtio.h"
+#include "hw/virtio/virtio-bus.h"
+#include "hw/virtio/virtio-pci.h"
+#include "hw/virtio/virtio-gpu.h"
+
+static Property virtio_gpu_pci_properties[] = {
+DEFINE_VIRTIO_GPU_PROPERTIES(VirtIOGPUPCI, vdev.conf),
+DEFINE_VIRTIO_GPU_PCI_PROPERTIES(VirtIOPCIProxy),
+DEFINE_PROP_END_OF_LIST(),
+};
+
+static void virtio_gpu_pci_realize(VirtIOPCIProxy *vpci_dev, Error **errp)
+{
+VirtIOGPUPCI *vgpu = VIRTIO_GPU_PCI(vpci_dev);
+DeviceState *vdev = DEVICE(&vgpu->vdev);
+
+qdev_set_parent_bus(vdev, BUS(&vpci_dev->bus));
+/* force virtio-1.0 */
+vpci_dev->flags &= ~VIRTIO_PCI_FLAG_DISABLE_MODERN;
+vpci_dev->flags |= VIRTIO_PCI_FLAG_DISABLE_LEGACY;
+object_property_set_bool(OBJECT(vdev), true, "realized", errp);
+}
+
+static void virtio_gpu_pci_class_init(ObjectClass *klass, void *data)
+{
+DeviceClass *dc = DEVICE_CLASS(klass);
+VirtioPCIClass *k = VIRTIO_PCI_CLASS(klass);
+PCIDeviceClass *pcidev_k = PCI_DEVICE_CLASS(klass);
+
+set_bit(DEVICE_CATEGORY_DISPLAY, dc->categories);
+dc->props = virtio_gpu_pci_properties;
+k->realize = virtio_gpu_pci_realize;
+pcidev_k->class_id = PCI_CLASS_DISPLAY_OTHER;
+}
+
+static void virtio_gpu_initfn(Object *obj)
+{
+VirtIOGPUPCI *dev = VIRTIO_GPU_PCI(obj);
+object_initialize(&dev->vdev, sizeof(dev->vdev), TYPE_VIRTIO_GPU);
+object_property_add_child(obj, "virtio-backend", OBJECT(&dev->vdev), NULL);
+}
+
+static const TypeInfo virtio_gpu_pci_info = {
+.name = TYPE_VIRTIO_GPU_PCI,
+.parent = TYPE_VIRTIO_PCI,
+.instance_size = sizeof(VirtIOGPUPCI),
+.instance_init = virtio_gpu_initfn,
+.class_init = virtio_gpu_pci_class_init,
+};
+
+static void virtio_gpu_pci_register_types(void)
+{
+type_register_static(&virtio_gpu_pci_info);
+}
+type_init(virtio_gpu_pci_register_types)
diff --git a/hw/virtio/virtio-pci.h b/hw/virtio/virtio-pci.h
index b382688..efe8d31 100644
--- a/hw/virtio/virtio-pci.h
+++ b/hw/virtio/virtio-pci.h
@@ -24,6 +24,7 @@
 #include "hw/virtio/virtio-balloon.h"
 #include "hw/virtio/virtio-bus.h"
 #include "hw/virtio/virtio-9p.h"
+#include "hw/virtio/virtio-gpu.h"
 #ifdef CONFIG_VIRTFS
 #include "hw/9pfs/virtio-9p.h"
 #endif
@@ -39,6 +40,7 @@ typedef struct VirtIOSerialPCI VirtIOSerialPCI;
 typedef struct VirtIONetPCI VirtIONetPCI;
 typedef struct VHostSCSIPCI VHostSCSIPCI;
 typedef struct VirtIORngPCI VirtIORngPCI;
+typedef struct VirtIOGPUPCI VirtIOGPUPCI;
 
 /* virtio-pci-bus */
 
@@ -225,6 +227,19 @@ struct VirtIORngPCI {
 VirtIORNG vdev;
 };
 
+/*
+ * virtio-gpu-pci: This extends VirtioPCIProxy.
+ */
+#define TYPE_VIRTIO_GPU_PCI "virtio-gpu-pci"
+#define VIRTIO_GPU_PCI(obj) \
+OBJECT_CHECK(VirtIOGPUPCI, (obj), TYPE_VIRTIO_GPU_PCI)
+
+struct VirtIOGPUPCI {
+VirtIOPCIProxy parent_obj;
+VirtIOGPU vdev;
+};
+
+
 /* Virtio ABI version, if we increment this, we break the guest driver. */
 #define VIRTIO_PCI_ABI_VERSION  0
 
-- 
1.8.3.1




Re: [Qemu-devel] [PATCH 0/6] [PREVIEW] s390x/kvm: fixes and features

2015-03-13 Thread Cornelia Huck
On Thu, 12 Mar 2015 13:53:48 +0100
Jens Freimann  wrote:

> Conny, Alex, Christian,
> 
> a few more s390 patches:
> 
> Patch 1: encapsulates the HAS_DEVICE check into a generic function
> Patch 2: use the function introduced in Patch 1
> Patch 3: introduces two new machine options for indicating the state of
>  AES/DEA key wrapping functions
> Patch 4 and 5: remove dead code
> Patch 6: fill in length for sei_nt2 event
> 
> regards
> Jens
> 
> Dominik Dingel (3):
>   kvm: encapsulate HAS_DEVICE for vm attrs
>   s390x/kvm: make use of generic vm attribute check
>   s390x/ipl: remove dead code
> 
> Frank Blaschka (1):
>   s390x/pci: fix length in sei_nt2 event
> 
> Thomas Huth (1):
>   s390x/virtio-bus: Remove unused function s390_virtio_bus_console()
> 
> Tony Krowiak (1):
>   s390x: CPACF: Handle key wrap machine options
> 
>  hw/s390x/ipl.c |  3 --
>  hw/s390x/s390-pci-bus.c|  1 +
>  hw/s390x/s390-virtio-bus.c |  5 ---
>  hw/s390x/s390-virtio-bus.h |  1 -
>  hw/s390x/s390-virtio-ccw.c | 63 +++
>  include/sysemu/kvm.h   | 12 ++
>  kvm-all.c  | 21 +++
>  qemu-options.hx| 12 +-
>  target-s390x/kvm.c | 93 
> +-
>  9 files changed, 166 insertions(+), 45 deletions(-)
> 

FWIW, there were some trivial conflicts with the machine state stuff,
which I fixed up.

Applied to my s390-next branch.




Re: [Qemu-devel] [v2][PATCH 2/2] libxl: introduce gfx_passthru_kind

2015-03-13 Thread Ian Campbell
On Fri, 2015-03-13 at 09:39 +0800, Chen, Tiejun wrote:
> > I don't think you can abort here, since a user can set
> > b_info->u.hvm.gfx_passthru_kind to default. You would need to return an
> > error.
> 
> Then, looks I should do this,
> 
>  LOG(ERROR, "No supported IGD to passthru,"
>  " or please force set gfx_passthru=\"igd\".\n");
>  return NULL;

If I remember the context correctly this is in the autodetect case, so I
think shouldn't mention IGD. Something like "Unable to detect graphics
passthru kind, please set gfx_passthru_kind. See xl.cfg(5) for more
information."

> >
> >> @@ -720,6 +720,13 @@ void libxl_mac_copy(libxl_ctx *ctx, libxl_mac *dst,
> >> libxl_mac *src);
> >>#define LIBXL_HAVE_PSR_MBM 1
> >>#endif
> >>
> >> +/*
> >> + * LIBXL_HAVE_GFX_PASSTHRU_KIND
> >> + *
> >> + * If this is defined, the Graphic Device Passthrough Override is
> >> supported.
> >
> > Almost, please also explicitly name the type field as other similar
> > comments do for clarity.
> 
> Okay, maybe something is like this,
> 
> +/*
> + * LIBXL_HAVE_IGD_GFX_PASSTHRU
> + *
> + * If this is defined, the IGD Graphic Device Passthrough is supported.
> + *
> + * LIBXL_HAVE_IGD_GFX_PASSTHRU indicates that the
> + * libxl_device_pci field in the hvm is present in the pci_info structure
> + * fixup_ids[] which contains all supported IGD devices. So wwe use
> + * "igd-passthru=on" specify on the qemu command-line.

This:

/*
 * libxl_domain_build_info has the u.hvm.gfx_passthru_kind field and
 * the libxl_gfx_passthru_kind enumeration is defined. 
 */
#define LIBXL_HAVE_GFX_PASSTHRU_KIND

Users don't care about the internal details, just about the existence of
the support.

Ian.




Re: [Qemu-devel] [PATCH] s390x/config: Do not include full pci.mak

2015-03-13 Thread Cornelia Huck
On Thu, 12 Mar 2015 15:19:14 +0100
Thomas Huth  wrote:

> pci.mak includes a lot of devices - and most of them do not make
> sense on s390x, like USB controllers or audio cards. These devices
> also show up when running "qemu-system-s390x -device help" and thus
> could raise the hope for the users that they could use these kind
> of devices with qemu-system-s390x. To avoid this confusion, we
> should not include pci.mak and rather include the bare minimum
> manually instead.
> 
> Signed-off-by: Thomas Huth 
> Acked-by: Frank Blaschka 
> ---
>  default-configs/s390x-softmmu.mak |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 

Applied to my s390-next branch.




Re: [Qemu-devel] [PULL v4 00/11] Net patches

2015-03-13 Thread Peter Maydell
On 13 March 2015 at 02:32, Fam Zheng  wrote:
> On Thu, 03/12 17:50, Stefan Hajnoczi wrote:
>> Hi Fam,
>> This pull request contains patches that fail mingw compilation and
>> glib version requirements.  They passed in patchew:
>> http://qemu.patchew.org/testing/log/%3c1426170808-6343-1-git-send-email-stefa...@redhat.com%3E
>>
>> Peter's build script is here:
>> https://git.linaro.org/people/peter.maydell/misc-scripts.git/blob/HEAD:/remake-merge-builds
>
> A good starter to extend the coverage of patchew :)

Just noticed that there's nothing in remake-merge-builds
for the centos5 tree. The hard part with that (and for that
matter with the win32 stuff) though is setting up the
chroot or cross-tools and libraries, not the QEMU build
tree config...

-- PMM



Re: [Qemu-devel] [PATCH v5 20/45] Modify savevm handlers for postcopy

2015-03-13 Thread Dr. David Alan Gilbert
* David Gibson (da...@gibson.dropbear.id.au) wrote:
> On Wed, Feb 25, 2015 at 04:51:43PM +, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" 
> > 
> > Modify save_live_pending to return separate postcopiable and
> > non-postcopiable counts.
> > 
> > Add 'can_postcopy' to allow a device to state if it can postcopy
> 
> What's the purpose of the can_postcopy callback?  There are no callers
> in this patch - is it still necessary with the change to
> save_live_pending?

The patch 'qemu_savevm_state_complete: Postcopy changes' uses
it in qemu_savevm_state_postcopy_complete and qemu_savevm_state_complete
to decide which devices must be completed at that point.

Dave

> 
> > 
> > Signed-off-by: Dr. David Alan Gilbert 
> > ---
> >  arch_init.c | 15 +--
> >  include/migration/vmstate.h | 10 --
> >  include/sysemu/sysemu.h |  4 +++-
> >  migration/block.c   |  7 +--
> >  migration/migration.c   |  9 +++--
> >  savevm.c| 21 +
> >  trace-events|  2 +-
> >  7 files changed, 54 insertions(+), 14 deletions(-)
> > 
> > diff --git a/arch_init.c b/arch_init.c
> > index fe0df0d..7bc5fa6 100644
> > --- a/arch_init.c
> > +++ b/arch_init.c
> > @@ -997,7 +997,9 @@ static int ram_save_complete(QEMUFile *f, void *opaque)
> >  return 0;
> >  }
> >  
> > -static uint64_t ram_save_pending(QEMUFile *f, void *opaque, uint64_t 
> > max_size)
> > +static void ram_save_pending(QEMUFile *f, void *opaque, uint64_t max_size,
> > + uint64_t *non_postcopiable_pending,
> > + uint64_t *postcopiable_pending)
> >  {
> >  uint64_t remaining_size;
> >  
> > @@ -1009,7 +1011,9 @@ static uint64_t ram_save_pending(QEMUFile *f, void 
> > *opaque, uint64_t max_size)
> >  qemu_mutex_unlock_iothread();
> >  remaining_size = ram_save_remaining() * TARGET_PAGE_SIZE;
> >  }
> > -return remaining_size;
> > +
> > +*non_postcopiable_pending = 0;
> > +*postcopiable_pending = remaining_size;
> >  }
> >  
> >  static int load_xbzrle(QEMUFile *f, ram_addr_t addr, void *host)
> > @@ -1204,6 +1208,12 @@ static int ram_load(QEMUFile *f, void *opaque, int 
> > version_id)
> >  return ret;
> >  }
> >  
> > +/* RAM's always up for postcopying */
> > +static bool ram_can_postcopy(void *opaque)
> > +{
> > +return true;
> > +}
> > +
> >  static SaveVMHandlers savevm_ram_handlers = {
> >  .save_live_setup = ram_save_setup,
> >  .save_live_iterate = ram_save_iterate,
> > @@ -1211,6 +1221,7 @@ static SaveVMHandlers savevm_ram_handlers = {
> >  .save_live_pending = ram_save_pending,
> >  .load_state = ram_load,
> >  .cancel = ram_migration_cancel,
> > +.can_postcopy = ram_can_postcopy,
> >  };
> >  
> >  void ram_mig_init(void)
> > diff --git a/include/migration/vmstate.h b/include/migration/vmstate.h
> > index 18da207..c9ec74a 100644
> > --- a/include/migration/vmstate.h
> > +++ b/include/migration/vmstate.h
> > @@ -54,8 +54,14 @@ typedef struct SaveVMHandlers {
> >  
> >  /* This runs outside the iothread lock!  */
> >  int (*save_live_setup)(QEMUFile *f, void *opaque);
> > -uint64_t (*save_live_pending)(QEMUFile *f, void *opaque, uint64_t 
> > max_size);
> > -
> > +/*
> > + * postcopiable_pending must return 0 unless the can_postcopy
> > + * handler returns true.
> > + */
> > +void (*save_live_pending)(QEMUFile *f, void *opaque, uint64_t max_size,
> > +  uint64_t *non_postcopiable_pending,
> > +  uint64_t *postcopiable_pending);
> > +bool (*can_postcopy)(void *opaque);
> >  LoadStateHandler *load_state;
> >  } SaveVMHandlers;
> >  
> > diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> > index e83bf80..5f518b3 100644
> > --- a/include/sysemu/sysemu.h
> > +++ b/include/sysemu/sysemu.h
> > @@ -111,7 +111,9 @@ void qemu_savevm_state_header(QEMUFile *f);
> >  int qemu_savevm_state_iterate(QEMUFile *f);
> >  void qemu_savevm_state_complete(QEMUFile *f);
> >  void qemu_savevm_state_cancel(void);
> > -uint64_t qemu_savevm_state_pending(QEMUFile *f, uint64_t max_size);
> > +void qemu_savevm_state_pending(QEMUFile *f, uint64_t max_size,
> > +   uint64_t *res_non_postcopiable,
> > +   uint64_t *res_postcopiable);
> >  void qemu_savevm_command_send(QEMUFile *f, enum qemu_vm_cmd command,
> >uint16_t len, uint8_t *data);
> >  void qemu_savevm_send_ping(QEMUFile *f, uint32_t value);
> > diff --git a/migration/block.c b/migration/block.c
> > index 0c76106..0f6f209 100644
> > --- a/migration/block.c
> > +++ b/migration/block.c
> > @@ -754,7 +754,9 @@ static int block_save_complete(QEMUFile *f, void 
> > *opaque)
> >  return 0;
> >  }
> >  
> > -static uint64_t block_save_pending(QEMUFile *f, void *opaque, uint64_t 
> > max_size

Re: [Qemu-devel] [PATCH] opengl: require glx

2015-03-13 Thread Gerd Hoffmann
On Fr, 2015-03-13 at 10:47 +0100, Gerd Hoffmann wrote:
> hw/display/milkymist-tmu2.c uses glx.  That will be replaced with egl in
> the future, with qemu getting more opengl support.  But we are not there
> yet, so put it back into configure to fix build failures on machines
> without glx (i.e. macos, possibly windows too).

Oops, scratch that one, old leftover *.patch file.

sorry,
  Gerd





Re: [Qemu-devel] [PATCH v2 3/6] hw/char: pl011 don't keep setting the IRQ if nothing changed

2015-03-13 Thread Alex Bennée

Peter Maydell  writes:

> On 12 March 2015 at 15:51, Peter Maydell  wrote:
>> On 4 March 2015 at 14:35, Alex Bennée  wrote:
>>> While observing KVM traces I can see additional IRQ calls on pretty much
>>> every MMIO access which is just plain inefficient. Only update the QEMU
>>> IRQ level if something has actually changed from last time. Otherwise we
>>> may be papering over other failure modes.
>
>> Consider this sequence of events:
>
> Incidentally, the code review rule of thumb that led me to
> construct that scenario is:
>  * state inside the device struct which doesn't correspond
>to real hardware state is suspicious
>  * state which doesn't have any handling on migration
>save/restore is doubly suspicious
> ...and then it was just a matter of "find the situation
> where this is broken" :-)
>
> If we want to avoid making syscalls back into KVM it might
> be better to attack the problem in the GIC object rather
> than in all the devices that might be connected to it.
> In general QEMU devices tend to assume they can just
> always call qemu_set_irq() and it's the other end's
> job to avoid doing anything too expensive in that situation.

Fair enough - I'll drop this patch on the re-spin

>
> -- PMM

-- 
Alex Bennée



Re: [Qemu-devel] [PATCH v2 1/6] target-arm: kvm: save/restore mp state

2015-03-13 Thread Alex Bennée

Peter Maydell  writes:

> On 4 March 2015 at 14:35, Alex Bennée  wrote:
>> This adds the saving and restore of the current Multi-Processing state
>> of the machine. While the KVM_GET/SET_MP_STATE API exposes a number of
>> potential states for x86 we only use two for ARM. Either the process is
>> running or not. We then save this state into the cpu_powered TCG state
>> to avoid changing the serialisation format.
>>
>> Signed-off-by: Alex Bennée 
>>
>> ---
>> v2
>>   - make mpstate field runtime dependant (kvm_enabled())
>>   - drop initial KVM_CAP_MP_STATE requirement
>>   - re-use cpu_powered instead of new field
>>
>> diff --git a/target-arm/machine.c b/target-arm/machine.c
>> index 9446e5a..185f9a2 100644
>> --- a/target-arm/machine.c
>> +++ b/target-arm/machine.c
>> @@ -161,6 +161,7 @@ static const VMStateInfo vmstate_cpsr = {
>>  .put = put_cpsr,
>>  };
>>
>> +
>>  static void cpu_pre_save(void *opaque)
>>  {
>>  ARMCPU *cpu = opaque;
>> @@ -170,6 +171,20 @@ static void cpu_pre_save(void *opaque)
>>  /* This should never fail */
>>  abort();
>>  }
>> +#if defined CONFIG_KVM
>> +if (kvm_check_extension(CPU(cpu)->kvm_state, KVM_CAP_MP_STATE)) {
>> +struct kvm_mp_state mp_state;
>> +int ret = kvm_vcpu_ioctl(CPU(cpu), KVM_GET_MP_STATE, &mp_state);
>> +if (ret) {
>> +fprintf(stderr, "%s: failed to get MP_STATE %d/%s\n",
>> +__func__, ret, strerror(ret));
>> +abort();
>> +}
>> +cpu->powered_off =
>> +(mp_state.mp_state == KVM_MP_STATE_RUNNABLE)
>> +? false : true;
>
> Ternary operator to produce a true-or-false result is a bit
> redundant...
>
>> +}
>> +#endif
>
> Why is this in pre-save/post-load rather than in the
> kvm_arch_get/put_registers functions like all the other
> syncing code?

Yeah the #ifdefs should have waved the red flag - I'll move it ;-)

>
> -- PMM

-- 
Alex Bennée



Re: [Qemu-devel] [PATCH v5 22/45] postcopy: OS support test

2015-03-13 Thread Dr. David Alan Gilbert
* David Gibson (da...@gibson.dropbear.id.au) wrote:
> On Wed, Feb 25, 2015 at 04:51:45PM +, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" 
> > 
> > Provide a check to see if the OS we're running on has all the bits
> > needed for postcopy.
> > 
> > Creates postcopy-ram.c which will get most of the other helpers we need.
> > 
> > Signed-off-by: Dr. David Alan Gilbert 
> > ---
> >  include/migration/postcopy-ram.h |  19 +
> >  migration/Makefile.objs  |   2 +-
> >  migration/postcopy-ram.c | 161 
> > +++
> >  savevm.c |   5 ++
> >  4 files changed, 186 insertions(+), 1 deletion(-)
> >  create mode 100644 include/migration/postcopy-ram.h
> >  create mode 100644 migration/postcopy-ram.c
> > 
> > diff --git a/include/migration/postcopy-ram.h 
> > b/include/migration/postcopy-ram.h
> > new file mode 100644
> > index 000..d81934f
> > --- /dev/null
> > +++ b/include/migration/postcopy-ram.h
> > @@ -0,0 +1,19 @@
> > +/*
> > + * Postcopy migration for RAM
> > + *
> > + * Copyright 2013 Red Hat, Inc. and/or its affiliates
> > + *
> > + * Authors:
> > + *  Dave Gilbert  
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2 or 
> > later.
> > + * See the COPYING file in the top-level directory.
> > + *
> > + */
> > +#ifndef QEMU_POSTCOPY_RAM_H
> > +#define QEMU_POSTCOPY_RAM_H
> > +
> > +/* Return true if the host supports everything we need to do postcopy-ram 
> > */
> > +bool postcopy_ram_supported_by_host(void);
> > +
> > +#endif
> > diff --git a/migration/Makefile.objs b/migration/Makefile.objs
> > index d929e96..0cac6d7 100644
> > --- a/migration/Makefile.objs
> > +++ b/migration/Makefile.objs
> > @@ -1,7 +1,7 @@
> >  common-obj-y += migration.o tcp.o
> >  common-obj-y += vmstate.o
> >  common-obj-y += qemu-file.o qemu-file-buf.o qemu-file-unix.o 
> > qemu-file-stdio.o
> > -common-obj-y += xbzrle.o
> > +common-obj-y += xbzrle.o postcopy-ram.o
> >  
> >  common-obj-$(CONFIG_RDMA) += rdma.o
> >  common-obj-$(CONFIG_POSIX) += exec.o unix.o fd.o
> > diff --git a/migration/postcopy-ram.c b/migration/postcopy-ram.c
> > new file mode 100644
> > index 000..a0e20b2
> > --- /dev/null
> > +++ b/migration/postcopy-ram.c
> > @@ -0,0 +1,161 @@
> > +/*
> > + * Postcopy migration for RAM
> > + *
> > + * Copyright 2013-2014 Red Hat, Inc. and/or its affiliates
> > + *
> > + * Authors:
> > + *  Dave Gilbert  
> > + *
> > + * This work is licensed under the terms of the GNU GPL, version 2 or 
> > later.
> > + * See the COPYING file in the top-level directory.
> > + *
> > + */
> > +
> > +/*
> > + * Postcopy is a migration technique where the execution flips from the
> > + * source to the destination before all the data has been copied.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "qemu-common.h"
> > +#include "migration/migration.h"
> > +#include "migration/postcopy-ram.h"
> > +#include "sysemu/sysemu.h"
> > +#include "qemu/error-report.h"
> > +#include "trace.h"
> > +
> > +/* Postcopy needs to detect accesses to pages that haven't yet been copied
> > + * across, and efficiently map new pages in, the techniques for doing this
> > + * are target OS specific.
> > + */
> > +#if defined(__linux__)
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include  /* for __u64 */
> > +#include 
> > +
> > +#ifdef HOST_X86_64
> > +#ifndef __NR_userfaultfd
> > +#define __NR_userfaultfd 323
> 
> Sholdn't this come from the kernel headers imported in the previous
> patch?  Rather than having an arch-specific hack.

The header, like the rest of the kernel headers, just provides
the constant and structure definitions for the call; the syscall numbers
come from arch specific headers.  I guess in the final world I wouldn't
need this at all since it'll come from the system headers; but what's
the right way to put this in for new syscalls?

> > +#endif
> > +#endif
> > +
> > +#endif
> > +
> > +#if defined(__linux__) && defined(__NR_userfaultfd)
> > +
> > +static bool ufd_version_check(int ufd)
> > +{
> > +struct uffdio_api api_struct;
> > +uint64_t feature_mask;
> > +
> > +api_struct.api = UFFD_API;
> > +if (ioctl(ufd, UFFDIO_API, &api_struct)) {
> > +perror("postcopy_ram_supported_by_host: UFFDIO_API failed");
> 
> This should be error_report() not, perror(), to match qemu
> conventions, shouldn't it?

Thanks; I've done all of the perrors.

> > +return false;
> > +}
> > +
> > +feature_mask = (__u64)1 << _UFFDIO_REGISTER |
> > +   (__u64)1 << _UFFDIO_UNREGISTER;
> > +if ((api_struct.ioctls & feature_mask) != feature_mask) {
> > +error_report("Missing userfault features: %" PRIu64,
> > + (uint64_t)(~api_struct.ioctls & feature_mask));
> > +return false;
> > +}
> > +
> > +return true;
> > +}
> > +
> > +bool postcopy_ram_supported_by_host(void)
> > +{
> > +long pagesize = ge

Re: [Qemu-devel] [PATCH v2 4/4] dma-helpers: Move reschedule_dma BH to blk's AioContext

2015-03-13 Thread Paolo Bonzini


On 13/03/2015 09:58, Fam Zheng wrote:
>> > 
>> > This looks good.  However, I wonder if dma_aio_cancel should also call
>> > cpu_unregister_map_client.  In this case, it's much better to just use a
>> > lock for the list (though you can still use atomics for the in-use flag).
> The other possibility is grab a reference for the cpu_register_map_client 
> call,
> and release it in reschedule_dma. This way the atomics can keep, but we'll 
> need
> a "finished" flag in DMAAIOCB to avoid double completion.

Considering this is a slow path, a lock seems preferrable.

It's not that your patch were bad, it's that a pre-existing bug got in
your way, and broke the assumptions you made.

Paolo



Re: [Qemu-devel] [PATCH v4 4/4] migration: Expose 'cancelling' status to user

2015-03-13 Thread Paolo Bonzini


On 09/03/2015 07:45, zhanghailiang wrote:
> 'cancelling' status was introduced by commit 51cf4c1a, mainly to avoid a 
> possible start of a new migration process while the previous one still exists.
> But we didn't expose this status to user, instead we returned the 'active' 
> state.
> 
> Here, we expose it to the user (such as libvirt), 'cancelling' status only
> occurs for a short window before the migration aborts, so for users,
> if they cancel a migration process, it will observe 'cancelling' status
> occasionally.
> 
> Testing revealed that with older libvirt (anything 1.2.13 or less) will
> print an odd error message if the state is seen, but that the migration
> is still properly cancelled. Newer libvirt will be patched to recognize
> the new state without the odd error message.
> 
> Signed-off-by: zhanghailiang 
> Reviewed-by: Eric Blake 
> Cc: libvir-l...@redhat.com

Why is this necessary?

Paolo

> ---
>  migration/migration.c | 6 +-
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/migration/migration.c b/migration/migration.c
> index 035e005..a57928d 100644
> --- a/migration/migration.c
> +++ b/migration/migration.c
> @@ -179,13 +179,11 @@ MigrationInfo *qmp_query_migrate(Error **errp)
>  break;
>  case MIGRATION_STATUS_SETUP:
>  info->has_status = true;
> -info->status = MIGRATION_STATUS_SETUP;
>  info->has_total_time = false;
>  break;
>  case MIGRATION_STATUS_ACTIVE:
>  case MIGRATION_STATUS_CANCELLING:
>  info->has_status = true;
> -info->status = MIGRATION_STATUS_ACTIVE;
>  info->has_total_time = true;
>  info->total_time = qemu_clock_get_ms(QEMU_CLOCK_REALTIME)
>  - s->total_time;
> @@ -221,7 +219,6 @@ MigrationInfo *qmp_query_migrate(Error **errp)
>  get_xbzrle_cache_stats(info);
>  
>  info->has_status = true;
> -info->status = MIGRATION_STATUS_COMPLETED;
>  info->has_total_time = true;
>  info->total_time = s->total_time;
>  info->has_downtime = true;
> @@ -243,13 +240,12 @@ MigrationInfo *qmp_query_migrate(Error **errp)
>  break;
>  case MIGRATION_STATUS_FAILED:
>  info->has_status = true;
> -info->status = MIGRATION_STATUS_FAILED;
>  break;
>  case MIGRATION_STATUS_CANCELLED:
>  info->has_status = true;
> -info->status = MIGRATION_STATUS_CANCELLED;
>  break;
>  }
> +info->status = s->state;
>  
>  return info;
>  }
> 



Re: [Qemu-devel] [PATCH v4 0/7] QEMU memory hot unplug support

2015-03-13 Thread Igor Mammedov
On Fri, 13 Mar 2015 14:05:08 +0800
Zhu Guihua  wrote:

> ping...

I can't find v4 series in my mailbox nor on list archives,
perhaps it got lost somewhere, could you resend rebased
version on top of current master, pls?

> 
> On 03/04/2015 02:01 PM, Zhu Guihua wrote:
> > Memory hot unplug are both asynchronous procedures.
> > When the unplug operation happens, unplug request cb is called first.
> > And when guest OS finished handling unplug, unplug cb will be called
> > to do the real removal of device.
> >
> > This series is rebased on mst pci branch.
> > http://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git
> >
> > v4:
> >   -reorganize the patchset
> >   -fix all about the new API acpi_send_gpe_event()
> >   -update ssdt-mem
> >
> > v3:
> >   -commit message changes
> >   -reorganize the patchset, squash and separate some patches
> >   -update specs about acpi_mem_hotplug
> >   -first cleanup external state, then un-map and un-register memory device
> >
> > v2:
> >   -do a generic for acpi to send gpe event
> >   -unparent object by PC_MACHINE
> >   -update description in acpi_mem_hotplug.txt
> >   -combine the last two patches in the last version
> >   -cleanup external state in acpi_memory_unplug_cb
> >
> > Tang Chen (6):
> >acpi, mem-hotplug: Add acpi_memory_slot_status() to get MemStatus
> >acpi: Add acpi_send_gpe_event() to rise sci for hotplug
> >acpi, mem-hotplug: Add unplug request cb for memory device
> >pc-dimm: Add memory hot unplug request support for pc-dimm
> >acpi, mem-hotplug: Add unplug cb for memory device
> >pc-dimm: Add memory hot unplug support for pc-dimm
> >
> > Zhu Guihua (1):
> >acpi: Add hardware implementation for memory hot unplug
> >
> >   docs/specs/acpi_mem_hotplug.txt   | 11 +-
> >   hw/acpi/core.c|  7 
> >   hw/acpi/cpu_hotplug.c |  3 +-
> >   hw/acpi/ich9.c| 19 +++--
> >   hw/acpi/memory_hotplug.c  | 81 
> > +--
> >   hw/acpi/pcihp.c   |  7 +---
> >   hw/acpi/piix4.c   | 16 ++--
> >   hw/core/qdev.c|  2 +-
> >   hw/i386/acpi-build.c  |  9 +
> >   hw/i386/acpi-dsdt-mem-hotplug.dsl | 10 +
> >   hw/i386/pc.c  | 54 --
> >   include/hw/acpi/acpi.h| 10 +
> >   include/hw/acpi/memory_hotplug.h  |  8 +++-
> >   include/hw/acpi/pc-hotplug.h  |  3 +-
> >   include/hw/qdev-core.h|  1 +
> >   trace-events  |  1 +
> >   16 files changed, 207 insertions(+), 35 deletions(-)
> >
> 
> 




Re: [Qemu-devel] [PATCH] block/throttle: Use host clock type

2015-03-13 Thread Paolo Bonzini


On 13/03/2015 09:27, Fam Zheng wrote:
> On Fri, 03/13 09:08, Paolo Bonzini wrote:
>>
>>
>> On 13/03/2015 07:35, Fam Zheng wrote:
>>> Throttle timers won't make any progress when VCPU is not running, which
>>> is prone to stall the request queue in cases like utils, qtest,
>>> suspending, and live migration, unless carefully handled. What we do now
>>> is crude. For example in bdrv_drain_all, requests are resumed
>>> immediately without consulting throttling timer. Unfortunately
>>> bdrv_drain_all is so widely used that there may be too many holes that
>>> guest could bypass throttling.
>>>
>>> If we use the host clock, we can just trust the nested poll when waiting
>>> for requests.
>>>
>>> Signed-off-by: Fam Zheng 
>>> ---
>>>  block.c   |  2 +-
>>>  tests/test-throttle.c | 14 +++---
>>
>> I think test-throttle.c should use the vm_clock.  At some point it was
>> managing the clock manually (by overriding cpu_get_clock from
>> libqemustub.a), and that's only possible with QEMU_CLOCK_VIRTUAL.
> 
> Ah! That is in iotests 093 (hint: authord by Fam Zheng :-/), which WILL be
> complicated if block.c switches away from QEMU_CLOCK_VIRTUAL. But I'll do the
> work if we decide to make this change.
> 
> As to tests/test-throttle.c, I don't see its dependency on clock type, so
> either way should work and I don't mind keeping it as-is at all.

If there's another way to do the same thing, I'd prefer it.

For example, can we call bdrv_drain_all() at the beginning of
do_vm_stop, before pausing the VCPUs?

>> As to block.c, I'll leave the review to the block folks.  But I think
>> QEMU_CLOCK_REALTIME is preferrable.
> 
> Real time clock should be fine, but we should review that the code handles
> clock reversing.

QEMU_CLOCK_HOST is the one that follows the wall clock;
QEMU_CLOCK_REALTIME is monotonic. :)

Paolo



Re: [Qemu-devel] [PATCH 2/2] memory: fix the eventfd data endianness according to the host

2015-03-13 Thread Paolo Bonzini


On 13/03/2015 09:11, Greg Kurz wrote:
> The data argument is a host entity. It is not related to the target
> endianness. Let's introduce a HOST_WORDS_BIGENDIAN based helper for
> that.
> 
> This patch fixes ioeventfd and vhost for a ppc64le host running a ppc64le
> guest (only virtqueue 0 was handled, all others being byteswapped because
> of TARGET_WORDS_BIGENDIAN). It doesn't change functionnality for fixed
> endian architectures (i.e. doesn't break x86).
> 
> Reported-by: Cédric Le Goater 
> Signed-off-by: Greg Kurz 
> ---
>  memory.c |   13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/memory.c b/memory.c
> index 6291cc0..1e29d40 100644
> --- a/memory.c
> +++ b/memory.c
> @@ -1549,6 +1549,15 @@ void memory_region_clear_flush_coalesced(MemoryRegion 
> *mr)
>  }
>  }
>  
> +static bool eventfd_wrong_endianness(MemoryRegion *mr)
> +{
> +#ifdef HOST_WORDS_BIGENDIAN
> +return mr->ops->endianness == DEVICE_LITTLE_ENDIAN;
> +#else
> +return mr->ops->endianness == DEVICE_BIG_ENDIAN;
> +#endif
> +}
> +
>  void memory_region_add_eventfd(MemoryRegion *mr,
> hwaddr addr,
> unsigned size,
> @@ -1565,7 +1574,7 @@ void memory_region_add_eventfd(MemoryRegion *mr,
>  };
>  unsigned i;
>  
> -adjust_endianness(&mrfd.data, size, memory_region_wrong_endianness(mr));
> +adjust_endianness(&mrfd.data, size, eventfd_wrong_endianness(mr));

Strictly speaking, the place to do this would be kvm_set_ioeventfd_mmio.
 A hypothetical userspace ioeventfd emulation would not need the swap.

I can accept the patch, but it's better to add a comment.

Paolo

>  memory_region_transaction_begin();
>  for (i = 0; i < mr->ioeventfd_nb; ++i) {
>  if (memory_region_ioeventfd_before(mrfd, mr->ioeventfds[i])) {
> @@ -1598,7 +1607,7 @@ void memory_region_del_eventfd(MemoryRegion *mr,
>  };
>  unsigned i;
>  
> -adjust_endianness(&mrfd.data, size, memory_region_wrong_endianness(mr));
> +adjust_endianness(&mrfd.data, size, eventfd_wrong_endianness(mr));
>  memory_region_transaction_begin();
>  for (i = 0; i < mr->ioeventfd_nb; ++i) {
>  if (memory_region_ioeventfd_equal(mrfd, mr->ioeventfds[i])) {
> 



[Qemu-devel] [PATCH] fsdev/virtfs-proxy-helper: Fix possible overflow

2015-03-13 Thread Shannon Zhao
It's detected by coverity. As max of sockaddr_un.sun_path is
sizeof(helper.sun_path), should check the length of source
and use strncpy instead of strcpy.

Signed-off-by: Shannon Zhao 
Signed-off-by: Shannon Zhao 
---
 fsdev/virtfs-proxy-helper.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fsdev/virtfs-proxy-helper.c b/fsdev/virtfs-proxy-helper.c
index bf2e5f3..f12d7a0 100644
--- a/fsdev/virtfs-proxy-helper.c
+++ b/fsdev/virtfs-proxy-helper.c
@@ -738,6 +738,7 @@ static int proxy_socket(const char *path, uid_t uid, gid_t 
gid)
 return -1;
 }
 
+g_assert(strlen(path) < sizeof(proxy.sun_path));
 sock = socket(AF_UNIX, SOCK_STREAM, 0);
 if (sock < 0) {
 do_perror("socket");
@@ -748,7 +749,7 @@ static int proxy_socket(const char *path, uid_t uid, gid_t 
gid)
 umask(7);
 
 proxy.sun_family = AF_UNIX;
-strcpy(proxy.sun_path, path);
+strncpy(proxy.sun_path, path, sizeof(proxy.sun_path));
 if (bind(sock, (struct sockaddr *)&proxy,
 sizeof(struct sockaddr_un)) < 0) {
 do_perror("bind");
-- 
1.8.3.1





Re: [Qemu-devel] [PULL 0/2] Block patches

2015-03-13 Thread Peter Maydell
On 12 March 2015 at 19:10, Stefan Hajnoczi  wrote:
> The following changes since commit 2a5b58e2405e9fe42ba356b5a1b78146a4e9a659:
>
>   Merge remote-tracking branch 'remotes/kraxel/tags/pull-vnc-20150312-1' into 
> staging (2015-03-12 10:35:54 +)
>
> are available in the git repository at:
>
>   git://github.com/stefanha/qemu.git tags/block-pull-request
>
> for you to fetch changes up to 87b86e7ef29771a7fa06e3e8e88fa95bbc13a39c:
>
>   qcow2: fix the macro QCOW_MAX_L1_SIZE's use (2015-03-12 17:41:23 +)
>
> 
>
> 

Applied, thanks.

-- PMM



[Qemu-devel] [PATCH] hw/9pfs/virtio-9p-proxy: Fix possible overflow

2015-03-13 Thread Shannon Zhao
It's detected by coverity. As max of sockaddr_un.sun_path is
sizeof(helper.sun_path), should check the length of source
and use strncpy instead of strcpy.

Signed-off-by: Shannon Zhao 
Signed-off-by: Shannon Zhao 
---
 hw/9pfs/virtio-9p-proxy.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/9pfs/virtio-9p-proxy.c b/hw/9pfs/virtio-9p-proxy.c
index 59c7445..fb1ab7b 100644
--- a/hw/9pfs/virtio-9p-proxy.c
+++ b/hw/9pfs/virtio-9p-proxy.c
@@ -1102,12 +1102,13 @@ static int connect_namedsocket(const char *path)
 int sockfd, size;
 struct sockaddr_un helper;
 
+g_assert(strlen(path) < sizeof(helper.sun_path));
 sockfd = socket(AF_UNIX, SOCK_STREAM, 0);
 if (sockfd < 0) {
 fprintf(stderr, "failed to create socket: %s\n", strerror(errno));
 return -1;
 }
-strcpy(helper.sun_path, path);
+strncpy(helper.sun_path, path, sizeof(helper.sun_path));
 helper.sun_family = AF_UNIX;
 size = strlen(helper.sun_path) + sizeof(helper.sun_family);
 if (connect(sockfd, (struct sockaddr *)&helper, size) < 0) {
-- 
1.8.3.1





Re: [Qemu-devel] [PATCH] virtio-scsi: Fix assert in virtio_scsi_push_event

2015-03-13 Thread Paolo Bonzini


On 13/03/2015 08:55, Fam Zheng wrote:
> Hotplugging a scsi-disk may trigger the assertion in qemu_sgl_concat.
> 
> qemu-system-x86_64: qemu/hw/scsi/virtio-scsi.c:115: qemu_sgl_concat:
> Assertion `skip == 0' failed.
> 
> This is introduced by commit 55783a55 (virtio-scsi: work around bug in
> old BIOSes) which didn't check out_num when accessing out_sg[0].iov_len
> (the same to in sg). For virtio_scsi_push_event, looking into out_sg
> doesn't make sense because 0 req_size is intended.
> 
> Cc: qemu-sta...@nongnu.org
> [Cc'ing qemu-stable because 55783a55 did it too]
> Signed-off-by: Fam Zheng 
> ---
>  hw/scsi/virtio-scsi.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/scsi/virtio-scsi.c b/hw/scsi/virtio-scsi.c
> index da0cff8..c9bea06 100644
> --- a/hw/scsi/virtio-scsi.c
> +++ b/hw/scsi/virtio-scsi.c
> @@ -146,8 +146,12 @@ static int virtio_scsi_parse_req(VirtIOSCSIReq *req,
>   * TODO: always disable this workaround for virtio 1.0 devices.
>   */
>  if (!virtio_has_feature(vdev, VIRTIO_F_ANY_LAYOUT)) {
> -req_size = req->elem.out_sg[0].iov_len;
> -resp_size = req->elem.in_sg[0].iov_len;
> +if (req->elem.out_num) {
> +req_size = req->elem.out_sg[0].iov_len;
> +}
> +if (req->elem.in_num) {
> +resp_size = req->elem.in_sg[0].iov_len;
> +}
>  }
>  
>  out_size = qemu_sgl_concat(req, req->elem.out_sg,
> 

Thanks, I'll send a pull request next week.

Paolo



[Qemu-devel] [PULL] Update OpenBIOS images

2015-03-13 Thread Mark Cave-Ayland
Hi Peter,

Here are the binaries for the outstanding OpenBIOS updates for 2.3. Please pull.


ATB,

Mark.


The following changes since commit f9f141b7475acfed1b6a28809687109702295be3:

  Merge remote-tracking branch 'remotes/stefanha/tags/block-pull-request' into 
staging (2015-03-13 09:54:23 +)

are available in the git repository at:


  https://github.com/mcayland/qemu.git tags/qemu-openbios-signed

for you to fetch changes up to 09c0772be9b44e9c6388caac0beb744bc59f6d71:

  Update OpenBIOS images (2015-03-13 11:03:41 +)


Update OpenBIOS images


Mark Cave-Ayland (1):
  Update OpenBIOS images

 pc-bios/openbios-ppc |  Bin 746588 -> 746588 bytes
 pc-bios/openbios-sparc32 |  Bin 381512 -> 381512 bytes
 pc-bios/openbios-sparc64 |  Bin 1616768 -> 1616768 bytes
 roms/openbios|2 +-
 4 files changed, 1 insertion(+), 1 deletion(-)



Re: [Qemu-devel] [PATCH v5 23/45] migrate_start_postcopy: Command to trigger transition to postcopy

2015-03-13 Thread Dr. David Alan Gilbert
* David Gibson (da...@gibson.dropbear.id.au) wrote:
> On Wed, Feb 25, 2015 at 04:51:46PM +, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" 
> > 
> > Once postcopy is enabled (with migrate_set_capability), the migration
> > will still start on precopy mode.  To cause a transition into postcopy
> > the:
> > 
> >   migrate_start_postcopy
> > 
> > command must be issued.  Postcopy will start sometime after this
> > (when it's next checked in the migration loop).
> > 
> > Issuing the command before migration has started will error,
> > and issuing after it has finished is ignored.
> > 
> > Signed-off-by: Dr. David Alan Gilbert 
> > Reviewed-by: Eric Blake 
> > ---
> >  hmp-commands.hx   | 15 +++
> >  hmp.c |  7 +++
> >  hmp.h |  1 +
> >  include/migration/migration.h |  3 +++
> >  migration/migration.c | 22 ++
> >  qapi-schema.json  |  8 
> >  qmp-commands.hx   | 19 +++
> >  7 files changed, 75 insertions(+)
> > 
> > diff --git a/hmp-commands.hx b/hmp-commands.hx
> > index e37bc8b..03b8b78 100644
> > --- a/hmp-commands.hx
> > +++ b/hmp-commands.hx
> > @@ -985,6 +985,21 @@ Enable/Disable the usage of a capability 
> > @var{capability} for migration.
> >  ETEXI
> >  
> >  {
> > +.name   = "migrate_start_postcopy",
> > +.args_type  = "",
> > +.params = "",
> > +.help   = "Switch migration to postcopy mode",
> > +.mhandler.cmd = hmp_migrate_start_postcopy,
> > +},
> > +
> > +STEXI
> > +@item migrate_start_postcopy
> > +@findex migrate_start_postcopy
> > +Switch in-progress migration to postcopy mode. Ignored after the end of
> > +migration (or once already in postcopy).
> > +ETEXI
> > +
> > +{
> >  .name   = "client_migrate_info",
> >  .args_type  = 
> > "protocol:s,hostname:s,port:i?,tls-port:i?,cert-subject:s?",
> >  .params = "protocol hostname port tls-port cert-subject",
> > diff --git a/hmp.c b/hmp.c
> > index b47f331..df9736c 100644
> > --- a/hmp.c
> > +++ b/hmp.c
> > @@ -1140,6 +1140,13 @@ void hmp_migrate_set_capability(Monitor *mon, const 
> > QDict *qdict)
> >  }
> >  }
> >  
> > +void hmp_migrate_start_postcopy(Monitor *mon, const QDict *qdict)
> > +{
> > +Error *err = NULL;
> > +qmp_migrate_start_postcopy(&err);
> > +hmp_handle_error(mon, &err);
> > +}
> > +
> >  void hmp_set_password(Monitor *mon, const QDict *qdict)
> >  {
> >  const char *protocol  = qdict_get_str(qdict, "protocol");
> > diff --git a/hmp.h b/hmp.h
> > index 4bb5dca..da1334f 100644
> > --- a/hmp.h
> > +++ b/hmp.h
> > @@ -64,6 +64,7 @@ void hmp_migrate_set_downtime(Monitor *mon, const QDict 
> > *qdict);
> >  void hmp_migrate_set_speed(Monitor *mon, const QDict *qdict);
> >  void hmp_migrate_set_capability(Monitor *mon, const QDict *qdict);
> >  void hmp_migrate_set_cache_size(Monitor *mon, const QDict *qdict);
> > +void hmp_migrate_start_postcopy(Monitor *mon, const QDict *qdict);
> >  void hmp_set_password(Monitor *mon, const QDict *qdict);
> >  void hmp_expire_password(Monitor *mon, const QDict *qdict);
> >  void hmp_eject(Monitor *mon, const QDict *qdict);
> > diff --git a/include/migration/migration.h b/include/migration/migration.h
> > index e6a814a..293c83e 100644
> > --- a/include/migration/migration.h
> > +++ b/include/migration/migration.h
> > @@ -104,6 +104,9 @@ struct MigrationState
> >  int64_t xbzrle_cache_size;
> >  int64_t setup_time;
> >  int64_t dirty_sync_count;
> > +
> > +/* Flag set once the migration has been asked to enter postcopy */
> > +bool start_postcopy;
> >  };
> >  
> >  void process_incoming_migration(QEMUFile *f);
> > diff --git a/migration/migration.c b/migration/migration.c
> > index a4fc7d7..43ca656 100644
> > --- a/migration/migration.c
> > +++ b/migration/migration.c
> > @@ -372,6 +372,28 @@ void 
> > qmp_migrate_set_capabilities(MigrationCapabilityStatusList *params,
> >  }
> >  }
> >  
> > +void qmp_migrate_start_postcopy(Error **errp)
> > +{
> > +MigrationState *s = migrate_get_current();
> > +
> > +if (!migrate_postcopy_ram()) {
> > +error_setg(errp, "Enable postcopy with migration_set_capability 
> > before"
> > + " the start of migration");
> > +return;
> > +}
> > +
> > +if (s->state == MIG_STATE_NONE) {
> > +error_setg(errp, "Postcopy must be started after migration has 
> > been"
> > + " started");
> > +return;
> > +}
> > +/*
> > + * we don't error if migration has finished since that would be racy
> > + * with issuing this command.
> > + */
> > +atomic_set(&s->start_postcopy, true);
> 
> Why atomic_set?

It's being read by the migration thread, this is happening in the main thread.

There's no strict ordering requirement or anything.

Dave

> 
> > +}
> > +

Re: [Qemu-devel] [PATCH 2/2] memory: fix the eventfd data endianness according to the host

2015-03-13 Thread Greg Kurz
On Fri, 13 Mar 2015 12:06:06 +0100
Paolo Bonzini  wrote:
> 
> 
> On 13/03/2015 09:11, Greg Kurz wrote:
> > The data argument is a host entity. It is not related to the target
> > endianness. Let's introduce a HOST_WORDS_BIGENDIAN based helper for
> > that.
> > 
> > This patch fixes ioeventfd and vhost for a ppc64le host running a ppc64le
> > guest (only virtqueue 0 was handled, all others being byteswapped because
> > of TARGET_WORDS_BIGENDIAN). It doesn't change functionnality for fixed
> > endian architectures (i.e. doesn't break x86).
> > 
> > Reported-by: Cédric Le Goater 
> > Signed-off-by: Greg Kurz 
> > ---
> >  memory.c |   13 +++--
> >  1 file changed, 11 insertions(+), 2 deletions(-)
> > 
> > diff --git a/memory.c b/memory.c
> > index 6291cc0..1e29d40 100644
> > --- a/memory.c
> > +++ b/memory.c
> > @@ -1549,6 +1549,15 @@ void 
> > memory_region_clear_flush_coalesced(MemoryRegion *mr)
> >  }
> >  }
> >  
> > +static bool eventfd_wrong_endianness(MemoryRegion *mr)
> > +{
> > +#ifdef HOST_WORDS_BIGENDIAN
> > +return mr->ops->endianness == DEVICE_LITTLE_ENDIAN;
> > +#else
> > +return mr->ops->endianness == DEVICE_BIG_ENDIAN;
> > +#endif
> > +}
> > +
> >  void memory_region_add_eventfd(MemoryRegion *mr,
> > hwaddr addr,
> > unsigned size,
> > @@ -1565,7 +1574,7 @@ void memory_region_add_eventfd(MemoryRegion *mr,
> >  };
> >  unsigned i;
> >  
> > -adjust_endianness(&mrfd.data, size, 
> > memory_region_wrong_endianness(mr));
> > +adjust_endianness(&mrfd.data, size, eventfd_wrong_endianness(mr));
> 
> Strictly speaking, the place to do this would be kvm_set_ioeventfd_mmio.

FWIW the swap is being done in memory.c since commit:

commit 28f362be6e7f45ea9b7a57a08555c4c784f36198
Author: Alexander Graf 
Date:   Mon Oct 15 20:30:28 2012 +0200

memory: Make eventfd adhere to device endianness

Are you asking to revert this commit and to pass the device endianness to
kvm_set_ioeventfd_mmio() so it can fix the ordering ?

>  A hypothetical userspace ioeventfd emulation would not need the swap.
> 

I don't understand why "would not need the swap"...


> I can accept the patch, but it's better to add a comment.
> 

... and so I don't know what to write. :)

Please enlight !

--
Greg

> Paolo
> 
> >  memory_region_transaction_begin();
> >  for (i = 0; i < mr->ioeventfd_nb; ++i) {
> >  if (memory_region_ioeventfd_before(mrfd, mr->ioeventfds[i])) {
> > @@ -1598,7 +1607,7 @@ void memory_region_del_eventfd(MemoryRegion *mr,
> >  };
> >  unsigned i;
> >  
> > -adjust_endianness(&mrfd.data, size, 
> > memory_region_wrong_endianness(mr));
> > +adjust_endianness(&mrfd.data, size, eventfd_wrong_endianness(mr));
> >  memory_region_transaction_begin();
> >  for (i = 0; i < mr->ioeventfd_nb; ++i) {
> >  if (memory_region_ioeventfd_equal(mrfd, mr->ioeventfds[i])) {
> > 
> 




Re: [Qemu-devel] [PATCH] block/throttle: Use host clock type

2015-03-13 Thread Fam Zheng
On Fri, 03/13 12:09, Paolo Bonzini wrote:
> 
> 
> On 13/03/2015 09:27, Fam Zheng wrote:
> > On Fri, 03/13 09:08, Paolo Bonzini wrote:
> >>
> >>
> >> On 13/03/2015 07:35, Fam Zheng wrote:
> >>> Throttle timers won't make any progress when VCPU is not running, which
> >>> is prone to stall the request queue in cases like utils, qtest,
> >>> suspending, and live migration, unless carefully handled. What we do now
> >>> is crude. For example in bdrv_drain_all, requests are resumed
> >>> immediately without consulting throttling timer. Unfortunately
> >>> bdrv_drain_all is so widely used that there may be too many holes that
> >>> guest could bypass throttling.
> >>>
> >>> If we use the host clock, we can just trust the nested poll when waiting
> >>> for requests.
> >>>
> >>> Signed-off-by: Fam Zheng 
> >>> ---
> >>>  block.c   |  2 +-
> >>>  tests/test-throttle.c | 14 +++---
> >>
> >> I think test-throttle.c should use the vm_clock.  At some point it was
> >> managing the clock manually (by overriding cpu_get_clock from
> >> libqemustub.a), and that's only possible with QEMU_CLOCK_VIRTUAL.
> > 
> > Ah! That is in iotests 093 (hint: authord by Fam Zheng :-/), which WILL be
> > complicated if block.c switches away from QEMU_CLOCK_VIRTUAL. But I'll do 
> > the
> > work if we decide to make this change.
> > 
> > As to tests/test-throttle.c, I don't see its dependency on clock type, so
> > either way should work and I don't mind keeping it as-is at all.
> 
> If there's another way to do the same thing, I'd prefer it.
> 
> For example, can we call bdrv_drain_all() at the beginning of
> do_vm_stop, before pausing the VCPUs?

Even with that, I still don't understand why block jobs should stop making
progress together with VCPUs.

IMO following host clock is the right things to do, because in the IO throttle
context, we are mostly refering to host resources (host_BW=host_IO/host_time).

> 
> >> As to block.c, I'll leave the review to the block folks.  But I think
> >> QEMU_CLOCK_REALTIME is preferrable.
> > 
> > Real time clock should be fine, but we should review that the code handles
> > clock reversing.
> 
> QEMU_CLOCK_HOST is the one that follows the wall clock;
> QEMU_CLOCK_REALTIME is monotonic. :)

I totally misread :)

Fam



[Qemu-devel] [PATCH qemu] pseries: Update SLOF firmware image to qemu-slof-20150313

2015-03-13 Thread Alexey Kardashevskiy
The changelog is:
  > virtio: Fix vring allocation
  > helpers: Fix SLOF_alloc_mem_aligned to meet callers expectation
  > Set default palette according to "16-color Text Extension" document
  > Fix rectangle drawing functions to work also with higher bit depths
  > Fix the x86emu patch file
  > Silence compiler warning when building the biosemu
  > Use device-type Forth word to set up the corresponding property
  > Improve /openprom node
  > pci-properties: Remove redundant call to device-type
  > cas: reconfigure memory nodes
  > pci: use 64bit bar ranges

Signed-off-by: Alexey Kardashevskiy 
---

I pushed it to github and I expect it to get mirrord to qemu.org tonight.

---
 pc-bios/README   |   2 +-
 pc-bios/slof.bin | Bin 911704 -> 912192 bytes
 roms/SLOF|   2 +-
 3 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/pc-bios/README b/pc-bios/README
index 8a85e69..63e7254 100644
--- a/pc-bios/README
+++ b/pc-bios/README
@@ -17,7 +17,7 @@
 - SLOF (Slimline Open Firmware) is a free IEEE 1275 Open Firmware
   implementation for certain IBM POWER hardware.  The sources are at
   https://github.com/aik/SLOF, and the image currently in qemu is
-  built from git tag qemu-slof-20141202.
+  built from git tag qemu-slof-20150313.
 
 - sgabios (the Serial Graphics Adapter option ROM) provides a means for
   legacy x86 software to communicate with an attached serial console as
diff --git a/pc-bios/slof.bin b/pc-bios/slof.bin
index 
031e3063a277e769c78b637de13c93f4074389f5..ab72cba80c528aea2545974e9c717cee583c254c
 100644
GIT binary patch
delta 10238
zcmeHMdw5e-wm|PwXrbXD
zlvfF_tRjU5M5qp80LR0q0~v>zTW5SkuQQkH_>FPo&fst_)^T(SGIG~C`xMg3z4Lwd
zyZ_wpyZM^@@>{>P*Is+=eRfXIKL7rN$ZsbE^5sj89R+t9`zG`mGGT`|E%k8wedg=>
zYuB>G*(ZK~Xp-V8xNDKUv@Ab=tjk`Kzo_g~!11zN@L-9LkG+%U*~gCOd3kr=IpOZS
z0*jeX`vITl_EmeTD*3&9v8N{YJFV-dEIDhg>X7J_RCO9UWHwt)IuDKnmM@!%)w%@s
z=}_hY=P;H5ZFc=)n|
z$yT6pdL%Y@5TX-V77Q81CbLhv8mB{G6gD19Npj#h%m{Ce!W8yvSqDe6UF<#d?GNG6
zY!GupbTrG88@|Bs8PGo$O$$KDV|J*>WiMe$WS*7H`WdA{$^V{4?ZeSFe-i6s>AX@X
zNf%dN?*LheN*o%N@UKs@
z26j-bd5WDfu@@m{9p=3a3fHj-Y%2KIu}7^+N5R^)k=4IARaYqeW*b~w$L6vtB;Bw2
z*R#hA>@)bNkv+jyLE$Dg6U()G6B{E(8Jye1e$B>1U^AP-zED5d%z)tpRcvMbu-=VZ
z**9#kx_%p`k-3dhtY6h{<>a*q#SQ1atSbmfiG|XeQz6{Mj^6tq$pwBzntA<=$@Kk>
zXVLwses!JoQpV&1^7s7pG^#(}F8m~^&Mol<*Y7al_Q9}wJNp~kt8NXjF|2ocGWj$-
zd#SF#FDWyxM@GO~JJ_VmpJ+|-W9Id5`)l79t?Mk5{^=lO?_@t@%Yt)poo@Jk?AM9o(Mm5-j>tQN*gDjops*OSPVNZj-nT_hJ1=oVEk-P)cYL%pWS|s@!#6s!ygQQV4>fQb78rFS^!#T5Gvytz|
zn$IdI-;49H5?4?s|y6YIGm_k<5Mq^#|Bu
z)(b8iVE3?JsJxX`CnT3>5q@rZ8Nv%#4*1KN0qpDXBXEux)%Omu*$ivT599iKTb+Lx
z7Zk3N!_P65)=tq;_H*_e@HX}o8v!kCxT1DI#cRnK>a6G4QJK9bNa`^*of);B!2Tj$
zO5PXQI^zlIS>vj5oLypUM$jZ@0}rz=anYuoU|U!%gidIiLdHq9j(RxB2KGKGmJHUb
zVg09dGq3M|6W%(BJIH5{dWwz0i>2Tco6zeKZCp2<`hx!yn`5cf%%6UPb7%L!N2gdn
z+uLNqWp)mMUd*2)NyTvD5xEZp)MQ2FFSBoxWlM+3&#>PmvNzRh=h&x-Y`hx#HQSOv
zm(aU-32lSMciA7TR&OVhl+MA|cg(#0+sDC~%(&VdWmTq3t)I^pN(#-_t|?OSl__+U
z{L5D=KhHi)v09@yTfXtOXqj_?{c|7oJY4%5)_)m{>%_G+02({lKE@#X3fqqG@)h*#|zG-=xY~ruS3U}!2MnbqYOVR
zlhftaD8$HDk9$xLaYz!rheF_}M41cFy$(AeB&-?)AWFRwvqTj?0W%RH5(xz)9cs%w1QjyD)HrkTr1YjR87
zi)t4m;bVsIDHPOGxwxwlHh1~>_Y0@aHdne=pzCsv%dG`&K&eN}N{^Qdk6e)or&keo
zmiVgOyr$gEwM0qlmSB%CzN#8twcPFFqxe{S=MvAwueliNf!d{BUQ@+ON{5#Ecu84}
zn-6geF?*?p+&oWZ4W}gPDyqE|o*E8IKQ?5hbtO#|3~3EiB^-ul
z(bCbSD={sPE7#|CRaKUG7T5Z)4po)8qImzfcHN5ij{{<_E?@ue6gIAUT81fkrM@aJ
z*FGV9*^qua&e3d|?Mf_4b**$1elOLWj`Mz0Gx!2{%t#sGbP<`{qY3oFM6mhT5UFNQF
zm6t54aP$0exr=bNT3U=l<@|B#oc+d4Pn2K-hrWPswk+aP%H6IfxTlP-aP#t#S
zrObULm5bfx_>RTU<1P8)v;wMU2c=G93$)b!7kXOisp{SpoamF7HoAzHRr&a$suEvm
z?lSk%TFQHcr=o(_;?+`3*Rn{NW)Co|mO){PX`-Ck42^_?IkcykF3U;9>giNdK9iFq=&+c8jaD12rg^EjHL0;IP2g%q
zf74la=IhvrjBhjbCP@Y-eOi?jVdz+6O3#cUyM|LO$hqi3ot
z-40%|UJ!v-cR~nhW+KKh;5&~3N^9QlPheFV%n&8HH!_kP_$HYXpqv$4kLo}q@r^Td
zbqL;~p*-xrkVk4Vy9UlJn3x~$<(x+AN7eNQfCz18V
zw@8~be4+db@TXCJ6&cBTYZ5j23^-9{=fH8*oMx~pYkGs9{B0=5_ZATTYce2A{;!J?
zuEAeaqIwC}bb_)0X`2|wx((nU+5}#LGXf$ILIxW*nEKPi_L0|hK$P@UZN}yGw%|rg
zfGSDrLQmMJ4|jbI*imN9y7OTuCVGZ?vdQb;pgs`4*7;S4Y$X0I1U8!b!Iv9xAr(RN
zL9{)+6?h|d)PkKnkMAA}>FML(B>5GT;tG+V&*;;q!H+U)hv+5*1BA&rOLx{MA)x>{
zPQr#E5F_Vo@UFm~H_QSB8)cUD@OJ9nmEfS5Ufp{=c*#51!@FGfJ^&%|4(Z-uEg^V!
zlPQCB1~+3vx>Ba$yT<@GmVuq*C3;-F&j=lGLPu4UBmP1
zuE!xlu3?cvV>T_0bXGvuzfEqO1$+zAV!FI+@+Jo@j&xRtw>?Bl!B5l-PBh;B#Pv!0**ps5!3qm`t
zrOHlfnzk>+r_`14t0JWdyYWIgwcC`I`Aa=_v0iQrZBHu1D5nD815#+`-*X=*dvL4|
zpnv>?d68o&_RInY$(wb#tFC@s#!Vh&T-zN%oP|BOD-k_H$=c+g0ir~?fN{YflKTaj
z4|ZZ@SQK=ugkofwO+9)Eh+cv_AwbT};Qv=s-vkBbLj*aT4dSX?PhF?8%~UO$3_F1X
zQv6jR7%c#=b=o4D@m7hf6_{^^B_vzxSMGC?^_bwi*z~7vrXO?5ee+O296@+ExnlOl9!_#e;J36W2{3@LNUp!by@Gq&?WmJ
zfHM0K_uA;ZaTMaLJt;3WDM<%P5Z{6r08waLeeAWXDA_#Clj!Ojcc<9`9=AesM4
z5pD8IW^f!t=Q;=x>;x~ujT;<&E{$~Gg0u5dv+!yIeuUaygeZB_y$uTDC4O}fM6OFlXH(9&*;}f%@STkqT_H2M5xg

Re: [Qemu-devel] [PULL v5 0/2] Net patches

2015-03-13 Thread Peter Maydell
On 12 March 2015 at 20:13, Stefan Hajnoczi  wrote:
> v5:
>  * Drop rocker due to w32 warning and glib minimum version issue [Peter]
>
> v4:
>  * Drop clang 3.5.0 fixes since they break with older clang and w32 [Peter]
>
> v3:
>  * Add clang 3.5.0 warning fixes
>  * Squash David Ahern's clang struct definition warnings fix
>
> v2:
>  * Squash in Jiri's fix for rocker format string specifiers [Peter]
>  * Squash in Windows build fix [Peter]
>  * Both build fixes are described in "rocker: add new rocker switch device"
>
> The following changes since commit 2a5b58e2405e9fe42ba356b5a1b78146a4e9a659:
>
>   Merge remote-tracking branch 'remotes/kraxel/tags/pull-vnc-20150312-1' into 
> staging (2015-03-12 10:35:54 +)
>
> are available in the git repository at:
>
>   git://github.com/stefanha/qemu.git tags/net-pull-request
>
> for you to fetch changes up to 069bb5831faf19d02041569580ad77565776bb1c:
>
>   tests: rtl8139: test timers and interrupt (2015-03-12 19:59:39 +)

Applied, thanks.

-- PMM



Re: [Qemu-devel] [PATCH v5 18/45] MIG_CMD_PACKAGED: Send a packaged chunk of migration stream

2015-03-13 Thread Dr. David Alan Gilbert
* David Gibson (da...@gibson.dropbear.id.au) wrote:
> On Wed, Feb 25, 2015 at 04:51:41PM +, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" 
> > 
> > MIG_CMD_PACKAGED is a migration command that allows a chunk
> > of migration stream to be sent in one go, and be received by
> > a separate instance of the loadvm loop while not interacting
> > with the migration stream.
> 
> Hrm.  I'd be more comfortable if the semantics of CMD_PACKAGED were
> defined in terms of visible effects on the other end, rather than in
> terms of how it's implemented internally.
> 
> > This is used by postcopy to load device state (from the package)
> > while loading memory pages from the main stream.
> 
> Which makes the above paragraph a bit misleading - the whole point
> here is that loading the package data *does* interact with the
> migration stream - just that it's the migration stream after the end
> of the package.

Hmm, how about:


MIG_CMD_PACKAGED is a migration command that wraps a chunk of migration
stream inside a package whose length can be determined purely by reading
its header.  The destination guarantees that the whole MIG_CMD_PACKAGED is
read off the stream prior to parsing the contents.

This is used by postcopy to load device state (from the package)
while leaving the main stream free to receive memory pages.


> > Signed-off-by: Dr. David Alan Gilbert 
> > ---
> >  include/sysemu/sysemu.h |  4 +++
> >  savevm.c| 82 
> > +
> >  trace-events|  4 +++
> >  3 files changed, 90 insertions(+)
> > 
> > diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
> > index d6a6d51..e83bf80 100644
> > --- a/include/sysemu/sysemu.h
> > +++ b/include/sysemu/sysemu.h
> > @@ -87,6 +87,7 @@ enum qemu_vm_cmd {
> >  MIG_CMD_INVALID = 0,   /* Must be 0 */
> >  MIG_CMD_OPEN_RETURN_PATH,  /* Tell the dest to open the Return path */
> >  MIG_CMD_PING,  /* Request a PONG on the RP */
> > +MIG_CMD_PACKAGED,  /* Send a wrapped stream within this stream 
> > */
> >  
> >  MIG_CMD_POSTCOPY_ADVISE = 20,  /* Prior to any page transfers, just
> >warn we might want to do PC */
> > @@ -101,6 +102,8 @@ enum qemu_vm_cmd {
> >  
> >  };
> >  
> > +#define MAX_VM_CMD_PACKAGED_SIZE (1ul << 24)
> > +
> >  bool qemu_savevm_state_blocked(Error **errp);
> >  void qemu_savevm_state_begin(QEMUFile *f,
> >   const MigrationParams *params);
> > @@ -113,6 +116,7 @@ void qemu_savevm_command_send(QEMUFile *f, enum 
> > qemu_vm_cmd command,
> >uint16_t len, uint8_t *data);
> >  void qemu_savevm_send_ping(QEMUFile *f, uint32_t value);
> >  void qemu_savevm_send_open_return_path(QEMUFile *f);
> > +void qemu_savevm_send_packaged(QEMUFile *f, const QEMUSizedBuffer *qsb);
> >  void qemu_savevm_send_postcopy_advise(QEMUFile *f);
> >  void qemu_savevm_send_postcopy_listen(QEMUFile *f);
> >  void qemu_savevm_send_postcopy_run(QEMUFile *f);
> > diff --git a/savevm.c b/savevm.c
> > index e31ccb0..f65bff3 100644
> > --- a/savevm.c
> > +++ b/savevm.c
> > @@ -636,6 +636,38 @@ void qemu_savevm_send_open_return_path(QEMUFile *f)
> >  qemu_savevm_command_send(f, MIG_CMD_OPEN_RETURN_PATH, 0, NULL);
> >  }
> >  
> > +/* We have a buffer of data to send; we don't want that all to be loaded
> > + * by the command itself, so the command contains just the length of the
> > + * extra buffer that we then send straight after it.
> > + * TODO: Must be a better way to organise that
> > + */
> > +void qemu_savevm_send_packaged(QEMUFile *f, const QEMUSizedBuffer *qsb)
> > +{
> > +size_t cur_iov;
> > +size_t len = qsb_get_length(qsb);
> > +uint32_t tmp;
> > +
> > +tmp = cpu_to_be32(len);
> > +
> > +trace_qemu_savevm_send_packaged();
> > +qemu_savevm_command_send(f, MIG_CMD_PACKAGED, 4, (uint8_t *)&tmp);
> > +
> > +/* all the data follows (concatinating the iov's) */
> > +for (cur_iov = 0; cur_iov < qsb->n_iov; cur_iov++) {
> > +/* The iov entries are partially filled */
> > +size_t towrite = (qsb->iov[cur_iov].iov_len > len) ?
> > +  len :
> > +  qsb->iov[cur_iov].iov_len;
> > +len -= towrite;
> > +
> > +if (!towrite) {
> > +break;
> > +}
> > +
> > +qemu_put_buffer(f, qsb->iov[cur_iov].iov_base, towrite);
> > +}
> > +}
> > +
> >  /* Send prior to any postcopy transfer */
> >  void qemu_savevm_send_postcopy_advise(QEMUFile *f)
> >  {
> > @@ -1265,6 +1297,48 @@ static int 
> > loadvm_process_command_simple_lencheck(const char *name,
> >  return 0;
> >  }
> >  
> > +/* Immediately following this command is a blob of data containing an 
> > embedded
> > + * chunk of migration stream; read it and load it.
> > + */
> > +static int loadvm_handle_cmd_packaged(MigrationIncomingState *mis,
> > +

[Qemu-devel] [RFC v0 PATCH] cpus: Convert cpu_index into a bitmap

2015-03-13 Thread Bharata B Rao
From: Bharata B Rao 

Currently CPUState.cpu_index is monotonically increasing and a newly
created CPU always gets the next higher index. The next available
index is calculated by counting the existing number of CPUs. This is
fine as long as we only add CPUs, but there are architectures which
are starting to support CPU removal too. For an architecture like PowerPC
which derives its CPU identifier (device tree ID) from cpu_index, the
existing logic of generating cpu_index values causes problems.

With the currently proposed method of handling vCPU removal by parking
the vCPU fd in QEMU
(Ref: http://lists.gnu.org/archive/html/qemu-devel/2015-02/msg02604.html),
generating cpu_index this way will not work for PowerPC.

This patch changes the way cpu_index is handed out by maintaining
a bit map of the CPUs that tracks both addition and removal of CPUs.

I am not sure if this is the right and an acceptable approach. The
alternative is to do something similar for PowerPC alone and not
depend on cpu_index.

I have tested this with out-of-the-tree patches for CPU hot plug and
removal on x86 and sPAPR PowerPC.

Signed-off-by: Bharata B Rao 
---
 exec.c  | 39 +--
 include/exec/exec-all.h |  1 +
 target-alpha/cpu.c  |  6 ++
 target-arm/cpu.c|  1 +
 target-cris/cpu.c   |  6 ++
 target-i386/cpu.c   |  6 ++
 target-lm32/cpu.c   |  6 ++
 target-m68k/cpu.c   |  6 ++
 target-microblaze/cpu.c |  6 ++
 target-mips/cpu.c   |  6 ++
 target-moxie/cpu.c  |  6 ++
 target-openrisc/cpu.c   |  6 ++
 target-ppc/translate_init.c |  6 ++
 target-s390x/cpu.c  |  1 +
 target-sh4/cpu.c|  6 ++
 target-sparc/cpu.c  |  1 +
 target-tricore/cpu.c|  5 +
 target-unicore32/cpu.c  |  6 ++
 target-xtensa/cpu.c |  6 ++
 19 files changed, 116 insertions(+), 10 deletions(-)

diff --git a/exec.c b/exec.c
index e97071a..7760f2d 100644
--- a/exec.c
+++ b/exec.c
@@ -530,21 +530,40 @@ void tcg_cpu_address_space_init(CPUState *cpu, 
AddressSpace *as)
 }
 #endif
 
+static DECLARE_BITMAP(cpu_index_map, MAX_CPUMASK_BITS);
+
+#ifdef CONFIG_USER_ONLY
+int max_cpus = 1; /* TODO: Check if this is correct ? */
+#endif
+
+static int cpu_get_free_index(void)
+{
+int cpu = find_first_zero_bit(cpu_index_map, max_cpus);
+
+if (cpu == max_cpus) {
+fprintf(stderr, "WARNING: qemu: Trying to use more "
+"CPUs than allowed max of %d\n", max_cpus);
+return max_cpus;
+} else {
+bitmap_set(cpu_index_map, cpu, 1);
+return cpu;
+}
+}
+
+void cpu_exec_exit(CPUState *cpu)
+{
+bitmap_clear(cpu_index_map, cpu->cpu_index, 1);
+}
+
 void cpu_exec_init(CPUArchState *env)
 {
 CPUState *cpu = ENV_GET_CPU(env);
 CPUClass *cc = CPU_GET_CLASS(cpu);
-CPUState *some_cpu;
-int cpu_index;
 
 #if defined(CONFIG_USER_ONLY)
 cpu_list_lock();
 #endif
-cpu_index = 0;
-CPU_FOREACH(some_cpu) {
-cpu_index++;
-}
-cpu->cpu_index = cpu_index;
+cpu->cpu_index = cpu_get_free_index();
 cpu->numa_node = 0;
 QTAILQ_INIT(&cpu->breakpoints);
 QTAILQ_INIT(&cpu->watchpoints);
@@ -558,16 +577,16 @@ void cpu_exec_init(CPUArchState *env)
 cpu_list_unlock();
 #endif
 if (qdev_get_vmsd(DEVICE(cpu)) == NULL) {
-vmstate_register(NULL, cpu_index, &vmstate_cpu_common, cpu);
+vmstate_register(NULL, cpu->cpu_index, &vmstate_cpu_common, cpu);
 }
 #if defined(CPU_SAVE_VERSION) && !defined(CONFIG_USER_ONLY)
-register_savevm(NULL, "cpu", cpu_index, CPU_SAVE_VERSION,
+register_savevm(NULL, "cpu", cpu->cpu_index, CPU_SAVE_VERSION,
 cpu_save, cpu_load, env);
 assert(cc->vmsd == NULL);
 assert(qdev_get_vmsd(DEVICE(cpu)) == NULL);
 #endif
 if (cc->vmsd != NULL) {
-vmstate_register(NULL, cpu_index, cc->vmsd, cpu);
+vmstate_register(NULL, cpu->cpu_index, cc->vmsd, cpu);
 }
 }
 
diff --git a/include/exec/exec-all.h b/include/exec/exec-all.h
index 8eb0db3..95fbba0 100644
--- a/include/exec/exec-all.h
+++ b/include/exec/exec-all.h
@@ -89,6 +89,7 @@ TranslationBlock *tb_gen_code(CPUState *cpu,
   target_ulong pc, target_ulong cs_base, int flags,
   int cflags);
 void cpu_exec_init(CPUArchState *env);
+void cpu_exec_exit(CPUState *cpu);
 void QEMU_NORETURN cpu_loop_exit(CPUState *cpu);
 int page_unprotect(target_ulong address, uintptr_t pc, void *puc);
 void tb_invalidate_phys_page_range(tb_page_addr_t start, tb_page_addr_t end,
diff --git a/target-alpha/cpu.c b/target-alpha/cpu.c
index a98b7d8..7c57165 100644
--- a/target-alpha/cpu.c
+++ b/target-alpha/cpu.c
@@ -250,6 +250,11 @@ static const TypeInfo ev68_cpu_type_info = {
 .parent = TYPE("ev67"),
 };
 
+static void alpha_cpu_finalize(Object *obj)
+{
+cpu_exec_exit(CPU(obj

Re: [Qemu-devel] [PATCH] block/throttle: Use host clock type

2015-03-13 Thread Alberto Garcia
On Fri, Mar 13, 2015 at 02:35:29PM +0800, Fam Zheng wrote:

> Throttle timers won't make any progress when VCPU is not running,
> which is prone to stall the request queue in cases like utils,
> qtest, suspending, and live migration, unless carefully handled.

Yes, this can be easily reproduced by stopping the VM and starting a
block-commit job. If the I/O in that device is throttled then the job
will be stalled.

Then there's also the situation that we discussed in IRC: if the
block-commit job is ongoing and then we stop the VM, then the rest of
the data will be committed bypassing the throttling settings.  But
that's not related to these changes.

> Signed-off-by: Fam Zheng 
> ---
>  block.c   |  2 +-
>  tests/test-throttle.c | 14 +++---
>  2 files changed, 8 insertions(+), 8 deletions(-)

Reviewed-By: Alberto Garcia 

Berto



Re: [Qemu-devel] [PATCH v4 4/4] migration: Expose 'cancelling' status to user

2015-03-13 Thread Eric Blake
On 03/13/2015 04:49 AM, Paolo Bonzini wrote:
> 
> 
> On 09/03/2015 07:45, zhanghailiang wrote:
>> 'cancelling' status was introduced by commit 51cf4c1a, mainly to avoid a 
>> possible start of a new migration process while the previous one still 
>> exists.
>> But we didn't expose this status to user, instead we returned the 'active' 
>> state.
>>
>> Here, we expose it to the user (such as libvirt), 'cancelling' status only
>> occurs for a short window before the migration aborts, so for users,
>> if they cancel a migration process, it will observe 'cancelling' status
>> occasionally.
>>
>> Testing revealed that with older libvirt (anything 1.2.13 or less) will
>> print an odd error message if the state is seen, but that the migration
>> is still properly cancelled. Newer libvirt will be patched to recognize
>> the new state without the odd error message.
>>
>> Signed-off-by: zhanghailiang 
>> Reviewed-by: Eric Blake 
>> Cc: libvir-l...@redhat.com
> 
> Why is this necessary?

It simplifies qemu's job of reporting migration status information (qemu
is no longer maintaining one set of states internally and a different
set of states externally), and I already have the libvirt counterpart
patch ready to go to gracefully accept the new state name.

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



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH v5 25/45] qemu_savevm_state_complete: Postcopy changes

2015-03-13 Thread Dr. David Alan Gilbert
* David Gibson (da...@gibson.dropbear.id.au) wrote:
> On Wed, Feb 25, 2015 at 04:51:48PM +, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" 
> > 
> > When postcopy calls qemu_savevm_state_complete it's not really
> > the end of migration, so skip:
> 
> Given that, maybe the name should change..

The name reflects that it calls the save_live_complete method on each
device, so if we wanted to remove the 'complete' from the name we'd
probably want to change the method name everywhere;   and anyway
it does complete most devices; the only exception are devices
that are postcopiable.

> >a) Finishing postcopiable iterative devices - they'll carry on
> >b) The termination byte on the end of the stream.
> > 
> > We then also add:
> >   qemu_savevm_state_postcopy_complete
> > which is called at the end of a postcopy migration to call the
> > complete methods on devices skipped in the _complete call.
> > 
> > Signed-off-by: Dr. David Alan Gilbert 
> 
> Otherwise,
> 
> Reviewed-by: David Gibson 

Thanks.

Dave

> 
> -- 
> 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


--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



Re: [Qemu-devel] [PATCH] block/throttle: Use host clock type

2015-03-13 Thread Paolo Bonzini


On 13/03/2015 13:23, Alberto Garcia wrote:
> On Fri, Mar 13, 2015 at 02:35:29PM +0800, Fam Zheng wrote:
> 
>> Throttle timers won't make any progress when VCPU is not running,
>> which is prone to stall the request queue in cases like utils,
>> qtest, suspending, and live migration, unless carefully handled.
> 
> Yes, this can be easily reproduced by stopping the VM and starting a
> block-commit job. If the I/O in that device is throttled then the job
> will be stalled.

That may be a different bug.  Should jobs be subject to throttling at all?

Paolo

> Then there's also the situation that we discussed in IRC: if the
> block-commit job is ongoing and then we stop the VM, then the rest of
> the data will be committed bypassing the throttling settings.  But
> that's not related to these changes.
> 
>> Signed-off-by: Fam Zheng 
>> ---
>>  block.c   |  2 +-
>>  tests/test-throttle.c | 14 +++---
>>  2 files changed, 8 insertions(+), 8 deletions(-)
> 
> Reviewed-By: Alberto Garcia 
> 
> Berto
> 
> 



Re: [Qemu-devel] [PATCH v4 4/4] migration: Expose 'cancelling' status to user

2015-03-13 Thread Dr. David Alan Gilbert
* Eric Blake (ebl...@redhat.com) wrote:
> On 03/13/2015 04:49 AM, Paolo Bonzini wrote:
> > 
> > 
> > On 09/03/2015 07:45, zhanghailiang wrote:
> >> 'cancelling' status was introduced by commit 51cf4c1a, mainly to avoid a 
> >> possible start of a new migration process while the previous one still 
> >> exists.
> >> But we didn't expose this status to user, instead we returned the 'active' 
> >> state.
> >>
> >> Here, we expose it to the user (such as libvirt), 'cancelling' status only
> >> occurs for a short window before the migration aborts, so for users,
> >> if they cancel a migration process, it will observe 'cancelling' status
> >> occasionally.
> >>
> >> Testing revealed that with older libvirt (anything 1.2.13 or less) will
> >> print an odd error message if the state is seen, but that the migration
> >> is still properly cancelled. Newer libvirt will be patched to recognize
> >> the new state without the odd error message.
> >>
> >> Signed-off-by: zhanghailiang 
> >> Reviewed-by: Eric Blake 
> >> Cc: libvir-l...@redhat.com
> > 
> > Why is this necessary?
> 
> It simplifies qemu's job of reporting migration status information (qemu
> is no longer maintaining one set of states internally and a different
> set of states externally), and I already have the libvirt counterpart
> patch ready to go to gracefully accept the new state name.

Yes, it does make life simpler in the long run.
(It does worry me a bit what happens to new qemu on old libvirt)

Dave

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


--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



Re: [Qemu-devel] [PATCH v2 4/4] dma-helpers: Move reschedule_dma BH to blk's AioContext

2015-03-13 Thread Paolo Bonzini


On 13/03/2015 11:48, Paolo Bonzini wrote:
> > The other possibility is grab a reference for the cpu_register_map_client 
> > call,
> > and release it in reschedule_dma. This way the atomics can keep, but we'll 
> > need
> > a "finished" flag in DMAAIOCB to avoid double completion.
> Considering this is a slow path, a lock seems preferrable.

And another problem...

You need to be careful about dma_aio_cancel running together with the
continue_after_map_failure, because continue_after_map_failure can be
called by another thread.  You could have

 continue_after_map_failure   dma_aio_cancel
 --
 aio_bh_new
  qemu_bh_delete
 qemu_bh_schedule (use after free)

To fix this, my suggestion is to pass a BH directly to
cpu_register_map_client (possibly to cpu_unregister_map_client as well?
 seems to have pros and cons).  Then cpu_notify_clients can run entirely
with the lock taken, and not race against cpu_unregister_map_client.
dma_aio_cancel can just do cpu_unregister_map_client followed by
qemu_bh_delete.

Paolo



Re: [Qemu-devel] [PATCH] hw/9pfs/virtio-9p-proxy: Fix possible overflow

2015-03-13 Thread Paolo Bonzini


On 13/03/2015 12:09, Shannon Zhao wrote:
> +g_assert(strlen(path) < sizeof(helper.sun_path));

Ok.

>  sockfd = socket(AF_UNIX, SOCK_STREAM, 0);
>  if (sockfd < 0) {
>  fprintf(stderr, "failed to create socket: %s\n", strerror(errno));
>  return -1;
>  }
> -strcpy(helper.sun_path, path);
> +strncpy(helper.sun_path, path, sizeof(helper.sun_path));

strcpy is okay here.  strncpy makes people think of what happens if
strlen(path) == sizeof(helper.sun_path).  While this cannot happen here
because of the assertion, the function should still be used with care.

Paolo



Re: [Qemu-devel] [PATCH] fsdev/virtfs-proxy-helper: Fix possible overflow

2015-03-13 Thread Paolo Bonzini


On 13/03/2015 12:09, Shannon Zhao wrote:
> +g_assert(strlen(path) < sizeof(proxy.sun_path));
>  sock = socket(AF_UNIX, SOCK_STREAM, 0);
>  if (sock < 0) {
>  do_perror("socket");
> @@ -748,7 +749,7 @@ static int proxy_socket(const char *path, uid_t uid, 
> gid_t gid)
>  umask(7);
>  
>  proxy.sun_family = AF_UNIX;
> -strcpy(proxy.sun_path, path);
> +strncpy(proxy.sun_path, path, sizeof(proxy.sun_path));
>  if (bind(sock, (struct sockaddr *)&proxy,

Same as the other patch.

Paolo



Re: [Qemu-devel] [PATCH] hw/net/e1000: fix integer endianness

2015-03-13 Thread Paolo Bonzini


On 13/03/2015 06:21, Shannon Zhao wrote:
> It's detected by coverity.In is_vlan_packet s->mac_reg[VET] is
> unsigned int but is dereferenced as a narrower unsigned short.
> This may lead to unexpected results depending on machine
> endianness.

Sounds good.  CCing Stefan, net/ maintainer.

> Signed-off-by: Shannon Zhao 
> Signed-off-by: Shannon Zhao 
> ---
>  hw/net/e1000.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/hw/net/e1000.c b/hw/net/e1000.c
> index a207e21..59d73cd 100644
> --- a/hw/net/e1000.c
> +++ b/hw/net/e1000.c
> @@ -578,7 +578,7 @@ static inline int
>  is_vlan_packet(E1000State *s, const uint8_t *buf)
>  {
>  return (be16_to_cpup((uint16_t *)(buf + 12)) ==
> -le16_to_cpup((uint16_t *)(s->mac_reg + VET)));
> +le16_to_cpu(s->mac_reg[VET]));
>  }
>  
>  static inline int
> @@ -711,7 +711,7 @@ process_tx_desc(E1000State *s, struct e1000_tx_desc *dp)
>  (tp->cptse || txd_lower & E1000_TXD_CMD_EOP)) {
>  tp->vlan_needed = 1;
>  stw_be_p(tp->vlan_header,
> -  le16_to_cpup((uint16_t *)(s->mac_reg + VET)));
> +  le16_to_cpu(s->mac_reg[VET]));
>  stw_be_p(tp->vlan_header + 2,
>le16_to_cpu(dp->upper.fields.special));
>  }
> 



Re: [Qemu-devel] [PATCH] vl: fix resource leak with monitor_fdset_add_fd

2015-03-13 Thread Paolo Bonzini


On 13/03/2015 06:17, Shannon Zhao wrote:
>> > -monitor_fdset_add_fd(dupfd, true, fdset_id, fd_opaque ? true : false,
>> > - fd_opaque, NULL);
>> > +fdinfo = monitor_fdset_add_fd(dupfd, true, fdset_id, fd_opaque ? true 
>> > : false,
>> > +  fd_opaque, NULL);
>> > +g_free(fdinfo);
>> >  
>> >  return 0;
>> >  }
>> > 
> Hi Paolo,
> 
> Not about the resource leak, but I think we should check fdinfo == NULL and 
> return -1.
> Then when error occurs, qemu will exit. Besides we should pass a meaningful 
> errp not NULL.
> So qemu can report the error reason. Right?

It cannot fail here, so another possibility could be to pass &error_abort.

Paolo



[Qemu-devel] [PATCH] vl: fix resource leak with monitor_fdset_add_fd

2015-03-13 Thread Paolo Bonzini
monitor_fdset_add_fd returns an AddfdInfo struct (used by the QMP
command add_fd).  Free it.

Signed-off-by: Paolo Bonzini 
---
v1->v2: line length [Fam], pass &error_abort [Shannon]
---
 vl.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/vl.c b/vl.c
index eba5d4c..9eae8f9 100644
--- a/vl.c
+++ b/vl.c
@@ -1011,6 +1011,7 @@ static int parse_add_fd(QemuOpts *opts, void *opaque)
 int fd, dupfd, flags;
 int64_t fdset_id;
 const char *fd_opaque = NULL;
+AddfdInfo *fdinfo;
 
 fd = qemu_opt_get_number(opts, "fd", -1);
 fdset_id = qemu_opt_get_number(opts, "set", -1);
@@ -1060,8 +1061,10 @@ static int parse_add_fd(QemuOpts *opts, void *opaque)
 }
 
 /* add the duplicate fd, and optionally the opaque string, to the fd set */
-monitor_fdset_add_fd(dupfd, true, fdset_id, fd_opaque ? true : false,
- fd_opaque, NULL);
+fdinfo = monitor_fdset_add_fd(dupfd, true, fdset_id,
+  fd_opaque ? true : false, fd_opaque,
+  &error_abort);
+g_free(fdinfo);
 
 return 0;
 }
-- 
2.3.0




[Qemu-devel] [PULL v3 1/5] sdl: Refresh debug statements

2015-03-13 Thread Gerd Hoffmann
From: Benjamin Herrenschmidt 

Put them under a #define similar to the VGA model and make them
actually compile. Add a couple too.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Gerd Hoffmann 
---
 ui/sdl.c | 24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/ui/sdl.c b/ui/sdl.c
index 138ca73..b89182a 100644
--- a/ui/sdl.c
+++ b/ui/sdl.c
@@ -61,16 +61,24 @@ static SDL_PixelFormat host_format;
 static int scaling_active = 0;
 static Notifier mouse_mode_notifier;
 
+#if 0
+#define DEBUG_SDL
+#endif
+
 static void sdl_update(DisplayChangeListener *dcl,
int x, int y, int w, int h)
 {
-//printf("updating x=%d y=%d w=%d h=%d\n", x, y, w, h);
 SDL_Rect rec;
 rec.x = x;
 rec.y = y;
 rec.w = w;
 rec.h = h;
 
+#ifdef DEBUG_SDL
+printf("SDL: Updating x=%d y=%d w=%d h=%d (scaling: %d)\n",
+   x, y, w, h, scaling_active);
+#endif
+
 if (guest_screen) {
 if (!scaling_active) {
 SDL_BlitSurface(guest_screen, &rec, real_screen, &rec);
@@ -89,7 +97,9 @@ static void do_sdl_resize(int width, int height, int bpp)
 int flags;
 SDL_Surface *tmp_screen;
 
-//printf("resizing to %d %d\n", w, h);
+#ifdef DEBUG_SDL
+printf("SDL: Resizing to %dx%d bpp %d\n", width, height, bpp);
+#endif
 
 flags = SDL_HWSURFACE | SDL_ASYNCBLIT | SDL_HWACCEL;
 if (gui_fullscreen) {
@@ -143,6 +153,12 @@ static void sdl_switch(DisplayChangeListener *dcl,
 if (guest_screen != NULL) {
 SDL_FreeSurface(guest_screen);
 }
+
+#ifdef DEBUG_SDL
+printf("SDL: Creating surface with masks: %08x %08x %08x %08x\n",
+   pf.rmask, pf.gmask, pf.bmask, pf.amask);
+#endif
+
 guest_screen = SDL_CreateRGBSurfaceFrom
 (surface_data(surface),
  surface_width(surface), surface_height(surface),
@@ -486,6 +502,10 @@ static void sdl_scale(int width, int height)
 {
 int bpp = real_screen->format->BitsPerPixel;
 
+#ifdef DEBUG_SDL
+printf("SDL: Scaling to %dx%d bpp %d\n", width, height, bpp);
+#endif
+
 if (bpp != 16 && bpp != 32) {
 bpp = 32;
 }
-- 
1.8.3.1




[Qemu-devel] [PULL v3 0/5] sdl patch queue.

2015-03-13 Thread Gerd Hoffmann
  Hi,

Misc stuff in the basket: sdl bugfixes, some preparing patches for the
upcoming opengl support in sdl2, x11 build improvement.

v2 fixes the clang build failure.
v3 (hopefully) fixes the osx build failure too.

please pull,
  Gerd

The following changes since commit ee74801035b0b5f1fdfd4e31d3a53f511f91c804:

  Merge remote-tracking branch 'remotes/lalrae/tags/mips-20150311' into staging 
(2015-03-11 18:22:15 +)

are available in the git repository at:


  git://git.kraxel.org/qemu tags/pull-sdl-20150312-2

for you to fetch changes up to 43db7c3d484943f62019434d919367c9e3e4402a:

  pixman: add a bunch of PIXMAN_BE_* defines for 32bpp (2015-03-12 15:50:11 
+0100)


misc ui patches, mostly sdl related.


Benjamin Herrenschmidt (2):
  sdl: Refresh debug statements
  sdl: Fix crash when calling sdl_switch() with NULL surface

Gerd Hoffmann (2):
  configure: opengl overhaul
  pixman: add a bunch of PIXMAN_BE_* defines for 32bpp

Jeremy White (1):
  Allow the use of X11 from a non standard location.

 configure| 59 +++-
 default-configs/lm32-softmmu.mak |  2 +-
 hw/display/Makefile.objs |  3 +-
 hw/lm32/milkymist-hw.h   |  4 +--
 include/sysemu/sysemu.h  |  1 +
 include/ui/qemu-pixman.h | 16 +++
 ui/sdl.c | 27 --
 vl.c |  1 +
 8 files changed, 81 insertions(+), 32 deletions(-)



[Qemu-devel] [PULL v3 4/5] Allow the use of X11 from a non standard location.

2015-03-13 Thread Gerd Hoffmann
From: Jeremy White 

Signed-off-by: Jeremy White 

[ kraxel: solve opengl patch conflicts ]

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Max Reitz 
---
 configure| 24 +++-
 hw/display/Makefile.objs |  1 +
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index 333d842..b858756 100755
--- a/configure
+++ b/configure
@@ -2085,6 +2085,15 @@ if test "$sparse" != "no" ; then
 fi
 
 ##
+# X11 probe
+x11_cflags=
+x11_libs=-lX11
+if $pkg_config --exists "x11"; then
+x11_cflags=`$pkg_config --cflags x11`
+x11_libs=`$pkg_config --libs x11`
+fi
+
+##
 # GTK probe
 
 if test "$gtkabi" = ""; then
@@ -2111,7 +2120,8 @@ if test "$gtk" != "no"; then
 gtk_cflags=`$pkg_config --cflags $gtkpackage`
 gtk_libs=`$pkg_config --libs $gtkpackage`
 if $pkg_config --exists "$gtkx11package >= $gtkversion"; then
-gtk_libs="$gtk_libs -lX11"
+gtk_cflags="$gtk_cflags $x11_cflags"
+gtk_libs="$gtk_libs $x11_libs"
 fi
 libs_softmmu="$gtk_libs $libs_softmmu"
 gtk="yes"
@@ -2236,8 +2246,9 @@ if test "$sdl" = "yes" ; then
 #endif
 int main(void) { return 0; }
 EOF
-  if compile_prog "$sdl_cflags" "$sdl_libs" ; then
-sdl_libs="$sdl_libs -lX11"
+  if compile_prog "$sdl_cflags $x11_cflags" "$sdl_libs $x11_libs" ; then
+sdl_cflags="$sdl_cflags $x11_cflags"
+sdl_libs="$sdl_libs $x11_libs"
   fi
   libs_softmmu="$sdl_libs $libs_softmmu"
 fi
@@ -3110,13 +3121,15 @@ libs_softmmu="$libs_softmmu $fdt_libs"
 # opengl probe (for sdl2, milkymist-tmu2)
 if test "$opengl" != "no" ; then
   opengl_pkgs="gl glx"
-  if $pkg_config $opengl_pkgs; then
-opengl_libs="$($pkg_config --libs $opengl_pkgs) -lX11"
+  if $pkg_config $opengl_pkgs x11; then
+opengl_cflags="$($pkg_config --cflags $opengl_pkgs) $x11_cflags"
+opengl_libs="$($pkg_config --libs $opengl_pkgs) $x11_libs"
 opengl=yes
   else
 if test "$opengl" = "yes" ; then
   feature_not_found "opengl" "Install GL devel (e.g. MESA)"
 fi
+opengl_cflags=""
 opengl_libs=""
 opengl=no
   fi
@@ -4753,6 +4766,7 @@ fi
 
 if test "$opengl" = "yes" ; then
   echo "CONFIG_OPENGL=y" >> $config_host_mak
+  echo "OPENGL_CFLAGS=$opengl_cflags" >> $config_host_mak
   echo "OPENGL_LIBS=$opengl_libs" >> $config_host_mak
 fi
 
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index e18ea57..e73cb7d 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -20,6 +20,7 @@ common-obj-$(CONFIG_ZAURUS) += tc6393xb.o
 
 ifeq ($(CONFIG_MILKYMIST_TMU2),y)
 common-obj-y += milkymist-tmu2.o
+milkymist-tmu2.o-cflags := $(OPENGL_CFLAGS)
 libs_softmmu += $(OPENGL_LIBS)
 endif
 
-- 
1.8.3.1




[Qemu-devel] [PULL v3 5/5] pixman: add a bunch of PIXMAN_BE_* defines for 32bpp

2015-03-13 Thread Gerd Hoffmann
Signed-off-by: Gerd Hoffmann 
Reviewed-by: Max Reitz 
---
 include/ui/qemu-pixman.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/include/ui/qemu-pixman.h b/include/ui/qemu-pixman.h
index 3dee576..5d7a9ac 100644
--- a/include/ui/qemu-pixman.h
+++ b/include/ui/qemu-pixman.h
@@ -27,8 +27,24 @@
 
 #ifdef HOST_WORDS_BIGENDIAN
 # define PIXMAN_BE_r8g8b8 PIXMAN_r8g8b8
+# define PIXMAN_BE_x8r8g8b8   PIXMAN_x8r8g8b8
+# define PIXMAN_BE_a8r8g8b8   PIXMAN_a8r8g8b8
+# define PIXMAN_BE_b8g8r8x8   PIXMAN_b8g8r8x8
+# define PIXMAN_BE_b8g8r8a8   PIXMAN_b8g8r8a8
+# define PIXMAN_BE_r8g8b8x8   PIXMAN_r8g8b8x8
+# define PIXMAN_BE_r8g8b8a8   PIXMAN_r8g8b8a8
+# define PIXMAN_BE_x8b8g8r8   PIXMAN_x8b8g8r8
+# define PIXMAN_BE_a8b8g8r8   PIXMAN_a8b8g8r8
 #else
 # define PIXMAN_BE_r8g8b8 PIXMAN_b8g8r8
+# define PIXMAN_BE_x8r8g8b8   PIXMAN_b8g8r8x8
+# define PIXMAN_BE_a8r8g8b8   PIXMAN_b8g8r8a8
+# define PIXMAN_BE_b8g8r8x8   PIXMAN_x8r8g8b8
+# define PIXMAN_BE_b8g8r8a8   PIXMAN_a8r8g8b8
+# define PIXMAN_BE_r8g8b8x8   PIXMAN_x8b8g8r8
+# define PIXMAN_BE_r8g8b8a8   PIXMAN_a8b8g8r8
+# define PIXMAN_BE_x8b8g8r8   PIXMAN_r8g8b8x8
+# define PIXMAN_BE_a8b8g8r8   PIXMAN_r8g8b8a8
 #endif
 
 /*  */
-- 
1.8.3.1




Re: [Qemu-devel] [PATCH v5 16/45] Add migration-capability boolean for postcopy-ram.

2015-03-13 Thread Dr. David Alan Gilbert
* David Gibson (da...@gibson.dropbear.id.au) wrote:
> On Wed, Feb 25, 2015 at 04:51:39PM +, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" 
> 
> This absolutely needs a commit message.  I shouldn't have to look at
> the code to find out what the presence of this capability asserts, and
> from where to where it's communicating that information.

OK, how about:

The 'postcopy ram' flag allows postcopy migration of RAM;
note that the migration starts off in precopy mode until
postcopy mode is triggered (see the migrate_start_postcopy
patch later in the series).


> > Signed-off-by: Dr. David Alan Gilbert 
> > Reviewed-by: Eric Blake 
> > ---
> >  include/migration/migration.h | 1 +
> >  migration/migration.c | 9 +
> >  qapi-schema.json  | 7 ++-
> >  3 files changed, 16 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/migration/migration.h b/include/migration/migration.h
> > index 751caa0..f94af5b 100644
> > --- a/include/migration/migration.h
> > +++ b/include/migration/migration.h
> > @@ -177,6 +177,7 @@ void migrate_add_blocker(Error *reason);
> >   */
> >  void migrate_del_blocker(Error *reason);
> >  
> > +bool migrate_postcopy_ram(void);
> >  bool migrate_rdma_pin_all(void);
> >  bool migrate_zero_blocks(void);
> >  
> > diff --git a/migration/migration.c b/migration/migration.c
> > index 4592060..434864a 100644
> > --- a/migration/migration.c
> > +++ b/migration/migration.c
> > @@ -663,6 +663,15 @@ bool migrate_rdma_pin_all(void)
> >  return s->enabled_capabilities[MIGRATION_CAPABILITY_RDMA_PIN_ALL];
> >  }
> >  
> > +bool migrate_postcopy_ram(void)
> > +{
> > +MigrationState *s;
> > +
> > +s = migrate_get_current();
> > +
> > +return s->enabled_capabilities[MIGRATION_CAPABILITY_X_POSTCOPY_RAM];
> 
> As an asside, I'm assuming you'll get rid of these "x-" prefixes
> before you post a series intended for final inclusion?

I was going to do that as a final patch that removed the x-.

Dave

> 
> > +}
> > +
> >  bool migrate_auto_converge(void)
> >  {
> >  MigrationState *s;
> > diff --git a/qapi-schema.json b/qapi-schema.json
> > index e16f8eb..a8af1cb 100644
> > --- a/qapi-schema.json
> > +++ b/qapi-schema.json
> > @@ -494,10 +494,15 @@
> >  # @auto-converge: If enabled, QEMU will automatically throttle down the 
> > guest
> >  #  to speed up convergence of RAM migration. (since 1.6)
> >  #
> > +# @x-postcopy-ram: Start executing on the migration target before all of 
> > RAM has
> > +#  been migrated, pulling the remaining pages along as needed. 
> > NOTE: If
> > +#  the migration fails during postcopy the VM will fail.  (since 
> > 2.3)
> > +#
> >  # Since: 1.2
> >  ##
> >  { 'enum': 'MigrationCapability',
> > -  'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks'] }
> > +  'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
> > +   'x-postcopy-ram'] }
> >  
> >  ##
> >  # @MigrationCapabilityStatus
> 
> -- 
> 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


--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



[Qemu-devel] [PULL v3 2/5] sdl: Fix crash when calling sdl_switch() with NULL surface

2015-03-13 Thread Gerd Hoffmann
From: Benjamin Herrenschmidt 

This happens for example when doing ctrl-alt-u and segfaults

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Gerd Hoffmann 
---
 ui/sdl.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ui/sdl.c b/ui/sdl.c
index b89182a..8bdbf52 100644
--- a/ui/sdl.c
+++ b/ui/sdl.c
@@ -135,12 +135,13 @@ static void do_sdl_resize(int width, int height, int bpp)
 static void sdl_switch(DisplayChangeListener *dcl,
DisplaySurface *new_surface)
 {
-PixelFormat pf = qemu_pixelformat_from_pixman(new_surface->format);
+PixelFormat pf;
 
 /* temporary hack: allows to call sdl_switch to handle scaling changes */
 if (new_surface) {
 surface = new_surface;
 }
+pf = qemu_pixelformat_from_pixman(surface->format);
 
 if (!scaling_active) {
 do_sdl_resize(surface_width(surface), surface_height(surface), 0);
-- 
1.8.3.1




[Qemu-devel] [PULL v3 3/5] configure: opengl overhaul

2015-03-13 Thread Gerd Hoffmann
Rename config option from "glx" to "opengl", glx will not be the only
option for opengl in near future.  Also switch over to pkg-config for
opengl support detection.

Signed-off-by: Gerd Hoffmann 
Reviewed-by: Max Reitz 
---
 configure| 39 +--
 default-configs/lm32-softmmu.mak |  2 +-
 hw/display/Makefile.objs |  2 +-
 hw/lm32/milkymist-hw.h   |  4 ++--
 include/sysemu/sysemu.h  |  1 +
 vl.c |  1 +
 6 files changed, 23 insertions(+), 26 deletions(-)

diff --git a/configure b/configure
index 7ba4bcb..333d842 100755
--- a/configure
+++ b/configure
@@ -309,7 +309,7 @@ rbd=""
 smartcard_nss=""
 libusb=""
 usb_redir=""
-glx=""
+opengl=""
 zlib="yes"
 lzo=""
 snappy=""
@@ -1027,9 +1027,9 @@ for opt do
   ;;
   --enable-vhost-scsi) vhost_scsi="yes"
   ;;
-  --disable-glx) glx="no"
+  --disable-opengl) opengl="no"
   ;;
-  --enable-glx) glx="yes"
+  --enable-opengl) opengl="yes"
   ;;
   --disable-rbd) rbd="no"
   ;;
@@ -3107,23 +3107,18 @@ fi
 libs_softmmu="$libs_softmmu $fdt_libs"
 
 ##
-# GLX probe, used by milkymist-tmu2
-if test "$glx" != "no" ; then
-  glx_libs="-lGL -lX11"
-  cat > $TMPC << EOF
-#include 
-#include 
-#include 
-int main(void) { glBegin(0); glXQueryVersion(0,0,0); return 0; }
-EOF
-  if compile_prog "" "-lGL -lX11" ; then
-glx=yes
+# opengl probe (for sdl2, milkymist-tmu2)
+if test "$opengl" != "no" ; then
+  opengl_pkgs="gl glx"
+  if $pkg_config $opengl_pkgs; then
+opengl_libs="$($pkg_config --libs $opengl_pkgs) -lX11"
+opengl=yes
   else
-if test "$glx" = "yes" ; then
-  feature_not_found "glx" "Install GL devel (e.g. MESA)"
+if test "$opengl" = "yes" ; then
+  feature_not_found "opengl" "Install GL devel (e.g. MESA)"
 fi
-glx_libs=
-glx=no
+opengl_libs=""
+opengl=no
   fi
 fi
 
@@ -4390,7 +4385,7 @@ echo "xfsctl support$xfs"
 echo "nss used  $smartcard_nss"
 echo "libusb$libusb"
 echo "usb net redir $usb_redir"
-echo "GLX support   $glx"
+echo "OpenGL support$opengl"
 echo "libiscsi support  $libiscsi"
 echo "libnfs support$libnfs"
 echo "build guest agent $guest_agent"
@@ -4756,9 +4751,9 @@ if test "$usb_redir" = "yes" ; then
   echo "CONFIG_USB_REDIR=y" >> $config_host_mak
 fi
 
-if test "$glx" = "yes" ; then
-  echo "CONFIG_GLX=y" >> $config_host_mak
-  echo "GLX_LIBS=$glx_libs" >> $config_host_mak
+if test "$opengl" = "yes" ; then
+  echo "CONFIG_OPENGL=y" >> $config_host_mak
+  echo "OPENGL_LIBS=$opengl_libs" >> $config_host_mak
 fi
 
 if test "$lzo" = "yes" ; then
diff --git a/default-configs/lm32-softmmu.mak b/default-configs/lm32-softmmu.mak
index 7df58c8..4889348 100644
--- a/default-configs/lm32-softmmu.mak
+++ b/default-configs/lm32-softmmu.mak
@@ -2,7 +2,7 @@
 
 CONFIG_LM32=y
 CONFIG_MILKYMIST=y
-CONFIG_MILKYMIST_TMU2=$(CONFIG_GLX)
+CONFIG_MILKYMIST_TMU2=$(CONFIG_OPENGL)
 CONFIG_FRAMEBUFFER=y
 CONFIG_PTIMER=y
 CONFIG_PFLASH_CFI01=y
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index 7ed76a9..e18ea57 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -20,7 +20,7 @@ common-obj-$(CONFIG_ZAURUS) += tc6393xb.o
 
 ifeq ($(CONFIG_MILKYMIST_TMU2),y)
 common-obj-y += milkymist-tmu2.o
-libs_softmmu += $(GLX_LIBS)
+libs_softmmu += $(OPENGL_LIBS)
 endif
 
 obj-$(CONFIG_OMAP) += omap_dss.o
diff --git a/hw/lm32/milkymist-hw.h b/hw/lm32/milkymist-hw.h
index 5317ce6..8d20cac 100644
--- a/hw/lm32/milkymist-hw.h
+++ b/hw/lm32/milkymist-hw.h
@@ -86,7 +86,7 @@ static inline DeviceState *milkymist_pfpu_create(hwaddr base,
 return dev;
 }
 
-#ifdef CONFIG_GLX
+#ifdef CONFIG_OPENGL
 #include 
 #include 
 static const int glx_fbconfig_attr[] = {
@@ -100,7 +100,7 @@ static const int glx_fbconfig_attr[] = {
 static inline DeviceState *milkymist_tmu2_create(hwaddr base,
 qemu_irq irq)
 {
-#ifdef CONFIG_GLX
+#ifdef CONFIG_OPENGL
 DeviceState *dev;
 Display *d;
 GLXFBConfig *configs;
diff --git a/include/sysemu/sysemu.h b/include/sysemu/sysemu.h
index 6e85097..8a52934 100644
--- a/include/sysemu/sysemu.h
+++ b/include/sysemu/sysemu.h
@@ -114,6 +114,7 @@ extern int graphic_width;
 extern int graphic_height;
 extern int graphic_depth;
 extern DisplayType display_type;
+extern int display_opengl;
 extern const char *keyboard_layout;
 extern int win2k_install_hack;
 extern int alt_grab;
diff --git a/vl.c b/vl.c
index eba5d4c..694deb4 100644
--- a/vl.c
+++ b/vl.c
@@ -130,6 +130,7 @@ static int data_dir_idx;
 const char *bios_name = NULL;
 enum vga_retrace_method vga_retrace_method = VGA_RETRACE_DUMB;
 DisplayType display_type = DT_DEFAULT;
+int display_opengl;
 static int display_remote;
 const char* keyboard_layout = NULL;
 ram_addr_t ram_size;
-- 
1.8.3.1




Re: [Qemu-devel] [PATCH v5 01/45] Start documenting how postcopy works.

2015-03-13 Thread Dr. David Alan Gilbert
* David Gibson (da...@gibson.dropbear.id.au) wrote:
> On Thu, Mar 05, 2015 at 09:21:39AM +, Dr. David Alan Gilbert wrote:
> > * David Gibson (da...@gibson.dropbear.id.au) wrote:
> > > On Wed, Feb 25, 2015 at 04:51:24PM +, Dr. David Alan Gilbert
> > (git) wrote:
> [snip]
> > > > +=== Enabling postcopy ===
> > > > +
> > > > +To enable postcopy (prior to the start of migration):
> > > > +
> > > > +migrate_set_capability x-postcopy-ram on
> > > > +
> > > > +The migration will still start in precopy mode, however issuing:
> > > > +
> > > > +migrate_start_postcopy
> > > > +
> > > > +will now cause the transition from precopy to postcopy.
> > > > +It can be issued immediately after migration is started or any
> > > > +time later on.  Issuing it after the end of a migration is harmless.
> > > 
> > > It's not quite clear to me what this means.  Does
> > > "migrate_start_postcopy" mean it will immediately transfer execution
> > > and transfer any remaining pages postcopy, or does it just mean it
> > > will start postcopying once the remaining data to transfer is small
> > > enough?
> > 
> > Yes; it will flip into postcopy soon after issuing that command irrespective
> > of the amount of data remaining.
> > 
> > > What's the reason for this rather awkward two stage activation of
> > > postcopy?
> > 
> > We need to keep track of the pages that are received during the precopy 
> > phase,
> > and do some madvise and other setups on the destination RAM area before 
> > precopy
> > starts; and so we need to know we might want to do postcopy - so we need
> > to be told early.  In the earliest posted version of my patches I had a
> > time-limit setting and after the time limit expired QEMU would switch into
> > the second phase of postcopy itself, but Paolo suggested the 
> > migrate_start_postcopy:
> > 
> > https://lists.nongnu.org/archive/html/qemu-devel/2014-07/msg00943.html
> > 
> > and it works out simpler anyway.
> 
> Ok, that makes sense.
> 
> > > > +=== Postcopy device transfer ===
> > > > +
> > > > +Loading of device data may cause the device emulation to access guest 
> > > > RAM
> > > > +that may trigger faults that have to be resolved by the source, as such
> > > > +the migration stream has to be able to respond with page data *during* 
> > > > the
> > > > +device load, and hence the device data has to be read from the stream 
> > > > completely
> > > > +before the device load begins to free the stream up.  This is achieved 
> > > > by
> > > > +'packaging' the device data into a blob that's read in one go.
> > > > +
> > > > +Source behaviour
> > > > +
> > > > +Until postcopy is entered the migration stream is identical to normal
> > > > +precopy, except for the addition of a 'postcopy advise' command at
> > > > +the beginning, to tell the destination that postcopy might happen.
> > > > +When postcopy starts the source sends the page discard data and then
> > > > +forms the 'package' containing:
> > > > +
> > > > +   Command: 'postcopy ram listen'
> > > > +   The device state
> > > > +  A series of sections, identical to the precopy streams device 
> > > > state stream
> > > > +  containing everything except postcopiable devices (i.e. RAM)
> > > > +   Command: 'postcopy ram run'
> > > > +
> > > > +The 'package' is sent as the data part of a Command: 'CMD_PACKAGED', 
> > > > and the
> > > > +contents are formatted in the same way as the main migration stream.
> > > 
> > > It seems to me the "ram listen", "ram run" and CMD_PACKAGED really
> > > have to be used in conjuction this way, they don't really have any use
> > > on their own.  So why not make it all CMD_POSTCOPY_TRANSITION and have
> > > the "listen" and "run" take effect implicitly at the beginning and end
> > > of the device data.
> > 
> > CMD_PACKAGED seems like something that was generally useful; it's fairly
> > complicated on it's own and so it seemed best to keep it separate.
> 
> And can you actually think of another use case for it?
> 
> The thing that bothers me is that the "listen" and "run" operations
> will not work correctly anywhere other than at the beginning and end
> of the packaged blob.

It feels similar to the packaged blobs that checkpointing schemes
like COLO and microcheckpointing use; although they seem to craft their own wire
protocol rather than sticking with a migration protocol.
What they do in terms of controlling the CPU etc is certainly different
(so the RUN/listen stuff is different).

Dave

> -- 
> 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


--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



[Qemu-devel] several security backports to the qemu-xen stable trees

2015-03-13 Thread Stefano Stabellini
Hi all,

I am writing to let you know that have pushed a long series of backports
to qemu-xen 4.2, 4.3, 4.4 and 4.5 stable staging trees. See below.

All the backports are security fixes of outstanding CVEs affecting QEMU.
As QEMU only provides backports to very recent stable releases, I had to
come up with some of the backports myself -- it is not impossible that I
introduced a few failures.  Please test and report any issues you might
find. Make sure you have QEMU_UPSTREAM_REVISION set to master in
Config.mk to build the lastest qemu-xen changes from the Xen build
system.

I have backported only fixes for issues that are relevant on a Xen
system. Although I also tried to cover things that can be triggered via
device_model_args (custom arguments for QEMU that would otherwise never
be used by libxl), I do not guarantee to have covered all of them. I
didn't backport fixes for emulated hardware we do not compile (e.g.
stellaris_enet) or we do not use (e.g. Q35).


The QEMU security team kindly agreed on letting me know about future
CVEs going forward -- I'll be able to provide timely backports from now
on.  I guarantee to provide backports for security issues that can be
triggered on a Xen system with the standard set of arguments passed by
libxl (no device_model_args) using QEMU as device model or provider of
Xen backends in userspace.

Please note that QEMU security issues are handled by the QEMU Security
team following the process described here: http://wiki.qemu.org/SecurityProcess

For people using QEMU stable trees with Xen, please be aware that QEMU
stable-2.0 and older are missing some of the backports below.  I
recommend switching to a new QEMU stable tree or to qemu-xen.


The full list of backports follow.


= qemu-xen 4.5 =
0b8fb1e cirrus: don't overflow CirrusVGAState->cirrus_bltbuf
f491518 cirrus: fix blit region check
99aa8a7 vnc: sanitize bits_per_pixel from the client
94d09f2 pcihp: fix possible array out of bounds
07fcd79 vmware-vga: CVE-2014-3689: turn off hw accel
979e4ea slirp: udp: fix NULL pointer dereference because of uninitialized socket
5c34028 spice: make sure we don't overflow ssd->buf
7154fba vbe: rework sanity checks
bedbc31 usb: fix up post load checks
c2757fe virtio-pci: fix MSI memory region use after free

= qemu-xen 4.4 =
d173a0c dmg: sanitize chunk length and sectorcount (CVE-2014-0145)
8b03ba5 dmg: prevent chunk buffer overflow (CVE-2014-0145)
f2edd51 bochs: Use unsigned variables for offsets and sizes (CVE-2014-0147)
b054785 qcow1: Validate image size (CVE-2014-0223)
7e6a078 qcow1: Validate L2 table size (CVE-2014-0222)
79eb552 qcow2: Don't rely on free_cluster_index in alloc_refcount_block() 
(CVE-2014-0147)
a796a26 qcow2: Fix NULL dereference in qcow2_open() error path (CVE-2014-0146)
b9b190d qcow2: Fix L1 allocation size in qcow2_snapshot_load_tmp() 
(CVE-2014-0145)
d792187 cirrus: don't overflow CirrusVGAState->cirrus_bltbuf
e12ce81 cirrus: fix blit region check
f67b16a vnc: sanitize bits_per_pixel from the client
9708234 vmstate_xhci_event: fix unterminated field list
a28 vmware-vga: CVE-2014-3689: turn off hw accel
f087884 slirp: udp: fix NULL pointer dereference because of uninitialized socket
2b4231f spice: make sure we don't overflow ssd->buf
3a8ef4b vbe: rework sanity checks
d0737b7 usb: fix up post load checks
29236c2 ide: Correct improper smart self test counter reset in ide core.
a86ea88 virtio: validate config_len on load
755a427 virtio-net: fix guest-triggerable buffer overrun
e86cc06 vhdx: Bounds checking for block_size and logical_sector_size 
(CVE-2014-0148)
d961961 virtio: avoid buffer overrun on incoming migration
ba607aa vmxnet3: validate queues configuration read on migration
8cc99ff vmxnet3: validate interrupt indices read on migration
7d34b5b vmxnet3: validate queues configuration coming from guest
ede728f vmxnet3: validate interrupt indices coming from guest
1b29677 virtio-scsi: fix buffer overrun on invalid state load
1a228d0 usb: sanity check setup_index+setup_len in post_load
5202189 virtio: validate num_sg when mapping
458864c hpet: fix buffer overrun on invalid state load
ae05660 ahci: fix buffer overrun on invalid state load
dee7bab virtio: out-of-bounds buffer write on invalid state load
651a486 virtio-net: out-of-bounds buffer write on invalid state load
90d1a97 virtio-net: out-of-bounds buffer write on load
ec86632 virtio-net: fix buffer overflow on invalid state load

= qemu-xen 4.3 =
ab689a8 dmg: sanitize chunk length and sectorcount (CVE-2014-0145)
1e005e1 dmg: prevent chunk buffer overflow (CVE-2014-0145)
2b2db1e bochs: Use unsigned variables for offsets and sizes (CVE-2014-0147)
62692e1 qcow1: Validate image size (CVE-2014-0223)
2247bc8 qcow1: Validate L2 table size (CVE-2014-0222)
982dc22 qcow2: Don't rely on free_cluster_index in alloc_refcount_block() 
(CVE-2014-0147)
8c58457 qcow2: Fix NULL dereference in qcow2_open() error path (CVE-2014-0146)
9af4ce8 qcow2: Fix L1 allocation size in qcow2_snapshot_load_tmp() 
(CVE-2014-01

Re: [Qemu-devel] [PATCH v4 4/4] migration: Expose 'cancelling' status to user

2015-03-13 Thread Eric Blake
On 03/13/2015 06:28 AM, Dr. David Alan Gilbert wrote:

>>
>> It simplifies qemu's job of reporting migration status information (qemu
>> is no longer maintaining one set of states internally and a different
>> set of states externally), and I already have the libvirt counterpart
>> patch ready to go to gracefully accept the new state name.
> 
> Yes, it does make life simpler in the long run.
> (It does worry me a bit what happens to new qemu on old libvirt)

In the past, we've already stated that it is okay for new qemu to
require new libvirt.  What is not okay is for new libvirt to require new
qemu.  This change is okay given those rules.

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



signature.asc
Description: OpenPGP digital signature


Re: [Qemu-devel] [PATCH v5 07/45] Return path: Open a return path on QEMUFile for sockets

2015-03-13 Thread Dr. David Alan Gilbert
* David Gibson (da...@gibson.dropbear.id.au) wrote:
> On Wed, Feb 25, 2015 at 04:51:30PM +, Dr. David Alan Gilbert (git) wrote:
> > From: "Dr. David Alan Gilbert" 
> > 
> > Postcopy needs a method to send messages from the destination back to
> > the source, this is the 'return path'.
> > 
> > Wire it up for 'socket' QEMUFile's using a dup'd fd.
> > 
> > Signed-off-by: Dr. David Alan Gilbert 
> > ---
> >  include/migration/qemu-file.h  |  7 +
> >  migration/qemu-file-internal.h |  2 ++
> >  migration/qemu-file-unix.c | 58 
> > +++---
> >  migration/qemu-file.c  | 12 +
> >  4 files changed, 70 insertions(+), 9 deletions(-)
> > 
> > diff --git a/include/migration/qemu-file.h b/include/migration/qemu-file.h
> > index 6ae0b03..3c38963 100644
> > --- a/include/migration/qemu-file.h
> > +++ b/include/migration/qemu-file.h
> > @@ -85,6 +85,11 @@ typedef size_t (QEMURamSaveFunc)(QEMUFile *f, void 
> > *opaque,
> > int *bytes_sent);
> >  
> >  /*
> > + * Return a QEMUFile for comms in the opposite direction
> > + */
> > +typedef QEMUFile *(QEMURetPathFunc)(void *opaque);
> > +
> > +/*
> >   * Stop any read or write (depending on flags) on the underlying
> >   * transport on the QEMUFile.
> >   * Existing blocking reads/writes must be woken
> > @@ -102,6 +107,7 @@ typedef struct QEMUFileOps {
> >  QEMURamHookFunc *after_ram_iterate;
> >  QEMURamHookFunc *hook_ram_load;
> >  QEMURamSaveFunc *save_page;
> > +QEMURetPathFunc *get_return_path;
> >  QEMUFileShutdownFunc *shut_down;
> >  } QEMUFileOps;
> >  
> > @@ -188,6 +194,7 @@ int64_t qemu_file_get_rate_limit(QEMUFile *f);
> >  int qemu_file_get_error(QEMUFile *f);
> >  void qemu_file_set_error(QEMUFile *f, int ret);
> >  int qemu_file_shutdown(QEMUFile *f);
> > +QEMUFile *qemu_file_get_return_path(QEMUFile *f);
> >  void qemu_fflush(QEMUFile *f);
> >  
> >  static inline void qemu_put_be64s(QEMUFile *f, const uint64_t *pv)
> > diff --git a/migration/qemu-file-internal.h b/migration/qemu-file-internal.h
> > index d95e853..a39b8e3 100644
> > --- a/migration/qemu-file-internal.h
> > +++ b/migration/qemu-file-internal.h
> > @@ -48,6 +48,8 @@ struct QEMUFile {
> >  unsigned int iovcnt;
> >  
> >  int last_error;
> > +
> > +struct QEMUFile *return_path;
> 
> AFAICT, the only thing this field is used for is an assert, which
> seems a bit pointless.  I'd suggest either getting rid of it, or

Done; it's gone.

Dave

> make qemu_file_get_return_path() safely idempotent by having it only
> call the FileOps pointer if QEMUFile::return_path is non-NULL,
> otherwise just return the existing return_path.
> 
> Setting the field probably belongs better in the wrapper than in the
> socket specific callback, too, since there's nothing inherently
> related to the socket implementation about it.
> 
> -- 
> 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


--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK



Re: [Qemu-devel] [Xen-devel] several security backports to the qemu-xen stable trees

2015-03-13 Thread Jan Beulich
>>> On 13.03.15 at 14:06,  wrote:
> I am writing to let you know that have pushed a long series of backports
> to qemu-xen 4.2, 4.3, 4.4 and 4.5 stable staging trees. See below.

And just for clarification - considering how late in the 4.4.2 and 4.3.4
release process it is, none of those fixes will be part of these releases.

Jan




Re: [Qemu-devel] [Bug 1428657] Re: qemu-system-arm does not ignore the lowest bit of pc when returning from interrrupt

2015-03-13 Thread Anders Esbensen
I've tested the patch against the FreeRTOS example. An the patch seems 
to make the example run.
The FreeRTOS sample now crash for other reasons. But I consider the 
issue resolved.

/Anders

On 03/12/2015 02:45 PM, Peter Maydell wrote:
> Proposed patch: http://patchwork.ozlabs.org/patch/449400/ which could
> use testing.
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1428657

Title:
  qemu-system-arm does not ignore the lowest bit of pc when returning
  from interrrupt

Status in QEMU:
  New

Bug description:
  This was observed in qemu v2.1.3, running a sample app from

  FreeRTOS(FreeRTOSV7.5.2/FreeRTOS/Demo/CORTEX_LM3S_Eclipse/RTOSDemo)

  In the sample code compiled with arm-none-eabi-gcc , version 4.8.2
  (4.8.2-14ubuntu1+6) .

  qemu seems to be executing the wrong instrunction after returning from
  the SVCHandler. The svc handler changes the PSP register and the new
  stack contains an add return address, which should be
  
allowed(http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka12545.html).
  The lowest bit of the address should be ignored, but it seems that
  qemu executes garbage after returning from the interrupt.

  qemu is run like this:

  qemu-system-arm -semihosting -machine lm3s6965evb -kernel RTOSDemo.axf
  -gdb tcp::1234 -S

  
  this is the arm-gdb trace
  Program received signal SIGINT, Interrupt.
  IntDefaultHandler () at startup.c:231
  231   {
  (gdb) bt
  #0  IntDefaultHandler () at startup.c:231
  #1  0xfffc in ?? ()

  (gdb) info registers 
  r0 0x00
  r1 0x14b4b4b4 347387060
  r2 0xa5a5a5a5 -1515870811
  r3 0xa5a5a53d -1515870915
  r4 0xa5a5a5a5 -1515870811
  r5 0xa5a5a5a5 -1515870811
  r6 0xa5a5a5a5 -1515870811
  r7 0x40d00542 1087374658
  r8 0xa5a5a5a5 -1515870811
  r9 0xa5a5a5a5 -1515870811
  r100xa5a5a5a5 -1515870811
  r110xa5a5a5a5 -1515870811
  r120xa5a5a5a5 -1515870811
  sp 0x20008380 0x20008380
  lr 0xfffd -3
  pc 0xc648 0xc648 
  cpsr   0x2173 536871283

  this exception occur after running SVC handler code

  (gdb) disassemble vPortSVCHandler 
  Dump of assembler code for function vPortSVCHandler:
 0xc24c <+0>:   ldr r3, [pc, #24]   ; (0xc268 )
 0xc24e <+2>:   ldr r1, [r3, #0]
 0xc250 <+4>:   ldr r0, [r1, #0]
 0xc252 <+6>:   ldmia.w r0!, {r4, r5, r6, r7, r8, r9, r10, r11}
 0xc256 <+10>:  msr PSP, r0
 0xc25a <+14>:  mov.w   r0, #0
 0xc25e <+18>:  msr BASEPRI, r0
 0xc262 <+22>:  orr.w   lr, lr, #13
 0xc266 <+26>:  bx  lr
 0xc268 <+28>:  andcs   r2, r0, r12, ror #5
  End of assembler dump.

  This stores this stack in PSP register:
  (gdb) x /32 0x200052c8
  0x200052c8:   0xa5a5a5a5  0xa5a5a5a5  0xa5a5a5a5  0xa5a5a5a5
  0x200052d8:   0xa5a5a5a5  0xa5a5a5a5  0xa5a5a5a5  0xa5a5a5a5
  0x200052e8:   0x  0x14b4b4b4  0xa5a5a5a5  0xa5a5a53d
  0x200052f8:   0xa5a5a5a5  0x  0x3b49  0x2100
  0x20005308:   0xa5a5a5a5  0xa5a5a5a5  0x200081b8  0x0058
  0x20005318:   0x  0x  0x  0x
  0x20005328:   0x  0x20005330  0x  0x20005330
  0x20005338:   0x20005330  0x  0x20005344  0x

  It seems that qemu actually executes 0x3b49 after the interrupt,
  but it should execute 0x3b48

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1428657/+subscriptions



[Qemu-devel] UMEQ: an alternative to QEMU user-mode

2015-03-13 Thread Rémi Duraffort

Hello,

during the last Linaro Connect in Hong Kong I presented (see [1] and 
[2]) a project called UMEQ, for User Mode Emulation Quest.


The goal of this project is to run AArch64 binaries on a x86_64 host in 
user mode. Exactly like QEMU user-mode.
But, as I presented, QEMU user-mode is often crashing with applications 
that use signals and/or threads while UMEQ is working correctly.


For instance we can run (thanks to UMEQ) complexe AArch64 programs like 
vlc, okular, battle for wesnoth, gdb, ... on an x86_64 host.


As promised during the connect, the code is now available at 
https://github.com/mickael-guene/umeq


Feel free to compile it, test it, read the sources and ask questions to 
his author mickael Guene.



Best regards


[1] 
http://www.slideshare.net/linaroorg/hkg15202-umeq-user-mode-emulation-quest

[2] http://www.youtube.com/watch?v=2-mU0mXHxJg

--
Rémi Duraffort
STMicroelectronics Engineer
Linaro assignee for LAVA



  1   2   3   >