[Qemu-devel] [PULL 3/3] spapr_drc: Change value of property "fdt" from null back to {}

2015-12-03 Thread David Gibson
From: Markus Armbruster 

prop_get_fdt() misuses the visitor API: when fdt is null, it doesn't
visit anything.  object_property_get_qobject() happily
object_property_get_qobject().  Amazingly, the latter survives the
misuse.  Turns out we've papered over it long before prop_get_fdt()
existed, in commit 1d10b44.

However, commit 6c2f9a1 changed how we paper over it, and as a side
effect changed qom-get's value from {} to null.  Change it right back
by fixing the visitor misuse.

Signed-off-by: Markus Armbruster 
Signed-off-by: David Gibson 
---
 hw/ppc/spapr_drc.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
index 404fb3c..8be62c3 100644
--- a/hw/ppc/spapr_drc.c
+++ b/hw/ppc/spapr_drc.c
@@ -259,6 +259,11 @@ static void prop_get_fdt(Object *obj, Visitor *v, void 
*opaque,
 void *fdt;
 
 if (!drc->fdt) {
+visit_start_struct(v, NULL, NULL, name, 0, );
+if (!err) {
+visit_end_struct(v, );
+}
+error_propagate(errp, err);
 return;
 }
 
-- 
2.5.0




[Qemu-devel] [PULL 2/3] spapr_drc: Make device "spapr-dr-connector" unavailable with -device

2015-12-03 Thread David Gibson
From: Markus Armbruster 

It should only be created via spapr_dr_connector_new().  Attempting to
create it with -device crashes.

Signed-off-by: Markus Armbruster 
Signed-off-by: David Gibson 
---
 hw/ppc/spapr_drc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/hw/ppc/spapr_drc.c b/hw/ppc/spapr_drc.c
index 4e7a1d3..404fb3c 100644
--- a/hw/ppc/spapr_drc.c
+++ b/hw/ppc/spapr_drc.c
@@ -594,6 +594,10 @@ static void spapr_dr_connector_class_init(ObjectClass *k, 
void *data)
 drck->attach = attach;
 drck->detach = detach;
 drck->release_pending = release_pending;
+/*
+ * Reason: it crashes FIXME find and document the real reason
+ */
+dk->cannot_instantiate_with_device_add_yet = true;
 }
 
 static const TypeInfo spapr_dr_connector_info = {
-- 
2.5.0




[Qemu-devel] [PULL 0/3] ppc-for-2.5 queue 20151204

2015-12-03 Thread David Gibson
The following changes since commit 4c65fed8bdf96780735dbdb92a8bd0d6b6526cc3:

  ui: vnc: avoid floating point exception (2015-12-03 13:34:50 +)

are available in the git repository at:

  git://github.com/dgibson/qemu.git tags/ppc-for-2.5-20151204

for you to fetch changes up to ab8bf1d735133df5b5847bef0b0bea496d614a5a:

  spapr_drc: Change value of property "fdt" from null back to {} (2015-12-04 
16:50:59 +1100)


Peter,

Not sure if you need a pull req for this, or you could just merge
Markus' patches directly, but to avoid another round trip if you would
prefer a pull req, here is one.



ppc patch queue for 2.5 2015-12-04

This contains some last minute QOM behaviour fixes from Markus
Armbruster.


Markus Armbruster (3):
  spapr_drc: Handle visitor errors properly
  spapr_drc: Make device "spapr-dr-connector" unavailable with -device
  spapr_drc: Change value of property "fdt" from null back to {}

 hw/ppc/spapr_drc.c | 41 +++--
 1 file changed, 35 insertions(+), 6 deletions(-)



[Qemu-devel] [PULL 8/9] typedefs: Put them back into alphabetical order

2015-12-03 Thread Michael Tokarev
From: Markus Armbruster 

"Please keep this list in alphabetical order" has been more honoured
in the breach than in the observance.  Clean up.

While there, drop a redundant struct declaration.

Signed-off-by: Markus Armbruster 
Reviewed-by: Dr. David Alan Gilbert 
Reviewed-by: Eric Blake 
Signed-off-by: Michael Tokarev 
---
 include/qemu/typedefs.h | 13 ++---
 1 file changed, 6 insertions(+), 7 deletions(-)

diff --git a/include/qemu/typedefs.h b/include/qemu/typedefs.h
index 6b1093d..3eedcf4 100644
--- a/include/qemu/typedefs.h
+++ b/include/qemu/typedefs.h
@@ -3,7 +3,6 @@
 
 /* A load of opaque types so that device init declarations don't have to
pull in all the real definitions.  */
-struct Monitor;
 
 /* Please keep this list in alphabetical order */
 typedef struct AdapterInfo AdapterInfo;
@@ -19,8 +18,8 @@ typedef struct BusState BusState;
 typedef struct CharDriverState CharDriverState;
 typedef struct CompatProperty CompatProperty;
 typedef struct CPUAddressSpace CPUAddressSpace;
-typedef struct DeviceState DeviceState;
 typedef struct DeviceListener DeviceListener;
+typedef struct DeviceState DeviceState;
 typedef struct DisplayChangeListener DisplayChangeListener;
 typedef struct DisplayState DisplayState;
 typedef struct DisplaySurface DisplaySurface;
@@ -46,6 +45,7 @@ typedef struct MigrationIncomingState MigrationIncomingState;
 typedef struct MigrationParams MigrationParams;
 typedef struct MigrationState MigrationState;
 typedef struct Monitor Monitor;
+typedef struct MonitorDef MonitorDef;
 typedef struct MouseTransformInfo MouseTransformInfo;
 typedef struct MSIMessage MSIMessage;
 typedef struct NetClientState NetClientState;
@@ -63,13 +63,13 @@ typedef struct PCIESlot PCIESlot;
 typedef struct PCIExpressDevice PCIExpressDevice;
 typedef struct PCIExpressHost PCIExpressHost;
 typedef struct PCIHostState PCIHostState;
-typedef struct PCMachineState PCMachineState;
 typedef struct PCMachineClass PCMachineClass;
+typedef struct PCMachineState PCMachineState;
 typedef struct PCMCIACardState PCMCIACardState;
 typedef struct PixelFormat PixelFormat;
 typedef struct PostcopyDiscardState PostcopyDiscardState;
-typedef struct PropertyInfo PropertyInfo;
 typedef struct Property Property;
+typedef struct PropertyInfo PropertyInfo;
 typedef struct QEMUBH QEMUBH;
 typedef struct QemuConsole QemuConsole;
 typedef struct QEMUFile QEMUFile;
@@ -78,10 +78,10 @@ typedef struct QemuOpts QemuOpts;
 typedef struct QemuOptsList QemuOptsList;
 typedef struct QEMUSGList QEMUSGList;
 typedef struct QEMUSizedBuffer QEMUSizedBuffer;
-typedef struct QEMUTimerListGroup QEMUTimerListGroup;
 typedef struct QEMUTimer QEMUTimer;
-typedef struct Range Range;
+typedef struct QEMUTimerListGroup QEMUTimerListGroup;
 typedef struct RAMBlock RAMBlock;
+typedef struct Range Range;
 typedef struct SerialState SerialState;
 typedef struct SHPCDevice SHPCDevice;
 typedef struct SMBusDevice SMBusDevice;
@@ -89,6 +89,5 @@ typedef struct SSIBus SSIBus;
 typedef struct uWireSlave uWireSlave;
 typedef struct VirtIODevice VirtIODevice;
 typedef struct Visitor Visitor;
-typedef struct MonitorDef MonitorDef;
 
 #endif /* QEMU_TYPEDEFS_H */
-- 
2.1.4




[Qemu-devel] [PATCH] report a error message if -net socket can not connect to server

2015-12-03 Thread Li Zhijian
From: Li Zhijian 

-netdev socket,connect=xx:xx now is asynchronous to connect
listening server, if we don't start listening server before
connecting, no error is detected but we can connect to listening
server forever.

Just report a error message in this case?

Signed-off-by: Li Zhijian 
---
 net/socket.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/net/socket.c b/net/socket.c
index e8605d4..a82da36 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -46,6 +46,7 @@ typedef struct NetSocketState {
 IOHandler *send_fn;   /* differs between SOCK_STREAM/SOCK_DGRAM */
 bool read_poll;   /* waiting to receive data? */
 bool write_poll;  /* waiting to transmit data? */
+bool connected;   /* connect socket is connected */
 } NetSocketState;
 
 static void net_socket_accept(void *opaque);
@@ -424,6 +425,21 @@ err:
 static void net_socket_connect(void *opaque)
 {
 NetSocketState *s = opaque;
+int err = -1;
+socklen_t len = sizeof(err);
+
+if (s->listen_fd == -1 && !s->connected) {
+if (getsockopt(s->fd, SOL_SOCKET, SO_ERROR, , )) {
+error_report("get socket opt error %s", strerror(errno));
+/* FIXME: cleanup and exit ? */
+} else if (err) {
+errno = err;
+error_report("net socket is not connected %s\n", strerror(errno));
+/* FIXME: cleanup and exit ? */
+} else {
+s->connected = true;
+}
+}
 s->send_fn = net_socket_send;
 net_socket_read_poll(s, true);
 }
@@ -451,6 +467,7 @@ static NetSocketState 
*net_socket_fd_init_stream(NetClientState *peer,
 
 s->fd = fd;
 s->listen_fd = -1;
+s->connected = is_connected;
 
 /* Disable Nagle algorithm on TCP sockets to reduce latency */
 socket_set_nodelay(fd);
-- 
1.7.12.4






Re: [Qemu-devel] Question about nonblocking stderr and lost logs

2015-12-03 Thread Stefan Hajnoczi
On Mon, Nov 30, 2015 at 04:34:47PM +1100, Sam Bobroff wrote:
> Hi QEMU programmers,
> 
> While doing some experimental work on QEMU that has involved adding a lot of
> new log messages (using qemu_log_mask()), I've discovered that under some
> conditions a lot of my log messages go missing.
> 
> I've tracked the issue down to qemu_logfile being left at the default (stderr)
> (so when not using -D) and according to strace what is happening is that the
> debug messages are being passed to write() but write() is returning 
> EWOULDBLOCK
> and the messags are dropped.
> 
> This seems to be happening because stderr is being set non-blocking (which is 
> a
> bit odd to me), and it seems like NONBLOCK is being set as qmp_chardev_add() 
> adds a
> device for stdout (yes stdout, not stderr; perhaps file descriptors have been
> dup'd by that point?).
> 
> Is this by design to prevent a slow console from blocking QEMU? If not, should
> I delve further and try to prevent non-blocking being set on stderr?
> 
> (Unfortunately I don't have a replication for this using an unmodified QEMU 
> but
> I suspect I could find one if necessary.)

This sounds like a bug.  stderr should be blocking.

But it's specific to your QEMU build or your command-line.  Here are my
results on an x86 host:

$ qemu-system-x86_64 -enable-kvm -m 1024 -cpu host \
 -drive if=virtio,cache=none,file=test.img,format=raw
$ cat /proc/$(pgrep qemu)/fdinfo/2
pos:0
flags:  012
mnt_id: 22

The flags are O_RDWR | O_LARGEFILE.

O_NONBLOCK would have been 04000 (octal).

Please retry with qemu.git/master and post your QEMU command-line.

Stefan


signature.asc
Description: PGP signature


Re: [Qemu-devel] [RFC PATCH 7/9] net/colo-proxy: add packet enqueue and handle function

2015-12-03 Thread Zhang Chen

Hi,Dave


On 12/03/2015 05:09 PM, Dr. David Alan Gilbert wrote:

* Zhang Chen (zhangchen.f...@cn.fujitsu.com) wrote:

Hi,Dave

On 12/02/2015 12:12 AM, Dr. David Alan Gilbert wrote:

* Zhang Chen (zhangchen.f...@cn.fujitsu.com) wrote:

From: zhangchen 

Add common packet handle function and enqueue
packet distinguished connection,then we can
lookup one connection packet to compare

Signed-off-by: zhangchen 
---
  net/colo-proxy.c | 167 ++-
  1 file changed, 166 insertions(+), 1 deletion(-)

diff --git a/net/colo-proxy.c b/net/colo-proxy.c
index 08a852f..a664e6d 100644
--- a/net/colo-proxy.c
+++ b/net/colo-proxy.c
@@ -24,6 +24,170 @@
  static char *mode;
  static bool colo_do_checkpoint;
+static void packet_destroy(void *opaque, void *user_data);
+
+static uint32_t connection_key_hash(const void *opaque)
+{
+const Connection_key *key = opaque;
+uint32_t a, b, c;
+
+/* Jenkins hash */
+a = b = c = JHASH_INITVAL + sizeof(*key);
+a += key->src;
+b += key->dst;
+c += key->ports;
+__jhash_mix(a, b, c);
+
+a += key->ip_proto;
+__jhash_final(a, b, c);
+
+return c;
+}
+
+static int connection_key_equal(const void *opaque1, const void *opaque2)
+{
+return memcmp(opaque1, opaque2, sizeof(Connection_key)) == 0;
+}
+
+static void connection_destroy(void *opaque)
+{
+Connection *connection = opaque;
+g_queue_foreach(>primary_list, packet_destroy, NULL);
+g_queue_free(>primary_list);
+g_queue_foreach(>secondary_list, packet_destroy, NULL);
+g_queue_free(>secondary_list);
+g_slice_free(Connection, connection);
+}
+
+static Connection *connection_new(void)
+{
+Connection *connection = g_slice_new(Connection);
+
+g_queue_init(>primary_list);
+g_queue_init(>secondary_list);
+connection->processing = false;
+
+return connection;
+}
+
+/* Return 0 on success, or return -1 if the pkt is corrpted */
+static int parse_packet_early(Packet *pkt, Connection_key *key)
+{
+int network_length;
+uint8_t *data = pkt->data;
+
+pkt->network_layer = data + ETH_HLEN;
+if (ntohs(*(uint16_t *)(data + 12)) != ETH_P_IP) {
+if (ntohs(*(uint16_t *)(data + 12)) == ETH_P_ARP) {
+return -1;
+}
+return 0;
+}

Can you use some of the functions/macros in include/net/eth.h to
make this easier? Maybe eth_get_l3_proto ?
Do you plan to do IPv6 at some point?

I will use include/net/eth.h in next version

IPv6 currently not support, still colo framework be merged


+network_length = pkt->ip->ip_hl * 4;
+pkt->transport_layer = pkt->network_layer + network_length;
+key->ip_proto = pkt->ip->ip_p;
+key->src = pkt->ip->ip_src;
+key->dst = pkt->ip->ip_dst;
+
+switch (key->ip_proto) {
+case IPPROTO_TCP:
+case IPPROTO_UDP:
+case IPPROTO_DCCP:
+case IPPROTO_ESP:
+case IPPROTO_SCTP:
+case IPPROTO_UDPLITE:
+key->ports = *(uint32_t *)(pkt->transport_layer);
+break;
+case IPPROTO_AH:
+key->ports = *(uint32_t *)(pkt->transport_layer + 4);

Interesting; I don't see any other code in QEMU to handle AH,
and I don't know much about it.


+break;
+default:
+break;
+}
+
+return 0;
+}
+
+static Packet *packet_new(ColoProxyState *s, const void *data,
+  int size, Connection_key *key, NetClientState 
*sender)
+{
+Packet *pkt = g_slice_new(Packet);
+
+pkt->data = g_malloc(size);
+memcpy(pkt->data, data, size);

g_memdup might be useful for these:
https://developer.gnome.org/glib/stable/glib-Memory-Allocation.html#g-memdup

I will fix it in next version


+pkt->size = size;
+pkt->s = s;
+pkt->sender = sender;
+pkt->should_be_sent = false;
+
+if (parse_packet_early(pkt, key)) {
+packet_destroy(pkt, NULL);
+pkt = NULL;
+}
+
+return pkt;
+}
+
+static void packet_destroy(void *opaque, void *user_data)
+{
+Packet *pkt = opaque;
+g_free(pkt->data);
+g_slice_free(Packet, pkt);
+}
+
+static Connection *colo_proxy_enqueue_packet(GHashTable *unprocessed_packets,
+  Connection_key *key,
+  Packet *pkt, packet_type type)
+{
+Connection *connection;
+Packet *tmppkt;
+connection = g_hash_table_lookup(unprocessed_packets, key);
+if (connection == NULL) {
+Connection_key *new_key = g_malloc(sizeof(*key));
+
+connection = connection_new();
+memcpy(new_key, key, sizeof(*key));
+key = new_key;
+
+g_hash_table_insert(unprocessed_packets, key, connection);

Is 'unprocessed_packets' a good name for this hashtable? I'm not quite
sure I understand, but it looks to me like it's your connection-tracking 
equivalent,
which then has a queue for each connection with unprocessed packets?

i will change hashtable name to 

Re: [Qemu-devel] [PATCH] vhost: drop dead code

2015-12-03 Thread Michael Tokarev
02.12.2015 14:50, Michael S. Tsirkin wrote:
> We dropped the implementation of vhost_dev_query,
> drop it from the header file as well.

Applied to -trivial with a commit message fix suggested
by Eric.  Thanks!

/mjt



Re: [Qemu-devel] [PATCH] net/vmxnet3.c: fix a build error when enabling debug output

2015-12-03 Thread 阎淼
2015-12-04 14:58 GMT+08:00 阎淼 :
> 2015-12-03 23:59 GMT+08:00 Eric Blake :
>> On 12/02/2015 10:08 PM, Miao Yan wrote:
>>> Macro MAC_FMT and MAC_ARG are not defined, but used in vmxnet3_net_init().
>>> This will cause build error when debug level is raised in
>>> vmxnet3_debug.h (enable all VMXNET3_DEBUG_xxx).
>>>
>>> Use VMXNET_MF and VXMNET_MA instead.
>>>
>>> Signed-off-by: Miao Yan 
>>> ---
>>>  hw/net/vmxnet3.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
>>> index 5e3a233..ea3d9b7 100644
>>> --- a/hw/net/vmxnet3.c
>>> +++ b/hw/net/vmxnet3.c
>>> @@ -2044,7 +2044,7 @@ static void vmxnet3_net_init(VMXNET3State *s)
>>>
>>>  s->link_status_and_speed = VMXNET3_LINK_SPEED | VMXNET3_LINK_STATUS_UP;
>>>
>>> -VMW_CFPRN("Permanent MAC: " MAC_FMT, MAC_ARG(s->perm_mac.a));
>>> +VMW_CFPRN("Permanent MAC: " VMXNET_MF, VMXNET_MA(s->perm_mac.a));
>>
>> This is a classic example of why dead code debug statements are evil.
>>
>> You should consider also providing a patch to hw/net/vmxnet_debug.h to
>> fix ALL of the broken debug macros in that file to instead use a sane
>> pattern, so that the format string is ALWAYS compiled and just optimized
>> out when debugging is disabled.
>>
>> Here's a conversion of one of the macros for an example of what to do:
>
>
> Thanks for the review. Will prepare a patch for it .


Oops, cc list dropped by mistake. Add them back.


>
>
>
>>
>> Instead of:
>>
>>> #ifdef VMXNET_DEBUG_CONFIG
>>> #define VMW_CFPRN(fmt, ...) 
>>> \
>>> do {
>>> \
>>> printf("[%s][CF][%s]: " fmt "\n", VMXNET_DEVICE_NAME, __func__, 
>>> \
>>> ## __VA_ARGS__);
>>> \
>>> } while (0)
>>> #else
>>> #define VMW_CFPRN(fmt, ...) do {} while (0)
>>> #endif
>>
>> you should do:
>>
>> #ifdef VMXNET_DEBUG_CONFIG
>> # define VMXNET_DEBUG_CONFIG_FLAG 1
>> #else
>> # define VMXNET_DEBUG_CONFIG_FLAG 0
>> #endif
>> #define VMW_CFPRN(fmt, ...)   \
>> do {  \
>> if (VMXNET_DEBUG_CONFIG_FLAG) {   \
>> printf("[%s][CF][%s]: " fmt "\n", VMXNET_DEVICE_NAME, \
>>__func__, ## __VA_ARGS__); \
>> } \
>> } while (0);
>>
>> With that pattern, VMW_CFPRN() will now always check that its arguments
>> can compile, even though it has no impact to the code size when
>> VMXNET_DEBUG_CONFIG is not defined.  Note that once you repair all of
>> the broken macros (I count 8 in that file), you may have some fallout of
>> other broken dead code that needs to be fixed.
>>
>> --
>> Eric Blake   eblake redhat com+1-919-301-3266
>> Libvirt virtualization library http://libvirt.org
>>



[Qemu-devel] [PATCH for-2.6 0/2] Preparation for PCI devices convert to realize()

2015-12-03 Thread Cao jin
Hi,
As you know, there are many PCI devices still using .init() as its
initialization function, I am planning to do the "convert to realize()"
work, and PCI bridge devices are chosen first.
The supporting functions should be modified first. msi_init() a supporting
function for PCI devices.

Maybe it should be put in 2.6, as title indicated

Cao jin (2):
  Add param Error** to msi_init()
  Modify callers of msi_init()

 hw/audio/intel-hda.c   |  7 ++-
 hw/ide/ich.c   |  2 +-
 hw/net/vmxnet3.c   |  3 ++-
 hw/pci-bridge/ioh3420.c|  6 +-
 hw/pci-bridge/pci_bridge_dev.c |  6 +-
 hw/pci-bridge/xio3130_downstream.c |  7 ++-
 hw/pci-bridge/xio3130_upstream.c   |  7 ++-
 hw/pci/msi.c   | 17 +
 hw/scsi/megasas.c  |  2 +-
 hw/scsi/vmw_pvscsi.c   |  3 ++-
 hw/usb/hcd-xhci.c  |  5 -
 hw/vfio/pci.c  |  3 ++-
 include/hw/pci/msi.h   |  4 ++--
 13 files changed, 55 insertions(+), 17 deletions(-)

-- 
2.1.0






Re: [Qemu-devel] net: vmxnet3: memory leakage issue

2015-12-03 Thread Jason Wang


On 12/03/2015 03:17 PM, Dmitry Fleytman wrote:
> Hello Prasad,
>
> The patch is good.
> Jason, would you apply is from attachment or should it be resent by
> "git send-email”?

Better with "git send-email". And I've a question for this patch which
needs to be answered before merging this.

What if guest deactivate the device before re-activate the device?

Thanks

>
> Acked-by: Dmitry Fleytman >
>
> ~Dmitry
>
>> On 2 Dec 2015, at 14:17 PM, P J P > > wrote:
>>
>>  Hello Dmitry, all
>>
>> A memory leakage issue was reported by Mr Qinghao Tang, CC'd here.
>>
>> In that, the Qemu VMXNET3 paravirtual device emulator does not check
>> if the device is already active, before activating it. This leads to
>> host memory leakage via calls to vmxnet_tx_pkt_init(), which calls
>> g_malloc0().
>>
>> ===
>> static void vmxnet3_activate_device(VMXNET3State *s)
>> {
>>   ...
>>   /* Preallocate TX packet wrapper */
>>   VMW_CFPRN("Max TX fragments is %u", s->max_tx_frags);
>>   vmxnet_tx_pkt_init(>tx_pkt, s->max_tx_frags, s->peer_has_vhdr);
>>   ...
>> }
>> ===
>>
>> A malicious guest driver could use this flaw to leak excessive memory
>> on the host, eventually killing the Qemu process.
>>
>> Please see attached herein is a proposed (tested)patch which fixes
>> this issue. Please let me know if it's okay or requires any changes.
>>
>> Thank you.
>> --
>> Prasad J Pandit / Red Hat Product Security Team
>> 47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B
>> 041F<0001-net-vmxnet3-avoid-multiple-activations-of-device.patch>
>




[Qemu-devel] [PATCH 1/2] qemu-file: fix flaws of qemu_put_compression_data

2015-12-03 Thread Liang Li
There are some flaws in qemu_put_compression_data, this patch tries
to fix it. Now it can be used by other code.

Signed-off-by: Liang Li 
---
 migration/qemu-file.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/migration/qemu-file.c b/migration/qemu-file.c
index 0bbd257..ef9cd4a 100644
--- a/migration/qemu-file.c
+++ b/migration/qemu-file.c
@@ -616,7 +616,9 @@ ssize_t qemu_put_compression_data(QEMUFile *f, const 
uint8_t *p, size_t size,
 ssize_t blen = IO_BUF_SIZE - f->buf_index - sizeof(int32_t);
 
 if (blen < compressBound(size)) {
-return 0;
+if (f->ops->writev_buffer || f->ops->put_buffer) {
+qemu_fflush(f);
+}
 }
 if (compress2(f->buf + f->buf_index + sizeof(int32_t), (uLongf *),
   (Bytef *)p, size, level) != Z_OK) {
@@ -624,7 +626,13 @@ ssize_t qemu_put_compression_data(QEMUFile *f, const 
uint8_t *p, size_t size,
 return 0;
 }
 qemu_put_be32(f, blen);
+if (f->ops->writev_buffer) {
+add_to_iovec(f, f->buf + f->buf_index, blen);
+}
 f->buf_index += blen;
+if (f->buf_index == IO_BUF_SIZE) {
+qemu_fflush(f);
+}
 return blen + sizeof(int32_t);
 }
 
-- 
1.9.1




[Qemu-devel] [PATCH 0/2] fix the flaws of qemu_put_compression_data

2015-12-03 Thread Liang Li
This patch fixed the flaws in qemu_put_compression_data function.
and cleanup the code based on the change.

Liang Li (2):
  qemu-file: fix flaws of qemu_put_compression_data
  migration: code clean up.

 migration/qemu-file.c | 10 +-
 migration/ram.c   | 20 
 2 files changed, 17 insertions(+), 13 deletions(-)

-- 
1.9.1




[Qemu-devel] [PATCH 5/8] bcm2835_peripherals: add rollup device for bcm2835 peripherals

2015-12-03 Thread Andrew Baumann
This device maintains all the non-CPU peripherals on bcm2835 (Pi1)
which are also present on bcm2836 (Pi2). It also implements the
private address space used for DMA.

Signed-off-by: Andrew Baumann 
---
 hw/arm/Makefile.objs |   1 +
 hw/arm/bcm2835_peripherals.c | 185 +++
 include/hw/arm/bcm2835_peripherals.h |  42 
 include/hw/arm/raspi_platform.h  | 161 ++
 4 files changed, 389 insertions(+)
 create mode 100644 hw/arm/bcm2835_peripherals.c
 create mode 100644 include/hw/arm/bcm2835_peripherals.h
 create mode 100644 include/hw/arm/raspi_platform.h

diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 2195b60..82cc142 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -11,6 +11,7 @@ obj-y += armv7m.o exynos4210.o pxa2xx.o pxa2xx_gpio.o 
pxa2xx_pic.o
 obj-$(CONFIG_DIGIC) += digic.o
 obj-y += omap1.o omap2.o strongarm.o
 obj-$(CONFIG_ALLWINNER_A10) += allwinner-a10.o cubieboard.o
+obj-$(CONFIG_RASPI) += bcm2835_peripherals.o
 obj-$(CONFIG_STM32F205_SOC) += stm32f205_soc.o
 obj-$(CONFIG_XLNX_ZYNQMP) += xlnx-zynqmp.o xlnx-ep108.o
 obj-$(CONFIG_FSL_IMX25) += fsl-imx25.o imx25_pdk.o
diff --git a/hw/arm/bcm2835_peripherals.c b/hw/arm/bcm2835_peripherals.c
new file mode 100644
index 000..3a3a1aa
--- /dev/null
+++ b/hw/arm/bcm2835_peripherals.c
@@ -0,0 +1,185 @@
+/*
+ * Raspberry Pi emulation (c) 2012 Gregory Estrade
+ * Upstreaming code cleanup [including bcm2835_*] (c) 2013 Jan Petrous
+ *
+ * Rasperry Pi 2 emulation and refactoring Copyright (c) 2015, Microsoft
+ * Written by Andrew Baumann
+ *
+ * This code is licensed under the GNU GPLv2 and later.
+ */
+
+#include "hw/arm/bcm2835_peripherals.h"
+#include "hw/arm/bcm2835_mbox.h"
+#include "hw/arm/raspi_platform.h"
+
+static void bcm2835_peripherals_init(Object *obj)
+{
+BCM2835PeripheralState *s = BCM2835_PERIPHERALS(obj);
+
+/* Memory region for peripheral devices, which we export to our parent */
+memory_region_init_io(>peri_mr, OBJECT(s), NULL, s,
+  "bcm2835_peripherals", 0x100);
+object_property_add_child(obj, "peripheral_io", OBJECT(>peri_mr), NULL);
+sysbus_init_mmio(SYS_BUS_DEVICE(s), >peri_mr);
+
+/* Internal memory region for peripheral bus addresses (not exported) */
+memory_region_init_io(>gpu_bus_mr, OBJECT(s), NULL, s, 
"bcm2835_gpu_bus",
+  (uint64_t)1 << 32);
+object_property_add_child(obj, "gpu_bus", OBJECT(>gpu_bus_mr), NULL);
+
+/* Internal memory region for communication of mailbox channel data */
+memory_region_init_io(>mbox_mr, OBJECT(s), NULL, s, "bcm2835_mbox",
+  MBOX_CHAN_COUNT << 4);
+
+/* Interrupt Controller */
+object_initialize(>ic, sizeof(s->ic), TYPE_BCM2835_IC);
+object_property_add_child(obj, "ic", OBJECT(>ic), NULL);
+qdev_set_parent_bus(DEVICE(>ic), sysbus_get_default());
+
+/* UART0 */
+s->uart0 = SYS_BUS_DEVICE(object_new("pl011"));
+object_property_add_child(obj, "uart0", OBJECT(s->uart0), NULL);
+qdev_set_parent_bus(DEVICE(s->uart0), sysbus_get_default());
+
+/* Semaphores / Doorbells / Mailboxes */
+object_initialize(>sbm, sizeof(s->sbm), TYPE_BCM2835_SBM);
+object_property_add_child(obj, "sbm", OBJECT(>sbm), NULL);
+qdev_set_parent_bus(DEVICE(>sbm), sysbus_get_default());
+
+object_property_add_const_link(OBJECT(>sbm), "mbox_mr",
+   OBJECT(>mbox_mr), _abort);
+
+/* Property channel */
+object_initialize(>property, sizeof(s->property), 
TYPE_BCM2835_PROPERTY);
+object_property_add_child(obj, "property", OBJECT(>property), NULL);
+qdev_set_parent_bus(DEVICE(>property), sysbus_get_default());
+
+object_property_add_const_link(OBJECT(>property), "dma_mr",
+   OBJECT(>gpu_bus_mr), _abort);
+
+/* Extended Mass Media Controller */
+object_initialize(>emmc, sizeof(s->emmc), TYPE_BCM2835_EMMC);
+object_property_add_child(obj, "emmc", OBJECT(>emmc), NULL);
+qdev_set_parent_bus(DEVICE(>emmc), sysbus_get_default());
+}
+
+static void bcm2835_peripherals_realize(DeviceState *dev, Error **errp)
+{
+BCM2835PeripheralState *s = BCM2835_PERIPHERALS(dev);
+MemoryRegion *ram;
+Error *err = NULL;
+uint32_t ram_size;
+int n;
+
+/* Map peripherals and RAM into the GPU address space. */
+memory_region_init_alias(>peri_mr_alias, OBJECT(s),
+ "bcm2835_peripherals", >peri_mr, 0,
+ memory_region_size(>peri_mr));
+
+memory_region_add_subregion_overlap(>gpu_bus_mr, BCM2835_VC_PERI_BASE,
+>peri_mr_alias, 1);
+
+/* XXX: assume that RAM is contiguous and mapped at system address zero */
+ram = memory_region_find(get_system_memory(), 0, 1).mr;
+assert(ram != NULL && memory_region_size(ram) >= 128 * 

[Qemu-devel] [PATCH 7/8] bcm2836: add bcm2836 soc device

2015-12-03 Thread Andrew Baumann
This is the SoC for Raspberry Pi 2.

Signed-off-by: Andrew Baumann 
---
 hw/arm/Makefile.objs |   2 +-
 hw/arm/bcm2836.c | 135 +++
 include/hw/arm/bcm2836.h |  33 
 3 files changed, 169 insertions(+), 1 deletion(-)
 create mode 100644 hw/arm/bcm2836.c
 create mode 100644 include/hw/arm/bcm2836.h

diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index 82cc142..f55f8d2 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -11,7 +11,7 @@ obj-y += armv7m.o exynos4210.o pxa2xx.o pxa2xx_gpio.o 
pxa2xx_pic.o
 obj-$(CONFIG_DIGIC) += digic.o
 obj-y += omap1.o omap2.o strongarm.o
 obj-$(CONFIG_ALLWINNER_A10) += allwinner-a10.o cubieboard.o
-obj-$(CONFIG_RASPI) += bcm2835_peripherals.o
+obj-$(CONFIG_RASPI) += bcm2835_peripherals.o bcm2836.o
 obj-$(CONFIG_STM32F205_SOC) += stm32f205_soc.o
 obj-$(CONFIG_XLNX_ZYNQMP) += xlnx-zynqmp.o xlnx-ep108.o
 obj-$(CONFIG_FSL_IMX25) += fsl-imx25.o imx25_pdk.o
diff --git a/hw/arm/bcm2836.c b/hw/arm/bcm2836.c
new file mode 100644
index 000..4b0544e
--- /dev/null
+++ b/hw/arm/bcm2836.c
@@ -0,0 +1,135 @@
+/*
+ * Raspberry Pi emulation (c) 2012 Gregory Estrade
+ * Upstreaming code cleanup [including bcm2835_*] (c) 2013 Jan Petrous
+ *
+ * Rasperry Pi 2 emulation and refactoring Copyright (c) 2015, Microsoft
+ * Written by Andrew Baumann
+ *
+ * This code is licensed under the GNU GPLv2 and later.
+ */
+
+#include "hw/arm/bcm2836.h"
+#include "hw/arm/raspi_platform.h"
+#include "hw/sysbus.h"
+#include "sysemu/sysemu.h" /* for smp_cpus */
+#include "exec/address-spaces.h"
+
+static void bcm2836_init(Object *obj)
+{
+BCM2836State *s = BCM2836(obj);
+int n;
+
+/* TODO: probably shouldn't be using smp_cpus here */
+assert(smp_cpus <= BCM2836_NCPUS);
+for (n = 0; n < smp_cpus; n++) {
+object_initialize(>cpus[n], sizeof(s->cpus[n]),
+  "cortex-a15-" TYPE_ARM_CPU);
+object_property_add_child(obj, "cpu[*]", OBJECT(>cpus[n]),
+  _abort);
+}
+
+object_initialize(>ic, sizeof(s->ic), TYPE_BCM2836_CONTROL);
+object_property_add_child(obj, "ic", OBJECT(>ic), NULL);
+qdev_set_parent_bus(DEVICE(>ic), sysbus_get_default());
+
+object_initialize(>peripherals, sizeof(s->peripherals),
+  TYPE_BCM2835_PERIPHERALS);
+object_property_add_child(obj, "peripherals", OBJECT(>peripherals),
+  _abort);
+qdev_set_parent_bus(DEVICE(>peripherals), sysbus_get_default());
+}
+
+static void bcm2836_realize(DeviceState *dev, Error **errp)
+{
+BCM2836State *s = BCM2836(dev);
+Error *err = NULL;
+int n;
+
+/* common peripherals from bcm2835 */
+object_property_set_bool(OBJECT(>peripherals), true, "realized", );
+if (err) {
+error_propagate(errp, err);
+return;
+}
+
+sysbus_mmio_map_overlap(SYS_BUS_DEVICE(>peripherals), 0,
+BCM2836_PERI_BASE, 1);
+
+/* bcm2836 interrupt controller (and mailboxes, etc.) */
+object_property_set_bool(OBJECT(>ic), true, "realized", );
+if (err) {
+error_propagate(errp, err);
+return;
+}
+
+sysbus_mmio_map(SYS_BUS_DEVICE(>ic), 0, BCM2836_CONTROL_BASE);
+
+sysbus_connect_irq(SYS_BUS_DEVICE(>peripherals), 0,
+   qdev_get_gpio_in_named(DEVICE(>ic), "gpu_irq", 0));
+sysbus_connect_irq(SYS_BUS_DEVICE(>peripherals), 1,
+   qdev_get_gpio_in_named(DEVICE(>ic), "gpu_fiq", 0));
+
+/* TODO: probably shouldn't be using smp_cpus here */
+assert(smp_cpus <= BCM2836_NCPUS);
+for (n = 0; n < smp_cpus; n++) {
+/* Mirror bcm2836, which has clusterid set to 0xf */
+s->cpus[n].mp_affinity = 0xF00 | n;
+
+/* set periphbase/CBAR value for CPU-local registers */
+object_property_set_int(OBJECT(>cpus[n]),
+BCM2836_PERI_BASE + MCORE_OFFSET,
+"reset-cbar", );
+if (err) {
+error_report_err(err);
+exit(1);
+}
+
+object_property_set_bool(OBJECT(>cpus[n]), true, "realized", );
+if (err) {
+error_report_err(err);
+exit(1);
+}
+
+/* Connect irq/fiq outputs from the interrupt controller. */
+qdev_connect_gpio_out_named(DEVICE(>ic), "irq", n,
+qdev_get_gpio_in(DEVICE(>cpus[n]),
+ ARM_CPU_IRQ));
+qdev_connect_gpio_out_named(DEVICE(>ic), "fiq", n,
+qdev_get_gpio_in(DEVICE(>cpus[n]),
+ ARM_CPU_FIQ));
+
+/* Connect timers from the CPU to the interrupt controller */
+s->cpus[n].gt_timer_outputs[GTIMER_PHYS]
+= qdev_get_gpio_in_named(DEVICE(>ic), "cntpsirq", 0);
+

[Qemu-devel] [PATCH for-2.6 1/2] Add param Error** to msi_init()

2015-12-03 Thread Cao jin
msi_init() is a supporting function in PCI device initialization, in order to
convert .init() to .realize(), it should be modified first.

Bonus: add more comment.
Signed-off-by: Cao jin 
---
 hw/pci/msi.c | 17 +
 include/hw/pci/msi.h |  4 ++--
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/hw/pci/msi.c b/hw/pci/msi.c
index c1dd531..1f5d9e8 100644
--- a/hw/pci/msi.c
+++ b/hw/pci/msi.c
@@ -150,15 +150,23 @@ bool msi_enabled(const PCIDevice *dev)
  PCI_MSI_FLAGS_ENABLE);
 }
 
-int msi_init(struct PCIDevice *dev, uint8_t offset,
- unsigned int nr_vectors, bool msi64bit, bool msi_per_vector_mask)
+/*
+ * @nr_vectors: Multiple Message Capable field of Message Control register
+ * @msi64bit: support 64-bit message address or not
+ * @msi_per_vector_mask: support per-vector masking or not
+ *
+ * return: MSI capability offset in config space
+ */
+int msi_init(struct PCIDevice *dev, uint8_t offset, unsigned int nr_vectors,
+ bool msi64bit, bool msi_per_vector_mask, Error **errp)
 {
 unsigned int vectors_order;
-uint16_t flags;
+uint16_t flags; /* Message Control register value */
 uint8_t cap_size;
 int config_offset;
 
 if (!msi_supported) {
+error_setg(errp, "MSI/MSI-X is not supported by interrupt controller");
 return -ENOTSUP;
 }
 
@@ -182,7 +190,7 @@ int msi_init(struct PCIDevice *dev, uint8_t offset,
 }
 
 cap_size = msi_cap_sizeof(flags);
-config_offset = pci_add_capability(dev, PCI_CAP_ID_MSI, offset, cap_size);
+config_offset = pci_add_capability2(dev, PCI_CAP_ID_MSI, offset, cap_size, 
errp);
 if (config_offset < 0) {
 return config_offset;
 }
@@ -205,6 +213,7 @@ int msi_init(struct PCIDevice *dev, uint8_t offset,
 pci_set_long(dev->wmask + msi_mask_off(dev, msi64bit),
  0x >> (PCI_MSI_VECTORS_MAX - nr_vectors));
 }
+
 return config_offset;
 }
 
diff --git a/include/hw/pci/msi.h b/include/hw/pci/msi.h
index 50e452b..da1dc1a 100644
--- a/include/hw/pci/msi.h
+++ b/include/hw/pci/msi.h
@@ -34,8 +34,8 @@ extern bool msi_supported;
 void msi_set_message(PCIDevice *dev, MSIMessage msg);
 MSIMessage msi_get_message(PCIDevice *dev, unsigned int vector);
 bool msi_enabled(const PCIDevice *dev);
-int msi_init(struct PCIDevice *dev, uint8_t offset,
- unsigned int nr_vectors, bool msi64bit, bool msi_per_vector_mask);
+int msi_init(struct PCIDevice *dev, uint8_t offset, unsigned int nr_vectors,
+ bool msi64bit, bool msi_per_vector_mask, Error **errp);
 void msi_uninit(struct PCIDevice *dev);
 void msi_reset(PCIDevice *dev);
 void msi_notify(PCIDevice *dev, unsigned int vector);
-- 
2.1.0






[Qemu-devel] [PATCH for-2.6 2/2] Modify callers of msi_init()

2015-12-03 Thread Cao jin
Because definition of msi_init() has been changed for the purpose: convert
to realize(). There are 11 callers for now.

Signed-off-by: Cao jin 
---
 hw/audio/intel-hda.c   | 7 ++-
 hw/ide/ich.c   | 2 +-
 hw/net/vmxnet3.c   | 3 ++-
 hw/pci-bridge/ioh3420.c| 6 +-
 hw/pci-bridge/pci_bridge_dev.c | 6 +-
 hw/pci-bridge/xio3130_downstream.c | 7 ++-
 hw/pci-bridge/xio3130_upstream.c   | 7 ++-
 hw/scsi/megasas.c  | 2 +-
 hw/scsi/vmw_pvscsi.c   | 3 ++-
 hw/usb/hcd-xhci.c  | 5 -
 hw/vfio/pci.c  | 3 ++-
 11 files changed, 40 insertions(+), 11 deletions(-)

diff --git a/hw/audio/intel-hda.c b/hw/audio/intel-hda.c
index 433463e..9d733da 100644
--- a/hw/audio/intel-hda.c
+++ b/hw/audio/intel-hda.c
@@ -1130,6 +1130,7 @@ static void intel_hda_realize(PCIDevice *pci, Error 
**errp)
 {
 IntelHDAState *d = INTEL_HDA(pci);
 uint8_t *conf = d->pci.config;
+int ret;
 
 d->name = object_get_typename(OBJECT(d));
 
@@ -1142,7 +1143,11 @@ static void intel_hda_realize(PCIDevice *pci, Error 
**errp)
   "intel-hda", 0x4000);
 pci_register_bar(>pci, 0, 0, >mmio);
 if (d->msi) {
-msi_init(>pci, d->old_msi_addr ? 0x50 : 0x60, 1, true, false);
+ret = msi_init(>pci, d->old_msi_addr ? 0x50 : 0x60, 1, true,
+false, errp);
+if(ret < 0) {
+return;
+}
 }
 
 hda_codec_bus_init(DEVICE(pci), >codecs, sizeof(d->codecs),
diff --git a/hw/ide/ich.c b/hw/ide/ich.c
index 16925fa..94b1809 100644
--- a/hw/ide/ich.c
+++ b/hw/ide/ich.c
@@ -145,7 +145,7 @@ static void pci_ich9_ahci_realize(PCIDevice *dev, Error 
**errp)
 /* Although the AHCI 1.3 specification states that the first capability
  * should be PMCAP, the Intel ICH9 data sheet specifies that the ICH9
  * AHCI device puts the MSI capability first, pointing to 0x80. */
-msi_init(dev, ICH9_MSI_CAP_OFFSET, 1, true, false);
+msi_init(dev, ICH9_MSI_CAP_OFFSET, 1, true, false, errp);
 }
 
 static void pci_ich9_uninit(PCIDevice *dev)
diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
index 5e3a233..4269141 100644
--- a/hw/net/vmxnet3.c
+++ b/hw/net/vmxnet3.c
@@ -2140,9 +2140,10 @@ vmxnet3_init_msi(VMXNET3State *s)
 {
 PCIDevice *d = PCI_DEVICE(s);
 int res;
+Error *local_err = NULL;
 
 res = msi_init(d, VMXNET3_MSI_OFFSET, VMXNET3_MAX_NMSIX_INTRS,
-   VMXNET3_USE_64BIT, VMXNET3_PER_VECTOR_MASK);
+   VMXNET3_USE_64BIT, VMXNET3_PER_VECTOR_MASK, _err);
 if (0 > res) {
 VMW_WRPRN("Failed to initialize MSI, error %d", res);
 s->msi_used = false;
diff --git a/hw/pci-bridge/ioh3420.c b/hw/pci-bridge/ioh3420.c
index eead195..05b004a 100644
--- a/hw/pci-bridge/ioh3420.c
+++ b/hw/pci-bridge/ioh3420.c
@@ -96,6 +96,7 @@ static int ioh3420_initfn(PCIDevice *d)
 PCIEPort *p = PCIE_PORT(d);
 PCIESlot *s = PCIE_SLOT(d);
 int rc;
+Error *local_err = NULL;
 
 pci_bridge_initfn(d, TYPE_PCIE_BUS);
 pcie_port_init_reg(d);
@@ -105,12 +106,15 @@ static int ioh3420_initfn(PCIDevice *d)
 if (rc < 0) {
 goto err_bridge;
 }
+
 rc = msi_init(d, IOH_EP_MSI_OFFSET, IOH_EP_MSI_NR_VECTOR,
   IOH_EP_MSI_SUPPORTED_FLAGS & PCI_MSI_FLAGS_64BIT,
-  IOH_EP_MSI_SUPPORTED_FLAGS & PCI_MSI_FLAGS_MASKBIT);
+  IOH_EP_MSI_SUPPORTED_FLAGS & PCI_MSI_FLAGS_MASKBIT,
+  _err);
 if (rc < 0) {
 goto err_bridge;
 }
+
 rc = pcie_cap_init(d, IOH_EP_EXP_OFFSET, PCI_EXP_TYPE_ROOT_PORT, p->port);
 if (rc < 0) {
 goto err_msi;
diff --git a/hw/pci-bridge/pci_bridge_dev.c b/hw/pci-bridge/pci_bridge_dev.c
index bc3e1b7..13e8583 100644
--- a/hw/pci-bridge/pci_bridge_dev.c
+++ b/hw/pci-bridge/pci_bridge_dev.c
@@ -51,6 +51,7 @@ static int pci_bridge_dev_initfn(PCIDevice *dev)
 PCIBridge *br = PCI_BRIDGE(dev);
 PCIBridgeDev *bridge_dev = PCI_BRIDGE_DEV(dev);
 int err;
+Error *local_err = NULL;
 
 pci_bridge_initfn(dev, TYPE_PCI_BUS);
 
@@ -66,13 +67,15 @@ static int pci_bridge_dev_initfn(PCIDevice *dev)
 /* MSI is not applicable without SHPC */
 bridge_dev->flags &= ~(1 << PCI_BRIDGE_DEV_F_MSI_REQ);
 }
+
 err = slotid_cap_init(dev, 0, bridge_dev->chassis_nr, 0);
 if (err) {
 goto slotid_error;
 }
+
 if ((bridge_dev->flags & (1 << PCI_BRIDGE_DEV_F_MSI_REQ)) &&
 msi_supported) {
-err = msi_init(dev, 0, 1, true, true);
+err = msi_init(dev, 0, 1, true, true, _err);
 if (err < 0) {
 goto msi_error;
 }
@@ -84,6 +87,7 @@ static int pci_bridge_dev_initfn(PCIDevice *dev)
  PCI_BASE_ADDRESS_MEM_TYPE_64, _dev->bar);
 }
 return 0;
+
 msi_error:
 slotid_cap_cleanup(dev);
 slotid_error:
diff --git 

[Qemu-devel] [PATCH 2/8] bcm2835_property: add bcm2835 property channel

2015-12-03 Thread Andrew Baumann
This sits behind the mailbox interface, and implements
request/response queries for system properties. The
framebuffer-related properties will be added in a later patch.

Signed-off-by: Andrew Baumann 
---
 hw/misc/Makefile.objs  |   1 +
 hw/misc/bcm2835_property.c | 262 +
 include/hw/misc/bcm2835_property.h |  27 
 3 files changed, 290 insertions(+)
 create mode 100644 hw/misc/bcm2835_property.c
 create mode 100644 include/hw/misc/bcm2835_property.h

diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index b9379f2..f4286f2 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -34,6 +34,7 @@ obj-$(CONFIG_OMAP) += omap_gpmc.o
 obj-$(CONFIG_OMAP) += omap_l4.o
 obj-$(CONFIG_OMAP) += omap_sdrc.o
 obj-$(CONFIG_OMAP) += omap_tap.o
+obj-$(CONFIG_RASPI) += bcm2835_property.o
 obj-$(CONFIG_RASPI) += bcm2835_sbm.o
 obj-$(CONFIG_SLAVIO) += slavio_misc.o
 obj-$(CONFIG_ZYNQ) += zynq_slcr.o
diff --git a/hw/misc/bcm2835_property.c b/hw/misc/bcm2835_property.c
new file mode 100644
index 000..d25c056
--- /dev/null
+++ b/hw/misc/bcm2835_property.c
@@ -0,0 +1,262 @@
+/*
+ * Raspberry Pi emulation (c) 2012 Gregory Estrade
+ * This code is licensed under the GNU GPLv2 and later.
+ */
+
+#include "hw/misc/bcm2835_property.h"
+#include "hw/arm/bcm2835_mbox.h"
+
+/* https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface */
+
+static void bcm2835_property_mbox_push(BCM2835PropertyState *s, uint32_t value)
+{
+uint32_t tag;
+uint32_t bufsize;
+uint32_t tot_len;
+size_t resplen;
+uint32_t tmp;
+
+value &= ~0xf;
+
+s->addr = value;
+
+tot_len = ldl_phys(>dma_as, value);
+
+/* @(addr + 4) : Buffer response code */
+value = s->addr + 8;
+while (value + 8 <= s->addr + tot_len) {
+tag = ldl_phys(>dma_as, value);
+bufsize = ldl_phys(>dma_as, value + 4);
+/* @(value + 8) : Request/response indicator */
+resplen = 0;
+switch (tag) {
+case 0x: /* End tag */
+break;
+case 0x0001: /* Get firmware revision */
+stl_phys(>dma_as, value + 12, 346337);
+resplen = 4;
+break;
+
+case 0x00010001: /* Get board model */
+resplen = 4;
+break;
+case 0x00010002: /* Get board revision */
+resplen = 4;
+break;
+case 0x00010003: /* Get board MAC address */
+/* write the first four bytes of the 6-byte MAC */
+stl_phys(>dma_as, value + 12, 0xB827EBD0);
+/* write the last two bytes, avoid any write past the buffer end */
+stb_phys(>dma_as, value + 16, 0xEE);
+stb_phys(>dma_as, value + 17, 0xDF);
+resplen = 6;
+break;
+case 0x00010004: /* Get board serial */
+resplen = 8;
+break;
+case 0x00010005: /* Get ARM memory */
+/* base */
+stl_phys(>dma_as, value + 12, 0);
+/* size */
+stl_phys(>dma_as, value + 16, s->ram_size);
+resplen = 8;
+break;
+case 0x00028001: /* Set power state */
+/* Assume that whatever device they asked for exists,
+ * and we'll just claim we set it to the desired state */
+tmp = ldl_phys(>dma_as, value + 16);
+stl_phys(>dma_as, value + 16, (tmp & 1));
+resplen = 8;
+break;
+
+/* Clocks */
+
+case 0x00030001: /* Get clock state */
+stl_phys(>dma_as, value + 16, 0x1);
+resplen = 8;
+break;
+
+case 0x00038001: /* Set clock state */
+resplen = 8;
+break;
+
+case 0x00030002: /* Get clock rate */
+case 0x00030004: /* Get max clock rate */
+case 0x00030007: /* Get min clock rate */
+switch (ldl_phys(>dma_as, value + 12)) {
+case 1: /* EMMC */
+stl_phys(>dma_as, value + 16, 5000);
+break;
+case 2: /* UART */
+stl_phys(>dma_as, value + 16, 300);
+break;
+default:
+stl_phys(>dma_as, value + 16, 7);
+break;
+}
+resplen = 8;
+break;
+
+case 0x00038002: /* Set clock rate */
+case 0x00038004: /* Set max clock rate */
+case 0x00038007: /* Set min clock rate */
+resplen = 8;
+break;
+
+/* Temperature */
+
+case 0x00030006: /* Get temperature */
+stl_phys(>dma_as, value + 16, 25000);
+resplen = 8;
+break;
+
+case 0x0003000A: /* Get max temperature */
+stl_phys(>dma_as, value + 16, 99000);
+resplen = 8;
+break;
+
+
+case 0x00060001: /* Get DMA channels */
+/* channels 2-5 

[Qemu-devel] [PATCH 4/8] bcm2835_emmc: add bcm2835 MMC/SD controller

2015-12-03 Thread Andrew Baumann
Signed-off-by: Andrew Baumann 
---
 hw/sd/Makefile.objs  |   1 +
 hw/sd/bcm2835_emmc.c | 800 +++
 include/hw/sd/bcm2835_emmc.h |  56 +++
 3 files changed, 857 insertions(+)
 create mode 100644 hw/sd/bcm2835_emmc.c
 create mode 100644 include/hw/sd/bcm2835_emmc.h

diff --git a/hw/sd/Makefile.objs b/hw/sd/Makefile.objs
index f1aed83..b9cb9b8 100644
--- a/hw/sd/Makefile.objs
+++ b/hw/sd/Makefile.objs
@@ -6,3 +6,4 @@ common-obj-$(CONFIG_SDHCI) += sdhci.o
 obj-$(CONFIG_MILKYMIST) += milkymist-memcard.o
 obj-$(CONFIG_OMAP) += omap_mmc.o
 obj-$(CONFIG_PXA2XX) += pxa2xx_mmci.o
+obj-$(CONFIG_RASPI) += bcm2835_emmc.o
diff --git a/hw/sd/bcm2835_emmc.c b/hw/sd/bcm2835_emmc.c
new file mode 100644
index 000..46628b5
--- /dev/null
+++ b/hw/sd/bcm2835_emmc.c
@@ -0,0 +1,800 @@
+/*
+ * Raspberry Pi emulation (c) 2012 Gregory Estrade
+ * This code is licensed under the GNU GPLv2 and later.
+ */
+
+#include "sysemu/blockdev.h"
+#include "hw/sd/bcm2835_emmc.h"
+
+/*
+ * Controller registers
+ */
+
+#define SDHCI_DMA_ADDRESS   0x00
+#define SDHCI_ARGUMENT2 SDHCI_DMA_ADDRESS
+
+#define SDHCI_BLOCK_SIZE0x04
+#define  SDHCI_MAKE_BLKSZ(dma, blksz) (((dma & 0x7) << 12) | (blksz & 0xFFF))
+
+#define SDHCI_BLOCK_COUNT   0x06
+
+#define SDHCI_ARGUMENT  0x08
+
+#define SDHCI_TRANSFER_MODE 0x0C
+#define  SDHCI_TRNS_DMA 0x01
+#define  SDHCI_TRNS_BLK_CNT_EN  0x02
+#define  SDHCI_TRNS_AUTO_CMD12  0x04
+#define  SDHCI_TRNS_AUTO_CMD23  0x08
+#define  SDHCI_TRNS_READ0x10
+#define  SDHCI_TRNS_MULTI   0x20
+
+#define SDHCI_COMMAND   0x0E
+#define  SDHCI_CMD_RESP_MASK0x03
+#define  SDHCI_CMD_CRC  0x08
+#define  SDHCI_CMD_INDEX0x10
+#define  SDHCI_CMD_DATA 0x20
+#define  SDHCI_CMD_ABORTCMD 0xC0
+
+#define  SDHCI_CMD_RESP_NONE0x00
+#define  SDHCI_CMD_RESP_LONG0x01
+#define  SDHCI_CMD_RESP_SHORT   0x02
+#define  SDHCI_CMD_RESP_SHORT_BUSY 0x03
+
+#define SDHCI_MAKE_CMD(c, f) (((c & 0xff) << 8) | (f & 0xff))
+#define SDHCI_GET_CMD(c) ((c>>8) & 0x3f)
+
+#define SDHCI_RESPONSE  0x10
+
+#define SDHCI_BUFFER0x20
+
+#define SDHCI_PRESENT_STATE 0x24
+#define  SDHCI_CMD_INHIBIT  0x0001
+#define  SDHCI_DATA_INHIBIT 0x0002
+#define  SDHCI_DOING_WRITE  0x0100
+#define  SDHCI_DOING_READ   0x0200
+#define  SDHCI_SPACE_AVAILABLE  0x0400
+#define  SDHCI_DATA_AVAILABLE   0x0800
+#define  SDHCI_CARD_PRESENT 0x0001
+#define  SDHCI_WRITE_PROTECT0x0008
+#define  SDHCI_DATA_LVL_MASK0x00F0
+#define   SDHCI_DATA_LVL_SHIFT  20
+
+#define SDHCI_HOST_CONTROL  0x28
+#define  SDHCI_CTRL_LED 0x01
+#define  SDHCI_CTRL_4BITBUS 0x02
+#define  SDHCI_CTRL_HISPD   0x04
+#define  SDHCI_CTRL_DMA_MASK0x18
+#define   SDHCI_CTRL_SDMA   0x00
+#define   SDHCI_CTRL_ADMA1  0x08
+#define   SDHCI_CTRL_ADMA32 0x10
+#define   SDHCI_CTRL_ADMA64 0x18
+#define   SDHCI_CTRL_8BITBUS0x20
+
+#define SDHCI_POWER_CONTROL 0x29
+#define  SDHCI_POWER_ON 0x01
+#define  SDHCI_POWER_1800x0A
+#define  SDHCI_POWER_3000x0C
+#define  SDHCI_POWER_3300x0E
+
+#define SDHCI_BLOCK_GAP_CONTROL 0x2A
+
+#define SDHCI_WAKE_UP_CONTROL   0x2B
+#define  SDHCI_WAKE_ON_INT  0x01
+#define  SDHCI_WAKE_ON_INSERT   0x02
+#define  SDHCI_WAKE_ON_REMOVE   0x04
+
+#define SDHCI_CLOCK_CONTROL 0x2C
+#define  SDHCI_DIVIDER_SHIFT8
+#define  SDHCI_DIVIDER_HI_SHIFT 6
+#define  SDHCI_DIV_MASK 0xFF
+#define  SDHCI_DIV_MASK_LEN 8
+#define  SDHCI_DIV_HI_MASK  0x300
+#define  SDHCI_PROG_CLOCK_MODE  0x0020
+#define  SDHCI_CLOCK_CARD_EN0x0004
+#define  SDHCI_CLOCK_INT_STABLE 0x0002
+#define  SDHCI_CLOCK_INT_EN 0x0001
+
+#define SDHCI_TIMEOUT_CONTROL   0x2E
+
+#define SDHCI_SOFTWARE_RESET0x2F
+#define  SDHCI_RESET_ALL0x01
+#define  SDHCI_RESET_CMD0x02
+#define  SDHCI_RESET_DATA   0x04
+
+#define SDHCI_INT_STATUS0x30
+#define SDHCI_INT_ENABLE0x34
+#define SDHCI_SIGNAL_ENABLE 0x38
+#define  SDHCI_INT_RESPONSE 0x0001
+#define  SDHCI_INT_DATA_END 0x0002
+#define  SDHCI_INT_DMA_END  0x0008
+#define  SDHCI_INT_SPACE_AVAIL  0x0010
+#define  SDHCI_INT_DATA_AVAIL   0x0020
+#define  SDHCI_INT_CARD_INSERT  0x0040
+#define  SDHCI_INT_CARD_REMOVE  0x0080
+#define  SDHCI_INT_CARD_INT 0x0100
+#define  SDHCI_INT_ERROR0x8000
+#define  SDHCI_INT_TIMEOUT  0x0001
+#define  SDHCI_INT_CRC  0x0002
+#define  SDHCI_INT_END_BIT  0x0004
+#define  SDHCI_INT_INDEX0x0008
+#define  SDHCI_INT_DATA_TIMEOUT 0x0010
+#define  SDHCI_INT_DATA_CRC 0x0020
+#define  SDHCI_INT_DATA_END_BIT 0x0040
+#define  SDHCI_INT_BUS_POWER0x0080
+#define  SDHCI_INT_ACMD12ERR0x0100
+#define  SDHCI_INT_ADMA_ERROR   0x0200
+
+#define  SDHCI_INT_NORMAL_MASK  0x7FFF
+#define  SDHCI_INT_ERROR_MASK   0x8000
+
+#define  SDHCI_INT_CMD_MASK (SDHCI_INT_RESPONSE | SDHCI_INT_TIMEOUT | \
+SDHCI_INT_CRC | SDHCI_INT_END_BIT | SDHCI_INT_INDEX)
+#define  

[Qemu-devel] [PATCH 6/8] bcm2836_control: add bcm2836 ARM control logic

2015-12-03 Thread Andrew Baumann
This module is specific to the bcm2836 (Pi2). It implements the top
level interrupt controller, and mailboxes used for inter-processor
synchronisation.

Signed-off-by: Andrew Baumann 
---
 hw/intc/Makefile.objs |   2 +-
 hw/intc/bcm2836_control.c | 344 ++
 include/hw/intc/bcm2836_control.h |  49 ++
 3 files changed, 394 insertions(+), 1 deletion(-)
 create mode 100644 hw/intc/bcm2836_control.c
 create mode 100644 include/hw/intc/bcm2836_control.h

diff --git a/hw/intc/Makefile.objs b/hw/intc/Makefile.objs
index 2ad1204..6a13a39 100644
--- a/hw/intc/Makefile.objs
+++ b/hw/intc/Makefile.objs
@@ -24,7 +24,7 @@ obj-$(CONFIG_GRLIB) += grlib_irqmp.o
 obj-$(CONFIG_IOAPIC) += ioapic.o
 obj-$(CONFIG_OMAP) += omap_intc.o
 obj-$(CONFIG_OPENPIC_KVM) += openpic_kvm.o
-obj-$(CONFIG_RASPI) += bcm2835_ic.o
+obj-$(CONFIG_RASPI) += bcm2835_ic.o bcm2836_control.o
 obj-$(CONFIG_SH4) += sh_intc.o
 obj-$(CONFIG_XICS) += xics.o
 obj-$(CONFIG_XICS_KVM) += xics_kvm.o
diff --git a/hw/intc/bcm2836_control.c b/hw/intc/bcm2836_control.c
new file mode 100644
index 000..c47b36f
--- /dev/null
+++ b/hw/intc/bcm2836_control.c
@@ -0,0 +1,344 @@
+/*
+ * Rasperry Pi 2 emulation ARM control logic module.
+ * Copyright (c) 2015, Microsoft
+ * Written by Andrew Baumann
+ *
+ * At present, only implements interrupt routing, and mailboxes (i.e.,
+ * not local timer, PMU interrupt, or AXI counters).
+ *
+ * Ref:
+ * 
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2836/QA7_rev3.4.pdf
+ *
+ * Based on bcm2835_ic.c, terms below...
+ */
+
+/*
+ * Raspberry Pi emulation (c) 2012 Gregory Estrade
+ * This code is licensed under the GNU GPLv2 and later.
+ */
+
+/* Heavily based on pl190.c, copyright terms below. */
+
+/*
+ * Arm PrimeCell PL190 Vector Interrupt Controller
+ *
+ * Copyright (c) 2006 CodeSourcery.
+ * Written by Paul Brook
+ *
+ * This code is licensed under the GPL.
+ */
+
+#include "hw/intc/bcm2836_control.h"
+
+#define ROUTE_CORE(x) ((x) & 0x3)
+#define ROUTE_FIQ(x)  (((x) & 0x4) != 0)
+
+#define IRQ_BIT(cntrl, num) (((cntrl) & (1 << (num))) != 0)
+#define FIQ_BIT(cntrl, num) (((cntrl) & (1 << ((num) + 4))) != 0)
+
+#define IRQ_CNTPSIRQ0
+#define IRQ_CNTPNSIRQ   1
+#define IRQ_CNTHPIRQ2
+#define IRQ_CNTVIRQ 3
+#define IRQ_MAILBOX04
+#define IRQ_MAILBOX15
+#define IRQ_MAILBOX26
+#define IRQ_MAILBOX37
+#define IRQ_GPU 8
+#define IRQ_PMU 9
+#define IRQ_AXI 10
+#define IRQ_TIMER   11
+#define IRQ_MAX IRQ_TIMER
+
+/* Update interrupts.  */
+static void bcm2836_control_update(BCM2836ControlState *s)
+{
+int i, j;
+
+/*
+ * reset pending IRQs/FIQs
+ */
+
+for (i = 0; i < BCM2836_NCORES; i++) {
+s->irqsrc[i] = s->fiqsrc[i] = 0;
+}
+
+/*
+ * apply routing logic, update status regs
+ */
+
+if (s->gpu_irq) {
+assert(s->route_gpu_irq < BCM2836_NCORES);
+s->irqsrc[s->route_gpu_irq] |= (uint32_t)1 << IRQ_GPU;
+}
+
+if (s->gpu_fiq) {
+assert(s->route_gpu_fiq < BCM2836_NCORES);
+s->fiqsrc[s->route_gpu_fiq] |= (uint32_t)1 << IRQ_GPU;
+}
+
+for (i = 0; i < BCM2836_NCORES; i++) {
+/* handle local interrupts for this core */
+if (s->localirqs[i]) {
+assert(s->localirqs[i] < (1 << IRQ_MAILBOX0));
+for (j = 0; j < IRQ_MAILBOX0; j++) {
+if ((s->localirqs[i] & (1 << j)) != 0) {
+/* local interrupt j is set */
+if (FIQ_BIT(s->timercontrol[i], j)) {
+/* deliver a FIQ */
+s->fiqsrc[i] |= (uint32_t)1 << j;
+} else if (IRQ_BIT(s->timercontrol[i], j)) {
+/* deliver an IRQ */
+s->irqsrc[i] |= (uint32_t)1 << j;
+} else {
+/* the interrupt is masked */
+}
+}
+}
+}
+
+/* handle mailboxes for this core */
+for (j = 0; j < BCM2836_MBPERCORE; j++) {
+if (s->mailboxes[i * BCM2836_MBPERCORE + j] != 0) {
+/* mailbox j is set */
+if (FIQ_BIT(s->mailboxcontrol[i], j)) {
+/* deliver a FIQ */
+s->fiqsrc[i] |= (uint32_t)1 << (j + IRQ_MAILBOX0);
+} else if (IRQ_BIT(s->mailboxcontrol[i], j)) {
+/* deliver an IRQ */
+s->irqsrc[i] |= (uint32_t)1 << (j + IRQ_MAILBOX0);
+} else {
+/* the interrupt is masked */
+}
+}
+}
+}
+
+/*
+ * call set_irq appropriately for each output
+ */
+
+for (i = 0; i < BCM2836_NCORES; i++) {
+qemu_set_irq(s->irq[i], s->irqsrc[i] != 0);
+qemu_set_irq(s->fiq[i], s->fiqsrc[i] != 0);
+}
+}
+
+static void 

[Qemu-devel] [PATCH 3/8] bcm2835_ic: add bcm2835 interrupt controller

2015-12-03 Thread Andrew Baumann
Signed-off-by: Andrew Baumann 
---
 hw/intc/Makefile.objs|   1 +
 hw/intc/bcm2835_ic.c | 234 +++
 include/hw/intc/bcm2835_ic.h |  26 +
 3 files changed, 261 insertions(+)
 create mode 100644 hw/intc/bcm2835_ic.c
 create mode 100644 include/hw/intc/bcm2835_ic.h

diff --git a/hw/intc/Makefile.objs b/hw/intc/Makefile.objs
index 004b0c2..2ad1204 100644
--- a/hw/intc/Makefile.objs
+++ b/hw/intc/Makefile.objs
@@ -24,6 +24,7 @@ obj-$(CONFIG_GRLIB) += grlib_irqmp.o
 obj-$(CONFIG_IOAPIC) += ioapic.o
 obj-$(CONFIG_OMAP) += omap_intc.o
 obj-$(CONFIG_OPENPIC_KVM) += openpic_kvm.o
+obj-$(CONFIG_RASPI) += bcm2835_ic.o
 obj-$(CONFIG_SH4) += sh_intc.o
 obj-$(CONFIG_XICS) += xics.o
 obj-$(CONFIG_XICS_KVM) += xics_kvm.o
diff --git a/hw/intc/bcm2835_ic.c b/hw/intc/bcm2835_ic.c
new file mode 100644
index 000..2419575
--- /dev/null
+++ b/hw/intc/bcm2835_ic.c
@@ -0,0 +1,234 @@
+/*
+ * Raspberry Pi emulation (c) 2012 Gregory Estrade
+ * This code is licensed under the GNU GPLv2 and later.
+ */
+
+/* Heavily based on pl190.c, copyright terms below. */
+
+/*
+ * Arm PrimeCell PL190 Vector Interrupt Controller
+ *
+ * Copyright (c) 2006 CodeSourcery.
+ * Written by Paul Brook
+ *
+ * This code is licensed under the GPL.
+ */
+
+#include "hw/intc/bcm2835_ic.h"
+
+#define IR_B 2
+#define IR_1 0
+#define IR_2 1
+
+/* Update interrupts.  */
+static void bcm2835_ic_update(BCM2835IcState *s)
+{
+int set;
+int i;
+
+set = 0;
+if (s->fiq_enable) {
+set = s->level[s->fiq_select >> 5] & (1u << (s->fiq_select & 0x1f));
+}
+qemu_set_irq(s->fiq, set);
+
+set = 0;
+for (i = 0; i < 3; i++) {
+set |= (s->level[i] & s->irq_enable[i]);
+}
+qemu_set_irq(s->irq, set);
+
+}
+
+static void bcm2835_ic_set_irq(void *opaque, int irq, int level)
+{
+BCM2835IcState *s = (BCM2835IcState *)opaque;
+
+if (irq >= 0 && irq <= 71) {
+if (level) {
+s->level[irq >> 5] |= 1u << (irq & 0x1f);
+} else {
+s->level[irq >> 5] &= ~(1u << (irq & 0x1f));
+}
+} else {
+qemu_log_mask(LOG_GUEST_ERROR,
+"bcm2835_ic_set_irq: Bad irq %d\n", irq);
+}
+
+bcm2835_ic_update(s);
+}
+
+static const int irq_dups[] = { 7, 9, 10, 18, 19, 53, 54, 55, 56, 57, 62, -1 };
+
+static uint64_t bcm2835_ic_read(void *opaque, hwaddr offset,
+unsigned size)
+{
+BCM2835IcState *s = (BCM2835IcState *)opaque;
+int i;
+int p = 0;
+uint32_t res = 0;
+
+switch (offset) {
+case 0x00:  /* IRQ basic pending */
+/* bits 0-7 - ARM irqs */
+res = (s->level[IR_B] & s->irq_enable[IR_B]) & 0xff;
+for (i = 0; i < 64; i++) {
+if (i == irq_dups[p]) {
+/* bits 10-20 - selected GPU irqs */
+if (s->level[i >> 5] & s->irq_enable[i >> 5]
+& (1u << (i & 0x1f))) {
+res |= (1u << (10 + p));
+}
+p++;
+} else {
+/* bits 8-9 - one or more bits set in pending registers 1-2 */
+if (s->level[i >> 5] & s->irq_enable[i >> 5]
+& (1u << (i & 0x1f))) {
+res |= (1u << (8 + (i >> 5)));
+}
+}
+}
+break;
+case 0x04:  /* IRQ pending 1 */
+res = s->level[IR_1] & s->irq_enable[IR_1];
+break;
+case 0x08:  /* IRQ pending 2 */
+res = s->level[IR_2] & s->irq_enable[IR_2];
+break;
+case 0x0C:  /* FIQ register */
+res = (s->fiq_enable << 7) | s->fiq_select;
+break;
+case 0x10:  /* Interrupt enable register 1 */
+res = s->irq_enable[IR_1];
+break;
+case 0x14:  /* Interrupt enable register 2 */
+res = s->irq_enable[IR_2];
+break;
+case 0x18:  /* Base interrupt enable register */
+res = s->irq_enable[IR_B];
+break;
+case 0x1C:  /* Interrupt disable register 1 */
+res = ~s->irq_enable[IR_1];
+break;
+case 0x20:  /* Interrupt disable register 2 */
+res = ~s->irq_enable[IR_2];
+break;
+case 0x24:  /* Base interrupt disable register */
+res = ~s->irq_enable[IR_B];
+break;
+default:
+qemu_log_mask(LOG_GUEST_ERROR,
+"bcm2835_ic_read: Bad offset %x\n", (int)offset);
+return 0;
+}
+
+return res;
+}
+
+static void bcm2835_ic_write(void *opaque, hwaddr offset,
+uint64_t val, unsigned size)
+{
+BCM2835IcState *s = (BCM2835IcState *)opaque;
+
+switch (offset) {
+case 0x0C:  /* FIQ register */
+s->fiq_select = (val & 0x7f);
+s->fiq_enable = (val >> 7) & 0x1;
+break;
+case 0x10:  /* Interrupt enable register 1 */
+s->irq_enable[IR_1] |= val;
+break;
+case 0x14:  /* Interrupt enable register 2 */
+s->irq_enable[IR_2] |= val;
+break;
+

Re: [Qemu-devel] [RFC PATCH V2 00/10] Qemu: Add live migration support for SRIOV NIC

2015-12-03 Thread Lan, Tianyu


On 12/2/2015 10:31 PM, Michael S. Tsirkin wrote:

>We hope
>to find a better way to make SRIOV NIC work in these cases and this is
>worth to do since SRIOV NIC provides better network performance compared
>with PV NIC.

If this is a performance optimization as the above implies,
you need to include some numbers, and document how did
you implement the switch and how did you measure the performance.



OK. Some ideas of my patches come from paper "CompSC: Live Migration with
Pass-through Devices".
http://www.cl.cam.ac.uk/research/srg/netos/vee_2012/papers/p109.pdf

It compared performance data between the solution of switching PV and VF 
and VF migration.(Chapter 7: Discussion)




>Current patches have some issues. I think we can find
>solution for them andimprove them step by step.




[Qemu-devel] [PATCH for 2.6 v3 1/1] qemu-char: append opt to stop truncation of serial file

2015-12-03 Thread Denis V. Lunev
From: Olga Krishtal 

Our QA team wants to preserve serial output of the guest in between QEMU
runs to perform post-analysis.

By default this behavior is off (file is truncated each time QEMU is
started or device is plugged).

Signed-off-by: Olga Krishtal 
Signed-off-by: Denis V. Lunev 
CC: Eric Blake 
CC: Markus Armbruster 
CC: Paolo Bonzini 
---
Changes from v1:
  - s/parallels.com/virtuozzo.com/ :(

Changes from v2:
  - fixed QAPI description
  - added has_append filling and checking

qapi-schema.json |  5 -
 qemu-char.c  | 14 +-
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/qapi-schema.json b/qapi-schema.json
index 18c9a6c..89201a9 100644
--- a/qapi-schema.json
+++ b/qapi-schema.json
@@ -3020,11 +3020,14 @@
 #
 # @in:  #optional The name of the input file
 # @out: The name of the output file
+# @append: #optional Open the file in append mode (default false to
+#  truncate) (Since 2.6)
 #
 # Since: 1.4
 ##
 { 'struct': 'ChardevFile', 'data': { '*in' : 'str',
-   'out' : 'str' } }
+   'out' : 'str',
+   '*append': 'bool' } }
 
 ##
 # @ChardevHostdev:
diff --git a/qemu-char.c b/qemu-char.c
index 2969c44..66703e3 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -3484,6 +3484,9 @@ static void qemu_chr_parse_file_out(QemuOpts *opts, 
ChardevBackend *backend,
 }
 backend->u.file = g_new0(ChardevFile, 1);
 backend->u.file->out = g_strdup(path);
+
+backend->u.file->has_append = true;
+backend->u.file->append = qemu_opt_get_bool(opts, "append", false);
 }
 
 static void qemu_chr_parse_stdio(QemuOpts *opts, ChardevBackend *backend,
@@ -4041,6 +4044,9 @@ QemuOptsList qemu_chardev_opts = {
 },{
 .name = "chardev",
 .type = QEMU_OPT_STRING,
+},{
+.name = "append",
+.type = QEMU_OPT_BOOL,
 },
 { /* end of list */ }
 },
@@ -4101,7 +4107,13 @@ static CharDriverState *qmp_chardev_open_file(const char 
*id,
 ChardevFile *file = backend->u.file;
 int flags, in = -1, out;
 
-flags = O_WRONLY | O_TRUNC | O_CREAT | O_BINARY;
+flags = O_WRONLY | O_CREAT | O_BINARY;
+if (file->has_append && file->append) {
+flags |= O_APPEND;
+} else {
+flags |= O_TRUNC;
+}
+
 out = qmp_chardev_open_file_source(file->out, flags, errp);
 if (out < 0) {
 return NULL;
-- 
2.5.0




[Qemu-devel] [PULL 4/9] crypto: avoid two coverity false positive error reports

2015-12-03 Thread Michael Tokarev
From: "Daniel P. Berrange" 

In qcrypto_tls_creds_get_path() coverity complains that
we are checking '*creds' for NULL, despite having
dereferenced it previously. This is harmless bug due
to fact that the trace call was too early. Moving it
after the cleanup gets the desired semantics.

In qcrypto_tls_creds_check_cert_key_purpose() coverity
complains that we're passing a pointer to a previously
free'd buffer into gnutls_x509_crt_get_key_purpose_oid()
This is harmless because we're passing a size == 0, so
gnutls won't access the buffer, but rather just report
what size it needs to be. We can avoid it though by
explicitly setting the buffer to NULL after free'ing
it.

Signed-off-by: Daniel P. Berrange 
Reviewed-by: Eric Blake 
Signed-off-by: Michael Tokarev 
---
 crypto/tlscreds.c | 4 ++--
 crypto/tlscredsx509.c | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/crypto/tlscreds.c b/crypto/tlscreds.c
index 5ec982c..e7d9c1c 100644
--- a/crypto/tlscreds.c
+++ b/crypto/tlscreds.c
@@ -123,10 +123,10 @@ qcrypto_tls_creds_get_path(QCryptoTLSCreds *creds,
 goto cleanup;
 }
 
-trace_qcrypto_tls_creds_get_path(creds, filename,
- *cred ? *cred : "");
 ret = 0;
  cleanup:
+trace_qcrypto_tls_creds_get_path(creds, filename,
+ *cred ? *cred : "");
 return ret;
 }
 
diff --git a/crypto/tlscredsx509.c b/crypto/tlscredsx509.c
index d080deb..26f18cb 100644
--- a/crypto/tlscredsx509.c
+++ b/crypto/tlscredsx509.c
@@ -255,6 +255,7 @@ 
qcrypto_tls_creds_check_cert_key_purpose(QCryptoTLSCredsX509 *creds,
 }
 
 g_free(buffer);
+buffer = NULL;
 }
 
 if (isServer) {
-- 
2.1.4




[Qemu-devel] [PULL 3/9] configure: Diagnose broken linkers directly

2015-12-03 Thread Michael Tokarev
From: Peter Maydell 

Currently if the user's compiler works for creating .o files but
their linker is broken such that compiling an executable from a
C file does not work, we will report a misleading error message
about the compiler not supporting __thread (since that happens
to be the first test we run which requires a working linker).
Explicitly check that compile_prog works as well as compile_object,
so that people whose toolchain setup is broken get a more helpful
error message.

Signed-off-by: Peter Maydell 
Signed-off-by: Michael Tokarev 
---
 configure | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configure b/configure
index 67801b0..2e8a672 100755
--- a/configure
+++ b/configure
@@ -1428,6 +1428,9 @@ if compile_object ; then
 else
 error_exit "\"$cc\" either does not exist or does not work"
 fi
+if ! compile_prog ; then
+error_exit "\"$cc\" cannot build an executable (is your linker broken?)"
+fi
 
 # Check that the C++ compiler exists and works with the C compiler
 if has $cxx; then
-- 
2.1.4




[Qemu-devel] [PULL 2/9] bt: avoid unintended sign extension

2015-12-03 Thread Michael Tokarev
From: Paolo Bonzini 

In the case of a 4-byte length, shifting a value by 24 may cause
an unintended sign extension when converting from int to size_t.
Use a uint32_t variable instead.

Signed-off-by: Paolo Bonzini 
Reviewed-by: Markus Armbruster 
Signed-off-by: Michael Tokarev 
---
 hw/bt/sdp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/bt/sdp.c b/hw/bt/sdp.c
index b9bcdcc..04eaeca 100644
--- a/hw/bt/sdp.c
+++ b/hw/bt/sdp.c
@@ -42,7 +42,7 @@ struct bt_l2cap_sdp_state_s {
 
 static ssize_t sdp_datalen(const uint8_t **element, ssize_t *left)
 {
-size_t len = *(*element) ++ & SDP_DSIZE_MASK;
+uint32_t len = *(*element) ++ & SDP_DSIZE_MASK;
 
 if (!*left)
 return -1;
-- 
2.1.4




[Qemu-devel] [PATCH] ivshmem: Store file descriptor for vhost-user negotiation

2015-12-03 Thread Tetsuya Mukawa
If virtio-net driver allocates memory in vishmem shared memory,
vhost-net will work correctly, but vhost-user will not work because
a fd of shared memory will not be sent to vhost-user backend.
This patch fixes ivshmem to store file descriptor of shared memory.
It will be used when vhost-user negotiates vhost-user backend.

Signed-off-by: Tetsuya Mukawa 
---
 exec.c  | 10 ++
 hw/misc/ivshmem.c   |  9 +++--
 include/exec/ram_addr.h |  1 +
 3 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/exec.c b/exec.c
index 0bf0a6e..908c4bf 100644
--- a/exec.c
+++ b/exec.c
@@ -1796,6 +1796,16 @@ int qemu_get_ram_fd(ram_addr_t addr)
 return fd;
 }
 
+void qemu_set_ram_fd(ram_addr_t addr, int fd)
+{
+RAMBlock *block;
+
+rcu_read_lock();
+block = qemu_get_ram_block(addr);
+block->fd = fd;
+rcu_read_unlock();
+}
+
 void *qemu_get_ram_block_host_ptr(ram_addr_t addr)
 {
 RAMBlock *block;
diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
index f73f0c2..df585de 100644
--- a/hw/misc/ivshmem.c
+++ b/hw/misc/ivshmem.c
@@ -29,6 +29,7 @@
 #include "sysemu/char.h"
 #include "sysemu/hostmem.h"
 #include "qapi/visitor.h"
+#include "exec/ram_addr.h"
 
 #include "hw/misc/ivshmem.h"
 
@@ -422,6 +423,7 @@ static int create_shared_memory_BAR(IVShmemState *s, int 
fd, uint8_t attr,
 
 memory_region_init_ram_ptr(>ivshmem, OBJECT(s), "ivshmem.bar2",
s->ivshmem_size, ptr);
+qemu_set_ram_fd(s->ivshmem.ram_addr, fd);
 vmstate_register_ram(>ivshmem, DEVICE(s));
 memory_region_add_subregion(>bar, 0, >ivshmem);
 
@@ -682,6 +684,7 @@ static void ivshmem_read(void *opaque, const uint8_t *buf, 
int size)
 }
 memory_region_init_ram_ptr(>ivshmem, OBJECT(s),
"ivshmem.bar2", s->ivshmem_size, map_ptr);
+qemu_set_ram_fd(s->ivshmem.ram_addr, incoming_fd);
 vmstate_register_ram(>ivshmem, DEVICE(s));
 
 IVSHMEM_DPRINTF("guest h/w addr = %p, size = %" PRIu64 "\n",
@@ -689,7 +692,6 @@ static void ivshmem_read(void *opaque, const uint8_t *buf, 
int size)
 
 memory_region_add_subregion(>bar, 0, >ivshmem);
 
-close(incoming_fd);
 return;
 }
 
@@ -991,7 +993,6 @@ static void pci_ivshmem_realize(PCIDevice *dev, Error 
**errp)
 }
 
 create_shared_memory_BAR(s, fd, attr, errp);
-close(fd);
 }
 }
 
@@ -1010,11 +1011,15 @@ static void pci_ivshmem_exit(PCIDevice *dev)
 if (memory_region_is_mapped(>ivshmem)) {
 if (!s->hostmem) {
 void *addr = memory_region_get_ram_ptr(>ivshmem);
+int fd;
 
 if (munmap(addr, s->ivshmem_size) == -1) {
 error_report("Failed to munmap shared memory %s",
  strerror(errno));
 }
+
+if ((fd = qemu_get_ram_fd(s->ivshmem.ram_addr)) != -1)
+close(fd);
 }
 
 vmstate_unregister_ram(>ivshmem, DEVICE(dev));
diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index 7115154..9ca659a 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -72,6 +72,7 @@ ram_addr_t qemu_ram_alloc_resizeable(ram_addr_t size, 
ram_addr_t max_size,
  void *host),
  MemoryRegion *mr, Error **errp);
 int qemu_get_ram_fd(ram_addr_t addr);
+void qemu_set_ram_fd(ram_addr_t addr, int fd);
 void *qemu_get_ram_block_host_ptr(ram_addr_t addr);
 void *qemu_get_ram_ptr(ram_addr_t addr);
 void qemu_ram_free(ram_addr_t addr);
-- 
2.1.4




[Qemu-devel] [PULL for-2.5 0/9] Trivial patches for 2015-12-04

2015-12-03 Thread Michael Tokarev
Hello.

During the freeze period, let me please add my trivial pull request too ;)

There are just 9 patches this time, which are either (small) bugfixes,
or just prettifying one or another part of code to look nicely in the
release tarball.  Here are all of them:

aniel P. Berrange (1):
  crypto: avoid two coverity false positive error reports
this is a cleanup together with a small tracing bugfix,
an easy patch.  An making coverity even more useful is
nice too.

Hervé Poussineau (1):
  scsi: remove scsi_req_free prototype
just removing a prototype of a single unused function

John Snow (1):
  util/id: fully allocate names table
a small bugfix avoiding accessing "random" memory

Markus Armbruster (1):
  typedefs: Put them back into alphabetical order
this one sorts include/qemu/typedefs.h in alphabetical order,
and removes duplicates while at it.  Actual set of typedefs
isn't changed.  We should have good-looking code conforming
to our own standards in the released tarball :)

Paolo Bonzini (3):
  bt: avoid unintended sign extension
a simple bt bugfix

  gt64xxx: fix decoding of ISD register
this is a small mips platform bugfix

  bt: check struct sizes
this one is rather large, but it tries to fix real mess in BT
device emulation which we have now

Peter Maydell (1):
  configure: Diagnose broken linkers directly
A simple patch trying to verify whenever linker works too, not
only compiler, at configure time before doing more complex
tests.

Rodrigo Rebello (1):
  configure: use appropriate code fragment for -fstack-protector checks
this is an interesting patch in context of the freeze time.
In short, current test for -fstack-protector gives false positives
(claiming the feature is available) in some configuration, because
it only verifies whenever compiler accepts this option but not
whenever it can compile and link a code which actually uses stack.

Please consider applying.

Thanks,

/mjt


The following changes since commit 4c65fed8bdf96780735dbdb92a8bd0d6b6526cc3:

  ui: vnc: avoid floating point exception (2015-12-03 13:34:50 +)

are available in the git repository at:

  git://git.corpit.ru/qemu.git tags/pull-trivial-patches-2015-12-04

for you to fetch changes up to 98475746b357f6c048caf9e001998d8a0618b2e4:

  bt: check struct sizes (2015-12-04 09:39:55 +0300)


trivial patches for 2015-12-04


Daniel P. Berrange (1):
  crypto: avoid two coverity false positive error reports

Hervé Poussineau (1):
  scsi: remove scsi_req_free prototype

John Snow (1):
  util/id: fully allocate names table

Markus Armbruster (1):
  typedefs: Put them back into alphabetical order

Paolo Bonzini (3):
  bt: avoid unintended sign extension
  gt64xxx: fix decoding of ISD register
  bt: check struct sizes

Peter Maydell (1):
  configure: Diagnose broken linkers directly

Rodrigo Rebello (1):
  configure: use appropriate code fragment for -fstack-protector checks

 configure   | 13 +
 crypto/tlscreds.c   |  4 ++--
 crypto/tlscredsx509.c   |  1 +
 hw/bt/sdp.c |  2 +-
 hw/mips/gt64xxx_pci.c   |  3 ++-
 include/hw/bt.h | 21 -
 include/hw/scsi/scsi.h  |  1 -
 include/qemu/typedefs.h | 13 ++---
 util/id.c   |  4 ++--
 9 files changed, 31 insertions(+), 31 deletions(-)



[Qemu-devel] [PULL 6/9] gt64xxx: fix decoding of ISD register

2015-12-03 Thread Michael Tokarev
From: Paolo Bonzini 

The GT64xxx's internal registers can be placed above the first 4 GiB
in the address space, but not above the first 64 GiB.  Correctly cast
the register to a 64-bit integer, and mask away bits above bit 35.

Datasheet at 
http://pdf.datasheetarchive.com/datasheetsmain/Datasheets-33/DSA-655889.pdf
(bug reported by Coverity).

Signed-off-by: Paolo Bonzini 
Signed-off-by: Michael Tokarev 
---
 hw/mips/gt64xxx_pci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/mips/gt64xxx_pci.c b/hw/mips/gt64xxx_pci.c
index 10fcca3..f76a9fd 100644
--- a/hw/mips/gt64xxx_pci.c
+++ b/hw/mips/gt64xxx_pci.c
@@ -275,7 +275,8 @@ static void check_reserved_space (hwaddr *start,
 
 static void gt64120_isd_mapping(GT64120State *s)
 {
-hwaddr start = s->regs[GT_ISD] << 21;
+/* Bits 14:0 of ISD map to bits 35:21 of the start address.  */
+hwaddr start = ((hwaddr)s->regs[GT_ISD] << 21) & 0xFFFE0ull;
 hwaddr length = 0x1000;
 
 if (s->ISD_length) {
-- 
2.1.4




[Qemu-devel] [PULL 9/9] bt: check struct sizes

2015-12-03 Thread Michael Tokarev
From: Paolo Bonzini 

See http://permalink.gmane.org/gmane.linux.bluez.kernel/36505.  For historical
reasons these do not use sizeof, and Coverity caught a mistake in
EVT_ENCRYPT_CHANGE_SIZE.

In addition:

- remove status from create_conn_cancel_cp; the "status" field is only
in rp structs.  Note that this means that the OCF_CREATE_CONN_CANCEL
could never have worked (it would have failed the LENGTH_CHECK), but
I am keeping it anyway.

- OCF_READ_LINK_QUALITY similarly could never have worked, but I am
fixing read_link_quality_cp anyway.

- fix inquiry_info which is shorter by one: the kernel has a struct that
is 14 byte long, but not counting the initial num_responses byte which
the kernel parses separately;

- remove extended_inquiry_info altogether, since it's not used and unlike
the other inquiry structs does not have the initial num_responses byte.

Signed-off-by: Paolo Bonzini 
Signed-off-by: Michael Tokarev 
---
 include/hw/bt.h | 21 -
 1 file changed, 4 insertions(+), 17 deletions(-)

diff --git a/include/hw/bt.h b/include/hw/bt.h
index cb2a7e6..c7c7909 100644
--- a/include/hw/bt.h
+++ b/include/hw/bt.h
@@ -504,7 +504,6 @@ typedef struct {
 
 #define OCF_CREATE_CONN_CANCEL 0x0008
 typedef struct {
-uint8_tstatus;
 bdaddr_t   bdaddr;
 } QEMU_PACKED create_conn_cancel_cp;
 #define CREATE_CONN_CANCEL_CP_SIZE 6
@@ -1266,13 +1265,13 @@ typedef struct {
 uint8_tstatus;
 uint16_t   handle;
 } QEMU_PACKED reset_failed_contact_counter_rp;
-#define RESET_FAILED_CONTACT_COUNTER_RP_SIZE 4
+#define RESET_FAILED_CONTACT_COUNTER_RP_SIZE 3
 
 #define OCF_READ_LINK_QUALITY  0x0003
 typedef struct {
 uint16_t   handle;
 } QEMU_PACKED read_link_quality_cp;
-#define READ_LINK_QUALITY_CP_SIZE 4
+#define READ_LINK_QUALITY_CP_SIZE 2
 
 typedef struct {
 uint8_tstatus;
@@ -1332,7 +1331,7 @@ typedef struct {
 uint8_tdev_class[3];
 uint16_t   clock_offset;
 } QEMU_PACKED inquiry_info;
-#define INQUIRY_INFO_SIZE 14
+#define INQUIRY_INFO_SIZE 15
 
 #define EVT_CONN_COMPLETE  0x03
 typedef struct {
@@ -1381,7 +1380,7 @@ typedef struct {
 uint16_t   handle;
 uint8_tencrypt;
 } QEMU_PACKED evt_encrypt_change;
-#define EVT_ENCRYPT_CHANGE_SIZE 5
+#define EVT_ENCRYPT_CHANGE_SIZE 4
 
 #define EVT_CHANGE_CONN_LINK_KEY_COMPLETE  0x09
 typedef struct {
@@ -1629,18 +1628,6 @@ typedef struct {
 } QEMU_PACKED evt_sniff_subrate;
 #define EVT_SNIFF_SUBRATE_SIZE 11
 
-#define EVT_EXTENDED_INQUIRY_RESULT0x2F
-typedef struct {
-bdaddr_t   bdaddr;
-uint8_tpscan_rep_mode;
-uint8_tpscan_period_mode;
-uint8_tdev_class[3];
-uint16_t   clock_offset;
-int8_t rssi;
-uint8_tdata[240];
-} QEMU_PACKED extended_inquiry_info;
-#define EXTENDED_INQUIRY_INFO_SIZE 254
-
 #define EVT_TESTING0xFE
 
 #define EVT_VENDOR 0xFF
-- 
2.1.4




[Qemu-devel] [PULL 7/9] scsi: remove scsi_req_free prototype

2015-12-03 Thread Michael Tokarev
From: Hervé Poussineau 

Function has been deleted in ad2d30f79d3b0812f02c741be2189796b788d6d7.

Signed-off-by: Hervé Poussineau 
Reviewed-by: Fam Zheng 
Signed-off-by: Michael Tokarev 
---
 include/hw/scsi/scsi.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/hw/scsi/scsi.h b/include/hw/scsi/scsi.h
index cdaf0f8..1915a73 100644
--- a/include/hw/scsi/scsi.h
+++ b/include/hw/scsi/scsi.h
@@ -250,7 +250,6 @@ SCSIRequest *scsi_req_alloc(const SCSIReqOps *reqops, 
SCSIDevice *d,
 SCSIRequest *scsi_req_new(SCSIDevice *d, uint32_t tag, uint32_t lun,
   uint8_t *buf, void *hba_private);
 int32_t scsi_req_enqueue(SCSIRequest *req);
-void scsi_req_free(SCSIRequest *req);
 SCSIRequest *scsi_req_ref(SCSIRequest *req);
 void scsi_req_unref(SCSIRequest *req);
 
-- 
2.1.4




[Qemu-devel] [PULL 5/9] configure: use appropriate code fragment for -fstack-protector checks

2015-12-03 Thread Michael Tokarev
From: Rodrigo Rebello 

The check for stack-protector support consisted in compiling and linking
the test program below (output by function write_c_skeleton()) with the
compiler flag -fstack-protector-strong first and then with
-fstack-protector-all if the first one failed to work:

  int main(void) { return 0; }

This caused false positives when using certain toolchains in which the
compiler accepted -fstack-protector-strong but no support was provided
by the C library, since for this stack-protector variant the compiler
emits canary code only for functions that meet specific conditions
(local arrays, memory references to local variables, etc.) and the code
fragment under test included none of them (hence no stack protection
code generated, no link failure).

This fix changes the test program used for -fstack-protector checks to
include a function that meets conditions which cause the compiler to
generate canary code in all variants.

Signed-off-by: Rodrigo Rebello 
Reviewed-by: Markus Armbruster 
Signed-off-by: Michael Tokarev 
---
 configure | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/configure b/configure
index 2e8a672..b9552fd 100755
--- a/configure
+++ b/configure
@@ -1491,6 +1491,16 @@ for flag in $gcc_flags; do
 done
 
 if test "$stack_protector" != "no"; then
+  cat > $TMPC << EOF
+int main(int argc, char *argv[])
+{
+char arr[64], *p = arr, *c = argv[0];
+while (*c) {
+*p++ = *c++;
+}
+return 0;
+}
+EOF
   gcc_flags="-fstack-protector-strong -fstack-protector-all"
   sp_on=0
   for flag in $gcc_flags; do
-- 
2.1.4




[Qemu-devel] [PULL 1/9] util/id: fully allocate names table

2015-12-03 Thread Michael Tokarev
From: John Snow 

Trivial: this array should be allocated to have ID_MAX entries always.
Otherwise if someone were to forget to expand this table, the assertion
in the id generator won't actually trigger; it will read junk data.

Signed-off-by: John Snow 
Reviewed-by: Eric Blake 
Reviewed-by: Jeff Cody 
Signed-off-by: Michael Tokarev 
---
 util/id.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/util/id.c b/util/id.c
index bcc64d8..7883fbe 100644
--- a/util/id.c
+++ b/util/id.c
@@ -29,7 +29,7 @@ bool id_wellformed(const char *id)
 
 #define ID_SPECIAL_CHAR '#'
 
-static const char *const id_subsys_str[] = {
+static const char *const id_subsys_str[ID_MAX] = {
 [ID_QDEV]  = "qdev",
 [ID_BLOCK] = "block",
 };
@@ -53,7 +53,7 @@ char *id_generate(IdSubSystems id)
 static uint64_t id_counters[ID_MAX];
 uint32_t rnd;
 
-assert(id < ID_MAX);
+assert(id < ARRAY_SIZE(id_subsys_str));
 assert(id_subsys_str[id]);
 
 rnd = g_random_int_range(0, 100);
-- 
2.1.4




Re: [Qemu-devel] [PATCH] net/vmxnet3.c: fix a build error when enabling debug output

2015-12-03 Thread Jason Wang


On 12/03/2015 03:24 PM, Dmitry Fleytman wrote:
> Acked-by: Dmitry Fleytman >

Applied in my -net for 2.5.

Thanks

>
>> On 3 Dec 2015, at 07:08 AM, Miao Yan > > wrote:
>>
>> Macro MAC_FMT and MAC_ARG are not defined, but used in
>> vmxnet3_net_init().
>> This will cause build error when debug level is raised in
>> vmxnet3_debug.h (enable all VMXNET3_DEBUG_xxx).
>>
>> Use VMXNET_MF and VXMNET_MA instead.
>>
>> Signed-off-by: Miao Yan > >
>> ---
>> hw/net/vmxnet3.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/hw/net/vmxnet3.c b/hw/net/vmxnet3.c
>> index 5e3a233..ea3d9b7 100644
>> --- a/hw/net/vmxnet3.c
>> +++ b/hw/net/vmxnet3.c
>> @@ -2044,7 +2044,7 @@ static void vmxnet3_net_init(VMXNET3State *s)
>>
>> s->link_status_and_speed = VMXNET3_LINK_SPEED |
>> VMXNET3_LINK_STATUS_UP;
>>
>> -VMW_CFPRN("Permanent MAC: " MAC_FMT, MAC_ARG(s->perm_mac.a));
>> +VMW_CFPRN("Permanent MAC: " VMXNET_MF, VMXNET_MA(s->perm_mac.a));
>>
>> s->nic = qemu_new_nic(_vmxnet3_info, >conf,
>>   object_get_typename(OBJECT(s)),
>> -- 
>> 2.1.4
>>
>




[Qemu-devel] [PATCH 1/8] bcm2835_sbm: add BCM2835 mailboxes

2015-12-03 Thread Andrew Baumann
This adds the system mailboxes which are used to communicate with a
number of GPU peripherals on Pi/Pi2.

Signed-off-by: Andrew Baumann 
---
 default-configs/arm-softmmu.mak  |   1 +
 hw/misc/Makefile.objs|   1 +
 hw/misc/bcm2835_sbm.c| 280 
 include/hw/arm/bcm2835_arm_control.h | 481 +++
 include/hw/arm/bcm2835_mbox.h|  19 ++
 include/hw/misc/bcm2835_sbm.h|  37 +++
 6 files changed, 819 insertions(+)
 create mode 100644 hw/misc/bcm2835_sbm.c
 create mode 100644 include/hw/arm/bcm2835_arm_control.h
 create mode 100644 include/hw/arm/bcm2835_mbox.h
 create mode 100644 include/hw/misc/bcm2835_sbm.h

diff --git a/default-configs/arm-softmmu.mak b/default-configs/arm-softmmu.mak
index d9b90a5..a9f82a1 100644
--- a/default-configs/arm-softmmu.mak
+++ b/default-configs/arm-softmmu.mak
@@ -79,6 +79,7 @@ CONFIG_TUSB6010=y
 CONFIG_IMX=y
 CONFIG_MAINSTONE=y
 CONFIG_NSERIES=y
+CONFIG_RASPI=y
 CONFIG_REALVIEW=y
 CONFIG_ZAURUS=y
 CONFIG_ZYNQ=y
diff --git a/hw/misc/Makefile.objs b/hw/misc/Makefile.objs
index aeb6b7d..b9379f2 100644
--- a/hw/misc/Makefile.objs
+++ b/hw/misc/Makefile.objs
@@ -34,6 +34,7 @@ obj-$(CONFIG_OMAP) += omap_gpmc.o
 obj-$(CONFIG_OMAP) += omap_l4.o
 obj-$(CONFIG_OMAP) += omap_sdrc.o
 obj-$(CONFIG_OMAP) += omap_tap.o
+obj-$(CONFIG_RASPI) += bcm2835_sbm.o
 obj-$(CONFIG_SLAVIO) += slavio_misc.o
 obj-$(CONFIG_ZYNQ) += zynq_slcr.o
 obj-$(CONFIG_ZYNQ) += zynq-xadc.o
diff --git a/hw/misc/bcm2835_sbm.c b/hw/misc/bcm2835_sbm.c
new file mode 100644
index 000..a5c9324
--- /dev/null
+++ b/hw/misc/bcm2835_sbm.c
@@ -0,0 +1,280 @@
+/*
+ * Raspberry Pi emulation (c) 2012 Gregory Estrade
+ * This code is licensed under the GNU GPLv2 and later.
+ */
+
+#include "hw/misc/bcm2835_sbm.h"
+#include "hw/arm/bcm2835_arm_control.h"
+
+static void mbox_update_status(BCM2835Mbox *mb)
+{
+if (mb->count == 0) {
+mb->status |= ARM_MS_EMPTY;
+} else {
+mb->status &= ~ARM_MS_EMPTY;
+}
+if (mb->count == MBOX_SIZE) {
+mb->status |= ARM_MS_FULL;
+} else {
+mb->status &= ~ARM_MS_FULL;
+}
+}
+
+static void mbox_init(BCM2835Mbox *mb)
+{
+int n;
+mb->count = 0;
+mb->config = 0;
+for (n = 0; n < MBOX_SIZE; n++) {
+mb->reg[n] = MBOX_INVALID_DATA;
+}
+mbox_update_status(mb);
+}
+
+static uint32_t mbox_pull(BCM2835Mbox *mb, int index)
+{
+int n;
+uint32_t val;
+
+assert(mb->count > 0);
+assert(index < mb->count);
+
+val = mb->reg[index];
+for (n = index + 1; n < mb->count; n++) {
+mb->reg[n - 1] = mb->reg[n];
+}
+mb->count--;
+mb->reg[mb->count] = MBOX_INVALID_DATA;
+
+mbox_update_status(mb);
+
+return val;
+}
+
+static void mbox_push(BCM2835Mbox *mb, uint32_t val)
+{
+assert(mb->count < MBOX_SIZE);
+mb->reg[mb->count++] = val;
+mbox_update_status(mb);
+}
+
+static void bcm2835_sbm_update(BCM2835SbmState *s)
+{
+int set;
+int done, n;
+uint32_t value;
+
+/* Avoid unwanted recursive calls */
+s->mbox_irq_disabled = 1;
+
+/* Get pending responses and put them in the vc->arm mbox */
+done = 0;
+while (!done) {
+done = 1;
+if (s->mbox[0].status & ARM_MS_FULL) {
+/* vc->arm mbox full, exit */
+} else {
+for (n = 0; n < MBOX_CHAN_COUNT; n++) {
+if (s->available[n]) {
+value = ldl_phys(>mbox_as, n<<4);
+if (value != MBOX_INVALID_DATA) {
+mbox_push(>mbox[0], value);
+} else {
+/* Hmmm... */
+}
+done = 0;
+break;
+}
+}
+}
+}
+
+/* Try to push pending requests from the arm->vc mbox */
+/* TODO (?) */
+
+/* Re-enable calls from the IRQ routine */
+s->mbox_irq_disabled = 0;
+
+/* Update ARM IRQ status */
+set = 0;
+if (s->mbox[0].status & ARM_MS_EMPTY) {
+s->mbox[0].config &= ~ARM_MC_IHAVEDATAIRQPEND;
+} else {
+s->mbox[0].config |= ARM_MC_IHAVEDATAIRQPEND;
+if (s->mbox[0].config & ARM_MC_IHAVEDATAIRQEN) {
+set = 1;
+}
+}
+qemu_set_irq(s->arm_irq, set);
+}
+
+static void bcm2835_sbm_set_irq(void *opaque, int irq, int level)
+{
+BCM2835SbmState *s = (BCM2835SbmState *)opaque;
+s->available[irq] = level;
+if (!s->mbox_irq_disabled) {
+bcm2835_sbm_update(s);
+}
+}
+
+static uint64_t bcm2835_sbm_read(void *opaque, hwaddr offset,
+   unsigned size)
+{
+BCM2835SbmState *s = (BCM2835SbmState *)opaque;
+uint32_t res = 0;
+
+offset &= 0xff;
+
+switch (offset) {
+case 0x80:  /* MAIL0_READ */
+case 0x84:
+case 0x88:
+case 0x8c:
+if (s->mbox[0].status & ARM_MS_EMPTY) {
+res = MBOX_INVALID_DATA;
+ 

[Qemu-devel] [PATCH 8/8] raspi: add raspberry pi 2 machine

2015-12-03 Thread Andrew Baumann
bcm2835/Pi1 requires more peripherals, and will be added in a later
patch series.

Signed-off-by: Andrew Baumann 
---
 hw/arm/Makefile.objs |   2 +-
 hw/arm/raspi.c   | 179 +++
 2 files changed, 180 insertions(+), 1 deletion(-)
 create mode 100644 hw/arm/raspi.c

diff --git a/hw/arm/Makefile.objs b/hw/arm/Makefile.objs
index f55f8d2..a711e4d 100644
--- a/hw/arm/Makefile.objs
+++ b/hw/arm/Makefile.objs
@@ -11,7 +11,7 @@ obj-y += armv7m.o exynos4210.o pxa2xx.o pxa2xx_gpio.o 
pxa2xx_pic.o
 obj-$(CONFIG_DIGIC) += digic.o
 obj-y += omap1.o omap2.o strongarm.o
 obj-$(CONFIG_ALLWINNER_A10) += allwinner-a10.o cubieboard.o
-obj-$(CONFIG_RASPI) += bcm2835_peripherals.o bcm2836.o
+obj-$(CONFIG_RASPI) += bcm2835_peripherals.o bcm2836.o raspi.o
 obj-$(CONFIG_STM32F205_SOC) += stm32f205_soc.o
 obj-$(CONFIG_XLNX_ZYNQMP) += xlnx-zynqmp.o xlnx-ep108.o
 obj-$(CONFIG_FSL_IMX25) += fsl-imx25.o imx25_pdk.o
diff --git a/hw/arm/raspi.c b/hw/arm/raspi.c
new file mode 100644
index 000..cc80c56
--- /dev/null
+++ b/hw/arm/raspi.c
@@ -0,0 +1,179 @@
+/*
+ * Raspberry Pi emulation (c) 2012 Gregory Estrade
+ * Upstreaming code cleanup [including bcm2835_*] (c) 2013 Jan Petrous
+ *
+ * Rasperry Pi 2 emulation Copyright (c) 2015, Microsoft
+ * Written by Andrew Baumann
+ *
+ * This code is licensed under the GNU GPLv2 and later.
+ */
+
+/* Based on versatilepb.c, copyright terms below. */
+
+/*
+ * ARM Versatile Platform/Application Baseboard System emulation.
+ *
+ * Copyright (c) 2005-2007 CodeSourcery.
+ * Written by Paul Brook
+ *
+ * This code is licensed under the GPL.
+ */
+
+#include "hw/arm/bcm2836.h"
+#include "qemu/error-report.h"
+#include "hw/boards.h"
+#include "hw/loader.h"
+#include "hw/arm/arm.h"
+#include "sysemu/sysemu.h"
+#include "hw/arm/raspi_platform.h"
+
+#define SMPBOOT_ADDR0x300 /* this should leave enough space for ATAGS */
+#define MVBAR_ADDR  0x400 /* secure vectors */
+#define BOARDSETUP_ADDR (MVBAR_ADDR + 0x20) /* board setup code */
+#define FIRMWARE_ADDR   0x8000 /* Pi loads kernel.img here by default */
+
+/* Table of Linux board IDs for different Pi versions */
+static const int raspi_boardid[] = {[1] = 0xc42, [2] = 0xc43};
+
+typedef struct RaspiMachineState {
+union {
+Object obj;
+BCM2836State pi2;
+} soc;
+MemoryRegion ram;
+} RaspiMachineState;
+
+static void write_smpboot(ARMCPU *cpu, const struct arm_boot_info *info)
+{
+static const uint32_t smpboot[] = {
+0xE1A0E00F, /*mov lr, pc */
+0xE3A0FE42, /*mov pc, #0x420   ;call BOARDSETUP_ADDR */
+0xEE100FB0, /*mrc p15, 0, r0, c0, c0, 5;get core ID */
+0xE7E10050, /*ubfxr0, r0, #0, #2   ;extract LSB */
+0xE59F5014, /*ldr r5, =0x40CC  ;load mbox base */
+0xE320F001, /* 1: yield */
+0xE7953200, /*ldr r3, [r5, r0, lsl #4] ;read mbox for our 
core*/
+0xE353, /*cmp r3, #0   ;spin while zero */
+0x0AFB, /*beq 1b */
+0xE7853200, /*str r3, [r5, r0, lsl #4] ;clear mbox */
+0xE12FFF13, /*bx  r3   ;jump to target */
+0x40CC, /* (constant: mailbox 3 read/clear base) */
+};
+
+assert(SMPBOOT_ADDR + sizeof(smpboot) <= MVBAR_ADDR);
+rom_add_blob_fixed("raspi_smpboot", smpboot, sizeof(smpboot),
+   info->smp_loader_start);
+}
+
+static void write_board_setup(ARMCPU *cpu, const struct arm_boot_info *info)
+{
+static const uint32_t board_setup[] = {
+/* MVBAR_ADDR: secure monitor vectors */
+0xEAFE, /* (spin) */
+0xEAFE, /* (spin) */
+0xE1B0F00E, /* movs pc, lr ;SMC exception return */
+0xEAFE, /* (spin) */
+0xEAFE, /* (spin) */
+0xEAFE, /* (spin) */
+0xEAFE, /* (spin) */
+0xEAFE, /* (spin) */
+/* BOARDSETUP_ADDR */
+0xE3A00B01, /* mov r0, #0x400 ;MVBAR_ADDR */
+0xEE0C0F30, /* mcr p15, 0, r0, c12, c0, 1 ;set MVBAR */
+0xE3000131, /* movwr0, #0x131 ;enable HVC, AW, FW, NS 
*/
+0xEE010F11, /* mcr p15, 0, r0, c1, c1, 0  ;write SCR */
+0xE1A0100E, /* mov r1, lr ;save LR across SMC */
+0xE1600070, /* smc #0 ;monitor call */
+0xE1A0F001, /* mov pc, r1 ;return */
+};
+
+rom_add_blob_fixed("raspi_boardsetup", board_setup, sizeof(board_setup),
+   MVBAR_ADDR);
+}
+
+static void reset_secondary(ARMCPU *cpu, const struct arm_boot_info *info)
+{
+CPUState *cs = CPU(cpu);
+cpu_set_pc(cs, info->smp_loader_start);
+}
+
+static void setup_boot(MachineState *machine, int version, size_t ram_size)
+{
+static struct arm_boot_info binfo;
+int r;
+
+binfo.board_id = raspi_boardid[version];

Re: [Qemu-devel] scripts/gdb: Fix a python exception in mtree.py

2015-12-03 Thread Stefan Hajnoczi
On Wed, Dec 02, 2015 at 03:56:24PM +0800, Yang Wei wrote:
> The following exception is threw:
> Python Exception  name 'long' is not defined:
> Error occurred in Python command: name 'long' is not defined
> 
> In python3, long is rename to int
> 
> Signed-off-by: Yang Wei 
> ---
>  scripts/qemugdb/mtree.py | 17 -
>  1 file changed, 12 insertions(+), 5 deletions(-)

Even in Python 2.4+, int()/long() have been unified to an extent:
https://www.python.org/dev/peps/pep-0237/
https://docs.python.org/2/whatsnew/2.4.html

If the value is too large for the int() constructor, it returns a
long().

Can this patch be simplified to s/\/long/g ?

That way no Python version checks are necessary.

> diff --git a/scripts/qemugdb/mtree.py b/scripts/qemugdb/mtree.py
> index 06011c3..460d4b6 100644
> --- a/scripts/qemugdb/mtree.py
> +++ b/scripts/qemugdb/mtree.py
> @@ -16,12 +16,19 @@
>  # 'qemu mtree' -- display the memory hierarchy
>  
>  import gdb
> +import sys
>  
>  def isnull(ptr):
>  return ptr == gdb.Value(0).cast(ptr.type)
>  
> +# PEP 0237: long renamed to int. That is, there is only one built-integral
> +# integral type, named int; but it behaves mostly like the old long type.
> +# https://docs.python.org/3.3/whatsnew/3.0.html#integers
> +def intptr(p):
> +return long(p) if sys.version_info.major == 2 else int(p)
> +
>  def int128(p):
> -return long(p['lo']) + (long(p['hi']) << 64)
> +return intptr(p['lo']) + (intptr(p['hi']) << 64)
>  
>  class MtreeCommand(gdb.Command):
>  '''Display the memory tree hierarchy'''
> @@ -40,11 +47,11 @@ class MtreeCommand(gdb.Command):
>  def process_queue(self):
>  while self.queue:
>  ptr = self.queue.pop(0)
> -if long(ptr) in self.seen:
> +if intptr(ptr) in self.seen:
>  continue
>  self.print_item(ptr)
>  def print_item(self, ptr, offset = gdb.Value(0), level = 0):
> -self.seen.add(long(ptr))
> +self.seen.add(intptr(ptr))
>  addr = ptr['addr']
>  addr += offset
>  size = int128(ptr['size'])
> @@ -58,8 +65,8 @@ class MtreeCommand(gdb.Command):
>  klass = ' (RAM)'
>  gdb.write('%s%016x-%016x %s%s (@ %s)\n'
>% ('  ' * level,
> - long(addr),
> - long(addr + (size - 1)),
> + intptr(addr),
> + intptr(addr + (size - 1)),
>   ptr['name'].string(),
>   klass,
>   ptr,
> -- 
> 1.9.1
> 
> 


signature.asc
Description: PGP signature


Re: [Qemu-devel] [PATCH 1/3] hw/sd/pxa2xx_mmci: convert to SysBusDevice object

2015-12-03 Thread Markus Armbruster
Peter Maydell  writes:

> On 7 September 2015 at 17:57, Markus Armbruster  wrote:
>> Peter Maydell  writes:
>>
>>> On 7 September 2015 at 17:40, Markus Armbruster  wrote:
 Peter Maydell  writes:

> Convert the pxa2xx_mmci device to be a sysbus device.
>>>
> +static Property pxa2xx_mmci_properties[] = {
> +/* Note: pointer property 'drive' may remain NULL, thus no need
> + * for dc->cannot_instantiate_with_device_add_yet = true;
> + * Unfortunately this can't be a DEFINE_PROP_DRIVE, because
> + * setting a 'drive' property results in a call to blk_attach_dev()
> + * attaching the BlockBackend to this device; that then means that
> + * the call in sd_init() to blk_attach_dev_nofail() which tries to
> + * attach the BlockBackend to the SD card object aborts.
> + */
> +DEFINE_PROP_PTR("drive", PXA2xxMMCIState, blk),
> +DEFINE_PROP_END_OF_LIST(),
> +};

 As far as I can tell, this problem is an artifact of our interface to
 the common sd-card code, namely sd_init().  sd_init() was made for the
 pre-qdev world: it creates and completely initializes the common
 SDState.

 In qdev, we do this in three separate steps: create, set properties,
 realize.  Split up sd_init(), and the problem should go away.
>>>
>>> Yes, but I don't really want to gate QOMification of mmc
>>> controller devices on the more complicated problem of
>>> QOMifying sd.c itself, especially since we already have several
>>> QOMified mmc controllers...
>>
>> Is serial.c QOMified?  I don't think so, it's merely structured in a
>> QOM-friendly way: typedef SerialState, realize helper
>> serial_realize_core(), unrealize helper serial_exit_core().  If
>> SerialState had more properties, we'd also need a macro to define them.
>
> It looks like since we had this conversation the problem has been
> dealt with in commit 5ec911c30ff433 by simply turning the sd_init() call
> to blk_attach_dev_nofail() into a call to blk_attach_dev() which ignores
> its error return. So I should be able to do this with a DEFINE_PROP_DRIVE
> now I think...

Ignoring the error is intentional according to the comment, but why is
it appropriate?



Re: [Qemu-devel] [PATCH COLO-Frame v11 15/39] COLO: Load PVM's dirty pages into SVM's RAM cache temporarily

2015-12-03 Thread Hailiang Zhang

On 2015/12/2 3:02, Dr. David Alan Gilbert wrote:

* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:

We should not load PVM's state directly into SVM, because there maybe some
errors happen when SVM is receving data, which will break SVM.

We need to ensure receving all data before load the state into SVM. We use
an extra memory to cache these data (PVM's ram). The ram cache in secondary side
is initially the same as SVM/PVM's memory. And in the process of checkpoint,
we cache the dirty pages of PVM into this ram cache firstly, so this ram cache
always the same as PVM's memory at every checkpoint, then we flush this cached 
ram
to SVM after we receive all PVM's state.

Signed-off-by: zhanghailiang 
Signed-off-by: Li Zhijian 
Signed-off-by: Gonglei 
---
v11:
- Rename 'host_cache' to 'colo_cache' (Dave's suggestion)
v10:
- Split the process of dirty pages recording into a new patch
---
  include/exec/ram_addr.h   |  1 +
  include/migration/migration.h |  4 +++
  migration/colo.c  | 10 +++
  migration/ram.c   | 69 ++-
  4 files changed, 83 insertions(+), 1 deletion(-)

diff --git a/include/exec/ram_addr.h b/include/exec/ram_addr.h
index 7115154..bb44f66 100644
--- a/include/exec/ram_addr.h
+++ b/include/exec/ram_addr.h
@@ -26,6 +26,7 @@ struct RAMBlock {
  struct rcu_head rcu;
  struct MemoryRegion *mr;
  uint8_t *host;
+uint8_t *colo_cache; /* For colo, VM's ram cache */
  ram_addr_t offset;
  ram_addr_t used_length;
  ram_addr_t max_length;
diff --git a/include/migration/migration.h b/include/migration/migration.h
index ba5bcec..e41372d 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -332,4 +332,8 @@ int ram_save_queue_pages(MigrationState *ms, const char 
*rbname,
  PostcopyState postcopy_state_get(void);
  /* Set the state and return the old state */
  PostcopyState postcopy_state_set(PostcopyState new_state);
+
+/* ram cache */
+int colo_init_ram_cache(void);
+void colo_release_ram_cache(void);
  #endif
diff --git a/migration/colo.c b/migration/colo.c
index 012d8e5..6e933fa 100644
--- a/migration/colo.c
+++ b/migration/colo.c
@@ -304,6 +304,12 @@ void *colo_process_incoming_thread(void *opaque)
  qemu_set_block(qemu_get_fd(mis->from_src_file));


+ret = colo_init_ram_cache();
+if (ret < 0) {
+error_report("Failed to initialize ram cache");
+goto out;
+}
+
  ret = colo_ctl_put(mis->to_src_file, COLO_COMMAND_CHECKPOINT_READY, 0);
  if (ret < 0) {
  goto out;
@@ -353,6 +359,10 @@ out:
   strerror(-ret));
  }

+qemu_mutex_lock_iothread();
+colo_release_ram_cache();
+qemu_mutex_unlock_iothread();
+
  if (mis->to_src_file) {
  qemu_fclose(mis->to_src_file);
  }
diff --git a/migration/ram.c b/migration/ram.c
index a161620..9d946a1 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -223,6 +223,7 @@ static RAMBlock *last_sent_block;
  static ram_addr_t last_offset;
  static QemuMutex migration_bitmap_mutex;
  static uint64_t migration_dirty_pages;
+static bool ram_cache_enable;
  static uint32_t last_version;
  static bool ram_bulk_stage;

@@ -2175,6 +2176,16 @@ static inline void *host_from_ram_block_offset(RAMBlock 
*block,
  return block->host + offset;
  }

+static inline void *colo_cache_from_block_offset(RAMBlock *block,
+ ram_addr_t offset)
+{
+if (!block) {
+return NULL;
+}
+
+return block->colo_cache + offset;
+}
+
  /*
   * If a page (or a whole RDMA chunk) has been
   * determined to be zero, then zap it.
@@ -2454,7 +2465,12 @@ static int ram_load(QEMUFile *f, void *opaque, int 
version_id)
   RAM_SAVE_FLAG_COMPRESS_PAGE | RAM_SAVE_FLAG_XBZRLE)) {
  RAMBlock *block = ram_block_from_stream(f, addr, flags);

-host = host_from_ram_block_offset(block, addr);
+/* After going into COLO, we should load the Page into colo_cache 
*/
+if (ram_cache_enable) {
+host = colo_cache_from_block_offset(block, addr);
+} else {
+host = host_from_ram_block_offset(block, addr);
+}
  if (!host) {
  error_report("Illegal RAM offset " RAM_ADDR_FMT, addr);
  ret = -EINVAL;
@@ -2550,6 +2566,57 @@ static int ram_load(QEMUFile *f, void *opaque, int 
version_id)
  return ret;
  }

+/*
+ * colo cache: this is for secondary VM, we cache the whole
+ * memory of the secondary VM, it will be called after first migration.
+ */
+int colo_init_ram_cache(void)
+{
+RAMBlock *block;
+
+rcu_read_lock();
+QLIST_FOREACH_RCU(block, _list.blocks, next) {
+block->colo_cache = qemu_anon_ram_alloc(block->used_length, NULL);
+if (!block->colo_cache) {
+   

Re: [Qemu-devel] [PATCH COLO-Frame v11 34/39] net/filter-buffer: Add default filter-buffer for each netdev

2015-12-03 Thread Hailiang Zhang

On 2015/12/3 15:21, Yang Hongyang wrote:



On 2015年12月03日 14:48, Hailiang Zhang wrote:

On 2015/12/3 14:25, Wen Congyang wrote:

On 12/03/2015 11:53 AM, Hailiang Zhang wrote:

On 2015/12/3 9:17, Wen Congyang wrote:

On 11/24/2015 05:25 PM, zhanghailiang wrote:

We add each netdev a default filter-buffer, which will be used for
COLO
or Micro-checkpoint to buffer VM's packets. The name of default
filter-buffer
is 'nop'.
For the default filter-buffer, it will not buffer any packets in
default.
So it has no side effect for the netdev.


No, filter-buffer doesn't support vhost, so if you add default
filter-buffer
for each netdev, you can't use vhost.



Have you tested it ? Did the default filter-buffer break vhost ?
It's not supposed to break vhost, I will look into it. Thanks.


Yes, I have tested it. When I want to start a normal vm with vhost, I get
the following error messages:

qemu-system-x86_64: -netdev tap,id=hn0,queues=1,vhost=on: Vhost is not
supported



Hmm, that is reported by filter in nextfilter_complete(), i will
investigate it.
We hope the default buffer filter has no side effect on netdev.


I think you'd better add an option to netdev to turn on/off default
filter, that will solve the problem.



OK, i will try to fix it like that. Thanks.



Thanks,
Hailiang




Thanks
Wen Congyang



Signed-off-by: zhanghailiang 
Cc: Jason Wang 
Cc: Yang Hongyang 
---
v11:
- New patch
---
   include/net/filter.h |  3 +++
   net/filter-buffer.c  | 74

   net/net.c|  8 ++
   3 files changed, 85 insertions(+)

diff --git a/include/net/filter.h b/include/net/filter.h
index 2deda36..01a7e90 100644
--- a/include/net/filter.h
+++ b/include/net/filter.h
@@ -74,4 +74,7 @@ ssize_t
qemu_netfilter_pass_to_next(NetClientState *sender,
   int iovcnt,
   void *opaque);

+void netdev_add_default_filter_buffer(const char *netdev_id,
+  NetFilterDirection direction,
+  Error **errp);
   #endif /* QEMU_NET_FILTER_H */
diff --git a/net/filter-buffer.c b/net/filter-buffer.c
index 57be149..195af68 100644
--- a/net/filter-buffer.c
+++ b/net/filter-buffer.c
@@ -14,6 +14,12 @@
   #include "qapi/qmp/qerror.h"
   #include "qapi-visit.h"
   #include "qom/object.h"
+#include "net/net.h"
+#include "qapi/qmp/qdict.h"
+#include "qapi/qmp-output-visitor.h"
+#include "qapi/qmp-input-visitor.h"
+#include "monitor/monitor.h"
+#include "qmp-commands.h"

   #define TYPE_FILTER_BUFFER "filter-buffer"

@@ -26,6 +32,8 @@ typedef struct FilterBufferState {
   NetQueue *incoming_queue;
   uint32_t interval;
   QEMUTimer release_timer;
+bool is_default;
+bool enable_buffer;
   } FilterBufferState;

   static void filter_buffer_flush(NetFilterState *nf)
@@ -65,6 +73,10 @@ static ssize_t
filter_buffer_receive_iov(NetFilterState *nf,
   {
   FilterBufferState *s = FILTER_BUFFER(nf);

+/* Don't buffer any packets if the filter is not enabled */
+if (!s->enable_buffer) {
+return 0;
+}
   /*
* We return size when buffer a packet, the sender will take
it as
* a already sent packet, so sent_cb should not be called
later.
@@ -102,6 +114,7 @@ static void
filter_buffer_cleanup(NetFilterState *nf)
   static void filter_buffer_setup(NetFilterState *nf, Error **errp)
   {
   FilterBufferState *s = FILTER_BUFFER(nf);
+char *path = object_get_canonical_path_component(OBJECT(nf));

   /*
* We may want to accept zero interval when VM FT solutions
like MC
@@ -114,6 +127,7 @@ static void filter_buffer_setup(NetFilterState
*nf, Error **errp)
   }

   s->incoming_queue =
qemu_new_net_queue(qemu_netfilter_pass_to_next, nf);
+s->is_default = !strcmp(path, "nop");
   if (s->interval) {
   timer_init_us(>release_timer, QEMU_CLOCK_VIRTUAL,
 filter_buffer_release_timer, nf);
@@ -163,6 +177,66 @@ out:
   error_propagate(errp, local_err);
   }

+/*
+* This will be used by COLO or MC FT, for which they will need
+* to buffer the packets of VM's net devices, Here we add a default
+* buffer filter for each netdev. The name of default buffer filter is
+* 'nop'
+*/
+void netdev_add_default_filter_buffer(const char *netdev_id,
+  NetFilterDirection direction,
+  Error **errp)
+{
+QmpOutputVisitor *qov;
+QmpInputVisitor *qiv;
+Visitor *ov, *iv;
+QObject *obj = NULL;
+QDict *qdict;
+void *dummy = NULL;
+const char *id = "nop";
+char *queue = g_strdup(NetFilterDirection_lookup[direction]);
+NetClientState *nc = qemu_find_netdev(netdev_id);
+Error *err = NULL;
+
+/* FIXME: Not support multiple queues */
+if (!nc || nc->queue_index > 1) {
+

[Qemu-devel] [PATCH] mmap-alloc: tweak a comment on ppc64

2015-12-03 Thread Michael S. Tsirkin
The comment I put in mmap-alloc to document the ppc64 rules
refers to the previous revision of the patch:
we don't look at memory alignment anymore, we check
the fs from which the fd is mapped, instead.

It's also not clear what does "in this case" refer
to, rearrange text to make it clearer.

Signed-off-by: Michael S. Tsirkin 
---
 util/mmap-alloc.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/util/mmap-alloc.c b/util/mmap-alloc.c
index 54793a5..5cd7f71 100644
--- a/util/mmap-alloc.c
+++ b/util/mmap-alloc.c
@@ -50,10 +50,11 @@ void *qemu_ram_mmap(int fd, size_t size, size_t align, bool 
shared)
 #if defined(__powerpc64__) && defined(__linux__)
 /* On ppc64 mappings in the same segment (aka slice) must share the same
  * page size. Since we will be re-allocating part of this segment
- * from the supplied fd, we should make sure to use the same page size,
- * unless we are using the system page size, in which case anonymous memory
- * is OK. Use align as a hint for the page size.
- * In this case, set MAP_NORESERVE to avoid allocating backing store 
memory.
+ * from the supplied fd, we should make sure to use the same page size, to
+ * this end we mmap the supplied fd.  In this case, set MAP_NORESERVE to
+ * avoid allocating backing store memory.
+ * We do this unless we are using the system page size, in which case
+ * anonymous memory is OK.
  */
 int anonfd = fd == -1 || qemu_fd_getpagesize(fd) == getpagesize() ? -1 : 
fd;
 int flags = anonfd == -1 ? MAP_ANONYMOUS : MAP_NORESERVE;
-- 
MST



Re: [Qemu-devel] WG: [ovirt-users] Segmentation fault in libtcmalloc

2015-12-03 Thread Grundmann, Christian
Hi,

qemu-img-ev-2.3.0-29.1.el7.x86_64
libvirt-daemon-driver-qemu-1.2.8-16.el7_1.4.x86_64
qemu-kvm-ev-2.3.0-29.1.el7.x86_64
qemu-kvm-common-ev-2.3.0-29.1.el7.x86_64
ipxe-roms-qemu-20130517-7.gitc4bce43.el7.noarch
qemu-kvm-tools-ev-2.3.0-29.1.el7.x86_64


it seems pc-i440fx-rhel7.2.0 is the default for ovirt 3.6 

I tried using only virtio-scsi disk but the VM wont boot (not bootable device) 
so i used IDE for the boot disk.

Thx Christian

-Ursprüngliche Nachricht-
Von: Dr. David Alan Gilbert [mailto:dgilb...@redhat.com] 
Gesendet: Donnerstag, 03. Dezember 2015 10:04
An: Grundmann, Christian 
Cc: 'Paolo Bonzini' ; 'qemu-devel@nongnu.org' 
; stefa...@redhat.com
Betreff: Re: AW: WG: [ovirt-users] Segmentation fault in libtcmalloc

* Grundmann, Christian (christian.grundm...@fabasoft.com) wrote:
> Hi again,
> got a Segfault today without virtio :-( (one IDE Disk and one 
> virtio-scsi)
> 
> Core was generated by `/usr/libexec/qemu-kvm -name vmname -S -machine 
> pc-i440fx-rhel7.2.0,accel='.

Can you confirm the package version you were using; if you're running the 
pc-i440fx-rhel7.2.0 machine type it must be pretty new.

Dave

> Program terminated with signal 11, Segmentation fault.
> #0  0x7fb299cbd3ab in 
> tcmalloc::ThreadCache::ReleaseToCentralCache(tcmalloc::ThreadCache::Fr
> eeList*, unsigned long, int) () from /lib64/libtcmalloc.so.4
> 
> Thread 6 (Thread 0x7fb28d0c5700 (LWP 29423)):
> #0  0x7fb29cc85ac3 in pread64 () at 
> ../sysdeps/unix/syscall-template.S:81
> No locals.
> #1  0x7fb29e37c2a3 in pread (__offset=, 
> __nbytes=, __buf=0x7fb2a3e21a00, __fd=) at 
> /usr/include/bits/unistd.h:99 No locals.
> #2  handle_aiocb_rw_linear (aiocb=aiocb@entry=0x7fb2a1474340, 
> buf=buf@entry=0x7fb2a3e21a00 "QF", ) at 
> block/raw-posix.c:909
> offset = 0
> len = 
> #3  0x7fb29e37c3d1 in handle_aiocb_rw (aiocb=0x7fb2a1474340) at 
> block/raw-posix.c:992
> nbytes = 
> buf = 0x7fb2a3e21a00 "QF", 
> __PRETTY_FUNCTION__ = "handle_aiocb_rw"
> #4  0x7fb29e37d945 in aio_worker (arg=0x7fb2a1474340) at 
> block/raw-posix.c:1204
> aiocb = 0x7fb2a1474340
> ret = 0
> #5  0x7fb29e33d91b in worker_thread (opaque=0x7fb2a148d450) at 
> thread-pool.c:105
> req = 0x7fb2a1474b30
> ret = 
> pool = 0x7fb2a148d450
> #6  0x7fb29cc7edf5 in start_thread (arg=0x7fb28d0c5700) at 
> pthread_create.c:308
> __res = 
> pd = 0x7fb28d0c5700
> now = 
> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140404847302400, 
> -4522449750849005939, 0, 140404847303104, 140404847302400, 26, 
> 4492373549408278157, 4492409237274449549}, mask_was_saved = 0}}, priv = {pad 
> = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
> not_first_call = 
> pagesize_m1 = 
> sp = 
> freesize = 
> #7  0x7fb29688c1ad in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
> No locals.
> 
> Thread 5 (Thread 0x7fb104fff700 (LWP 29084)):
> #0  0x7fb296881b7d in poll () at 
> ../sysdeps/unix/syscall-template.S:81
> No locals.
> #1  0x7fb2977d6fe7 in red_worker_main () from 
> /lib64/libspice-server.so.1 No symbol table info available.
> #2  0x7fb29cc7edf5 in start_thread (arg=0x7fb104fff700) at 
> pthread_create.c:308
> __res = 
> pd = 0x7fb104fff700
> now = 
> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140398269822720, 
> -4522449750849005939, 0, 140398269823424, 140398269822720, 140405245697216, 
> 4494326442046740109, 4492409237274449549}, mask_was_saved = 0}}, priv = {pad 
> = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
> not_first_call = 
> pagesize_m1 = 
> sp = 
> freesize = 
> #3  0x7fb29688c1ad in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
> No locals.
> 
> Thread 4 (Thread 0x7fb28c8c4700 (LWP 29081)):
> #0  pthread_cond_wait@@GLIBC_2.3.2 () at 
> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
> No locals.
> #1  0x7fb29e3b9f79 in qemu_cond_wait (cond=, 
> mutex=mutex@entry=0x7fb29e866d40 ) at 
> util/qemu-thread-posix.c:132
> err = 
> __func__ = "qemu_cond_wait"
> #2  0x7fb29e172d3b in qemu_kvm_wait_io_event (cpu=) 
> at /usr/src/debug/qemu-2.3.0/cpus.c:912
> No locals.
> #3  qemu_kvm_cpu_thread_fn (arg=0x7fb2a3d2e000) at 
> /usr/src/debug/qemu-2.3.0/cpus.c:949
> cpu = 0x7fb2a3d2e000
> r = 
> #4  0x7fb29cc7edf5 in start_thread (arg=0x7fb28c8c4700) at 
> pthread_create.c:308
> __res = 
> pd = 0x7fb28c8c4700
> now = 
> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140404838909696, 
> -4522449750849005939, 0, 140404838910400, 140404838909696, 140735272359936, 
> 4492374652678002317, 4492409237274449549}, mask_was_saved = 0}}, priv = {pad 
> = {0x0, 0x0, 0x0, 0x0}, 

Re: [Qemu-devel] [PATCH for-2.5] virtio: handle non-virtio-1-capable backend

2015-12-03 Thread Christian Borntraeger
On 12/02/2015 05:43 PM, Michael S. Tsirkin wrote:
> On Wed, Dec 02, 2015 at 03:09:58PM +0100, Cornelia Huck wrote:
>> If you run a qemu advertising VERSION_1 with an old kernel where
>> vhost did not yet support VERSION_1, you'll end up with a device
>> that is {modern pci|ccw revision 1} but does not advertise VERSION_1.
>> This is not a sensible configuration and is rejected by the Linux
>> guest drivers.
>>
>> To fix this, add a ->post_plugged() callback invoked after features
>> have been queried that can handle the VERSION_1 bit being withdrawn
>> and change pci (only setup modern if VERSION_1 is still present) and
>> ccw (fall back to revision 0 if VERSION_1 is gone).
>>
>> Signed-off-by: Cornelia Huck 
> 
> 
> Unfortunately this is too late: we need to know
> whether modern will be supported to know whether
> to add the pci express capability :(

I can at least confirm that this patch "fixes" the guest error message

virtio_net virtio0: virtio: device uses modern interface but does not have 
VIRTIO_F_VERSION_1
virtio_net: probe of virtio0 failed with error -22

is gone. but yes, its not enough for the other aspects.



> 
> Maybe this should be moved into plugged
> callback?




[Qemu-devel] vhost-user on qemu qemu-2.5.0-rc2 FAILS for multi-queue

2015-12-03 Thread Naredula Janardhana Reddy
Hi
  I am using the latest qemu-2.5.0-rc2 with vhost-user(with multi-queue,
with 3 queues)  to test multi-queue feature with vhost-user.  In the guest
vm, multi-queue feature flag is not getting enabled .

On the backend, the backend(user space switch) is receving SET_VRING_ADDR
message only for the first queue, but set VRING_ENABLE message is recevied
for all the 6 rings(or 3 queues).

On the guest vm,  "Multi-queue" feature( bit 22) is not enabled in the host
features(0x409f0024), due to this guest is not enabling multi-queue.


Is the vhost-user with multi-queue is fully implemented in the
qemu-2.5.0-rc2?.

Thanks
Jana
-
Pls find the qemu command line and logs :

guest vm command line:
 ../qemu-system-x86_64 -enable-kvm -gdb tcp::1336,server,nowait -m 256M
-monitor tcp::52001,server,nowait,nodelay -object
memory-backend-file,size=256M,id=ram0,prealloc=yes,mem-path=/mnt/hugetlbfs,share=on
-numa node,memdev=ram0 -mem-prealloc -smp 6 -chardev
socket,id=char1,path=./p1 -netdev
vhost-user,id=guest0,chardev=char1,queues=3 -device
virtio-net-pci,mq=on,vectors=8,mac=00:30:48:DB:5E:01,netdev=guest0 -vnc :8
-serial telnet::50001,server,nowait -serial telnet::50011,server,nowait
-daemonize -append ipaddr=192.168.122.3 gw=192.168.122.1 hugepages=1
hw_clock=0 -kernel ./test_image -drive
if=virtio,id=hdr0,file=./test_disk,aio=native

log on the guest vm:
: Matches inside the NETPROBE
   2:VirtioNet: Initializing VIRTIO PCI NET status :1 : pcioaddr:c000
   2:VirtioNet:  HOSTfeatures :409f0024:  capabilitie:40
guestfeatures:100024 mask_features:7000ff
   2:[5] MacAddress,   2:[16] Status,   2:[17] ControlVq,   2:[18]
RxMode,   2:[19] VLanFilter,   2:[20] RxModeExtra,   2:
   2: msi vector start :101 num:8
   2:create Kernel vmap: msix   :d0501000-d0502000
size:0M
   2: msix table :d0501000  bar addr:febd1000  baroffset:1
   2:Kernel Adding to LEAF: private page paddr: febd1004 vaddr:
d0501004
   2:addr:d0501004 ->  Lindex ( 1ff : 1ff : 82 :101 )
   2:3: addr:d0501004 ->  Lindexloc ( ff8 : ff8 : 410 :808 )
   2: 0: MSIX  data :165 address:fee8
   2: 1: MSIX  data :166 address:fee8
   2: 2: MSIX  data :167 address:fee8
   2: 3: MSIX  data :168 address:fee8
   2: 4: MSIX  data :169 address:fee8
   2: 5: MSIX  data :16a address:fee8
   2: 6: MSIX  data :16b address:fee8
   2: 7: MSIX  data :16c address:fee8
   2:MSIX... Configured ISR vector:101  numvector:8 ctrl:8007
   2:VIRTIONET:  pioaddr:c018 MAC address : 0 :30 :48 :db :182005e
:0001 mis_vector:0065   : max_vqs:1
   2:VIRTIONET: initializing MAX VQ's:1


log of user space switch:
./vhost ./p1 ./p2 0
 : ./p1 : ./p2


Cmd: VHOST_USER_GET_FEATURES (0x1)
Flags: 0x1
u64: 0x5
Processing message: VHOST_USER_GET_FEATURES
_get_features
 New MQ feature as enabled: SIZE: 8  value:4000

Cmd: VHOST_USER_GET_protocol_FEATURES (0xf)
Flags: 0x1
u64: 0x4000
Processing message: VHOST_USER_GET_protocol_FEATURES
_get_proto_features
 New MQ PROTOCOL feature as enabled: SIZE: 8  value:1

Cmd: VHOST_USER_NOTDEFINED2 (0x10)
Flags: 0x1
u64: 0x1
Processing message: VHOST_USER_NOTDEFINED2
_set_features
 set protocol features SIZE: 8  value:1

Cmd: VHOST_USER_GET_QNUMBER (0x11)
Flags: 0x1
u64: 0x1
Processing message: VHOST_USER_GET_QNUMBER
_get_qnumber
 New qnumber as enabled: SIZE: 8  value:3

Cmd: VHOST_USER_SET_OWNER (0x3)
Flags: 0x1
Processing message: VHOST_USER_SET_OWNER
_set_owner

Cmd: VHOST_USER_GET_FEATURES (0x1)
Flags: 0x1
u64: 0x3
Processing message: VHOST_USER_GET_FEATURES
_get_features
 New MQ feature as enabled: SIZE: 8  value:4000

Cmd: VHOST_USER_SET_VRING_CALL (0xd)
Flags: 0x1
u64: 0x0
Processing message: VHOST_USER_SET_VRING_CALL
_set_vring_call
Got callfd 0x6

Cmd: VHOST_USER_SET_VRING_CALL (0xd)
Flags: 0x1
u64: 0x1
Processing message: VHOST_USER_SET_VRING_CALL
_set_vring_call
Got callfd 0x7

Cmd: VHOST_USER_GET_FEATURES (0x1)
Flags: 0x1
u64: 0x1
Processing message: VHOST_USER_GET_FEATURES
_get_features
 New MQ feature as enabled: SIZE: 8  value:4000

Re: [Qemu-devel] [PATCH v3 2/3] qemu-iotests: s390x: fix test 051

2015-12-03 Thread tu bo

Hi Max:

On 12/02/2015 11:48 PM, Max Reitz wrote:

On 01.12.2015 08:35, tu bo wrote:

Hi Max:

在 2015/12/1 3:38, Max Reitz 写道:

On 26.11.2015 10:53, Bo Tu wrote:

From: Bo Tu 

The tests for device type "ide_cd" should only be tested for the pc
platform.
The default device id of hard disk on the s390 platform differs to that
of the x86 platform. A new variable device_id is defined and "virtio0"
set for the s390 platform. A x86 platform specific output file is also
needed.
Warning message expected for s390x when drive without device.

Reviewed-by: Max Reitz 


I can't remember having given this for this patch. ;-)


It's my mistake, please forgive me for it.


No problem.


Reviewed-by: Sascha Silbe 
Signed-off-by: Bo Tu 
---
   tests/qemu-iotests/051  |  99 ++
   tests/qemu-iotests/051.out  | 422

   tests/qemu-iotests/051.pc.out   | 422

   tests/qemu-iotests/051.s390.out | 335 +++
   tests/qemu-iotests/Makefile |   7 +-
   5 files changed, 828 insertions(+), 457 deletions(-)
   delete mode 100644 tests/qemu-iotests/051.out
   create mode 100644 tests/qemu-iotests/051.pc.out
   create mode 100644 tests/qemu-iotests/051.s390.out


I didn't even know we had a Makefile in tests/qemu-iotests. I don't
think it is invoked automatically, and if it was, it should not modify
the source tree. For instance, I have a separate build directory so my
source tree remains clean.

I don't think expecting the user to invoke the Makefile manually is a
good idea either. When I said "copy" I literally meant adding a copy of
051.s390.out with this patch (even though it is ugly, I'd still consider
it better).


Adding a copy of 051.s390.out is not perfect, but acceptable.



Anyway, we can circumvent the whole issue anyway. While 051 does test
some devices explicitly which are only available on the PC platform, the
thing in question which would require a s390-specific output, too, is
the final part of the test ("=== Snapshot mode ===").

You can just drop the "case" introduced by this patch and set device_id
to whatever you want (e.g. "drive0" or "none0"). Then, you replace every
"-drive file..." by "-drive if=none,id=$device_id,file=..." and you're
done (obviously, the reference output needs to be adjusted for the
changed drive ID).

Then, you don't need an 051.s390.out at all, and can just make that the
common output (051.out).


I got your idea. we can get the common output(051.out) for the final
part of the test ("=== Snapshot mode ===") with this solution.

However, other parts of this test has different outputs as below,
1. s390x has no output for some test commands for "=== No medium ===",
"=== Read-only ===" and "=== Cache modes ===". for example, "line 204 -
209" has output for pc, but no output for s390x.

 202 case "$QEMU_DEFAULT_MACHINE" in
 203 pc)
 204 run_qemu -drive media=cdrom,cache=none
 205 run_qemu -drive media=cdrom,cache=directsync
 206 run_qemu -drive media=cdrom,cache=writeback
 207 run_qemu -drive media=cdrom,cache=writethrough
 208 run_qemu -drive media=cdrom,cache=unsafe
 209 run_qemu -drive media=cdrom,cache=invalid_value
 210 ;;
 211  *)
 212 ;;
 213 esac


Yes, indeed. However, it has this output only for pc, but it will not
have any output for any other platform type. Therefore, we don't need an
s390-specific reference output, but only one reference output for pc
(051.pc.out) and one for all the other platforms (051.out).


2. s390x has "Warning: Orphaned drive without device:" for
run_qemu -drive file="$TEST_IMG",if=scsi,readonly=on
run_qemu -drive if=scsi

Please refer
http://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg04836.html.


Yes, and that's exactly the reason why I advocated filtering out that
line because we don't know whether it is visible on any platform but s390.

(e.g. see the _filter_orphan added in
http://lists.nongnu.org/archive/html/qemu-devel/2015-05/msg05992.html)

Even if we decide against adding such a filter I think we should put the
s390 output into the common 051.out file anyway. If someone tries to run
the tests on a non-s390 and non-pc platform and does not get this
warning, thus failing the test, we can still talk about adding that filter.


I prefer to keep the warning in 051.out.




I plan to change the final part of the test("=== Snapshot mode ===")
with your solution, and adding a copy of 051.s390.out. If this is fine
to you, I plan to send a new version of patch for review asap, since
Christmas is coming :-)


I'm fine with patches after christmas, too. ;-)

If you change the final part of the test and put the output into 051.out
instead of 051.s390.out (and don't create any copy for s390-virtio),
that should be 

Re: [Qemu-devel] [TCG only][Migration Bug? ] Occasionally, the content of VM's memory is inconsistent between Source and Destination of migration

2015-12-03 Thread Dr. David Alan Gilbert
* Li Zhijian (lizhij...@cn.fujitsu.com) wrote:
> 
> 
> On 12/03/2015 05:24 PM, Dr. David Alan Gilbert wrote:
> >* Li Zhijian (lizhij...@cn.fujitsu.com) wrote:
> >>Hi all,
> >>
> >>Does anyboday remember the similar issue post by hailiang months ago
> >>  http://patchwork.ozlabs.org/patch/454322/
> >>At least tow bugs about migration had been fixed since that.
> >
> >Yes, I wondered what happened to that.
> >
> >>And now we found the same issue at the tcg vm(kvm is fine), after migration,
> >>the content VM's memory is inconsistent.
> >
> >Hmm, TCG only - I don't know much about that; but I guess something must
> >be accessing memory without using the proper macros/functions so
> >it doesn't mark it as dirty.
> >
> >>we add a patch to check memory content, you can find it from affix
> >>
> >>steps to reporduce:
> >>1) apply the patch and re-build qemu
> >>2) prepare the ubuntu guest and run memtest in grub.
> >>soruce side:
> >>x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device
> >>e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive
> >>if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device
> >>virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0
> >>-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp
> >>tcp::,server,nowait -monitor stdio -cpu qemu64 -machine
> >>pc-i440fx-2.3,accel=tcg,usb=off
> >>
> >>destination side:
> >>x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device
> >>e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive
> >>if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device
> >>virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0
> >>-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp
> >>tcp::,server,nowait -monitor stdio -cpu qemu64 -machine
> >>pc-i440fx-2.3,accel=tcg,usb=off -incoming tcp:0:8881
> >>
> >>3) start migration
> >>with 1000M NIC, migration will finish within 3 min.
> >>
> >>at source:
> >>(qemu) migrate tcp:192.168.2.66:8881
> >>after saving ram complete
> >>e9e725df678d392b1a83b3a917f332bb
> >>qemu-system-x86_64: end ram md5
> >>(qemu)
> >>
> >>at destination:
> >>...skip...
> >>Completed load of VM with exit code 0 seq iteration 1264
> >>Completed load of VM with exit code 0 seq iteration 1265
> >>Completed load of VM with exit code 0 seq iteration 1266
> >>qemu-system-x86_64: after loading state section id 2(ram)
> >>49c2dac7bde0e5e22db7280dcb3824f9
> >>qemu-system-x86_64: end ram md5
> >>qemu-system-x86_64: qemu_loadvm_state: after cpu_synchronize_all_post_init
> >>
> >>49c2dac7bde0e5e22db7280dcb3824f9
> >>qemu-system-x86_64: end ram md5
> >>
> >>This occurs occasionally and only at tcg machine. It seems that
> >>some pages dirtied in source side don't transferred to destination.
> >>This problem can be reproduced even if we disable virtio.
> >>
> >>Is it OK for some pages that not transferred to destination when do
> >>migration ? Or is it a bug?
> >
> >I'm pretty sure that means it's a bug.  Hard to find though, I guess
> >at least memtest is smaller than a big OS.  I think I'd dump the whole
> >of memory on both sides, hexdump and diff them  - I'd guess it would
> >just be one byte/word different, maybe that would offer some idea what
> >wrote it.
> 
> I try to dump and compare them, more than 10 pages are different.
> in source side, they are random value rather than always 'FF' 'FB' 'EF'
> 'BF'... in destination.
> 
> and not all of the different pages are continuous.

I wonder if it happens on all of memtest's different test patterns,
perhaps it might be possible to narrow it down if you tell memtest
to only run one test at a time.

Dave

> 
> thanks
> Li
> 
> 
> >
> >Dave
> >
> >>Any idea...
> >>
> >>=md5 check patch=
> >>
> >>diff --git a/Makefile.target b/Makefile.target
> >>index 962d004..e2cb8e9 100644
> >>--- a/Makefile.target
> >>+++ b/Makefile.target
> >>@@ -139,7 +139,7 @@ obj-y += memory.o cputlb.o
> >>  obj-y += memory_mapping.o
> >>  obj-y += dump.o
> >>  obj-y += migration/ram.o migration/savevm.o
> >>-LIBS := $(libs_softmmu) $(LIBS)
> >>+LIBS := $(libs_softmmu) $(LIBS) -lplumb
> >>
> >>  # xen support
> >>  obj-$(CONFIG_XEN) += xen-common.o
> >>diff --git a/migration/ram.c b/migration/ram.c
> >>index 1eb155a..3b7a09d 100644
> >>--- a/migration/ram.c
> >>+++ b/migration/ram.c
> >>@@ -2513,7 +2513,7 @@ static int ram_load(QEMUFile *f, void *opaque, int
> >>version_id)
> >>  }
> >>
> >>  rcu_read_unlock();
> >>-DPRINTF("Completed load of VM with exit code %d seq iteration "
> >>+fprintf(stderr, "Completed load of VM with exit code %d seq iteration "
> >>  "%" PRIu64 "\n", ret, seq_iter);
> >>  return ret;
> >>  }
> >>diff --git a/migration/savevm.c b/migration/savevm.c
> >>index 0ad1b93..3feaa61 100644
> >>--- a/migration/savevm.c
> >>+++ b/migration/savevm.c
> >>@@ -891,6 +891,29 @@ void qemu_savevm_state_header(QEMUFile *f)
> 

[Qemu-devel] [Minios-devel] [PATCH v6 0/] Begin to disentangle libxenctrl and provide some stable libraries

2015-12-03 Thread Ian Campbell
In <1431963008.4944.80.ca...@citrix.com> I proposed stabilising some
parts of the libxenctrl API/ABI by disaggregating into separate
libraries.

This is v6 of that set of series against:
xen
qemu-xen
qemu-xen-traditional
mini-os

NB: Samuel+minios-devel will only get the mini-os side and Stefano+qemu
-devel the qemu-xen side.

The code for all repos can be found in:

git://xenbits.xen.org/people/ianc/libxenctrl-split/xen.git  v6
git://xenbits.xen.org/people/ianc/libxenctrl-split/qemu-xen.git v6
git://xenbits.xen.org/people/ianc/libxenctrl-split/qemu-xen-traditional.git v6
git://xenbits.xen.org/people/ianc/libxenctrl-split/mini-os.git  v6

The tip of the xen.git branch contains an extra patch hacking Config.mk
to point to all the others above, which should get the correct things for
the HEAD of the branch, but not further back in time.

The new libraries here are:

 * libxentoollog: Common logging infrastructure
 * libxenevtchn: Userspace access to evtchns (via /dev/xen/evtchn etc)
 * libxengnttab: Userspace access to grant tables (via /dev/xen/gnt??? etc)
 * libxencall: Making hypercalls (i.e. the IOCTL_PRIVCMD_HYPERCALL type
   functionality)
 * libxenforeignmemory: Privileged mappings of foreign memory
   (IOCTL_PRIVCMD_MMAP et al)

The first three were actually pretty distinct within libxenctrl already and
have not changed in quite some time.

Although the other two are somewhat new they are based on top of long
standing stable ioctls, which gives me some confidence.

Nonetheless I would appreciate extra review of at least the interface
headers of all of these with a particular eye to the suitability of these
interfaces being maintained in an ABI (_B_, not _P_) stable way going
forward.

Still to come would be libraries for specific out of tree purposes
(device model, kexec), which would be adding new library at the same
level as libxc I think, rather than underneath, i.e. also using the
libraries split out here, but hopefully not libxenctrl itself.

The new libraries use linker version-scripts to hopefully make future
ABI changes be possible in a compatible way.

Since last time:

 * Major changes to the libxenforeignmemory interface, which necessitated
   some changes on the qemu-xen side too, invalidating various
   (Ack|Review)ed-by.
* Reordered the arguments to make the use of VLA possible in the future
  
* Allow err==NULL, this in turn lead to the realisation that the error
  handling for a bunch of the xc_map_foreign_* functions which
  transition => xc_map_foreign_bulk => xenforeigmemory_map in this
  series was all wrong in expecting a NULL return on error when errors
  can also be signalled in err[]. This lead to most of the dropped acks
  and various reorderings/restructuring of changes 
 * Lots of docs updates based on feedback given, especially to the gnttab
   interface.

Even with the dropped acks mini-os and qemu-xen-trad are fully acked, while
qemu-xen and xen are mostly acked (but had a few dropped acks since last
time).

The whole thing has been build tested on Linux (incl stubdoms), and on
FreeBSD. I have runtime on Linux with qemu-xen, qemu-xen-trad and stubdoms.

Neither NetBSD nor Solaris have been tested at all. It's certainly not
impossible that I've not got the #includes in the new files quite right.

http://xenbits.xen.org/people/ianc/libxenctrl-split/v6.html is the document
I've been using to try and track what I'm doing. It may not be all that
useful. The history of it is in the v6-with-doc branch of the xen.git
linked to above.

Last time  proposed that these precursors (and the corresponding qemu-xen-
traditional + mini-os patches) should go in now:

tools/Rules.mk: Properly handle libraries with recursive dependencies.
tools: Refactor "xentoollog" into its own library

But I subsequently found a couple of build issues, which are addressed by
two new patches at the head of the xen series.

Note also that I've picked up "x86/libxc: add an arch domain config
parameter to xc_domain_create" into my xen branch, in order that I can work
against qemu mainline, I expect that to go in shortly and be dropped here
(just waiting on a qemu-xen-upstream-unstable osstest pass).

Ian.




Re: [Qemu-devel] [PATCH v2 5/6] target-arm: support QMP dump-guest-memory

2015-12-03 Thread Peter Maydell
On 25 November 2015 at 00:37, Andrew Jones  wrote:
> Add the support needed for creating prstatus elf notes. This
> allows us to use QMP dump-guest-memory.

> +
> +if (is_a64(env)) {
> +for (i = 0; i < 31; ++i) {
> +note.prstatus.pr_reg.regs[i] = cpu_to_dump64(s, env->xregs[i]);
> +}
> +note.prstatus.pr_reg.sp = cpu_to_dump64(s, env->xregs[31]);
> +note.prstatus.pr_reg.pc = cpu_to_dump64(s, env->pc);
> +note.prstatus.pr_reg.pstate = cpu_to_dump64(s, pstate_read(env));
> +} else {
> +aarch64_sync_64_to_32(env);
> +for (i = 0; i < 16; ++i) {
> +note.prstatus.pr_reg.regs[i] = cpu_to_dump64(s, env->regs[i]);
> +}
> +note.prstatus.pr_reg.sp = note.prstatus.pr_reg.regs[13];
> +note.prstatus.pr_reg.pc = note.prstatus.pr_reg.regs[15];
> +note.prstatus.pr_reg.pstate = cpu_to_dump64(s, cpsr_read(env));
> +}

This doesn't look right. sync_64_to_32 is copying the state held
in the 64-bit env->xregs etc into the 32-bit env->regs. But if we're
in 32-bit state then the true state is in the 32-bit fields and
this will trash it. You want to sync_32_to_64 here, and then the
code to write the values to the dump is the same either way
(except for pstate vs cpsr which we haven't managed to clean up
and unify yet, sadly).

I think you want
   uint64_t pstate;
   [...]

   if (!is_a64(env)) {
   aarch64_sync_32_to_64(env);
   pstate = cpsr_read(env);
   } else {
   pstate = pstate_read(env);
   }
   for (i = 0; i < 31; ++i) {
   note.prstatus.pr_reg.regs[i] = cpu_to_dump64(s, env->xregs[i]);
   }
   note.prstatus.pr_reg.sp = cpu_to_dump64(s, env->xregs[31]);
   note.prstatus.pr_reg.pc = cpu_to_dump64(s, env->pc);
   note.prstatus.pr_reg.pstate = cpu_to_dump64(s, pstate);

(Note that the 32-bit SP is not architecturally in X31;
it's in one of the other xregs, depending what mode the CPU
was in. For 32-bit userspace that will be USR and it's in X13.)


> +
> +ret = f(, sizeof(note), s);
> +if (ret < 0) {
> +return -1;
> +}
> +
> +return 0;
> +}
> +
> +/* struct pt_regs from arch/arm/include/asm/ptrace.h */
> +struct arm_user_regs {
> +uint32_t regs[17];
> +char pad[4];
> +} QEMU_PACKED;
> +
> +QEMU_BUILD_BUG_ON(sizeof(struct arm_user_regs) != 72);
> +
> +/* struct elf_prstatus from include/uapi/linux/elfcore.h */
> +struct arm_elf_prstatus {
> +char pad1[24]; /* 24 == offsetof(struct elf_prstatus, pr_pid) */
> +uint32_t pr_pid;
> +char pad2[44]; /* 44 == offsetof(struct elf_prstatus, pr_reg) -
> +offsetof(struct elf_prstatus, pr_ppid) */
> +struct arm_user_regs pr_reg;
> +int pr_fpvalid;
> +} QEMU_PACKED arm_elf_prstatus;
> +
> +QEMU_BUILD_BUG_ON(sizeof(struct arm_elf_prstatus) != 148);
> +
> +struct arm_note {
> +Elf32_Nhdr hdr;
> +char name[QEMU_ALIGN_UP(NOTE_NAMESZ, 4)];
> +struct arm_elf_prstatus prstatus;
> +} QEMU_PACKED;
> +
> +QEMU_BUILD_BUG_ON(sizeof(struct arm_note) != 168);
> +
> +static int
> +arm_write_elf32_note(WriteCoreDumpFunction f, CPUARMState *env,
> + int id, DumpState *s)
> +{
> +struct arm_note note;
> +int ret, i;
> +
> +memset(, 0, sizeof(note));
> +
> +note.hdr.n_namesz = cpu_to_dump32(s, NOTE_NAMESZ);
> +note.hdr.n_descsz = cpu_to_dump32(s, sizeof(note.prstatus));
> +note.hdr.n_type = cpu_to_dump32(s, NT_PRSTATUS);
> +
> +memcpy(note.name, NOTE_NAME, NOTE_NAMESZ);
> +note.prstatus.pr_pid = cpu_to_dump32(s, id);
> +
> +for (i = 0; i < 16; ++i) {
> +note.prstatus.pr_reg.regs[i] = cpu_to_dump32(s, env->regs[i]);
> +}
> +note.prstatus.pr_reg.regs[16] = cpu_to_dump32(s, cpsr_read(env));
> +
> +ret = f(, sizeof(note), s);
> +if (ret < 0) {
> +return -1;
> +}
> +
> +return 0;
> +}
> +
> +int arm_cpu_write_elf64_note(WriteCoreDumpFunction f, CPUState *cs,
> + int cpuid, void *opaque)
> +{
> +CPUARMState *env = _CPU(cs)->env;
> +int ret;
> +
> +if (arm_el_is_aa64(env, 1)) {
> +ret = aarch64_write_elf64_note(f, env, cpuid, opaque);
> +} else {
> +ret = arm_write_elf32_note(f, env, cpuid, opaque);
> +}

This might produce the wrong kind of dump if we're in EL2
or EL3 at the point we take it (can only happen in emulation
and only once we add EL2 and EL3 emulation support, which isn't
active yet). Do we care?

thanks
-- PMM



Re: [Qemu-devel] [PATCH for-2.5] tcg: Increase the highwater reservation

2015-12-03 Thread Aurelien Jarno
On 2015-12-02 10:36, Richard Henderson wrote:
> On 12/01/2015 08:32 AM, Aurelien Jarno wrote:
> >On 2015-12-01 08:19, Richard Henderson wrote:
> >>If there are a lot of guest memory ops in the TB, the amount of
> >>code generated by tcg_out_tb_finalize could be well more than 1k.
> >>In the short term, increase the reservation larger than any TB
> >>seen in practice.
> >>
> >>Reported-by: Aurelien Jarno 
> >>Signed-off-by: Richard Henderson 
> >
> >Thanks! I was testing the same patch locally after our discussion, and I
> >confirm it fixes the issue.
> 
> Here's the proper patch for 2.6.  If you'd like to run it through your same
> tests, please?

The patch looks fine to me, the only tiny nitpick I have is that you can
return a bool instead of a hint.

I am currently testing it (which is basically running a glibc build and
testsuite multiple time in a VM), I'll let you know the result by
tomorrow. In the meantime, you can add:

Reviewed-by: Aurelien Jarno 

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net



Re: [Qemu-devel] [PATCH v2 6/6] target-arm: dump-guest-memory: add fpregset notes

2015-12-03 Thread Peter Maydell
On 25 November 2015 at 00:37, Andrew Jones  wrote:
> Also refactors note init code to avoid code duplication.

Can you squash those parts down into the preceding patch?

>
> Signed-off-by: Andrew Jones 
> ---
>  target-arm/arch_dump.c | 161 
> ++---
>  1 file changed, 139 insertions(+), 22 deletions(-)
>
> diff --git a/target-arm/arch_dump.c b/target-arm/arch_dump.c
> index 5debe549d721d..8d74788411d79 100644
> --- a/target-arm/arch_dump.c
> +++ b/target-arm/arch_dump.c
> @@ -35,6 +35,16 @@ struct aarch64_user_regs {
>
>  QEMU_BUILD_BUG_ON(sizeof(struct aarch64_user_regs) != 272);
>
> +/* struct user_fpsimd_state from arch/arm64/include/uapi/asm/ptrace.h */

The kernel struct uses __uint128_t, not an array of uint64_t; that's
worth commenting because it clarifies what the expected format is.

> +struct aarch64_user_vfp_state {
> +uint64_t vregs[64];
> +uint32_t fpsr;
> +uint32_t fpcr;
> +char pad[8];
> +} QEMU_PACKED;
> +
> +QEMU_BUILD_BUG_ON(sizeof(struct aarch64_user_vfp_state) != 528);
> +
>  /* struct elf_prstatus from include/uapi/linux/elfcore.h */
>  struct aarch64_elf_prstatus {
>  char pad1[32]; /* 32 == offsetof(struct elf_prstatus, pr_pid) */
> @@ -51,10 +61,77 @@ QEMU_BUILD_BUG_ON(sizeof(struct aarch64_elf_prstatus) != 
> 392);
>  struct aarch64_note {
>  Elf64_Nhdr hdr;
>  char name[QEMU_ALIGN_UP(NOTE_NAMESZ, 4)];
> -struct aarch64_elf_prstatus prstatus;
> +union {
> +struct aarch64_elf_prstatus prstatus;
> +struct aarch64_user_vfp_state vfp;
> +};
>  } QEMU_PACKED;
>
> -QEMU_BUILD_BUG_ON(sizeof(struct aarch64_note) != 412);
> +#define AARCH64_NOTE_HEADER_SIZE offsetof(struct aarch64_note, prstatus)
> +#define AARCH64_PRSTATUS_NOTE_SIZE \
> +(AARCH64_NOTE_HEADER_SIZE + sizeof(struct aarch64_elf_prstatus))
> +#define AARCH64_FPREGSET_NOTE_SIZE \
> +(AARCH64_NOTE_HEADER_SIZE + sizeof(struct 
> aarch64_user_vfp_state))
> +
> +static void aarch64_note_init(struct aarch64_note *note, DumpState *s,
> +  Elf64_Word type, Elf64_Word descsz)
> +{
> +memset(note, 0, sizeof(*note));
> +
> +note->hdr.n_namesz = cpu_to_dump32(s, NOTE_NAMESZ);
> +note->hdr.n_descsz = cpu_to_dump32(s, descsz);
> +note->hdr.n_type = cpu_to_dump32(s, type);
> +
> +memcpy(note->name, NOTE_NAME, NOTE_NAMESZ);
> +}
> +
> +static void arm_write_vregs(uint64_t *vregs, int num_regs,
> +CPUARMState *env, DumpState *s)
> +{
> +int i;
> +
> +for (i = 0; i < num_regs; ++i) {
> +vregs[i] = cpu_to_dump64(s, env->vfp.regs[i]);
> +}
> +
> +if (s->dump_info.d_endian == ELFDATA2MSB) {
> +/* We must always swap vfp.regs's 2n and 2n+1 entries when
> + * generating BE notes, because even big endian hosts use
> + * 2n+1 for the high half.
> + */
> +for (i = 0; i < num_regs/2; ++i) {
> +uint64_t tmp = vregs[2*i];
> +vregs[2*i] = vregs[2*i+1];
> +vregs[2*i+1] = tmp;
> +}

This swapping is correct for AArch64, where the core dump format
is an array of 128 bit Qn register values (which in QEMU
are stored in vfp.regs[2n+1]:vfp.regs[2n] as a pair of 64
bit values). However it's wrong for AArch32, where the core
dump format is an array of 64-bit Dn register values, which
in QEMU are just in vfp.regs[n].

(See the comment in target-arm/cpu.h about VFP/Neon register
state and different views of the register bank.)

> +static int
> +arm_write_elf32_fpregset(WriteCoreDumpFunction f, CPUARMState *env,
> + int id, DumpState *s)
> +{
> +struct arm_note note;
> +int ret;
> +
> +arm_note_init(, s, NT_FPREGSET, sizeof(note.vfp));
> +
> +arm_write_vregs(note.vfp.vregs, 32, env, s);
> +
> +note.vfp.fpscr = cpu_to_dump32(s, vfp_get_fpscr(env));

Do consumers care if we write out a dump with FP register
state for a CPU which doesn't implement FP? (For AArch64
FP is always present, but for AArch32 it may not be.)

thanks
-- PMM



Re: [Qemu-devel] [TCG only][Migration Bug? ] Occasionally, the content of VM's memory is inconsistent between Source and Destination of migration

2015-12-03 Thread Juan Quintela
Li Zhijian  wrote:
> Hi all,
>
> Does anyboday remember the similar issue post by hailiang months ago
>  http://patchwork.ozlabs.org/patch/454322/
> At least tow bugs about migration had been fixed since that.
>
> And now we found the same issue at the tcg vm(kvm is fine), after
> migration, the content VM's memory is inconsistent.
>
> we add a patch to check memory content, you can find it from affix
>
> steps to reporduce:
> 1) apply the patch and re-build qemu
> 2) prepare the ubuntu guest and run memtest in grub.
> soruce side:
> x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device
> e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive
> if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device
> virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0
> -vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp
> tcp::,server,nowait -monitor stdio -cpu qemu64 -machine
> pc-i440fx-2.3,accel=tcg,usb=off
>
> destination side:
> x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device
> e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive
> if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device
> virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0
> -vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp
> tcp::,server,nowait -monitor stdio -cpu qemu64 -machine
> pc-i440fx-2.3,accel=tcg,usb=off -incoming tcp:0:8881
>
> 3) start migration
> with 1000M NIC, migration will finish within 3 min.
>
> at source:
> (qemu) migrate tcp:192.168.2.66:8881
> after saving ram complete
> e9e725df678d392b1a83b3a917f332bb
> qemu-system-x86_64: end ram md5
> (qemu)
>
> at destination:
> ...skip...
> Completed load of VM with exit code 0 seq iteration 1264
> Completed load of VM with exit code 0 seq iteration 1265
> Completed load of VM with exit code 0 seq iteration 1266
> qemu-system-x86_64: after loading state section id 2(ram)
> 49c2dac7bde0e5e22db7280dcb3824f9
> qemu-system-x86_64: end ram md5
> qemu-system-x86_64: qemu_loadvm_state: after cpu_synchronize_all_post_init
>
> 49c2dac7bde0e5e22db7280dcb3824f9
> qemu-system-x86_64: end ram md5
>
> This occurs occasionally and only at tcg machine. It seems that
> some pages dirtied in source side don't transferred to destination.
> This problem can be reproduced even if we disable virtio.
>
> Is it OK for some pages that not transferred to destination when do
> migration ? Or is it a bug?
>
> Any idea...

Thanks for describing how to reproduce the bug.
If some pages are not transferred to destination then it is a bug, so we
need to know what the problem is, notice that the problem can be that
TCG is not marking dirty some page, that Migration code "forgets" about
that page, or anything eles altogether, that is what we need to find.

There are more posibilities, I am not sure that memtest is on 32bit
mode, and it is inside posibility that we are missing some state when we
are on real mode.

Will try to take a look at this.

THanks, again.


>
> =md5 check patch=
>
> diff --git a/Makefile.target b/Makefile.target
> index 962d004..e2cb8e9 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -139,7 +139,7 @@ obj-y += memory.o cputlb.o
>  obj-y += memory_mapping.o
>  obj-y += dump.o
>  obj-y += migration/ram.o migration/savevm.o
> -LIBS := $(libs_softmmu) $(LIBS)
> +LIBS := $(libs_softmmu) $(LIBS) -lplumb
>
>  # xen support
>  obj-$(CONFIG_XEN) += xen-common.o
> diff --git a/migration/ram.c b/migration/ram.c
> index 1eb155a..3b7a09d 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -2513,7 +2513,7 @@ static int ram_load(QEMUFile *f, void *opaque,
> int version_id)
>  }
>
>  rcu_read_unlock();
> -DPRINTF("Completed load of VM with exit code %d seq iteration "
> +fprintf(stderr, "Completed load of VM with exit code %d seq iteration "
>  "%" PRIu64 "\n", ret, seq_iter);
>  return ret;
>  }
> diff --git a/migration/savevm.c b/migration/savevm.c
> index 0ad1b93..3feaa61 100644
> --- a/migration/savevm.c
> +++ b/migration/savevm.c
> @@ -891,6 +891,29 @@ void qemu_savevm_state_header(QEMUFile *f)
>
>  }
>
> +#include "exec/ram_addr.h"
> +#include "qemu/rcu_queue.h"
> +#include 
> +#ifndef MD5_DIGEST_LENGTH
> +#define MD5_DIGEST_LENGTH 16
> +#endif
> +
> +static void check_host_md5(void)
> +{
> +int i;
> +unsigned char md[MD5_DIGEST_LENGTH];
> +rcu_read_lock();
> +RAMBlock *block = QLIST_FIRST_RCU(_list.blocks);/* Only check
> 'pc.ram' block */
> +rcu_read_unlock();
> +
> +MD5(block->host, block->used_length, md);
> +for(i = 0; i < MD5_DIGEST_LENGTH; i++) {
> +fprintf(stderr, "%02x", md[i]);
> +}
> +fprintf(stderr, "\n");
> +error_report("end ram md5");
> +}
> +
>  void qemu_savevm_state_begin(QEMUFile *f,
>   const MigrationParams *params)
>  {
> @@ -1056,6 +1079,10 @@ 

[Qemu-devel] [PATCH] ui: vnc: avoid floating point exception

2015-12-03 Thread P J P

  Hello Gerd,

A floating point exception issue in the VNC server PNG compression support was 
reported by Mr Lian Yihan, CC'd here. Given below is a proposed (tested)patch 
to fix this issue.


===

From 1ca4818333d39fed6567e316e37f6a6516f59c69 Mon Sep 17 00:00:00 2001

From: Prasad J Pandit 
Date: Thu, 3 Dec 2015 16:04:51 +0530
Subject: [PATCH] ui: vnc: avoid floating point exception

While sending 'SetPixelFormat' messages to a VNC server,
the client could set the 'red-max', 'green-max' and 'blue-max'
values to be zero. This leads to a floating point exception in
write_png_palette while doing frame buffer updates.

Reported-by: Lian Yihan 
Signed-off-by: Prasad J Pandit 
---
 ui/vnc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/ui/vnc.c b/ui/vnc.c
index caf82f5..52c6809 100644
--- a/ui/vnc.c
+++ b/ui/vnc.c
@@ -2189,15 +2189,15 @@ static void set_pixel_format(VncState *vs,
 return;
 }

-vs->client_pf.rmax = red_max;
+vs->client_pf.rmax = red_max ? red_max : 0xFF;
 vs->client_pf.rbits = hweight_long(red_max);
 vs->client_pf.rshift = red_shift;
 vs->client_pf.rmask = red_max << red_shift;
-vs->client_pf.gmax = green_max;
+vs->client_pf.gmax = green_max ? green_max : 0xFF;
 vs->client_pf.gbits = hweight_long(green_max);
 vs->client_pf.gshift = green_shift;
 vs->client_pf.gmask = green_max << green_shift;
-vs->client_pf.bmax = blue_max;
+vs->client_pf.bmax = blue_max ? blue_max : 0xFF;
 vs->client_pf.bbits = hweight_long(blue_max);
 vs->client_pf.bshift = blue_shift;
 vs->client_pf.bmask = blue_max << blue_shift;
--
2.4.3
===


Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F



Re: [Qemu-devel] [PATCH for-2.5 0/2] tests: A cleanup and a fix

2015-12-03 Thread Markus Armbruster
Peter Maydell  writes:

> On 2 December 2015 at 20:20, Markus Armbruster  wrote:
>> PATCH 1 cleans up unnecessary type punning.
>>
>> PATCH 2 plugs a massive memory leak in qom-test.  I think it would be
>> nice to have in 2.5, but at this late stage, it's really up to the
>> maintainer.
>
> To go into 2.5 it needs to be reviewed and either be in a pull
> request or have a request from the maintainer for me to apply it
> directly by the end of today UK time.

Understood.

> Is the memory leak a regression, or have we always leaked and
> not noticed?

As far as I can see, a minor leak was introduced in commit 5c1904f, but
the major leakage comes from commit dc06cbd, both v2.0.



Re: [Qemu-devel] [PATCH] ui: vnc: avoid floating point exception

2015-12-03 Thread Gerd Hoffmann
On Do, 2015-12-03 at 17:07 +0530, P J P wrote:
>Hello Gerd,
> 
> A floating point exception issue in the VNC server PNG compression support 
> was 
> reported by Mr Lian Yihan, CC'd here. Given below is a proposed (tested)patch 
> to fix this issue.

> -vs->client_pf.rmax = red_max;
> +vs->client_pf.rmax = red_max ? red_max : 0xFF;

Looks good.

Reviewed-by: Gerd Hoffmann 

Peter, can you pick this up directly for 2.5-rc3?

thanks,
  Gerd




Re: [Qemu-devel] [PATCH for-2.5 0/2] tests: A cleanup and a fix

2015-12-03 Thread Andreas Färber
Am 03.12.2015 um 13:06 schrieb Markus Armbruster:
> Peter Maydell  writes:
> 
>> On 2 December 2015 at 20:20, Markus Armbruster  wrote:
>>> PATCH 1 cleans up unnecessary type punning.
>>>
>>> PATCH 2 plugs a massive memory leak in qom-test.  I think it would be
>>> nice to have in 2.5, but at this late stage, it's really up to the
>>> maintainer.
>>
>> To go into 2.5 it needs to be reviewed and either be in a pull
>> request or have a request from the maintainer for me to apply it
>> directly by the end of today UK time.
> 
> Understood.
> 
>> Is the memory leak a regression, or have we always leaked and
>> not noticed?
> 
> As far as I can see, a minor leak was introduced in commit 5c1904f, but
> the major leakage comes from commit dc06cbd, both v2.0.

Well, as the qom-test maintainer I have been struggling with the two 1GB
Exynos4 machines on i586 hosts from 2.3 on already
(http://bugzilla.opensuse.org/show_bug.cgi?id=957379). While this
happens really early and we have been able to work around it by
decoupling compilation and execution of the tests a little (blaming make
or whomever for memory fragmentation), I'd like to investigate whether
this helps that regression. Otherwise memory cleanup has not been a
topic for non-QAPI allocations in tests either so it does not seem too
urgent to me if it's just cosmetic.

The preceding patch looks fine to me on a first look.

An unrelated question to consider going forward is whether we should
conditionalize and by default skip my property tests for time reasons.

Thanks,
Andreas

P.S. Since Peter insists on a pull, I will prepare one to finally fix
the make test breakage Marc and me both pointed out to no effect. If you
desire changes beyond dropping my one cosmetic patch, do comment.

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)



Re: [Qemu-devel] net: vmxnet3: memory leakage issue

2015-12-03 Thread P J P
  Hello Dmitry,

+-- On Thu, 3 Dec 2015, Dmitry Fleytman wrote --+
| The patch is good.
| Jason, would you apply is from attachment or should it be resent by "git 
send-email”?
| 
| Acked-by: Dmitry Fleytman >

Thank you. (/me makes a note to learn about git send-email.)
--
Prasad J Pandit / Red Hat Product Security Team
47AF CE69 3A90 54AA 9045 1053 DD13 3D32 FE5B 041F

Re: [Qemu-devel] [PATCH] ui: vnc: avoid floating point exception

2015-12-03 Thread Peter Maydell
On 3 December 2015 at 12:11, Gerd Hoffmann  wrote:
> On Do, 2015-12-03 at 17:07 +0530, P J P wrote:
>>Hello Gerd,
>>
>> A floating point exception issue in the VNC server PNG compression support 
>> was
>> reported by Mr Lian Yihan, CC'd here. Given below is a proposed (tested)patch
>> to fix this issue.
>
>> -vs->client_pf.rmax = red_max;
>> +vs->client_pf.rmax = red_max ? red_max : 0xFF;
>
> Looks good.
>
> Reviewed-by: Gerd Hoffmann 
>
> Peter, can you pick this up directly for 2.5-rc3?

The patch doesn't apply to master. Can you produce a version
that does, please?

thanks
-- PMM



Re: [Qemu-devel] [PULL 0/2] Migration PULL request

2015-12-03 Thread Peter Maydell
On 2 December 2015 at 23:22, Juan Quintela <quint...@redhat.com> wrote:
> Hi
>
> Two small fixes
>
> - Coverity error discovered by Paole that got lost on the track
>   (it is a needed cast).
>   We got this one in RHEL in the past, so it is not only theoretical.v
> - Armbru fix for g_poll() returning one error
>
> Please, apply.
>
>
> The following changes since commit cf22132367a188426ac07cf1805b214dd2d0cc80:
>
>   Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging 
> (2015-12-02 17:05:34 +)
>
> are available in the git repository at:
>
>   git://github.com/juanquintela/qemu.git tags/migration/20151203
>
> for you to fetch changes up to a694ee343d13159d214823294bbda08e4bdac685:
>
>   migration: do floating-point division (2015-12-03 00:03:00 +0100)
>
> ----
> migration/next for 20151203
>
> 
> Markus Armbruster (1):
>   migration: Clean up use of g_poll() in socket_writev_buffer()
>
> Paolo Bonzini (1):
>   migration: do floating-point division

Applied, thanks.

-- PMM



[Qemu-devel] [PATCH QEMU-XEN v6 0/8] Begin to disentangle libxenctrl and provide some stable libraries

2015-12-03 Thread Ian Campbell
We intend to stabilise some parts of the libxenctrl interface by
splitting out some functionality into separate stable libraries.

This is the qemu-xen part of the first phase of that change.

This mail is (or is intended to be) a reply to a "0/"
super-intro mail covering all of the related patch series and which
contains more details.

Ian Campbell (8):
  xen_console: correctly cleanup primary console on teardown.
  xen: Switch to libxenevtchn interface for compat shims.
  xen: Switch to libxengnttab interface for compat shims.
  xen: Switch uses of xc_map_foreign_range into xc_map_foreign_pages
  xen: Switch uses of xc_map_foreign_{pages,bulk} to use
libxenforeignmemory API.
  xen: Use stable library interfaces when they are available.
  xen: domainbuild: reopen libxenctrl interface after forking for domain
watcher.
  xen: make it possible to build without the Xen PV domain builder

 configure|  57 -
 hw/block/xen_disk.c  |  38 +--
 hw/char/xen_console.c|  19 +++---
 hw/display/xenfb.c   |  18 +++---
 hw/net/xen_nic.c |  18 +++---
 hw/xen/xen_backend.c |  44 ++---
 hw/xenpv/Makefile.objs   |   4 +-
 hw/xenpv/xen_domainbuild.c   |   9 ++-
 hw/xenpv/xen_machine_pv.c|  15 +++--
 include/hw/xen/xen_backend.h |   5 +-
 include/hw/xen/xen_common.h  | 147 +++
 xen-common.c |   6 ++
 xen-hvm.c|  39 ++--
 xen-mapcache.c   |   6 +-
 14 files changed, 297 insertions(+), 128 deletions(-)

-- 
2.1.4




[Qemu-devel] [PATCH QEMU-XEN v6 1/8] xen_console: correctly cleanup primary console on teardown.

2015-12-03 Thread Ian Campbell
All of the work in con_disconnect applies to the primary console case
(when xendev->dev is NULL). Therefore remove the early check and bail
and allow it to fall through. All of the existing code is correctly
conditional already.

The ->dev and ->gnttabdev handles are either both set or neither. For
consistency with con_initialise() with to the former here too.

With this con_initialise and con_disconnect now mirror each other.

Fix up a hard tab in the function while editing.

Signed-off-by: Ian Campbell 
Reviewed-by: Stefano Stabellini 

---
v4: New patch based on feedback to "xen: Switch uses of
xc_map_foreign_bulk to use libxenforeignmemory API."
---
 hw/char/xen_console.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index eb7f450..63ade33 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -265,9 +265,6 @@ static void con_disconnect(struct XenDevice *xendev)
 {
 struct XenConsole *con = container_of(xendev, struct XenConsole, xendev);
 
-if (!xendev->dev) {
-return;
-}
 if (con->chr) {
 qemu_chr_add_handlers(con->chr, NULL, NULL, NULL, NULL);
 qemu_chr_fe_release(con->chr);
@@ -275,12 +272,12 @@ static void con_disconnect(struct XenDevice *xendev)
 xen_be_unbind_evtchn(>xendev);
 
 if (con->sring) {
-if (!xendev->gnttabdev) {
+if (!xendev->dev) {
 munmap(con->sring, XC_PAGE_SIZE);
 } else {
 xc_gnttab_munmap(xendev->gnttabdev, con->sring, 1);
 }
-   con->sring = NULL;
+con->sring = NULL;
 }
 }
 
-- 
2.1.4




Re: [Qemu-devel] [PATCH 04/13] block: add meta bitmaps

2015-12-03 Thread Fam Zheng
On Wed, 11/11 18:16, Vladimir Sementsov-Ogievskiy wrote:
> Meta bitmap is a 'dirty bitmap' for the BdrvDirtyBitmap. It tracks
> changes (set/unset) of this BdrvDirtyBitmap. It is needed for live
> migration of block dirty bitmaps.
> 
> Reviewed-by: John Snow 
> Signed-off-by: Vladimir Sementsov-Ogievskiy 
> ---
>  block.c   | 44 
>  include/block/block.h |  7 +++
>  2 files changed, 51 insertions(+)
> 
> diff --git a/block.c b/block.c
> index 1171dbb..05307bc 100644
> --- a/block.c
> +++ b/block.c
> @@ -61,9 +61,15 @@
>   * (3) successor is set: frozen mode.
>   * A frozen bitmap cannot be renamed, deleted, anonymized, cleared, set,
>   * or enabled. A frozen bitmap can only abdicate() or reclaim().
> + *
> + * Meta bitmap:
> + * Meta bitmap is a 'dirty bitmap' for the BdrvDirtyBitmap. It tracks changes
> + * (set/unset) of this BdrvDirtyBitmap. It is needed for live migration of
> + * block dirty bitmaps.
>   */
>  struct BdrvDirtyBitmap {
>  HBitmap *bitmap;/* Dirty sector bitmap implementation */
> +HBitmap *meta_bitmap;   /* Meta bitmap */
>  BdrvDirtyBitmap *successor; /* Anonymous child; implies frozen status */
>  char *name; /* Optional non-empty unique ID */
>  int64_t size;   /* Size of the bitmap (Number of sectors) */
> @@ -3145,6 +3151,35 @@ void bdrv_dirty_bitmap_make_anon(BdrvDirtyBitmap 
> *bitmap)
>  bitmap->name = NULL;
>  }
>  
> +HBitmap *bdrv_create_meta_bitmap(BdrvDirtyBitmap *bitmap,
> + uint64_t chunk_size)
> +{
> +uint64_t sector_granularity;
> +
> +assert((chunk_size & (chunk_size - 1)) == 0);
> +
> +/* one chunk is corresponding to one bit of the meta bitmap, and each bit
> + * of the chunk is corresponding to 
> 'bdrv_dirty_bitmap_granularity(bitmap)'
> + * bytes of the node */
> +sector_granularity =
> +(chunk_size * 8 * bdrv_dirty_bitmap_granularity(bitmap))
> +>> BDRV_SECTOR_BITS;
> +assert(sector_granularity);
> +
> +bitmap->meta_bitmap =
> +hbitmap_alloc(bitmap->size, ctz64(sector_granularity));
> +
> +return bitmap->meta_bitmap;
> +}
> +
> +void bdrv_release_meta_bitmap(BdrvDirtyBitmap *bitmap)
> +{
> +if (bitmap->meta_bitmap) {
> +hbitmap_free(bitmap->meta_bitmap);
> +bitmap->meta_bitmap = NULL;
> +}
> +}
> +
>  BdrvDirtyBitmap *bdrv_create_dirty_bitmap(BlockDriverState *bs,
>uint32_t granularity,
>const char *name,
> @@ -3305,6 +3340,9 @@ void bdrv_release_dirty_bitmap(BlockDriverState *bs, 
> BdrvDirtyBitmap *bitmap)
>  assert(!bdrv_dirty_bitmap_frozen(bm));
>  QLIST_REMOVE(bitmap, list);
>  hbitmap_free(bitmap->bitmap);
> +if (bitmap->meta_bitmap) {
> +hbitmap_free(bitmap->meta_bitmap);
> +}
>  g_free(bitmap->name);
>  g_free(bitmap);
>  return;
> @@ -3390,6 +3428,9 @@ void bdrv_set_dirty_bitmap(BdrvDirtyBitmap *bitmap,
>  {
>  assert(bdrv_dirty_bitmap_enabled(bitmap));
>  hbitmap_set(bitmap->bitmap, cur_sector, nr_sectors);
> +if (bitmap->meta_bitmap) {
> +hbitmap_set(bitmap->meta_bitmap, cur_sector, nr_sectors);

This is a bit too much, the bitmap is not necessarily dirty even though
bdrv_set_dirty_bitmap is called, if this range is already dirty. For example
when the guest is repeatedly writing to a hot spot on disk.

Fam

> +}
>  }
>  
>  void bdrv_reset_dirty_bitmap(BdrvDirtyBitmap *bitmap,
> @@ -3397,6 +3438,9 @@ void bdrv_reset_dirty_bitmap(BdrvDirtyBitmap *bitmap,
>  {
>  assert(bdrv_dirty_bitmap_enabled(bitmap));
>  hbitmap_reset(bitmap->bitmap, cur_sector, nr_sectors);
> +if (bitmap->meta_bitmap) {
> +hbitmap_set(bitmap->meta_bitmap, cur_sector, nr_sectors);
> +}
>  }
>  
>  void bdrv_clear_dirty_bitmap(BdrvDirtyBitmap *bitmap)
> diff --git a/include/block/block.h b/include/block/block.h
> index 5b9c2d6..7deb8e8 100644
> --- a/include/block/block.h
> +++ b/include/block/block.h
> @@ -5,6 +5,7 @@
>  #include "qemu-common.h"
>  #include "qemu/option.h"
>  #include "qemu/coroutine.h"
> +#include "qemu/hbitmap.h"
>  #include "block/accounting.h"
>  #include "qapi/qmp/qobject.h"
>  #include "qapi-types.h"
> @@ -511,6 +512,12 @@ void 
> bdrv_dirty_bitmap_deserialize_zeroes(BdrvDirtyBitmap *bitmap,
>uint64_t start, uint64_t count);
>  void bdrv_dirty_bitmap_deserialize_finish(BdrvDirtyBitmap *bitmap);
>  
> +/* chunk size here is number of bytes of the @bitmap data per one bit of the
> + * meta bitmap being created */
> +HBitmap *bdrv_create_meta_bitmap(BdrvDirtyBitmap *bitmap,
> + uint64_t granularity);
> +void bdrv_release_meta_bitmap(BdrvDirtyBitmap 

[Qemu-devel] [PATCH QEMU-XEN v6 8/8] xen: make it possible to build without the Xen PV domain builder

2015-12-03 Thread Ian Campbell
Until the previous patch this relied on xc_fd(), which was only
implemented for Xen 4.0 and earlier.

Given this wasn't working since Xen 4.0 I have marked this as disabled
by default.

Removing this support drops the use of a bunch of symbols from
libxenctrl, specifically:

  - xc_domain_create
  - xc_domain_destroy
  - xc_domain_getinfo
  - xc_domain_max_vcpus
  - xc_domain_setmaxmem
  - xc_domain_unpause
  - xc_evtchn_alloc_unbound
  - xc_linux_build

This is another step towards only using Xen libraries which provide a
stable inteface.

Signed-off-by: Ian Campbell 
Reviewed-by: Stefano Stabellini 
---
v6: Rebase onto "xen: fix usage of xc_domain_create in domain
builder" (trivial, Reviewed-by retained)

v5: XEN_CREATE entirely wihtin CONFIG_XEN_PV_DOMAIN_BUILD ifdef.
Simplify configure'ry.

v4: Fixed all checkpatch errors.
Disabled by default.
---
 configure   | 15 +++
 hw/xenpv/Makefile.objs  |  4 +++-
 hw/xenpv/xen_machine_pv.c   | 15 +++
 include/hw/xen/xen_common.h |  4 
 4 files changed, 33 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index cb72115..1d27289 100755
--- a/configure
+++ b/configure
@@ -250,6 +250,7 @@ vnc_jpeg=""
 vnc_png=""
 xen=""
 xen_ctrl_version=""
+xen_pv_domain_build="no"
 xen_pci_passthrough=""
 linux_aio=""
 cap_ng=""
@@ -925,6 +926,10 @@ for opt do
   ;;
   --enable-xen-pci-passthrough) xen_pci_passthrough="yes"
   ;;
+  --disable-xen-pv-domain-build) xen_pv_domain_build="no"
+  ;;
+  --enable-xen-pv-domain-build) xen_pv_domain_build="yes"
+  ;;
   --disable-brlapi) brlapi="no"
   ;;
   --enable-brlapi) brlapi="yes"
@@ -2199,6 +2204,12 @@ if test "$xen_pci_passthrough" != "no"; then
   fi
 fi
 
+if test "$xen_pv_domain_build" = "yes" &&
+   test "$xen" != "yes"; then
+error_exit "User requested Xen PV domain builder support" \
+  "which requires Xen support."
+fi
+
 ##
 # libtool probe
 
@@ -4806,6 +4817,7 @@ fi
 echo "xen support   $xen"
 if test "$xen" = "yes" ; then
   echo "xen ctrl version  $xen_ctrl_version"
+  echo "pv dom build  $xen_pv_domain_build"
 fi
 echo "brlapi support$brlapi"
 echo "bluez  support$bluez"
@@ -5174,6 +5186,9 @@ fi
 if test "$xen" = "yes" ; then
   echo "CONFIG_XEN_BACKEND=y" >> $config_host_mak
   echo "CONFIG_XEN_CTRL_INTERFACE_VERSION=$xen_ctrl_version" >> 
$config_host_mak
+  if test "$xen_pv_domain_build" = "yes" ; then
+echo "CONFIG_XEN_PV_DOMAIN_BUILD=y" >> $config_host_mak
+  fi
 fi
 if test "$linux_aio" = "yes" ; then
   echo "CONFIG_LINUX_AIO=y" >> $config_host_mak
diff --git a/hw/xenpv/Makefile.objs b/hw/xenpv/Makefile.objs
index 49f6e9e..bbf5873 100644
--- a/hw/xenpv/Makefile.objs
+++ b/hw/xenpv/Makefile.objs
@@ -1,2 +1,4 @@
 # Xen PV machine support
-obj-$(CONFIG_XEN) += xen_domainbuild.o xen_machine_pv.o
+obj-$(CONFIG_XEN) += xen_machine_pv.o
+# Xen PV machine builder support
+obj-$(CONFIG_XEN_PV_DOMAIN_BUILD) += xen_domainbuild.o
diff --git a/hw/xenpv/xen_machine_pv.c b/hw/xenpv/xen_machine_pv.c
index 23d6ef0..3250b94 100644
--- a/hw/xenpv/xen_machine_pv.c
+++ b/hw/xenpv/xen_machine_pv.c
@@ -30,9 +30,6 @@
 
 static void xen_init_pv(MachineState *machine)
 {
-const char *kernel_filename = machine->kernel_filename;
-const char *kernel_cmdline = machine->kernel_cmdline;
-const char *initrd_filename = machine->initrd_filename;
 DriveInfo *dinfo;
 int i;
 
@@ -46,17 +43,27 @@ static void xen_init_pv(MachineState *machine)
 case XEN_ATTACH:
 /* nothing to do, xend handles everything */
 break;
-case XEN_CREATE:
+#ifdef CONFIG_XEN_PV_DOMAIN_BUILD
+case XEN_CREATE: {
+const char *kernel_filename = machine->kernel_filename;
+const char *kernel_cmdline = machine->kernel_cmdline;
+const char *initrd_filename = machine->initrd_filename;
 if (xen_domain_build_pv(kernel_filename, initrd_filename,
 kernel_cmdline) < 0) {
 fprintf(stderr, "xen pv domain creation failed\n");
 exit(1);
 }
 break;
+}
+#endif
 case XEN_EMULATE:
 fprintf(stderr, "xen emulation not implemented (yet)\n");
 exit(1);
 break;
+default:
+fprintf(stderr, "unhandled xen_mode %d\n", xen_mode);
+exit(1);
+break;
 }
 
 xen_be_register("console", _console_ops);
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 206c188..54a9a7f 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -528,6 +528,8 @@ static inline int xen_xc_domain_add_to_physmap(XenXC xch, 
uint32_t domid,
 }
 #endif
 
+#ifdef CONFIG_XEN_PV_DOMAIN_BUILD
+
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 470
 static inline int xen_domain_create(XenXC xc, uint32_t ssidref,
 xen_domain_handle_t handle, uint32_t 

[Qemu-devel] [PATCH QEMU-XEN v6 3/8] xen: Switch to libxengnttab interface for compat shims.

2015-12-03 Thread Ian Campbell
In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.

One such library will be libxengnttab which provides access to grant
tables.

In preparation for this switch the compatibility layer in xen_common.h
(which support building with older versions of Xen) to use what will
be the new library API. This means that the gnttab shim will disappear
for versions of Xen which include libxengnttab.

To simplify things for the <= 4.0.0 support we wrap the int fd in a
malloc(sizeof int) such that the handle is always a pointer. This
leads to less typedef headaches and the need for
XC_HANDLER_INITIAL_VALUE etc for these interfaces.

Note that this patch does not add any support for actually using
libxengnttab, it just adjusts the existing shims.

Signed-off-by: Ian Campbell 
Reviewed-by: Stefano Stabellini 
---
v4: Ran checkpatch, fixed all errors
Allocate correct size for handle (i.e. not size of the ptr)
Rebase onto "xen_console: correctly cleanup primary console on
teardown."

v5: Rebase over b4f72e31b924 "hw/net/xen_nic.c: Free 'netdev->txs'
when map 'netdev->rxs' fails" which added a new gnttab_munmap.
---
 hw/block/xen_disk.c  | 38 --
 hw/char/xen_console.c|  4 ++--
 hw/net/xen_nic.c | 18 +-
 hw/xen/xen_backend.c | 10 +-
 include/hw/xen/xen_backend.h |  2 +-
 include/hw/xen/xen_common.h  | 42 --
 6 files changed, 69 insertions(+), 45 deletions(-)

diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c
index 8146650..12c01b6 100644
--- a/hw/block/xen_disk.c
+++ b/hw/block/xen_disk.c
@@ -171,11 +171,11 @@ static gint int_cmp(gconstpointer a, gconstpointer b, 
gpointer user_data)
 static void destroy_grant(gpointer pgnt)
 {
 PersistentGrant *grant = pgnt;
-XenGnttab gnt = grant->blkdev->xendev.gnttabdev;
+xengnttab_handle *gnt = grant->blkdev->xendev.gnttabdev;
 
-if (xc_gnttab_munmap(gnt, grant->page, 1) != 0) {
+if (xengnttab_munmap(gnt, grant->page, 1) != 0) {
 xen_be_printf(>blkdev->xendev, 0,
-  "xc_gnttab_munmap failed: %s\n",
+  "xengnttab_munmap failed: %s\n",
   strerror(errno));
 }
 grant->blkdev->persistent_gnt_count--;
@@ -188,11 +188,11 @@ static void remove_persistent_region(gpointer data, 
gpointer dev)
 {
 PersistentRegion *region = data;
 struct XenBlkDev *blkdev = dev;
-XenGnttab gnt = blkdev->xendev.gnttabdev;
+xengnttab_handle *gnt = blkdev->xendev.gnttabdev;
 
-if (xc_gnttab_munmap(gnt, region->addr, region->num) != 0) {
+if (xengnttab_munmap(gnt, region->addr, region->num) != 0) {
 xen_be_printf(>xendev, 0,
-  "xc_gnttab_munmap region %p failed: %s\n",
+  "xengnttab_munmap region %p failed: %s\n",
   region->addr, strerror(errno));
 }
 xen_be_printf(>xendev, 3,
@@ -327,7 +327,7 @@ err:
 
 static void ioreq_unmap(struct ioreq *ioreq)
 {
-XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
+xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
 int i;
 
 if (ioreq->num_unmap == 0 || ioreq->mapped == 0) {
@@ -337,8 +337,9 @@ static void ioreq_unmap(struct ioreq *ioreq)
 if (!ioreq->pages) {
 return;
 }
-if (xc_gnttab_munmap(gnt, ioreq->pages, ioreq->num_unmap) != 0) {
-xen_be_printf(>blkdev->xendev, 0, "xc_gnttab_munmap failed: 
%s\n",
+if (xengnttab_munmap(gnt, ioreq->pages, ioreq->num_unmap) != 0) {
+xen_be_printf(>blkdev->xendev, 0,
+  "xengnttab_munmap failed: %s\n",
   strerror(errno));
 }
 ioreq->blkdev->cnt_map -= ioreq->num_unmap;
@@ -348,8 +349,9 @@ static void ioreq_unmap(struct ioreq *ioreq)
 if (!ioreq->page[i]) {
 continue;
 }
-if (xc_gnttab_munmap(gnt, ioreq->page[i], 1) != 0) {
-xen_be_printf(>blkdev->xendev, 0, "xc_gnttab_munmap 
failed: %s\n",
+if (xengnttab_munmap(gnt, ioreq->page[i], 1) != 0) {
+xen_be_printf(>blkdev->xendev, 0,
+  "xengnttab_munmap failed: %s\n",
   strerror(errno));
 }
 ioreq->blkdev->cnt_map--;
@@ -361,7 +363,7 @@ static void ioreq_unmap(struct ioreq *ioreq)
 
 static int ioreq_map(struct ioreq *ioreq)
 {
-XenGnttab gnt = ioreq->blkdev->xendev.gnttabdev;
+xengnttab_handle *gnt = ioreq->blkdev->xendev.gnttabdev;
 uint32_t domids[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 uint32_t refs[BLKIF_MAX_SEGMENTS_PER_REQUEST];
 void *page[BLKIF_MAX_SEGMENTS_PER_REQUEST];
@@ -412,7 +414,7 @@ static int ioreq_map(struct ioreq *ioreq)
 }
 
 if 

[Qemu-devel] [PATCH QEMU-XEN v6 4/8] xen: Switch uses of xc_map_foreign_range into xc_map_foreign_pages

2015-12-03 Thread Ian Campbell
In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.

One such library will be libxenforeignmemory which provides access to
privileged foreign mappings and which will provide an interface
equivalent to xc_map_foreign_{pages,bulk}.

In preparation for this switch all uses of xc_map_foreign_range to
xc_map_foreign_pages. This is trivial because size was always
XC_PAGE_SIZE so the necessary adjustments are trivial:

  * Pass  (an array of length 1) instead of mfn. The function
takes a pointer to const, so there is no possibily of mfn changing
due to this change.
  * Pass nr_pages=1 instead of size=XC_PAGE_SIZE

There is one wrinkle in xen_console.c:con_initialise() where
con->ring_ref is an int but can in some code paths (when !xendev->dev)
be treated as an mfn. I think this is an existing latent truncation
hazard on platforms where xen_pfn_t is 64-bit and int is 32-bit (e.g.
amd64, both arm* variants). I'm unsure under what circumstances
xendev->dev can be NULL or if anything elsewhere ensures the value
fits into an int. For now I just use a temporary xen_pfn_t to in
effect upcast the pointer from int* to xen_pfn_t*.

Signed-off-by: Ian Campbell 
---
v6: Switch to xc_map_foreign_pages rather than _bulk. Switching to
_bulk without checking the value of err[0] risked missing errors.
The new xenforeignmemory_map coming later in this series will
DTRT with err==NULL.

Dropped Stefano's Reviewed-by due to this change.

v4: Ran checkpatch, fixed all errors
Mention the const-ness of the mfn array in the commit log
---
 hw/char/xen_console.c |  8 
 hw/display/xenfb.c|  5 ++---
 xen-hvm.c | 14 +++---
 3 files changed, 13 insertions(+), 14 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index 8c06c19..56f1b1a 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -228,10 +228,10 @@ static int con_initialise(struct XenDevice *xendev)
con->buffer.max_capacity = limit;
 
 if (!xendev->dev) {
-con->sring = xc_map_foreign_range(xen_xc, con->xendev.dom,
-  XC_PAGE_SIZE,
-  PROT_READ|PROT_WRITE,
-  con->ring_ref);
+xen_pfn_t mfn = con->ring_ref;
+con->sring = xc_map_foreign_pages(xen_xc, con->xendev.dom,
+ PROT_READ|PROT_WRITE,
+ , 1);
 } else {
 con->sring = xengnttab_map_grant_ref(xendev->gnttabdev, 
con->xendev.dom,
  con->ring_ref,
diff --git a/hw/display/xenfb.c b/hw/display/xenfb.c
index 5e324ef..c96d974 100644
--- a/hw/display/xenfb.c
+++ b/hw/display/xenfb.c
@@ -104,9 +104,8 @@ static int common_bind(struct common *c)
 if (xenstore_read_fe_int(>xendev, "event-channel", 
>xendev.remote_port) == -1)
return -1;
 
-c->page = xc_map_foreign_range(xen_xc, c->xendev.dom,
-  XC_PAGE_SIZE,
-  PROT_READ | PROT_WRITE, mfn);
+c->page = xc_map_foreign_pages(xen_xc, c->xendev.dom,
+   PROT_READ | PROT_WRITE, , 1);
 if (c->page == NULL)
return -1;
 
diff --git a/xen-hvm.c b/xen-hvm.c
index 6680782..2f4e109 100644
--- a/xen-hvm.c
+++ b/xen-hvm.c
@@ -1240,8 +1240,9 @@ int xen_hvm_init(PCMachineState *pcms,
 DPRINTF("buffered io page at pfn %lx\n", bufioreq_pfn);
 DPRINTF("buffered io evtchn is %x\n", bufioreq_evtchn);
 
-state->shared_page = xc_map_foreign_range(xen_xc, xen_domid, XC_PAGE_SIZE,
-  PROT_READ|PROT_WRITE, ioreq_pfn);
+state->shared_page = xc_map_foreign_pages(xen_xc, xen_domid,
+  PROT_READ|PROT_WRITE,
+  _pfn, 1);
 if (state->shared_page == NULL) {
 hw_error("map shared IO page returned error %d handle=" 
XC_INTERFACE_FMT,
  errno, xen_xc);
@@ -1251,8 +1252,8 @@ int xen_hvm_init(PCMachineState *pcms,
 if (!rc) {
 DPRINTF("shared vmport page at pfn %lx\n", ioreq_pfn);
 state->shared_vmport_page =
-xc_map_foreign_range(xen_xc, xen_domid, XC_PAGE_SIZE,
- PROT_READ|PROT_WRITE, ioreq_pfn);
+xc_map_foreign_pages(xen_xc, xen_domid, PROT_READ|PROT_WRITE,
+ _pfn, 1);
 if (state->shared_vmport_page == NULL) {
 hw_error("map shared vmport IO page returned error %d handle="
  XC_INTERFACE_FMT, errno, xen_xc);
@@ -1261,10 +1262,9 @@ int xen_hvm_init(PCMachineState *pcms,
 hw_error("get vmport regs pfn returned error %d, rc=%d", errno, rc);
 }
 
-state->buffered_io_page = 

[Qemu-devel] [PATCH QEMU-XEN v6 7/8] xen: domainbuild: reopen libxenctrl interface after forking for domain watcher.

2015-12-03 Thread Ian Campbell
Using an existing libxenctrl handle after a fork was never
particularly safe (especially if foreign mappings existed at the time
of the fork) and the xc fd has been unavailable for many releases.

Reopen the handle after fork and therefore do away with xc_fd().

Signed-off-by: Ian Campbell 
Acked-by: Stefano Stabellini 
---
The fact that xc_fd hasn't been useful since at least Xen 4.1 makes me
question the utility of this domainbuild in QEMU. Perhaps we should
just nuke it?
---
 hw/xenpv/xen_domainbuild.c  |  9 ++---
 include/hw/xen/xen_common.h | 17 -
 2 files changed, 6 insertions(+), 20 deletions(-)

diff --git a/hw/xenpv/xen_domainbuild.c b/hw/xenpv/xen_domainbuild.c
index ac0e5ac..f9be029 100644
--- a/hw/xenpv/xen_domainbuild.c
+++ b/hw/xenpv/xen_domainbuild.c
@@ -174,12 +174,15 @@ static int xen_domain_watcher(void)
 for (i = 3; i < n; i++) {
 if (i == fd[0])
 continue;
-if (i == xc_fd(xen_xc)) {
-continue;
-}
 close(i);
 }
 
+/*
+ * Reopen xc interface, since the original is unsafe after fork
+ * and was closed above.
+ */
+xen_xc = xc_interface_open(0, 0, 0);
+
 /* ignore term signals */
 signal(SIGINT,  SIG_IGN);
 signal(SIGTERM, SIG_IGN);
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 884fbd1..206c188 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -127,12 +127,6 @@ static inline void *xenforeignmemory_map(XenXC *h, 
uint32_t dom,
 }
 #define xenforeignmemory_unmap(h, p, s) munmap(p, s * XC_PAGE_SIZE)
 
-static inline int xc_fd(int xen_xc)
-{
-return xen_xc;
-}
-
-
 static inline int xc_domain_populate_physmap_exact
 (XenXC xc_handle, uint32_t domid, unsigned long nr_extents,
  unsigned int extent_order, unsigned int mem_flags, xen_pfn_t 
*extent_start)
@@ -216,11 +210,6 @@ static inline void *xenforeignmemory_map(XenXC *h, 
uint32_t dom,
 
 #define xenforeignmemory_unmap(h, p, s) munmap(p, s * XC_PAGE_SIZE)
 
-/* FIXME There is no way to have the xen fd */
-static inline int xc_fd(xc_interface *xen_xc)
-{
-return -1;
-}
 #else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 470 */
 
 typedef xc_interface *XenXC;
@@ -237,12 +226,6 @@ static inline XenXC xen_xc_interface_open(void *logger, 
void *dombuild_logger,
 {
 return xc_interface_open(logger, dombuild_logger, open_flags);
 }
-
-/* FIXME There is now way to have the xen fd */
-static inline int xc_fd(xc_interface *xen_xc)
-{
-return -1;
-}
 #endif
 
 /* Xen before 4.2 */
-- 
2.1.4




Re: [Qemu-devel] [PULL for-2.5 0/4] Block patches

2015-12-03 Thread Peter Maydell
On 3 December 2015 at 04:59, Stefan Hajnoczi  wrote:
> The following changes since commit cf22132367a188426ac07cf1805b214dd2d0cc80:
>
>   Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging 
> (2015-12-02 17:05:34 +)
>
> are available in the git repository at:
>
>   git://github.com/stefanha/qemu.git tags/block-pull-request
>
> for you to fetch changes up to 9cc0f19de213fcb7098f0ea8f42448728f2cfcde:
>
>   iotests: Add regresion test case for write notifier assertion failure 
> (2015-12-03 11:08:07 +0800)
>
> 
>
> 
>
> Fam Zheng (3):
>   block: Don't wait serialising for non-COR read requests
>   iotests: Add "add_drive_raw" method
>   iotests: Add regresion test case for write notifier assertion failure
>
> Paolo Bonzini (1):
>   iothread: include id in thread name
>

Applied, thanks.

-- PMM



Re: [Qemu-devel] MinGW build

2015-12-03 Thread Peter Maydell
On 29 November 2015 at 12:03, Juan Quintela  wrote:
> Peter Maydell  wrote:
>> Yes, I've reported it to them, and I agree we don't need to fix
>> this for 2.5. (There are other warnings with this mingw compiler
>> anyway.)
>
> For my compiler (F23 cross-compiler) and a fairly large configuration (*)
> this is the only warning.

The others I see are:

  CCqga/commands.o
In file included from
/home/petmay01/linaro/mingw64/lib/glib-2.0/include/glibconfig.h:9:0,
 from
/home/petmay01/linaro/mingw64/include/glib-2.0/glib/gtypes.h:34,
 from
/home/petmay01/linaro/mingw64/include/glib-2.0/glib/galloca.h:34,
 from /home/petmay01/linaro/mingw64/include/glib-2.0/glib.h:32,
 from /home/petmay01/linaro/qemu-for-merges/qga/commands.c:13:
/home/petmay01/linaro/qemu-for-merges/qga/commands.c: In function
‘qmp_guest_exec_status’:
/home/petmay01/linaro/mingw64/include/glib-2.0/glib/gmacros.h:162:53:
error: typedef ‘_GStaticAssertCompileTimeAssertion_0’ locally defined
but not used [-Werror=unused-local-typedefs]
 #define G_STATIC_ASSERT(expr) typedef char G_PASTE
(_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1]
 ^
/home/petmay01/linaro/mingw64/include/glib-2.0/glib/gmacros.h:159:47:
note: in definition of macro ‘G_PASTE_ARGS’
 #define G_PASTE_ARGS(identifier1,identifier2) identifier1 ## identifier2
   ^
/home/petmay01/linaro/mingw64/include/glib-2.0/glib/gmacros.h:162:44:
note: in expansion of macro ‘G_PASTE’
 #define G_STATIC_ASSERT(expr) typedef char G_PASTE
(_GStaticAssertCompileTimeAssertion_, __COUNTER__)[(expr) ? 1 : -1]
^
/home/petmay01/linaro/mingw64/include/glib-2.0/glib/gatomic.h:79:5:
note: in expansion of macro ‘G_STATIC_ASSERT’
 G_STATIC_ASSERT (sizeof *(atomic) == sizeof (gint)); \
 ^
/home/petmay01/linaro/qemu-for-merges/qga/commands.c:157:21: note: in
expansion of macro ‘g_atomic_int_get’
 bool finished = g_atomic_int_get(>finished);
 ^

(and similar others in this file).

thanks
-- PMM



[Qemu-devel] [PATCH v2] gdb: provide the name of the architecture in the target.xml

2015-12-03 Thread Christian Borntraeger
From: David Hildenbrand 

This patch provides the name of the architecture in the target.xml
if available.

This allows the remote gdb to detect the target architecture on its
own - so there is no need to specify it manually (e.g. if gdb is
started without a binary) using "set arch *arch_name*".

The name of the architecture is provided by a callback that can
be implemented by all architectures. The arm implementation has
special handling for iwmmxt and returns arm otherwise. This can
be extended if necessary.

Signed-off-by: David Hildenbrand 
Acked-by: Cornelia Huck 
Signed-off-by: Christian Borntraeger 
[rework to use a callback]
---
v1->v2: replace the fixed string with a callback

 gdbstub.c   | 21 ++---
 include/qom/cpu.h   |  3 +++
 target-arm/cpu.c| 12 
 target-arm/cpu64.c  |  6 ++
 target-ppc/translate_init.c | 10 ++
 target-s390x/cpu.c  |  6 ++
 6 files changed, 51 insertions(+), 7 deletions(-)

diff --git a/gdbstub.c b/gdbstub.c
index 9c29aa0..6a674b2 100644
--- a/gdbstub.c
+++ b/gdbstub.c
@@ -540,13 +540,20 @@ static const char *get_feature_xml(const char *p, const 
char **newp,
 GDBRegisterState *r;
 CPUState *cpu = first_cpu;
 
-snprintf(target_xml, sizeof(target_xml),
- ""
- ""
- ""
- "",
- cc->gdb_core_xml_file);
-
+pstrcat(target_xml, sizeof(target_xml),
+""
+""
+"");
+if (cc->gdb_arch_name) {
+gchar *arch = cc->gdb_arch_name(cpu);
+pstrcat(target_xml, sizeof(target_xml), "");
+pstrcat(target_xml, sizeof(target_xml), arch);
+pstrcat(target_xml, sizeof(target_xml), "");
+   g_free(arch);
+}
+pstrcat(target_xml, sizeof(target_xml), "gdb_core_xml_file);
+pstrcat(target_xml, sizeof(target_xml), "\"/>");
 for (r = cpu->gdb_regs; r; r = r->next) {
 pstrcat(target_xml, sizeof(target_xml), "xml);
diff --git a/include/qom/cpu.h b/include/qom/cpu.h
index 51a1323..c3c2812 100644
--- a/include/qom/cpu.h
+++ b/include/qom/cpu.h
@@ -114,6 +114,8 @@ struct TranslationBlock;
  * @gdb_core_xml_file: File name for core registers GDB XML description.
  * @gdb_stop_before_watchpoint: Indicates whether GDB expects the CPU to stop
  *   before the insn which triggers a watchpoint rather than after it.
+ * @gdb_arch_name: Optional callback that returns the architecture name known
+ * to GDB. The caller must free the returned string with g_free.
  * @cpu_exec_enter: Callback for cpu_exec preparation.
  * @cpu_exec_exit: Callback for cpu_exec cleanup.
  * @cpu_exec_interrupt: Callback for processing interrupts in cpu_exec.
@@ -168,6 +170,7 @@ typedef struct CPUClass {
 const struct VMStateDescription *vmsd;
 int gdb_num_core_regs;
 const char *gdb_core_xml_file;
+gchar * (*gdb_arch_name)(CPUState *cpu);
 bool gdb_stop_before_watchpoint;
 
 void (*cpu_exec_enter)(CPUState *cpu);
diff --git a/target-arm/cpu.c b/target-arm/cpu.c
index 30739fc..771cf91 100644
--- a/target-arm/cpu.c
+++ b/target-arm/cpu.c
@@ -1393,6 +1393,17 @@ static int arm_cpu_handle_mmu_fault(CPUState *cs, vaddr 
address, int rw,
 }
 #endif
 
+static gchar *arm_gdb_arch_name(CPUState *cs)
+{
+ARMCPU *cpu = ARM_CPU(cs);
+CPUARMState *env = >env;
+
+if (arm_feature(env, ARM_FEATURE_IWMMXT)) {
+return g_strdup("iwmmxt");
+}
+return g_strdup("arm");
+}
+
 static void arm_cpu_class_init(ObjectClass *oc, void *data)
 {
 ARMCPUClass *acc = ARM_CPU_CLASS(oc);
@@ -1423,6 +1434,7 @@ static void arm_cpu_class_init(ObjectClass *oc, void 
*data)
 #endif
 cc->gdb_num_core_regs = 26;
 cc->gdb_core_xml_file = "arm-core.xml";
+cc->gdb_arch_name = arm_gdb_arch_name;
 cc->gdb_stop_before_watchpoint = true;
 cc->debug_excp_handler = arm_debug_excp_handler;
 
diff --git a/target-arm/cpu64.c b/target-arm/cpu64.c
index 63c8b1c..ad1991d 100644
--- a/target-arm/cpu64.c
+++ b/target-arm/cpu64.c
@@ -286,6 +286,11 @@ static void aarch64_cpu_set_pc(CPUState *cs, vaddr value)
 }
 }
 
+static gchar *aarch64_gdb_arch_name(CPUState *cs)
+{
+return g_strdup("aarch64");
+}
+
 static void aarch64_cpu_class_init(ObjectClass *oc, void *data)
 {
 CPUClass *cc = CPU_CLASS(oc);
@@ -299,6 +304,7 @@ static void aarch64_cpu_class_init(ObjectClass *oc, void 
*data)
 cc->gdb_write_register = aarch64_cpu_gdb_write_register;
 cc->gdb_num_core_regs = 34;
 cc->gdb_core_xml_file = "aarch64-core.xml";
+cc->gdb_arch_name = aarch64_gdb_arch_name;
 }
 
 static void aarch64_cpu_register(const ARMCPUInfo *info)
diff --git 

[Qemu-devel] [PATCH QEMU-XEN v6 2/8] xen: Switch to libxenevtchn interface for compat shims.

2015-12-03 Thread Ian Campbell
In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.

One such library will be libxenevtchn which provides access to event
channels.

In preparation for this switch the compatibility layer in xen_common.h
(which support building with older versions of Xen) to use what will
be the new library API. This means that the evtchn shim will disappear
for versions of Xen which include libxenevtchn.

To simplify things for the <= 4.0.0 support we wrap the int fd in a
malloc(sizeof int) such that the handle is always a pointer. This
leads to less typedef headaches and the need for
XC_HANDLER_INITIAL_VALUE etc for these interfaces.

Note that this patch does not add any support for actually using
libxenevtchn, it just adjusts the existing shims.

Note that xc_evtchn_alloc_unbound functionality remains in libxenctrl,
since that functionality is not exposed by /dev/xen/evtchn.

Signed-off-by: Ian Campbell 
Reviewed-by: Stefano Stabellini 
---
v4: Ran checkpatch, fixed all errors
Allocate correct size for handle (i.e. not size of the ptr)
---
 hw/xen/xen_backend.c | 31 ---
 include/hw/xen/xen_backend.h |  2 +-
 include/hw/xen/xen_common.h  | 44 ++--
 xen-hvm.c| 25 +
 4 files changed, 64 insertions(+), 38 deletions(-)

diff --git a/hw/xen/xen_backend.c b/hw/xen/xen_backend.c
index 2510e2e..ae2a1f0 100644
--- a/hw/xen/xen_backend.c
+++ b/hw/xen/xen_backend.c
@@ -243,19 +243,19 @@ static struct XenDevice *xen_be_get_xendev(const char 
*type, int dom, int dev,
 xendev->debug  = debug;
 xendev->local_port = -1;
 
-xendev->evtchndev = xen_xc_evtchn_open(NULL, 0);
-if (xendev->evtchndev == XC_HANDLER_INITIAL_VALUE) {
+xendev->evtchndev = xenevtchn_open(NULL, 0);
+if (xendev->evtchndev == NULL) {
 xen_be_printf(NULL, 0, "can't open evtchn device\n");
 g_free(xendev);
 return NULL;
 }
-fcntl(xc_evtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
+fcntl(xenevtchn_fd(xendev->evtchndev), F_SETFD, FD_CLOEXEC);
 
 if (ops->flags & DEVOPS_FLAG_NEED_GNTDEV) {
 xendev->gnttabdev = xen_xc_gnttab_open(NULL, 0);
 if (xendev->gnttabdev == XC_HANDLER_INITIAL_VALUE) {
 xen_be_printf(NULL, 0, "can't open gnttab device\n");
-xc_evtchn_close(xendev->evtchndev);
+xenevtchn_close(xendev->evtchndev);
 g_free(xendev);
 return NULL;
 }
@@ -306,8 +306,8 @@ static struct XenDevice *xen_be_del_xendev(int dom, int dev)
 g_free(xendev->fe);
 }
 
-if (xendev->evtchndev != XC_HANDLER_INITIAL_VALUE) {
-xc_evtchn_close(xendev->evtchndev);
+if (xendev->evtchndev != NULL) {
+xenevtchn_close(xendev->evtchndev);
 }
 if (xendev->gnttabdev != XC_HANDLER_INITIAL_VALUE) {
 xc_gnttab_close(xendev->gnttabdev);
@@ -691,13 +691,14 @@ static void xen_be_evtchn_event(void *opaque)
 struct XenDevice *xendev = opaque;
 evtchn_port_t port;
 
-port = xc_evtchn_pending(xendev->evtchndev);
+port = xenevtchn_pending(xendev->evtchndev);
 if (port != xendev->local_port) {
-xen_be_printf(xendev, 0, "xc_evtchn_pending returned %d (expected 
%d)\n",
+xen_be_printf(xendev, 0,
+  "xenevtchn_pending returned %d (expected %d)\n",
   port, xendev->local_port);
 return;
 }
-xc_evtchn_unmask(xendev->evtchndev, port);
+xenevtchn_unmask(xendev->evtchndev, port);
 
 if (xendev->ops->event) {
 xendev->ops->event(xendev);
@@ -740,14 +741,14 @@ int xen_be_bind_evtchn(struct XenDevice *xendev)
 if (xendev->local_port != -1) {
 return 0;
 }
-xendev->local_port = xc_evtchn_bind_interdomain
+xendev->local_port = xenevtchn_bind_interdomain
 (xendev->evtchndev, xendev->dom, xendev->remote_port);
 if (xendev->local_port == -1) {
-xen_be_printf(xendev, 0, "xc_evtchn_bind_interdomain failed\n");
+xen_be_printf(xendev, 0, "xenevtchn_bind_interdomain failed\n");
 return -1;
 }
 xen_be_printf(xendev, 2, "bind evtchn port %d\n", xendev->local_port);
-qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev),
+qemu_set_fd_handler(xenevtchn_fd(xendev->evtchndev),
 xen_be_evtchn_event, NULL, xendev);
 return 0;
 }
@@ -757,15 +758,15 @@ void xen_be_unbind_evtchn(struct XenDevice *xendev)
 if (xendev->local_port == -1) {
 return;
 }
-qemu_set_fd_handler(xc_evtchn_fd(xendev->evtchndev), NULL, NULL, NULL);
-xc_evtchn_unbind(xendev->evtchndev, xendev->local_port);
+qemu_set_fd_handler(xenevtchn_fd(xendev->evtchndev), NULL, NULL, NULL);
+xenevtchn_unbind(xendev->evtchndev, 

[Qemu-devel] [PATCH QEMU-XEN v6 6/8] xen: Use stable library interfaces when they are available.

2015-12-03 Thread Ian Campbell
In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.

Specifically libxenevtchn, libxengnttab and libxenforeignmemory.

Previous patches have already laid the groundwork for using these by
switching the existing compatibility shims to reflect the intefaces to
these libraries.

So all which remains is to update configure to detect the libraries
and enable their use. Although they are notionally independent we take
an all or nothing approach to the three libraries since they were
added at the same time.

The only non-obvious bit is that we now open a proper xenforeignmemory
handle for xen_fmem instead of reusing the xen_xc handle.

Build tested with 4.0 .. 4.6 (inclusive) and the patches targetting
4.7 which adds these libraries.

Signed-off-by: Ian Campbell 
---
v6: Two minor formatting things.
Rebase onto "xen: fix usage of xc_domain_create in domain
builder", required adjusting the configure script changes.

The rebase wasn't entirely trivial (semantically), so dropped
Stefano's reviwed by.

v5: Remove ifdef check when undeffing the compat stuff.
s/now way/no way/

v4: xenforeignmemory_open is now a compat wrapper, so no ifdef.

Simplify configury by asserting that interface version 470 will
always have the libraries (lack of them makes it 460).

Ran checkpatch and fixed everything except:

ERROR: need consistent spacing around '*' (ctx:WxV)
+typedef xc_interface *XenXC;

Which I think is a false +ve.

Simpler configure stuff
---
 configure   | 42 +-
 include/hw/xen/xen_common.h | 35 +--
 2 files changed, 74 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index 979bc55..cb72115 100755
--- a/configure
+++ b/configure
@@ -1923,6 +1923,7 @@ fi
 
 if test "$xen" != "no" ; then
   xen_libs="-lxenstore -lxenctrl -lxenguest"
+  xen_stable_libs="-lxenforeignmemory -lxengnttab -lxenevtchn"
 
   # First we test whether Xen headers and libraries are available.
   # If no, we are done and there is no Xen support.
@@ -1945,16 +1946,52 @@ EOF
   # Xen unstable
   elif
   cat > $TMPC <
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#if !defined(HVM_MAX_VCPUS)
+# error HVM_MAX_VCPUS not defined
+#endif
 int main(void) {
   xc_interface *xc = NULL;
+  xenforeignmemory_handle *xfmem;
+  xenevtchn_handle *xe;
+  xengnttab_handle *xg;
   xen_domain_handle_t handle;
+
+  xs_daemon_open();
+
+  xc = xc_interface_open(0, 0, 0);
+  xc_hvm_set_mem_type(0, 0, HVMMEM_ram_ro, 0, 0);
+  xc_domain_add_to_physmap(0, 0, XENMAPSPACE_gmfn, 0, 0);
+  xc_hvm_inject_msi(xc, 0, 0xf000, 0x);
+  xc_hvm_create_ioreq_server(xc, 0, HVM_IOREQSRV_BUFIOREQ_ATOMIC, NULL);
   xc_domain_create(xc, 0, handle, 0, NULL, NULL);
+
+  xfmem = xenforeignmemory_open(0, 0);
+  xenforeignmemory_map(xfmem, 0, 0, 0, 0, 0);
+
+  xe = xenevtchn_open(0, 0);
+  xenevtchn_fd(xe);
+
+  xg = xengnttab_open(0, 0);
+  xengnttab_map_grant_ref(xg, 0, 0, 0);
+
   return 0;
 }
 EOF
-  compile_prog "" "$xen_libs"
+  compile_prog "" "$xen_libs $xen_stable_libs"
 then
 xen_ctrl_version=470
 xen=yes
@@ -2138,6 +2175,9 @@ EOF
   fi
 
   if test "$xen" = yes; then
+if test $xen_ctrl_version -ge 470  ; then
+  libs_softmmu="$xen_stable_libs $libs_softmmu"
+fi
 libs_softmmu="$xen_libs $libs_softmmu"
   fi
 fi
diff --git a/include/hw/xen/xen_common.h b/include/hw/xen/xen_common.h
index 8fbaf07..884fbd1 100644
--- a/include/hw/xen/xen_common.h
+++ b/include/hw/xen/xen_common.h
@@ -6,6 +6,15 @@
 #include 
 #include 
 
+/*
+ * If we have new enough libxenctrl then we do not want/need these compat
+ * interfaces, despite what the user supplied cflags might say. They
+ * must be undefined before including xenctrl.h
+ */
+#undef XC_WANT_COMPAT_EVTCHN_API
+#undef XC_WANT_COMPAT_GNTTAB_API
+#undef XC_WANT_COMPAT_MAP_FOREIGN_API
+
 #include 
 #if CONFIG_XEN_CTRL_INTERFACE_VERSION < 420
 #  include 
@@ -159,8 +168,8 @@ static inline void xs_close(struct xs_handle *xsh)
 }
 
 
-/* Xen 4.1 */
-#else
+/* Xen 4.1 thru 4.6 */
+#elif CONFIG_XEN_CTRL_INTERFACE_VERSION < 470
 
 typedef xc_interface *XenXC;
 typedef xc_interface *xenforeignmemory_handle;
@@ -207,6 +216,28 @@ static inline void *xenforeignmemory_map(XenXC *h, 
uint32_t dom,
 
 #define xenforeignmemory_unmap(h, p, s) munmap(p, s * XC_PAGE_SIZE)
 
+/* FIXME There is no way to have the xen fd */
+static inline int xc_fd(xc_interface *xen_xc)
+{
+return -1;
+}
+#else /* CONFIG_XEN_CTRL_INTERFACE_VERSION >= 470 */
+
+typedef xc_interface *XenXC;
+
+#  define XC_INTERFACE_FMT "%p"
+#  define XC_HANDLER_INITIAL_VALUENULL
+
+#include 
+#include 
+#include 
+
+static inline XenXC xen_xc_interface_open(void *logger, void *dombuild_logger,
+  unsigned int open_flags)
+{
+

[Qemu-devel] [PATCH QEMU-XEN v6 5/8] xen: Switch uses of xc_map_foreign_{pages, bulk} to use libxenforeignmemory API.

2015-12-03 Thread Ian Campbell
In Xen 4.7 we are refactoring parts libxenctrl into a number of
separate libraries which will provide backward and forward API and ABI
compatiblity.

One such library will be libxenforeignmemory which provides access to
privileged foreign mappings and which will provide an interface
equivalent to xc_map_foreign_{pages,bulk}.

The new xenforeignmemory_map() function behaves like
xc_map_foreign_pages() when the err argument is NULL and like
xc_map_foreign_bulk() when err is non-NULL, which maps into the shim
here onto checking err == NULL and calling the appropriate old
function.

Note that xenforeignmemory_map() takes the number of pages before the
arrays themselves, in order to support potentially future use of
variable-length-arrays in the prototype (in the future, when Xen's
baseline toolchain requirements are new enough to ensure VLAs are
supported).

In preparation for adding support for libxenforeignmemory add support
to the <=4.0 and <=4.6 compat code in xen_common.h to allow us to
switch to using the new API. These shims will disappear for versions
of Xen which include libxenforeignmemory.

Since libxenforeignmemory will have its own handle type but for <= 4.6
the functionality is provided by using a libxenctrl handle we
introduce a new global xen_fmem alongside the existing xen_xc. In fact
we make xen_fmem a pointer to the existing xen_xc, which then works
correctly with both <=4.0 (xc handle is an int) and <=4.6 (xc handle
is a pointer). In the latter case xen_fmem is actually a double
indirect pointer, but it all falls out in the wash.

Unlike libxenctrl libxenforeignmemory has an explicit unmap function,
rather than just specifying that munmap should be used, so the unmap
paths are updated to use xenforeignmemory_unmap, which is a shim for
munmap on these versions of xen. The mappings in xen-hvm.c do not
appear to be unmapped (which makes sense for a qemu-dm process)

In fb_disconnect this results in a change from simply mmap over the
existing mapping (with an implicit munmap) to expliclty unmapping with
xenforeignmemory_unmap and then mapping the required anonymous memory
in the same hole. I don't think this is a problem since any other
thread which was racily touching this region would already be running
the risk of hitting the mapping halfway through the call. If this is
thought to be a problem then we could consider adding an extra API to
the libxenforeignmemory interface to replace a foreign mapping with
anonymous shared memory, but I'd prefer not to.

Signed-off-by: Ian Campbell 
---
v6: Handle _pages as well as _bulk, due to changes in the previous
patches, including the dropping of "xen: Switch uses of
xc_map_foreign_pages into xc_map_foreign_bulk" which previous preceded
this patch and the change of "xen: Switch uses of
xc_map_foreign_range into xc_map_foreign_bulk" into "xen: Switch
uses of xc_map_foreign_range into xc_map_foreign_pages".

Handle reordering of arguments to xenforeignmemory_map().

Dropped Stefano's Reviewed-by due to these changes.

v4: Rebase onto "xen_console: correctly cleanup primary console on
teardown."

xenforeignmemory_unmap takes pages not bytes

Compat wrapper for xenforeignmemory_open instead of ifdef in code.

Run check patch and fix most issues. I did not fix:

ERROR: do not initialise globals to 0 or NULL
+xenforeignmemory_handle *xen_fmem = NULL;

=> This is consistent with all of the existing declarations.

ERROR: need consistent spacing around '*' (ctx:WxV)
+typedef xc_interface *xenforeignmemory_handle;

=> I think this is a false +ve since this is a pointer "*" not a multiple "*".

reorder args to xenforeignmemory_map
---
 hw/char/xen_console.c|  8 
 hw/display/xenfb.c   | 17 +
 hw/xen/xen_backend.c |  3 ++-
 include/hw/xen/xen_backend.h |  1 +
 include/hw/xen/xen_common.h  | 29 +
 xen-common.c |  6 ++
 xen-hvm.c| 12 ++--
 xen-mapcache.c   |  6 +++---
 8 files changed, 60 insertions(+), 22 deletions(-)

diff --git a/hw/char/xen_console.c b/hw/char/xen_console.c
index 56f1b1a..788dd31 100644
--- a/hw/char/xen_console.c
+++ b/hw/char/xen_console.c
@@ -229,9 +229,9 @@ static int con_initialise(struct XenDevice *xendev)
 
 if (!xendev->dev) {
 xen_pfn_t mfn = con->ring_ref;
-con->sring = xc_map_foreign_pages(xen_xc, con->xendev.dom,
- PROT_READ|PROT_WRITE,
- , 1);
+con->sring = xenforeignmemory_map(xen_fmem, con->xendev.dom,
+  PROT_READ|PROT_WRITE,
+  1, , NULL);
 } else {
 con->sring = xengnttab_map_grant_ref(xendev->gnttabdev, 
con->xendev.dom,
  con->ring_ref,
@@ -273,7 +273,7 @@ static void 

Re: [Qemu-devel] [PATCH] vfio: Align iova also to IOMMU page size

2015-12-03 Thread Pavel Fedin
 Hello!

> >  My device defines this BAR to be of 2M size. In this case qemu splits it 
> > up into three
> > regions:
> >  1) Region below the MSI-X table (it's called "mmap", for me it's empty 
> > because table offset
> > is 0)
> >  2) MSI-X table itself (20 vectors = 0x0140 bytes for me).
> >  3) Region above the MSi-X table (it's called "mmap msix-hi"). Size for my 
> > case is 2M -
> > REAL_HOST_PAGE_ALIGN(0x140) = 0x1FF000.
> > Regions (1) and (3) are passed through and directly mapped by VFIO, region 
> > (2) is emulated.
> >  Now, we have PBA. The device says that PBA is placed in memory specified 
> > by the same BAR as
> > table, and its offset is 0x000f. PBA is also emulated by qemu, and as a 
> > result it overlaps
> > "mmap msix-hi" region, which breaks up into two fragments as a consequence:
> >  3a) offset 0x0 size 0x0EF000
> >  3b) offset 0xEF008 size 0x10FFF8
> >  PBA sits between these fragments, having only 8 bytes in size.
> >  Attempt to map (3b) causes the problem. vfio_mmap_region() is expected to 
> > align this up,
> > and it does, but it does it to a minimum possible granularity for ARM 
> > platform, which, as qemu
> > thinks, is always 1K.
> 
> Yep, on x86 we'd have target page size == host page size == minimum
> iommu page size and we'd align that up to something that can be mapped,
> which means we wouldn't have an iommu mapping for peer-to-peer in this
> space, but nobody is likely to notice.

 So, OK, to keep the quoting short... I've also read your previous reply about 
that "rounding up just works". Let's sum things up.

1. Rounding up "just works" in my case too. So i don't see a direct reason to 
change it.
2. The only problem is rounding up to 1K, which TARGET_PAGE_ALIGN() does on 
ARM. What we need is 4K,
   which is appropriate for host too. And, by the way, for modern ARM guests 
too. So, we can do either of:
   a) Keep my original approach - TARGET_PAGE_ALIGN(), then align to 
vfio_container_granularity().
   b) Just align to vfio_container_granularity() instead of using 
TARGET_PAGE_ALIGN().
   c) Use HOST_PAGE_ALIGN() instead of TARGET_PAGE_ALIGN() (what Peter 
suggested).

   On x86 there would be no difference, because all these alignments are 
identical. On ARM, actually, all of these approaches would also give correct 
result, because it's only TARGET_PAGE_ALIGN() wrong in this case. So - what do 
you think is the most appropriate? Let's make a choice and i'll send a proper 
patch.

Kind regards,
Pavel Fedin
Expert Engineer
Samsung Electronics Research center Russia





Re: [Qemu-devel] [TCG only][Migration Bug? ] Occasionally, the content of VM's memory is inconsistent between Source and Destination of migration

2015-12-03 Thread Li Zhijian



On 12/03/2015 05:37 PM, Hailiang Zhang wrote:

On 2015/12/3 17:24, Dr. David Alan Gilbert wrote:

* Li Zhijian (lizhij...@cn.fujitsu.com) wrote:

Hi all,

Does anyboday remember the similar issue post by hailiang months ago
  http://patchwork.ozlabs.org/patch/454322/
At least tow bugs about migration had been fixed since that.


Yes, I wondered what happened to that.


And now we found the same issue at the tcg vm(kvm is fine), after
migration,
the content VM's memory is inconsistent.


Hmm, TCG only - I don't know much about that; but I guess something must
be accessing memory without using the proper macros/functions so
it doesn't mark it as dirty.


we add a patch to check memory content, you can find it from affix

steps to reporduce:
1) apply the patch and re-build qemu
2) prepare the ubuntu guest and run memtest in grub.
soruce side:
x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device
e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive
if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device
virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0

-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp
tcp::,server,nowait -monitor stdio -cpu qemu64 -machine
pc-i440fx-2.3,accel=tcg,usb=off

destination side:
x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device
e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive
if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device
virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0

-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp
tcp::,server,nowait -monitor stdio -cpu qemu64 -machine
pc-i440fx-2.3,accel=tcg,usb=off -incoming tcp:0:8881

3) start migration
with 1000M NIC, migration will finish within 3 min.

at source:
(qemu) migrate tcp:192.168.2.66:8881
after saving ram complete
e9e725df678d392b1a83b3a917f332bb
qemu-system-x86_64: end ram md5
(qemu)

at destination:
...skip...
Completed load of VM with exit code 0 seq iteration 1264
Completed load of VM with exit code 0 seq iteration 1265
Completed load of VM with exit code 0 seq iteration 1266
qemu-system-x86_64: after loading state section id 2(ram)
49c2dac7bde0e5e22db7280dcb3824f9
qemu-system-x86_64: end ram md5
qemu-system-x86_64: qemu_loadvm_state: after
cpu_synchronize_all_post_init

49c2dac7bde0e5e22db7280dcb3824f9
qemu-system-x86_64: end ram md5

This occurs occasionally and only at tcg machine. It seems that
some pages dirtied in source side don't transferred to destination.
This problem can be reproduced even if we disable virtio.

Is it OK for some pages that not transferred to destination when do
migration ? Or is it a bug?


I'm pretty sure that means it's a bug.  Hard to find though, I guess
at least memtest is smaller than a big OS.  I think I'd dump the whole
of memory on both sides, hexdump and diff them  - I'd guess it would
just be one byte/word different, maybe that would offer some idea what
wrote it.



Maybe one better way to do that is with the help of userfaultfd's
write-protect
capability. It is still in the development by Andrea Arcangeli, but there
is a RFC version available, please refer to
http://www.spinics.net/lists/linux-mm/msg97422.html
(I'm developing live memory snapshot which based on it, maybe this is
another scene where we
can use userfaultfd's WP ;) ).


sounds good.

thanks
Li





Dave


Any idea...

=md5 check patch=

diff --git a/Makefile.target b/Makefile.target
index 962d004..e2cb8e9 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -139,7 +139,7 @@ obj-y += memory.o cputlb.o
  obj-y += memory_mapping.o
  obj-y += dump.o
  obj-y += migration/ram.o migration/savevm.o
-LIBS := $(libs_softmmu) $(LIBS)
+LIBS := $(libs_softmmu) $(LIBS) -lplumb

  # xen support
  obj-$(CONFIG_XEN) += xen-common.o
diff --git a/migration/ram.c b/migration/ram.c
index 1eb155a..3b7a09d 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2513,7 +2513,7 @@ static int ram_load(QEMUFile *f, void *opaque, int
version_id)
  }

  rcu_read_unlock();
-DPRINTF("Completed load of VM with exit code %d seq iteration "
+fprintf(stderr, "Completed load of VM with exit code %d seq
iteration "
  "%" PRIu64 "\n", ret, seq_iter);
  return ret;
  }
diff --git a/migration/savevm.c b/migration/savevm.c
index 0ad1b93..3feaa61 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -891,6 +891,29 @@ void qemu_savevm_state_header(QEMUFile *f)

  }

+#include "exec/ram_addr.h"
+#include "qemu/rcu_queue.h"
+#include 
+#ifndef MD5_DIGEST_LENGTH
+#define MD5_DIGEST_LENGTH 16
+#endif
+
+static void check_host_md5(void)
+{
+int i;
+unsigned char md[MD5_DIGEST_LENGTH];
+rcu_read_lock();
+RAMBlock *block = QLIST_FIRST_RCU(_list.blocks);/* Only check
'pc.ram' block */
+rcu_read_unlock();
+
+MD5(block->host, block->used_length, md);
+for(i = 0; i < MD5_DIGEST_LENGTH; 

Re: [Qemu-devel] [PULL 0/9] virtio,vhost,mmap fixes for 2.5

2015-12-03 Thread Peter Maydell
On 2 December 2015 at 20:39, Michael S. Tsirkin  wrote:
> On Wed, Dec 02, 2015 at 10:35:18PM +0200, Michael S. Tsirkin wrote:
>> The following changes since commit 9d7b969ea6d9663a94760c6c131481b366f4d38a:
>>
>>   Merge remote-tracking branch 'remotes/rth/tags/pull-tcg-20151201' into 
>> staging (2015-12-02 10:16:53 +)
>>
>> are available in the git repository at:
>>
>>   git://git.kernel.org/pub/scm/virt/kvm/mst/qemu.git tags/for_upstream
>>
>> for you to fetch changes up to 203ed8d6239cdf3c1e61688259b4aa2be2de66b4:
>
> 7197fb4058bcb68986bae2bb2c04d6370f3e7218 now as I added Rick's ack.
>
>>   util/mmap-alloc: fix hugetlb support on ppc64 (2015-12-02 22:31:55 +0200)
>>
>> 
>> virtio,vhost,mmap fixes for 2.5
>>
>> vhost test patches to fix the travis build
>> virtio ccw patch to fix virtio 1
>> virtio pci patch to fix pci express
>> vhost user bridge patch to fix fd leaks
>> mmap-alloc patch to fix hugetlbfs on ppc64
>> remove dead code for vhost (trivial)
>>
>> Signed-off-by: Michael S. Tsirkin 
>>
>> 

Applied, thanks.

-- PMM



Re: [Qemu-devel] WG: [ovirt-users] Segmentation fault in libtcmalloc

2015-12-03 Thread Grundmann, Christian
Hi again,
got a Segfault today without virtio :-( (one IDE Disk and one virtio-scsi)

Core was generated by `/usr/libexec/qemu-kvm -name vmname -S -machine 
pc-i440fx-rhel7.2.0,accel='.
Program terminated with signal 11, Segmentation fault.
#0  0x7fb299cbd3ab in 
tcmalloc::ThreadCache::ReleaseToCentralCache(tcmalloc::ThreadCache::FreeList*, 
unsigned long, int) () from /lib64/libtcmalloc.so.4

Thread 6 (Thread 0x7fb28d0c5700 (LWP 29423)):
#0  0x7fb29cc85ac3 in pread64 () at ../sysdeps/unix/syscall-template.S:81
No locals.
#1  0x7fb29e37c2a3 in pread (__offset=, __nbytes=, __buf=0x7fb2a3e21a00, __fd=) at 
/usr/include/bits/unistd.h:99
No locals.
#2  handle_aiocb_rw_linear (aiocb=aiocb@entry=0x7fb2a1474340, 
buf=buf@entry=0x7fb2a3e21a00 "QF", ) at 
block/raw-posix.c:909
offset = 0
len = 
#3  0x7fb29e37c3d1 in handle_aiocb_rw (aiocb=0x7fb2a1474340) at 
block/raw-posix.c:992
nbytes = 
buf = 0x7fb2a3e21a00 "QF", 
__PRETTY_FUNCTION__ = "handle_aiocb_rw"
#4  0x7fb29e37d945 in aio_worker (arg=0x7fb2a1474340) at 
block/raw-posix.c:1204
aiocb = 0x7fb2a1474340
ret = 0
#5  0x7fb29e33d91b in worker_thread (opaque=0x7fb2a148d450) at 
thread-pool.c:105
req = 0x7fb2a1474b30
ret = 
pool = 0x7fb2a148d450
#6  0x7fb29cc7edf5 in start_thread (arg=0x7fb28d0c5700) at 
pthread_create.c:308
__res = 
pd = 0x7fb28d0c5700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140404847302400, 
-4522449750849005939, 0, 140404847303104, 140404847302400, 26, 
4492373549408278157, 4492409237274449549}, mask_was_saved = 0}}, priv = {pad = 
{0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
#7  0x7fb29688c1ad in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:113
No locals.

Thread 5 (Thread 0x7fb104fff700 (LWP 29084)):
#0  0x7fb296881b7d in poll () at ../sysdeps/unix/syscall-template.S:81
No locals.
#1  0x7fb2977d6fe7 in red_worker_main () from /lib64/libspice-server.so.1
No symbol table info available.
#2  0x7fb29cc7edf5 in start_thread (arg=0x7fb104fff700) at 
pthread_create.c:308
__res = 
pd = 0x7fb104fff700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140398269822720, 
-4522449750849005939, 0, 140398269823424, 140398269822720, 140405245697216, 
4494326442046740109, 4492409237274449549}, mask_was_saved = 0}}, priv = {pad = 
{0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
#3  0x7fb29688c1ad in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:113
No locals.

Thread 4 (Thread 0x7fb28c8c4700 (LWP 29081)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at 
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
No locals.
#1  0x7fb29e3b9f79 in qemu_cond_wait (cond=, 
mutex=mutex@entry=0x7fb29e866d40 ) at 
util/qemu-thread-posix.c:132
err = 
__func__ = "qemu_cond_wait"
#2  0x7fb29e172d3b in qemu_kvm_wait_io_event (cpu=) at 
/usr/src/debug/qemu-2.3.0/cpus.c:912
No locals.
#3  qemu_kvm_cpu_thread_fn (arg=0x7fb2a3d2e000) at 
/usr/src/debug/qemu-2.3.0/cpus.c:949
cpu = 0x7fb2a3d2e000
r = 
#4  0x7fb29cc7edf5 in start_thread (arg=0x7fb28c8c4700) at 
pthread_create.c:308
__res = 
pd = 0x7fb28c8c4700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140404838909696, 
-4522449750849005939, 0, 140404838910400, 140404838909696, 140735272359936, 
4492374652678002317, 4492409237274449549}, mask_was_saved = 0}}, priv = {pad = 
{0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
#5  0x7fb29688c1ad in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:113
No locals.

Thread 3 (Thread 0x7fb28c0c3700 (LWP 29082)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at 
../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
No locals.
#1  0x7fb29e3b9f79 in qemu_cond_wait (cond=, 
mutex=mutex@entry=0x7fb29e866d40 ) at 
util/qemu-thread-posix.c:132
err = 
__func__ = "qemu_cond_wait"
#2  0x7fb29e172d3b in qemu_kvm_wait_io_event (cpu=) at 
/usr/src/debug/qemu-2.3.0/cpus.c:912
No locals.
#3  qemu_kvm_cpu_thread_fn (arg=0x7fb2a3d7e000) at 
/usr/src/debug/qemu-2.3.0/cpus.c:949
cpu = 0x7fb2a3d7e000
r = 
#4  0x7fb29cc7edf5 in start_thread (arg=0x7fb28c0c3700) at 
pthread_create.c:308
__res = 
pd = 0x7fb28c0c3700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140404830516992, 
-4522449750849005939, 0, 140404830517696, 140404830516992, 140735272359936, 
4492375751652759181, 4492409237274449549}, mask_was_saved = 0}}, priv = {pad = 
{0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, 

Re: [Qemu-devel] [RFC PATCH V2 09/10] Qemu/VFIO: Add SRIOV VF migration support

2015-12-03 Thread Lan, Tianyu



On 12/3/2015 6:25 AM, Alex Williamson wrote:

On Tue, 2015-11-24 at 21:35 +0800, Lan Tianyu wrote:

This patch is to add SRIOV VF migration support.
Create new device type "vfio-sriov" and add faked PCI migration capability
to the type device.

The purpose of the new capability
1) sync migration status with VF driver in the VM
2) Get mailbox irq vector to notify VF driver during migration.
3) Provide a way to control injecting irq or not.

Qemu will migrate PCI configure space regs and MSIX config for VF.
Inject mailbox irq at last stage of migration to notify VF about
migration event and wait VF driver ready for migration. VF driver
writeS PCI config reg PCI_VF_MIGRATION_VF_STATUS in the new cap table
to tell Qemu.


What makes this sr-iov specific?  Why wouldn't we simply extend vfio-pci
with a migration=on feature?  Thanks,


Sounds reasonable and will update it.



Alex





Re: [Qemu-devel] WG: [ovirt-users] Segmentation fault in libtcmalloc

2015-12-03 Thread Dr. David Alan Gilbert
* Grundmann, Christian (christian.grundm...@fabasoft.com) wrote:
> Hi again,
> got a Segfault today without virtio :-( (one IDE Disk and one virtio-scsi)
> 
> Core was generated by `/usr/libexec/qemu-kvm -name vmname -S -machine 
> pc-i440fx-rhel7.2.0,accel='.

Can you confirm the package version you were using; if you're running the 
pc-i440fx-rhel7.2.0 machine
type it must be pretty new.

Dave

> Program terminated with signal 11, Segmentation fault.
> #0  0x7fb299cbd3ab in 
> tcmalloc::ThreadCache::ReleaseToCentralCache(tcmalloc::ThreadCache::FreeList*,
>  unsigned long, int) () from /lib64/libtcmalloc.so.4
> 
> Thread 6 (Thread 0x7fb28d0c5700 (LWP 29423)):
> #0  0x7fb29cc85ac3 in pread64 () at ../sysdeps/unix/syscall-template.S:81
> No locals.
> #1  0x7fb29e37c2a3 in pread (__offset=, 
> __nbytes=, __buf=0x7fb2a3e21a00, __fd=) at 
> /usr/include/bits/unistd.h:99
> No locals.
> #2  handle_aiocb_rw_linear (aiocb=aiocb@entry=0x7fb2a1474340, 
> buf=buf@entry=0x7fb2a3e21a00 "QF", ) at 
> block/raw-posix.c:909
> offset = 0
> len = 
> #3  0x7fb29e37c3d1 in handle_aiocb_rw (aiocb=0x7fb2a1474340) at 
> block/raw-posix.c:992
> nbytes = 
> buf = 0x7fb2a3e21a00 "QF", 
> __PRETTY_FUNCTION__ = "handle_aiocb_rw"
> #4  0x7fb29e37d945 in aio_worker (arg=0x7fb2a1474340) at 
> block/raw-posix.c:1204
> aiocb = 0x7fb2a1474340
> ret = 0
> #5  0x7fb29e33d91b in worker_thread (opaque=0x7fb2a148d450) at 
> thread-pool.c:105
> req = 0x7fb2a1474b30
> ret = 
> pool = 0x7fb2a148d450
> #6  0x7fb29cc7edf5 in start_thread (arg=0x7fb28d0c5700) at 
> pthread_create.c:308
> __res = 
> pd = 0x7fb28d0c5700
> now = 
> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140404847302400, 
> -4522449750849005939, 0, 140404847303104, 140404847302400, 26, 
> 4492373549408278157, 4492409237274449549}, mask_was_saved = 0}}, priv = {pad 
> = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
> not_first_call = 
> pagesize_m1 = 
> sp = 
> freesize = 
> #7  0x7fb29688c1ad in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
> No locals.
> 
> Thread 5 (Thread 0x7fb104fff700 (LWP 29084)):
> #0  0x7fb296881b7d in poll () at ../sysdeps/unix/syscall-template.S:81
> No locals.
> #1  0x7fb2977d6fe7 in red_worker_main () from /lib64/libspice-server.so.1
> No symbol table info available.
> #2  0x7fb29cc7edf5 in start_thread (arg=0x7fb104fff700) at 
> pthread_create.c:308
> __res = 
> pd = 0x7fb104fff700
> now = 
> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140398269822720, 
> -4522449750849005939, 0, 140398269823424, 140398269822720, 140405245697216, 
> 4494326442046740109, 4492409237274449549}, mask_was_saved = 0}}, priv = {pad 
> = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
> not_first_call = 
> pagesize_m1 = 
> sp = 
> freesize = 
> #3  0x7fb29688c1ad in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
> No locals.
> 
> Thread 4 (Thread 0x7fb28c8c4700 (LWP 29081)):
> #0  pthread_cond_wait@@GLIBC_2.3.2 () at 
> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
> No locals.
> #1  0x7fb29e3b9f79 in qemu_cond_wait (cond=, 
> mutex=mutex@entry=0x7fb29e866d40 ) at 
> util/qemu-thread-posix.c:132
> err = 
> __func__ = "qemu_cond_wait"
> #2  0x7fb29e172d3b in qemu_kvm_wait_io_event (cpu=) at 
> /usr/src/debug/qemu-2.3.0/cpus.c:912
> No locals.
> #3  qemu_kvm_cpu_thread_fn (arg=0x7fb2a3d2e000) at 
> /usr/src/debug/qemu-2.3.0/cpus.c:949
> cpu = 0x7fb2a3d2e000
> r = 
> #4  0x7fb29cc7edf5 in start_thread (arg=0x7fb28c8c4700) at 
> pthread_create.c:308
> __res = 
> pd = 0x7fb28c8c4700
> now = 
> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140404838909696, 
> -4522449750849005939, 0, 140404838910400, 140404838909696, 140735272359936, 
> 4492374652678002317, 4492409237274449549}, mask_was_saved = 0}}, priv = {pad 
> = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
> not_first_call = 
> pagesize_m1 = 
> sp = 
> freesize = 
> #5  0x7fb29688c1ad in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
> No locals.
> 
> Thread 3 (Thread 0x7fb28c0c3700 (LWP 29082)):
> #0  pthread_cond_wait@@GLIBC_2.3.2 () at 
> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
> No locals.
> #1  0x7fb29e3b9f79 in qemu_cond_wait (cond=, 
> mutex=mutex@entry=0x7fb29e866d40 ) at 
> util/qemu-thread-posix.c:132
> err = 
> __func__ = "qemu_cond_wait"
> #2  0x7fb29e172d3b in qemu_kvm_wait_io_event (cpu=) at 
> /usr/src/debug/qemu-2.3.0/cpus.c:912
> No locals.
> #3  qemu_kvm_cpu_thread_fn (arg=0x7fb2a3d7e000) at 
> /usr/src/debug/qemu-2.3.0/cpus.c:949
> cpu = 0x7fb2a3d7e000

Re: [Qemu-devel] [RFC PATCH 7/9] net/colo-proxy: add packet enqueue and handle function

2015-12-03 Thread Dr. David Alan Gilbert
* Zhang Chen (zhangchen.f...@cn.fujitsu.com) wrote:
> 
> Hi,Dave
> 
> On 12/02/2015 12:12 AM, Dr. David Alan Gilbert wrote:
> >* Zhang Chen (zhangchen.f...@cn.fujitsu.com) wrote:
> >>From: zhangchen 
> >>
> >>Add common packet handle function and enqueue
> >>packet distinguished connection,then we can
> >>lookup one connection packet to compare
> >>
> >>Signed-off-by: zhangchen 
> >>---
> >>  net/colo-proxy.c | 167 
> >> ++-
> >>  1 file changed, 166 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/net/colo-proxy.c b/net/colo-proxy.c
> >>index 08a852f..a664e6d 100644
> >>--- a/net/colo-proxy.c
> >>+++ b/net/colo-proxy.c
> >>@@ -24,6 +24,170 @@
> >>  static char *mode;
> >>  static bool colo_do_checkpoint;
> >>+static void packet_destroy(void *opaque, void *user_data);
> >>+
> >>+static uint32_t connection_key_hash(const void *opaque)
> >>+{
> >>+const Connection_key *key = opaque;
> >>+uint32_t a, b, c;
> >>+
> >>+/* Jenkins hash */
> >>+a = b = c = JHASH_INITVAL + sizeof(*key);
> >>+a += key->src;
> >>+b += key->dst;
> >>+c += key->ports;
> >>+__jhash_mix(a, b, c);
> >>+
> >>+a += key->ip_proto;
> >>+__jhash_final(a, b, c);
> >>+
> >>+return c;
> >>+}
> >>+
> >>+static int connection_key_equal(const void *opaque1, const void *opaque2)
> >>+{
> >>+return memcmp(opaque1, opaque2, sizeof(Connection_key)) == 0;
> >>+}
> >>+
> >>+static void connection_destroy(void *opaque)
> >>+{
> >>+Connection *connection = opaque;
> >>+g_queue_foreach(>primary_list, packet_destroy, NULL);
> >>+g_queue_free(>primary_list);
> >>+g_queue_foreach(>secondary_list, packet_destroy, NULL);
> >>+g_queue_free(>secondary_list);
> >>+g_slice_free(Connection, connection);
> >>+}
> >>+
> >>+static Connection *connection_new(void)
> >>+{
> >>+Connection *connection = g_slice_new(Connection);
> >>+
> >>+g_queue_init(>primary_list);
> >>+g_queue_init(>secondary_list);
> >>+connection->processing = false;
> >>+
> >>+return connection;
> >>+}
> >>+
> >>+/* Return 0 on success, or return -1 if the pkt is corrpted */
> >>+static int parse_packet_early(Packet *pkt, Connection_key *key)
> >>+{
> >>+int network_length;
> >>+uint8_t *data = pkt->data;
> >>+
> >>+pkt->network_layer = data + ETH_HLEN;
> >>+if (ntohs(*(uint16_t *)(data + 12)) != ETH_P_IP) {
> >>+if (ntohs(*(uint16_t *)(data + 12)) == ETH_P_ARP) {
> >>+return -1;
> >>+}
> >>+return 0;
> >>+}
> >Can you use some of the functions/macros in include/net/eth.h to
> >make this easier? Maybe eth_get_l3_proto ?
> >Do you plan to do IPv6 at some point?
> 
> I will use include/net/eth.h in next version
> 
> IPv6 currently not support, still colo framework be merged
> 
> >>+network_length = pkt->ip->ip_hl * 4;
> >>+pkt->transport_layer = pkt->network_layer + network_length;
> >>+key->ip_proto = pkt->ip->ip_p;
> >>+key->src = pkt->ip->ip_src;
> >>+key->dst = pkt->ip->ip_dst;
> >>+
> >>+switch (key->ip_proto) {
> >>+case IPPROTO_TCP:
> >>+case IPPROTO_UDP:
> >>+case IPPROTO_DCCP:
> >>+case IPPROTO_ESP:
> >>+case IPPROTO_SCTP:
> >>+case IPPROTO_UDPLITE:
> >>+key->ports = *(uint32_t *)(pkt->transport_layer);
> >>+break;
> >>+case IPPROTO_AH:
> >>+key->ports = *(uint32_t *)(pkt->transport_layer + 4);
> >Interesting; I don't see any other code in QEMU to handle AH,
> >and I don't know much about it.
> >
> >>+break;
> >>+default:
> >>+break;
> >>+}
> >>+
> >>+return 0;
> >>+}
> >>+
> >>+static Packet *packet_new(ColoProxyState *s, const void *data,
> >>+  int size, Connection_key *key, NetClientState 
> >>*sender)
> >>+{
> >>+Packet *pkt = g_slice_new(Packet);
> >>+
> >>+pkt->data = g_malloc(size);
> >>+memcpy(pkt->data, data, size);
> >g_memdup might be useful for these:
> >https://developer.gnome.org/glib/stable/glib-Memory-Allocation.html#g-memdup
> 
> I will fix it in next version
> 
> >>+pkt->size = size;
> >>+pkt->s = s;
> >>+pkt->sender = sender;
> >>+pkt->should_be_sent = false;
> >>+
> >>+if (parse_packet_early(pkt, key)) {
> >>+packet_destroy(pkt, NULL);
> >>+pkt = NULL;
> >>+}
> >>+
> >>+return pkt;
> >>+}
> >>+
> >>+static void packet_destroy(void *opaque, void *user_data)
> >>+{
> >>+Packet *pkt = opaque;
> >>+g_free(pkt->data);
> >>+g_slice_free(Packet, pkt);
> >>+}
> >>+
> >>+static Connection *colo_proxy_enqueue_packet(GHashTable 
> >>*unprocessed_packets,
> >>+  Connection_key *key,
> >>+  Packet *pkt, packet_type type)
> >>+{
> >>+Connection *connection;
> >>+Packet *tmppkt;
> >>+connection = g_hash_table_lookup(unprocessed_packets, key);
> 

Re: [Qemu-devel] [TCG only][Migration Bug? ] Occasionally, the content of VM's memory is inconsistent between Source and Destination of migration

2015-12-03 Thread Dr. David Alan Gilbert
* Li Zhijian (lizhij...@cn.fujitsu.com) wrote:
> Hi all,
> 
> Does anyboday remember the similar issue post by hailiang months ago
>  http://patchwork.ozlabs.org/patch/454322/
> At least tow bugs about migration had been fixed since that.

Yes, I wondered what happened to that.

> And now we found the same issue at the tcg vm(kvm is fine), after migration,
> the content VM's memory is inconsistent.

Hmm, TCG only - I don't know much about that; but I guess something must
be accessing memory without using the proper macros/functions so
it doesn't mark it as dirty.

> we add a patch to check memory content, you can find it from affix
> 
> steps to reporduce:
> 1) apply the patch and re-build qemu
> 2) prepare the ubuntu guest and run memtest in grub.
> soruce side:
> x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device
> e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive
> if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device
> virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0
> -vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp
> tcp::,server,nowait -monitor stdio -cpu qemu64 -machine
> pc-i440fx-2.3,accel=tcg,usb=off
> 
> destination side:
> x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device
> e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive
> if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device
> virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0
> -vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp
> tcp::,server,nowait -monitor stdio -cpu qemu64 -machine
> pc-i440fx-2.3,accel=tcg,usb=off -incoming tcp:0:8881
> 
> 3) start migration
> with 1000M NIC, migration will finish within 3 min.
> 
> at source:
> (qemu) migrate tcp:192.168.2.66:8881
> after saving ram complete
> e9e725df678d392b1a83b3a917f332bb
> qemu-system-x86_64: end ram md5
> (qemu)
> 
> at destination:
> ...skip...
> Completed load of VM with exit code 0 seq iteration 1264
> Completed load of VM with exit code 0 seq iteration 1265
> Completed load of VM with exit code 0 seq iteration 1266
> qemu-system-x86_64: after loading state section id 2(ram)
> 49c2dac7bde0e5e22db7280dcb3824f9
> qemu-system-x86_64: end ram md5
> qemu-system-x86_64: qemu_loadvm_state: after cpu_synchronize_all_post_init
> 
> 49c2dac7bde0e5e22db7280dcb3824f9
> qemu-system-x86_64: end ram md5
> 
> This occurs occasionally and only at tcg machine. It seems that
> some pages dirtied in source side don't transferred to destination.
> This problem can be reproduced even if we disable virtio.
> 
> Is it OK for some pages that not transferred to destination when do
> migration ? Or is it a bug?

I'm pretty sure that means it's a bug.  Hard to find though, I guess
at least memtest is smaller than a big OS.  I think I'd dump the whole
of memory on both sides, hexdump and diff them  - I'd guess it would
just be one byte/word different, maybe that would offer some idea what
wrote it.

Dave

> Any idea...
> 
> =md5 check patch=
> 
> diff --git a/Makefile.target b/Makefile.target
> index 962d004..e2cb8e9 100644
> --- a/Makefile.target
> +++ b/Makefile.target
> @@ -139,7 +139,7 @@ obj-y += memory.o cputlb.o
>  obj-y += memory_mapping.o
>  obj-y += dump.o
>  obj-y += migration/ram.o migration/savevm.o
> -LIBS := $(libs_softmmu) $(LIBS)
> +LIBS := $(libs_softmmu) $(LIBS) -lplumb
> 
>  # xen support
>  obj-$(CONFIG_XEN) += xen-common.o
> diff --git a/migration/ram.c b/migration/ram.c
> index 1eb155a..3b7a09d 100644
> --- a/migration/ram.c
> +++ b/migration/ram.c
> @@ -2513,7 +2513,7 @@ static int ram_load(QEMUFile *f, void *opaque, int
> version_id)
>  }
> 
>  rcu_read_unlock();
> -DPRINTF("Completed load of VM with exit code %d seq iteration "
> +fprintf(stderr, "Completed load of VM with exit code %d seq iteration "
>  "%" PRIu64 "\n", ret, seq_iter);
>  return ret;
>  }
> diff --git a/migration/savevm.c b/migration/savevm.c
> index 0ad1b93..3feaa61 100644
> --- a/migration/savevm.c
> +++ b/migration/savevm.c
> @@ -891,6 +891,29 @@ void qemu_savevm_state_header(QEMUFile *f)
> 
>  }
> 
> +#include "exec/ram_addr.h"
> +#include "qemu/rcu_queue.h"
> +#include 
> +#ifndef MD5_DIGEST_LENGTH
> +#define MD5_DIGEST_LENGTH 16
> +#endif
> +
> +static void check_host_md5(void)
> +{
> +int i;
> +unsigned char md[MD5_DIGEST_LENGTH];
> +rcu_read_lock();
> +RAMBlock *block = QLIST_FIRST_RCU(_list.blocks);/* Only check
> 'pc.ram' block */
> +rcu_read_unlock();
> +
> +MD5(block->host, block->used_length, md);
> +for(i = 0; i < MD5_DIGEST_LENGTH; i++) {
> +fprintf(stderr, "%02x", md[i]);
> +}
> +fprintf(stderr, "\n");
> +error_report("end ram md5");
> +}
> +
>  void qemu_savevm_state_begin(QEMUFile *f,
>   const MigrationParams *params)
>  {
> @@ -1056,6 +1079,10 @@ void 

[Qemu-devel] Wiki account request (was: Re: Highlighting changes in QEMU 2.5)

2015-12-03 Thread Thomas Huth
> On (Tue) 24 Nov 2015 [10:28:25], Amit Shah wrote:
>> Hello,
>>
>> The 2.5 release is close - and I'm collecting a list of notable
>> changes and features once more.  The video made for the 2.4 release
>> [1] was popular, and I'm volunteering to make one for 2.5 as well.  In
>> addition, we need more feature pages, and there's a template at [2]
>> that you can use to base feature pages off.

I'd like to add a feature page for the H_RANDOM feature that I've
contributed in this release cycle (see the commit message for details:
http://git.qemu.org/?p=qemu.git;a=commit;h=4d9392be6c1aada69ce86c),
since I think it might be good to document for the users how to use this
feature.

However, I do not have an Wiki account yet. Would it be possible to get
an account for this?

 Thanks,
  Thomas




Re: [Qemu-devel] [TCG only][Migration Bug? ] Occasionally, the content of VM's memory is inconsistent between Source and Destination of migration

2015-12-03 Thread Li Zhijian



On 12/03/2015 05:24 PM, Dr. David Alan Gilbert wrote:

* Li Zhijian (lizhij...@cn.fujitsu.com) wrote:

Hi all,

Does anyboday remember the similar issue post by hailiang months ago
  http://patchwork.ozlabs.org/patch/454322/
At least tow bugs about migration had been fixed since that.


Yes, I wondered what happened to that.


And now we found the same issue at the tcg vm(kvm is fine), after migration,
the content VM's memory is inconsistent.


Hmm, TCG only - I don't know much about that; but I guess something must
be accessing memory without using the proper macros/functions so
it doesn't mark it as dirty.


we add a patch to check memory content, you can find it from affix

steps to reporduce:
1) apply the patch and re-build qemu
2) prepare the ubuntu guest and run memtest in grub.
soruce side:
x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device
e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive
if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device
virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0
-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp
tcp::,server,nowait -monitor stdio -cpu qemu64 -machine
pc-i440fx-2.3,accel=tcg,usb=off

destination side:
x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device
e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive
if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device
virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0
-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp
tcp::,server,nowait -monitor stdio -cpu qemu64 -machine
pc-i440fx-2.3,accel=tcg,usb=off -incoming tcp:0:8881

3) start migration
with 1000M NIC, migration will finish within 3 min.

at source:
(qemu) migrate tcp:192.168.2.66:8881
after saving ram complete
e9e725df678d392b1a83b3a917f332bb
qemu-system-x86_64: end ram md5
(qemu)

at destination:
...skip...
Completed load of VM with exit code 0 seq iteration 1264
Completed load of VM with exit code 0 seq iteration 1265
Completed load of VM with exit code 0 seq iteration 1266
qemu-system-x86_64: after loading state section id 2(ram)
49c2dac7bde0e5e22db7280dcb3824f9
qemu-system-x86_64: end ram md5
qemu-system-x86_64: qemu_loadvm_state: after cpu_synchronize_all_post_init

49c2dac7bde0e5e22db7280dcb3824f9
qemu-system-x86_64: end ram md5

This occurs occasionally and only at tcg machine. It seems that
some pages dirtied in source side don't transferred to destination.
This problem can be reproduced even if we disable virtio.

Is it OK for some pages that not transferred to destination when do
migration ? Or is it a bug?


I'm pretty sure that means it's a bug.  Hard to find though, I guess
at least memtest is smaller than a big OS.  I think I'd dump the whole
of memory on both sides, hexdump and diff them  - I'd guess it would
just be one byte/word different, maybe that would offer some idea what
wrote it.


I try to dump and compare them, more than 10 pages are different.
in source side, they are random value rather than always 'FF' 'FB' 'EF' 
'BF'... in destination.


and not all of the different pages are continuous.

thanks
Li




Dave


Any idea...

=md5 check patch=

diff --git a/Makefile.target b/Makefile.target
index 962d004..e2cb8e9 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -139,7 +139,7 @@ obj-y += memory.o cputlb.o
  obj-y += memory_mapping.o
  obj-y += dump.o
  obj-y += migration/ram.o migration/savevm.o
-LIBS := $(libs_softmmu) $(LIBS)
+LIBS := $(libs_softmmu) $(LIBS) -lplumb

  # xen support
  obj-$(CONFIG_XEN) += xen-common.o
diff --git a/migration/ram.c b/migration/ram.c
index 1eb155a..3b7a09d 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2513,7 +2513,7 @@ static int ram_load(QEMUFile *f, void *opaque, int
version_id)
  }

  rcu_read_unlock();
-DPRINTF("Completed load of VM with exit code %d seq iteration "
+fprintf(stderr, "Completed load of VM with exit code %d seq iteration "
  "%" PRIu64 "\n", ret, seq_iter);
  return ret;
  }
diff --git a/migration/savevm.c b/migration/savevm.c
index 0ad1b93..3feaa61 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -891,6 +891,29 @@ void qemu_savevm_state_header(QEMUFile *f)

  }

+#include "exec/ram_addr.h"
+#include "qemu/rcu_queue.h"
+#include 
+#ifndef MD5_DIGEST_LENGTH
+#define MD5_DIGEST_LENGTH 16
+#endif
+
+static void check_host_md5(void)
+{
+int i;
+unsigned char md[MD5_DIGEST_LENGTH];
+rcu_read_lock();
+RAMBlock *block = QLIST_FIRST_RCU(_list.blocks);/* Only check
'pc.ram' block */
+rcu_read_unlock();
+
+MD5(block->host, block->used_length, md);
+for(i = 0; i < MD5_DIGEST_LENGTH; i++) {
+fprintf(stderr, "%02x", md[i]);
+}
+fprintf(stderr, "\n");
+error_report("end ram md5");
+}
+
  void qemu_savevm_state_begin(QEMUFile *f,
   const MigrationParams 

Re: [Qemu-devel] [PATCH for-2.5 0/2] tests: A cleanup and a fix

2015-12-03 Thread Peter Maydell
On 2 December 2015 at 20:20, Markus Armbruster  wrote:
> PATCH 1 cleans up unnecessary type punning.
>
> PATCH 2 plugs a massive memory leak in qom-test.  I think it would be
> nice to have in 2.5, but at this late stage, it's really up to the
> maintainer.

To go into 2.5 it needs to be reviewed and either be in a pull
request or have a request from the maintainer for me to apply it
directly by the end of today UK time.

Is the memory leak a regression, or have we always leaked and
not noticed?

thanks
-- PMM



Re: [Qemu-devel] [PATCH for-2.5 1/2] tests: Use proper functions types instead of void (*fn)

2015-12-03 Thread Markus Armbruster
Eric Blake  writes:

> On 12/02/2015 01:20 PM, Markus Armbruster wrote:
>> We have several function parameters declared as void (*fn).  This is
>> just a stupid way to write void *, and the only purpose writing it
>> like that could serve is obscuring the sin of bypassing the type
>> system without need.
>
> Presumably, someone meant to write 'void (*fn)()' or some other argument
> list to designate fn as a function pointer; but I agree with the
> approach you took of using typedefs rather than spelling it out raw.
>
>> 
>> The original sin is commit 49ee359: its qtest_add_func() is a wrapper
>> for g_test_add_func().  Fix the parameter type to match
>> g_test_add_func()'s.  This uncovers type errors in ide-test.c; fix
>> them.
>> 
>> Commit 7949c0e faithfully repeated the sin for qtest_add_data_func().
>> Fix it the same way, along with a harmless type error uncovered in
>> vhost-user-test.c.
>> 
>> Commit 063c23d repeated it for qtest_add_abrt_handler().  The screwy
>> parameter gets assigned to GHook member func, so change its type to
>> match.  Requires wrapping kill_qemu() to keep the type checker happy.
>> 
>> Signed-off-by: Markus Armbruster 
>> ---
>>  tests/ide-test.c|  4 ++--
>>  tests/libqtest.c| 13 +
>>  tests/libqtest.h|  6 +++---
>>  tests/vhost-user-test.c |  3 ++-
>>  4 files changed, 16 insertions(+), 10 deletions(-)
>> 
>
>> +++ b/tests/libqtest.c
>> @@ -110,6 +110,11 @@ static void kill_qemu(QTestState *s)
>>  }
>>  }
>>  
>> +static void kill_qemu_hook_func(void *s)
>> +{
>> +kill_qemu(s);
>
> Getting the implicit conversion from void * to QTestState *, without
> having to cast the actual function signature.  Makes sense.

I'm not fond of wrappers, but I really dislike function pointer casts;
I've seen too many of them with undefined behavior.

>> @@ -133,7 +138,7 @@ static void cleanup_sigabrt_handler(void)
>>  sigaction(SIGABRT, _old, NULL);
>>  }
>>  
>> -void qtest_add_abrt_handler(void (*fn), const void *data)
>> +void qtest_add_abrt_handler(GHookFunc fn, const void *data)
>
> I had to look it up:
>
> /usr/include/glib-2.0/glib/ghook.h:typedef void   (*GHookFunc)
> (gpointer  data);
>
> which is the same as
>
> void (*fn)(void *)

Speaking of function pointer cases...  note struct GHook's member func's
documentation:

gpointer func; the function to call when this hook is invoked. The
   possible signatures for this function are GHookFunc
   and GHookCheckFunc

GHookFunc is void (*)(gpointer data), and to be used when the hook is
passed to g_hook_list_invoke().

GHookCheckFunc is gboolean (*)(gpointer data), and to be used when the
hook is passed to g_hook_list_invoke_check().

Undefined behavior when you get it wrong.

This interface displays no evidence of adult supervision.  Oh well,
"strong typing is for people with weak memories."

>> @@ -755,14 +760,14 @@ void qtest_memread(QTestState *s, uint64_t addr, void 
>> *data, size_t size)
>>  g_strfreev(args);
>>  }
>>  
>> -void qtest_add_func(const char *str, void (*fn))
>> +void qtest_add_func(const char *str, GTestFunc fn)
>>  {
>>  gchar *path = g_strdup_printf("/%s/%s", qtest_get_arch(), str);
>>  g_test_add_func(path, fn);
>
> /usr/include/glib-2.0/glib/gtestutils.h:typedef void (*GTestFunc)
>  (void);
>
>>  g_free(path);
>>  }
>>  
>> -void qtest_add_data_func(const char *str, const void *data, void (*fn))
>> +void qtest_add_data_func(const char *str, const void *data, GTestDataFunc 
>> fn)
>
> /usr/include/glib-2.0/glib/gtestutils.h:typedef void (*GTestDataFunc)
>  (gconstpointer user_data);
>
>> +++ b/tests/vhost-user-test.c
>> @@ -172,8 +172,9 @@ static void wait_for_fds(TestServer *s)
>>  g_mutex_unlock(>data_mutex);
>>  }
>>  
>> -static void read_guest_mem(TestServer *s)
>> +static void read_guest_mem(const void *data)
>>  {
>> +TestServer *s = (void *)data;
>
> And here you have to cast away const.
>
> At any rate, all the fixes look sane, and the fact that it compiles with
> now-tighter types is in its favor.
>
> Reviewed-by: Eric Blake 

Thanks!



Re: [Qemu-devel] [PATCH v6 02/23] qapi: Require int64/uint64 implementation

2015-12-03 Thread Markus Armbruster
Eric Blake  writes:

> On 11/27/2015 05:05 AM, Markus Armbruster wrote:
>> Eric Blake  writes:
>> 
>>> Now that all visitors supply both type_int64() and type_uint64()
>>> callbacks, we can drop the redundant type_int() callback (the
>>> public interface visit_type_int() remains, but calls into
>>> type_int64() under the hood).
>>>
>>> Signed-off-by: Eric Blake 
>>>
>
>>>  void visit_type_uint8(Visitor *v, uint8_t *obj, const char *name, Error 
>>> **errp)
>>>  {
>>> -int64_t value;
>>> +uint64_t value;
>>>
>>>  if (v->type_uint8) {
>>>  v->type_uint8(v, obj, name, errp);
>>>  } else {
>>>  value = *obj;
>>> -v->type_int(v, , name, errp);
>>> -if (value < 0 || value > UINT8_MAX) {
>>> +v->type_uint64(v, , name, errp);
>>> +if (value > UINT8_MAX) {
>>>  error_setg(errp, QERR_INVALID_PARAMETER_VALUE,
>>> name ? name : "null", "uint8_t");
>>>  return;
>> 
>> Note that this relies on value being in range after type_uint64() fails.
>> If it isn't, we call error_setg() with non-null *errp.
>> 
>> Two solutions:
>> 
>> 1. Stipulate that type_uint64() & friends leave value alone on error.
>>Works, because its initial value *obj is in range.
>
> Pre-existing and simpler, but sets a poor example for the rest of the
> code base (not everyone is going to read the fine print for why it works
> here), and requires cross-file audits to ensure visitors comply.

Yes, but "don't mess up externally visible state on error" is a pretty
common design maxim.

>> 2. Avoid using value on error.  A clean way to do this:
>> 
>> Error *err = NULL;
>> 
>> value = *obj;
>> v->type_uint64(v, , name, );
>> if (err) {
>> error_propagate(errp, err);
>> return;
>> }
>> if (value < 0 || value > UINT8_MAX) {
>> error_setg(errp, QERR_INVALID_PARAMETER_VALUE,
>>name ? name : "null", "uint8_t");
>> return;
>> }
>> *obj = value;
>> 
>>More boilerplate.  If we pick this solution, we'll want a separate
>>PATCH 1.5 cleaning up the preexisting instances.
>
> Of course, if I do the cleanup as 1.5, then patch 3/23 reindents
> everything, that's a lot of churn.  So I may end up rearranging 2 and 3
> after all, and then do the cleanup as 3.5.
>
> Or maybe option 3, write a pair of helper functions containing the
> boilerplate for checking against min and max:
>
> void visit_type_intN(Visitor *v, int64_t *obj, const char *name,
>  int64_t min, int64_t max, Error **errp);
> void visit_type_uintN(Visitor *v, int64_t *obj, const char *name,
>   uint64_t max, Error **errp);
>
> leaving us with simpler clients:
>
> visit_type_int8(Visitor *v, int8_t *obj, const char *name, Error **errp)
> {
> int64_t value = *obj;
> visit_type_uintN(v, , name, INT8_MIN, INT8_MAX, errp);
> *obj = value;
> }
>
> and here, because the helpers are in the same file, it's easier to prove
> that value was unchanged on error.  Or I may even squash 2 and 3 into a
> single patch now.

Artistic license applies.



Re: [Qemu-devel] [RFC PATCH V2 02/10] Qemu/VFIO: Add new VFIO_GET_PCI_CAP_INFO ioctl cmd definition

2015-12-03 Thread Lan, Tianyu


On 12/3/2015 6:25 AM, Alex Williamson wrote:

I didn't seen a matching kernel patch series for this, but why is the
kernel more capable of doing this than userspace is already?

The following link is the kernel patch.
http://marc.info/?l=kvm=144837328920989=2


These seem
like pointless ioctls, we're creating a purely virtual PCI capability,
the kernel doesn't really need to participate in that.


VFIO kernel driver has pci_config_map which indicates the PCI capability 
position and length which helps to find free PCI config regs. Qemu side 
doesn't have such info and can't get the exact table size of PCI 
capability. If we want to add such support in the Qemu, needs duplicates 
a lot of code of vfio_pci_configs.c in the Qemu.



Also, why are we
restricting ourselves to standard capabilities?


This version is to check whether it's on the right way and We can extend
this to pci extended capability later.


That's often a crowded
space and we can't always know whether an area is free or not based only
on it being covered by a capability.  Some capabilities can also appear
more than once, so there's context that isn't being passed to the kernel
here.  Thanks,


The region outside of PCI capability are not passed to kernel or used by 
Qemu for MSI/MSIX . It's possible to use these places for new 
capability. One concerns is that guest driver may abuse them and quirk 
of masking some special regs outside of capability maybe helpful.






Re: [Qemu-devel] [TCG only][Migration Bug? ] Occasionally, the content of VM's memory is inconsistent between Source and Destination of migration

2015-12-03 Thread Hailiang Zhang

On 2015/12/3 17:24, Dr. David Alan Gilbert wrote:

* Li Zhijian (lizhij...@cn.fujitsu.com) wrote:

Hi all,

Does anyboday remember the similar issue post by hailiang months ago
  http://patchwork.ozlabs.org/patch/454322/
At least tow bugs about migration had been fixed since that.


Yes, I wondered what happened to that.


And now we found the same issue at the tcg vm(kvm is fine), after migration,
the content VM's memory is inconsistent.


Hmm, TCG only - I don't know much about that; but I guess something must
be accessing memory without using the proper macros/functions so
it doesn't mark it as dirty.


we add a patch to check memory content, you can find it from affix

steps to reporduce:
1) apply the patch and re-build qemu
2) prepare the ubuntu guest and run memtest in grub.
soruce side:
x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device
e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive
if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device
virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0
-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp
tcp::,server,nowait -monitor stdio -cpu qemu64 -machine
pc-i440fx-2.3,accel=tcg,usb=off

destination side:
x86_64-softmmu/qemu-system-x86_64 -netdev tap,id=hn0 -device
e1000,id=net-pci0,netdev=hn0,mac=52:54:00:12:34:65 -boot c -drive
if=none,file=/home/lizj/ubuntu.raw,id=drive-virtio-disk0 -device
virtio-blk-pci,bus=pci.0,addr=0x4,drive=drive-virtio-disk0,id=virtio-disk0
-vnc :7 -m 128 -smp 1 -device piix3-usb-uhci -device usb-tablet -qmp
tcp::,server,nowait -monitor stdio -cpu qemu64 -machine
pc-i440fx-2.3,accel=tcg,usb=off -incoming tcp:0:8881

3) start migration
with 1000M NIC, migration will finish within 3 min.

at source:
(qemu) migrate tcp:192.168.2.66:8881
after saving ram complete
e9e725df678d392b1a83b3a917f332bb
qemu-system-x86_64: end ram md5
(qemu)

at destination:
...skip...
Completed load of VM with exit code 0 seq iteration 1264
Completed load of VM with exit code 0 seq iteration 1265
Completed load of VM with exit code 0 seq iteration 1266
qemu-system-x86_64: after loading state section id 2(ram)
49c2dac7bde0e5e22db7280dcb3824f9
qemu-system-x86_64: end ram md5
qemu-system-x86_64: qemu_loadvm_state: after cpu_synchronize_all_post_init

49c2dac7bde0e5e22db7280dcb3824f9
qemu-system-x86_64: end ram md5

This occurs occasionally and only at tcg machine. It seems that
some pages dirtied in source side don't transferred to destination.
This problem can be reproduced even if we disable virtio.

Is it OK for some pages that not transferred to destination when do
migration ? Or is it a bug?


I'm pretty sure that means it's a bug.  Hard to find though, I guess
at least memtest is smaller than a big OS.  I think I'd dump the whole
of memory on both sides, hexdump and diff them  - I'd guess it would
just be one byte/word different, maybe that would offer some idea what
wrote it.



Maybe one better way to do that is with the help of userfaultfd's write-protect
capability. It is still in the development by Andrea Arcangeli, but there
is a RFC version available, please refer to 
http://www.spinics.net/lists/linux-mm/msg97422.html
(I'm developing live memory snapshot which based on it, maybe this is another 
scene where we
can use userfaultfd's WP ;) ).



Dave


Any idea...

=md5 check patch=

diff --git a/Makefile.target b/Makefile.target
index 962d004..e2cb8e9 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -139,7 +139,7 @@ obj-y += memory.o cputlb.o
  obj-y += memory_mapping.o
  obj-y += dump.o
  obj-y += migration/ram.o migration/savevm.o
-LIBS := $(libs_softmmu) $(LIBS)
+LIBS := $(libs_softmmu) $(LIBS) -lplumb

  # xen support
  obj-$(CONFIG_XEN) += xen-common.o
diff --git a/migration/ram.c b/migration/ram.c
index 1eb155a..3b7a09d 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2513,7 +2513,7 @@ static int ram_load(QEMUFile *f, void *opaque, int
version_id)
  }

  rcu_read_unlock();
-DPRINTF("Completed load of VM with exit code %d seq iteration "
+fprintf(stderr, "Completed load of VM with exit code %d seq iteration "
  "%" PRIu64 "\n", ret, seq_iter);
  return ret;
  }
diff --git a/migration/savevm.c b/migration/savevm.c
index 0ad1b93..3feaa61 100644
--- a/migration/savevm.c
+++ b/migration/savevm.c
@@ -891,6 +891,29 @@ void qemu_savevm_state_header(QEMUFile *f)

  }

+#include "exec/ram_addr.h"
+#include "qemu/rcu_queue.h"
+#include 
+#ifndef MD5_DIGEST_LENGTH
+#define MD5_DIGEST_LENGTH 16
+#endif
+
+static void check_host_md5(void)
+{
+int i;
+unsigned char md[MD5_DIGEST_LENGTH];
+rcu_read_lock();
+RAMBlock *block = QLIST_FIRST_RCU(_list.blocks);/* Only check
'pc.ram' block */
+rcu_read_unlock();
+
+MD5(block->host, block->used_length, md);
+for(i = 0; i < MD5_DIGEST_LENGTH; i++) {
+fprintf(stderr, "%02x", md[i]);
+}
+fprintf(stderr, 

[Qemu-devel] blockcopy qemu fail and libvirt

2015-12-03 Thread Vasiliy Tolstov
Hi, i'm use qemu 2.4.0 and libvirt 1.2.16 and try blockcopy to migrate vm disk

virsh -c qemu+ssh://root@xxx/system blockcopy domain sda /dev/nbd2
--wait --pivot

libvirt says:
Successfully pivoted
2015-12-01 14:37:18.188+: 18288: info : libvirt version: 1.2.16
2015-12-01 14:37:18.188+: 18288: warning :
virEventPollUpdateTimeout:268 : Ignoring invalid update timer -1

but virsh command returns zero exit code

qemu blockcopy failed and target device contains zeroes.

i see some qemu git commits about block/migration and block that can
fix this isse, does qemu-devs confirm that this bug is fixed?

Also libvirt devs - do you know about this libvirt issue (when virsh
doing blockcopy and qemu process does not success complete blockcopy)
?

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru



Re: [Qemu-devel] [PATCH] mmap-alloc: tweak a comment on ppc64

2015-12-03 Thread Greg Kurz
On Thu, 3 Dec 2015 10:38:10 +0200
"Michael S. Tsirkin"  wrote:

> The comment I put in mmap-alloc to document the ppc64 rules
> refers to the previous revision of the patch:
> we don't look at memory alignment anymore, we check
> the fs from which the fd is mapped, instead.
> 
> It's also not clear what does "in this case" refer
> to, rearrange text to make it clearer.
> 
> Signed-off-by: Michael S. Tsirkin 
> ---

This is better indeed. Thanks !

Reviewed-by: Greg Kurz 

>  util/mmap-alloc.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/util/mmap-alloc.c b/util/mmap-alloc.c
> index 54793a5..5cd7f71 100644
> --- a/util/mmap-alloc.c
> +++ b/util/mmap-alloc.c
> @@ -50,10 +50,11 @@ void *qemu_ram_mmap(int fd, size_t size, size_t align, 
> bool shared)
>  #if defined(__powerpc64__) && defined(__linux__)
>  /* On ppc64 mappings in the same segment (aka slice) must share the same
>   * page size. Since we will be re-allocating part of this segment
> - * from the supplied fd, we should make sure to use the same page size,
> - * unless we are using the system page size, in which case anonymous 
> memory
> - * is OK. Use align as a hint for the page size.
> - * In this case, set MAP_NORESERVE to avoid allocating backing store 
> memory.
> + * from the supplied fd, we should make sure to use the same page size, 
> to
> + * this end we mmap the supplied fd.  In this case, set MAP_NORESERVE to
> + * avoid allocating backing store memory.
> + * We do this unless we are using the system page size, in which case
> + * anonymous memory is OK.
>   */
>  int anonfd = fd == -1 || qemu_fd_getpagesize(fd) == getpagesize() ? -1 : 
> fd;
>  int flags = anonfd == -1 ? MAP_ANONYMOUS : MAP_NORESERVE;




Re: [Qemu-devel] [PATCH COLO-Frame v11 18/39] COLO: Flush PVM's cached RAM into SVM's memory

2015-12-03 Thread Hailiang Zhang

On 2015/12/2 4:06, Dr. David Alan Gilbert wrote:

* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:

During the time of VM's running, PVM may dirty some pages, we will transfer
PVM's dirty pages to SVM and store them into SVM's RAM cache at next checkpoint
time. So, the content of SVM's RAM cache will always be some with PVM's memory
after checkpoint.

Instead of flushing all content of PVM's RAM cache into SVM's MEMORY,
we do this in a more efficient way:
Only flush any page that dirtied by PVM since last checkpoint.
In this way, we can ensure SVM's memory same with PVM's.

Besides, we must ensure flush RAM cache before load device state.

Signed-off-by: zhanghailiang 
Signed-off-by: Li Zhijian 
Signed-off-by: Gonglei 
---
v11:
- Move the place of 'need_flush' (Dave's suggestion)
- Remove unused 'DPRINTF("Flush ram_cache\n")'
v10:
- trace the number of dirty pages that be received.
---
  include/migration/migration.h |  1 +
  migration/colo.c  |  2 --
  migration/ram.c   | 37 +
  trace-events  |  1 +
  4 files changed, 39 insertions(+), 2 deletions(-)

diff --git a/include/migration/migration.h b/include/migration/migration.h
index e41372d..221176b 100644
--- a/include/migration/migration.h
+++ b/include/migration/migration.h
@@ -336,4 +336,5 @@ PostcopyState postcopy_state_set(PostcopyState new_state);
  /* ram cache */
  int colo_init_ram_cache(void);
  void colo_release_ram_cache(void);
+void colo_flush_ram_cache(void);
  #endif
diff --git a/migration/colo.c b/migration/colo.c
index 5ac8ff2..4095d97 100644
--- a/migration/colo.c
+++ b/migration/colo.c
@@ -385,8 +385,6 @@ void *colo_process_incoming_thread(void *opaque)
  }
  qemu_mutex_unlock_iothread();

-/* TODO: flush vm state */
-


Might have been better to put the TODO in a place that needed to be changed!



OK~


  ret = colo_ctl_put(mis->to_src_file, COLO_COMMAND_VMSTATE_LOADED, 0);
  if (ret < 0) {
  goto out;
diff --git a/migration/ram.c b/migration/ram.c
index da6bbd6..4f37144 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2448,6 +2448,7 @@ static int ram_load(QEMUFile *f, void *opaque, int 
version_id)
   * be atomic
   */
  bool postcopy_running = postcopy_state_get() >= 
POSTCOPY_INCOMING_LISTENING;
+bool need_flush = false;

  seq_iter++;

@@ -2482,6 +2483,7 @@ static int ram_load(QEMUFile *f, void *opaque, int 
version_id)
  /* After going into COLO, we should load the Page into colo_cache 
*/
  if (ram_cache_enable) {
  host = colo_cache_from_block_offset(block, addr);
+need_flush = true;
  } else {
  host = host_from_ram_block_offset(block, addr);
  }
@@ -2575,6 +2577,10 @@ static int ram_load(QEMUFile *f, void *opaque, int 
version_id)
  }

  rcu_read_unlock();
+
+if (!ret  && ram_cache_enable && need_flush) {
+colo_flush_ram_cache();
+}
  DPRINTF("Completed load of VM with exit code %d seq iteration "
  "%" PRIu64 "\n", ret, seq_iter);
  return ret;
@@ -2647,6 +2653,37 @@ void colo_release_ram_cache(void)
  rcu_read_unlock();
  }

+/*
+ * Flush content of RAM cache into SVM's memory.
+ * Only flush the pages that be dirtied by PVM or SVM or both.
+ */
+void colo_flush_ram_cache(void)
+{
+RAMBlock *block = NULL;
+void *dst_host;
+void *src_host;
+ram_addr_t  offset = 0;
+
+trace_colo_flush_ram_cache(migration_dirty_pages);
+rcu_read_lock();
+block = QLIST_FIRST_RCU(_list.blocks);
+while (block) {
+ram_addr_t ram_addr_abs;
+offset = migration_bitmap_find_dirty(block, offset, _addr_abs);
+migration_bitmap_clear_dirty(ram_addr_abs);
+if (offset >= block->used_length) {
+offset = 0;
+block = QLIST_NEXT_RCU(block, next);
+} else {
+dst_host = block->host + offset;
+src_host = block->colo_cache + offset;
+memcpy(dst_host, src_host, TARGET_PAGE_SIZE);
+}
+}
+rcu_read_unlock();


If you added a trace point here as well, it would make it very easy
to measure how long the flush was taking.



Good idea, i will add it in next version.


+assert(migration_dirty_pages == 0);
+}
+
  static SaveVMHandlers savevm_ram_handlers = {
  .save_live_setup = ram_save_setup,
  .save_live_iterate = ram_save_iterate,
diff --git a/trace-events b/trace-events
index f8a0959..f158d2a 100644
--- a/trace-events
+++ b/trace-events
@@ -1264,6 +1264,7 @@ migration_throttle(void) ""
  ram_load_postcopy_loop(uint64_t addr, int flags) "@%" PRIx64 " %x"
  ram_postcopy_send_discard_bitmap(void) ""
  ram_save_queue_pages(const char *rbname, size_t start, size_t len) "%s: start: %zx 
len: %zx"
+colo_flush_ram_cache(uint64_t 

[Qemu-devel] 答复: [RFC v1] virtio-crypto specification

2015-12-03 Thread Lingli Deng
Hi guys,

I am curious about the status of this proposal at OASIS. 
When is it planned for release? Is there any running PoC for the proposal? Is 
it still open? Any plan for upstreamming?

Thanks,
Lingli

-邮件原件-
发件人: Denis Crasta [mailto:denis.cra...@freescale.com] 
发送时间: 2015年11月26日 10:44
收件人: Lingli Deng; Varun Sethi; 'Gonglei (Arei)'; 
virtio-...@lists.oasis-open.org; qemu-devel@nongnu.org
抄送: 'Hanweidong (Randy)'; m...@redhat.com; 'Claudio Fontana'; 'Huangpeng 
(Peter)'; 'Lauri Leukkunen'; 'Jani Kokkonen'; Arun Pathak; Caraman Mike; Rajesh 
Kumar Madabushi; Silbermintz Michal; Grigore Sebastian
主题: RE: [RFC v1] virtio-crypto specification

+Rajesh, Michal, Sebastian

Denis

-Original Message-
From: Lingli Deng [mailto:denglin...@chinamobile.com]
Sent: Wednesday, November 25, 2015 6:31 PM
To: Sethi Varun-B16395 ; 'Gonglei (Arei)' 
; virtio-...@lists.oasis-open.org; 
qemu-devel@nongnu.org
Cc: 'Hanweidong (Randy)' ; m...@redhat.com; 'Claudio 
Fontana' ; 'Huangpeng (Peter)' 
; 'Lauri Leukkunen' ; 
'Jani Kokkonen' ; Crasta Denis-B22176 
; Pathak Arun-B33046 ; 
Caraman Mihai Claudiu-B02008 
Subject: 答复: [RFC v1] virtio-crypto specification

Hi Varun,

Thanks for the bridging. 

Hi Gonglei and virtio-crypto guys, 

As Varun said, dpacc is working on enabling the portability of data plane VNFs 
(leveraging software/hardware accelerators in the host) across hardware 
platforms, and virtio extensions for such accelerator had been recognized as a 
promising solution. In particular, we are interested in the use-case of a 
smallcell GW VNF, where hardware/host accelerators are used for crypto 
offloading. As part of the OPNFV initiative, we are targeting at adding 
features to the open-source platform, which would used as a reference 
implementation for NFV deployment.

However, we are not member of OASIS, and is not familiar with its organization 
or procedure. So we start with the gap analysis and the PoC implementation, 
without knowing that there is actually an OASIS thread taking place in parallel.

I understand it may not the the only application scenario for virtio-crypto 
spec you are doing, but assume it could be an interesting one in operators' NFV 
deployment.

I believe we should definitely encourage this discussion and try to work 
together. 
I suppose we can start with an exchange of what we expect in our usecase and 
PoC with what you would provide with the specified virtual device.

Please advise how we can start collaboration.

Regards,
Lingli
+86 13810597148

-邮件原件-
发件人: Varun Sethi [mailto:varun.se...@freescale.com]
发送时间: 2015年11月25日 20:41
收件人: Gonglei (Arei); virtio-...@lists.oasis-open.org; qemu-devel@nongnu.org
抄送: Hanweidong (Randy); m...@redhat.com; Claudio Fontana; Huangpeng (Peter); 
Lauri Leukkunen; Jani Kokkonen; Denis Crasta; Arun Pathak; Lingli Deng; Caraman 
Mike
主题: RE: [RFC v1] virtio-crypto specification

Hi Gonglei,
Please find my comments inline.

Regards
Varun

> -Original Message-
> From: Gonglei (Arei) [mailto:arei.gong...@huawei.com]
> Sent: Wednesday, November 25, 2015 1:14 PM
> To: Sethi Varun-B16395 ;
> virtio-dev@lists.oasis- open.org; qemu-devel@nongnu.org
> Cc: Hanweidong (Randy) ; m...@redhat.com; 
> Claudio Fontana ; Huangpeng (Peter) 
> ; Lauri Leukkunen 
> ; Jani Kokkonen 
> ; Crasta Denis-B22176 
> ; Pathak Arun-B33046 
> 
> Subject: RE: [RFC v1] virtio-crypto specification
> 
> Hello Varun,
> 
> 
> > -Original Message-
> > From: Varun Sethi [mailto:varun.se...@freescale.com]
> > Sent: Wednesday, November 25, 2015 3:08 AM
> > Subject: RE: [RFC v1] virtio-crypto specification
> >
> > Hi Gonglei,
> > We have been working on the virtio-ipsec  look-aside accelerator 
> > device specification at the OPNFV DPACC forum. The virtio-ipsec 
> > device is aimed at providing the protocol offload capabilities 
> > (offered by security hardware
> > accelerator) to the VM. The device supports a control queue and 
> > encap/decap queue pair per guest vcpu (multi queue support). Based 
> > on the feature bits, a notification queue can also be supported.
> > Following document gives the details for the virtio-ipsec device:
> > https://wiki.opnfv.org/_media/dpacc/freescale-ipsec-virtual-accelera
> > tor-rev-
> 3.
> > docx
> >
> > Currently we are focusing on userspace virtio-ipsec backend emulation.
> > We are working on a POC  for vhost-user IPSec backend emulation and 
> > guest VM kernel virtio-ipsec driver.
> >
> > Following document provides guest API details to utilize 

[Qemu-devel] [PATCH v4 2/3] qemu-iotests: s390x: fix test 051

2015-12-03 Thread Bo Tu
From: Bo Tu  

The tests for ide device should only be tested for the pc
platform.
Set device_id to "drive0", and replace every "-drive file..."
by "-drive file=...,if=none,id=$device_id", then x86 and s390x
can get the common output in the test of "Snapshot mode".
Warning message expected for s390x when drive without device.
A x86 platform specific output file is also needed.

Reviewed-by: Sascha Silbe 
Signed-off-by: Bo Tu 
---
 tests/qemu-iotests/051|  95 ++
 tests/qemu-iotests/051.out| 163 
 tests/qemu-iotests/051.pc.out | 422 ++
 3 files changed, 521 insertions(+), 159 deletions(-)
 create mode 100644 tests/qemu-iotests/051.pc.out

diff --git a/tests/qemu-iotests/051 b/tests/qemu-iotests/051
index 17dbf04..286b6cd 100755
--- a/tests/qemu-iotests/051
+++ b/tests/qemu-iotests/051
@@ -148,33 +148,49 @@ run_qemu -drive if=ide
 run_qemu -drive if=virtio
 run_qemu -drive if=scsi
 
-run_qemu -drive if=none,id=disk -device ide-cd,drive=disk
-run_qemu -drive if=none,id=disk -device lsi53c895a -device scsi-cd,drive=disk
-
-run_qemu -drive if=none,id=disk -device ide-drive,drive=disk
-run_qemu -drive if=none,id=disk -device ide-hd,drive=disk
-run_qemu -drive if=none,id=disk -device lsi53c895a -device scsi-disk,drive=disk
-run_qemu -drive if=none,id=disk -device lsi53c895a -device scsi-hd,drive=disk
+case "$QEMU_DEFAULT_MACHINE" in
+pc)
+run_qemu -drive if=none,id=disk -device ide-cd,drive=disk
+run_qemu -drive if=none,id=disk -device lsi53c895a -device 
scsi-cd,drive=disk
+run_qemu -drive if=none,id=disk -device ide-drive,drive=disk
+run_qemu -drive if=none,id=disk -device ide-hd,drive=disk
+run_qemu -drive if=none,id=disk -device lsi53c895a -device 
scsi-disk,drive=disk
+run_qemu -drive if=none,id=disk -device lsi53c895a -device 
scsi-hd,drive=disk
+;;
+ *)
+;;
+esac
 
 echo
 echo === Read-only ===
 echo
 
-run_qemu -drive file="$TEST_IMG",if=floppy,readonly=on
-run_qemu -drive file="$TEST_IMG",if=ide,media=cdrom,readonly=on
-run_qemu -drive file="$TEST_IMG",if=scsi,media=cdrom,readonly=on
+case "$QEMU_DEFAULT_MACHINE" in
+pc)
+run_qemu -drive file="$TEST_IMG",if=floppy,readonly=on
+run_qemu -drive file="$TEST_IMG",if=ide,media=cdrom,readonly=on
+run_qemu -drive file="$TEST_IMG",if=scsi,media=cdrom,readonly=on
+run_qemu -drive file="$TEST_IMG",if=ide,readonly=on
+;;
+ *)
+;;
+esac
 
-run_qemu -drive file="$TEST_IMG",if=ide,readonly=on
 run_qemu -drive file="$TEST_IMG",if=virtio,readonly=on
 run_qemu -drive file="$TEST_IMG",if=scsi,readonly=on
 
-run_qemu -drive file="$TEST_IMG",if=none,id=disk,readonly=on -device 
ide-cd,drive=disk
-run_qemu -drive file="$TEST_IMG",if=none,id=disk,readonly=on -device 
lsi53c895a -device scsi-cd,drive=disk
-
-run_qemu -drive file="$TEST_IMG",if=none,id=disk,readonly=on -device 
ide-drive,drive=disk
-run_qemu -drive file="$TEST_IMG",if=none,id=disk,readonly=on -device 
ide-hd,drive=disk
-run_qemu -drive file="$TEST_IMG",if=none,id=disk,readonly=on -device 
lsi53c895a -device scsi-disk,drive=disk
-run_qemu -drive file="$TEST_IMG",if=none,id=disk,readonly=on -device 
lsi53c895a -device scsi-hd,drive=disk
+case "$QEMU_DEFAULT_MACHINE" in
+pc)
+run_qemu -drive file="$TEST_IMG",if=none,id=disk,readonly=on -device 
ide-cd,drive=disk
+run_qemu -drive file="$TEST_IMG",if=none,id=disk,readonly=on -device 
lsi53c895a -device scsi-cd,drive=disk
+run_qemu -drive file="$TEST_IMG",if=none,id=disk,readonly=on -device 
ide-drive,drive=disk
+run_qemu -drive file="$TEST_IMG",if=none,id=disk,readonly=on -device 
ide-hd,drive=disk
+run_qemu -drive file="$TEST_IMG",if=none,id=disk,readonly=on -device 
lsi53c895a -device scsi-disk,drive=disk
+run_qemu -drive file="$TEST_IMG",if=none,id=disk,readonly=on -device 
lsi53c895a -device scsi-hd,drive=disk
+;;
+ *)
+;;
+esac
 
 echo
 echo === Cache modes ===
@@ -183,12 +199,18 @@ echo
 # Cannot use the test image because cache=none might not work on the host FS
 # Use cdrom so that we won't get errors about missing media
 
-run_qemu -drive media=cdrom,cache=none
-run_qemu -drive media=cdrom,cache=directsync
-run_qemu -drive media=cdrom,cache=writeback
-run_qemu -drive media=cdrom,cache=writethrough
-run_qemu -drive media=cdrom,cache=unsafe
-run_qemu -drive media=cdrom,cache=invalid_value
+case "$QEMU_DEFAULT_MACHINE" in
+pc)
+run_qemu -drive media=cdrom,cache=none
+run_qemu -drive media=cdrom,cache=directsync
+run_qemu -drive media=cdrom,cache=writeback
+run_qemu -drive media=cdrom,cache=writethrough
+run_qemu -drive media=cdrom,cache=unsafe
+run_qemu -drive media=cdrom,cache=invalid_value
+;;
+ *)
+;;
+esac
 
 echo
 echo === Specifying the 

Re: [Qemu-devel] Wiki account request (was: Re: Highlighting changes in QEMU 2.5)

2015-12-03 Thread Peter Maydell
On 3 December 2015 at 09:43, Thomas Huth  wrote:
>> On (Tue) 24 Nov 2015 [10:28:25], Amit Shah wrote:
>>> Hello,
>>>
>>> The 2.5 release is close - and I'm collecting a list of notable
>>> changes and features once more.  The video made for the 2.4 release
>>> [1] was popular, and I'm volunteering to make one for 2.5 as well.  In
>>> addition, we need more feature pages, and there's a template at [2]
>>> that you can use to base feature pages off.
>
> I'd like to add a feature page for the H_RANDOM feature that I've
> contributed in this release cycle (see the commit message for details:
> http://git.qemu.org/?p=qemu.git;a=commit;h=4d9392be6c1aada69ce86c),
> since I think it might be good to document for the users how to use this
> feature.
>
> However, I do not have an Wiki account yet. Would it be possible to get
> an account for this?

Sure, I can create you an account -- let me know what username you want.

thanks
-- PMM



Re: [Qemu-devel] [PATCH v5] bt: check struct sizes

2015-12-03 Thread Michael Tokarev
30.11.2015 12:57, Paolo Bonzini wrote:
> See http://permalink.gmane.org/gmane.linux.bluez.kernel/36505.  For historical
> reasons these do not use sizeof, and Coverity caught a mistake in
> EVT_ENCRYPT_CHANGE_SIZE.
...

Applied to -trivial.  Oh well!.. :)

Thanks,

/mjt



[Qemu-devel] [PATCH v4 3/3] qemu-iotests: s390x: fix test 068

2015-12-03 Thread Bo Tu
Now, s390-virtio-ccw is default machine and s390-ccw.img is default boot
loader. If the s390-virtio-ccw machine finds no device to load from and
errors out, then emits a panic and exits the vm. This breaks test cases
068 for s390x.
Adding the parameter of "-no-shutdown" for s390-ccw-virtio will pause VM
before shutdown.

Acked-by: Max Reitz 
Reviewed-by: Sascha Silbe 
Signed-off-by: Bo Tu 
---
 tests/qemu-iotests/068 | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/tests/qemu-iotests/068 b/tests/qemu-iotests/068
index b72e555..58d1d80 100755
--- a/tests/qemu-iotests/068
+++ b/tests/qemu-iotests/068
@@ -50,13 +50,23 @@ echo
 echo "=== Saving and reloading a VM state to/from a qcow2 image ==="
 echo
 _make_test_img $IMG_SIZE
+
+case "$QEMU_DEFAULT_MACHINE" in
+  s390-ccw-virtio)
+  platform_parm="-no-shutdown -machine accel=kvm"
+  ;;
+  *)
+  platform_parm=""
+  ;;
+esac
+
 # Give qemu some time to boot before saving the VM state
 bash -c 'sleep 1; echo -e "savevm 0\nquit"' |\
-$QEMU -nographic -monitor stdio -serial none -hda "$TEST_IMG" |\
+$QEMU $platform_parm -nographic -monitor stdio -serial none -hda 
"$TEST_IMG" |\
 _filter_qemu
 # Now try to continue from that VM state (this should just work)
 echo quit |\
-$QEMU -nographic -monitor stdio -serial none -hda "$TEST_IMG" -loadvm 0 |\
+$QEMU $platform_parm -nographic -monitor stdio -serial none -hda 
"$TEST_IMG" -loadvm 0 |\
 _filter_qemu
 
 # success, all done
-- 
2.4.3




[Qemu-devel] [PATCH v4 0/3] Update tests/qemu-iotests failing cases for the s390 platform

2015-12-03 Thread Bo Tu
From: Bo Tu  

v4:
1. Remove 051.s390.out, and rollback the changes in Makefile to generate
051.s390-ccw-virtio.out
2. Use 051.out as the common output for any non-pc platform
3. Set device_id to "drive0", and replace every "-drive file..."
by "-drive file=...,if=none,id=$device_id", then x86 and s390x
can get the common output in the test of "Snapshot mode" for test 051
4. Update 051.out and 051.pc.out

v3:
1. Remove patch for test 120 because Fam Zheng upstreamed same fix for
test 119 and 120
2. Rename 051.out to 051.s390.out, add rule in Makefile to generate
051.s390-ccw-virtio.out
3. Remove superfluous quotation marks in common.config
4. Add "Acked-by: Max Reitz " for test 068,
add "Reviewed-by: Max Reitz " for test 051 and common.config

v2:
1. Refine common.config via changing the definition of default_alias_machine
and default_machine
2. Add Reviewed-by of Eric Blake for common.config

v1:
1. Refine common.config
2. Update the output file for test 051 based on its current
output for s390 platform, add a pc specific output file for test 051
3. checkpatch.pl reports invaid UTF-8 error for 051 patch,
because its output files contain some non-text data
4. Add the parameter of "-no-shutdown -machine accel=kvm" for
s390-ccw-virtio for test 068
5. Disable VNC server for test 120

Bo Tu (3):
  qemu-iotests: refine common.config
  qemu-iotests: s390x: fix test 051
  qemu-iotests: s390x: fix test 068

 tests/qemu-iotests/051   |  95 +
 tests/qemu-iotests/051.out   | 163 ---
 tests/qemu-iotests/051.pc.out| 422 +++
 tests/qemu-iotests/068   |  14 +-
 tests/qemu-iotests/common.config |   9 +-
 5 files changed, 537 insertions(+), 166 deletions(-)
 create mode 100644 tests/qemu-iotests/051.pc.out

-- 
2.4.3




[Qemu-devel] [PATCH v4 1/3] qemu-iotests: refine common.config

2015-12-03 Thread Bo Tu
From: Bo Tu  

Replacing awk with sed, then it's easier to read.
Replacing "[ ! -z "$default_alias_machine" ]" with
"[[ $default_alias_machine ]]", then it's slightly shorter.

Reviewed-by: Max Reitz 
Suggested-By: Sascha Silbe 
Reviewed-by: Sascha Silbe 
Reviewed-by: Eric Blake   
Signed-off-by: Bo Tu 
---
 tests/qemu-iotests/common.config | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/tests/qemu-iotests/common.config b/tests/qemu-iotests/common.config
index 3ed51b8..60bfabf 100644
--- a/tests/qemu-iotests/common.config
+++ b/tests/qemu-iotests/common.config
@@ -154,11 +154,10 @@ export QEMU_IMG=_qemu_img_wrapper
 export QEMU_IO=_qemu_io_wrapper
 export QEMU_NBD=_qemu_nbd_wrapper
 
-default_machine=$($QEMU -machine \? | awk '/(default)/{print $1}')
-default_alias_machine=$($QEMU -machine \? |\
-awk -v var_default_machine="$default_machine"\)\
-'{if ($(NF-2)=="(alias"&&$(NF-1)=="of"&&$(NF)==var_default_machine){print 
$1}}')
-if [ ! -z "$default_alias_machine" ]; then
+default_machine=$($QEMU -machine help | sed -n '/(default)/ s/ .*//p')
+default_alias_machine=$($QEMU -machine help | \
+   sed -n "/(alias of $default_machine)/ { s/ .*//p; q; }")
+if [[ "$default_alias_machine" ]]; then
 default_machine="$default_alias_machine"
 fi
 
-- 
2.4.3




Re: [Qemu-devel] [PATCH COLO-Frame v11 16/39] ram/COLO: Record the dirty pages that SVM received

2015-12-03 Thread Hailiang Zhang

On 2015/12/2 3:36, Dr. David Alan Gilbert wrote:

* zhanghailiang (zhang.zhanghaili...@huawei.com) wrote:

We record the address of the dirty pages that received,
it will help flushing pages that cached into SVM.
We record them by re-using migration dirty bitmap.

Signed-off-by: zhanghailiang 
---
v11:
- Split a new helper function from original
   host_from_stream_offset() (Dave's suggestion)
- Only do recording work in this patch
v10:
- New patch split from v9's patch 13
- Rebase to master to use 'migration_bitmap_rcu'
---
  migration/ram.c | 30 ++
  1 file changed, 30 insertions(+)

diff --git a/migration/ram.c b/migration/ram.c
index 9d946a1..da6bbd6 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -2153,6 +2153,7 @@ static inline RAMBlock *ram_block_from_stream(QEMUFile *f,

  return block;
  }
+
  len = qemu_get_byte(f);
  qemu_get_buffer(f, (uint8_t *)id, len);
  id[len] = 0;


That blank should probably go, but other than that:



I will remove it, thanks.


Reviewed-by: Dr. David Alan Gilbert 

Dave


@@ -2179,10 +2180,23 @@ static inline void *host_from_ram_block_offset(RAMBlock 
*block,
  static inline void *colo_cache_from_block_offset(RAMBlock *block,
   ram_addr_t offset)
  {
+unsigned long *bitmap;
+long k;
+
  if (!block) {
  return NULL;
  }

+k = (block->mr->ram_addr + offset) >> TARGET_PAGE_BITS;
+bitmap = atomic_rcu_read(_bitmap_rcu)->bmap;
+/*
+* During colo checkpoint, we need bitmap of these migrated pages.
+* It help us to decide which pages in ram cache should be flushed
+* into VM's RAM later.
+*/
+if (!test_and_set_bit(k, bitmap)) {
+migration_dirty_pages++;
+}
  return block->colo_cache + offset;
  }

@@ -2573,6 +2587,7 @@ static int ram_load(QEMUFile *f, void *opaque, int 
version_id)
  int colo_init_ram_cache(void)
  {
  RAMBlock *block;
+int64_t ram_cache_pages = last_ram_offset() >> TARGET_PAGE_BITS;

  rcu_read_lock();
  QLIST_FOREACH_RCU(block, _list.blocks, next) {
@@ -2587,6 +2602,15 @@ int colo_init_ram_cache(void)
  }
  rcu_read_unlock();
  ram_cache_enable = true;
+/*
+* Record the dirty pages that sent by PVM, we use this dirty bitmap 
together
+* with to decide which page in cache should be flushed into SVM's RAM. Here
+* we use the same name 'migration_bitmap_rcu' as for migration.
+*/
+migration_bitmap_rcu = g_new0(struct BitmapRcu, 1);
+migration_bitmap_rcu->bmap = bitmap_new(ram_cache_pages);
+migration_dirty_pages = 0;
+
  return 0;

  out_locked:
@@ -2604,9 +2628,15 @@ out_locked:
  void colo_release_ram_cache(void)
  {
  RAMBlock *block;
+struct BitmapRcu *bitmap = migration_bitmap_rcu;

  ram_cache_enable = false;

+atomic_rcu_set(_bitmap_rcu, NULL);
+if (bitmap) {
+call_rcu(bitmap, migration_bitmap_free, rcu);
+}
+
  rcu_read_lock();
  QLIST_FOREACH_RCU(block, _list.blocks, next) {
  if (block->colo_cache) {
--
1.8.3.1



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

.







Re: [Qemu-devel] [RFC PATCH V2 06/10] Qemu/PCI: Add macros for faked PCI migration capability

2015-12-03 Thread Lan, Tianyu



On 12/3/2015 6:25 AM, Alex Williamson wrote:

This will of course break if the PCI SIG defines that capability index.
Couldn't this be done within a vendor defined capability?  Thanks,


Yes, it should work and thanks for suggestion.



[Qemu-devel] [PATCH 2/2] migration: code clean up.

2015-12-03 Thread Liang Li
Use qemu_put_compression_data to do the compression directly
instead of using do_compress_ram_page, avoid some data copy.
very small improvement, but the code looks better.

Signed-off-by: Liang Li 
---
 migration/ram.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/migration/ram.c b/migration/ram.c
index 1eb155a..44b3edc 100644
--- a/migration/ram.c
+++ b/migration/ram.c
@@ -911,22 +911,18 @@ static int ram_save_compressed_page(QEMUFile *f, RAMBlock 
*block,
 uint64_t *bytes_transferred)
 {
 int pages = -1;
-uint64_t bytes_xmit;
+uint64_t bytes_xmit = 0;
 uint8_t *p;
 int ret;
 
 p = block->host + offset;
 
-bytes_xmit = 0;
 ret = ram_control_save_page(f, block->offset,
 offset, TARGET_PAGE_SIZE, _xmit);
 if (bytes_xmit) {
 *bytes_transferred += bytes_xmit;
 pages = 1;
 }
-if (block == last_sent_block) {
-offset |= RAM_SAVE_FLAG_CONTINUE;
-}
 if (ret != RAM_SAVE_CONTROL_NOT_SUPP) {
 if (ret != RAM_SAVE_CONTROL_DELAYED) {
 if (bytes_xmit > 0) {
@@ -946,17 +942,17 @@ static int ram_save_compressed_page(QEMUFile *f, RAMBlock 
*block,
 flush_compressed_data(f);
 pages = save_zero_page(f, block, offset, p, bytes_transferred);
 if (pages == -1) {
-set_compress_params(_param[0], block, offset);
-/* Use the qemu thread to compress the data to make sure the
- * first page is sent out before other pages
- */
-bytes_xmit = do_compress_ram_page(_param[0]);
-acct_info.norm_pages++;
-qemu_put_qemu_file(f, comp_param[0].file);
+/* Make sure the first page is sent out before other pages */
+bytes_xmit = save_page_header(f, block, offset |
+  RAM_SAVE_FLAG_COMPRESS_PAGE);
+bytes_xmit += qemu_put_compression_data(f, p, TARGET_PAGE_SIZE,
+migrate_compress_level());
 *bytes_transferred += bytes_xmit;
+acct_info.norm_pages++;
 pages = 1;
 }
 } else {
+offset |= RAM_SAVE_FLAG_CONTINUE;
 pages = save_zero_page(f, block, offset, p, bytes_transferred);
 if (pages == -1) {
 pages = compress_page_with_multi_thread(f, block, offset,
-- 
1.9.1




[Qemu-devel] [PATCH 1/2] qemu-file: fix flaws of qemu_put_compression_data

2015-12-03 Thread Liang Li
There are some flaws in qemu_put_compression_data, this patch tries
to fix it. Now it can be used by other code.

Signed-off-by: Liang Li 
---
 migration/qemu-file.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/migration/qemu-file.c b/migration/qemu-file.c
index 0bbd257..ef9cd4a 100644
--- a/migration/qemu-file.c
+++ b/migration/qemu-file.c
@@ -616,7 +616,9 @@ ssize_t qemu_put_compression_data(QEMUFile *f, const 
uint8_t *p, size_t size,
 ssize_t blen = IO_BUF_SIZE - f->buf_index - sizeof(int32_t);
 
 if (blen < compressBound(size)) {
-return 0;
+if (f->ops->writev_buffer || f->ops->put_buffer) {
+qemu_fflush(f);
+}
 }
 if (compress2(f->buf + f->buf_index + sizeof(int32_t), (uLongf *),
   (Bytef *)p, size, level) != Z_OK) {
@@ -624,7 +626,13 @@ ssize_t qemu_put_compression_data(QEMUFile *f, const 
uint8_t *p, size_t size,
 return 0;
 }
 qemu_put_be32(f, blen);
+if (f->ops->writev_buffer) {
+add_to_iovec(f, f->buf + f->buf_index, blen);
+}
 f->buf_index += blen;
+if (f->buf_index == IO_BUF_SIZE) {
+qemu_fflush(f);
+}
 return blen + sizeof(int32_t);
 }
 
-- 
1.9.1




  1   2   3   >