[Qemu-devel] [Bug 1196773] [NEW] pci_add auto nic failed on qemu monitor

2013-07-01 Thread xingshui.dong
Public bug reported:

hello!
execute "qemu-system-x86_64 -M pc -m 256 -hda pc/img.qcow2 -nographic -net 
nic,vlan=0,macaddr=00:e0:fc:00:00:01 -net tap,vlan=0,ifname=tap0,script=no 
-serial tcp::,server,nowait -boot c"
and then
(qemu) pci_add auto nic vlan=1,macaddr=00:e0:fc:40:20:02
Property 'e1000.netdev' can't take value 'hub0port0', it's in use

the qemu version is 1.4.1

thx!

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  pci_add auto nic failed on qemu monitor

Status in QEMU:
  New

Bug description:
  hello!
  execute "qemu-system-x86_64 -M pc -m 256 -hda pc/img.qcow2 -nographic -net 
nic,vlan=0,macaddr=00:e0:fc:00:00:01 -net tap,vlan=0,ifname=tap0,script=no 
-serial tcp::,server,nowait -boot c"
  and then
  (qemu) pci_add auto nic vlan=1,macaddr=00:e0:fc:40:20:02
  Property 'e1000.netdev' can't take value 'hub0port0', it's in use

  the qemu version is 1.4.1

  thx!

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



Re: [Qemu-devel] [PATCH v2 1/2] ps2: add support of auto-repeat

2013-07-01 Thread Amos Kong
On Wed, Jun 26, 2013 at 01:56:33PM +0200, Markus Armbruster wrote:
> Luiz Capitulino  writes:
> 
> > On Fri, 14 Jun 2013 13:46:41 +0800
> > Amos Kong  wrote:
> >
> >> On Fri, May 31, 2013 at 08:31:17PM +0800, Amos Kong wrote:
> >> > On Thu, May 30, 2013 at 11:48:46AM -0500, Anthony Liguori wrote:
> >> > > Amos Kong  writes:
> >> 
> >> 
> >> > > > diff --git a/hw/input/ps2.c b/hw/input/ps2.c
> >> > > > index 3412079..8adbb4a 100644
> >> > > > --- a/hw/input/ps2.c
> >> > > > +++ b/hw/input/ps2.c
> >> > > > @@ -94,6 +94,10 @@ typedef struct {
> >> > > >  int translate;
> >> > > >  int scancode_set; /* 1=XT, 2=AT, 3=PS/2 */
> >> > > >  int ledstate;
> >> > > > +int repeat_period; /* typematic period, ms */
> >> > > > +int repeat_delay; /* typematic delay, ms */
> >> > > > +int repeat_key; /* keycode to repeat */
> >> > > > +QEMUTimer *repeat_timer;
> >> > > 
> >> > > This state needs to be migrated, no?  I suspect it can/should be done
> >> > > via a subsection too.
> >> > 
> >> > It sounds only reasonable for 'sendkey' command. We want to repeat one
> >> > key for 100 times, the key should be continaully repeated in the dest
> >> > vm until it reaches to 100 times.
> >> > 
> >> > For implement this, we should also migrate key_timer in ui/input.c,
> >> > then it will send a release event to ps2 queue when the key_timer
> >> > is expired. The bottom patch migrates repeat_timer & repeat_key,
> >> > where should we save key_timer for migration?
> >> 
> >> Luiz, any suggestion about migrate the key_timer in ui/input.c?
> >
> > I don't have any. Maybe Markus or Juan can help (CC'ed).
> >
> >> 
> >> We need to migrate it, then sendkey can continually work in dest vm
> >> until the timer is expired.
> 
> I read the thread, but I'm not sure I have enough context for a sensible
> answer.  Let me try to piece it together.
> 
> On a real PC keyboard, key down generates that key's make code, key up
> generates the key's break code.  If the key is typematic, the make code
> repeats while the key is down.  First repeat is after a programmable
> delay, subsequent repeats happen at a programmable rate.
> 
> Which keys are typematic is programmable in scan code set 3, but we
> don't implement the commands to do so.  Oh well, the world is full of
> crappy clone keyboards, this is just one more.
> 
> What problem are you trying to solve?  Your cover letter mentions the
> sendkey command.  Takes an array of keys and an optional hold-time,
> defaulting to 100ms.
> 
> Aside: array of keys + a single hold time is a rotten design.  Outside
> the scope of this patch.
> 
> 100ms is well below the smallest typematic delay, so by default no
> repeat happens.  But if you specify a sufficiently large hold-time, it
> arguably should.  Is that the problem you're trying to fix?

The events qemu gets from host userspace is auto-repeated (using host's
repeat rate), it's ok to just pass the events to guest.

What my patch is doing:

1) process the events from host userspace to the raw events from
keyboard hardware, then implement the auto-repeat function in qemu,
then it can be configured by guest os(delay/rate).

2) for the sendkey. I had planed to just sent repeated events from
sendkey code by calling interface in ps2 code. The discussion wishes
to implement real auto-repeat for ps2 emulated device.


Actually it's not a urgent/necessary request. Host provided
auto-repeat works, and we didn't have real application of holding
key by sendkey command now.


> Why is this problem worth fixing?
> 
> Does your patch affect anything but the sendkey command?  I'm asking
> because I'm not at all sure injecting emulated repeat between the user's
> keyboard and the guest OS is a good idea.  I'd expect the user's
> keyboard to repeat according to the user's wishes already, and I'm
> concerned a second repeat could mess up things.

-- 
Amos.



Re: [Qemu-devel] [PATCH v5] Add timestamp to error_report()

2013-07-01 Thread Laszlo Ersek
On 07/01/13 20:54, Seiji Aguchi wrote:
> [Issue]
> When we offer a customer support service and a problem happens
> in a customer's system, we try to understand the problem by
> comparing what the customer reports with message logs of the
> customer's system.
> 
> In this case, we often need to know when the problem happens.
> 
> But, currently, there is no timestamp in qemu's error messages.
> Therefore, we may not be able to understand the problem based on
> error messages.
> 
> [Solution]
> Add a timestamp to qemu's error message logged by
> error_report() with g_time_val_to_iso8601().
> 
> Signed-off-by: Seiji Aguchi 
> ---
> Changelog
>  v4 -> v5
>  - Use sizeof() to define TIMESTAMP_LEN.
>  - Fix descriptions of msg option.
>  - Rename TIME_H to QEMU_TIME_H. (avoiding double inclusion of qemu/time.h)
>  - Change argument of qemu_get_timestamp_str to "char *" and "size_t".
>  - Confirmed msg option is displayed by query-command-line-options.

Reviewed-by: Laszlo Ersek 

Since you plan to post followup patches, please at that time include a
one-liner modification: the STEXI-ETEXI section in "qemu-options.hx"
still says (right before ETEXI) "(disabled by default)". I think it
should be fixed in a followup, not by posting v6.

Thanks!
Laszlo





Re: [Qemu-devel] [PATCH 21/24] hw/p*: pass owner to memory_region_init_io

2013-07-01 Thread Paolo Bonzini
Il 02/07/2013 01:31, Andreas Färber ha scritto:
>> > Signed-off-by: Paolo Bonzini 
> Needs an update after ppc-next merge, cf. attached.

Thanks!

Paolo



Re: [Qemu-devel] [PATCH v2 06/11] memory: add ref/unref calls

2013-07-01 Thread Paolo Bonzini
Il 01/07/2013 20:33, Jan Kiszka ha scritto:
> On 2013-06-28 18:58, Paolo Bonzini wrote:
>> Add ref/unref calls at the following places:
>>
>> - places where memory regions are stashed by a listener and
>>   used outside the BQL (including in Xen or KVM).
>>
>> - memory_region_find callsites
> 
> You missed some recently added ones. Check hw/acpi/piix4.c and
> hw/isa/lpc_ich9.c (both will require some refactorings for this).

Here are the required changes:

diff --git a/hw/acpi/piix4.c b/hw/acpi/piix4.c
index 3b95c69..0310053 100644
--- a/hw/acpi/piix4.c
+++ b/hw/acpi/piix4.c
@@ -380,6 +380,16 @@ static void piix4_pm_powerdown_req(Notifier *n, void 
*opaque)
 acpi_pm1_evt_power_down(&s->ar);
 }
 
+static bool memory_region_present(MemoryRegion *io, hwaddr port)
+{
+MemoryRegion *mr = memory_region_find(io, port, 1);
+if (!mr) {
+return false;
+}
+memory_region_unref(mr);
+return true;
+}
+
 static void piix4_pm_machine_ready(Notifier *n, void *opaque)
 {
 PIIX4PMState *s = container_of(n, PIIX4PMState, machine_ready);
@@ -388,10 +398,10 @@ static void piix4_pm_machine_ready(Notifier *n, void 
*opaque)
 
 pci_conf = s->dev.config;
 pci_conf[0x5f] = 0x10 |
-(memory_region_find(io_as, 0x378, 1).mr ? 0x80 : 0);
+(memory_region_present(io_as, 0x378, 1) ? 0x80 : 0);
 pci_conf[0x63] = 0x60;
-pci_conf[0x67] = (memory_region_find(io_as, 0x3f8, 1).mr ? 0x08 : 0) |
-(memory_region_find(io_as, 0x2f8, 1).mr ? 0x90 : 0);
+pci_conf[0x67] = (memory_region_present(io_as, 0x3f8, 1) ? 0x08 : 0) |
+(memory_region_present(io_as, 0x2f8, 1) ? 0x90 : 0);
 }
 
 static int piix4_pm_initfn(PCIDevice *dev)
diff --git a/hw/isa/lpc_ich9.c b/hw/isa/lpc_ich9.c
index 82f8ea6..205ac26 100644
--- a/hw/isa/lpc_ich9.c
+++ b/hw/isa/lpc_ich9.c
@@ -478,24 +478,33 @@ static void ich9_lpc_machine_ready(Notifier *n, void 
*opaque)
 {
 ICH9LPCState *s = container_of(n, ICH9LPCState, machine_ready);
 MemoryRegion *io_as = pci_address_space_io(&s->d);
+MemoryRegion *mr;
 uint8_t *pci_conf;
 
 pci_conf = s->d.config;
-if (memory_region_find(io_as, 0x3f8, 1).mr) {
+mr = memory_region_find(io_as, 0x3f8, 1).mr;
+if (mr) {
 /* com1 */
 pci_conf[0x82] |= 0x01;
+memory_region_unref(mr);
 }
-if (memory_region_find(io_as, 0x2f8, 1).mr) {
+mr = memory_region_find(io_as, 0x2f8, 1).mr;
+if (mr) {
 /* com2 */
 pci_conf[0x82] |= 0x02;
+memory_region_unref(mr);
 }
-if (memory_region_find(io_as, 0x378, 1).mr) {
+mr = memory_region_find(io_as, 0x378, 1).mr;
+if (mr) {
 /* lpt */
 pci_conf[0x82] |= 0x04;
+memory_region_unref(mr);
 }
-if (memory_region_find(io_as, 0x3f0, 1).mr) {
+mr = memory_region_find(io_as, 0x3f0, 1).mr;
+if (mr) {
 /* floppy */
 pci_conf[0x82] |= 0x08;
+memory_region_unref(mr);
 }
 }
 





Re: [Qemu-devel] [PATCH v4 08/10] qemu-ga: call Windows VSS requester in fsfreeze command handler

2013-07-01 Thread Laszlo Ersek
On 07/01/13 19:59, Tomoki Sekiyama wrote:
> On 7/1/13 9:29 , "Laszlo Ersek"  wrote:
> 
>>> +error:
>>> +qmp_guest_fsfreeze_thaw(NULL);
>>
>> Passing NULL here as "errp" concerns me slightly. I've been assuming
>> that "errp" is never NULL due to the outermost QMP layer always wanting
>> to receive errors and to serialize them.
>>
>> Specifically, a NULL "errp" would turn all error_set*(errp, ...) calls
>> into no-ops under qmp_guest_fsfreeze_thaw(), and all error_is_set(errp)
>> questions would answer with false. That said, nothing seems to be
>> affected right now.
>>
>> Maybe a dummy local variable would be more future-proof... OTOH it would
>> be stylistically questionable :)
> 
> OK, then it should be:
> Error *local_err = NULL;
> ...
> error:
> qmp_guest_fsfreeze_thaw(&local_err);
> if (error_is_set(&local_err)) {
> error_free(local_err);
> }

I think so, yes.

You could also log it before freeing it I guess:

g_debug("cleanup thaw: %s", error_get_pretty(local_err));

or some such, but it's probably not important.

Thanks,
Laszlo




Re: [Qemu-devel] [PATCH v3 2/2] net: introduce command to query rx-filter information

2013-07-01 Thread Amos Kong
On Wed, Jun 26, 2013 at 11:54:20AM +0200, Markus Armbruster wrote:
> Amos Kong  writes:
> 
> > We want to implement mac programming over macvtap through Libvirt,
> > related rx-filter configuration contains main mac, some of rx-mode
> > and mac-table.
> >
> > The previous patch adds QMP event to notify management of rx-filter
> > change. This patch adds a monitor command to query rx-filter
> > information.
> >
> > A flag is used to avoid events flooding, if user don't query
> > rx-filter after receives one event, new events won't be sent
> > to qmp monitor.
> >
> > (qemu) info rx-filter vnet0
> > vnet0:
> >  \ promiscuous: on
> >  \ multicast: normal
> >  \ unicast: normal
> >  \ broadcast-allowed: off
> >  \ multicast-overflow: off
> >  \ unicast-overflow: off
> >  \ main-mac: 52:54:00:12:34:56
> >  \ unicast-table:
> >  \ multicast-table:
> > 01:00:5e:00:00:01
> > 33:33:00:00:00:01
> > 33:33:ff:12:34:56
> >
> > Signed-off-by: Amos Kong 

Thanks for your comments, some comments are out-of-data, I removed
them in this reply.

> > +static RxFilterInfo *virtio_net_query_rxfilter(NetClientState *nc)
> > +{
> > +VirtIONet *n = qemu_get_nic_opaque(nc);
> > +RxFilterInfo *info;
> > +strList *str_list = NULL;
> > +strList *entry;
> > +int i;
> > +
> > +info = g_malloc0(sizeof(*info));
> > +info->name = g_strdup(nc->name);
> > +info->promiscuous = n->promisc;
> > +
> > +if (n->nouni) {
> > +info->unicast = RX_STATE_NO;
> > +} else if (n->alluni) {
> > +info->unicast = RX_STATE_ALL;
> > +} else {
> > +info->unicast = RX_STATE_NORMAL;
> > +}
> > +
> > +if (n->nomulti) {
> > +info->multicast = RX_STATE_NO;
> > +} else if (n->allmulti) {
> > +info->multicast = RX_STATE_ALL;
> > +} else {
> > +info->multicast = RX_STATE_NORMAL;
> > +}
> 
> Makes me wonder whether replacing VirtIONet members noFOO and allFOO by
> an enum RxState would make things clearer there.  Outside the scope of
> this patch.

Good suggestion, added to my todolist.
 
> > +
> > +info->broadcast_allowed = n->nobcast;
> > +info->multicast_overflow = n->mac_table.multi_overflow;
> > +info->unicast_overflow = n->mac_table.uni_overflow;
> > +info->main_mac = g_strdup_printf("%.2x:%.2x:%.2x:%.2x:%.2x:%.2x",
> > + n->mac[0], n->mac[1], n->mac[2],
> > + n->mac[3], n->mac[4], n->mac[5]);
> > +
> 
> Please initialize str_list here rather than at its declaration, because
> that'll make the loop's workings more locally obvious, and because...
> 
> > +for (i = 0; i < n->mac_table.first_multi; i++) {
> > +entry = g_malloc0(sizeof(*entry));
> > +entry->value = g_strdup_printf("%.2x:%.2x:%.2x:%.2x:%.2x:%.2x",
> > +   n->mac_table.macs[i * ETH_ALEN],
> > +   n->mac_table.macs[i * ETH_ALEN + 1],
> > +   n->mac_table.macs[i * ETH_ALEN + 2],
> > +   n->mac_table.macs[i * ETH_ALEN + 3],
> > +   n->mac_table.macs[i * ETH_ALEN + 4],
> > +   n->mac_table.macs[i * ETH_ALEN + 
> > 5]);
> > +entry->next = str_list;
> > +str_list = entry;
> > +}
> > +info->unicast_table = str_list;
> > +
> 
> ... it's how this loop works.
> 
> Actually, the two loops are duplicates.  Consider factoring out a helper
> function.
> > +return info;
> > +}
> > +
> >  static void virtio_net_reset(VirtIODevice *vdev)
> >  {
> >  VirtIONet *n = VIRTIO_NET(vdev);
> > @@ -442,6 +528,8 @@ static int virtio_net_handle_rx_mode(VirtIONet *n, 
> > uint8_t cmd,
> >  return VIRTIO_NET_ERR;
> >  }
> >  
> > +rxfilter_notify(n->netclient_name);
> > +
> >  return VIRTIO_NET_OK;
> >  }
> >  
> > @@ -495,6 +583,8 @@ static int virtio_net_handle_mac(VirtIONet *n, uint8_t 
> > cmd,
> >  s = iov_to_buf(iov, iov_cnt, 0, &n->mac, sizeof(n->mac));
> >  assert(s == sizeof(n->mac));
> >  qemu_format_nic_info_str(qemu_get_queue(n->nic), n->mac);
> > +rxfilter_notify(n->netclient_name);
> > +
> >  return VIRTIO_NET_OK;
> >  }
> >  
> > @@ -559,6 +649,8 @@ static int virtio_net_handle_mac(VirtIONet *n, uint8_t 
> > cmd,
> >  n->mac_table.multi_overflow = 1;
> >  }
> >  
> > +rxfilter_notify(n->netclient_name);
> > +
> >  return VIRTIO_NET_OK;
> >  }
> >  
> 
> The error returns don't trigger the event.  We can fail after clearing
> n->mac_table.  Why is that okay?

We should notify in error path if n->mac_table is changed.
 
> > @@ -1312,6 +1404,7 @@ static NetClientInfo net_virtio_info = {
> >  .receive = virtio_net_receive,
> >  .cleanup = virtio_net_cleanup,
> >  .link_status_changed = virtio_net_set_link_status,
> > +.query_rx_filter = virtio_net_que

[Qemu-devel] [PATCH 7/7] block: assign backing relationship in drive-backup

2013-07-01 Thread Fam Zheng
Assign source image as the backing hd of target bs, so reading target bs
gets the point-in-time copy of data from source image.

Signed-off-by: Fam Zheng 
---
 block/backup.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/block/backup.c b/block/backup.c
index 4e9f927..2dd0540 100644
--- a/block/backup.c
+++ b/block/backup.c
@@ -294,6 +294,11 @@ static void coroutine_fn backup_run(void *opaque)
 hbitmap_free(job->bitmap);
 
 bdrv_iostatus_disable(target);
+
+bdrv_put_ref(target->backing_hd);
+target->backing_hd = NULL;
+target->backing_file[0] = '\0';
+target->backing_format[0] = '\0';
 bdrv_put_ref(target);
 
 block_job_completed(&job->common, ret);
@@ -332,7 +337,15 @@ void backup_start(BlockDriverState *bs, BlockDriverState 
*target,
 return;
 }
 
+target->backing_hd = bs;
+pstrcpy(target->backing_file, sizeof(target->backing_file),
+bs->filename);
+pstrcpy(target->backing_format, sizeof(target->backing_format),
+bs->drv->format_name);
 bdrv_get_ref(target);
+/* Get another ref to source for backing_hd relationship */
+bdrv_get_ref(bs);
+
 job->on_source_error = on_source_error;
 job->on_target_error = on_target_error;
 job->target = target;
-- 
1.8.3.1




[Qemu-devel] [PATCH 4/7] block: simplify bdrv_drop_intermediate

2013-07-01 Thread Fam Zheng
Signed-off-by: Fam Zheng 
---
 block.c | 71 ++---
 1 file changed, 11 insertions(+), 60 deletions(-)

diff --git a/block.c b/block.c
index d1ce570..ae5de17 100644
--- a/block.c
+++ b/block.c
@@ -2015,12 +2015,6 @@ BlockDriverState *bdrv_find_overlay(BlockDriverState 
*active,
 return overlay;
 }
 
-typedef struct BlkIntermediateStates {
-BlockDriverState *bs;
-QSIMPLEQ_ENTRY(BlkIntermediateStates) entry;
-} BlkIntermediateStates;
-
-
 /*
  * Drops images above 'base' up to and including 'top', and sets the image
  * above 'top' to have base as its backing file.
@@ -2050,15 +2044,9 @@ typedef struct BlkIntermediateStates {
 int bdrv_drop_intermediate(BlockDriverState *active, BlockDriverState *top,
BlockDriverState *base)
 {
-BlockDriverState *intermediate;
-BlockDriverState *base_bs = NULL;
 BlockDriverState *new_top_bs = NULL;
-BlkIntermediateStates *intermediate_state, *next;
 int ret = -EIO;
 
-QSIMPLEQ_HEAD(states_to_delete, BlkIntermediateStates) states_to_delete;
-QSIMPLEQ_INIT(&states_to_delete);
-
 if (!top->drv || !base->drv) {
 goto exit;
 }
@@ -2070,58 +2058,21 @@ int bdrv_drop_intermediate(BlockDriverState *active, 
BlockDriverState *top,
 goto exit;
 }
 
-/* special case of new_top_bs->backing_hd already pointing to base - 
nothing
- * to do, no intermediate images */
-if (new_top_bs->backing_hd == base) {
-ret = 0;
-goto exit;
-}
-
-intermediate = top;
-
-/* now we will go down through the list, and add each BDS we find
- * into our deletion queue, until we hit the 'base'
- */
-while (intermediate) {
-intermediate_state = g_malloc0(sizeof(BlkIntermediateStates));
-intermediate_state->bs = intermediate;
-QSIMPLEQ_INSERT_TAIL(&states_to_delete, intermediate_state, entry);
-
-if (intermediate->backing_hd == base) {
-base_bs = intermediate->backing_hd;
-break;
+while (new_top_bs->backing_hd && new_top_bs->backing_hd != base) {
+BlockDriverState *backing = new_top_bs->backing_hd;
+if (backing == NULL) {
+goto exit;
 }
-intermediate = intermediate->backing_hd;
-}
-if (base_bs == NULL) {
-/* something went wrong, we did not end at the base. safely
- * unravel everything, and exit with error */
-goto exit;
+new_top_bs->backing_hd = backing->backing_hd;
+/* break backing_hd chain before releasing bs, so we don't free all the
+ * way up the backing chain */
+backing->backing_hd = NULL;
+bdrv_put_ref(backing);
 }
 
-/* success - we can delete the intermediate states, and link top->base */
-ret = bdrv_change_backing_file(new_top_bs, base_bs->filename,
-   base_bs->drv ? base_bs->drv->format_name : 
"");
-if (ret) {
-goto exit;
-}
-if (new_top_bs->backing_hd) {
-bdrv_put_ref(new_top_bs->backing_hd);
-}
-new_top_bs->backing_hd = base_bs;
-bdrv_get_ref(base_bs);
-
-QSIMPLEQ_FOREACH_SAFE(intermediate_state, &states_to_delete, entry, next) {
-/* so that bdrv_close() does not recursively close the chain */
-intermediate_state->bs->backing_hd = NULL;
-bdrv_put_ref(intermediate_state->bs);
-}
-ret = 0;
-
+ret = bdrv_change_backing_file(new_top_bs, base->filename,
+   base->drv ? base->drv->format_name : "");
 exit:
-QSIMPLEQ_FOREACH_SAFE(intermediate_state, &states_to_delete, entry, next) {
-g_free(intermediate_state);
-}
 return ret;
 }
 
-- 
1.8.3.1




[Qemu-devel] [PATCH 6/7] block: add target-id option to drive-backup QMP command

2013-07-01 Thread Fam Zheng
Add target-id (optional) to drive-backup command, to make the target bs
a named drive so that we can operate on it (e.g. export with NBD).

Signed-off-by: Fam Zheng 
---
 blockdev.c   | 4 +++-
 qapi-schema.json | 7 +--
 qmp-commands.hx  | 3 ++-
 3 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/blockdev.c b/blockdev.c
index d02d99a..a297eaf 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -936,6 +936,7 @@ static void drive_backup_prepare(BlkTransactionState 
*common, Error **errp)
 backup = common->action->drive_backup;
 
 qmp_drive_backup(backup->device, backup->target,
+ backup->has_target_id, backup->target_id,
  backup->has_format, backup->format,
  backup->has_mode, backup->mode,
  backup->has_speed, backup->speed,
@@ -1421,6 +1422,7 @@ void qmp_block_commit(const char *device,
 }
 
 void qmp_drive_backup(const char *device, const char *target,
+  bool has_target_id, const char *target_id,
   bool has_format, const char *format,
   bool has_mode, enum NewImageMode mode,
   bool has_speed, int64_t speed,
@@ -1495,7 +1497,7 @@ void qmp_drive_backup(const char *device, const char 
*target,
 return;
 }
 
-target_bs = bdrv_new("");
+target_bs = bdrv_new(has_target_id ? target_id : "");
 ret = bdrv_open(target_bs, target, NULL, flags, drv);
 if (ret < 0) {
 bdrv_delete(target_bs);
diff --git a/qapi-schema.json b/qapi-schema.json
index 5c32528..2f2a87f 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -1654,7 +1654,8 @@
 # Since: 1.6
 ##
 { 'type': 'DriveBackup',
-  'data': { 'device': 'str', 'target': 'str', '*format': 'str',
+  'data': { 'device': 'str', 'target': 'str',
+'*target-id': 'str', '*format': 'str',
 '*mode': 'NewImageMode', '*speed': 'int',
 '*on-source-error': 'BlockdevOnError',
 '*on-target-error': 'BlockdevOnError' } }
@@ -1807,6 +1808,7 @@
 #  is a device, the existing file/device will be used as the new
 #  destination.  If it does not exist, a new file will be created.
 #
+# @target-id: #optional the drive id of the target.
 # @format: #optional the format of the new destination, default is to
 #  probe if @mode is 'existing', else the format of the source
 #
@@ -1833,7 +1835,8 @@
 # Since 1.6
 ##
 { 'command': 'drive-backup',
-  'data': { 'device': 'str', 'target': 'str', '*format': 'str',
+  'data': { 'device': 'str', 'target': 'str',
+'*target-id': 'str', '*format': 'str',
 '*mode': 'NewImageMode', '*speed': 'int',
 '*on-source-error': 'BlockdevOnError',
 '*on-target-error': 'BlockdevOnError' } }
diff --git a/qmp-commands.hx b/qmp-commands.hx
index 362f0e1..3ed03de 100644
--- a/qmp-commands.hx
+++ b/qmp-commands.hx
@@ -913,7 +913,7 @@ EQMP
 
 {
 .name   = "drive-backup",
-.args_type  = "device:B,target:s,speed:i?,mode:s?,format:s?,"
+.args_type  = 
"device:B,target:s,target-id:s?,speed:i?,mode:s?,format:s?,"
   "on-source-error:s?,on-target-error:s?",
 .mhandler.cmd_new = qmp_marshal_input_drive_backup,
 },
@@ -936,6 +936,7 @@ Arguments:
 device, the existing file/device will be used as the new
 destination.  If it does not exist, a new file will be created.
 (json-string)
+- "target-id": the drive id of the target image.
 - "format": the format of the new destination, default is to probe if 'mode' is
 'existing', else the format of the source
 (json-string, optional)
-- 
1.8.3.1




[Qemu-devel] [PATCH 5/7] block: rename bdrv_in_use to bdrv_is_shared

2013-07-01 Thread Fam Zheng
The patch only does a rename: bdrv_in_use is obsecure literally (any BDS
is certain to be used somewhere). Rename it to bdrv_is_shared since we
have reference count now and the user number of the BDS is reflected
there.

Signed-off-by: Fam Zheng 
---
 block.c   | 16 ++--
 blockdev.c| 10 +-
 blockjob.c|  2 +-
 include/block/block.h |  2 +-
 4 files changed, 17 insertions(+), 13 deletions(-)

diff --git a/block.c b/block.c
index ae5de17..85dc76f 100644
--- a/block.c
+++ b/block.c
@@ -1775,7 +1775,7 @@ int bdrv_commit(BlockDriverState *bs)
 return -ENOTSUP;
 }
 
-if (bdrv_in_use(bs) || bdrv_in_use(bs->backing_hd)) {
+if (bdrv_is_shared(bs) || bdrv_is_shared(bs->backing_hd)) {
 return -EBUSY;
 }
 
@@ -2621,14 +2621,18 @@ int bdrv_truncate(BlockDriverState *bs, int64_t offset)
 {
 BlockDriver *drv = bs->drv;
 int ret;
-if (!drv)
+if (!drv) {
 return -ENOMEDIUM;
-if (!drv->bdrv_truncate)
+}
+if (!drv->bdrv_truncate) {
 return -ENOTSUP;
-if (bs->read_only)
+}
+if (bs->read_only) {
 return -EACCES;
-if (bdrv_in_use(bs))
+}
+if (bdrv_is_shared(bs)) {
 return -EBUSY;
+}
 ret = drv->bdrv_truncate(bs, offset);
 if (ret == 0) {
 ret = refresh_total_sectors(bs, offset >> BDRV_SECTOR_BITS);
@@ -4333,7 +4337,7 @@ void bdrv_get_ref(BlockDriverState *bs)
 bs->refcount++;
 }
 
-int bdrv_in_use(BlockDriverState *bs)
+int bdrv_is_shared(BlockDriverState *bs)
 {
 return bs->refcount > 1;
 }
diff --git a/blockdev.c b/blockdev.c
index 2c2ea59..d02d99a 100644
--- a/blockdev.c
+++ b/blockdev.c
@@ -858,7 +858,7 @@ static void external_snapshot_prepare(BlkTransactionState 
*common,
 return;
 }
 
-if (bdrv_in_use(state->old_bs)) {
+if (bdrv_is_shared(state->old_bs)) {
 error_set(errp, QERR_DEVICE_IN_USE, device);
 return;
 }
@@ -1064,7 +1064,7 @@ exit:
 
 static void eject_device(BlockDriverState *bs, int force, Error **errp)
 {
-if (bdrv_in_use(bs)) {
+if (bdrv_is_shared(bs)) {
 error_set(errp, QERR_DEVICE_IN_USE, bdrv_get_device_name(bs));
 return;
 }
@@ -1226,7 +1226,7 @@ int do_drive_del(Monitor *mon, const QDict *qdict, 
QObject **ret_data)
 qerror_report(QERR_DEVICE_NOT_FOUND, id);
 return -1;
 }
-if (bdrv_in_use(bs)) {
+if (bdrv_is_shared(bs)) {
 qerror_report(QERR_DEVICE_IN_USE, id);
 return -1;
 }
@@ -1471,7 +1471,7 @@ void qmp_drive_backup(const char *device, const char 
*target,
 }
 }
 
-if (bdrv_in_use(bs)) {
+if (bdrv_is_shared(bs)) {
 error_set(errp, QERR_DEVICE_IN_USE, device);
 return;
 }
@@ -1588,7 +1588,7 @@ void qmp_drive_mirror(const char *device, const char 
*target,
 }
 }
 
-if (bdrv_in_use(bs)) {
+if (bdrv_is_shared(bs)) {
 error_set(errp, QERR_DEVICE_IN_USE, device);
 return;
 }
diff --git a/blockjob.c b/blockjob.c
index a841a66..3e9b9a8 100644
--- a/blockjob.c
+++ b/blockjob.c
@@ -41,7 +41,7 @@ void *block_job_create(const BlockJobType *job_type, 
BlockDriverState *bs,
 {
 BlockJob *job;
 
-if (bs->job || bdrv_in_use(bs)) {
+if (bs->job || bdrv_is_shared(bs)) {
 error_set(errp, QERR_DEVICE_IN_USE, bdrv_get_device_name(bs));
 return NULL;
 }
diff --git a/include/block/block.h b/include/block/block.h
index 77f0f0d..6b33f5a 100644
--- a/include/block/block.h
+++ b/include/block/block.h
@@ -355,7 +355,7 @@ void bdrv_disable_copy_on_read(BlockDriverState *bs);
 
 void bdrv_put_ref(BlockDriverState *bs);
 void bdrv_get_ref(BlockDriverState *bs);
-int bdrv_in_use(BlockDriverState *bs);
+int bdrv_is_shared(BlockDriverState *bs);
 
 #ifdef CONFIG_LINUX_AIO
 int raw_get_aio_fd(BlockDriverState *bs);
-- 
1.8.3.1




[Qemu-devel] [PATCH 3/7] nbd: use BDS refcount

2013-07-01 Thread Fam Zheng
Previously, nbd call drive_get_ref on the drive of bs. A BDS doesn't
always have associated dinfo, it's more proper to use bdrv_get_ref().

Signed-off-by: Fam Zheng 
---
 blockdev-nbd.c | 9 +
 nbd.c  | 5 +
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/blockdev-nbd.c b/blockdev-nbd.c
index 95f10c8..d8bcd6f 100644
--- a/blockdev-nbd.c
+++ b/blockdev-nbd.c
@@ -69,12 +69,6 @@ static void nbd_close_notifier(Notifier *n, void *data)
 g_free(cn);
 }
 
-static void nbd_server_put_ref(NBDExport *exp)
-{
-BlockDriverState *bs = nbd_export_get_blockdev(exp);
-drive_put_ref(drive_get_by_blockdev(bs));
-}
-
 void qmp_nbd_server_add(const char *device, bool has_writable, bool writable,
 Error **errp)
 {
@@ -106,10 +100,9 @@ void qmp_nbd_server_add(const char *device, bool 
has_writable, bool writable,
 }
 
 exp = nbd_export_new(bs, 0, -1, writable ? 0 : NBD_FLAG_READ_ONLY,
- nbd_server_put_ref);
+ NULL);
 
 nbd_export_set_name(exp, device);
-drive_get_ref(drive_get_by_blockdev(bs));
 
 n = g_malloc0(sizeof(NBDCloseNotifier));
 n->n.notify = nbd_close_notifier;
diff --git a/nbd.c b/nbd.c
index 2606403..f28b9fb 100644
--- a/nbd.c
+++ b/nbd.c
@@ -881,6 +881,7 @@ NBDExport *nbd_export_new(BlockDriverState *bs, off_t 
dev_offset,
 exp->nbdflags = nbdflags;
 exp->size = size == -1 ? bdrv_getlength(bs) : size;
 exp->close = close;
+bdrv_get_ref(bs);
 return exp;
 }
 
@@ -927,6 +928,10 @@ void nbd_export_close(NBDExport *exp)
 }
 nbd_export_set_name(exp, NULL);
 nbd_export_put(exp);
+if (exp->bs) {
+bdrv_put_ref(exp->bs);
+exp->bs = NULL;
+}
 }
 
 void nbd_export_get(NBDExport *exp)
-- 
1.8.3.1




[Qemu-devel] [PATCH 2/7] block: use refcount to manage BlockDriverState lifecycle

2013-07-01 Thread Fam Zheng
Device attach, NBD server and block job can share a BlockDriverState,
this patch makes them to use refcount to grab/release a bs so they don't
interfere each other with BDS lifecycle.

Local BDS allocation/releasing don't need to use refcount to manage it,
just use bdrv_new() and bdrv_delete().

If BDS is possibly shared with other code (e.g. NBD and guest device),
use bdrv_new to allocate, then bdrv_get_ref to grab it, when job is
done, call bdrv_put_ref() to release it. Don't call bdrv_delete(), since
it's deleted automatically by the last bdrv_put_ref().

Signed-off-by: Fam Zheng 
---
 block-migration.c |  1 -
 block.c   | 31 ---
 block/backup.c|  3 ++-
 block/blkdebug.c  |  1 +
 block/blkverify.c |  2 ++
 block/mirror.c|  4 ++--
 block/snapshot.c  |  3 ++-
 block/stream.c|  2 +-
 block/vvfat.c |  4 +++-
 blockdev.c|  5 +++--
 hw/block/xen_disk.c   |  7 +--
 include/block/block_int.h | 16 
 12 files changed, 53 insertions(+), 26 deletions(-)

diff --git a/block-migration.c b/block-migration.c
index 2efb6c0..2154b3a 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -558,7 +558,6 @@ static void blk_mig_cleanup(void)
 while ((bmds = QSIMPLEQ_FIRST(&block_mig_state.bmds_list)) != NULL) {
 QSIMPLEQ_REMOVE_HEAD(&block_mig_state.bmds_list, entry);
 bdrv_get_ref(bmds->bs);
-drive_put_ref(drive_get_by_blockdev(bmds->bs));
 g_free(bmds->aio_bitmap);
 g_free(bmds);
 }
diff --git a/block.c b/block.c
index 84c3181..d1ce570 100644
--- a/block.c
+++ b/block.c
@@ -740,7 +740,6 @@ static int bdrv_open_common(BlockDriverState *bs, 
BlockDriverState *file,
 ret = -EINVAL;
 goto free_and_fail;
 }
-assert(file != NULL);
 bs->file = file;
 ret = drv->bdrv_open(bs, options, open_flags);
 }
@@ -748,7 +747,6 @@ static int bdrv_open_common(BlockDriverState *bs, 
BlockDriverState *file,
 if (ret < 0) {
 goto free_and_fail;
 }
-
 ret = refresh_total_sectors(bs, bs->total_sectors);
 if (ret < 0) {
 goto free_and_fail;
@@ -925,6 +923,7 @@ int bdrv_open_backing_file(BlockDriverState *bs, QDict 
*options)
 bs->open_flags |= BDRV_O_NO_BACKING;
 return ret;
 }
+bdrv_get_ref(bs->backing_hd);
 return 0;
 }
 
@@ -1068,9 +1067,11 @@ int bdrv_open(BlockDriverState *bs, const char 
*filename, QDict *options,
 
 if (bs->file != file) {
 bdrv_delete(file);
-file = NULL;
 }
 
+file = NULL;
+bdrv_get_ref(bs->file);
+
 /* If there is a backing file, use it */
 if ((flags & BDRV_O_NO_BACKING) == 0) {
 QDict *backing_options;
@@ -1367,7 +1368,7 @@ void bdrv_close(BlockDriverState *bs)
 
 if (bs->drv) {
 if (bs->backing_hd) {
-bdrv_delete(bs->backing_hd);
+bdrv_put_ref(bs->backing_hd);
 bs->backing_hd = NULL;
 }
 bs->drv->bdrv_close(bs);
@@ -1391,7 +1392,7 @@ void bdrv_close(BlockDriverState *bs)
 bs->options = NULL;
 
 if (bs->file != NULL) {
-bdrv_delete(bs->file);
+bdrv_put_ref(bs->file);
 bs->file = NULL;
 }
 }
@@ -1536,7 +1537,7 @@ void bdrv_swap(BlockDriverState *bs_new, BlockDriverState 
*bs_old)
 assert(bs_new->dirty_bitmap == NULL);
 assert(bs_new->job == NULL);
 assert(bs_new->dev == NULL);
-assert(bs_new->refcount == 0);
+assert(bs_new->refcount <= 1);
 assert(bs_new->io_limits_enabled == false);
 assert(bs_new->block_timer == NULL);
 
@@ -1555,7 +1556,7 @@ void bdrv_swap(BlockDriverState *bs_new, BlockDriverState 
*bs_old)
 /* Check a few fields that should remain attached to the device */
 assert(bs_new->dev == NULL);
 assert(bs_new->job == NULL);
-assert(bs_new->refcount == 0);
+assert(bs_new->refcount <= 1);
 assert(bs_new->io_limits_enabled == false);
 assert(bs_new->block_timer == NULL);
 
@@ -1609,6 +1610,7 @@ int bdrv_attach_dev(BlockDriverState *bs, void *dev)
 return -EBUSY;
 }
 bs->dev = dev;
+bdrv_get_ref(bs);
 bdrv_iostatus_reset(bs);
 return 0;
 }
@@ -1626,6 +1628,7 @@ void bdrv_detach_dev(BlockDriverState *bs, void *dev)
 {
 assert(bs->dev == dev);
 bs->dev = NULL;
+bdrv_put_ref(bs);
 bs->dev_ops = NULL;
 bs->dev_opaque = NULL;
 bs->buffer_alignment = 512;
@@ -2102,13 +2105,16 @@ int bdrv_drop_intermediate(BlockDriverState *active, 
BlockDriverState *top,
 if (ret) {
 goto exit;
 }
+if (new_top_bs->backing_hd) {
+bdrv_put_ref(new_top_bs->backing_hd);
+}
 new_top_bs->backing_hd = base_bs;
-
+bdrv_get_ref(base_bs);
 
 QSIMPLEQ_FOREACH_SAFE(intermediate_state, &states_to_delete, entry, next) {
 /* so that bdrv_close() does not recursively close the chain */
   

[Qemu-devel] [PATCH 0/7] Point-in-time snapshot exporting over NBD

2013-07-01 Thread Fam Zheng
This series adds for point-in-time snapshot NBD exporting based on
drive-backup. The ideas is described below and patches followed (the missing
part is item 3, which work is in progress by Ian Main who will have another
patch on it). As the work does not overlap, these series should be quite
reviewable by itself.

Background
==

The goal of image fleecing is to provide a interface to inspect a point-in-time
snapshot of guest image data, not being interfered with guest overwrites after
it's created.  With drive-backup we already have the point-in-time snapshot
image (the target image), we only need three modifications to realize this:

 1. Give backup target an id, so we can add it to NBD server.

 2. Assign source device as backing of target, so reading the unallocated will
be passed to source.
As there's copy-on-write mechanism with drive-backup job, all the modified
data after snapshot created is copied to target, the unallocated data is
guaranteed to be unchanged, so reading from the source is correct. Note
that this requires target format supports backing file.

 3. Adding sync mode 'none' to drive-backup, so the block job only copy changed
data from source, which has minimal IO overhead.

Usage
=

With above three, we can simply export a point-in-time snapshot with two QMP 
commands:

drive-backup device=virtio0 format=qcow2 target=point-in-time.qcow2 
target-id=pit0 sync=none
(sync=none is not implemented for now but we can simulate with speed=1)

nbd-server-add device=pit0 writable=no

Lifecycle
=

Reference count for BlockDriverState is implemented to manage their lifecycles.
Device attachment, block job, backing hd, bs->file NBD and others are current
referred points of a BDS, they each call bdrv_get_ref when starting to use a
BDS and bdrv_put_ref when releasing, e.g. on hot plug/unplug, nbd_server_add,
drive-backup, etc.

I.e., when a drive-backup target bs is being exported through NBD and the backup
job finishes (or cancelled), the device is not deleted, the client can continue
to access the NBD target until nbd_server_stop. It is automatically deleted
when the last reference is released.

The target image file is not removed automatically, since we can't assume that
it's temporary. It's up to the user to remove it manually, or we need to add a
command or option to mark the target bs temporary.

Fam Zheng (7):
  block: Convert BlockDriverState.in_use to refcount
  block: use refcount to manage BlockDriverState lifecycle
  nbd: use BDS refcount
  block: simplify bdrv_drop_intermediate
  block: rename bdrv_in_use to bdrv_is_shared
  block: add target-id option to drive-backup QMP command
  block: assign backing relationship in drive-backup

 block-migration.c   |   5 +-
 block.c | 123 +++-
 block/backup.c  |  16 +-
 block/blkdebug.c|   1 +
 block/blkverify.c   |   2 +
 block/mirror.c  |   4 +-
 block/snapshot.c|   3 +-
 block/stream.c  |   2 +-
 block/vvfat.c   |   4 +-
 blockdev-nbd.c  |   9 +--
 blockdev.c  |  19 ---
 blockjob.c  |   8 +--
 hw/block/dataplane/virtio-blk.c |   4 +-
 hw/block/xen_disk.c |   7 +--
 include/block/block.h   |   5 +-
 include/block/block_int.h   |  18 +-
 nbd.c   |   5 ++
 qapi-schema.json|   7 ++-
 qmp-commands.hx |   3 +-
 19 files changed, 126 insertions(+), 119 deletions(-)

-- 
1.8.3.1




[Qemu-devel] [PATCH 1/7] block: Convert BlockDriverState.in_use to refcount

2013-07-01 Thread Fam Zheng
Use numeric value to replace in_use flag in BDS, this will make
lifecycle management with ref count possible. This patch only replaces
existing uses of bdrv_set_in_use, so no logic change here.

Signed-off-by: Fam Zheng 
---
 block-migration.c   |  4 ++--
 block.c | 23 +++
 blockjob.c  |  6 +++---
 hw/block/dataplane/virtio-blk.c |  4 ++--
 include/block/block.h   |  3 ++-
 include/block/block_int.h   |  2 +-
 6 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/block-migration.c b/block-migration.c
index 2fd7699..2efb6c0 100644
--- a/block-migration.c
+++ b/block-migration.c
@@ -321,7 +321,7 @@ static void init_blk_migration_it(void *opaque, 
BlockDriverState *bs)
 bmds->shared_base = block_mig_state.shared_base;
 alloc_aio_bitmap(bmds);
 drive_get_ref(drive_get_by_blockdev(bs));
-bdrv_set_in_use(bs, 1);
+bdrv_get_ref(bs);
 
 block_mig_state.total_sector_sum += sectors;
 
@@ -557,7 +557,7 @@ static void blk_mig_cleanup(void)
 blk_mig_lock();
 while ((bmds = QSIMPLEQ_FIRST(&block_mig_state.bmds_list)) != NULL) {
 QSIMPLEQ_REMOVE_HEAD(&block_mig_state.bmds_list, entry);
-bdrv_set_in_use(bmds->bs, 0);
+bdrv_get_ref(bmds->bs);
 drive_put_ref(drive_get_by_blockdev(bmds->bs));
 g_free(bmds->aio_bitmap);
 g_free(bmds);
diff --git a/block.c b/block.c
index 6c493ad..84c3181 100644
--- a/block.c
+++ b/block.c
@@ -1503,8 +1503,10 @@ static void bdrv_move_feature_fields(BlockDriverState 
*bs_dest,
 /* dirty bitmap */
 bs_dest->dirty_bitmap   = bs_src->dirty_bitmap;
 
+/* ref count */
+bs_dest->refcount   = bs_src->refcount;
+
 /* job */
-bs_dest->in_use = bs_src->in_use;
 bs_dest->job= bs_src->job;
 
 /* keep the same entry in bdrv_states */
@@ -1534,7 +1536,7 @@ void bdrv_swap(BlockDriverState *bs_new, BlockDriverState 
*bs_old)
 assert(bs_new->dirty_bitmap == NULL);
 assert(bs_new->job == NULL);
 assert(bs_new->dev == NULL);
-assert(bs_new->in_use == 0);
+assert(bs_new->refcount == 0);
 assert(bs_new->io_limits_enabled == false);
 assert(bs_new->block_timer == NULL);
 
@@ -1553,7 +1555,7 @@ void bdrv_swap(BlockDriverState *bs_new, BlockDriverState 
*bs_old)
 /* Check a few fields that should remain attached to the device */
 assert(bs_new->dev == NULL);
 assert(bs_new->job == NULL);
-assert(bs_new->in_use == 0);
+assert(bs_new->refcount == 0);
 assert(bs_new->io_limits_enabled == false);
 assert(bs_new->block_timer == NULL);
 
@@ -1590,7 +1592,7 @@ void bdrv_delete(BlockDriverState *bs)
 {
 assert(!bs->dev);
 assert(!bs->job);
-assert(!bs->in_use);
+assert(!bs->refcount);
 
 /* remove from list, if necessary */
 bdrv_make_anon(bs);
@@ -4360,15 +4362,20 @@ int64_t bdrv_get_dirty_count(BlockDriverState *bs)
 }
 }
 
-void bdrv_set_in_use(BlockDriverState *bs, int in_use)
+void bdrv_put_ref(BlockDriverState *bs)
+{
+assert(bs->refcount > 0);
+bs->refcount--;
+}
+
+void bdrv_get_ref(BlockDriverState *bs)
 {
-assert(bs->in_use != in_use);
-bs->in_use = in_use;
+bs->refcount++;
 }
 
 int bdrv_in_use(BlockDriverState *bs)
 {
-return bs->in_use;
+return bs->refcount > 0;
 }
 
 void bdrv_iostatus_enable(BlockDriverState *bs)
diff --git a/blockjob.c b/blockjob.c
index ca80df1..a841a66 100644
--- a/blockjob.c
+++ b/blockjob.c
@@ -45,7 +45,7 @@ void *block_job_create(const BlockJobType *job_type, 
BlockDriverState *bs,
 error_set(errp, QERR_DEVICE_IN_USE, bdrv_get_device_name(bs));
 return NULL;
 }
-bdrv_set_in_use(bs, 1);
+bdrv_get_ref(bs);
 
 job = g_malloc0(job_type->instance_size);
 job->job_type  = job_type;
@@ -63,7 +63,7 @@ void *block_job_create(const BlockJobType *job_type, 
BlockDriverState *bs,
 if (error_is_set(&local_err)) {
 bs->job = NULL;
 g_free(job);
-bdrv_set_in_use(bs, 0);
+bdrv_put_ref(bs);
 error_propagate(errp, local_err);
 return NULL;
 }
@@ -79,7 +79,7 @@ void block_job_completed(BlockJob *job, int ret)
 job->cb(job->opaque, ret);
 bs->job = NULL;
 g_free(job);
-bdrv_set_in_use(bs, 0);
+bdrv_put_ref(bs);
 }
 
 void block_job_set_speed(BlockJob *job, int64_t speed, Error **errp)
diff --git a/hw/block/dataplane/virtio-blk.c b/hw/block/dataplane/virtio-blk.c
index 0356665..9893a11 100644
--- a/hw/block/dataplane/virtio-blk.c
+++ b/hw/block/dataplane/virtio-blk.c
@@ -431,7 +431,7 @@ bool virtio_blk_data_plane_create(VirtIODevice *vdev, 
VirtIOBlkConf *blk,
 s->blk = blk;
 
 /* Prevent block operations that conflict with data plane thread */
-bdrv_set_in_use(blk->conf.bs, 1);
+bdrv_get_ref(blk->conf.bs);
 
 error_setg(&s->migration_blocker,
 "x-data-p

Re: [Qemu-devel] [PATCH 24/24] hw/[u-x]*: pass owner to memory_region_init_io

2013-07-01 Thread Paolo Bonzini
Il 02/07/2013 01:42, Andreas Färber ha scritto:
> I happened to notice that the scripted approach you describe in the
> cover letter causes some unnecessary indirection here:
> In this hunk a human could've just supplied the function argument obj.
> But since OBJECT() is not a dynamic cast and f is referenced on the same
> line for the MemoryRegion itself, I guess there is no harm in always
> using OBJECT(f) for simplicity.

The conversion actually wasn't scripted, only the review.  I used
OBJECT(f) because it was easier to think about, and any mistakes
(opaques that are not QOM objects) would be caught during the scripted
review.

Paolo



[Qemu-devel] Biweekly upstream qemu-kvm test report - July 1st, 2013

2013-07-01 Thread chandrashekar shastri


Adding Libvirt list.

Thanks,
Shastri

 Original Message 
Subject:Biweekly upstream qemu-kvm test report - July 1st, 2013
Date:   Mon, 01 Jul 2013 19:45:32 +0530
From:   chandrashekar shastri 
To: 	qemu-devel@nongnu.org, ltc-...@lists.linux.ibm.com, 
virt-test-de...@redhat.com




Hi,

Please find the status of the upstream testing:

Kernel :  3.10.0-rc5+
Qemu  :  1.5.50
Libvirt : 1.0.6

Total number of bugs filed :  6

Bugs filed in this week : 5

Qemu Bugs in Launchpad :

1)  1192499 - virsh migration copy-storage-all fails with "Unable to
read from monitor: Connection reset by peer"
2)  1192847 - NMI watchdog fails to increment the NMI counter in
/proc/interrupts
3)  1195170 - cpu hot-add doesn't work with upstream qemu 1.5.50

Libvirt Bugs Redhat Bugzilla:

1) 979260 - cpu hot-add doesn't work with upstream libvirt 1.0.6 + qemu
1.5.50
2) 979360 - Libvirt fails to Bootstrap fails for local gnulib with 1.0.

Features tested in this week:

 1. NMI Watchdog
 2. Live Migration (with and without shared Storage)
 3. CPU hotplug
 4. QMP with latest qemu

Features that will be taken up in the next cycle:

1. Chardev hotplug
2. VirtIO-scsi
3. Virt Guest Suspend Hibernate

Thanks,
Shastri






[Qemu-devel] Wayland support

2013-07-01 Thread Yu, Max A
Hi,

Can QEMU support wayland? I'd like to know if anybody have ideas/solutions on 
that.

Thanks,
Max



Re: [Qemu-devel] [PATCH 02/17] pseries: rework XICS

2013-07-01 Thread Alexey Kardashevskiy
On 07/02/2013 10:21 AM, Alexander Graf wrote:
> 
> On 02.07.2013, at 02:06, David Gibson wrote:
> 
>> On Thu, Jun 27, 2013 at 10:17:19PM +1000, Alexey Kardashevskiy wrote:
>>> On 06/27/2013 09:47 PM, David Gibson wrote:
 On Thu, Jun 27, 2013 at 04:45:45PM +1000, Alexey Kardashevskiy wrote:
> Currently XICS interrupt controller is not a QEMU device. As we are going
> to support in-kernel emulated XICS which is a part of KVM, it make
> sense not to extend the existing XICS and have multiple KVM stub functions
> but to create yet another device and share pieces between fully emulated
> XICS and in-kernel XICS.

 Hmm.  So, I think changing the xics to the qdev/qom framework is a
 generally good idea.  But I'm not convinced its a good idea to have
 different devices for the kernel and non-kernel xics.
>>>
>>> The idea came from Alex Graf, this is already done for openpic/openpic-kvm.
>>> The normal practice is to move ioctls to KVM to KVM code and provide empty
>>> stubs for non-KVM case. There were too many so having a separate xics-kvm
>>> is kind of help.
>>>
>>>
 Won't that
 prevent migrating from a system with a kernel xics to one without, or
 vice versa?
>>>
>>> Mmm. Do we care much about that?...
>>
>> Enough to avoid making it impossible by design.
> 
> We went that route with x86 too after lots of hassle trying to shoehorn the 
> in-kernel APIC into the emulation device. It's more hassle than gain.

At the moment it can be supported at no cost so next time I'll post it with
matched vmsd.



>>> At the moment it is not supported that as VMStateDescription have different
>>> .name for xics and xics-kvm but easy to fix. And we do not pass a device to
>>> vmstate_register so that must be it.
>>
>> Ok, if you can make the ids in the vmsd match, then that should be ok.
> 
> I really just wouldn't bother too much about it. Sooner or later QEMU-XICS is 
> going to be a legacy and debug only option.


-- 
Alexey



Re: [Qemu-devel] [PATCH RFC qom-cpu 01/41] log: Change log_cpu_state[_mask]() argument to CPUState

2013-07-01 Thread Andreas Färber
Am 29.06.2013 22:01, schrieb Andreas Färber:
> diff --git a/target-microblaze/helper.c b/target-microblaze/helper.c
> index 01d4bbf..86aad6a 100644
> --- a/target-microblaze/helper.c
> +++ b/target-microblaze/helper.c
> @@ -152,7 +152,7 @@ void mb_cpu_do_interrupt(CPUState *cs)
>"hw exception at pc=%x ear=%x esr=%x iflags=%x\n",
>env->sregs[SR_PC], env->sregs[SR_EAR],
>env->sregs[SR_ESR], env->iflags);
> -log_cpu_state_mask(CPU_LOG_INT, env, 0);
> +log_cpu_state_mask(CPU_LOG_INT, CPU(cpu), 0);
>  env->iflags &= ~(IMM_FLAG | D_FLAG);
>  env->sregs[SR_PC] = cpu->base_vectors + 0x20;
>  break;
> @@ -175,7 +175,7 @@ void mb_cpu_do_interrupt(CPUState *cs)
>"bimm exception at pc=%x iflags=%x\n",
>env->sregs[SR_PC], env->iflags);
>  env->regs[17] -= 4;
> -log_cpu_state_mask(CPU_LOG_INT, env, 0);
> +log_cpu_state_mask(CPU_LOG_INT, CPU(cpu), 0);
>  }
>  } else if (env->iflags & IMM_FLAG) {
>  D(qemu_log("IMM_FLAG set at exception\n"));
> @@ -192,7 +192,7 @@ void mb_cpu_do_interrupt(CPUState *cs)
>  qemu_log_mask(CPU_LOG_INT,
>"exception at pc=%x ear=%x iflags=%x\n",
>env->sregs[SR_PC], env->sregs[SR_EAR], 
> env->iflags);
> -log_cpu_state_mask(CPU_LOG_INT, env, 0);
> +log_cpu_state_mask(CPU_LOG_INT, CPU(cpu), 0);
>  env->iflags &= ~(IMM_FLAG | D_FLAG);
>  env->sregs[SR_PC] = cpu->base_vectors + 0x20;
>  break;
> @@ -222,7 +222,7 @@ void mb_cpu_do_interrupt(CPUState *cs)
>   env->sregs[SR_PC], env->sregs[SR_MSR], t, 
> env->iflags,
>   sym);
>  
> -log_cpu_state(env, 0);
> +log_cpu_state(CPU(cpu), 0);
>  }
>  }
>  #endif
> @@ -236,7 +236,7 @@ void mb_cpu_do_interrupt(CPUState *cs)
>  
>  env->regs[14] = env->sregs[SR_PC];
>  env->sregs[SR_PC] = cpu->base_vectors + 0x10;
> -//log_cpu_state_mask(CPU_LOG_INT, env, 0);
> +//log_cpu_state_mask(CPU_LOG_INT, CPU(cpu), 0);
>  break;
>  
>  case EXCP_BREAK:
> @@ -247,7 +247,7 @@ void mb_cpu_do_interrupt(CPUState *cs)
>  qemu_log_mask(CPU_LOG_INT,
>  "break at pc=%x msr=%x %x iflags=%x\n",
>  env->sregs[SR_PC], env->sregs[SR_MSR], t, 
> env->iflags);
> -log_cpu_state_mask(CPU_LOG_INT, env, 0);
> +log_cpu_state_mask(CPU_LOG_INT, CPU(cpu), 0);
>  env->sregs[SR_MSR] &= ~(MSR_VMS | MSR_UMS | MSR_VM | MSR_UM);
>  env->sregs[SR_MSR] |= t;
>  env->sregs[SR_MSR] |= MSR_BIP;

Re-reviewing this patch for my X86CPU changes, I noticed all these could
use "cs" rather than "CPU(cpu)" - fixed and applied along with the
following one to qom-cpu:
https://github.com/afaerber/qemu-cpu/commits/qom-cpu

> diff --git a/target-microblaze/translate.c b/target-microblaze/translate.c
> index 54f439f..f9acdb1 100644
> --- a/target-microblaze/translate.c
> +++ b/target-microblaze/translate.c
> @@ -1741,6 +1741,9 @@ static void
>  gen_intermediate_code_internal(CPUMBState *env, TranslationBlock *tb,
> int search_pc)
>  {
> +#if !SIM_COMPAT
> +MicroBlazeCPU *cpu = mb_env_get_cpu(env);
> +#endif
>  uint16_t *gen_opc_end;
>  uint32_t pc_start;
>  int j, lj;
[snip]

This hunk would benefit from the gen_intermediate_code_internal()
argument type change prompted by gdbstub later in this series, so I
intend to prepend those once v2 is done - inline is missing here.
Trying to avoid resending a 41-patch series. ;)

TBD: Follow up with patches for the x86 and ppc logging macros
respectively before I forget about them.

Andreas

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



Re: [Qemu-devel] [PATCH qom-cpu v3 00/14] QOM CPUState, part 10: CPU loops

2013-07-01 Thread Andreas Färber
Am 26.06.2013 19:35, schrieb Andreas Färber:
> Hello,
> 
> This series changes cpu_single_env, first_cpu, next_cpu and thread_env to 
> CPUState.
> 
> v3 defers the removal of qemu_for_each_cpu() and drops CPU_INTERRUPT_* 
> changes,
> renames cpu_single_cpu to current_cpu, while enforcing consistent use of
> ENV_GET_CPU() and CPUArchState macros.
> 
> Available for testing at:
> git://github.com/afaerber/qemu-cpu.git qom-cpu-10.v3
> https://github.com/afaerber/qemu-cpu/commits/qom-cpu-10.v3

This v3 didn't spark new controversies, and Alex and Peter had agreed to
the remaining obj-y -> common-obj-y device changes, so I'm applying the
rebased version as indicated (still builds on ppc, too) to qom-cpu, well
aware that I will need to rebase PReP and x86 KVM first_cpu changes on
top of Paolo's memory part 4 series.

https://github.com/afaerber/qemu-cpu/commits/qom-cpu

Andreas

[...]
> Andreas Färber (14):
>   kvm: Free current_cpu identifier
>   cpu: Replace cpu_single_env with CPUState current_cpu
>   kvm: Change kvm_remove_all_breakpoints() argument to CPUState
>   linux-user: Clean up do_syscall() Coding Style for TARGET_NR_exit
>   cpu: Make first_cpu and next_cpu CPUState
>   linux-user: Change thread_env to CPUState
>   bsd-user: Change thread_env to CPUState
>   intc/arm_gic: Build arm_gic only once
>   intc/openpic: Build openpic only once
>   timer/arm_mptimer: Build arm_mptimer only once
>   target-ppc: Don't overuse ENV_GET_CPU()
>   target-s390x: Don't overuse ENV_GET_CPU()
>   target-s390x: Change handle_{hypercall,diag}() argument to S390CPU
>   target-i386: Don't overuse CPUArchState
> 
>  bsd-user/elfload.c|   6 +-
>  bsd-user/main.c   |   6 +-
>  bsd-user/qemu.h   |   2 +-
>  cpu-exec.c|  13 ++--
>  cpus.c| 167 
> --
>  cputlb.c  |   4 +-
>  dump.c|  16 ++---
>  exec.c|  55 ---
>  gdbstub.c |  35 ++
>  hw/alpha/typhoon.c|  16 ++---
>  hw/arm/boot.c |  10 +--
>  hw/arm/exynos4_boards.c   |   4 +-
>  hw/arm/highbank.c |   2 +-
>  hw/arm/pxa2xx.c   |   3 +-
>  hw/arm/realview.c |   2 +-
>  hw/arm/vexpress.c |   2 +-
>  hw/arm/xilinx_zynq.c  |   2 +-
>  hw/i386/kvm/clock.c   |  12 ++--
>  hw/i386/kvmvapic.c|  19 --
>  hw/i386/pc.c  |  28 
>  hw/i386/pc_piix.c |   3 +-
>  hw/intc/Makefile.objs |   4 +-
>  hw/intc/arm_gic.c |   4 +-
>  hw/intc/armv7m_nvic.c |  11 ++-
>  hw/intc/openpic.c |   9 +--
>  hw/intc/sh_intc.c |   5 +-
>  hw/isa/lpc_ich9.c |   2 +-
>  hw/mips/mips_fulong2e.c   |   6 +-
>  hw/mips/mips_jazz.c   |   6 +-
>  hw/mips/mips_malta.c  |   9 +--
>  hw/misc/vmport.c  |  26 +---
>  hw/ppc/mpc8544_guts.c |   3 +-
>  hw/ppc/ppc.c  |  12 ++--
>  hw/ppc/prep.c |  12 ++--
>  hw/ppc/spapr.c|  27 
>  hw/sparc/sun4m.c  |   5 +-
>  hw/timer/Makefile.objs|   2 +-
>  hw/timer/arm_mptimer.c|   9 ++-
>  include/exec/cpu-all.h|   4 --
>  include/exec/cpu-defs.h   |   1 -
>  include/hw/ppc/ppc.h  |   2 -
>  include/hw/ppc/ppc_e500.h |   6 ++
>  include/qom/cpu.h |   8 +++
>  include/sysemu/kvm.h  |  10 +--
>  kvm-all.c |  53 ---
>  kvm-stub.c|   6 +-
>  linux-user/elfload.c  |  21 +++---
>  linux-user/linuxload.c|   3 +-
>  linux-user/main.c |  16 ++---
>  linux-user/qemu.h |   2 +-
>  linux-user/signal.c   |  12 ++--
>  linux-user/syscall.c  |  80 +++---
>  memory.c  |  10 ++-
>  memory_mapping.c  |  16 ++---
>  monitor.c |   4 +-
>  target-i386/arch_dump.c   |  17 +++--
>  target-i386/helper.c  |  15 +++--
>  target-i386/kvm.c |   8 ++-
>  target-i386/misc_helper.c |   2 +-
>  target-mips/op_helper.c   |  25 ---
>  target-ppc/excp_helper.c  |   9 ++-
>  target-ppc/kvm.c  |   2 +-
>  target-ppc/mmu_helper.c   |   2 +-
>  target-s390x/kvm.c|  14 ++--
>  translate-all.c   |  32 +
>  user-exec.c   |   9 +--
>  66 files changed, 500 insertions(+), 448 deletions(-)
>  create mode 100644 include/hw/ppc/ppc_e500.h
> 


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



Re: [Qemu-devel] [PATCH 02/17] pseries: rework XICS

2013-07-01 Thread Alexander Graf

On 02.07.2013, at 02:06, David Gibson wrote:

> On Thu, Jun 27, 2013 at 10:17:19PM +1000, Alexey Kardashevskiy wrote:
>> On 06/27/2013 09:47 PM, David Gibson wrote:
>>> On Thu, Jun 27, 2013 at 04:45:45PM +1000, Alexey Kardashevskiy wrote:
 Currently XICS interrupt controller is not a QEMU device. As we are going
 to support in-kernel emulated XICS which is a part of KVM, it make
 sense not to extend the existing XICS and have multiple KVM stub functions
 but to create yet another device and share pieces between fully emulated
 XICS and in-kernel XICS.
>>> 
>>> Hmm.  So, I think changing the xics to the qdev/qom framework is a
>>> generally good idea.  But I'm not convinced its a good idea to have
>>> different devices for the kernel and non-kernel xics.
>> 
>> The idea came from Alex Graf, this is already done for openpic/openpic-kvm.
>> The normal practice is to move ioctls to KVM to KVM code and provide empty
>> stubs for non-KVM case. There were too many so having a separate xics-kvm
>> is kind of help.
>> 
>> 
>>> Won't that
>>> prevent migrating from a system with a kernel xics to one without, or
>>> vice versa?
>> 
>> Mmm. Do we care much about that?...
> 
> Enough to avoid making it impossible by design.

We went that route with x86 too after lots of hassle trying to shoehorn the 
in-kernel APIC into the emulation device. It's more hassle than gain.

> 
>> At the moment it is not supported that as VMStateDescription have different
>> .name for xics and xics-kvm but easy to fix. And we do not pass a device to
>> vmstate_register so that must be it.
> 
> Ok, if you can make the ids in the vmsd match, then that should be ok.

I really just wouldn't bother too much about it. Sooner or later QEMU-XICS is 
going to be a legacy and debug only option.


Alex




Re: [Qemu-devel] [PATCH 02/17] pseries: rework XICS

2013-07-01 Thread David Gibson
On Thu, Jun 27, 2013 at 10:17:19PM +1000, Alexey Kardashevskiy wrote:
> On 06/27/2013 09:47 PM, David Gibson wrote:
> > On Thu, Jun 27, 2013 at 04:45:45PM +1000, Alexey Kardashevskiy wrote:
> >> Currently XICS interrupt controller is not a QEMU device. As we are going
> >> to support in-kernel emulated XICS which is a part of KVM, it make
> >> sense not to extend the existing XICS and have multiple KVM stub functions
> >> but to create yet another device and share pieces between fully emulated
> >> XICS and in-kernel XICS.
> > 
> > Hmm.  So, I think changing the xics to the qdev/qom framework is a
> > generally good idea.  But I'm not convinced its a good idea to have
> > different devices for the kernel and non-kernel xics.
> 
> The idea came from Alex Graf, this is already done for openpic/openpic-kvm.
> The normal practice is to move ioctls to KVM to KVM code and provide empty
> stubs for non-KVM case. There were too many so having a separate xics-kvm
> is kind of help.
> 
> 
> > Won't that
> > prevent migrating from a system with a kernel xics to one without, or
> > vice versa?
> 
> Mmm. Do we care much about that?...

Enough to avoid making it impossible by design.

> At the moment it is not supported that as VMStateDescription have different
> .name for xics and xics-kvm but easy to fix. And we do not pass a device to
> vmstate_register so that must be it.

Ok, if you can make the ids in the vmsd match, then that should be ok.

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


pgp7HrfXMc7Gk.pgp
Description: PGP signature


Re: [Qemu-devel] Significant slowdown after qemu-kvm-1.2.0

2013-07-01 Thread Andreas Färber
Hi,

Am 02.07.2013 00:24, schrieb jinho hwang:
> Thank you for your reply. I tried qemu-1.5.0 with --enable-kvm, but
> there is still a big difference between qemu-kvm-1.2.0 and qemu-1.5.0.
> They both use the same command line to create VM. Am I missing something
> in the command-line?
> 
> sudo qemu-system-x86_64 -name vm -m 1g -hda /home/jinho/virt/vms/vm1.img
> -device e1000,netdev=net0,mac=00:0c:29:f0:bc:33 -netdev tap,id=net0 -vnc :1

Yes, you are still missing -enable-kvm on the QEMU command line, or
alternatively the more modern -machine accel=kvm.

Regards,
Andreas

P.S. Please avoid top-posting and HTML on the mailing list.

> On Mon, Jul 1, 2013 at 5:54 PM, Paolo Bonzini  > wrote:
> 
> Il 01/07/2013 23:51, jinho hwang ha scritto:
> > Hi Guys,
> >
> > I am new to kvm development (used to work on Xen). I used
> qemu-kvm-1.2.0
> > first, and then due to pci memory size (x64 bit support), I switched
> > from 1.2.0 to qemu-kvm-1.5.0 (same for 1.3.0~).
> 
> There is no qemu-kvm 1.5.0.  You are using qemu 1.5.0.
> 
> > After that, my VM slows
> > down significantly including booting and execution. Also, sometimes
> > kernel messages "CPU stuck for x seconds" show in dmesg. I think CPU
> > scheduling has been changed or should be set up properly, but I
> have no
> > clue for now. Can anyone help me to figure out this? I really need
> some
> > fast VMs as I used to run with qemu-kvm-1.2.0.
> >
> > I am currently running ubuntu-12.10_64 in VM, and my configure was
> >
> > ./configure --prefix=/usr
> --target-list=x86_64-linux-user,x86_64-softmmu
> >
> > sudo qemu-system-x86_64 -name vm -m 1g -hda
> /home/jinho/virt/vms/vm1.img
> > -device e1000,netdev=net0,mac=00:0c:29:f0:bc:33 -netdev
> tap,id=net0 -vnc
> > 135.207.127.181:1 
> 
> 
> You are not using kvm.  Add --enable-kvm to the command line.
> 
> Paolo
> 


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



Re: [Qemu-devel] [PATCH 24/24] hw/[u-x]*: pass owner to memory_region_init_io

2013-07-01 Thread Andreas Färber
Am 25.06.2013 16:15, schrieb Paolo Bonzini:
> Signed-off-by: Paolo Bonzini 
> ---
>  hw/usb/hcd-ehci-sysbus.c   |  2 +-
>  hw/usb/hcd-ehci.c  |  8 
>  hw/usb/hcd-ohci.c  |  3 ++-
>  hw/usb/hcd-uhci.c  |  4 +++-
>  hw/usb/hcd-xhci.c  | 12 ++--
>  hw/virtio/virtio-pci.c |  4 ++--
>  hw/watchdog/wdt_i6300esb.c |  3 ++-
>  hw/xen/xen_apic.c  |  4 ++--
>  hw/xen/xen_platform.c  |  7 ---
>  hw/xen/xen_pt.c|  4 ++--
>  hw/xen/xen_pt_msi.c|  3 ++-
>  hw/xtensa/xtensa_lx60.c|  2 +-
>  12 files changed, 31 insertions(+), 25 deletions(-)
> 
> diff --git a/hw/usb/hcd-ehci-sysbus.c b/hw/usb/hcd-ehci-sysbus.c
> index 76b4c05..54147b5 100644
> --- a/hw/usb/hcd-ehci-sysbus.c
> +++ b/hw/usb/hcd-ehci-sysbus.c
> @@ -173,7 +173,7 @@ static void fusbh200_ehci_init(Object *obj)
>  FUSBH200EHCIState *f = FUSBH200_EHCI(obj);
>  EHCIState *s = &i->ehci;
>  
> -memory_region_init_io(&f->mem_vendor, NULL, &fusbh200_ehci_mmio_ops, s,
> +memory_region_init_io(&f->mem_vendor, OBJECT(f), 
> &fusbh200_ehci_mmio_ops, s,
>"fusbh200", 0x4c);
>  memory_region_add_subregion(&s->mem,
>  s->opregbase + s->portscbase + 4 * s->portnr,
[snip]

I happened to notice that the scripted approach you describe in the
cover letter causes some unnecessary indirection here:
In this hunk a human could've just supplied the function argument obj.
But since OBJECT() is not a dynamic cast and f is referenced on the same
line for the MemoryRegion itself, I guess there is no harm in always
using OBJECT(f) for simplicity.

Regards,
Andreas

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



Re: [Qemu-devel] [PATCH 21/24] hw/p*: pass owner to memory_region_init_io

2013-07-01 Thread Andreas Färber
Am 25.06.2013 16:15, schrieb Paolo Bonzini:
> Signed-off-by: Paolo Bonzini 

Needs an update after ppc-next merge, cf. attached.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
diff --cc hw/ppc/mpc8544_guts.c
index 56249b4,6448772..000
--- a/hw/ppc/mpc8544_guts.c
+++ b/hw/ppc/mpc8544_guts.c
@@@ -114,14 -108,24 +114,14 @@@ static const MemoryRegionOps mpc8544_gu
  },
  };
  
 -static int mpc8544_guts_initfn(SysBusDevice *dev)
 -{
 -GutsState *s;
 -
 -s = FROM_SYSBUS(GutsState, SYS_BUS_DEVICE(dev));
 -
 -memory_region_init_io(&s->iomem, OBJECT(s), &mpc8544_guts_ops, s,
 -  "mpc6544.guts", MPC8544_GUTS_MMIO_SIZE);
 -sysbus_init_mmio(dev, &s->iomem);
 -
 -return 0;
 -}
 -
 -static void mpc8544_guts_class_init(ObjectClass *klass, void *data)
 +static void mpc8544_guts_initfn(Object *obj)
  {
 -SysBusDeviceClass *k = SYS_BUS_DEVICE_CLASS(klass);
 +SysBusDevice *d = SYS_BUS_DEVICE(obj);
 +GutsState *s = MPC8544_GUTS(obj);
  
- memory_region_init_io(&s->iomem, NULL, &mpc8544_guts_ops, s,
 -k->init = mpc8544_guts_initfn;
++memory_region_init_io(&s->iomem, obj, &mpc8544_guts_ops, s,
 +  "mpc8544.guts", MPC8544_GUTS_MMIO_SIZE);
 +sysbus_init_mmio(d, &s->iomem);
  }
  
  static const TypeInfo mpc8544_guts_info = {


Re: [Qemu-devel] [PATCH 18/24] hw/i*: pass owner to memory_region_init_io

2013-07-01 Thread Andreas Färber
Am 25.06.2013 16:14, schrieb Paolo Bonzini:
> Signed-off-by: Paolo Bonzini 

Needs update after ppc-next merge, cf. attached.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
diff --cc hw/intc/openpic.c
index b9e025f,d324b1e..000
--- a/hw/intc/openpic.c
+++ b/hw/intc/openpic.c
@@@ -1527,17 -1526,9 +1527,17 @@@ static void map_list(OpenPICState *opp
  }
  }
  
 -static int openpic_init(SysBusDevice *dev)
 +static void openpic_init(Object *obj)
  {
 -OpenPICState *opp = FROM_SYSBUS(typeof (*opp), dev);
 +OpenPICState *opp = OPENPIC(obj);
 +
- memory_region_init(&opp->mem, NULL, "openpic", 0x4);
++memory_region_init(&opp->mem, obj, "openpic", 0x4);
 +}
 +
 +static void openpic_realize(DeviceState *dev, Error **errp)
 +{
 +SysBusDevice *d = SYS_BUS_DEVICE(dev);
 +OpenPICState *opp = OPENPIC(dev);
  int i, j;
  int list_count = 0;
  static const MemReg list_le[] = {
diff --git a/hw/intc/openpic_kvm.c b/hw/intc/openpic_kvm.c
index 6775879..2f73193 100644
--- a/hw/intc/openpic_kvm.c
+++ b/hw/intc/openpic_kvm.c
@@ -155,7 +155,7 @@ static void kvm_openpic_init(Object *obj)
 {
 KVMOpenPICState *opp = KVM_OPENPIC(obj);
 
-memory_region_init_io(&opp->mem, &kvm_openpic_mem_ops, opp,
+memory_region_init_io(&opp->mem, obj, &kvm_openpic_mem_ops, opp,
   "kvm-openpic", 0x4);
 }
 


Re: [Qemu-devel] [PATCH v2 01/11] memory: add owner argument to initialization functions

2013-07-01 Thread Andreas Färber
Am 02.07.2013 01:16, schrieb Andreas Färber:
> Am 28.06.2013 18:58, schrieb Paolo Bonzini:
>> Signed-off-by: Paolo Bonzini 
> 
> Since the ppc-next merge, something like the attached is necessary for
> iommu-for-anythony branch to apply to master.

Add to that the ppc KVM-only:

diff --git a/hw/intc/openpic_kvm.c b/hw/intc/openpic_kvm.c
index 6775879..dc08031 100644
--- a/hw/intc/openpic_kvm.c
+++ b/hw/intc/openpic_kvm.c
@@ -155,7 +155,7 @@ static void kvm_openpic_init(Object *obj)
 {
 KVMOpenPICState *opp = KVM_OPENPIC(obj);

-memory_region_init_io(&opp->mem, &kvm_openpic_mem_ops, opp,
+memory_region_init_io(&opp->mem, NULL, &kvm_openpic_mem_ops, opp,
   "kvm-openpic", 0x4);
 }


Andreas

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



Re: [Qemu-devel] [PATCH v2 01/11] memory: add owner argument to initialization functions

2013-07-01 Thread Andreas Färber
Am 28.06.2013 18:58, schrieb Paolo Bonzini:
> Signed-off-by: Paolo Bonzini 

Since the ppc-next merge, something like the attached is necessary for
iommu-for-anythony branch to apply to master.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
diff --cc hw/intc/openpic.c
index a26c641,5777ece..000
--- a/hw/intc/openpic.c
+++ b/hw/intc/openpic.c
@@@ -1527,17 -1526,9 +1527,17 @@@ static void map_list(OpenPICState *opp
  }
  }
  
 -static int openpic_init(SysBusDevice *dev)
 +static void openpic_init(Object *obj)
  {
 -OpenPICState *opp = FROM_SYSBUS(typeof (*opp), dev);
 +OpenPICState *opp = OPENPIC(obj);
 +
- memory_region_init(&opp->mem, "openpic", 0x4);
++memory_region_init(&opp->mem, NULL, "openpic", 0x4);
 +}
 +
 +static void openpic_realize(DeviceState *dev, Error **errp)
 +{
 +SysBusDevice *d = SYS_BUS_DEVICE(dev);
 +OpenPICState *opp = OPENPIC(dev);
  int i, j;
  int list_count = 0;
  static const MemReg list_le[] = {
diff --cc hw/ppc/mac_newworld.c
index 3badfa3,28d0f7e..000
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@@ -289,13 -279,10 +289,13 @@@ static void ppc_core99_init(QEMUMachine
  /* Register 8 MB of ISA IO space */
  isa_mmio_init(0xf200, 0x0080);
  
 -/* UniN init */
 -memory_region_init_io(unin_memory, NULL, &unin_ops, NULL, "unin", 0x1000);
 +/* UniN init: XXX should be a real device */
- memory_region_init_io(unin_memory, &unin_ops, token, "unin", 0x1000);
++memory_region_init_io(unin_memory, NULL, &unin_ops, token, "unin", 0x1000);
  memory_region_add_subregion(get_system_memory(), 0xf800, unin_memory);
  
- memory_region_init_io(unin2_memory, &unin_ops, token, "unin", 0x1000);
++memory_region_init_io(unin2_memory, NULL, &unin_ops, token, "unin", 0x1000);
 +memory_region_add_subregion(get_system_memory(), 0xf300, unin2_memory);
 +
  openpic_irqs = g_malloc0(smp_cpus * sizeof(qemu_irq *));
  openpic_irqs[0] =
  g_malloc0(smp_cpus * sizeof(qemu_irq) * OPENPIC_OUTPUT_NB);
diff --cc hw/ppc/mpc8544_guts.c
index d41f615,9d34fd5..000
--- a/hw/ppc/mpc8544_guts.c
+++ b/hw/ppc/mpc8544_guts.c
@@@ -114,14 -108,24 +114,14 @@@ static const MemoryRegionOps mpc8544_gu
  },
  };
  
 -static int mpc8544_guts_initfn(SysBusDevice *dev)
 +static void mpc8544_guts_initfn(Object *obj)
  {
 -GutsState *s;
 -
 -s = FROM_SYSBUS(GutsState, SYS_BUS_DEVICE(dev));
 +SysBusDevice *d = SYS_BUS_DEVICE(obj);
 +GutsState *s = MPC8544_GUTS(obj);
  
- memory_region_init_io(&s->iomem, &mpc8544_guts_ops, s,
+ memory_region_init_io(&s->iomem, NULL, &mpc8544_guts_ops, s,
 -  "mpc6544.guts", MPC8544_GUTS_MMIO_SIZE);
 -sysbus_init_mmio(dev, &s->iomem);
 -
 -return 0;
 -}
 -
 -static void mpc8544_guts_class_init(ObjectClass *klass, void *data)
 -{
 -SysBusDeviceClass *k = SYS_BUS_DEVICE_CLASS(klass);
 -
 -k->init = mpc8544_guts_initfn;
 +  "mpc8544.guts", MPC8544_GUTS_MMIO_SIZE);
 +sysbus_init_mmio(d, &s->iomem);
  }
  
  static const TypeInfo mpc8544_guts_info = {
diff --git a/hw/misc/macio/macio.c b/hw/misc/macio/macio.c
index 787a4c7..5930ccd 100644
--- a/hw/misc/macio/macio.c
+++ b/hw/misc/macio/macio.c
@@ -104,11 +104,11 @@ static void macio_escc_legacy_setup(MacIOState *macio_state)
 0xF0, 0xE0,
 };
 
-memory_region_init(escc_legacy, "escc-legacy", 256);
+memory_region_init(escc_legacy, NULL, "escc-legacy", 256);
 for (i = 0; i < ARRAY_SIZE(maps); i += 2) {
 MemoryRegion *port = g_new(MemoryRegion, 1);
-memory_region_init_alias(port, "escc-legacy-port", macio_state->escc_mem,
- maps[i+1], 0x2);
+memory_region_init_alias(port, NULL, "escc-legacy-port",
+ macio_state->escc_mem, maps[i + 1], 0x2);
 memory_region_add_subregion(escc_legacy, maps[i], port);
 }
 


[Qemu-devel] Re: Significant slowdown after qemu-kvm-1.2.0

2013-07-01 Thread jinho hwang
Hi Paolo,

Thank you for your reply. I tried qemu-1.5.0 with --enable-kvm, but there
is still a big difference between qemu-kvm-1.2.0 and qemu-1.5.0. They both
use the same command line to create VM. Am I missing something in the
command-line?

sudo qemu-system-x86_64 -name vm -m 1g -hda /home/jinho/virt/vms/vm1.img
-device e1000,netdev=net0,mac=00:0c:29:f0:bc:33 -netdev tap,id=net0 -vnc :1

Thank you,

Jinho

On Mon, Jul 1, 2013 at 5:54 PM, Paolo Bonzini  wrote:

> Il 01/07/2013 23:51, jinho hwang ha scritto:
> > Hi Guys,
> >
> > I am new to kvm development (used to work on Xen). I used qemu-kvm-1.2.0
> > first, and then due to pci memory size (x64 bit support), I switched
> > from 1.2.0 to qemu-kvm-1.5.0 (same for 1.3.0~).
>
> There is no qemu-kvm 1.5.0.  You are using qemu 1.5.0.
>
> > After that, my VM slows
> > down significantly including booting and execution. Also, sometimes
> > kernel messages "CPU stuck for x seconds" show in dmesg. I think CPU
> > scheduling has been changed or should be set up properly, but I have no
> > clue for now. Can anyone help me to figure out this? I really need some
> > fast VMs as I used to run with qemu-kvm-1.2.0.
> >
> > I am currently running ubuntu-12.10_64 in VM, and my configure was
> >
> > ./configure --prefix=/usr --target-list=x86_64-linux-user,x86_64-softmmu
> >
> > sudo qemu-system-x86_64 -name vm -m 1g -hda /home/jinho/virt/vms/vm1.img
> > -device e1000,netdev=net0,mac=00:0c:29:f0:bc:33 -netdev tap,id=net0 -vnc
> > 135.207.127.181:1 
>
> You are not using kvm.  Add --enable-kvm to the command line.
>
> Paolo
>


[Qemu-devel] [Bug 1196727] [NEW] SLIRP on Windows 7 64-bit host or is it me?

2013-07-01 Thread Kenneth Salerno
Public bug reported:

 Version: 1.5.1 and tried latest in Git, compiled for x86_64 Windows 64-bit
  Host: Windows 7 64-bit
Guest: FreeBSD 9.1 i386, RHEL 6.4 x86_64, SLES 11.2 x86_64, OpenSUSE 12.3 
ppc64, Fedora 18 ppc64
 libiconv: 1.14
glib: 2.28.8
gettext: 0.18.1.1
 pixman: 0.30.0
   libSDL: 1.2.14
   Driver: virtio-net-pci
 Emu: full (non-KVM)

I'm new to Windows 7 64-bit as a host for QEMU (previously I was running
QEMU on Windows XP with no issues) so it could be me, now on Windows 7
SLIRP only works for me connecting internally from the host to the guest
via SLIRP redirect, but any outbound requests from the guest to the
Internet are failing with the following:

if_start...
m_get...
 m = 61f7bd40
ip_input...
 m = 61f7bd40
 m_len = 48
tcp_input...
 m = 61f7bd40  iphlen = 20  inso = 0
tcp_fconnect...
 so = 33e140
 connect()ing, addr.sin_port=80, addr.sin_addr.s_addr=206.190.36.45
 tcp fconnect errno = 10035-Unknown error
icmp_error...
 msrc = 61f7bd40
 msrc_len = 48
 10.0.2.5 to 206.190.36.45
m_get...
 m = 61f7b6c0
ip_output...
 so = 0
 m0 = 61f7b6c0
if_output...
 so = 0
 ifm = 61f7b6c0
if_start...
arp_table_search...
 ip = 0x502000a
 found hw addr = 52:54:00:12:34:56
m_free...
 m = 61f7b6c0
tcp_close...
 tp = 377840
m_free...
 m = 0
m_free...
 m = 61f7bd40

Am I doing something wrong with my Windows host configuration or is this
a bug in SLIRP only on W64 and not W32?

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  SLIRP on Windows 7 64-bit host or is it me?

Status in QEMU:
  New

Bug description:
   Version: 1.5.1 and tried latest in Git, compiled for x86_64 Windows 64-bit
Host: Windows 7 64-bit
  Guest: FreeBSD 9.1 i386, RHEL 6.4 x86_64, SLES 11.2 x86_64, OpenSUSE 12.3 
ppc64, Fedora 18 ppc64
   libiconv: 1.14
  glib: 2.28.8
  gettext: 0.18.1.1
   pixman: 0.30.0
 libSDL: 1.2.14
 Driver: virtio-net-pci
   Emu: full (non-KVM)

  I'm new to Windows 7 64-bit as a host for QEMU (previously I was
  running QEMU on Windows XP with no issues) so it could be me, now on
  Windows 7 SLIRP only works for me connecting internally from the host
  to the guest via SLIRP redirect, but any outbound requests from the
  guest to the Internet are failing with the following:

  if_start...
  m_get...
   m = 61f7bd40
  ip_input...
   m = 61f7bd40
   m_len = 48
  tcp_input...
   m = 61f7bd40  iphlen = 20  inso = 0
  tcp_fconnect...
   so = 33e140
   connect()ing, addr.sin_port=80, addr.sin_addr.s_addr=206.190.36.45
   tcp fconnect errno = 10035-Unknown error
  icmp_error...
   msrc = 61f7bd40
   msrc_len = 48
   10.0.2.5 to 206.190.36.45
  m_get...
   m = 61f7b6c0
  ip_output...
   so = 0
   m0 = 61f7b6c0
  if_output...
   so = 0
   ifm = 61f7b6c0
  if_start...
  arp_table_search...
   ip = 0x502000a
   found hw addr = 52:54:00:12:34:56
  m_free...
   m = 61f7b6c0
  tcp_close...
   tp = 377840
  m_free...
   m = 0
  m_free...
   m = 61f7bd40

  Am I doing something wrong with my Windows host configuration or is
  this a bug in SLIRP only on W64 and not W32?

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



Re: [Qemu-devel] Significant slowdown after qemu-kvm-1.2.0

2013-07-01 Thread Paolo Bonzini
Il 01/07/2013 23:51, jinho hwang ha scritto:
> Hi Guys,
> 
> I am new to kvm development (used to work on Xen). I used qemu-kvm-1.2.0
> first, and then due to pci memory size (x64 bit support), I switched
> from 1.2.0 to qemu-kvm-1.5.0 (same for 1.3.0~).

There is no qemu-kvm 1.5.0.  You are using qemu 1.5.0.

> After that, my VM slows
> down significantly including booting and execution. Also, sometimes
> kernel messages "CPU stuck for x seconds" show in dmesg. I think CPU
> scheduling has been changed or should be set up properly, but I have no
> clue for now. Can anyone help me to figure out this? I really need some
> fast VMs as I used to run with qemu-kvm-1.2.0.
> 
> I am currently running ubuntu-12.10_64 in VM, and my configure was
> 
> ./configure --prefix=/usr --target-list=x86_64-linux-user,x86_64-softmmu
> 
> sudo qemu-system-x86_64 -name vm -m 1g -hda /home/jinho/virt/vms/vm1.img
> -device e1000,netdev=net0,mac=00:0c:29:f0:bc:33 -netdev tap,id=net0 -vnc
> 135.207.127.181:1 

You are not using kvm.  Add --enable-kvm to the command line.

Paolo



[Qemu-devel] Significant slowdown after qemu-kvm-1.2.0

2013-07-01 Thread jinho hwang
Hi Guys,

I am new to kvm development (used to work on Xen). I used qemu-kvm-1.2.0
first, and then due to pci memory size (x64 bit support), I switched from
1.2.0 to qemu-kvm-1.5.0 (same for 1.3.0~). After that, my VM slows down
significantly including booting and execution. Also, sometimes kernel
messages "CPU stuck for x seconds" show in dmesg. I think CPU scheduling
has been changed or should be set up properly, but I have no clue for now.
Can anyone help me to figure out this? I really need some fast VMs as I
used to run with qemu-kvm-1.2.0.

I am currently running ubuntu-12.10_64 in VM, and my configure was

./configure --prefix=/usr --target-list=x86_64-linux-user,x86_64-softmmu

sudo qemu-system-x86_64 -name vm -m 1g -hda /home/jinho/virt/vms/vm1.img
-device e1000,netdev=net0,mac=00:0c:29:f0:bc:33 -netdev tap,id=net0 -vnc
135.207.127.181:1

No particular environmental settings are done.

Thank you,

Jinho


Re: [Qemu-devel] [PATCH RFC qom-cpu 23/41] target-xtensa: Change gen_intermediate_code_internal() arg to XtensaCPU

2013-07-01 Thread Andreas Färber
Am 01.07.2013 20:03, schrieb Richard Henderson:
> On 07/01/2013 10:51 AM, Andreas Färber wrote:
>> I wonder, all targets seem to implement the same pattern of passing a
>> hard-coded bool argument to their internal function.
>>
>> Is there any reason not to have translate-all.c call the function with
>> that true/false directly?
> 
> The idea is to avoid runtime checks for the rare search_pc case.
> 
> Instead we pass constants to inline functions and transform what would be
> runtime checks into compile-time optimized code paths.

Thanks for the explanation!

Not every target seems to be aware of that, I'll put together a patch.

Andreas

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



Re: [Qemu-devel] [PATCHv2 07/11] iscsi: let bdrv_create conditionally zero out the device

2013-07-01 Thread Peter Lieven

Am 01.07.2013 um 22:20 schrieb Paolo Bonzini :

> Il 27/06/2013 15:11, Peter Lieven ha scritto:
>> if the device supports unmapping and unmapped blocks read as
>> zero ensure that the whole device is unmapped and report
>> .has_zero_init = 1 in this case to speed up qemu-img convert.
> 
> This can still take several minutes.  Do you need any special timeout in
> libiscsi?

Not as far as I know. The number of unmapped sectors is bound by 
iscsilun->max_unmap.
This is what the storage will handle in one request. For my storage its the 
internal
page size (15MB). Its very fast. Except for some broken storages I expect that 
unmapping
on a thin-provisioned target means deleting of pointers or something similar 
not actually
writing something to the disks. This it what the SANITIZE command does.

Do you have evidence that it is really taking minutes somewhere?

I tested it with a fully allocated 1TB volume. In my case it was a question of 
about 20 seconds.
I think this was mainly due to the thousands of sync requests that had to be 
sent.

> 
> Perhaps we can have a new "discard_zeroes" field in bdrv_get_info, and
> the unmap functionality can be moved up to qemu-img convert?

Is there any other storage protocol out there that could benefit from it?

Peter




Re: [Qemu-devel] [PATCH 05/30] exec: do not use qemu/tls.h

2013-07-01 Thread Peter Maydell
On 1 July 2013 21:52, Paolo Bonzini  wrote:
> Il 01/07/2013 18:26, Peter Maydell ha scritto:
>> Since the two largest cases are both "cpu_single_env must be TLS"
>> (ie (a) system emulation built with KVM support and (b) linux-user),
>> the set of targets which can be non-TLS is really really small,
>> and I think (1) makes much more sense.
>
> Not many linux-user targets support threads (including not i386).

i386 guest is a comparatively rare case for linux-user (because
most people have an i386 box they can run them on). Also I'm
hoping to get most of the linux-user guests up to the point where
we can just have CONFIG_NPTL be true for all of them -- I have
several patches on-list which are trying to head in that direction.

thanks
-- PMM



Re: [Qemu-devel] [PATCHv2 07/11] iscsi: let bdrv_create conditionally zero out the device

2013-07-01 Thread Paolo Bonzini
Il 27/06/2013 15:11, Peter Lieven ha scritto:
> if the device supports unmapping and unmapped blocks read as
> zero ensure that the whole device is unmapped and report
> .has_zero_init = 1 in this case to speed up qemu-img convert.

This can still take several minutes.  Do you need any special timeout in
libiscsi?

Perhaps we can have a new "discard_zeroes" field in bdrv_get_info, and
the unmap functionality can be moved up to qemu-img convert?

Paolo

> 
> Signed-off-by: Peter Lieven 
> ---
>  block/iscsi.c |   72 
> -
>  1 file changed, 71 insertions(+), 1 deletion(-)
> 
> diff --git a/block/iscsi.c b/block/iscsi.c
> index 92e66a6..621ca40 100644
> --- a/block/iscsi.c
> +++ b/block/iscsi.c
> @@ -1436,7 +1436,8 @@ static int iscsi_truncate(BlockDriverState *bs, int64_t 
> offset)
>  
>  static int iscsi_has_zero_init(BlockDriverState *bs)
>  {
> -return 0;
> +IscsiLun *iscsilun = bs->opaque;
> +return (iscsilun->lbpu && iscsilun->lbprz) ? 1 : 0;
>  }
>  
>  static int iscsi_create(const char *filename, QEMUOptionParameter *options)
> @@ -1446,6 +1447,7 @@ static int iscsi_create(const char *filename, 
> QEMUOptionParameter *options)
>  BlockDriverState bs;
>  IscsiLun *iscsilun = NULL;
>  QDict *bs_options;
> +struct scsi_task *task = NULL;
>  
>  memset(&bs, 0, sizeof(BlockDriverState));
>  
> @@ -1481,7 +1483,75 @@ static int iscsi_create(const char *filename, 
> QEMUOptionParameter *options)
>  }
>  
>  ret = 0;
> +
> +if (iscsilun->lbpu && iscsilun->lbprz) {
> +uint64_t lba = 0;
> +while (lba < iscsilun->num_blocks) {
> +struct scsi_get_lba_status *lbas = NULL;
> +struct scsi_lba_status_descriptor *lbasd = NULL;
> +enum scsi_provisioning_type provisioning;
> +uint32_t nb_sectors;
> +
> +task = iscsi_get_lba_status_sync(iscsilun->iscsi, iscsilun->lun,
> + lba, 8 + 16);
> +if (task == NULL || task->status != SCSI_STATUS_GOOD) {
> +error_report("iSCSI: Failed to get_lba_status on iSCSI lun. 
> %s",
> + iscsi_get_error(iscsilun->iscsi));
> +ret = -EINVAL;
> +goto out;
> +}
> +
> +lbas = scsi_datain_unmarshall(task);
> +if (lbas == NULL) {
> +error_report("iSCSI: failed to unmarshall inquiry datain 
> blob");
> +ret = -EINVAL;
> +goto out;
> +}
> +lbasd = &lbas->descriptors[0];
> +if (lbasd->lba != lba) {
> +ret = -EINVAL;
> +goto out;
> +}
> +nb_sectors = lbasd->num_blocks;
> +provisioning = lbasd->provisioning;
> +scsi_free_scsi_task(task);
> +task = NULL;
> +
> +/* blocks from lba to lba + nb_sectors - 1 are not mapped
> + * and read as zero (lbprz==1) so we can skip them */
> +if (provisioning != SCSI_PROVISIONING_TYPE_MAPPED) {
> +lba += nb_sectors;
> +continue;
> +}
> +
> +uint64_t lba2 = lba + nb_sectors;
> +while (lba < lba2) {
> +struct unmap_list list[1];
> +list[0].lba = lba;
> +list[0].num = iscsilun->max_unmap;
> +if (lba + list[0].num > iscsilun->num_blocks) {
> +list[0].num = iscsilun->num_blocks - lba;
> +}
> +task = iscsi_unmap_sync(iscsilun->iscsi,
> +iscsilun->lun,
> +0, 0, &list[0], 1);
> +if (task == NULL || task->status != SCSI_STATUS_GOOD) {
> +error_report("iSCSI: Failed to unmap data on iSCSI lun. 
> %s",
> + iscsi_get_error(iscsilun->iscsi));
> +ret = -EINVAL;
> +goto out;
> +}
> +scsi_free_scsi_task(task);
> +task = NULL;
> +lba += list[0].num;
> +}
> +}
> +}
> +
>  out:
> +if (task) {
> +scsi_free_scsi_task(task);
> +}
>  if (iscsilun->iscsi != NULL) {
>  iscsi_destroy_context(iscsilun->iscsi);
>  }
> 




Re: [Qemu-devel] [PATCH 1/2] target-alpha: Copy singlestep_enabled to DisasContext

2013-07-01 Thread Andreas Färber
Am 01.07.2013 22:19, schrieb Richard Henderson:
> Prepare for removing env from DisasContext.
> 
> Signed-off-by: Richard Henderson 
> ---
>  target-alpha/translate.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/target-alpha/translate.c b/target-alpha/translate.c
> index 4db16db..b59f919 100644
> --- a/target-alpha/translate.c
> +++ b/target-alpha/translate.c
> @@ -46,6 +46,8 @@ struct DisasContext {
>  int tb_rm;
>  /* Current flush-to-zero setting for this TB.  */
>  int tb_ftz;
> +
> +bool singlestep_enabled;

env->singlestep_enabled is an int containing flags. Below it's only used
as a boolean though, so

Reviewed-by: Andreas Färber 

Thanks,
Andreas

>  };
>  
>  /* Return values from translate_one, indicating the state of the TB.
> @@ -380,7 +382,7 @@ static int use_goto_tb(DisasContext *ctx, uint64_t dest)
>  /* Check for the dest on the same page as the start of the TB.  We
> also want to suppress goto_tb in the case of single-steping and IO.  
> */
>  return (((ctx->tb->pc ^ dest) & TARGET_PAGE_MASK) == 0
> -&& !ctx->env->singlestep_enabled
> +&& !ctx->singlestep_enabled
>  && !(ctx->tb->cflags & CF_LAST_IO));
>  }
>  
> @@ -3396,6 +3398,7 @@ static inline void 
> gen_intermediate_code_internal(CPUAlphaState *env,
>  ctx.env = env;
>  ctx.pc = pc_start;
>  ctx.mem_idx = cpu_mmu_index(env);
> +ctx.singlestep_enabled = env->singlestep_enabled;
>  
>  /* ??? Every TB begins with unset rounding mode, to be initialized on
> the first fp insn of the TB.  Alternately we could define a proper
> @@ -3452,7 +3455,7 @@ static inline void 
> gen_intermediate_code_internal(CPUAlphaState *env,
>  || tcg_ctx.gen_opc_ptr >= gen_opc_end
>  || num_insns >= max_insns
>  || singlestep
> -|| env->singlestep_enabled)) {
> +|| ctx.singlestep_enabled)) {
>  ret = EXIT_PC_STALE;
>  }
>  } while (ret == NO_EXIT);
> @@ -3469,7 +3472,7 @@ static inline void 
> gen_intermediate_code_internal(CPUAlphaState *env,
>  tcg_gen_movi_i64(cpu_pc, ctx.pc);
>  /* FALLTHRU */
>  case EXIT_PC_UPDATED:
> -if (env->singlestep_enabled) {
> +if (ctx.singlestep_enabled) {
>  gen_excp_1(EXCP_DEBUG, 0);
>  } else {
>  tcg_gen_exit_tb(0);

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



Re: [Qemu-devel] [PATCH 05/30] exec: do not use qemu/tls.h

2013-07-01 Thread Paolo Bonzini
Il 01/07/2013 18:26, Peter Maydell ha scritto:
> > I think we should strive for one of these two:
> >
> > (1) all targets are TLS;
> >
> > (2) all targets are non-TLS if this is possible.
> >
> > Either maximizes the homogeneity across platforms.
> 
> Since the two largest cases are both "cpu_single_env must be TLS"
> (ie (a) system emulation built with KVM support and (b) linux-user),
> the set of targets which can be non-TLS is really really small,
> and I think (1) makes much more sense.

Not many linux-user targets support threads (including not i386).

> (I'm assuming you don't want to try to support cpu_single_env
> being both per-thread and not-per-thread in a single binary
> depending on whether the user passes -enable-kvm or not.)

No, of course not.



[Qemu-devel] [Bug 1196498] [NEW] Failed to create COM port in Windows Guest VM

2013-07-01 Thread Venkatesh Petla
Public bug reported:

Hi,

Tried to establish virtual serial connection between two Windows Guest
VMs(Windows 2008 Server).

As it mentioned under the link,
http://www.linux-kvm.org/page/WindowsGuestDrivers/UpdatedGuestDebugging

Started VM using the below command with serial device as TCP port.
# qemu-system-x86_64 -smp 1 -enable-kvm -m 512 -boot c -serial 
tcp:127.0.0.1:50001,server,nowait -hda 
/mnt/sda5/var/lib/libvirt/images/win2008host.img

And started WinDbg in the Windows VM, with serial port:COM1 and
Baudrate:115200.

It throws the error "Could not start kernel debugging using
com:port:COM1,baudrate:115200 parameters, Win32 error 0n2. The system
cannot find the file specified."

Checked under Device Manager and there is no COM1 port.
Does the -serial tcp:127.0.0.01:50001 creates COM1 port? I doubt.
If no what are the parameters I should pass to WinDbg for serial port?

Please help me how to solve this issue.

Thanks
Venkatesh

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  Failed to create COM port in Windows Guest VM

Status in QEMU:
  New

Bug description:
  Hi,

  Tried to establish virtual serial connection between two Windows Guest
  VMs(Windows 2008 Server).

  As it mentioned under the link,
  http://www.linux-kvm.org/page/WindowsGuestDrivers/UpdatedGuestDebugging

  Started VM using the below command with serial device as TCP port.
  # qemu-system-x86_64 -smp 1 -enable-kvm -m 512 -boot c -serial 
tcp:127.0.0.1:50001,server,nowait -hda 
/mnt/sda5/var/lib/libvirt/images/win2008host.img

  And started WinDbg in the Windows VM, with serial port:COM1 and
  Baudrate:115200.

  It throws the error "Could not start kernel debugging using
  com:port:COM1,baudrate:115200 parameters, Win32 error 0n2. The system
  cannot find the file specified."

  Checked under Device Manager and there is no COM1 port.
  Does the -serial tcp:127.0.0.01:50001 creates COM1 port? I doubt.
  If no what are the parameters I should pass to WinDbg for serial port?

  Please help me how to solve this issue.

  Thanks
  Venkatesh

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



Re: [Qemu-devel] [PATCH] [slirp] add nextserver support in slirp's dhcp-server

2013-07-01 Thread Eric Blake
On 06/21/2013 07:20 AM, Bas van Sisseren wrote:
> The slirp dhcp-server normally returns its own address as tftp
> nextserver for netbooting. This patch makes that address
> configurable, so it is possible to use an external tftp boot-
> environment.
> 
> Signed-off-by: Bas van Sisseren 
> ---
>  net/slirp.c  | 10 --

> +++ b/qapi-schema.json
> @@ -2537,6 +2537,8 @@
>  # @dhcpstart: #optional the first of the 16 IPs the built-in DHCP server can
>  # assign
>  #
> +# @nextserver: #optional IP address of BOOTP server
> +#

Please mark this field as '(since 1.6)'.  Does the field work for both
IPv4 and IPv6 addresses?

>  # @dns: #optional guest-visible address of the virtual nameserver
>  #
>  # @dnssearch: #optional list of DNS suffixes to search, passed as DHCP option
> @@ -2563,6 +2565,7 @@
>  '*tftp':  'str',
>  '*bootfile':  'str',
>  '*dhcpstart': 'str',
> +'*nextserver': 'str',

This is a command addition that libvirt can't take advantage of unless
we get introspection working in a timely manner.

-- 
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 v2 07/11] exec: check MRU in qemu_ram_addr_from_host

2013-07-01 Thread Paolo Bonzini
Il 01/07/2013 20:33, Jan Kiszka ha scritto:
> > This function is not used outside the iothread mutex, so it
> > can use ram_list.mru_block.
> 
> Add a comment to qemu_ram_addr_from_host to document this requirement?

Right now there is hardly any documentation of what does _not_ require
the iothread mutex...  basically everything except qemu_safe_ram_ptr and
qemu_ram_ptr_length requires it.

Paolo



[Qemu-devel] Cirrus issues

2013-07-01 Thread Mark
Hi,

The developer of WinUAE has been adding support for Cirrus-based graphics
cards to the program, based on the Qemu Cirrus emulation. Apparently he
has discovered some bugs, which I thought I'd post about here in case
someone who knows about that code wants to take a look.

[begin quote]

Graphics glitches are actually caused by bug in cirrus logic blitter
emulation, it has incorrect "blit is outside of vram" tests, it assumes
all blits are normal copy blits, for example it can incorrectly reject
color expansion blits (used by RectFill).

Because I am too lazy to create logins to qemu bugtracker or mailing list,
at least not yet, here are bugs I have found:

cirrus_vga.c: BLTUNSAFE() macro is broken. (Graphics glitches are gone if
I uncomment them all, of course it can introduce crashes if there are
actual invalid blits..)

cirrus_vga.c: cirrus_do_copy() "extra x, y", s->cirrus_blt_srcpitch or
s->cirrus_blt_dstpitch can be zeros: division by zero.

CIRRUS_BLT_STATUS bit was missing. PicassoII driver polls this to check if
blit has finished.

And one thing that may not be a bug:

vga.c: vga_draw_graphic() seems to assume shift_control =
(s->gr[VGA_GFX_MODE] >> 5) & 3; must be >=2 (bit 6 of Mode Register is
"256 color mode") or it uses standard VGA graphics mode, even if cirrus
extended registers are used to enabled extended (SVGA) modes. My
workaround was to set bit 6 when any extended mode is enabled.

[end quote]

Original forum posting URL: http://eab.abime.net/896935-post30.html

Regards,
-- Mark





[Qemu-devel] [Bug 1196426] [NEW] Setup virtual serial connection for Windows VMs FAILS

2013-07-01 Thread Venkatesh Petla
Public bug reported:

Hi,

To setup a virtual serial connections between two Windows 2008 R2(64-bit) guest 
VMs, I am referring the link 
http://www.linux-kvm.org/page/WindowsGuestDrivers/UpdatedGuestDebugging

I started the host VM using the command
# /usr/local/bin/qemu-system-x86_64 -smp 1 -enable-kvm -m 512 -boot c -chardev 
stdio,id=mon0 -mon chardev=mon0 -serial tcp::4445,server,nowait -hda 
/mnt/sda5/var/lib/libvirt/images/win2008host.img 

To start a target VM, the link specifies the below command
/usr/local/bin/qemu-system-x86_64 \--enable-kvm \-m 1024 \-drive 
file=win-target.img \-chardev stdio,id=mon0 \-mdev=mon0 \-serial 
tcp:127.0.0.1:4445.

I am using the QEMU emulator version 0.15.1 (qemu-kvm-0.15.1). The
command is lil bit changed and also doesn't have -mdev option. I
executed the below command.

# /usr/local/bin/qemu-system-x86_64 -enable-kvm -smp 1 -m 512 -boot c
-chardev stdio,id=mon0 -mon chardev=mon0 -serial tcp:127.0.0.1:4455 -hda
/var/lib/libvirt/images/win2008target.img

It through the error 
inet_connect_opts: connect(ipv4,127.0.0.1,127.0.0.1,4455): Connection refused
chardev: opening backend "socket" failed: Connection refused
qemu: could not open serial device 'tcp:127.0.0.1:4455': Connection refused

Please let me know if any one knows how to fix issue.

My Linux System Info:
# cat /etc/redhat-release 
Fedora release 12 (Constantine)

# uname -a
Linux petla 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 x86_64 
x86_64 x86_64 GNU/Linux

#cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 44
model name  : Intel(R) Xeon(R) CPU   E5645  @ 2.40GHz

#/usr/local/bin/qemu-system-x86_64 --version
QEMU emulator version 0.15.1 (qemu-kvm-0.15.1), Copyright (c) 2003-2008 Fabrice 
Bellard

Guest VMs(host and target): Windows Server 2008 R2 (64-bit)

Thanks in Advance
Venkatesh

** Affects: qemu
 Importance: Undecided
 Status: New


** Tags: connection serial virtual

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

Title:
  Setup virtual serial connection for Windows VMs FAILS

Status in QEMU:
  New

Bug description:
  Hi,

  To setup a virtual serial connections between two Windows 2008 R2(64-bit) 
guest VMs, I am referring the link 
  http://www.linux-kvm.org/page/WindowsGuestDrivers/UpdatedGuestDebugging

  I started the host VM using the command
  # /usr/local/bin/qemu-system-x86_64 -smp 1 -enable-kvm -m 512 -boot c 
-chardev stdio,id=mon0 -mon chardev=mon0 -serial tcp::4445,server,nowait -hda 
/mnt/sda5/var/lib/libvirt/images/win2008host.img 

  To start a target VM, the link specifies the below command
  /usr/local/bin/qemu-system-x86_64 \--enable-kvm \-m 1024 \-drive 
file=win-target.img \-chardev stdio,id=mon0 \-mdev=mon0 \-serial 
tcp:127.0.0.1:4445.

  I am using the QEMU emulator version 0.15.1 (qemu-kvm-0.15.1). The
  command is lil bit changed and also doesn't have -mdev option. I
  executed the below command.

  # /usr/local/bin/qemu-system-x86_64 -enable-kvm -smp 1 -m 512 -boot c
  -chardev stdio,id=mon0 -mon chardev=mon0 -serial tcp:127.0.0.1:4455
  -hda /var/lib/libvirt/images/win2008target.img

  It through the error 
  inet_connect_opts: connect(ipv4,127.0.0.1,127.0.0.1,4455): Connection refused
  chardev: opening backend "socket" failed: Connection refused
  qemu: could not open serial device 'tcp:127.0.0.1:4455': Connection refused

  Please let me know if any one knows how to fix issue.

  My Linux System Info:
  # cat /etc/redhat-release 
  Fedora release 12 (Constantine)

  # uname -a
  Linux petla 2.6.31.5-127.fc12.x86_64 #1 SMP Sat Nov 7 21:11:14 EST 2009 
x86_64 x86_64 x86_64 GNU/Linux

  #cat /proc/cpuinfo
  processor : 0
  vendor_id : GenuineIntel
  cpu family: 6
  model : 44
  model name: Intel(R) Xeon(R) CPU   E5645  @ 2.40GHz

  #/usr/local/bin/qemu-system-x86_64 --version
  QEMU emulator version 0.15.1 (qemu-kvm-0.15.1), Copyright (c) 2003-2008 
Fabrice Bellard

  Guest VMs(host and target): Windows Server 2008 R2 (64-bit)

  Thanks in Advance
  Venkatesh

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



[Qemu-devel] help me for nahanni device

2013-07-01 Thread DAI Weibin
Hi all,
When use nahanni device as following, The QEMU/KVM doesn’t work.
I attach two ivshmem devices to VM, QEMU/KVM only supports a ivshmem device, 
why?
Expect your reply!


-device 
virtio-net-pci,vlan=0,id=net0,mac=DE:AD:BE:09:03:01,bus=pci.0,addr=0x5 \
-net tap,script=/etc/qemu-ifup \
-device ivshmem,size=256m,shm=l1shm \
-device ivshmem,size=256m,shm=l2shm \
-usbdevice tablet \
-vnc :2 \
-daemonize

Best regards
戴卫彬





Re: [Qemu-devel] [PATCH v2 10/11] exec: reorganize address_space_map

2013-07-01 Thread Paolo Bonzini
Il 01/07/2013 20:34, Jan Kiszka ha scritto:
> The transformation looks correct, but I'm currently not understanding in
> which cases we still need the loop. address_space_translate should
> return as much of the target mr as the region can contiguously provide, no?

You could have separate sections if, for example, two consecutive ranges
map to contiguous sections but one is read-only and one is read-write.

Paolo



Re: [Qemu-devel] [PATCH 2/2] qemu-thread: add TLS wrappers

2013-07-01 Thread Richard Henderson
On 07/01/2013 12:25 PM, Peter Maydell wrote:
> Does any OS have a __thread which compiles but is broken, or can
> we just have a configure test for this? That would let MacOSX+clang
> use __thread.

I suspect that this will work.  Some targets may succeed in using gcc's
"emutls" path, which while slower than TLS is pretty much exactly the pthread
get/setcontext fallback that's been proposed elsewhere on this list.


r~



Re: [Qemu-devel] [PATCH RFC qom-cpu 01/41] log: Change log_cpu_state[_mask]() argument to CPUState

2013-07-01 Thread Richard Henderson
On 07/01/2013 10:21 AM, Andreas Färber wrote:
> Thanks. If Blue or you don't have any further comments on the previous
> part 10 series v3, I will queue that on qom-cpu (rebasing right now).

Nothing further from me.


r~



Re: [Qemu-devel] [PATCH RFC qom-cpu 04/41] cpu: Introduce CPUClass::set_pc() for gdb_set_cpu_pc()

2013-07-01 Thread Richard Henderson
On 07/01/2013 12:41 PM, Peter Maydell wrote:
> Returning to the point, what we're after here is "a type which will hold
> a guest virtual address but whose size doesn't depend on the target the
> way target_ulong does", right? My inclination is to suggest that we have
> a 'vaddr' typedef by analogy with 'hwaddr'; it seems like that might make
> code dealing with guest addresses a little more self documenting. I don't
> feel very strongly about it though so if people think it's pointless/will
> cause problems that's fine.
> 

I agree that vaddr would probably be a good name.


r~



[Qemu-devel] [PATCH 2/2] target-alpha: Copy implver to DisasContext

2013-07-01 Thread Richard Henderson
Which allows removing env from DisasContext.

Signed-off-by: Richard Henderson 
---
 target-alpha/translate.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index b59f919..7dac0c8 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -38,7 +38,6 @@
 typedef struct DisasContext DisasContext;
 struct DisasContext {
 struct TranslationBlock *tb;
-CPUAlphaState *env;
 uint64_t pc;
 int mem_idx;
 
@@ -47,6 +46,9 @@ struct DisasContext {
 /* Current flush-to-zero setting for this TB.  */
 int tb_ftz;
 
+/* implver value for this CPU.  */
+int implver;
+
 bool singlestep_enabled;
 };
 
@@ -2246,8 +2248,9 @@ static ExitStatus translate_one(DisasContext *ctx, 
uint32_t insn)
 break;
 case 0x6C:
 /* IMPLVER */
-if (rc != 31)
-tcg_gen_movi_i64(cpu_ir[rc], ctx->env->implver);
+if (rc != 31) {
+tcg_gen_movi_i64(cpu_ir[rc], ctx->implver);
+}
 break;
 default:
 goto invalid_opc;
@@ -3395,9 +3398,9 @@ static inline void 
gen_intermediate_code_internal(CPUAlphaState *env,
 gen_opc_end = tcg_ctx.gen_opc_buf + OPC_MAX_SIZE;
 
 ctx.tb = tb;
-ctx.env = env;
 ctx.pc = pc_start;
 ctx.mem_idx = cpu_mmu_index(env);
+ctx.implver = env->implver;
 ctx.singlestep_enabled = env->singlestep_enabled;
 
 /* ??? Every TB begins with unset rounding mode, to be initialized on
-- 
1.8.1.4




[Qemu-devel] [PATCH 1/2] target-alpha: Copy singlestep_enabled to DisasContext

2013-07-01 Thread Richard Henderson
Prepare for removing env from DisasContext.

Signed-off-by: Richard Henderson 
---
 target-alpha/translate.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/target-alpha/translate.c b/target-alpha/translate.c
index 4db16db..b59f919 100644
--- a/target-alpha/translate.c
+++ b/target-alpha/translate.c
@@ -46,6 +46,8 @@ struct DisasContext {
 int tb_rm;
 /* Current flush-to-zero setting for this TB.  */
 int tb_ftz;
+
+bool singlestep_enabled;
 };
 
 /* Return values from translate_one, indicating the state of the TB.
@@ -380,7 +382,7 @@ static int use_goto_tb(DisasContext *ctx, uint64_t dest)
 /* Check for the dest on the same page as the start of the TB.  We
also want to suppress goto_tb in the case of single-steping and IO.  */
 return (((ctx->tb->pc ^ dest) & TARGET_PAGE_MASK) == 0
-&& !ctx->env->singlestep_enabled
+&& !ctx->singlestep_enabled
 && !(ctx->tb->cflags & CF_LAST_IO));
 }
 
@@ -3396,6 +3398,7 @@ static inline void 
gen_intermediate_code_internal(CPUAlphaState *env,
 ctx.env = env;
 ctx.pc = pc_start;
 ctx.mem_idx = cpu_mmu_index(env);
+ctx.singlestep_enabled = env->singlestep_enabled;
 
 /* ??? Every TB begins with unset rounding mode, to be initialized on
the first fp insn of the TB.  Alternately we could define a proper
@@ -3452,7 +3455,7 @@ static inline void 
gen_intermediate_code_internal(CPUAlphaState *env,
 || tcg_ctx.gen_opc_ptr >= gen_opc_end
 || num_insns >= max_insns
 || singlestep
-|| env->singlestep_enabled)) {
+|| ctx.singlestep_enabled)) {
 ret = EXIT_PC_STALE;
 }
 } while (ret == NO_EXIT);
@@ -3469,7 +3472,7 @@ static inline void 
gen_intermediate_code_internal(CPUAlphaState *env,
 tcg_gen_movi_i64(cpu_pc, ctx.pc);
 /* FALLTHRU */
 case EXIT_PC_UPDATED:
-if (env->singlestep_enabled) {
+if (ctx.singlestep_enabled) {
 gen_excp_1(EXCP_DEBUG, 0);
 } else {
 tcg_gen_exit_tb(0);
-- 
1.8.1.4




[Qemu-devel] [PATCH 0/2] target-alpha prep work for qom cpu changes

2013-07-01 Thread Richard Henderson
As discussed in the QOM thread.


r~


Richard Henderson (2):
  target-alpha: Copy singlestep_enabled to DisasContext
  target-alpha: Copy implver to DisasContext

 target-alpha/translate.c | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

-- 
1.8.1.4




Re: [Qemu-devel] [PATCH 2/2] qemu-thread: add TLS wrappers

2013-07-01 Thread Ed Maste
On 1 July 2013 15:25, Peter Maydell  wrote:
> Does any OS have a __thread which compiles but is broken, or can
> we just have a configure test for this? That would let MacOSX+clang
> use __thread.

I believe this was recently the case on NetBSD - code with __thread
would build, but fail at run time.  I think this applies to NetBSD 5.0
and earlier, but I see that TLS support is listed in the 6.0 release
notes.  So perhaps a __thread configure test with an override for the
known-failing case(s).



Re: [Qemu-devel] [PATCH 0/6][RFC] AArch64 support for Versatile Express using KVM

2013-07-01 Thread Mian M. Hamayun
At the time we started working on AArch64, we were not certain that our 
implementation would be published in near future. Now that this is 
cleared up we are more than happy to coordinate together.

On 28 June 2013 14:04, Andreas Färber  wrote:

I had been looking into that tree myself, and apart from John's
Linux'ish "ARM: " prefixes rather than our usual "target-arm: " (part of
which you forgot to fix before sending a PULL), I am really opposed to
copying A15MPCore_priv for A57.

I agree that just copying A15 is wrong (among other things, we
should be modelling the hardware, not just "this seems to make
KVM not barf"). That's one of the reasons I hadn't sent the patch
set out yet.

Initially we thought about this aspect too, but in order to get started, 
we made the choice to continue using the already available A15 part as 
is. Obviously this is an RFC patch series and we would like to have your 
opinion on how we can proceed from here, based on the working solution 
that we have now, although we may have some differences from the real 
hardware.

Also I would really prefer to have the is_aarch64() helper operate on
ARMCPU rather than CPUARMState. QOM cast removal is underway to make
that more efficient.

Is there a 32-bit aarch64 register in ARMv8 to be accessed by TCG? If
not, the field should be in ARMCPU and a bool rather than uint32_t.

This also needs looking at, yes.

-- PMM

--
Hamayun




Re: [Qemu-devel] [PATCH RFC qom-cpu 04/41] cpu: Introduce CPUClass::set_pc() for gdb_set_cpu_pc()

2013-07-01 Thread Peter Maydell
On 1 July 2013 20:03, Richard Henderson  wrote:
> I would think hwaddr wouldn't be appropriate, since that's supposed to be
> talking about physical addresses, and that's not the case here.  The name (and
> admittedly minimal documentation for) ram_addr_t sounds right, but it seems to
> be sized wrong, so I don't know what it's actually supposed to be.

ram_addr_t is for indexes into guest RAM, ie into what you get by concatenating
all the RAMBlocks together. (This is why it's uintptr_t sized -- you know you
can't have more RAM total than will fit into the host's address space.)
It usually isn't what you want. Feel free to suggest improvements to
HACKING -- I tried to describe this in the bit that goes "ram_addr_t is
a QEMU internal address space ..." but since I already knew what it did
I probably failed to explain sufficiently.

Returning to the point, what we're after here is "a type which will hold
a guest virtual address but whose size doesn't depend on the target the
way target_ulong does", right? My inclination is to suggest that we have
a 'vaddr' typedef by analogy with 'hwaddr'; it seems like that might make
code dealing with guest addresses a little more self documenting. I don't
feel very strongly about it though so if people think it's pointless/will
cause problems that's fine.

thanks
-- PMM



Re: [Qemu-devel] [PATCH 2/2] qemu-thread: add TLS wrappers

2013-07-01 Thread Peter Maydell
On 1 July 2013 19:52, Ed Maste  wrote:
> The most recent version of this patch posted by Paolo that I see has:
>
> +#if defined(__linux__) || defined(__FreeBSD__)
> +#define DECLARE_TLS(type, x) \
>
> while this one has only __linux__.  Do you mind picking up that
> change, if this is likely to make it in via your work?

Does any OS have a __thread which compiles but is broken, or can
we just have a configure test for this? That would let MacOSX+clang
use __thread.

-- PMM



Re: [Qemu-devel] [PATCH 1/6] Added aarch64 configure support and default configuration

2013-07-01 Thread Peter Maydell
On 1 July 2013 20:22, Peter Maydell  wrote:
 In particular this would try to build
> a 64 bit binary but with QEMU's copy of the 32 bit kernel headers:
> I'm not sure that's expected (by the kernel folk) to work at all. If not,
> we should just not put the line into configure in the first place.

Sorry, this bit is wrong; ignore it. We pick the kernel headers based
on $cpu, not $target, so get the aarch64 ones whether we're building
arm-softmmu or aarch64-softmmu.

-- PMM



Re: [Qemu-devel] [PATCH 1/6] Added aarch64 configure support and default configuration

2013-07-01 Thread Peter Maydell
On 1 July 2013 19:46, Alexander Spyridakis
 wrote:
> On 29 June 2013 21:20, Peter Maydell  wrote:
>> So this is enabling support for emulating 32 bit VMs with a
>> QEMU running as a 64 bit process, but the commit message
>> doesn't mention this. Did you test that combination?

Actually I wasn't quite right here -- in fact
\( "$target_name" = "arm"-a "$cpu" = "aarch64"   \)
is the case where you're building a QEMU running as a 64 bit binary
but only supporting 32 bit CPUs.  In particular this would try to build
a 64 bit binary but with QEMU's copy of the 32 bit kernel headers:
I'm not sure that's expected (by the kernel folk) to work at all. If not,
we should just not put the line into configure in the first place.

Note that that still leaves the case of "built aarch64-softmmu
with KVM support and user used -cpu cortex-a15" which you can only
catch at runtime. My guess is that will either (a) work or (b) be
caught already by the KVM_ARM_VCPU_INIT ioctl failing because we asked
for KVM_ARM_TARGET_CORTEX_A15 and the kernel didn't support it.
Either way, it seems like a more sensible way to support the 32-on-64
case when we eventually choose to do so.

> Nope, this case is not handled. Currently it won't crash but of course
> won't boot either. Definitely worth looking into, at the very minimum
> it should gracefully deny execution.

Yes, in general I'm happy for us not to support 32-bit-VM-on-64-host
initially, as long as it fails gracefully.

thanks
-- PMM



Re: [Qemu-devel] [PATCH 4/6] Added the Versatile Express Machine Model for A57

2013-07-01 Thread Peter Maydell
On 1 July 2013 19:06, Alexander Spyridakis
 wrote:
> On 29 June 2013 21:21, Peter Maydell  wrote:
>> So, which documentation or TRM or hardware are you basing this
>> definition of an A57 Versatile Express daughterboard on?
>
> Currently there is no existing hardware that I am aware of, or a
> public TRM describing it.

Then you can't put a board model into QEMU that claims to be
a vexpress-a57. What you want is mach-virt (see John Rigby's
patchset).

thanks
-- PMM



Re: [Qemu-devel] [PATCH v5 00/21] AArch64 preparation patchset

2013-07-01 Thread Peter Maydell
On 1 July 2013 18:34, Peter Maydell  wrote:
> This patchset is v5 of the "preparation patchset" that started
> off with Alex, was passed to John Rigby and now to me.

Also available via git:

git://git.linaro.org/people/pmaydell/qemu-arm.git aarch64
(caution: branch likely to rebase in future)

-- PMM



Re: [Qemu-devel] [PATCH RFC qom-cpu 04/41] cpu: Introduce CPUClass::set_pc() for gdb_set_cpu_pc()

2013-07-01 Thread Richard Henderson
On 07/01/2013 10:25 AM, Andreas Färber wrote:
> This is the first case where I am proposing the use of uint64_t in place
> of target_ulong. In this case a gdb command using such a hook is not
> performance-sensitive. Do you see this as an acceptable path for adding
> further CPUClass hooks such as MMU fault handling?

I think that would be appropriate.  MMU faulting can't be much more performance
sensitive than device emulation, which is already standardizing on 64-bit
addresses.

> Should we introduce some ulong-target-max typedef similar to hwaddr or
> use plain uint64_t as done here?

I would think hwaddr wouldn't be appropriate, since that's supposed to be
talking about physical addresses, and that's not the case here.  The name (and
admittedly minimal documentation for) ram_addr_t sounds right, but it seems to
be sized wrong, so I don't know what it's actually supposed to be.

Unless someone has a better suggestion, I'd stay with uint64_t.


r~



Re: [Qemu-devel] [PATCH v4] Add timestamp to error message

2013-07-01 Thread Seiji Aguchi
> > >  void error_report(const char *fmt, ...)
> > >  {
> > >  va_list ap;
> > > +char timestr[TIMESTAMP_LEN];
> > > +
> > > +if (enable_timestamp_msg) {
> > > +qemu_get_timestamp_str(×tr);
> > > +error_printf("%s ", timestr);
> > > +}
> > >
> > >  error_print_loc();
> > >  va_start(ap, fmt);
> >
> > Does this print the timestamp to all kinds of monitors too? On stderr,
> > the timestamp is great. When printed to an "interactive monitor", it
> > could also help post-mortem debugging. But would it not confuse libvirt
> > eg.? (Apologies if this has been discussed before.)
> 
> I will try to add timestamp to monitor_printf().
> (In the long term, I would like to add it to all fprintf() in qemu.)

I tried to add timestamp to monitor_printf().
But, it wasn't easier than I expected.
(At least, we should not add it to monitor_printf() in readline.c.)
We need to discuss which message of monitor_printf() has to be
added timestamp.

Therefore, I would like to forcus on error_report() in this thread.
(I posted patch v5 just now.)

Seiji



Re: [Qemu-devel] [PATCH v2 10/11] exec: reorganize address_space_map

2013-07-01 Thread Jan Kiszka
On 2013-06-28 18:58, Paolo Bonzini wrote:
> First of all, rename "todo" to "done".
> 
> Second, clearly separate the case of done == 0 from the case of done != 0.
> This will help handling reference counting in the next patch.
> 
> Third, this test:
> 
>  if (memory_region_get_ram_addr(mr) + xlat != raddr + todo) {
> 
> does not guarantee that the memory region is the same across two iterations
> of the while loop.  For example, you could have two blocks:
> 
> A) size 640 K, mapped at physical address 0, ram_addr_t 0
> B) size 64 K, mapped at physical address 0xa, ram_addr_t 0xa
> 
> then mapping 1 M starting at physical address zero will erroneously treat
> B as the continuation of block A.  qemu_ram_ptr_length ensures that no
> invalid memory is accessed, but it is still a pointless complication of
> the algorithm.  The patch makes the logic clearer with an explicit test
> that the memory region is the same.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  exec.c | 71 
> +++---
>  1 file changed, 38 insertions(+), 33 deletions(-)
> 
> diff --git a/exec.c b/exec.c
> index a372963..ea79aea 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -2073,47 +2073,52 @@ void *address_space_map(AddressSpace *as,
>  bool is_write)
>  {
>  hwaddr len = *plen;
> -hwaddr todo = 0;
> -hwaddr l, xlat;
> -MemoryRegion *mr;
> -ram_addr_t raddr = RAM_ADDR_MAX;
> -ram_addr_t rlen;
> -void *ret;
> +hwaddr done = 0;
> +hwaddr l, xlat, base;
> +MemoryRegion *mr, *this_mr;
> +ram_addr_t raddr;
>  
> -while (len > 0) {
> -l = len;
> -mr = address_space_translate(as, addr, &xlat, &l, is_write);
> -
> -if (!memory_access_is_direct(mr, is_write)) {
> -if (todo || bounce.buffer) {
> -break;
> -}
> -bounce.buffer = qemu_memalign(TARGET_PAGE_SIZE, 
> TARGET_PAGE_SIZE);
> -bounce.addr = addr;
> -bounce.len = l;
> -if (!is_write) {
> -address_space_read(as, addr, bounce.buffer, l);
> -}
> +if (len == 0) {
> +return NULL;
> +}
>  
> -*plen = l;
> -return bounce.buffer;
> +l = len;
> +mr = address_space_translate(as, addr, &xlat, &l, is_write);
> +if (!memory_access_is_direct(mr, is_write)) {
> +if (bounce.buffer) {
> +return NULL;
>  }
> -if (!todo) {
> -raddr = memory_region_get_ram_addr(mr) + xlat;
> -} else {
> -if (memory_region_get_ram_addr(mr) + xlat != raddr + todo) {
> -break;
> -}
> +bounce.buffer = qemu_memalign(TARGET_PAGE_SIZE, TARGET_PAGE_SIZE);
> +bounce.addr = addr;
> +bounce.len = l;
> +if (!is_write) {
> +address_space_read(as, addr, bounce.buffer, l);
>  }
>  
> +*plen = l;
> +return bounce.buffer;
> +}
> +
> +base = xlat;
> +raddr = memory_region_get_ram_addr(mr);
> +
> +for (;;) {
>  len -= l;
>  addr += l;
> -todo += l;
> +done += l;
> +if (len == 0) {
> +break;
> +}
> +
> +l = len;
> +this_mr = address_space_translate(as, addr, &xlat, &l, is_write);
> +if (this_mr != mr || xlat != base + done) {
> +break;
> +}
>  }
> -rlen = todo;
> -ret = qemu_ram_ptr_length(raddr, &rlen);
> -*plen = rlen;
> -return ret;
> +
> +*plen = done;
> +return qemu_ram_ptr_length(raddr + base, plen);
>  }
>  
>  /* Unmaps a memory region previously mapped by address_space_map().
> 

The transformation looks correct, but I'm currently not understanding in
which cases we still need the loop. address_space_translate should
return as much of the target mr as the region can contiguously provide, no?

Jan

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



Re: [Qemu-devel] [PATCH v4 06/10] qemu-ga: Add Windows VSS provider to quiesce applications on fsfreeze

2013-07-01 Thread Tomoki Sekiyama
On 6/30/13 9:16 , "Gal Hammer"  wrote:

>On 26/06/2013 01:31, Tomoki Sekiyama wrote:
>
>>> Also, is it needed to call VSSCheckOSVersion from the requestor?  I
>>> would think that checking VSSAPI.DLL is stronger than checking the
>>> version, and indeed you do that check too.
>>
>> In Windows XP, VSSAPI.DLL exists but it has different functionality
>> and interfaces from newer Windows.
>> 
>>http://msdn.microsoft.com/en-us/library/windows/desktop/aa384627(v=vs.85)
>>.aspx
>>
>> It is checking the OS version because this patchset only supports
>> Windows 2003 or later.
>
>So why don't you query for the interface you supports rather than
>checking the OS version?

Hmm, I don't know what I should query for. Microsoft's document above only
provides a table of compatibility between VSS SDK version and OS version.

Of course I can install the component and test whether it works or not,
but I want to know that before installing something.

>Thanks,
>
> Gal.

Thanks,
Tomoki Sekiyama




[Qemu-devel] [PATCH v5] Add timestamp to error_report()

2013-07-01 Thread Seiji Aguchi
[Issue]
When we offer a customer support service and a problem happens
in a customer's system, we try to understand the problem by
comparing what the customer reports with message logs of the
customer's system.

In this case, we often need to know when the problem happens.

But, currently, there is no timestamp in qemu's error messages.
Therefore, we may not be able to understand the problem based on
error messages.

[Solution]
Add a timestamp to qemu's error message logged by
error_report() with g_time_val_to_iso8601().

Signed-off-by: Seiji Aguchi 
---
Changelog
 v4 -> v5
 - Use sizeof() to define TIMESTAMP_LEN.
 - Fix descriptions of msg option.
 - Rename TIME_H to QEMU_TIME_H. (avoiding double inclusion of qemu/time.h)
 - Change argument of qemu_get_timestamp_str to "char *" and "size_t".
 - Confirmed msg option is displayed by query-command-line-options.

 v3 -> v4
 - Correct email address of Signed-off-by.

 v2 -> v3
 - Use g_time_val_to_iso8601() to get timestamp instead of
   copying libvirt's time-handling functions.

   According to discussion below, qemu doesn't need to take care
   if timestamp functions are async-signal safe or not.

   http://marc.info/?l=qemu-devel&m=136741841921265&w=2

   Also, In the review of v2 patch, strftime() are recommended to
   format string. But it is not a suitable function to handle msec.

   Then, simply call g_time_val_to_iso8601().

 - Intoroduce a common time-handling function to util/qemu-time.c.
   (Suggested by Daniel P. Berrange)

 - Add testing for g_time_val_to_iso8601() to tests/test-time.c.
   The test cases are copied from libvirt's virtimetest.
   (Suggested by Daniel P. Berrange)

 v1 -> v2

 - add an option, -msg timestamp={on|off}, to enable output message with 
timestamp
---
 include/qemu/time.h |   10 ++
 qemu-options.hx |   12 
 util/Makefile.objs  |1 +
 util/qemu-error.c   |8 
 util/qemu-time.c|   26 ++
 vl.c|   28 
 6 files changed, 85 insertions(+), 0 deletions(-)
 create mode 100644 include/qemu/time.h
 create mode 100644 util/qemu-time.c

diff --git a/include/qemu/time.h b/include/qemu/time.h
new file mode 100644
index 000..ce3903e
--- /dev/null
+++ b/include/qemu/time.h
@@ -0,0 +1,10 @@
+#ifndef QEMU_TIME_H
+#define QEMU_TIME_H
+
+#include "qemu-common.h"
+
+#define TIMESTAMP_LEN sizeof("1970-01-01T00:00:00.99Z")
+extern void qemu_get_timestamp_str(char *, size_t);
+extern bool enable_timestamp_msg;
+
+#endif /* QEMU_TIME_H */
diff --git a/qemu-options.hx b/qemu-options.hx
index ca6fdf6..a6dac1a 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -3102,3 +3102,15 @@ HXCOMM This is the last statement. Insert new options 
before this line!
 STEXI
 @end table
 ETEXI
+
+DEF("msg", HAS_ARG, QEMU_OPTION_msg,
+"-msg [timestamp=on|off]\n"
+"  change the format of messages\n"
+"  timestamp=on|off enables leading timestamps (default:on)\n",
+QEMU_ARCH_ALL)
+STEXI
+@item -msg timestamp=on|off
+@findex -msg
+prepend a timestamp to each log message.
+(disabled by default)
+ETEXI
diff --git a/util/Makefile.objs b/util/Makefile.objs
index dc72ab0..063db56 100644
--- a/util/Makefile.objs
+++ b/util/Makefile.objs
@@ -11,3 +11,4 @@ util-obj-y += iov.o aes.o qemu-config.o qemu-sockets.o uri.o 
notify.o
 util-obj-y += qemu-option.o qemu-progress.o
 util-obj-y += hexdump.o
 util-obj-y += crc32c.o
+util-obj-y += qemu-time.o
diff --git a/util/qemu-error.c b/util/qemu-error.c
index 08a36f4..c65fdfd 100644
--- a/util/qemu-error.c
+++ b/util/qemu-error.c
@@ -12,6 +12,7 @@
 
 #include 
 #include "monitor/monitor.h"
+#include "qemu/time.h"
 
 /*
  * Print to current monitor if we have one, else to stderr.
@@ -196,6 +197,7 @@ void error_print_loc(void)
 }
 }
 
+bool enable_timestamp_msg;
 /*
  * Print an error message to current monitor if we have one, else to stderr.
  * Format arguments like sprintf().  The result should not contain
@@ -206,6 +208,12 @@ void error_print_loc(void)
 void error_report(const char *fmt, ...)
 {
 va_list ap;
+char timestr[TIMESTAMP_LEN];
+
+if (enable_timestamp_msg) {
+qemu_get_timestamp_str(timestr, sizeof(timestr));
+error_printf("%s ", timestr);
+}
 
 error_print_loc();
 va_start(ap, fmt);
diff --git a/util/qemu-time.c b/util/qemu-time.c
new file mode 100644
index 000..3862788
--- /dev/null
+++ b/util/qemu-time.c
@@ -0,0 +1,26 @@
+/*
+ * Time handling
+ *
+ * Copyright (C) 2013 Hitachi Data Systems Corp.
+ *
+ * Authors:
+ *  Seiji Aguchi 
+ *
+ * This work is licensed under the terms of the GNU GPL, version 2 or later.
+ * See the COPYING file in the top-level directory.
+ */
+#include "qemu/time.h"
+
+void qemu_get_timestamp_str(char *timestr, size_t len)
+{
+GTimeVal tv;
+gchar *tmp_str = NULL;
+
+/* Size of len should be at least TIMESTAMP_LEN to avoid truncation */
+assert(len >= TIMESTAMP_LEN);
+
+g_get_current_time(&tv);
+

Re: [Qemu-devel] [PATCH 2/2] qemu-thread: add TLS wrappers

2013-07-01 Thread Ed Maste
 On 1 July 2013 05:35, Stefan Hajnoczi  wrote:
> From: Paolo Bonzini 
>
> Fast TLS is not available on some platforms, but it is always nice to
> use it.  This wrapper implementation falls back to pthread_get/setspecific
> on POSIX systems that lack __thread, but uses the dynamic linker's TLS
> support on Linux and Windows.

The most recent version of this patch posted by Paolo that I see has:

+#if defined(__linux__) || defined(__FreeBSD__)
+#define DECLARE_TLS(type, x) \

while this one has only __linux__.  Do you mind picking up that
change, if this is likely to make it in via your work?



Re: [Qemu-devel] [PATCH 1/6] Added aarch64 configure support and default configuration

2013-07-01 Thread Alexander Spyridakis
On 29 June 2013 21:20, Peter Maydell  wrote:
> So this is enabling support for emulating 32 bit VMs with a
> QEMU running as a 64 bit process, but the commit message
> doesn't mention this. Did you test that combination?

Nope, this case is not handled. Currently it won't crash but of course
won't boot either. Definitely worth looking into, at the very minimum
it should gracefully deny execution.

Regards.



Re: [Qemu-devel] [PATCH v2 11/11] memory: ref/unref memory across address_space_map/unmap

2013-07-01 Thread Jan Kiszka
On 2013-06-28 18:58, Paolo Bonzini wrote:
> The iothread mutex might be released between map and unmap, so the
> mapped region might disappear.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  exec.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/exec.c b/exec.c
> index ea79aea..d28403b 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -1994,6 +1994,7 @@ void cpu_physical_memory_write_rom(hwaddr addr,
>  }
>  
>  typedef struct {
> +MemoryRegion *mr;
>  void *buffer;
>  hwaddr addr;
>  hwaddr len;
> @@ -2091,6 +2092,9 @@ void *address_space_map(AddressSpace *as,
>  bounce.buffer = qemu_memalign(TARGET_PAGE_SIZE, TARGET_PAGE_SIZE);
>  bounce.addr = addr;
>  bounce.len = l;
> +
> +memory_region_ref(mr);
> +bounce.mr = mr;
>  if (!is_write) {
>  address_space_read(as, addr, bounce.buffer, l);
>  }
> @@ -2117,6 +2121,7 @@ void *address_space_map(AddressSpace *as,
>  }
>  }
>  
> +memory_region_ref(mr);
>  *plen = done;
>  return qemu_ram_ptr_length(raddr + base, plen);
>  }
> @@ -2129,9 +2134,12 @@ void address_space_unmap(AddressSpace *as, void 
> *buffer, hwaddr len,
>   int is_write, hwaddr access_len)
>  {
>  if (buffer != bounce.buffer) {
> +MemoryRegion *mr;
> +ram_addr_t addr1;
> +
> +mr = qemu_ram_addr_from_host(buffer, &addr1);
> +assert(mr);
>  if (is_write) {
> -ram_addr_t addr1;
> -qemu_ram_addr_from_host(buffer, &addr1);
>  while (access_len) {
>  unsigned l;
>  l = TARGET_PAGE_SIZE;
> @@ -2145,6 +2153,7 @@ void address_space_unmap(AddressSpace *as, void 
> *buffer, hwaddr len,
>  if (xen_enabled()) {
>  xen_invalidate_map_cache_entry(buffer);
>  }
> +memory_region_unref(mr);
>  return;
>  }
>  if (is_write) {
> @@ -2152,6 +2161,7 @@ void address_space_unmap(AddressSpace *as, void 
> *buffer, hwaddr len,
>  }
>  qemu_vfree(bounce.buffer);
>  bounce.buffer = NULL;
> +memory_region_unref(bounce.mr);
>  cpu_notify_map_clients();
>  }
>  
> 

Reviewed-by: Jan Kiszka 

Jan

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



Re: [Qemu-devel] [PATCH v2 07/11] exec: check MRU in qemu_ram_addr_from_host

2013-07-01 Thread Jan Kiszka
On 2013-06-28 18:58, Paolo Bonzini wrote:
> This function is not used outside the iothread mutex, so it
> can use ram_list.mru_block.

Add a comment to qemu_ram_addr_from_host to document this requirement?

> 
> Signed-off-by: Paolo Bonzini 
> ---
>  exec.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/exec.c b/exec.c
> index 8722420..f3d7b18 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -1408,18 +1408,26 @@ int qemu_ram_addr_from_host(void *ptr, ram_addr_t 
> *ram_addr)
>  return 0;
>  }
>  
> +block = ram_list.mru_block;
> +if (block && block->host && host - block->host < block->length) {
> +goto found;
> +}
> +
>  QTAILQ_FOREACH(block, &ram_list.blocks, next) {
>  /* This case append when the block is not mapped. */
>  if (block->host == NULL) {
>  continue;
>  }
>  if (host - block->host < block->length) {
> -*ram_addr = block->offset + (host - block->host);
> -return 0;
> +goto found;
>  }
>  }
>  
>  return -1;
> +
> +found:
> +*ram_addr = block->offset + (host - block->host);
> +return 0;
>  }
>  
>  /* Some of the softmmu routines need to translate from a host pointer
> 

Beside the nit:
Reviewed-by: Jan Kiszka 

Jan

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



Re: [Qemu-devel] [PATCH v2 09/11] memory: return MemoryRegion from qemu_ram_addr_from_host

2013-07-01 Thread Jan Kiszka
On 2013-06-28 18:58, Paolo Bonzini wrote:
> It will be needed in the next patches.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  cputlb.c  |  2 +-
>  exec.c| 33 -
>  include/exec/cpu-common.h |  2 +-
>  target-i386/kvm.c |  4 ++--
>  4 files changed, 24 insertions(+), 17 deletions(-)
> 
> diff --git a/cputlb.c b/cputlb.c
> index b716bbe..51381ae 100644
> --- a/cputlb.c
> +++ b/cputlb.c
> @@ -162,7 +162,7 @@ static inline ram_addr_t 
> qemu_ram_addr_from_host_nofail(void *ptr)
>  {
>  ram_addr_t ram_addr;
>  
> -if (qemu_ram_addr_from_host(ptr, &ram_addr)) {
> +if (qemu_ram_addr_from_host(ptr, &ram_addr) == NULL) {
>  fprintf(stderr, "Bad ram pointer %p\n", ptr);
>  abort();
>  }
> diff --git a/exec.c b/exec.c
> index aa76366..a372963 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -1296,15 +1296,7 @@ void qemu_ram_remap(ram_addr_t addr, ram_addr_t length)
>  }
>  #endif /* !_WIN32 */
>  
> -/* Return a host pointer to ram allocated with qemu_ram_alloc.
> -   With the exception of the softmmu code in this file, this should
> -   only be used for local memory (e.g. video ram) that the device owns,
> -   and knows it isn't going to access beyond the end of the block.
> -
> -   It should not be used for general purpose DMA.
> -   Use cpu_physical_memory_map/cpu_physical_memory_rw instead.
> - */
> -void *qemu_get_ram_ptr(ram_addr_t addr)
> +static RAMBlock *qemu_get_ram_block(ram_addr_t addr)
>  {
>  RAMBlock *block;
>  
> @@ -1324,6 +1316,21 @@ void *qemu_get_ram_ptr(ram_addr_t addr)
>  
>  found:
>  ram_list.mru_block = block;
> +return block;
> +}
> +
> +/* Return a host pointer to ram allocated with qemu_ram_alloc.
> +   With the exception of the softmmu code in this file, this should
> +   only be used for local memory (e.g. video ram) that the device owns,
> +   and knows it isn't going to access beyond the end of the block.
> +
> +   It should not be used for general purpose DMA.
> +   Use cpu_physical_memory_map/cpu_physical_memory_rw instead.
> + */
> +void *qemu_get_ram_ptr(ram_addr_t addr)
> +{
> +RAMBlock *block = qemu_get_ram_block(addr);
> +
>  if (xen_enabled()) {
>  /* We need to check if the requested address is in the RAM
>   * because we don't want to map the entire memory in QEMU.
> @@ -1400,14 +1407,14 @@ static void *qemu_ram_ptr_length(ram_addr_t addr, 
> ram_addr_t *size)
>  
>  /* Some of the softmmu routines need to translate from a host pointer
> (typically a TLB entry) back to a ram offset.  */
> -int qemu_ram_addr_from_host(void *ptr, ram_addr_t *ram_addr)
> +MemoryRegion *qemu_ram_addr_from_host(void *ptr, ram_addr_t *ram_addr)
>  {
>  RAMBlock *block;
>  uint8_t *host = ptr;
>  
>  if (xen_enabled()) {
>  *ram_addr = xen_ram_addr_from_mapcache(ptr);
> -return 0;
> +return qemu_get_ram_block(*ram_addr)->mr;
>  }
>  
>  block = ram_list.mru_block;
> @@ -1425,11 +1432,11 @@ int qemu_ram_addr_from_host(void *ptr, ram_addr_t 
> *ram_addr)
>  }
>  }
>  
> -return -1;
> +return NULL;
>  
>  found:
>  *ram_addr = block->offset + (host - block->host);
> -return 0;
> +return block->mr;
>  }
>  
>  static void notdirty_mem_write(void *opaque, hwaddr ram_addr,
> diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
> index 8063ba2..8f75233 100644
> --- a/include/exec/cpu-common.h
> +++ b/include/exec/cpu-common.h
> @@ -50,7 +50,7 @@ typedef uint32_t CPUReadMemoryFunc(void *opaque, hwaddr 
> addr);
>  
>  void qemu_ram_remap(ram_addr_t addr, ram_addr_t length);
>  /* This should not be used by devices.  */
> -int qemu_ram_addr_from_host(void *ptr, ram_addr_t *ram_addr);
> +MemoryRegion *qemu_ram_addr_from_host(void *ptr, ram_addr_t *ram_addr);
>  void qemu_ram_set_idstr(ram_addr_t addr, const char *name, DeviceState *dev);
>  
>  void cpu_physical_memory_rw(hwaddr addr, uint8_t *buf,
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index 9ffb6ca..7ba98cd 100644
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
> @@ -318,7 +318,7 @@ int kvm_arch_on_sigbus_vcpu(CPUState *c, int code, void 
> *addr)
>  
>  if ((env->mcg_cap & MCG_SER_P) && addr
>  && (code == BUS_MCEERR_AR || code == BUS_MCEERR_AO)) {
> -if (qemu_ram_addr_from_host(addr, &ram_addr) ||
> +if (qemu_ram_addr_from_host(addr, &ram_addr) == NULL ||
>  !kvm_physical_memory_addr_from_host(c->kvm_state, addr, &paddr)) 
> {
>  fprintf(stderr, "Hardware memory error for memory used by "
>  "QEMU itself instead of guest system!\n");
> @@ -350,7 +350,7 @@ int kvm_arch_on_sigbus(int code, void *addr)
>  hwaddr paddr;
>  
>  /* Hope we are lucky for AO MCE */
> -if (qemu_ram_addr_from_host(addr, &ram_addr) ||
> +if (qemu_ram_addr_from_host(addr, &ram_addr) == NULL ||
>  !kvm_physical_memory_addr_f

Re: [Qemu-devel] [PATCH v2 08/11] exec: move qemu_ram_addr_from_host_nofail to cputlb.c

2013-07-01 Thread Jan Kiszka
On 2013-06-28 18:58, Paolo Bonzini wrote:
> After the next patch it would not be used elsewhere anyway.  Also,
> the _nofail and the standard versions of this function return different
> things, which is confusing.  Removing the function from the public headers
> limits the confusion.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  cputlb.c  | 11 +++
>  exec.c| 18 --
>  include/exec/cpu-common.h |  1 -
>  3 files changed, 15 insertions(+), 15 deletions(-)
> 
> diff --git a/cputlb.c b/cputlb.c
> index 947f17c..b716bbe 100644
> --- a/cputlb.c
> +++ b/cputlb.c
> @@ -158,6 +158,17 @@ void tlb_reset_dirty_range(CPUTLBEntry *tlb_entry, 
> uintptr_t start,
>  }
>  }
>  
> +static inline ram_addr_t qemu_ram_addr_from_host_nofail(void *ptr)
> +{
> +ram_addr_t ram_addr;
> +
> +if (qemu_ram_addr_from_host(ptr, &ram_addr)) {
> +fprintf(stderr, "Bad ram pointer %p\n", ptr);
> +abort();
> +}
> +return ram_addr;
> +}
> +
>  static inline void tlb_update_dirty(CPUTLBEntry *tlb_entry)
>  {
>  ram_addr_t ram_addr;
> diff --git a/exec.c b/exec.c
> index f3d7b18..aa76366 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -1398,6 +1398,8 @@ static void *qemu_ram_ptr_length(ram_addr_t addr, 
> ram_addr_t *size)
>  }
>  }
>  
> +/* Some of the softmmu routines need to translate from a host pointer
> +   (typically a TLB entry) back to a ram offset.  */
>  int qemu_ram_addr_from_host(void *ptr, ram_addr_t *ram_addr)
>  {
>  RAMBlock *block;
> @@ -1430,19 +1432,6 @@ found:
>  return 0;
>  }
>  
> -/* Some of the softmmu routines need to translate from a host pointer
> -   (typically a TLB entry) back to a ram offset.  */
> -ram_addr_t qemu_ram_addr_from_host_nofail(void *ptr)
> -{
> -ram_addr_t ram_addr;
> -
> -if (qemu_ram_addr_from_host(ptr, &ram_addr)) {
> -fprintf(stderr, "Bad ram pointer %p\n", ptr);
> -abort();
> -}
> -return ram_addr;
> -}
> -
>  static void notdirty_mem_write(void *opaque, hwaddr ram_addr,
> uint64_t val, unsigned size)
>  {
> @@ -2129,7 +2118,8 @@ void address_space_unmap(AddressSpace *as, void 
> *buffer, hwaddr len,
>  {
>  if (buffer != bounce.buffer) {
>  if (is_write) {
> -ram_addr_t addr1 = qemu_ram_addr_from_host_nofail(buffer);
> +ram_addr_t addr1;
> +qemu_ram_addr_from_host(buffer, &addr1);

assert() that it succeeds? There remains the risk someone passes an
invalid buffer address.

Ah, wait, you'll do this in patch 11. Well, OK.

>  while (access_len) {
>  unsigned l;
>  l = TARGET_PAGE_SIZE;
> diff --git a/include/exec/cpu-common.h b/include/exec/cpu-common.h
> index e061e21..8063ba2 100644
> --- a/include/exec/cpu-common.h
> +++ b/include/exec/cpu-common.h
> @@ -51,7 +51,6 @@ typedef uint32_t CPUReadMemoryFunc(void *opaque, hwaddr 
> addr);
>  void qemu_ram_remap(ram_addr_t addr, ram_addr_t length);
>  /* This should not be used by devices.  */
>  int qemu_ram_addr_from_host(void *ptr, ram_addr_t *ram_addr);
> -ram_addr_t qemu_ram_addr_from_host_nofail(void *ptr);
>  void qemu_ram_set_idstr(ram_addr_t addr, const char *name, DeviceState *dev);
>  
>  void cpu_physical_memory_rw(hwaddr addr, uint8_t *buf,
> 

Reviewed-by: Jan Kiszka 

Jan

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



Re: [Qemu-devel] [PATCH v2 06/11] memory: add ref/unref calls

2013-07-01 Thread Jan Kiszka
On 2013-06-28 18:58, Paolo Bonzini wrote:
> Add ref/unref calls at the following places:
> 
> - places where memory regions are stashed by a listener and
>   used outside the BQL (including in Xen or KVM).
> 
> - memory_region_find callsites

You missed some recently added ones. Check hw/acpi/piix4.c and
hw/isa/lpc_ich9.c (both will require some refactorings for this).

> 
> - creation of aliases and containers (only the aliased/contained
>   region gets a reference to avoid loops)
> 
> - around calls to del_subregion/add_subregion, where the region
>   could disappear after the first call
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  exec.c|  3 +++
>  hw/core/loader.c  |  1 +
>  hw/display/exynos4210_fimd.c  |  6 ++
>  hw/display/framebuffer.c  | 12 +++-
>  hw/i386/kvmvapic.c|  1 +
>  hw/misc/vfio.c|  2 ++
>  hw/virtio/dataplane/hostmem.c |  7 +++
>  hw/virtio/vhost.c |  2 ++
>  hw/virtio/virtio-balloon.c|  1 +
>  hw/xen/xen_pt.c   |  4 
>  include/hw/virtio/dataplane/hostmem.h |  1 +
>  kvm-all.c |  2 ++
>  memory.c  | 20 
>  target-arm/kvm.c  |  2 ++
>  target-sparc/mmu_helper.c |  1 +
>  xen-all.c |  2 ++
>  16 files changed, 62 insertions(+), 5 deletions(-)
> 
> diff --git a/exec.c b/exec.c
> index 9c77285..8722420 100644
> --- a/exec.c
> +++ b/exec.c
> @@ -771,11 +771,14 @@ static uint16_t phys_section_add(MemoryRegionSection 
> *section)
>  phys_sections_nb_alloc);
>  }
>  phys_sections[phys_sections_nb] = *section;
> +memory_region_ref(section->mr);
>  return phys_sections_nb++;
>  }
> 
>  static void phys_section_destroy(MemoryRegion *mr)
>  {
> +memory_region_unref(mr);
> +
>  if (mr->subpage) {
>  subpage_t *subpage = container_of(mr, subpage_t, iomem);
>  memory_region_destroy(&subpage->iomem);
> diff --git a/hw/core/loader.c b/hw/core/loader.c
> index d569636..44311ff 100644
> --- a/hw/core/loader.c
> +++ b/hw/core/loader.c
> @@ -727,6 +727,7 @@ int rom_load_all(void)
>  addr += rom->romsize;
>  section = memory_region_find(get_system_memory(), rom->addr, 1);
>  rom->isrom = int128_nz(section.size) && 
> memory_region_is_rom(section.mr);
> +memory_region_unref(section.mr);
>  }
>  qemu_register_reset(rom_reset, NULL);
>  roms_loaded = 1;
> diff --git a/hw/display/exynos4210_fimd.c b/hw/display/exynos4210_fimd.c
> index d9088d9..b520f52 100644
> --- a/hw/display/exynos4210_fimd.c
> +++ b/hw/display/exynos4210_fimd.c
> @@ -1126,6 +1126,11 @@ static void 
> fimd_update_memory_section(Exynos4210fimdState *s, unsigned win)
>  /* Total number of bytes of virtual screen used by current window */
>  w->fb_len = fb_mapped_len = (w->virtpage_width + w->virtpage_offsize) *
>  (w->rightbot_y - w->lefttop_y + 1);
> +
> +/* TODO: add .exit and unref the region there.  Not needed yet since 
> sysbus
> + * does not support hot-unplug.
> + */
> +memory_region_unref(w->mem_section.mr);
>  w->mem_section = memory_region_find(sysbus_address_space(&s->busdev),
>  fb_start_addr, w->fb_len);
>  assert(w->mem_section.mr);
> @@ -1154,6 +1159,7 @@ static void 
> fimd_update_memory_section(Exynos4210fimdState *s, unsigned win)
>  return;
> 
>  error_return:
> +memory_region_unref(w->mem_section.mr);
>  w->mem_section.mr = NULL;
>  w->mem_section.size = int128_zero();
>  w->host_fb_addr = NULL;
> diff --git a/hw/display/framebuffer.c b/hw/display/framebuffer.c
> index 49c9e59..4546e42 100644
> --- a/hw/display/framebuffer.c
> +++ b/hw/display/framebuffer.c
> @@ -54,11 +54,11 @@ void framebuffer_update_display(
>  src_len = src_width * rows;
> 
>  mem_section = memory_region_find(address_space, base, src_len);
> +mem = mem_section.mr;
>  if (int128_get64(mem_section.size) != src_len ||
>  !memory_region_is_ram(mem_section.mr)) {
> -return;
> +goto out;
>  }
> -mem = mem_section.mr;
>  assert(mem);
>  assert(mem_section.offset_within_address_space == base);
> 
> @@ -68,10 +68,10 @@ void framebuffer_update_display(
> but it's not really worth it as dirty flag tracking will probably
> already have failed above.  */
>  if (!src_base)
> -return;
> +goto out;
>  if (src_len != src_width * rows) {
>  cpu_physical_memory_unmap(src_base, src_len, 0, 0);
> -return;
> +goto out;
>  }
>  src = src_base;
>  dest = surface_data(ds);
> @@ -102,10 +102,12 @@ void framebuffer_update_display(
>  }
>  cpu_physical_memory_unmap(src_base, src_len, 0, 0);
>  if (first < 0) {
> -

[Qemu-devel] [PATCH v5 12/21] linux-user: Fix up AArch64 syscall handlers

2013-07-01 Thread Peter Maydell
From: Alexander Graf 

Some syscall handlers have special code for ARM enabled that we don't
need on AArch64. Exclude AArch64 in those cases. In other places we
can share struct definitions with other targets or have to provide our
own.

With this patch applied, most syscall definitions in linux-user should
be sound for AArch64.

Signed-off-by: Alexander Graf 
Signed-off-by: John Rigby 
Message-id: 1368505980-17151-9-git-send-email-john.ri...@linaro.org
Signed-off-by: Peter Maydell 
---
 linux-user/syscall.c  |5 +++--
 linux-user/syscall_defs.h |   28 ++--
 2 files changed, 29 insertions(+), 4 deletions(-)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index cdd0c28..802ec95 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -4695,7 +4695,7 @@ static inline abi_long host_to_target_stat64(void 
*cpu_env,
  abi_ulong target_addr,
  struct stat *host_st)
 {
-#ifdef TARGET_ARM
+#if defined(TARGET_ARM) && defined(TARGET_ABI32)
 if (((CPUARMState *)cpu_env)->eabi) {
 struct target_eabi_stat64 *target_st;
 
@@ -6327,7 +6327,8 @@ abi_long do_syscall(void *cpu_env, int num, abi_long arg1,
 #endif
 #ifdef TARGET_NR_mmap
 case TARGET_NR_mmap:
-#if (defined(TARGET_I386) && defined(TARGET_ABI32)) || defined(TARGET_ARM) || \
+#if (defined(TARGET_I386) && defined(TARGET_ABI32)) || \
+(defined(TARGET_ARM) && defined(TARGET_ABI32)) || \
 defined(TARGET_M68K) || defined(TARGET_CRIS) || defined(TARGET_MICROBLAZE) 
\
 || defined(TARGET_S390X)
 {
diff --git a/linux-user/syscall_defs.h b/linux-user/syscall_defs.h
index 92c01a9..08f7559 100644
--- a/linux-user/syscall_defs.h
+++ b/linux-user/syscall_defs.h
@@ -1137,7 +1137,8 @@ struct target_winsize {
 #define TARGET_MAP_UNINITIALIZED 0x400 /* for anonymous mmap, memory 
could be uninitialized */
 #endif
 
-#if (defined(TARGET_I386) && defined(TARGET_ABI32)) || defined(TARGET_ARM) \
+#if (defined(TARGET_I386) && defined(TARGET_ABI32)) \
+|| (defined(TARGET_ARM) && defined(TARGET_ABI32)) \
 || defined(TARGET_CRIS) || defined(TARGET_UNICORE32) \
 || defined(TARGET_OPENRISC)
 struct target_stat {
@@ -1836,6 +1837,28 @@ struct target_stat {
 abi_long   st_blocks;
 abi_ulong  __unused[3];
 };
+#elif defined(TARGET_AARCH64)
+struct target_stat {
+abi_ulong  st_dev;
+abi_ulong  st_ino;
+unsigned int st_mode;
+unsigned int st_nlink;
+unsigned int   st_uid;
+unsigned int   st_gid;
+abi_ulong  st_rdev;
+abi_ulong  _pad1;
+abi_long  st_size;
+intst_blksize;
+int__pad2;
+abi_long   st_blocks;
+abi_long  target_st_atime;
+abi_ulong  target_st_atime_nsec;
+abi_long  target_st_mtime;
+abi_ulong  target_st_mtime_nsec;
+abi_long  target_st_ctime;
+abi_ulong  target_st_ctime_nsec;
+unsigned int __unused[2];
+};
 #elif defined(TARGET_OPENRISC)
 struct target_stat {
 abi_ulong st_dev;
@@ -1918,7 +1941,8 @@ struct target_statfs64 {
uint32_tf_spare[6];
 };
 #elif (defined(TARGET_PPC64) || defined(TARGET_X86_64) || \
-   defined(TARGET_SPARC64)) && !defined(TARGET_ABI32)
+   defined(TARGET_SPARC64) || defined(TARGET_AARCH64)) && \
+   !defined(TARGET_ABI32)
 struct target_statfs {
abi_long f_type;
abi_long f_bsize;
-- 
1.7.9.5




Re: [Qemu-devel] [PATCH 6/6] Added SMP for Aarch64 Processors.

2013-07-01 Thread Alexander Spyridakis
On 29 June 2013 21:24, Peter Maydell  wrote:
> On 28 June 2013 13:11, Mian M. Hamayun  
> wrote:
>> From: Alexander Spyridakis 
>>
>> AArch64 uses a cpu-release-addr memory location (defined in the dts) as
>> a way to inform secondary CPUs where to jump to and enter their holding
>> pen. Inject a very simple bootloader that polls this memory location,
>> until the primary CPU sets it to the right address.
>
> This and the previous patch are a bit heavy on the #ifdef TARGET_AARCH64.
> I suspect the code could be restructured better to avoid that.

Fair point. Initially it was even heavier on the #ifdef usage, and for
the first version we opted for something in-between in order to get
comments first. Next version will improve this with some further
restructuring.

Regards.



Re: [Qemu-devel] [PATCH 4/6] Added the Versatile Express Machine Model for A57

2013-07-01 Thread Alexander Spyridakis
On 29 June 2013 21:21, Peter Maydell  wrote:
> On 28 June 2013 13:11, Mian M. Hamayun  
> wrote:
> > From: "Mian M. Hamayun" 
> >
> > The vexpress model for A57 is based on the A15 machine model with a few
> > changes in the daughterboard initialization (using a subset of A15
> > functionality). The A57 daughterboard init also shares the A15MPCore
> > private memory region with A15 daughterboard init function.
>
> So, which documentation or TRM or hardware are you basing this
> definition of an A57 Versatile Express daughterboard on?

Currently there is no existing hardware that I am aware of, or a
public TRM describing it. On existing ARMv8 models the peripherals
used and the platform memory map seems to be identical with the
previous iteration. Based on that, the same approach was followed to
have a working setup, on which to base further development when
another target is available.



[Qemu-devel] [PATCH v5 19/21] configure: Add handling code for AArch64 targets

2013-07-01 Thread Peter Maydell
From: Alexander Graf 

Add the necessary code to configure to handle AArch64 as a target
CPU (we already have some code for supporting it as host). Note
that this doesn't enable the AArch64 targets yet.

Signed-off-by: Alexander Graf 
Signed-off-by: John Rigby 
Message-id: 1368505980-17151-12-git-send-email-john.ri...@linaro.org
[PMM:
 * don't need to set TARGET_ABI_DIR to aarch64 as that is the default
 * don't build nwfpe -- this is 32 bit legacy only
 * rewrite commit message
 * add aarch64 to the list of "fdt required" targets
]
Signed-off-by: Peter Maydell 
---
 configure |9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 0e0adde..2f83771 100755
--- a/configure
+++ b/configure
@@ -2491,7 +2491,7 @@ fi
 fdt_required=no
 for target in $target_list; do
   case $target in
-arm*-softmmu|ppc*-softmmu|microblaze*-softmmu)
+aarch64*-softmmu|arm*-softmmu|ppc*-softmmu|microblaze*-softmmu)
   fdt_required=yes
 ;;
   esac
@@ -4169,6 +4169,13 @@ case "$target_name" in
 target_nptl="yes"
 gdb_xml_files="arm-core.xml arm-vfp.xml arm-vfp3.xml arm-neon.xml"
   ;;
+  aarch64)
+TARGET_BASE_ARCH=arm
+bflt="yes"
+target_nptl="yes"
+gdb_xml_files="aarch64-core.xml aarch64-fpu.xml"
+target_long_alignment=8
+  ;;
   cris)
 target_nptl="yes"
   ;;
-- 
1.7.9.5




[Qemu-devel] [PATCH v5 02/21] target-arm: Extract the disas struct to a header file

2013-07-01 Thread Peter Maydell
From: Alexander Graf 

We will need to share the disassembly status struct between AArch32 and
AArch64 modes. So put it into a header file that both sides can use.

Signed-off-by: Alexander Graf 
Signed-off-by: John Rigby 
Message-id: 1368505980-17151-2-git-send-email-john.ri...@linaro.org
Signed-off-by: Peter Maydell 
---
 target-arm/translate.c |   24 +---
 target-arm/translate.h |   27 +++
 2 files changed, 28 insertions(+), 23 deletions(-)
 create mode 100644 target-arm/translate.h

diff --git a/target-arm/translate.c b/target-arm/translate.c
index 1618524..1a9c1a0 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -45,29 +45,7 @@
 
 #define ARCH(x) do { if (!ENABLE_ARCH_##x) goto illegal_op; } while(0)
 
-/* internal defines */
-typedef struct DisasContext {
-target_ulong pc;
-int is_jmp;
-/* Nonzero if this instruction has been conditionally skipped.  */
-int condjmp;
-/* The label that will be jumped to when the instruction is skipped.  */
-int condlabel;
-/* Thumb-2 conditional execution bits.  */
-int condexec_mask;
-int condexec_cond;
-struct TranslationBlock *tb;
-int singlestep_enabled;
-int thumb;
-int bswap_code;
-#if !defined(CONFIG_USER_ONLY)
-int user;
-#endif
-int vfp_enabled;
-int vec_len;
-int vec_stride;
-} DisasContext;
-
+#include "translate.h"
 static uint32_t gen_opc_condexec_bits[OPC_BUF_SIZE];
 
 #if defined(CONFIG_USER_ONLY)
diff --git a/target-arm/translate.h b/target-arm/translate.h
new file mode 100644
index 000..e727bc6
--- /dev/null
+++ b/target-arm/translate.h
@@ -0,0 +1,27 @@
+#ifndef TARGET_ARM_TRANSLATE_H
+#define TARGET_ARM_TRANSLATE_H
+
+/* internal defines */
+typedef struct DisasContext {
+target_ulong pc;
+int is_jmp;
+/* Nonzero if this instruction has been conditionally skipped.  */
+int condjmp;
+/* The label that will be jumped to when the instruction is skipped.  */
+int condlabel;
+/* Thumb-2 conditional execution bits.  */
+int condexec_mask;
+int condexec_cond;
+struct TranslationBlock *tb;
+int singlestep_enabled;
+int thumb;
+int bswap_code;
+#if !defined(CONFIG_USER_ONLY)
+int user;
+#endif
+int vfp_enabled;
+int vec_len;
+int vec_stride;
+} DisasContext;
+
+#endif /* TARGET_ARM_TRANSLATE_H */
-- 
1.7.9.5




Re: [Qemu-devel] [PATCH RFC qom-cpu 23/41] target-xtensa: Change gen_intermediate_code_internal() arg to XtensaCPU

2013-07-01 Thread Richard Henderson
On 07/01/2013 10:51 AM, Andreas Färber wrote:
> I wonder, all targets seem to implement the same pattern of passing a
> hard-coded bool argument to their internal function.
> 
> Is there any reason not to have translate-all.c call the function with
> that true/false directly?

The idea is to avoid runtime checks for the rare search_pc case.

Instead we pass constants to inline functions and transform what would be
runtime checks into compile-time optimized code paths.



r~



Re: [Qemu-devel] [PATCH RFC qom-cpu 41/41] cpu: Introduce CPUClass::gdb_{read, write}_register()

2013-07-01 Thread Richard Henderson
On 06/29/2013 01:01 PM, Andreas Färber wrote:
> Replace GET_REG*() macros by gdb_get_reg*() inline functions for
> clarity and drop breaks after return.
> 
> Allows to move target-specific code to new target-*/gdbstub.c files.
> 
> Signed-off-by: Andreas Färber 

This one's quite hard to read.

I wonder if there's value in splitting out functions one target at a time into
the new gdbstub.c files, and only afterward performing a few minor textual
changes to transform those functions into the CPUClass methods?


r~



Re: [Qemu-devel] [PATCH 3/6] Added Aarch64 CPU Initialization, Get and Put Registers Support.

2013-07-01 Thread Alexander Spyridakis
On 29 June 2013 21:17, Peter Maydell  wrote:
>
> > +#ifdef TARGET_AARCH64
> > +int kvm_arch_init_vcpu(CPUState *cs)
> > +{
> > +struct kvm_vcpu_init init;
> > +int ret;
> > +
> > +/* Try initializing with Foundation Models */
> > +init.target = KVM_ARM_TARGET_FOUNDATION_V8;
> > +memset(init.features, 0, sizeof(init.features));
> > +ret = kvm_vcpu_ioctl(cs, KVM_ARM_VCPU_INIT, &init);
> > +if (ret) {
> > +/* Retry initializing with Fast Models */
> > +init.target = KVM_ARM_TARGET_AEM_V8;
>
> If we're emulating an A57 we should be asking KVM for an A57
> guest. If we're asking KVM for "a CPU like the one in
> the Foundation model" we need to support that via -cpu $something.

Wouldn't that be an overkill at this early stage? There is no target
to test KVM_ARM_TARGET_CORTEX_A57 so we opted for the other two tested
cases.

> But I'm a bit dubious about that anyway -- you need to provide
> a good justification for why KVM/QEMU should be emulating
> emulators and not hardware.

Mainly because there is no real hardware yet. This patch series was
meant to enable basic working support of KVM in AArch64 on what is
available and open discussion on how to proceed from there. Also,
given that fact that kvmtool uses the same approach it was the most
obvious way at the time to handle it.



[Qemu-devel] [PATCH v5 04/21] target-arm: Fix target_ulong/uint32_t confusions

2013-07-01 Thread Peter Maydell
From: Alexander Graf 

Correct a few places that were using uint32_t or a 32 bit
only format string to handle something that should be a target_ulong.

Signed-off-by: Alexander Graf 
Signed-off-by: John Rigby 
[PMM: split out to separate patch; added gen_goto_tb() and
gen_set_pc_im() dest params to list of things to change.]
Signed-off-by: Peter Maydell 
---
 target-arm/cpu.h   |4 ++--
 target-arm/translate.c |9 +
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/target-arm/cpu.h b/target-arm/cpu.h
index abcc0b4..1f3beac 100644
--- a/target-arm/cpu.h
+++ b/target-arm/cpu.h
@@ -816,7 +816,7 @@ static inline void cpu_pc_from_tb(CPUARMState *env, 
TranslationBlock *tb)
 }
 
 /* Load an instruction and return it in the standard little-endian order */
-static inline uint32_t arm_ldl_code(CPUARMState *env, uint32_t addr,
+static inline uint32_t arm_ldl_code(CPUARMState *env, target_ulong addr,
 bool do_swap)
 {
 uint32_t insn = cpu_ldl_code(env, addr);
@@ -827,7 +827,7 @@ static inline uint32_t arm_ldl_code(CPUARMState *env, 
uint32_t addr,
 }
 
 /* Ditto, for a halfword (Thumb) instruction */
-static inline uint16_t arm_lduw_code(CPUARMState *env, uint32_t addr,
+static inline uint16_t arm_lduw_code(CPUARMState *env, target_ulong addr,
  bool do_swap)
 {
 uint16_t insn = cpu_lduw_code(env, addr);
diff --git a/target-arm/translate.c b/target-arm/translate.c
index a6c2cf9..02319b3 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -903,7 +903,7 @@ DO_GEN_ST(st8)
 DO_GEN_ST(st16)
 DO_GEN_ST(st32)
 
-static inline void gen_set_pc_im(uint32_t val)
+static inline void gen_set_pc_im(target_ulong val)
 {
 tcg_gen_movi_i32(cpu_R[15], val);
 }
@@ -3411,7 +3411,7 @@ static int disas_vfp_insn(CPUARMState * env, DisasContext 
*s, uint32_t insn)
 return 0;
 }
 
-static inline void gen_goto_tb(DisasContext *s, int n, uint32_t dest)
+static inline void gen_goto_tb(DisasContext *s, int n, target_ulong dest)
 {
 TranslationBlock *tb;
 
@@ -9869,7 +9869,7 @@ static inline void 
gen_intermediate_code_internal(CPUARMState *env,
 uint16_t *gen_opc_end;
 int j, lj;
 target_ulong pc_start;
-uint32_t next_page_start;
+target_ulong next_page_start;
 int num_insns;
 int max_insns;
 
@@ -10023,7 +10023,8 @@ static inline void 
gen_intermediate_code_internal(CPUARMState *env,
 }
 
 if (tcg_check_temp_count()) {
-fprintf(stderr, "TCG temporary leak before %08x\n", dc->pc);
+fprintf(stderr, "TCG temporary leak before "TARGET_FMT_lx"\n",
+dc->pc);
 }
 
 /* Translation stops when a conditional branch is encountered.
-- 
1.7.9.5




[Qemu-devel] [PATCH v5 16/21] linux-user: Add AArch64 termbits.h definitions

2013-07-01 Thread Peter Maydell
From: Alexander Graf 

Add the AArch64 termbits.h with all the target's termios related
constants and structures.

Signed-off-by: Alexander Graf 
Signed-off-by: John Rigby 
[PMM: split out from another patch]
Signed-off-by: Peter Maydell 
---
 linux-user/aarch64/termbits.h |  220 +
 1 file changed, 220 insertions(+)
 create mode 100644 linux-user/aarch64/termbits.h

diff --git a/linux-user/aarch64/termbits.h b/linux-user/aarch64/termbits.h
new file mode 100644
index 000..b64ba97
--- /dev/null
+++ b/linux-user/aarch64/termbits.h
@@ -0,0 +1,220 @@
+/* from asm/termbits.h */
+/* NOTE: exactly the same as i386 */
+
+#define TARGET_NCCS 19
+
+struct target_termios {
+unsigned int c_iflag;   /* input mode flags */
+unsigned int c_oflag;   /* output mode flags */
+unsigned int c_cflag;   /* control mode flags */
+unsigned int c_lflag;   /* local mode flags */
+unsigned char c_line;/* line discipline */
+unsigned char c_cc[TARGET_NCCS];/* control characters */
+};
+
+/* c_iflag bits */
+#define TARGET_IGNBRK  001
+#define TARGET_BRKINT  002
+#define TARGET_IGNPAR  004
+#define TARGET_PARMRK  010
+#define TARGET_INPCK   020
+#define TARGET_ISTRIP  040
+#define TARGET_INLCR   100
+#define TARGET_IGNCR   200
+#define TARGET_ICRNL   400
+#define TARGET_IUCLC   0001000
+#define TARGET_IXON0002000
+#define TARGET_IXANY   0004000
+#define TARGET_IXOFF   001
+#define TARGET_IMAXBEL 002
+#define TARGET_IUTF8   004
+
+/* c_oflag bits */
+#define TARGET_OPOST   001
+#define TARGET_OLCUC   002
+#define TARGET_ONLCR   004
+#define TARGET_OCRNL   010
+#define TARGET_ONOCR   020
+#define TARGET_ONLRET  040
+#define TARGET_OFILL   100
+#define TARGET_OFDEL   200
+#define TARGET_NLDLY   400
+#define   TARGET_NL0   000
+#define   TARGET_NL1   400
+#define TARGET_CRDLY   0003000
+#define   TARGET_CR0   000
+#define   TARGET_CR1   0001000
+#define   TARGET_CR2   0002000
+#define   TARGET_CR3   0003000
+#define TARGET_TABDLY  0014000
+#define   TARGET_TAB0  000
+#define   TARGET_TAB1  0004000
+#define   TARGET_TAB2  001
+#define   TARGET_TAB3  0014000
+#define   TARGET_XTABS 0014000
+#define TARGET_BSDLY   002
+#define   TARGET_BS0   000
+#define   TARGET_BS1   002
+#define TARGET_VTDLY   004
+#define   TARGET_VT0   000
+#define   TARGET_VT1   004
+#define TARGET_FFDLY   010
+#define   TARGET_FF0   000
+#define   TARGET_FF1   010
+
+/* c_cflag bit meaning */
+#define TARGET_CBAUD   0010017
+#define  TARGET_B0 000 /* hang up */
+#define  TARGET_B50001
+#define  TARGET_B75002
+#define  TARGET_B110   003
+#define  TARGET_B134   004
+#define  TARGET_B150   005
+#define  TARGET_B200   006
+#define  TARGET_B300   007
+#define  TARGET_B600   010
+#define  TARGET_B1200  011
+#define  TARGET_B1800  012
+#define  TARGET_B2400  013
+#define  TARGET_B4800  014
+#define  TARGET_B9600  015
+#define  TARGET_B19200 016
+#define  TARGET_B38400 017
+#define TARGET_EXTA B19200
+#define TARGET_EXTB B38400
+#define TARGET_CSIZE   060
+#define   TARGET_CS5   000
+#define   TARGET_CS6   020
+#define   TARGET_CS7   040
+#define   TARGET_CS8   060
+#define TARGET_CSTOPB  100
+#define TARGET_CREAD   200
+#define TARGET_PARENB  400
+#define TARGET_PARODD  0001000
+#define TARGET_HUPCL   0002000
+#define TARGET_CLOCAL  0004000
+#define TARGET_CBAUDEX 001
+#define  TARGET_B57600  0010001
+#define  TARGET_B115200 0010002
+#define  TARGET_B230400 0010003
+#define  TARGET_B460800 0010004
+#define TARGET_CIBAUD00200360  /* input baud rate (not used) */
+#define TARGET_CMSPAR0100  /* mark or space (stick) parity */
+#define TARGET_CRTSCTS   0200  /* flow control */
+
+/* c_lflag bits */
+#define TARGET_ISIG001
+#define TARGET_ICANON  002
+#define TARGET_XCASE   004
+#define TARGET_ECHO010
+#define TARGET_ECHOE   020
+#define TARGET_ECHOK   040
+#define TARGET_ECHONL  100
+#define TARGET_NOFLSH  200
+#define TARGET_TOSTOP  400
+#define TARGET_ECHOCTL 0001000
+#define TARGET_ECHOPRT 0002000
+#define TARGET_ECHOKE  0004000
+#define TARGET_FLUSHO  001
+#define TARGET_PENDIN  004
+#define TARGET_IEXTEN  010
+
+/* c_cc character offsets */
+#define TARGET_VINTR0
+#define TARGET_VQUIT1
+#define TARGET_VERASE   2
+#define TARGET_VKILL3
+#define TARGET_VEOF 4
+#define TARGET_VTIME5
+#define TARGET_VMIN 6
+#define TARGET_VSWTC7
+#define TARGET_VSTART   8
+#define TARGET_VSTOP9
+#define TARGET_VSUSP10
+#define TARGET_VEOL 11
+#define TARGET_VREPRINT 12
+#define TARGET_VDISCARD 13
+#define TARGET_VWERASE  14
+#define TARGET_VLNEXT   15
+#define TARGE

Re: [Qemu-devel] [PATCH v4 08/10] qemu-ga: call Windows VSS requester in fsfreeze command handler

2013-07-01 Thread Eric Blake
On 07/01/2013 07:29 AM, Laszlo Ersek wrote:
> some comments below
> 
> On 06/06/13 17:06, Tomoki Sekiyama wrote:
>> Support guest-fsfreeze-freeze and guest-fsfreeze-thaw commands for Windows
>> guests. When fsfreeze command is issued, it calls the VSS requester to
>> freeze filesystems and applications. On thaw command, it again tells the VSS
>> requester to thaw them.
>>

>>  int64_t qmp_guest_fsfreeze_thaw(Error **err)
>>  {
>> +int i;
>> +
>> +if (!vss_initialized()) {
>> +error_set(err, QERR_UNSUPPORTED);
>> +return 0;
>> +}
>> +
>> +qga_vss_fsfreeze_thaw(&i, err);
> 
> I wonder how libvirt interprets a failure to thaw -- does it expect
> filesystems to remain frozen? (CC'ing Eric.)

On failure to thaw, libvirt marks the virDomainSnapshotCreateXML() API
call as failed, and logs the failure returned from the guest agent; but
beyond that, there really isn't anything further that libvirt can
attempt.  Guest freeze/thaw is a best-effort attempt, and we don't
really have any clean way to recover from a non-cooperative guest (ie.
it's no different from a Linux guest managing to kill off the guest
agent daemon in the guest at the wrong time).  In short, a failed
snapshot request has no guarantees on whether the guest is frozen or
thawed, and libvirt currently has no additional support to try a thaw in
isolation (although there is an intentionally unsupported 'virsh
qemu-agent-command' for attempting recovery manually).

> ... This patch made me look at ga_command_state_cleanup_all().
> Apparently the POSIX flavor thaws filesystems if qemu-ga exits before a
> thaw command over QMP; see guest_fsfreeze_cleanup() and
> ga_command_state_init(). Do you think something similar would be useful
> for the Windows flavor as well?

I agree that it is better to try and clean up a thaw on any error case
(including the error of qemu-ga exiting without seeing a QMP thaw
request), if only to minimize the chance of failure leaving the system
wedged with no chance of further recovery attempts.

-- 
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 v4 09/10] qemu-ga: install Windows VSS provider on `qemu-ga -s install'

2013-07-01 Thread Tomoki Sekiyama
On 7/1/13 10:50 , "Laszlo Ersek"  wrote:

>On 06/06/13 17:06, Tomoki Sekiyama wrote:
>>+#ifdef HAS_VSS_SDK
>> +if (FAILED(COMRegister())) {
>> +return EXIT_FAILURE;
>> +}
>
>COMRegister() seems to print error messages on failure, OK.
>
>> +#endif
>>  return ga_install_service(path, log_filepath,
>>fixed_state_dir);
>
>Shouldn't you call COMUnregister() if ga_install_service() fails?
>Otherwise we might end up with a half-installed service (COM app catalog
>entry for VSS provider: yes, VSS provider DLL: yes, VSS client / qemu-ga
>service: no).

Agreed. I will fix this.

Thanks,
Tomoki Sekiyama




[Qemu-devel] [PATCH v5 07/21] target-arm: Add AArch64 translation stub

2013-07-01 Thread Peter Maydell
From: Alexander Graf 

We should translate AArch64 mode separately from AArch32 mode. In AArch64 mode,
registers look vastly different, instruction encoding is completely different,
basically the system turns into a different machine.

So let's do a simple if() in translate.c to decide whether we can handle the
current code in the legacy AArch32 code or in the new AArch64 code.

So far, the translation always complains about unallocated instructions. There
is no emulator functionality in this patch!

Signed-off-by: Alexander Graf 
Signed-off-by: John Rigby 
Message-id: 1368505980-17151-5-git-send-email-john.ri...@linaro.org
[PMM:
 * provide no-op versions of a64 functions ifndef TARGET_AARCH64;
   this lets us avoid #ifdefs in translate.c
 * insert the missing call to disas_a64_insn()
]
Signed-off-by: Peter Maydell 
---
 target-arm/Makefile.objs   |1 +
 target-arm/translate-a64.c |  137 
 target-arm/translate.c |   19 +-
 target-arm/translate.h |   25 
 4 files changed, 179 insertions(+), 3 deletions(-)
 create mode 100644 target-arm/translate-a64.c

diff --git a/target-arm/Makefile.objs b/target-arm/Makefile.objs
index 4a6e52e..3378eb8 100644
--- a/target-arm/Makefile.objs
+++ b/target-arm/Makefile.objs
@@ -4,3 +4,4 @@ obj-$(CONFIG_KVM) += kvm.o
 obj-$(CONFIG_NO_KVM) += kvm-stub.o
 obj-y += translate.o op_helper.o helper.o cpu.o
 obj-y += neon_helper.o iwmmxt_helper.o
+obj-$(TARGET_AARCH64) += translate-a64.o
diff --git a/target-arm/translate-a64.c b/target-arm/translate-a64.c
new file mode 100644
index 000..29e8937
--- /dev/null
+++ b/target-arm/translate-a64.c
@@ -0,0 +1,137 @@
+/*
+ *  AArch64 translation
+ *
+ *  Copyright (c) 2013 Alexander Graf 
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "cpu.h"
+#include "tcg-op.h"
+#include "qemu/log.h"
+#include "translate.h"
+#include "qemu/host-utils.h"
+
+#include "helper.h"
+#define GEN_HELPER 1
+#include "helper.h"
+
+static TCGv_i64 cpu_X[32];
+static TCGv_i64 cpu_pc;
+static TCGv_i32 pstate;
+
+static const char *regnames[] = {
+"x0", "x1", "x2", "x3", "x4", "x5", "x6", "x7",
+"x8", "x9", "x10", "x11", "x12", "x13", "x14", "x15",
+"x16", "x17", "x18", "x19", "x20", "x21", "x22", "x23",
+"x24", "x25", "x26", "x27", "x28", "x29", "lr", "sp"
+};
+
+/* initialize TCG globals.  */
+void a64_translate_init(void)
+{
+int i;
+
+cpu_pc = tcg_global_mem_new_i64(TCG_AREG0,
+offsetof(CPUARMState, pc),
+"pc");
+for (i = 0; i < 32; i++) {
+cpu_X[i] = tcg_global_mem_new_i64(TCG_AREG0,
+  offsetof(CPUARMState, xregs[i]),
+  regnames[i]);
+}
+
+pstate = tcg_global_mem_new_i32(TCG_AREG0,
+offsetof(CPUARMState, pstate),
+"pstate");
+}
+
+void cpu_dump_state_a64(CPUARMState *env, FILE *f, fprintf_function 
cpu_fprintf,
+int flags)
+{
+int i;
+
+cpu_fprintf(f, "PC=%016"PRIx64"  SP=%016"PRIx64"\n",
+env->pc, env->xregs[31]);
+for (i = 0; i < 31; i++) {
+cpu_fprintf(f, "X%02d=%016"PRIx64, i, env->xregs[i]);
+if ((i % 4) == 3) {
+cpu_fprintf(f, "\n");
+} else {
+cpu_fprintf(f, " ");
+}
+}
+cpu_fprintf(f, "PSTATE=%c%c%c%c\n",
+env->pstate & PSTATE_N ? 'n' : '.',
+env->pstate & PSTATE_Z ? 'z' : '.',
+env->pstate & PSTATE_C ? 'c' : '.',
+env->pstate & PSTATE_V ? 'v' : '.');
+cpu_fprintf(f, "\n");
+}
+
+void gen_a64_set_pc_im(uint64_t val)
+{
+tcg_gen_movi_i64(cpu_pc, val);
+}
+
+static void gen_exception(int excp)
+{
+TCGv_i32 tmp = tcg_temp_new_i32();
+tcg_gen_movi_i32(tmp, excp);
+gen_helper_exception(cpu_env, tmp);
+tcg_temp_free_i32(tmp);
+}
+
+static void gen_exception_insn(DisasContext *s, int offset, int excp)
+{
+gen_a64_set_pc_im(s->pc - offset);
+gen_exception(excp);
+s->is_jmp = DISAS_JUMP;
+}
+
+static void real_unallocated_encoding(DisasContext *s)
+{
+fprintf(stderr, "Unknown instruction: %#x\n",
+arm_ldl_code(cpu_single_env, s->pc - 4, s->bswap_

Re: [Qemu-devel] [PATCH RFC qom-cpu 24/41] target-alpha: Change DisasContext::env to CPUState

2013-07-01 Thread Andreas Färber
Am 01.07.2013 19:23, schrieb Richard Henderson:
> On 06/29/2013 01:01 PM, Andreas Färber wrote:
>> -CPUAlphaState *env;
>> +AlphaCPU *cpu;
> 
> Actually, I take this back.  I'd prefer that we simply pull out the two
> variables that we need and place them in the DisasContext.  That's the way it
> should have been in the first place.

Fine with me. Do you want to send a patch based on master right away, or
should I do that in v2?

>> @@ -3394,7 +3394,7 @@ static inline void 
>> gen_intermediate_code_internal(AlphaCPU *cpu,
>>  gen_opc_end = tcg_ctx.gen_opc_buf + OPC_MAX_SIZE;
>>  
>>  ctx.tb = tb;
>> -ctx.env = env;
>> +ctx.cpu = alpha_env_get_cpu(env);
> 
> This should have been ctx.cpu = cpu anyway, apparently fixed in the next 
> patch.

Oops, I had done alpha first and then prepended the AlphaCPU propagation
alongside the other targets that needed it.

Andreas

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



Re: [Qemu-devel] [PATCH v4 08/10] qemu-ga: call Windows VSS requester in fsfreeze command handler

2013-07-01 Thread Tomoki Sekiyama
On 7/1/13 9:29 , "Laszlo Ersek"  wrote:

>>+error:
>> +qmp_guest_fsfreeze_thaw(NULL);
>
>Passing NULL here as "errp" concerns me slightly. I've been assuming
>that "errp" is never NULL due to the outermost QMP layer always wanting
>to receive errors and to serialize them.
>
>Specifically, a NULL "errp" would turn all error_set*(errp, ...) calls
>into no-ops under qmp_guest_fsfreeze_thaw(), and all error_is_set(errp)
>questions would answer with false. That said, nothing seems to be
>affected right now.
>
>Maybe a dummy local variable would be more future-proof... OTOH it would
>be stylistically questionable :)

OK, then it should be:
Error *local_err = NULL;
...
error:
qmp_guest_fsfreeze_thaw(&local_err);
if (error_is_set(&local_err)) {
error_free(local_err);
}

>>+#ifdef HAS_VSS_SDK
>> +#include "qga/vss-win32-provider.h"
>> +#include "qga/vss-win32-requester.h"
>> +#endif
>
>The protection of #include "qga/vss-win32-requester.h" is inconsistent
>between "commands-win32.c" and "qga/main.c". For now the header only
>brings in a few prototypes, which shouldn't cause trouble in
>"commands-win32.c" even without VSS. Still consistent guarding would be
>nice.

I will remove #ifdef's from qga/main.c. Instead, I will add static inline
functions that does nothing when CONFIG_VSS_SDK isn't defined.
(And vss-win32-provider.h can also be removed by stop linking the DLL.)


>... This patch made me look at ga_command_state_cleanup_all().
>Apparently the POSIX flavor thaws filesystems if qemu-ga exits before a
>thaw command over QMP; see guest_fsfreeze_cleanup() and
>ga_command_state_init(). Do you think something similar would be useful
>for the Windows flavor as well?

Hm, however the backup is automatically terminated if IVssBackupComponents
is released, it would be nice to have cleanup. I will add them.

Thanks,
Tomoki Sekiyama




Re: [Qemu-devel] [PATCH qom-cpu v3 05/14] cpu: Make first_cpu and next_cpu CPUState

2013-07-01 Thread Andreas Färber
Am 26.06.2013 19:35, schrieb Andreas Färber:
> Move next_cpu from CPU_COMMON to CPUState.
> Move first_cpu variable to qom/cpu.h.
> 
> gdbstub needs to use CPUState::env_ptr for now.
> cpu_copy() no longer needs to save and restore cpu_next.
> 
> Acked-by: Paolo Bonzini 
> [AF: Rebased, simplified cpu_copy()]
> Signed-off-by: Andreas Färber 

Squashing the following additional conversion after rebase.

Andreas

diff --git a/hw/ppc/e500.c b/hw/ppc/e500.c
index 38f7990..ff86154 100644
--- a/hw/ppc/e500.c
+++ b/hw/ppc/e500.c
@@ -500,7 +500,6 @@ static DeviceState
*ppce500_init_mpic_kvm(PPCE500Params *params,
   qemu_irq **irqs)
 {
 DeviceState *dev;
-CPUPPCState *env;
 CPUState *cs;
 int r;

@@ -512,9 +511,7 @@ static DeviceState
*ppce500_init_mpic_kvm(PPCE500Params *params,
 return NULL;
 }

-for (env = first_cpu; env != NULL; env = env->next_cpu) {
-cs = ENV_GET_CPU(env);
-
+for (cs = first_cpu; cs != NULL; cs = cs->next_cpu) {
 if (kvm_openpic_connect_vcpu(dev, cs)) {


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



Re: [Qemu-devel] [PATCH RFC qom-cpu 01/41] log: Change log_cpu_state[_mask]() argument to CPUState

2013-07-01 Thread Andreas Färber
Am 01.07.2013 19:03, schrieb Richard Henderson:
> On 06/29/2013 01:01 PM, Andreas Färber wrote:
>>  if ((env->cr[0] & CR0_PE_MASK)) {
>> +X86CPU *cpu = x86_env_get_cpu(env);
>>  static int count;
>>  
>>  qemu_log("%6d: v=%02x e=%04x i=%d cpl=%d IP=%04x:" TARGET_FMT_lx
>> @@ -1180,7 +1181,7 @@ static void do_interrupt_all(CPUX86State *env, int 
>> intno, int is_int,
>>  qemu_log(" env->regs[R_EAX]=" TARGET_FMT_lx, 
>> env->regs[R_EAX]);
>>  }
>>  qemu_log("\n");
>> -log_cpu_state(env, CPU_DUMP_CCOP);
>> +log_cpu_state(CPU(cpu), CPU_DUMP_CCOP);
> 
> Not a bug, but I'd like to know your rationale for adding X86CPU *cpu 
> variables
> as opposed to CPUState *cs variables?  Especially when the cpu variable is
> never used without the cast to CPU.

It's been a few days already, but I believe that I was preparing for
changing the function argument to X86CPU for any static helpers. So the
local variable would get dropped or replaced by a CPUX86State variable.

Generally, Anthony had veto'ed against CPU(cpu)->something, so I
introduce CPUState variables to avoid that, but if there's only one use
case like here and we stay within 80 chars then there is no strict need
for a separate variable IMO, whether FooCPU or CPUState.
Similarly, when there's just one or two short uses of CPU*State I have
chosen to not introduce an extra CPUFooState variable (e.g., set_pc).

> Otherwise,
> 
> Reviewed-by: Richard Henderson 

Thanks. If Blue or you don't have any further comments on the previous
part 10 series v3, I will queue that on qom-cpu (rebasing right now).

Andreas

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



[Qemu-devel] [PATCH v5 21/21] default-configs: Add config for aarch64-softmmu

2013-07-01 Thread Peter Maydell
Add a config for aarch64-softmmu; this enables building of this target.
The resulting executable doesn't know about any 64 bit CPUs, but all
the 32 bit CPUs and board models work.

Signed-off-by: Peter Maydell 
---
 default-configs/aarch64-softmmu.mak |   82 +++
 1 file changed, 82 insertions(+)
 create mode 100644 default-configs/aarch64-softmmu.mak

diff --git a/default-configs/aarch64-softmmu.mak 
b/default-configs/aarch64-softmmu.mak
new file mode 100644
index 000..27cbe3d
--- /dev/null
+++ b/default-configs/aarch64-softmmu.mak
@@ -0,0 +1,82 @@
+# Default configuration for arm-softmmu
+
+include pci.mak
+include usb.mak
+CONFIG_GDBSTUB_XML=y
+CONFIG_VGA=y
+CONFIG_ISA_MMIO=y
+CONFIG_NAND=y
+CONFIG_ECC=y
+CONFIG_SERIAL=y
+CONFIG_PTIMER=y
+CONFIG_SD=y
+CONFIG_MAX7310=y
+CONFIG_WM8750=y
+CONFIG_TWL92230=y
+CONFIG_TSC2005=y
+CONFIG_LM832X=y
+CONFIG_TMP105=y
+CONFIG_STELLARIS=y
+CONFIG_STELLARIS_INPUT=y
+CONFIG_STELLARIS_ENET=y
+CONFIG_SSD0303=y
+CONFIG_SSD0323=y
+CONFIG_ADS7846=y
+CONFIG_MAX111X=y
+CONFIG_SSI=y
+CONFIG_SSI_SD=y
+CONFIG_SSI_M25P80=y
+CONFIG_LAN9118=y
+CONFIG_SMC91C111=y
+CONFIG_DS1338=y
+CONFIG_PFLASH_CFI01=y
+CONFIG_PFLASH_CFI02=y
+CONFIG_MICRODRIVE=y
+CONFIG_USB_MUSB=y
+
+CONFIG_ARM9MPCORE=y
+CONFIG_ARM11MPCORE=y
+CONFIG_ARM15MPCORE=y
+
+CONFIG_ARM_GIC=y
+CONFIG_ARM_GIC_KVM=$(CONFIG_KVM)
+CONFIG_ARM_TIMER=y
+CONFIG_ARM_MPTIMER=y
+CONFIG_PL011=y
+CONFIG_PL022=y
+CONFIG_PL031=y
+CONFIG_PL041=y
+CONFIG_PL050=y
+CONFIG_PL061=y
+CONFIG_PL080=y
+CONFIG_PL110=y
+CONFIG_PL181=y
+CONFIG_PL190=y
+CONFIG_PL310=y
+CONFIG_PL330=y
+CONFIG_CADENCE=y
+CONFIG_XGMAC=y
+CONFIG_EXYNOS4=y
+CONFIG_PXA2XX=y
+CONFIG_BITBANG_I2C=y
+CONFIG_FRAMEBUFFER=y
+CONFIG_XILINX_SPIPS=y
+
+CONFIG_A9SCU=y
+CONFIG_MARVELL_88W8618=y
+CONFIG_OMAP=y
+CONFIG_TSC210X=y
+CONFIG_BLIZZARD=y
+CONFIG_ONENAND=y
+CONFIG_TUSB6010=y
+CONFIG_IMX=y
+CONFIG_MAINSTONE=y
+CONFIG_NSERIES=y
+CONFIG_REALVIEW=y
+CONFIG_ZAURUS=y
+CONFIG_ZYNQ=y
+
+CONFIG_VERSATILE_PCI=y
+CONFIG_VERSATILE_I2C=y
+
+CONFIG_SDHCI=y
-- 
1.7.9.5




[Qemu-devel] [PATCH v5 01/21] target-arm: Abstract out load/store from a vaddr in AArch32

2013-07-01 Thread Peter Maydell
AArch32 code (ie traditional 32 bit world) expects to be
able to pass a vaddr in a TCGv_i32. However when QEMU is
compiled with TARGET_LONG_BITS=32 the TCG load/store
functions take a TCGv_i64. Abstract out load/store with
a 32 bit vaddr so we have a place to put the zero extension
of the vaddr and the extension/truncation of the data value.

Apart from the function definitions most of this patch is
a simple s/tcg_gen_qemu_/gen_aa32_/.

Signed-off-by: Peter Maydell 
---
 target-arm/translate.c |  310 +++-
 1 file changed, 198 insertions(+), 112 deletions(-)

diff --git a/target-arm/translate.c b/target-arm/translate.c
index af2aef2..1618524 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -841,6 +841,90 @@ static inline void store_reg_from_load(CPUARMState *env, 
DisasContext *s,
 }
 }
 
+/* Abstractions of "generate code to do a guest load/store for
+ * AArch32", where a vaddr is always 32 bits (and is zero
+ * extended if we're a 64 bit core) and  data is also
+ * 32 bits unless specifically doing a 64 bit access.
+ * These functions work like tcg_gen_qemu_{ld,st}* except
+ * that their arguments are TCGv_i32 rather than TCGv.
+ */
+#if TARGET_LONG_BITS == 32
+
+#define DO_GEN_LD(OP)\
+static inline void gen_aa32_##OP(TCGv_i32 val, TCGv_i32 addr, int index) \
+{\
+tcg_gen_qemu_##OP(val, addr, index); \
+}
+
+#define DO_GEN_ST(OP)\
+static inline void gen_aa32_##OP(TCGv_i32 val, TCGv_i32 addr, int index) \
+{\
+tcg_gen_qemu_##OP(val, addr, index); \
+}
+
+static inline void gen_aa32_ld64(TCGv_i64 val, TCGv_i32 addr, int index)
+{
+tcg_gen_qemu_ld64(val, addr, index);
+}
+
+static inline void gen_aa32_st64(TCGv_i64 val, TCGv_i32 addr, int index)
+{
+tcg_gen_qemu_st64(val, addr, index);
+}
+
+#else
+
+#define DO_GEN_LD(OP)\
+static inline void gen_aa32_##OP(TCGv_i32 val, TCGv_i32 addr, int index) \
+{\
+TCGv addr64 = tcg_temp_new();\
+TCGv val64 = tcg_temp_new(); \
+tcg_gen_extu_i32_i64(addr64, addr);  \
+tcg_gen_qemu_##OP(val64, addr64, index); \
+tcg_temp_free(addr64);   \
+tcg_gen_trunc_i64_i32(val, val64);   \
+tcg_temp_free(val64);\
+}
+
+#define DO_GEN_ST(OP)\
+static inline void gen_aa32_##OP(TCGv_i32 val, TCGv_i32 addr, int index) \
+{\
+TCGv addr64 = tcg_temp_new();\
+TCGv val64 = tcg_temp_new(); \
+tcg_gen_extu_i32_i64(addr64, addr);  \
+tcg_gen_extu_i32_i64(val64, val);\
+tcg_gen_qemu_##OP(val64, addr64, index); \
+tcg_temp_free(addr64);   \
+tcg_temp_free(val64);\
+}
+
+static inline void gen_aa32_ld64(TCGv_i64 val, TCGv_i32 addr, int index)
+{
+TCGv addr64 = tcg_temp_new();
+tcg_gen_extu_i32_i64(addr64, addr);
+tcg_gen_qemu_ld64(val, addr64, index);
+tcg_temp_free(addr64);
+}
+
+static inline void gen_aa32_st64(TCGv_i64 val, TCGv_i32 addr, int index)
+{
+TCGv addr64 = tcg_temp_new();
+tcg_gen_extu_i32_i64(addr64, addr);
+tcg_gen_qemu_st64(val, addr64, index);
+tcg_temp_free(addr64);
+}
+
+#endif
+
+DO_GEN_LD(ld8s)
+DO_GEN_LD(ld8u)
+DO_GEN_LD(ld16s)
+DO_GEN_LD(ld16u)
+DO_GEN_LD(ld32u)
+DO_GEN_ST(st8)
+DO_GEN_ST(st16)
+DO_GEN_ST(st32)
+
 static inline void gen_set_pc_im(uint32_t val)
 {
 tcg_gen_movi_i32(cpu_R[15], val);
@@ -1070,18 +1154,20 @@ VFP_GEN_FIX(ulto)
 
 static inline void gen_vfp_ld(DisasContext *s, int dp, TCGv_i32 addr)
 {
-if (dp)
-tcg_gen_qemu_ld64(cpu_F0d, addr, IS_USER(s));
-else
-tcg_gen_qemu_ld32u(cpu_F0s, addr, IS_USER(s));
+if (dp) {
+gen_aa32_ld64(cpu_F0d, addr, IS_USER(s));
+} else {
+gen_aa32_ld32u(cpu_F0s, addr, IS_USER(s));
+}
 }
 
 static inline void gen_vfp_st(DisasContext *s, int dp, TCGv_i32 addr)
 {
-if (dp)
-tcg_gen_qemu_st64(cpu_F0d, addr, IS_USER(s));
-else
-tcg_gen_qemu_st32(cpu_F0s, addr, IS_USER(s));
+if (dp) {
+gen_aa32_st64(cpu_

[Qemu-devel] [PATCH v5 11/21] linux-user: Add syscall number definitions for AArch64

2013-07-01 Thread Peter Maydell
From: Alexander Graf 

The AArch64 syscall definitions are all publicly available in the Linux
kernel. Let's add them to our linux-user emulation target, so that we
can easily handle AArch64 syscalls.

Signed-off-by: Alexander Graf 
Signed-off-by: John Rigby 
Message-id: 1368505980-17151-8-git-send-email-john.ri...@linaro.org
[PMM: changes relating to cpu_loop() removed as they are superseded
 by an earlier patch]
Signed-off-by: Peter Maydell 
---
 linux-user/aarch64/syscall_nr.h |  323 +++
 1 file changed, 323 insertions(+)
 create mode 100644 linux-user/aarch64/syscall_nr.h

diff --git a/linux-user/aarch64/syscall_nr.h b/linux-user/aarch64/syscall_nr.h
new file mode 100644
index 000..743255d
--- /dev/null
+++ b/linux-user/aarch64/syscall_nr.h
@@ -0,0 +1,323 @@
+/*
+ * This file contains the system call numbers.
+ */
+
+#define TARGET_NR_io_setup 0
+#define TARGET_NR_io_destroy 1
+#define TARGET_NR_io_submit 2
+#define TARGET_NR_io_cancel 3
+#define TARGET_NR_io_getevents 4
+#define TARGET_NR_setxattr 5
+#define TARGET_NR_lsetxattr 6
+#define TARGET_NR_fsetxattr 7
+#define TARGET_NR_getxattr 8
+#define TARGET_NR_lgetxattr 9
+#define TARGET_NR_fgetxattr 10
+#define TARGET_NR_listxattr 11
+#define TARGET_NR_llistxattr 12
+#define TARGET_NR_flistxattr 13
+#define TARGET_NR_removexattr 14
+#define TARGET_NR_lremovexattr 15
+#define TARGET_NR_fremovexattr 16
+#define TARGET_NR_getcwd 17
+#define TARGET_NR_lookup_dcookie 18
+#define TARGET_NR_eventfd2 19
+#define TARGET_NR_epoll_create1 20
+#define TARGET_NR_epoll_ctl 21
+#define TARGET_NR_epoll_pwait 22
+#define TARGET_NR_dup 23
+#define TARGET_NR_dup3 24
+#define TARGET_NR_fcntl 25
+#define TARGET_NR_inotify_init1 26
+#define TARGET_NR_inotify_add_watch 27
+#define TARGET_NR_inotify_rm_watch 28
+#define TARGET_NR_ioctl 29
+#define TARGET_NR_ioprio_set 30
+#define TARGET_NR_ioprio_get 31
+#define TARGET_NR_flock 32
+#define TARGET_NR_mknodat 33
+#define TARGET_NR_mkdirat 34
+#define TARGET_NR_unlinkat 35
+#define TARGET_NR_symlinkat 36
+#define TARGET_NR_linkat 37
+#define TARGET_NR_renameat 38
+#define TARGET_NR_umount2 39
+#define TARGET_NR_mount 40
+#define TARGET_NR_pivot_root 41
+#define TARGET_NR_nfsservctl 42
+#define TARGET_NR_statfs 43
+#define TARGET_NR_fstatfs 44
+#define TARGET_NR_truncate 45
+#define TARGET_NR_ftruncate 46
+#define TARGET_NR_fallocate 47
+#define TARGET_NR_faccessat 48
+#define TARGET_NR_chdir 49
+#define TARGET_NR_fchdir 50
+#define TARGET_NR_chroot 51
+#define TARGET_NR_fchmod 52
+#define TARGET_NR_fchmodat 53
+#define TARGET_NR_fchownat 54
+#define TARGET_NR_fchown 55
+#define TARGET_NR_openat 56
+#define TARGET_NR_close 57
+#define TARGET_NR_vhangup 58
+#define TARGET_NR_pipe2 59
+#define TARGET_NR_quotactl 60
+#define TARGET_NR_getdents64 61
+#define TARGET_NR_lseek 62
+#define TARGET_NR_read 63
+#define TARGET_NR_write 64
+#define TARGET_NR_readv 65
+#define TARGET_NR_writev 66
+#define TARGET_NR_pread64 67
+#define TARGET_NR_pwrite64 68
+#define TARGET_NR_preadv 69
+#define TARGET_NR_pwritev 70
+#define TARGET_NR_sendfile 71
+#define TARGET_NR_pselect6 72
+#define TARGET_NR_ppoll 73
+#define TARGET_NR_signalfd4 74
+#define TARGET_NR_vmsplice 75
+#define TARGET_NR_splice 76
+#define TARGET_NR_tee 77
+#define TARGET_NR_readlinkat 78
+#define TARGET_NR_fstatat64 79
+#define TARGET_NR_fstat 80
+#define TARGET_NR_sync 81
+#define TARGET_NR_fsync 82
+#define TARGET_NR_fdatasync 83
+#define TARGET_NR_sync_file_range2 84
+/* #define TARGET_NR_sync_file_range 84 */
+#define TARGET_NR_timerfd_create 85
+#define TARGET_NR_timerfd_settime 86
+#define TARGET_NR_timerfd_gettime 87
+#define TARGET_NR_utimensat 88
+#define TARGET_NR_acct 89
+#define TARGET_NR_capget 90
+#define TARGET_NR_capset 91
+#define TARGET_NR_personality 92
+#define TARGET_NR_exit 93
+#define TARGET_NR_exit_group 94
+#define TARGET_NR_waitid 95
+#define TARGET_NR_set_tid_address 96
+#define TARGET_NR_unshare 97
+#define TARGET_NR_futex 98
+#define TARGET_NR_set_robust_list 99
+#define TARGET_NR_get_robust_list 100
+#define TARGET_NR_nanosleep 101
+#define TARGET_NR_getitimer 102
+#define TARGET_NR_setitimer 103
+#define TARGET_NR_kexec_load 104
+#define TARGET_NR_init_module 105
+#define TARGET_NR_delete_module 106
+#define TARGET_NR_timer_create 107
+#define TARGET_NR_timer_gettime 108
+#define TARGET_NR_timer_getoverrun 109
+#define TARGET_NR_timer_settime 110
+#define TARGET_NR_timer_delete 111
+#define TARGET_NR_clock_settime 112
+#define TARGET_NR_clock_gettime 113
+#define TARGET_NR_clock_getres 114
+#define TARGET_NR_clock_nanosleep 115
+#define TARGET_NR_syslog 116
+#define TARGET_NR_ptrace 117
+#define TARGET_NR_sched_setparam 118
+#define TARGET_NR_sched_setscheduler 119
+#define TARGET_NR_sched_getscheduler 120
+#define TARGET_NR_sched_getparam 121
+#define TARGET_NR_sched_setaffinity 122
+#define TARGET_NR_sched_getaffinity 123
+#define TARGET_NR_sched_yield 124
+#define TARGET_NR_sched_get_priority_max 125
+#defin

Re: [Qemu-devel] [PATCH RFC qom-cpu 23/41] target-xtensa: Change gen_intermediate_code_internal() arg to XtensaCPU

2013-07-01 Thread Andreas Färber
Am 01.07.2013 19:16, schrieb Richard Henderson:
> On 06/29/2013 01:01 PM, Andreas Färber wrote:
>> Also use bool type while at it.
>>
>> Prepares for moving singlestep_enabled field to CPUState.
>>
>> Signed-off-by: Andreas Färber 
>> ---
>>  target-xtensa/translate.c | 10 ++
>>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> All of 10-23/41,
> 
> Reviewed-by: Richard Henderson 

I wonder, all targets seem to implement the same pattern of passing a
hard-coded bool argument to their internal function.

Is there any reason not to have translate-all.c call the function with
that true/false directly?

That would then call for using CPUState *cs argument and leaving FooCPU
*cpu as local variable only where needed. In that case it would be a
central change covering all targets in one patch. :)

Regards,
Andreas

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



[Qemu-devel] [PATCH v5 03/21] target-arm: Export cpu_env

2013-07-01 Thread Peter Maydell
From: Alexander Graf 

The cpu_env tcg variable will be used by both the AArch32 and AArch64
handling code. Unstaticify it, so that both sides can make use of it.

Signed-off-by: Alexander Graf 
Signed-off-by: John Rigby 
Message-id: 1368505980-17151-3-git-send-email-john.ri...@linaro.org
Signed-off-by: Peter Maydell 
---
 target-arm/translate.c |2 +-
 target-arm/translate.h |2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/target-arm/translate.c b/target-arm/translate.c
index 1a9c1a0..a6c2cf9 100644
--- a/target-arm/translate.c
+++ b/target-arm/translate.c
@@ -59,7 +59,7 @@ static uint32_t gen_opc_condexec_bits[OPC_BUF_SIZE];
 #define DISAS_WFI 4
 #define DISAS_SWI 5
 
-static TCGv_ptr cpu_env;
+TCGv_ptr cpu_env;
 /* We reuse the same 64-bit temporaries for efficiency.  */
 static TCGv_i64 cpu_V0, cpu_V1, cpu_M0;
 static TCGv_i32 cpu_R[16];
diff --git a/target-arm/translate.h b/target-arm/translate.h
index e727bc6..8ba1433 100644
--- a/target-arm/translate.h
+++ b/target-arm/translate.h
@@ -24,4 +24,6 @@ typedef struct DisasContext {
 int vec_stride;
 } DisasContext;
 
+extern TCGv_ptr cpu_env;
+
 #endif /* TARGET_ARM_TRANSLATE_H */
-- 
1.7.9.5




[Qemu-devel] [PATCH v5 13/21] linux-user: Add signal handling for AArch64

2013-07-01 Thread Peter Maydell
From: Andreas Schwab 

This patch adds signal handling for AArch64. The code is based on the
respective source in the Linux kernel.

Signed-off-by: Andreas Schwab 
Signed-off-by: Alexander Graf 
Signed-off-by: John Rigby 
Message-id: 1368505980-17151-10-git-send-email-john.ri...@linaro.org
[PMM: fixed style nits: tabs, long lines;
 pulled target_signal.h in from a later patch; it fits better here]
Signed-off-by: Peter Maydell 
---
 linux-user/aarch64/target_signal.h |   29 
 linux-user/signal.c|  254 
 2 files changed, 283 insertions(+)
 create mode 100644 linux-user/aarch64/target_signal.h

diff --git a/linux-user/aarch64/target_signal.h 
b/linux-user/aarch64/target_signal.h
new file mode 100644
index 000..d69a2d2
--- /dev/null
+++ b/linux-user/aarch64/target_signal.h
@@ -0,0 +1,29 @@
+#ifndef TARGET_SIGNAL_H
+#define TARGET_SIGNAL_H
+
+#include "cpu.h"
+
+/* this struct defines a stack used during syscall handling */
+
+typedef struct target_sigaltstack {
+abi_ulong ss_sp;
+abi_long ss_flags;
+abi_ulong ss_size;
+} target_stack_t;
+
+
+/*
+ * sigaltstack controls
+ */
+#define TARGET_SS_ONSTACK 1
+#define TARGET_SS_DISABLE 2
+
+#define TARGET_MINSIGSTKSZ 2048
+#define TARGET_SIGSTKSZ 8192
+
+static inline abi_ulong get_sp_from_cpustate(CPUARMState *state)
+{
+   return state->xregs[31];
+}
+
+#endif /* TARGET_SIGNAL_H */
diff --git a/linux-user/signal.c b/linux-user/signal.c
index c4e20dc..076a9a2 100644
--- a/linux-user/signal.c
+++ b/linux-user/signal.c
@@ -1090,6 +1090,260 @@ badframe:
return 0;
 }
 
+#elif defined(TARGET_AARCH64)
+
+struct target_sigcontext {
+uint64_t fault_address;
+/* AArch64 registers */
+uint64_t regs[31];
+uint64_t sp;
+uint64_t pc;
+uint64_t pstate;
+/* 4K reserved for FP/SIMD state and future expansion */
+char __reserved[4096] __attribute__((__aligned__(16)));
+};
+
+struct target_ucontext {
+abi_ulong tuc_flags;
+abi_ulong tuc_link;
+target_stack_t tuc_stack;
+target_sigset_t tuc_sigmask;
+/* glibc uses a 1024-bit sigset_t */
+char __unused[1024 / 8 - sizeof(target_sigset_t)];
+/* last for future expansion */
+struct target_sigcontext tuc_mcontext;
+};
+
+/*
+ * Header to be used at the beginning of structures extending the user
+ * context. Such structures must be placed after the rt_sigframe on the stack
+ * and be 16-byte aligned. The last structure must be a dummy one with the
+ * magic and size set to 0.
+ */
+struct target_aarch64_ctx {
+uint32_t magic;
+uint32_t size;
+};
+
+#define TARGET_FPSIMD_MAGIC 0x46508001
+
+struct target_fpsimd_context {
+struct target_aarch64_ctx head;
+uint32_t fpsr;
+uint32_t fpcr;
+uint64_t vregs[32 * 2];
+};
+
+/*
+ * Auxiliary context saved in the sigcontext.__reserved array. Not exported to
+ * user space as it will change with the addition of new context. User space
+ * should check the magic/size information.
+ */
+struct target_aux_context {
+struct target_fpsimd_context fpsimd;
+/* additional context to be added before "end" */
+struct target_aarch64_ctx end;
+};
+
+struct target_rt_sigframe {
+struct target_siginfo info;
+struct target_ucontext uc;
+uint64_t fp;
+uint64_t lr;
+uint32_t tramp[2];
+};
+
+static int target_setup_sigframe(struct target_rt_sigframe *sf,
+ CPUARMState *env, target_sigset_t *set)
+{
+int i;
+struct target_aux_context *aux =
+(struct target_aux_context *)sf->uc.tuc_mcontext.__reserved;
+
+/* set up the stack frame for unwinding */
+__put_user(env->xregs[29], &sf->fp);
+__put_user(env->xregs[30], &sf->lr);
+
+for (i = 0; i < 31; i++) {
+__put_user(env->xregs[i], &sf->uc.tuc_mcontext.regs[i]);
+}
+__put_user(env->xregs[31], &sf->uc.tuc_mcontext.sp);
+__put_user(env->pc, &sf->uc.tuc_mcontext.pc);
+__put_user(env->pstate, &sf->uc.tuc_mcontext.pstate);
+
+__put_user(/*current->thread.fault_address*/ 0,
+&sf->uc.tuc_mcontext.fault_address);
+
+for (i = 0; i < TARGET_NSIG_WORDS; i++) {
+__put_user(set->sig[i], &sf->uc.tuc_sigmask.sig[i]);
+}
+
+for (i = 0; i < 32 * 2; i++) {
+__put_user(env->vfp.regs[i], &aux->fpsimd.vregs[i]);
+}
+__put_user(/*env->fpsr*/0, &aux->fpsimd.fpsr);
+__put_user(/*env->fpcr*/0, &aux->fpsimd.fpcr);
+__put_user(TARGET_FPSIMD_MAGIC, &aux->fpsimd.head.magic);
+__put_user(sizeof(struct target_fpsimd_context),
+&aux->fpsimd.head.size);
+
+/* set the "end" magic */
+__put_user(0, &aux->end.magic);
+__put_user(0, &aux->end.size);
+
+return 0;
+}
+
+static int target_restore_sigframe(CPUARMState *env,
+   struct target_rt_sigframe *sf)
+{
+sigset_t set;
+int i;
+struct target_aux_context *aux =
+(struct target_aux_context *)sf->uc.tuc_mcontext.__reserved;
+uint32_t

[Qemu-devel] [PATCH v5 14/21] linux-user: Make sure NWFPE code is 32 bit ARM only

2013-07-01 Thread Peter Maydell
On ARM, linux-user emulation includes NWFPE support for emulating the
ancient FPA floating point coprocessor. This has long since been
superseded by VFP and is only required for legacy binaries. The
AArch64 linux-user target doesn't compile in NWFPE support, so make
sure the relevant code is protected by suitable ifdefs.

Signed-off-by: Peter Maydell 
---
 linux-user/qemu.h |4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/linux-user/qemu.h b/linux-user/qemu.h
index b10e957..d51d827 100644
--- a/linux-user/qemu.h
+++ b/linux-user/qemu.h
@@ -79,7 +79,7 @@ struct vm86_saved_state {
 };
 #endif
 
-#ifdef TARGET_ARM
+#if defined(TARGET_ARM) && defined(TARGET_ABI32)
 /* FPU emulator */
 #include "nwfpe/fpa11.h"
 #endif
@@ -103,8 +103,10 @@ struct emulated_sigtable {
 typedef struct TaskState {
 pid_t ts_tid; /* tid (or pid) of this task */
 #ifdef TARGET_ARM
+# ifdef TARGET_ABI32
 /* FPA state */
 FPA11 fpa;
+# endif
 int swi_errno;
 #endif
 #ifdef TARGET_UNICORE32
-- 
1.7.9.5




[Qemu-devel] [PATCH v5 18/21] linux-user: AArch64 requires at least 3.8.0

2013-07-01 Thread Peter Maydell
From: Alexander Graf 

Glibc 1.17 checks for the host kernel version on startup. Unfortunately,
it also checks whether the host kernel version is recent enough for the
target to run at all.

Since AArch64 support only got introduced in 3.8.0, that means that glibc
refuses to run on any older kernel version than that.

To allow for execution of linux-user guests even on older host kernels,
let's always fake the kernel version to 3.8.0 on AArch64 guests.

Signed-off-by: Alexander Graf 
Signed-off-by: John Rigby 
Message-id: 1368505980-17151-13-git-send-email-john.ri...@linaro.org
Signed-off-by: Peter Maydell 
---
 linux-user/syscall.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index 802ec95..c2497e4 100644
--- a/linux-user/syscall.c
+++ b/linux-user/syscall.c
@@ -304,7 +304,12 @@ static int sys_uname(struct new_utsname *buf)
   memset(buf, 0, sizeof(*buf));
   COPY_UTSNAME_FIELD(buf->sysname, uts_buf.sysname);
   COPY_UTSNAME_FIELD(buf->nodename, uts_buf.nodename);
+#ifdef TARGET_AARCH64
+  /* glibc refuses to run on older kernels */
+  COPY_UTSNAME_FIELD(buf->release, "3.8.0");
+#else
   COPY_UTSNAME_FIELD(buf->release, uts_buf.release);
+#endif
   COPY_UTSNAME_FIELD(buf->version, uts_buf.version);
   COPY_UTSNAME_FIELD(buf->machine, uts_buf.machine);
 #ifdef _GNU_SOURCE
-- 
1.7.9.5




[Qemu-devel] [PATCH v5 10/21] linux-user: Add cpu loop for AArch64

2013-07-01 Thread Peter Maydell
Add the main linux-user cpu loop for AArch64. Since AArch64
has a different system call interface, doesn't need to worry
about FPA emulation and may in the future keep the prefetch/data
abort information in different system registers, it's simplest
just to use a completely separate loop from the 32 bit ARM
target, rather than peppering it with ifdefs.

Signed-off-by: Peter Maydell 
---
 linux-user/main.c |   82 +
 1 file changed, 82 insertions(+)

diff --git a/linux-user/main.c b/linux-user/main.c
index af82db8..8aba817 100644
--- a/linux-user/main.c
+++ b/linux-user/main.c
@@ -484,6 +484,9 @@ void cpu_loop(CPUX86State *env)
 __r;\
 })
 
+#ifdef TARGET_ABI32
+/* Commpage handling -- there is no commpage for AArch64 */
+
 /*
  * See the Linux kernel's Documentation/arm/kernel_user_helpers.txt
  * Input:
@@ -617,6 +620,7 @@ do_kernel_trap(CPUARMState *env)
 
 return 0;
 }
+#endif
 
 static int do_strex(CPUARMState *env)
 {
@@ -696,6 +700,7 @@ done:
 return segv;
 }
 
+#ifdef TARGET_ABI32
 void cpu_loop(CPUARMState *env)
 {
 CPUState *cs = CPU(arm_env_get_cpu(env));
@@ -908,6 +913,83 @@ void cpu_loop(CPUARMState *env)
 }
 }
 
+#else
+
+/* AArch64 main loop */
+void cpu_loop(CPUARMState *env)
+{
+CPUState *cs = CPU(arm_env_get_cpu(env));
+int trapnr, sig;
+target_siginfo_t info;
+uint32_t addr;
+
+for (;;) {
+cpu_exec_start(cs);
+trapnr = cpu_arm_exec(env);
+cpu_exec_end(cs);
+
+switch (trapnr) {
+case EXCP_SWI:
+env->xregs[0] = do_syscall(env,
+   env->xregs[8],
+   env->xregs[0],
+   env->xregs[1],
+   env->xregs[2],
+   env->xregs[3],
+   env->xregs[4],
+   env->xregs[5],
+   0, 0);
+break;
+case EXCP_INTERRUPT:
+/* just indicate that signals should be handled asap */
+break;
+case EXCP_UDEF:
+info.si_signo = SIGILL;
+info.si_errno = 0;
+info.si_code = TARGET_ILL_ILLOPN;
+info._sifields._sigfault._addr = env->pc;
+queue_signal(env, info.si_signo, &info);
+break;
+case EXCP_PREFETCH_ABORT:
+addr = env->cp15.c6_insn;
+goto do_segv;
+case EXCP_DATA_ABORT:
+addr = env->cp15.c6_data;
+do_segv:
+info.si_signo = SIGSEGV;
+info.si_errno = 0;
+/* XXX: check env->error_code */
+info.si_code = TARGET_SEGV_MAPERR;
+info._sifields._sigfault._addr = addr;
+queue_signal(env, info.si_signo, &info);
+break;
+case EXCP_DEBUG:
+case EXCP_BKPT:
+sig = gdb_handlesig(env, TARGET_SIGTRAP);
+if (sig) {
+info.si_signo = sig;
+info.si_errno = 0;
+info.si_code = TARGET_TRAP_BRKPT;
+queue_signal(env, info.si_signo, &info);
+}
+break;
+case EXCP_STREX:
+if (do_strex(env)) {
+addr = env->cp15.c6_data;
+goto do_segv;
+}
+break;
+default:
+fprintf(stderr, "qemu: unhandled CPU exception 0x%x - aborting\n",
+trapnr);
+cpu_dump_state(cs, stderr, fprintf, 0);
+abort();
+}
+process_pending_signals(env);
+}
+}
+#endif /* ndef TARGET_ABI32 */
+
 #endif
 
 #ifdef TARGET_UNICORE32
-- 
1.7.9.5




Re: [Qemu-devel] [PATCH RFC qom-cpu 04/41] cpu: Introduce CPUClass::set_pc() for gdb_set_cpu_pc()

2013-07-01 Thread Andreas Färber
Richard or anyone,

Am 01.07.2013 19:09, schrieb Richard Henderson:
> On 06/29/2013 01:01 PM, Andreas Färber wrote:
>> This moves setting the Program Counter from gdbstub into target code.
>> Use uint64_t type as maximum replacement for target_ulong.
>>
>> Signed-off-by: Andreas Färber 
>> ---
>>  gdbstub.c   | 39 ++-
>>  include/qom/cpu.h   |  1 +
>>  target-alpha/cpu.c  |  8 
>>  target-arm/cpu.c|  8 
>>  target-cris/cpu.c   |  8 
>>  target-i386/cpu.c   |  8 
>>  target-lm32/cpu.c   |  8 
>>  target-microblaze/cpu.c |  8 
>>  target-mips/cpu.c   | 14 ++
>>  target-openrisc/cpu.c   |  8 
>>  target-ppc/translate_init.c |  8 
>>  target-s390x/cpu.c  |  8 
>>  target-sh4/cpu.c|  8 
>>  target-sparc/cpu.c  |  9 +
>>  target-xtensa/cpu.c |  8 
>>  15 files changed, 118 insertions(+), 33 deletions(-)
> 
> Reviewed-by: Richard Henderson 

This is the first case where I am proposing the use of uint64_t in place
of target_ulong. In this case a gdb command using such a hook is not
performance-sensitive. Do you see this as an acceptable path for adding
further CPUClass hooks such as MMU fault handling?

Should we introduce some ulong-target-max typedef similar to hwaddr or
use plain uint64_t as done here?

Thanks,
Andreas

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



[Qemu-devel] [PATCH v5 08/21] gdbstub: Add AArch64 support

2013-07-01 Thread Peter Maydell
From: Alexander Graf 

We want to be able to debug AArch64 guests. So let's add the respective gdb
stub functions and xml descriptions that allow us to do so.

Signed-off-by: Alexander Graf 
Signed-off-by: John Rigby 
Message-id: 1368505980-17151-6-git-send-email-john.ri...@linaro.org
Signed-off-by: Peter Maydell 
---
 gdb-xml/aarch64-core.xml |   46 +
 gdb-xml/aarch64-fpu.xml  |   86 ++
 gdbstub.c|   53 
 3 files changed, 185 insertions(+)
 create mode 100644 gdb-xml/aarch64-core.xml
 create mode 100644 gdb-xml/aarch64-fpu.xml

diff --git a/gdb-xml/aarch64-core.xml b/gdb-xml/aarch64-core.xml
new file mode 100644
index 000..e1e9dc3
--- /dev/null
+++ b/gdb-xml/aarch64-core.xml
@@ -0,0 +1,46 @@
+
+
+
+
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
+  
+  
+
diff --git a/gdb-xml/aarch64-fpu.xml b/gdb-xml/aarch64-fpu.xml
new file mode 100644
index 000..997197e
--- /dev/null
+++ b/gdb-xml/aarch64-fpu.xml
@@ -0,0 +1,86 @@
+
+
+
+
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
+
+
+  
+  
+
+
+
+  
+  
+
+
+  
+  
+
+
+  
+  
+
+
+  
+  
+
+
+
+
+
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
diff --git a/gdbstub.c b/gdbstub.c
index 3101a43..757805d 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -940,6 +940,59 @@ static int cpu_gdb_write_register(CPUSPARCState *env, 
uint8_t *mem_buf, int n)
 return 8;
 #endif
 }
+#elif defined(TARGET_AARCH64)
+
+#define NUM_CORE_REGS 34
+#define GDB_CORE_XML "aarch64-core.xml"
+
+static int cpu_gdb_read_register(CPUARMState *env, uint8_t *mem_buf, int n)
+{
+if (n < 31) {
+/* Core integer register.  */
+GET_REG64(env->xregs[n]);
+}
+switch (n) {
+case 31:
+GET_REG64(env->xregs[31]);
+break;
+case 32:
+GET_REG64(env->pc);
+break;
+case 33:
+GET_REG32(env->pstate);
+break;
+}
+/* Unknown register.  */
+return 0;
+}
+
+static int cpu_gdb_write_register(CPUARMState *env, uint8_t *mem_buf, int n)
+{
+uint64_t tmp;
+
+tmp = ldq_p(mem_buf);
+
+if (n < 31) {
+/* Core integer register.  */
+env->xregs[n] = tmp;
+return 8;
+}
+switch (n) {
+case 31:
+env->xregs[31] = tmp;
+return 8;
+case 32:
+env->pc = tmp;
+return 8;
+case 33:
+/* CPSR */
+env->pstate = tmp;
+return 4;
+}
+/* Unknown register.  */
+return 0;
+}
+
 #elif defined (TARGET_ARM)
 
 /* Old gdb always expect FPA registers.  Newer (xml-aware) gdb only expect
-- 
1.7.9.5




  1   2   3   >