date:20160529




On 2016年05月29日 00:37, w...@redhat.com wrote:

From: Wei Xu 

Field 'coalesced' is to indicate how many packets are coalesced and field
'dup_ack' is how many duplicate acks are merged, guest driver can use these
information to notify what's the exact scene of original traffic over the
networks.

Signed-off-by: Wei Xu 
---
  hw/net/virtio-net.c | 8 
  include/standard-headers/linux/virtio_net.h | 2 ++
  2 files changed, 10 insertions(+)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index cc8cbe4..20f552a 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -1768,6 +1768,10 @@ static size_t virtio_net_rsc_drain_seg(NetRscChain 
*chain, NetRscSeg *seg)
  if ((chain->proto == ETH_P_IP) && seg->is_coalesced) {
  virtio_net_rsc_ipv4_checksum(h, seg->unit.ip);
  }
+h->coalesced = seg->packets;
+h->dup_ack = seg->dup_ack;
+h->gso_type = chain->gso_type;
+h->gso_size = chain->max_payload;
  ret = virtio_net_do_receive(seg->nc, seg->buf, seg->size);
  QTAILQ_REMOVE(>buffers, seg, next);
  g_free(seg->buf);
@@ -2302,9 +2306,13 @@ static ssize_t virtio_net_receive(NetClientState *nc,
const uint8_t *buf, size_t size)
  {
  VirtIONet *n;
+struct virtio_net_hdr *h;
  
  n = qemu_get_nic_opaque(nc);

  if (n->host_features & (1ULL << VIRTIO_NET_F_GUEST_RSC)) {
+h = (struct virtio_net_hdr *)buf;
+h->coalesced = 0;
+h->dup_ack = 0;
  return virtio_net_rsc_receive(nc, buf, size);
  } else {
  return virtio_net_do_receive(nc, buf, size);
diff --git a/include/standard-headers/linux/virtio_net.h 
b/include/standard-headers/linux/virtio_net.h
index 5b95762..c837417 100644
--- a/include/standard-headers/linux/virtio_net.h
+++ b/include/standard-headers/linux/virtio_net.h
@@ -114,6 +114,8 @@ struct virtio_net_hdr {
__virtio16 gso_size;/* Bytes to append to hdr_len per frame 
*/
__virtio16 csum_start;  /* Position to start checksumming from */
__virtio16 csum_offset; /* Offset after that to place checksum */
+__virtio16 coalesced;   /* packets coalesced by host */


Can we just reuse gso_segs for this?


+__virtio16 dup_ack; /* duplicate ack count */
  };
  
  /* This is the version of the header to use when the MRG_RXBUF

Re: [Qemu-devel] [PATCH v7 07/25] intel_iommu: define several structs for IOMMU IR

2016-05-29 Thread Jan Kiszka

On 2016-05-30 07:45, Peter Xu wrote:
> On Sun, May 29, 2016 at 11:21:35AM +0300, David Kiarie wrote:
> [...]
 +
 +/* Programming format for MSI/MSI-X addresses */
 +union VTD_IR_MSIAddress {
 +struct {
 +uint8_t __not_care:2;
 +uint8_t index_h:1;  /* Interrupt index bit 15 */
 +uint8_t sub_valid:1;/* SHV: Sub-Handle Valid bit */
 +uint8_t int_mode:1; /* Interrupt format */
 +uint16_t index_l:15;/* Interrupt index bit 14-0 */
 +uint16_t __head:12; /* Should always be: 0x0fee */
 +} QEMU_PACKED;
 +uint32_t data;
 +};
>>>
>>> In a recent discussion, it was brought to my attention that you might
>>> have a problem with bitfields when the host cpu is not x86. Have you
>>> considered this ?
>>
>> In a case when say the host cpu is little endian.
> 
> I assume you mean when host cpu is big endian. x86 was little endian,
> and I was testing on x86.
> 
> I think you are right. I should do conditional byte swap for all
> uint{16/32/64} cases within the fields. For example, index_l field in
> above VTD_IR_MSIAddress. And there are several other cases that need
> special treatment in the patchset. Will go over and fix corresponding
> issues in next version.

You actually need bit-swap with bit fields, see e.g. hw/net/vmxnet3.h.

Jan




signature.asc
Description: OpenPGP digital signature

Re: [Qemu-devel] [PATCH v7 07/25] intel_iommu: define several structs for IOMMU IR

2016-05-29 Thread Peter Xu

On Sun, May 29, 2016 at 11:21:35AM +0300, David Kiarie wrote:
[...]
> >> +
> >> +/* Programming format for MSI/MSI-X addresses */
> >> +union VTD_IR_MSIAddress {
> >> +struct {
> >> +uint8_t __not_care:2;
> >> +uint8_t index_h:1;  /* Interrupt index bit 15 */
> >> +uint8_t sub_valid:1;/* SHV: Sub-Handle Valid bit */
> >> +uint8_t int_mode:1; /* Interrupt format */
> >> +uint16_t index_l:15;/* Interrupt index bit 14-0 */
> >> +uint16_t __head:12; /* Should always be: 0x0fee */
> >> +} QEMU_PACKED;
> >> +uint32_t data;
> >> +};
> >
> > In a recent discussion, it was brought to my attention that you might
> > have a problem with bitfields when the host cpu is not x86. Have you
> > considered this ?
> 
> In a case when say the host cpu is little endian.

I assume you mean when host cpu is big endian. x86 was little endian,
and I was testing on x86.

I think you are right. I should do conditional byte swap for all
uint{16/32/64} cases within the fields. For example, index_l field in
above VTD_IR_MSIAddress. And there are several other cases that need
special treatment in the patchset. Will go over and fix corresponding
issues in next version.

Thanks!

-- peterx

Re: [Qemu-devel] [ RFC Patch v6 0/2] Support Receive-Segment-Offload(RSC) for WHQL

2016-05-29 Thread Wei Xu



On 2016年05月30日 12:22, Jason Wang wrote:



On 2016年05月29日 00:37, w...@redhat.com wrote:

From: Wei Xu 

Changes in V6:
- Sync upstream code
- Split new fields in 'virtio_net_hdr' to a seperate patch
- Remove feature bit code, replace it with a command line parameter
'guest_rsc'
which is turned off by default.

Changes in V5:
- Passed all IPv4/6 test cases
- Add new fields in 'virtio_net_hdr'
- Set 'gso_type' & 'coalesced packets' in new field.
- Bypass all 'tcp option' packet
- Bypass all 'pure ack' packet
- Bypass all 'duplicate ack' packet
- Change 'guest_rsc' feature bit to 'false' by default
- Feedbacks from v4, typo, etc.


Change-log is very important for the ease and speed up reviewers. More
details are more than welcomed. But I see some changes were not
documented here. Please give a more complete one in next iteration.

OK.




Note:
There is still a few pending issues about the feature bit, and need to be
discussed with windows driver maintainer, so linux guests with this patch
won't work at current, haven't figure it out yet, but i'm guessing it's
caused by the 'gso_type' is set to 'VIRTIO_NET_HDR_GSO_TCPV4/6',
will fix it after get the final solution, the below test steps and
performance data is based on v4.


This is probably because you've increased the vnet header length.



Another suggestion from Jason is to adjust part of the code to make it
more readable, since there maybe still few change about the flowchart
in the future, such as timestamp, duplicate ack, so i'd like to delay it
temporarily.

Changes in V4:
- Add new host feature bit
- Replace using fixed header lenght with dynamic header lenght in
VirtIONet
- Change ip/ip6 header union in NetRscUnit to void* pointer
- Add macro prefix, adjust code indent, etc.

Changes in V3:
- Removed big param list, replace it with 'NetRscUnit'
- Different virtio header size
- Modify callback function to direct call.
- Needn't check the failure of g_malloc()
- Other code format adjustment, macro naming, etc

Changes in V2:
- Add detailed commit log

This patch is to support WHQL test for Windows guest, while this
feature also
benifits other guest works as a kernel 'gro' like feature with userspace
implementation.
Feature information:
   http://msdn.microsoft.com/en-us/library/windows/hardware/jj853324

Both IPv4 and IPv6 are supported, though performance with userspace
virtio
is slow than vhost-net, there is about 1.5x to 2x performance
improvement to
userspace virtio, this is done by turning this feature on and disable
'tso/gso/gro' on corresponding tap interface and guest interface,
while get
less improment with all these feature on.

Linux guest performance data(Netperf):
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to
192.168.2.101 () port 0 AF_INET : nodelay
Size   SizeSize Time Throughput
bytes  bytes   bytessecs.10^6bits/sec

  87380  16384 646.00 1221.20
  87380  16384 646.00 1260.30

  87380  163841286.00 1978.51
  87380  163841286.00 2286.05

  87380  163842566.00 2677.94
  87380  163842566.00 4615.42

  87380  163845126.00 2956.54
  87380  163845126.00 5356.39

  87380  16384   10246.00 2798.17
  87380  16384   10246.00 4943.30

  87380  16384   20486.00 2681.09
  87380  16384   20486.00 4835.81

  87380  16384   40966.00 3390.14
  87380  16384   40966.00 5391.54

  87380  16384   80926.00 3008.27
  87380  16384   80926.00 5381.68

  87380  16384  102406.00 2999.89
  87380  16384  102406.00 5393.11

Test steps:
Although this feature is mainly used for window guest, i used linux
guest to
help test the feature, to make things simple, i used 3 steps to test
the patch
as i moved on.

1. With a tcp socket client/server pair running on 2 linux guest, thus
i can
control
the traffic and debugging the code as i want.
2. Netperf on linux guest test the throughput.
3. WHQL test with 2 Windows guests.

Wei Xu (3):
   virtio-net rsc: support coalescing ipv4 tcp traffic
   virtio-net rsc: support coalescing ipv6 tcp traffic
   virtio-net rsc: add 2 new rsc information fields to 'virtio_net_hdr'

  hw/net/virtio-net.c | 642
+++-
  include/hw/virtio/virtio-net.h  |   2 +
  include/hw/virtio/virtio.h  |  75 
  include/standard-headers/linux/virtio_net.h |   3 +
  4 files changed, 721 insertions(+), 1 deletion(-)

Re: [Qemu-devel] [ RFC Patch v6 2/3] virtio-net rsc: support coalescing ipv6 tcp traffic




On 2016年05月29日 00:37, w...@redhat.com wrote:

From: Wei Xu 

Most stuffs are like ipv4 2 differences between ipv4 and ipv6.

1. Fragment length in ipv4 header includes itself, while it's not
included for ipv6, thus means ipv6 can carry a real '65535' payload.

2. IPv6 header does not need calculate header checksum.

Signed-off-by: Wei Xu 
---
  hw/net/virtio-net.c | 152 +---
  1 file changed, 144 insertions(+), 8 deletions(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index b3bb63b..cc8cbe4 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -53,6 +53,10 @@
  /* header length value in ip header without option */
  #define VIRTIO_NET_IP4_HEADER_LENGTH 5
  
+#define ETH_IP6_HDR_SZ (ETH_HDR_SZ + IP6_HDR_SZ)

+#define VIRTIO_NET_IP6_ADDR_SIZE   32  /* ipv6 saddr + daddr */
+#define VIRTIO_NET_MAX_IP6_PAYLOAD VIRTIO_NET_MAX_TCP_PAYLOAD
+
  /* Purge coalesced packets timer interval, This value affects the performance
 a lot, and should be tuned carefully, '30'(300us) is the recommended
 value to pass the WHQL test, '5' can gain 2x netperf throughput with
@@ -1724,6 +1728,25 @@ static void virtio_net_rsc_extract_unit4(NetRscChain 
*chain,
  unit->payload = htons(*unit->ip_plen) - ip_hdrlen - unit->tcp_hdrlen;
  }
  
+static void virtio_net_rsc_extract_unit6(NetRscChain *chain,

+ const uint8_t *buf, NetRscUnit* unit)
+{
+uint16_t hdr_len;
+struct ip6_header *ip6;
+
+hdr_len = ((VirtIONet *)(chain->n))->guest_hdr_len;
+ip6 = (struct ip6_header *)(buf + hdr_len + sizeof(struct eth_header));
+unit->ip = ip6;
+unit->ip_plen = &(ip6->ip6_ctlun.ip6_un1.ip6_un1_plen);
+unit->tcp = (struct tcp_header *)(((uint8_t *)unit->ip)\
++ sizeof(struct ip6_header));
+unit->tcp_hdrlen = (htons(unit->tcp->th_offset_flags) & 0xF000) >> 10;
+
+/* There is a difference between payload lenght in ipv4 and v6,
+   ip header is excluded in ipv6 */
+unit->payload = htons(*unit->ip_plen) - unit->tcp_hdrlen;
+}
+
  static void virtio_net_rsc_ipv4_checksum(struct virtio_net_hdr *vhdr,
   struct ip_header *ip)
  {
@@ -1742,7 +1765,9 @@ static size_t virtio_net_rsc_drain_seg(NetRscChain 
*chain, NetRscSeg *seg)
  struct virtio_net_hdr *h;
  
  h = (struct virtio_net_hdr *)seg->buf;

-virtio_net_rsc_ipv4_checksum(h, seg->unit.ip);
+if ((chain->proto == ETH_P_IP) && seg->is_coalesced) {
+virtio_net_rsc_ipv4_checksum(h, seg->unit.ip);
+}
  ret = virtio_net_do_receive(seg->nc, seg->buf, seg->size);
  QTAILQ_REMOVE(>buffers, seg, next);
  g_free(seg->buf);
@@ -1798,7 +1823,7 @@ static void virtio_net_rsc_cache_buf(NetRscChain *chain, 
NetClientState *nc,
  hdr_len = chain->n->guest_hdr_len;
  seg = g_malloc(sizeof(NetRscSeg));
  seg->buf = g_malloc(hdr_len + sizeof(struct eth_header)\
-   + VIRTIO_NET_MAX_TCP_PAYLOAD);
+   + sizeof(struct ip6_header) + VIRTIO_NET_MAX_TCP_PAYLOAD);
  memcpy(seg->buf, buf, size);
  seg->size = size;
  seg->packets = 1;
@@ -1809,7 +1834,18 @@ static void virtio_net_rsc_cache_buf(NetRscChain *chain, 
NetClientState *nc,
  QTAILQ_INSERT_TAIL(>buffers, seg, next);
  chain->stat.cache++;
  
-virtio_net_rsc_extract_unit4(chain, seg->buf, >unit);

+switch (chain->proto) {
+case ETH_P_IP:
+virtio_net_rsc_extract_unit4(chain, seg->buf, >unit);
+break;
+
+case ETH_P_IPV6:
+virtio_net_rsc_extract_unit6(chain, seg->buf, >unit);
+break;
+
+default:
+g_assert_not_reached();
+}
  }
  
  static int32_t virtio_net_rsc_handle_ack(NetRscChain *chain,

@@ -1929,6 +1965,24 @@ static int32_t virtio_net_rsc_coalesce4(NetRscChain 
*chain, NetRscSeg *seg,
  return virtio_net_rsc_coalesce_data(chain, seg, buf, unit);
  }
  
+static int32_t virtio_net_rsc_coalesce6(NetRscChain *chain, NetRscSeg *seg,

+const uint8_t *buf, size_t size, NetRscUnit *unit)
+{
+struct ip6_header *ip1, *ip2;
+
+ip1 = (struct ip6_header *)(unit->ip);
+ip2 = (struct ip6_header *)(seg->unit.ip);
+if (memcmp(>ip6_src, >ip6_src, sizeof(struct in6_address))
+|| memcmp(>ip6_dst, >ip6_dst, sizeof(struct in6_address))
+|| (unit->tcp->th_sport ^ seg->unit.tcp->th_sport)
+|| (unit->tcp->th_dport ^ seg->unit.tcp->th_dport)) {
+chain->stat.no_match++;
+return RSC_NO_MATCH;
+}
+
+return virtio_net_rsc_coalesce_data(chain, seg, buf, unit);
+}
+
  /* Pakcets with 'SYN' should bypass, other flag should be sent after drain
   * to prevent out of order */
  static int virtio_net_rsc_tcp_ctrl_check(NetRscChain *chain,
@@ -1981,7 +2035,11 @@ static size_t virtio_net_rsc_do_coalesce(NetRscChain 
*chain, NetClientState *nc,

Re: [Qemu-devel] [ RFC Patch v6 0/2] Support Receive-Segment-Offload(RSC) for WHQL




On 2016年05月29日 00:37, w...@redhat.com wrote:

From: Wei Xu 

Changes in V6:
- Sync upstream code
- Split new fields in 'virtio_net_hdr' to a seperate patch
- Remove feature bit code, replace it with a command line parameter 'guest_rsc'
which is turned off by default.

Changes in V5:
- Passed all IPv4/6 test cases
- Add new fields in 'virtio_net_hdr'
- Set 'gso_type' & 'coalesced packets' in new field.
- Bypass all 'tcp option' packet
- Bypass all 'pure ack' packet
- Bypass all 'duplicate ack' packet
- Change 'guest_rsc' feature bit to 'false' by default
- Feedbacks from v4, typo, etc.


Change-log is very important for the ease and speed up reviewers. More 
details are more than welcomed. But I see some changes were not 
documented here. Please give a more complete one in next iteration.




Note:
There is still a few pending issues about the feature bit, and need to be
discussed with windows driver maintainer, so linux guests with this patch
won't work at current, haven't figure it out yet, but i'm guessing it's
caused by the 'gso_type' is set to 'VIRTIO_NET_HDR_GSO_TCPV4/6',
will fix it after get the final solution, the below test steps and
performance data is based on v4.


This is probably because you've increased the vnet header length.



Another suggestion from Jason is to adjust part of the code to make it
more readable, since there maybe still few change about the flowchart
in the future, such as timestamp, duplicate ack, so i'd like to delay it
temporarily.

Changes in V4:
- Add new host feature bit
- Replace using fixed header lenght with dynamic header lenght in VirtIONet
- Change ip/ip6 header union in NetRscUnit to void* pointer
- Add macro prefix, adjust code indent, etc.

Changes in V3:
- Removed big param list, replace it with 'NetRscUnit'
- Different virtio header size
- Modify callback function to direct call.
- Needn't check the failure of g_malloc()
- Other code format adjustment, macro naming, etc

Changes in V2:
- Add detailed commit log

This patch is to support WHQL test for Windows guest, while this feature also
benifits other guest works as a kernel 'gro' like feature with userspace
implementation.
Feature information:
   http://msdn.microsoft.com/en-us/library/windows/hardware/jj853324

Both IPv4 and IPv6 are supported, though performance with userspace virtio
is slow than vhost-net, there is about 1.5x to 2x performance improvement to
userspace virtio, this is done by turning this feature on and disable
'tso/gso/gro' on corresponding tap interface and guest interface, while get
less improment with all these feature on.

Linux guest performance data(Netperf):
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 192.168.2.101 
() port 0 AF_INET : nodelay
Size   SizeSize Time Throughput
bytes  bytes   bytessecs.10^6bits/sec

  87380  16384 646.00 1221.20
  87380  16384 646.00 1260.30

  87380  163841286.00 1978.51
  87380  163841286.00 2286.05

  87380  163842566.00 2677.94
  87380  163842566.00 4615.42

  87380  163845126.00 2956.54
  87380  163845126.00 5356.39

  87380  16384   10246.00 2798.17
  87380  16384   10246.00 4943.30

  87380  16384   20486.00 2681.09
  87380  16384   20486.00 4835.81

  87380  16384   40966.00 3390.14
  87380  16384   40966.00 5391.54

  87380  16384   80926.00 3008.27
  87380  16384   80926.00 5381.68

  87380  16384  102406.00 2999.89
  87380  16384  102406.00 5393.11

Test steps:
Although this feature is mainly used for window guest, i used linux guest to
help test the feature, to make things simple, i used 3 steps to test the patch
as i moved on.

1. With a tcp socket client/server pair running on 2 linux guest, thus i can
control
the traffic and debugging the code as i want.
2. Netperf on linux guest test the throughput.
3. WHQL test with 2 Windows guests.

Wei Xu (3):
   virtio-net rsc: support coalescing ipv4 tcp traffic
   virtio-net rsc: support coalescing ipv6 tcp traffic
   virtio-net rsc: add 2 new rsc information fields to 'virtio_net_hdr'

  hw/net/virtio-net.c | 642 +++-
  include/hw/virtio/virtio-net.h  |   2 +
  include/hw/virtio/virtio.h  |  75 
  include/standard-headers/linux/virtio_net.h |   3 +
  4 files changed, 721 insertions(+), 1 deletion(-)

Re: [Qemu-devel] [ RFC Patch v6 1/3] virtio-net rsc: support coalescing ipv4 tcp traffic




On 2016年05月29日 00:37, w...@redhat.com wrote:

From: Wei Xu 

All the data packets in a tcp connection will be cached to a big buffer
in every receive interval, and will be sent out via a timer, the
'virtio_net_rsc_timeout' controls the interval, the value will influent the
performance and response of tcp connection extremely, 5(50us) is a
experience value to gain a performance improvement, since the whql test
sends packets every 100us, so '30(300us)' can pass the test case,
this is also the default value, it's tunable via the command line
parameter 'rsc_interval' with 'virtio-net-pci' device, for example, below
parameter is to launch a guest with interval set as '50'.


Does the value make sense if it was smaller than 1us? If not, why not 
just make the unit to be 1us?




'virtio-net-pci,netdev=hostnet1,bus=pci.0,id=net1,mac=00,rsc_interval=50'
will

The timer will only be triggered if the packets pool is not empty,
and it'll drain off all the cached packets.

'NetRscChain' is used to save the segments of different protocols in a
VirtIONet device.

The main handler of TCP includes TCP window update, duplicated ACK check
and the real data coalescing if the new segment passed sanity check
and is identified as an 'wanted' one.

An 'wanted' segment means:
1. Segment is within current window and the sequence is the expected one.
2. 'ACK' of the segment is in the valid window.

Sanity check includes:
1. Incorrect version in IP header
2. IP options & IP fragment
3. Not a TCP packets
4. Sanity size check to prevent buffer overflow attack.

There maybe more cases should be considered such as ip identification other
flags, while it broke the test because windows set it to the same even it's
not a fragment.

Normally it includes 2 typical ways to handle a TCP control flag, 'bypass'
and 'finalize', 'bypass' means should be sent out directly, and 'finalize'
means the packets should also be bypassed, and this should be done
after searching for the same connection packets in the pool and sending
all of them out, this is to avoid out of data.

All the 'SYN' packets will be bypassed since this always begin a new'
connection, other flags such 'FIN/RST' will trigger a finalization, because
this normally happens upon a connection is going to be closed, an 'URG' packet
also finalize current coalescing unit.

Statistics can be used to monitor the basic coalescing status, the 'out of 
order'
and 'out of window' means how many retransmitting packets, thus describe the
performance intuitively.


We usually don't add device specific monitor command. Maybe a new 
control vq command ethtool -S in guest in the future. I was thinking of 
removing those counters since it was never used in this series.




Signed-off-by: Wei Xu 
---
  hw/net/virtio-net.c | 498 +++-
  include/hw/virtio/virtio-net.h  |   2 +
  include/hw/virtio/virtio.h  |  75 +
  include/standard-headers/linux/virtio_net.h |   1 +


For RFC, it's ok. But for formal patch, this is not the correct way to 
modify Linux headers. There's a script in 
scripts/update-linux-headers.sh which was used to sync it from Linux 
source. This means, it must be merged in Linux or at least in 
maintainer's tree first.



  4 files changed, 575 insertions(+), 1 deletion(-)

diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
index 5798f87..b3bb63b 100644
--- a/hw/net/virtio-net.c
+++ b/hw/net/virtio-net.c
@@ -15,10 +15,12 @@
  #include "qemu/iov.h"
  #include "hw/virtio/virtio.h"
  #include "net/net.h"
+#include "net/eth.h"
  #include "net/checksum.h"
  #include "net/tap.h"
  #include "qemu/error-report.h"
  #include "qemu/timer.h"
+#include "qemu/sockets.h"
  #include "hw/virtio/virtio-net.h"
  #include "net/vhost_net.h"
  #include "hw/virtio/virtio-bus.h"
@@ -38,6 +40,25 @@
  #define endof(container, field) \
  (offsetof(container, field) + sizeof(((container *)0)->field))
  
+#define VIRTIO_NET_IP4_ADDR_SIZE   8/* ipv4 saddr + daddr */

+#define VIRTIO_NET_TCP_PORT_SIZE   4/* sport + dport */
+
+#define VIRTIO_NET_TCP_FLAG 0x3F
+#define VIRTIO_NET_TCP_HDR_LENGTH   0xF000
+
+/* IPv4 max payload, 16 bits in the header */
+#define VIRTIO_NET_MAX_IP4_PAYLOAD (65535 - sizeof(struct ip_header))
+#define VIRTIO_NET_MAX_TCP_PAYLOAD 65535


Is this still true if window scaling is enabled? And need to make sure 
your ack/seq processing can work for window scaling.



+
+/* header length value in ip header without option */
+#define VIRTIO_NET_IP4_HEADER_LENGTH 5
+
+/* Purge coalesced packets timer interval, This value affects the performance
+   a lot, and should be tuned carefully, '30'(300us) is the recommended
+   value to pass the WHQL test, '5' can gain 2x netperf throughput with
+   tso/gso/gro 'off'. */
+#define VIRTIO_NET_RSC_INTERVAL  30


Do we need a new property for this value?


+
  typedef struct

Re: [Qemu-devel] [PATCH] docs/multi-thread-compression: Fix wrong command string

2016-05-29 Thread Wei, Jiangang

Add qemu-trivial 

Reviewed-by: Eric Blake 
Reviewed-by: Liang Li 

Thanks,
wei

On Mon, 2016-05-23 at 17:43 +0800, Wei Jiangang wrote:
> s/info_migrate_capabilities/info migrate_capabilities
> 
> Signed-off-by: Wei Jiangang 
> ---
>  docs/multi-thread-compression.txt | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/docs/multi-thread-compression.txt 
> b/docs/multi-thread-compression.txt
> index 3d477c3..d0caaf7 100644
> --- a/docs/multi-thread-compression.txt
> +++ b/docs/multi-thread-compression.txt
> @@ -110,7 +110,7 @@ Usage
>  =
>  1. Verify both the source and destination QEMU are able
>  to support the multiple thread compression migration:
> -{qemu} info_migrate_capabilities
> +{qemu} info migrate_capabilities
>  {qemu} ... compress: off ...
>  
>  2. Activate compression on the source:

Re: [Qemu-devel] [RFC PATCH V4 0/4] Introduce COLO-compare




On 2016年05月25日 20:50, Zhang Chen wrote:

COLO-compare is a part of COLO project. It is used
to compare the network package to help COLO decide
whether to do checkpoint.

the full version in this github:
https://github.com/zhangckid/qemu/tree/colo-v2.7-proxy-mode-compare-with-colo-base-may25


v4:
  p4:
 - add some comments
 - fix some trace-events
 - fix tcp compare error
  p3:
 - add rcu_read_lock().
 - fix trace name
 - fix jason's other comments
 - rebase some Dave's branch function
  p2:
 - colo_compare_connection() change g_queue_push_head() to
 - g_queue_push_tail() match to sorted order.
 - remove QemuMutex conn_list_lock


Looks like conn_list lock is still there. I still prefer to do all thing 
in the comparing thread. Have you tried Fam's suggestion to use 
g_main_context_push_thread_default()? If it does not work, does it work 
simply by replacing all:


g_source_attach(x, NULL);

with

g_souce_attach(x, g_main_context_get_thread_default());

after call g_main_context_push_thread_default()?

Thanks

 - remove pkt->s
 - move data structure to colo-base.h
 - add colo-base.c reuse codes for filter-rewriter
 - add some filter-rewriter needs struct
 - depends on previous SocketReadState patch
  p1:
 - except move qemu_chr_add_handlers()
   to colo thread
 - remove class_finalize
 - remove secondary arp codes
 - depends on previous SocketReadState patch

v3:
   - rebase colo-compare to colo-frame v2.7
   - fix most of Dave's comments
 (except RCU)
   - add TCP,UDP,ICMP and other packet comparison
   - add trace-event
   - add some comments
   - other bug fix
   - add RFC index
   - add usage in patch 1/4

v2:
   - add jhash.h

v1:
   - initial patch


Zhang Chen (4):
   colo-compare: introduce colo compare initialization
   colo-compare: track connection and enqueue packet
   colo-compare: introduce packet comparison thread
   colo-compare: add TCP,UDP,ICMP packet comparison

  include/qemu/jhash.h |  61 +
  net/Makefile.objs|   2 +
  net/colo-base.c  | 183 +
  net/colo-base.h  |  92 +++
  net/colo-compare.c   | 745 +++
  qemu-options.hx  |  34 +++
  trace-events |  11 +
  vl.c |   3 +-
  8 files changed, 1130 insertions(+), 1 deletion(-)
  create mode 100644 include/qemu/jhash.h
  create mode 100644 net/colo-base.c
  create mode 100644 net/colo-base.h
  create mode 100644 net/colo-compare.c

[Qemu-devel] [Bug 797905] Re: virsh live migration

2016-05-29 Thread Michael liu

You can try to copy the image file from source to destination before
migration.

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

Title:
  virsh live migration

Status in QEMU:
  New

Bug description:
  Hi,
  i do not manage to do a virsh migrate live command.
  Using Ubuntu Server 10.04 x64

  root@svr50abl:~# virsh list
   Id Nome Estado
  --
   18 Winxpexecutando
   19 testeexecutando

  root@svr50abl:~# sudo virsh migrate --live 19 qemu+ssh://10.1.5.1/system
  root@10.1.5.1's password: 
  erro: unable to set user and group to '116:127' on 
'/var/lib/libvirt/images/teste.img': No such file or directory

  teste.img has root:root (xrw)

  10.1.5.1 is a functional kvm host too

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

[Qemu-devel] [Bug 682360] Re: Unaccessible memory

2016-05-29 Thread Michael liu

This is a qemu emulator problem, whould qemu stop when the memory is
larger than 128M? You can try  set the memory 256 to start vm.

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

Title:
  Unaccessible memory

Status in QEMU:
  New

Bug description:
  Hello,

  I'm trying to develop a OS over L4/X2 microkernel and I use Linux
  debian and qemu 0.13 in 64 bits mode. When I start qemu with qemu-
  system-x86_64 -hdc freevms.img -smp 1 -serial stdio -m 128M -k fr, my
  kernel boots fine. If I modify this command line with -m 384M (for
  example), my kernel is loaded but enter in a deadlock. I have found a
  bug in my code until I have tried to use the _same_ disk image under
  virtualbox and it works without any trouble. I runs fine on a real PC
  also.

  I have bissected my code and qemu stops (maybe in a deadlock) when I try to 
access to memory :
  %MEM-I-VM_ALLOC, adding $00045000 - $00108FFF to VM allocator
  %MEM-I-VM_ALLOC, adding $0010B000 - $003F2FFF to VM allocator
  %MEM-I-VM_ALLOC, adding $0040C000 - $00FF to VM allocator
  %MEM-I-VM_ALLOC, adding $0100F000 - $FEFF to VM allocator
  %MEM-I-ACCMAP, accepting mapping
  %MEM-I-ACCMAP, virtual  $ - $0FFF
  %MEM-I-ACCMAP, physical $0009E000 - $0009EFFF

  Note that qemu doesn't crash. It only stops. My virtual memory
  subsystem maps $ in physical memory ($9E000). And when
  I try to initialize this memory, qemu enters in deadlock.

  A disk image to reproduce this bug is available at
  http://www.systella.fr/~bertrand/freevms.img.bz2

  Regards,

  JKB

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

Re: [Qemu-devel] [PATCH v5 00/10] Add Ethernet device for i.MX6 SOC




On 2016年05月21日 16:01, Jean-Christophe Dubois wrote:

This patch series adds Gb ENET Ethernet device to the i.MX6 SOC.

The ENET device is an evolution of the FEC device present on the i.MX25 SOC
and is backward compatible with it.

Therefore the ENET support has been added to the actual Qemu FEC device (
rather than adding a new device).

The Patch has been tested by:
  * Booting linux on i.MX25 PDK board emulation and accessing internet
  * Booting linux on i.MX6 Sabrelite board emulation and accessing internet

Jean-Christophe Dubois (10):
   net: improve UDP/TCP checksum computation.
   net: handle optional VLAN header in checksum computation.
   i.MX: Fix FEC code for MDIO operation selection
   i.MX: Fix FEC code for MDIO address selection
   i.MX: Fix FEC code for ECR register reset value.
   i.MX: reset TX/RX descriptors when FEC is disabled.
   i.MX: Rename i.MX FEC defines to ENET_XXX
   i.MX: move FEC device to a register array structure.
   Add ENET/Gbps Ethernet support to FEC device
   Add ENET device to i.MX6 SOC.

  hw/arm/fsl-imx25.c|1 +
  hw/arm/fsl-imx6.c |   17 +
  hw/net/imx_fec.c  | 1009 ++---
  include/hw/arm/fsl-imx6.h |6 +-
  include/hw/net/imx_fec.h  |  250 ---
  net/checksum.c|  121 --
  6 files changed, 1077 insertions(+), 327 deletions(-)



Want to merge this, but I get:

Applying: net: improve UDP/TCP checksum computation.
Applying: net: handle optional VLAN header in checksum computation.
Applying: i.MX: Fix FEC code for MDIO operation selection
Applying: i.MX: Fix FEC code for MDIO address selection
Applying: i.MX: Fix FEC code for ECR register reset value.
Applying: i.MX: reset TX/RX descriptors when FEC is disabled.
Applying: i.MX: Rename i.MX FEC defines to ENET_XXX
Applying: i.MX: move FEC device to a register array structure.
Applying: Add ENET/Gbps Ethernet support to FEC device
error: patch failed: hw/net/imx_fec.c:24
error: hw/net/imx_fec.c: patch does not apply
Patch failed at 0009 Add ENET/Gbps Ethernet support to FEC device
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

[Qemu-devel] [Bug 567380] Re: qemu-img fails to create images >= 4G

2016-05-29 Thread Michael liu

what a zero-length file means? Run the following command to see
qemu-img info foo.img

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

Title:
  qemu-img fails to create images >= 4G

Status in QEMU:
  Incomplete

Bug description:
  On a Windows XP system and an NTFS drive, using QEMU on Windows Ver
  0.12.2 from http://homepage3.nifty.com/takeda-toshiya/qemu/ or QEMU
  0.12.3 or d3538b45ea88e82d1b01959b4ca55d3696b71cb2 built locally, when
  I run the following command, a zero-length file is created.

   qemu-img create foo.img 4G

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

Re: [Qemu-devel] [PULL V3 00/20] Net patches




On 2016年05月30日 00:45, Peter Maydell wrote:

On 29 May 2016 at 16:22, Dmitry Fleytman  wrote:

It turned out that the issue is not in the new code but in
pci.h helper functions used by the new code to fill DSN capability.

Thanks for tracking this down.


Following patch fixes the problem:

diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index ef6ba51..ee238ad
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -468,13 +468,13 @@ pci_get_long(const uint8_t *config)
  static inline void
  pci_set_quad(uint8_t *config, uint64_t val)
  {
-cpu_to_le64w((uint64_t *)config, val);
+stq_le_p(config, val);
  }

  static inline uint64_t
  pci_get_quad(const uint8_t *config)
  {
-return le64_to_cpup((const uint64_t *)config);
+return ldq_le_p(config);
  }

I see from git blame that some time ago you did similar change in all other
pci_set_* pci_get_* functions except these two.

Is there any specific reason you did not change these two functions then?

The patches where I changed the other functions were cleanups
to convert away from some legacy *_to_cpupu() functions, which
were specifically intended to work with unaligned pointers
(which is what the "u" indicated). I was doing the cleanups
per-conversion-function, not per-callsite, and since these
two functions aren't using a _to_cpupu() function but just
_to_cpup() they wouldn't have shown up in my searches.

In any case this is the correct fix, and we should probably
audit the other uses of *_to_cpup and cpu_to_* -- I suspect
many of them are working with possibly-unaligned
pointers in to guest memory and we should replace them with
ld*_*_p functions and get rid of the _to_cpup functions entirely.

thanks
-- PMM


git grep shows lots of places. Is it ok to send a new version of pull 
request with Dmitry's fix first?


Thanks

[Qemu-devel] [PATCH 8/9] adding instruction translations

Signed-off-by: Michael Rolnik 
---
 target-avr/translate.c.inc | 2546 
 1 file changed, 2546 insertions(+)
 create mode 100644 target-avr/translate.c.inc

diff --git a/target-avr/translate.c.inc b/target-avr/translate.c.inc
new file mode 100644
index 000..74b3c2c
--- /dev/null
+++ b/target-avr/translate.c.inc
@@ -0,0 +1,2546 @@
+/*
+ *  QEMU AVR CPU
+ *
+ *  Copyright (c) 2016 Michael Rolnik
+ *
+ *  This library is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU Lesser General Public
+ *  License as published by the Free Software Foundation; either
+ *  version 2.1 of the License, or (at your option) any later version.
+ *
+ *  This library is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  Lesser General Public License for more details.
+ *
+ *  You should have received a copy of the GNU Lesser General Public
+ *  License along with this library; if not, see
+ *  
+ */
+
+#include 
+#include 
+
+#ifdef  HOST_WORDS_BIGENDIAN
+#include "inst-be.h"
+#else
+#include "inst-le.h"
+#endif
+
+/*
+NOTE:   all registers are assumed to hold 8 bit values.
+so all operations done on registers should preseve this property
+*/
+
+/*
+NOTE:   the flags C,H,V,N,V have either 0 or 1 values
+NOTE:   the flag Z has inverse logic, when the value of Zf is 0 the flag 
is assumed to be set, non zero - not set
+*/
+
+voidgen_add_CHf(TCGvR, TCGvRd, TCGvRr);
+voidgen_add_Vf( TCGvR, TCGvRd, TCGvRr);
+voidgen_sub_CHf(TCGvR, TCGvRd, TCGvRr);
+voidgen_sub_Vf( TCGvR, TCGvRd, TCGvRr);
+voidgen_ZNSf(   TCGvR);
+voidgen_push_ret(   CPUAVRState *env, intret);
+voidgen_pop_ret(CPUAVRState *env, TCGvret);
+voidgen_jmp_ez( void);
+voidgen_jmp_z(  void);
+
+voidgen_set_addr(   TCGv addr, TCGv H, TCGv M, TCGv l); /*  H:M:L   = addr 
 */
+voidgen_set_xaddr(  TCGv addr);
+voidgen_set_yaddr(  TCGv addr);
+voidgen_set_zaddr(  TCGv addr);
+
+TCGvgen_get_addr(   TCGv H, TCGv M, TCGv L);/*  addr = H:M:L   
 */
+TCGvgen_get_xaddr(  void);
+TCGvgen_get_yaddr(  void);
+TCGvgen_get_zaddr(  void);
+int sex(int Imm, unsigned bits);
+
+voidgen_add_CHf(TCGvR, TCGvRd, TCGvRr)
+{
+TCGvt1  = tcg_temp_new_i32();
+TCGvt2  = tcg_temp_new_i32();
+TCGvt3  = tcg_temp_new_i32();
+
+tcg_gen_and_tl( t1, Rd, Rr);/*  t1  = Rd & Rr  */
+tcg_gen_not_tl( t2, R); /*  t2  = Rd & ~R  */
+tcg_gen_and_tl( t2, Rd, t2);
+tcg_gen_not_tl( t3, R); /*  t3  = Rr  *~R  */
+tcg_gen_and_tl( t3, Rr, t3);
+tcg_gen_or_tl(  t1, t1, t2);/*  t1  = t1 | t2 | t3  */
+tcg_gen_or_tl(  t1, t1, t3);
+
+tcg_gen_shri_tl(cpu_Cf, t1, 7); /*  Cf  = t1(7)  */
+tcg_gen_shri_tl(cpu_Hf, t1, 3); /*  Hf  = t1(3)  */
+tcg_gen_andi_tl(cpu_Hf, cpu_Hf, 1);
+
+tcg_temp_free_i32(t3);
+tcg_temp_free_i32(t2);
+tcg_temp_free_i32(t1);
+}
+
+voidgen_add_Vf(TCGvR, TCGvRd, TCGvRr)
+{
+TCGvt1  = tcg_temp_new_i32();
+TCGvt2  = tcg_temp_new_i32();
+
+tcg_gen_not_tl( t1, Rd);/*  t1  = ~Rd & ~Rr & R  */
+tcg_gen_not_tl( t2, Rr);
+tcg_gen_and_tl( t1, t1, t2);
+tcg_gen_and_tl( t1, t1, R);
+
+tcg_gen_not_tl( t2, R); /*  t2  = Rd & Rr & ~R  */
+tcg_gen_and_tl( t2, t2, Rd);
+tcg_gen_and_tl( t2, t2, Rr);
+
+tcg_gen_or_tl(  t1, t1, t2);/*  t1  = Rd & Rr & ~R | ~Rd & ~Rr 
& R  */
+
+tcg_gen_shri_tl(cpu_Vf, t1, 7); /*  Vf  = t1(7)  */
+
+tcg_temp_free_i32(t2);
+tcg_temp_free_i32(t1);
+}
+
+voidgen_sub_CHf(TCGvR, TCGvRd, TCGvRr)
+{
+TCGvt1  = tcg_temp_new_i32();
+TCGvt2  = tcg_temp_new_i32();
+TCGvt3  = tcg_temp_new_i32();
+
+/*  Cf & Hf  */
+tcg_gen_not_tl( t1, Rd);/*  t1  = ~Rd  */
+tcg_gen_and_tl( t2, t1, Rr);/*  t2  = ~Rd & Rr  */
+tcg_gen_or_tl(  t3, t1, Rr);/*  t3  = (~Rd | Rr) & R  */
+tcg_gen_and_tl( t3, t3, R);
+tcg_gen_or_tl(  t2, t2, t3);/*  t2  = ~Rd & Rr | ~Rd & R | R & 
Rr  */
+tcg_gen_shri_tl(cpu_Cf, t2, 7); /*  Cf  = t2(7)  */
+tcg_gen_shri_tl(cpu_Hf, t2, 3); /*  Hf  = t2(3)  */
+tcg_gen_andi_tl(cpu_Hf, cpu_Hf, 1);
+
+tcg_temp_free_i32(t3);
+tcg_temp_free_i32(t2);
+tcg_temp_free_i32(t1);
+}
+
+voidgen_sub_Vf(TCGvR, TCGvRd, TCGvRr)
+{
+TCGvt1  = tcg_temp_new_i32();
+TCGv

[Qemu-devel] [PATCH 2/9] adding AVR CPU features/flavors

Signed-off-by: Michael Rolnik 
---
 target-avr/cpu.c | 326 ++-
 target-avr/cpu.h |  59 ++
 2 files changed, 383 insertions(+), 2 deletions(-)

diff --git a/target-avr/cpu.c b/target-avr/cpu.c
index ff26018..9be0a1d 100644
--- a/target-avr/cpu.c
+++ b/target-avr/cpu.c
@@ -31,7 +31,7 @@ static void avr_cpu_set_pc(
 {
 AVRCPU   *cpu = AVR_CPU(cs);
 
-cpu->env.pc = value / 2;/*  internaly PC points to words, not bytes */
+cpu->env.pc = value / 2;/*  internally PC points to words   */
 }
 
 static bool avr_cpu_has_work(
@@ -52,7 +52,7 @@ static void avr_cpu_synchronize_from_tb(
 AVRCPU  *cpu = AVR_CPU(cs);
 CPUAVRState *env = >env;
 
-env->pc = tb->pc / 2;
+env->pc = tb->pc / 2;   /*  internally PC points to words   */
 }
 
 static void avr_cpu_reset(
@@ -61,12 +61,14 @@ static void avr_cpu_reset(
 AVRCPU *cpu = AVR_CPU(s);
 AVRCPUClass*mcc = AVR_CPU_GET_CLASS(cpu);
 CPUAVRState*env = >env;
+uint32_tfeatures= env->features;
 
 mcc->parent_reset(s);
 
 memset(env, 0, sizeof(CPUAVRState));
 env->pc = 0;
 env->sregI  = 1;
+env->features   = features;
 
 tlb_flush(s, 1);
 }
@@ -206,6 +208,311 @@ static void avr_cpu_class_init(
 = true;
 }
 
+static void avr_avr1_initfn(
+Object *obj)
+{
+AVRCPU *cpu = AVR_CPU(obj);
+CPUAVRState*env = >env;
+
+avr_set_feature(env,AVR_FEATURE_LPM);
+avr_set_feature(env,AVR_FEATURE_2_BYTE_SP);
+avr_set_feature(env,AVR_FEATURE_2_BYTE_PC);
+}
+static void avr_avr2_initfn(
+Object *obj)
+{
+AVRCPU *cpu = AVR_CPU(obj);
+CPUAVRState*env = >env;
+
+avr_set_feature(env,AVR_FEATURE_LPM);
+avr_set_feature(env,AVR_FEATURE_IJMP_ICALL);
+avr_set_feature(env,AVR_FEATURE_ADIW_SBIW);
+avr_set_feature(env,AVR_FEATURE_SRAM);
+avr_set_feature(env,AVR_FEATURE_BREAK);
+
+avr_set_feature(env,AVR_FEATURE_2_BYTE_PC);
+avr_set_feature(env,AVR_FEATURE_2_BYTE_SP);
+}
+
+static void avr_avr25_initfn(
+Object *obj)
+{
+AVRCPU *cpu = AVR_CPU(obj);
+CPUAVRState*env = >env;
+
+avr_set_feature(env,AVR_FEATURE_LPM);
+avr_set_feature(env,AVR_FEATURE_IJMP_ICALL);
+avr_set_feature(env,AVR_FEATURE_ADIW_SBIW);
+avr_set_feature(env,AVR_FEATURE_SRAM);
+avr_set_feature(env,AVR_FEATURE_BREAK);
+
+avr_set_feature(env,AVR_FEATURE_2_BYTE_PC);
+avr_set_feature(env,AVR_FEATURE_2_BYTE_SP);
+avr_set_feature(env,AVR_FEATURE_LPMX);
+avr_set_feature(env,AVR_FEATURE_MOVW);
+}
+
+static void avr_avr3_initfn(
+Object *obj)
+{
+AVRCPU *cpu = AVR_CPU(obj);
+CPUAVRState*env = >env;
+
+avr_set_feature(env,AVR_FEATURE_LPM);
+avr_set_feature(env,AVR_FEATURE_IJMP_ICALL);
+avr_set_feature(env,AVR_FEATURE_ADIW_SBIW);
+avr_set_feature(env,AVR_FEATURE_SRAM);
+avr_set_feature(env,AVR_FEATURE_BREAK);
+
+avr_set_feature(env,AVR_FEATURE_2_BYTE_PC);
+avr_set_feature(env,AVR_FEATURE_2_BYTE_SP);
+avr_set_feature(env,AVR_FEATURE_JMP_CALL);
+}
+
+static void avr_avr31_initfn(
+Object *obj)
+{
+AVRCPU *cpu = AVR_CPU(obj);
+CPUAVRState*env = >env;
+
+avr_set_feature(env,AVR_FEATURE_LPM);
+avr_set_feature(env,AVR_FEATURE_IJMP_ICALL);
+avr_set_feature(env,AVR_FEATURE_ADIW_SBIW);
+avr_set_feature(env,AVR_FEATURE_SRAM);
+avr_set_feature(env,AVR_FEATURE_BREAK);
+
+avr_set_feature(env,AVR_FEATURE_2_BYTE_PC);
+avr_set_feature(env,AVR_FEATURE_2_BYTE_SP);
+avr_set_feature(env,AVR_FEATURE_RAMPZ);
+avr_set_feature(env,AVR_FEATURE_ELPM);
+avr_set_feature(env,AVR_FEATURE_JMP_CALL);
+}
+
+static void avr_avr35_initfn(
+Object *obj)
+{
+AVRCPU *cpu = AVR_CPU(obj);
+CPUAVRState*env = >env;
+
+avr_set_feature(env,AVR_FEATURE_LPM);
+avr_set_feature(env,AVR_FEATURE_IJMP_ICALL);
+avr_set_feature(env,AVR_FEATURE_ADIW_SBIW);
+avr_set_feature(env,AVR_FEATURE_SRAM);
+avr_set_feature(env,AVR_FEATURE_BREAK);
+
+avr_set_feature(env,AVR_FEATURE_2_BYTE_PC);
+avr_set_feature(env,AVR_FEATURE_2_BYTE_SP);
+avr_set_feature(env,AVR_FEATURE_JMP_CALL);
+avr_set_feature(env,AVR_FEATURE_LPMX);
+avr_set_feature(env,AVR_FEATURE_MOVW);
+}
+
+static void avr_avr4_initfn(
+Object

[Qemu-devel] [PATCH 7/9] adding instruction decoder

Signed-off-by: Michael Rolnik 
---
 target-avr/decode.c | 732 
 1 file changed, 732 insertions(+)
 create mode 100644 target-avr/decode.c

diff --git a/target-avr/decode.c b/target-avr/decode.c
new file mode 100644
index 000..f517045
--- /dev/null
+++ b/target-avr/decode.c
@@ -0,0 +1,732 @@
+/*
+ * QEMU AVR CPU
+ *
+ * Copyright (c) 2016 Michael Rolnik
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * 
+ */
+
+
+#include 
+#ifdef HOST_WORDS_BIGENDIAN
+#include "inst-be.h"
+#else
+#include "inst-le.h"
+#endif
+
+
+typedef int (*translate_function_t)(CPUAVRState *env, DisasContext* ctx, 
uint8_t const *opcode);
+uint32_tavr_decode(uint32_t pc, uint32_t *length, uint8_t *code, 
translate_function_t *translate);
+uint32_tget_opcode(uint8_t const *code, unsigned bitBase, unsigned 
bitSsize);
+
+uint32_tavr_decode(uint32_t pc, uint32_t *length, uint8_t *code, 
translate_function_t *translate)
+{
+uint32_topcode  = get_opcode(code, 0, 16);
+switch (opcode & 0xd000) {
+case0x: {
+uint32_topcode  = get_opcode(code, 0, 16);
+switch (opcode & 0x2c00) {
+case0x: {
+uint32_topcode  = get_opcode(code, 0, 16);
+switch (opcode & 0x0300) {
+case0x: {
+*length = 16;
+*translate = 
(translate_function_t)_translate_NOP;
+break;
+}
+case0x0100: {
+*length = 16;
+*translate = 
(translate_function_t)_translate_MOVW;
+break;
+}
+case0x0200: {
+*length = 16;
+*translate = 
(translate_function_t)_translate_MULS;
+break;
+}
+case0x0300: {
+uint32_topcode  = get_opcode(code, 0, 16);
+switch (opcode & 0x0088) {
+case0x: {
+*length = 16;
+*translate = 
(translate_function_t)_translate_MULSU;
+break;
+}
+case0x0008: {
+*length = 16;
+*translate = 
(translate_function_t)_translate_FMUL;
+break;
+}
+case0x0080: {
+*length = 16;
+*translate = 
(translate_function_t)_translate_FMULS;
+break;
+}
+case0x0088: {
+*length = 16;
+*translate = 
(translate_function_t)_translate_FMULSU;
+break;
+}
+}
+break;
+}
+}
+break;
+}
+case0x0400: {
+*length = 16;
+*translate = (translate_function_t)_translate_CPC;
+break;
+}
+case0x0800: {
+*length = 16;
+*translate = (translate_function_t)_translate_SBC;
+break;
+}
+case0x0c00: {
+*length = 16;
+*translate = (translate_function_t)_translate_ADD;
+break;
+}
+case0x2000: {
+*length = 16;
+*translate = (translate_function_t)_translate_AND;
+break;
+}
+case0x2400: {
+

[Qemu-devel] [PATCH 3/9] adding a sample AVR board

Signed-off-by: Michael Rolnik 
---
 hw/Makefile.objs |   1 +
 hw/avr/Makefile.objs |   1 +
 hw/avr/sample-io.c   | 246 +++
 hw/avr/sample.c  | 120 +
 4 files changed, 368 insertions(+)
 create mode 100644 hw/avr/Makefile.objs
 create mode 100644 hw/avr/sample-io.c
 create mode 100644 hw/avr/sample.c

diff --git a/hw/Makefile.objs b/hw/Makefile.objs
index 4a07ed4..262ca15 100644
--- a/hw/Makefile.objs
+++ b/hw/Makefile.objs
@@ -33,6 +33,7 @@ devices-dirs-$(CONFIG_SOFTMMU) += watchdog/
 devices-dirs-$(CONFIG_SOFTMMU) += xen/
 devices-dirs-$(CONFIG_MEM_HOTPLUG) += mem/
 devices-dirs-$(CONFIG_SMBIOS) += smbios/
+devices-dirs-$(CONFIG_SOFTMMU) += avr/
 devices-dirs-y += core/
 common-obj-y += $(devices-dirs-y)
 obj-y += $(devices-dirs-y)
diff --git a/hw/avr/Makefile.objs b/hw/avr/Makefile.objs
new file mode 100644
index 000..9f6be2f
--- /dev/null
+++ b/hw/avr/Makefile.objs
@@ -0,0 +1 @@
+obj-y   += sample.o sample-io.o
diff --git a/hw/avr/sample-io.c b/hw/avr/sample-io.c
new file mode 100644
index 000..133c72f
--- /dev/null
+++ b/hw/avr/sample-io.c
@@ -0,0 +1,246 @@
+/*
+ *  QEMU AVR CPU
+ *
+ *  Copyright (c) 2016 Michael Rolnik
+ *
+ *  This library is free software; you can redistribute it and/or
+ *  modify it under the terms of the GNU Lesser General Public
+ *  License as published by the Free Software Foundation; either
+ *  version 2.1 of the License, or (at your option) any later version.
+ *
+ *  This library is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ *  Lesser General Public License for more details.
+ *
+ *  You should have received a copy of the GNU Lesser General Public
+ *  License along with this library; if not, see
+ *  
+ */
+
+#include "qemu/osdep.h"
+#include "qapi/error.h"
+#include "qemu-common.h"
+#include "cpu.h"
+#include "include/hw/sysbus.h"
+
+#define TYPE_SAMPLEIO   "SampleIO"
+#define SAMPLEIO(obj)   OBJECT_CHECK(SAMPLEIOState, (obj), TYPE_SAMPLEIO)
+
+#ifndef DEBUG_SAMPLEIO
+#define DEBUG_SAMPLEIO 1
+#endif
+
+#define DPRINTF(fmt, args...) \
+do {  \
+if (DEBUG_SAMPLEIO) { \
+fprintf(stderr, "[%s]%s: " fmt , TYPE_SAMPLEIO, __func__, ##args);\
+} \
+} \
+while (0)
+
+#define AVR_IO_CPU_REGS_SIZE0x0020
+#define AVR_IO_CPU_IO_SIZE  0x0040
+#define AVR_IO_EXTERN_IO_SIZE   0x00a0
+#define AVR_IO_SIZE (AVR_IO_CPU_REGS_SIZE   \
++ AVR_IO_CPU_IO_SIZE\
++ AVR_IO_EXTERN_IO_SIZE)
+
+#define AVR_IO_CPU_REGS_BASE0x
+#define AVR_IO_CPU_IO_BASE  (AVR_IO_CPU_REGS_BASE   \
++ AVR_IO_CPU_REGS_SIZE)
+#define AVR_IO_EXTERN_IO_BASE   (AVR_IO_CPU_IO_BASE \
++ AVR_IO_CPU_IO_SIZE)
+
+
+typedef struct SAMPLEIOState {
+SysBusDeviceparent;
+
+MemoryRegioniomem;
+
+AVRCPU *cpu;
+
+uint8_t io[0x40];
+uint8_t exio[0xa0];
+} SAMPLEIOState;
+
+static uint64_t sample_io_read(
+void   *opaque,
+hwaddr  offset,
+unsignedsize);
+static void sample_io_write(void   *opaque,
+hwaddr  offset,
+uint64_tvalue,
+unsignedsize);
+static int  sample_io_init(
+DeviceState*sbd);
+static void sample_io_class_init(
+ObjectClass*klass,
+void   *data);
+static void sample_io_register_types(void);
+
+static void write_Rx(
+CPUAVRState*env,
+int inst,
+uint8_t data);
+static uint8_t  read_Rx(
+CPUAVRState*env,
+int inst);
+
+static const
+MemoryRegionOps sample_io_ops = {
+.read   = sample_io_read,
+.write  = sample_io_write,
+.endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+static
+Propertysample_io_properties[] = {
+DEFINE_PROP_END_OF_LIST(),
+};
+static const

[Qemu-devel] [PATCH 9/9] updating gen_intermediate_code function to use prevously added decoder and translator

Signed-off-by: Michael Rolnik 
---
 target-avr/Makefile.objs |  4 ++-
 target-avr/translate.c   | 91 +++-
 2 files changed, 86 insertions(+), 9 deletions(-)

diff --git a/target-avr/Makefile.objs b/target-avr/Makefile.objs
index c503546..bbd2409 100644
--- a/target-avr/Makefile.objs
+++ b/target-avr/Makefile.objs
@@ -1,3 +1,5 @@
-obj-y   += translate.o cpu.o helper.o
+obj-y   += translate.o helper.o cpu.o
 obj-y   += gdbstub.o
 obj-$(CONFIG_SOFTMMU) += machine.o
+
+obj-y   += decode.o
diff --git a/target-avr/translate.c b/target-avr/translate.c
index e98aaef..5a7436f 100644
--- a/target-avr/translate.c
+++ b/target-avr/translate.c
@@ -30,13 +30,32 @@
 #include "exec/helper-gen.h"
 #include "exec/log.h"
 
+uint32_tget_opcode(
+uint8_t const  *code,
+unsignedbitBase,
+unsignedbitSize);
+
 typedef struct DisasContext DisasContext;
 typedef struct InstInfo InstInfo;
 
+typedef int (*translate_function_t)(
+CPUAVRState*env,
+DisasContext   *ctx,
+uint8_t const  *opcode);
+struct InstInfo {
+target_long cpc;
+target_long npc;
+uint32_topcode;
+translate_function_ttranslate;
+unsignedlength;
+};
+
 /*This is the state at translation time.  */
 struct DisasContext {
 struct TranslationBlock*tb;
 
+InstInfoinst[2];/*  two consequitive instructions  
 */
+
 /*Routine used to access memory */
 int memidx;
 int bstate;
@@ -144,6 +163,55 @@ static inline void  gen_goto_tb(CPUAVRState*env,
 }
 }
 
+#include "translate.c.inc"
+
+typedef int (*translate_function_t)(
+CPUAVRState*env,
+DisasContext   *ctx,
+uint8_t const  *opcode);
+voidavr_decode(
+uint32_tpc,
+uint32_t   *length,
+uint8_t const  *code,
+translate_function_t *translate);
+
+
+static void decode_opc(
+AVRCPU *cpu,
+DisasContext   *ctx,
+InstInfo   *inst)
+{
+CPUAVRState*env = >env;
+
+inst->opcode= cpu_ldl_code(env, inst->cpc * 2);   /*  pc points to 
words*/
+inst->length= 16;
+inst->translate = NULL;
+
+/*  the following function looks onto the opcode as a string of bytes   */
+avr_decode(inst->cpc, >length, (uint8_t const *)>opcode, 
>translate);
+
+if (inst->length == 16) {
+inst->npc= inst->cpc + 1;
+/*  get opcode as 16bit value   */
+inst->opcode = inst->opcode & 0x;
+}
+if (inst->length == 32) {
+inst->npc= inst->cpc + 2;
+/*  get opcode as 32bit value   */
+inst->opcode = (inst->opcode << 16)
+ | (inst->opcode >> 16);
+}
+}
+
+uint32_tget_opcode(
+uint8_t const  *code,
+unsignedbitBase,
+unsignedbitSize)
+{
+return  *(uint16_t *)code;
+}
+
+
 /*generate intermediate code for basic block 'tb'.  */
 voidgen_intermediate_code(
 CPUAVRState*env,
@@ -176,18 +244,21 @@ voidgen_intermediate_code(
 gen_tb_start(tb);
 
 /*  decode first instruction*/
-cpc = pc_start;
-npc = cpc + 1;
+ctx.inst[0].cpc = pc_start;
+decode_opc(cpu, , [0]);
 do {
-/*  translate current instruction   */
+/*  set curr/next PCs   */
+cpc = ctx.inst[0].cpc;
+npc = ctx.inst[0].npc;
+
+/*  decode next instruction */
+ctx.inst[1].cpc = ctx.inst[0].npc;
+decode_opc(cpu, , [1]);
+
+/*  translate current instruction */
 tcg_gen_insn_start(cpc);
 num_insns++;
 
-/*  just skip to next instruction   */
-cpc++;
-npc++;
-ctx.bstate  = BS_NONE;
-
 if (unlikely(cpu_breakpoint_test(cs, cpc * 2, BP_ANY))) {
 tcg_gen_movi_i32(cpu_pc, cpc);
 gen_helper_debug(cpu_env);
@@ -199,6 +270,8 @@ voidgen_intermediate_code(
 goto done_generating;
 }
 
+ctx.bstate  = ctx.inst[0].translate(env, , (uint8_t const 
*)[0].opcode);
+
 if (num_insns >= max_insns)

[Qemu-devel] [PATCH 6/9] adding helpers for IN, OUT, SLEEP, WBR & unsupported instructions

Signed-off-by: Michael Rolnik 
---
 target-avr/helper.c | 103 
 target-avr/helper.h |   5 +++
 2 files changed, 108 insertions(+)

diff --git a/target-avr/helper.c b/target-avr/helper.c
index ed22b37..450f598 100644
--- a/target-avr/helper.c
+++ b/target-avr/helper.c
@@ -155,6 +155,23 @@ voidtlb_fill(
 
 tlb_set_page_with_attrs(cs, vaddr, paddr, attrs, prot, mmu_idx, page_size);
 }
+voidhelper_sleep(
+CPUAVRState*env)
+{
+CPUState   *cs = CPU(avr_env_get_cpu(env));
+
+cs->exception_index = EXCP_HLT;
+cpu_loop_exit(cs);
+}
+voidhelper_unsupported(
+CPUAVRState*env)
+{
+CPUState   *cs = CPU(avr_env_get_cpu(env));
+
+cs->exception_index = EXCP_DEBUG;
+cpu_dump_state(cs, stderr, fprintf, 0);
+cpu_loop_exit(cs);
+}
 
 voidhelper_debug(
 CPUAVRState*env)
@@ -165,3 +182,89 @@ voidhelper_debug(
 cpu_loop_exit(cs);
 }
 
+voidhelper_wdr(
+CPUAVRState*env)
+{
+CPUState   *cs = CPU(avr_env_get_cpu(env));
+
+cs->exception_index = EXCP_DEBUG;
+cpu_loop_exit(cs);
+}
+
+target_ulonghelper_inb(
+CPUAVRState*env,
+uint32_tport)
+{
+printf("in: io[%02x]\n", port);
+
+switch (port) {
+case0x3b: {
+return  env->rampZ; /*  RAMPZ */
+}
+case0x3d: { /*  SPL */
+return  env->sp & 0x00ff;
+}
+case0x3e: { /*  SPH */
+return  env->sp >> 8;
+}
+case0x3f: { /*  SREG */
+uint8_t sreg;
+sreg=   (env->sregC & 0x01) << 0
+|   (env->sregZ & 0x01) << 1
+|   (env->sregN & 0x01) << 2
+|   (env->sregV & 0x01) << 3
+|   (env->sregS & 0x01) << 4
+|   (env->sregH & 0x01) << 5
+|   (env->sregT & 0x01) << 6
+|   (env->sregI & 0x01) << 7;
+return  sreg;
+}
+}
+return  0;
+}
+
+voidhelper_outb(
+CPUAVRState*env,
+uint32_tport,
+uint32_tdata)
+{
+printf("out:%02x -> io[%02x]\n", data, port);
+
+data&= 0x00ff;
+
+switch (port) {
+case0x04: {
+qemu_irqirq;
+CPUState   *cpu = CPU(avr_env_get_cpu(env));
+irq = qdev_get_gpio_in(DEVICE(cpu), 3);
+qemu_set_irq(irq, 1);
+break;
+}
+case0x3b: {
+env->rampZ  = data & 0x01;  /*  RAMPZ */
+break;
+}
+case0x3d: { /*  SPL */
+if (avr_feature(env, AVR_FEATURE_2_BYTE_SP)) {
+env->sp = (env->sp & 0xff00) | (data);
+}
+break;
+}
+case0x3e: {  /*  SPH */
+env->sp = (env->sp & 0x00ff) | (data << 8);
+break;
+}
+case0x3f: { /*  SREG */
+env->sregC  = (data >> 0) & 0x01;
+env->sregZ  = (data >> 1) & 0x01;
+env->sregN  = (data >> 2) & 0x01;
+env->sregV  = (data >> 3) & 0x01;
+env->sregS  = (data >> 4) & 0x01;
+env->sregH  = (data >> 5) & 0x01;
+env->sregT  = (data >> 6) & 0x01;
+env->sregI  = (data >> 7) & 0x01;
+break;
+}
+}
+}
+
diff --git a/target-avr/helper.h b/target-avr/helper.h
index 017e076..5a08cfd 100644
--- a/target-avr/helper.h
+++ b/target-avr/helper.h
@@ -18,4 +18,9 @@
  * 
  */
 
+DEF_HELPER_1(wdr,   void,   env)
 DEF_HELPER_1(debug, void,   env)
+DEF_HELPER_1(sleep, void,   env)
+DEF_HELPER_1(unsupported,   void,   env)
+DEF_HELPER_3(outb,  void,   env, i32, i32)
+DEF_HELPER_2(inb,   tl, env, i32)
-- 
2.4.9 (Apple Git-60)

[Qemu-devel] [PATCH 4/9] adding instructions encodings for LE and BE compilers.

I am aware of bad portability of bit fields as compilers
for LE and BE hosts lists bit fields in different order
However they won't "parse" in target memory but a data prepared by me

Signed-off-by: Michael Rolnik 
---
 target-avr/inst-be.h | 1018 ++
 target-avr/inst-le.h | 1018 ++
 2 files changed, 2036 insertions(+)
 create mode 100644 target-avr/inst-be.h
 create mode 100644 target-avr/inst-le.h

diff --git a/target-avr/inst-be.h b/target-avr/inst-be.h
new file mode 100644
index 000..99897c0
--- /dev/null
+++ b/target-avr/inst-be.h
@@ -0,0 +1,1018 @@
+/*
+ * QEMU AVR CPU
+ *
+ * Copyright (c) 2016 Michael Rolnik
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see
+ * 
+ */
+
+
+typedef struct DisasContextDisasContext;
+typedef struct CPUAVRState CPUAVRState;
+
+typedef union avr_opcode_NOP_u {
+uint16_topcode;
+struct {
+uint16_t:16; /*  */
+};
+} avr_opcode_NOP_t;
+int avr_translate_NOP(CPUAVRState *env, DisasContext *ctx, 
avr_opcode_NOP_t const *inst);
+
+typedef union avr_opcode_MOVW_u {
+uint16_topcode;
+struct {
+uint16_t:8; /* 0001 */
+uint16_tRd:4;
+uint16_tRr:4;
+};
+} avr_opcode_MOVW_t;
+int avr_translate_MOVW(CPUAVRState *env, DisasContext *ctx, 
avr_opcode_MOVW_t const *inst);
+
+typedef union avr_opcode_MULS_u {
+uint16_topcode;
+struct {
+uint16_t:8; /* 0010 */
+uint16_tRd:4;
+uint16_tRr:4;
+};
+} avr_opcode_MULS_t;
+int avr_translate_MULS(CPUAVRState *env, DisasContext *ctx, 
avr_opcode_MULS_t const *inst);
+
+typedef union avr_opcode_MULSU_u {
+uint16_topcode;
+struct {
+uint16_t:9; /* 00110 */
+uint16_tRd:3;
+uint16_t:1; /* 0 */
+uint16_tRr:3;
+};
+} avr_opcode_MULSU_t;
+int avr_translate_MULSU(CPUAVRState *env, DisasContext *ctx, 
avr_opcode_MULSU_t const *inst);
+
+typedef union avr_opcode_FMUL_u {
+uint16_topcode;
+struct {
+uint16_t:9; /* 00110 */
+uint16_tRd:3;
+uint16_t:1; /* 1 */
+uint16_tRr:3;
+};
+} avr_opcode_FMUL_t;
+int avr_translate_FMUL(CPUAVRState *env, DisasContext *ctx, 
avr_opcode_FMUL_t const *inst);
+
+typedef union avr_opcode_FMULS_u {
+uint16_topcode;
+struct {
+uint16_t:9; /* 00111 */
+uint16_tRd:3;
+uint16_t:1; /* 0 */
+uint16_tRr:3;
+};
+} avr_opcode_FMULS_t;
+int avr_translate_FMULS(CPUAVRState *env, DisasContext *ctx, 
avr_opcode_FMULS_t const *inst);
+
+typedef union avr_opcode_FMULSU_u {
+uint16_topcode;
+struct {
+uint16_t:9; /* 00111 */
+uint16_tRd:3;
+uint16_t:1; /* 1 */
+uint16_tRr:3;
+};
+} avr_opcode_FMULSU_t;
+int avr_translate_FMULSU(CPUAVRState *env, DisasContext *ctx, 
avr_opcode_FMULSU_t const *inst);
+
+typedef union avr_opcode_CPC_u {
+uint16_topcode;
+struct {
+uint16_t:6; /* 01 */
+uint16_thRr:1;
+uint16_tRd:5;
+uint16_tlRr:4;
+};
+} avr_opcode_CPC_t;
+int avr_translate_CPC(CPUAVRState *env, DisasContext *ctx, 
avr_opcode_CPC_t const *inst);
+
+typedef union avr_opcode_SBC_u {
+uint16_topcode;
+struct {
+uint16_t:6; /* 10 */
+uint16_thRr:1;
+uint16_tRd:5;
+uint16_tlRr:4;
+};
+} avr_opcode_SBC_t;
+int avr_translate_SBC(CPUAVRState *env, DisasContext *ctx, 
avr_opcode_SBC_t const *inst);
+
+typedef union avr_opcode_ADD_u {
+uint16_topcode;
+struct {
+uint16_t:6; /* 11 */
+uint16_thRr:1;
+uint16_tRd:5;
+uint16_tlRr:4;
+};
+} avr_opcode_ADD_t;
+int avr_translate_ADD(CPUAVRState *env, DisasContext *ctx, 
avr_opcode_ADD_t const *inst);
+
+typedef union avr_opcode_AND_u {
+uint16_topcode;
+struct {
+uint16_t:6; /* 001000 */
+uint16_thRr:1;
+uint16_tRd:5;
+uint16_tlRr:4;
+};
+} avr_opcode_AND_t;
+int avr_translate_AND(CPUAVRState *env, DisasContext *ctx, 
avr_opcode_AND_t const *inst);
+
+typedef union

[Qemu-devel] [PATCH 1/9] AVR cores support is added. 1. basic CPU structure 2. registers 3. no instructions

Signed-off-by: Michael Rolnik 
---
 arch_init.c |   2 +
 configure   |   5 +
 default-configs/avr-softmmu.mak |   1 +
 disas/Makefile.objs |   1 +
 disas/avr.c |  10 ++
 include/disas/bfd.h |   7 +
 include/sysemu/arch_init.h  |   1 +
 target-avr/Makefile.objs|   3 +
 target-avr/cpu-qom.h|  97 +
 target-avr/cpu.c| 315 
 target-avr/cpu.h| 152 +++
 target-avr/gdbstub.c| 105 ++
 target-avr/helper.c | 105 ++
 target-avr/helper.h |  21 +++
 target-avr/machine.c|  54 +++
 target-avr/machine.h|  21 +++
 target-avr/translate.c  | 300 ++
 17 files changed, 1200 insertions(+)
 create mode 100644 default-configs/avr-softmmu.mak
 create mode 100644 disas/avr.c
 create mode 100644 target-avr/Makefile.objs
 create mode 100644 target-avr/cpu-qom.h
 create mode 100644 target-avr/cpu.c
 create mode 100644 target-avr/cpu.h
 create mode 100644 target-avr/gdbstub.c
 create mode 100644 target-avr/helper.c
 create mode 100644 target-avr/helper.h
 create mode 100644 target-avr/machine.c
 create mode 100644 target-avr/machine.h
 create mode 100644 target-avr/translate.c

diff --git a/arch_init.c b/arch_init.c
index fa05973..be6e6de 100644
--- a/arch_init.c
+++ b/arch_init.c
@@ -80,6 +80,8 @@ int graphic_depth = 32;
 #define QEMU_ARCH QEMU_ARCH_UNICORE32
 #elif defined(TARGET_TRICORE)
 #define QEMU_ARCH QEMU_ARCH_TRICORE
+#elif defined(TARGET_AVR)
+#define QEMU_ARCH QEMU_ARCH_AVR
 #endif
 
 const uint32_t arch_type = QEMU_ARCH;
diff --git a/configure b/configure
index b5aab72..90af399 100755
--- a/configure
+++ b/configure
@@ -5630,6 +5630,8 @@ case "$target_name" in
   x86_64)
 TARGET_BASE_ARCH=i386
   ;;
+  avr)
+  ;;
   alpha)
   ;;
   arm|armeb)
@@ -5826,6 +5828,9 @@ disas_config() {
 
 for i in $ARCH $TARGET_BASE_ARCH ; do
   case "$i" in
+  avr)
+disas_config "AVR"
+  ;;
   alpha)
 disas_config "ALPHA"
   ;;
diff --git a/default-configs/avr-softmmu.mak b/default-configs/avr-softmmu.mak
new file mode 100644
index 000..ca94aad
--- /dev/null
+++ b/default-configs/avr-softmmu.mak
@@ -0,0 +1 @@
+# Default configuration for avr-softmmu
diff --git a/disas/Makefile.objs b/disas/Makefile.objs
index abeba84..218e434 100644
--- a/disas/Makefile.objs
+++ b/disas/Makefile.objs
@@ -21,6 +21,7 @@ common-obj-$(CONFIG_S390_DIS) += s390.o
 common-obj-$(CONFIG_SH4_DIS) += sh4.o
 common-obj-$(CONFIG_SPARC_DIS) += sparc.o
 common-obj-$(CONFIG_LM32_DIS) += lm32.o
+common-obj-$(CONFIG_AVR_DIS) += avr.o
 
 # TODO: As long as the TCG interpreter and its generated code depend
 # on the QEMU target, we cannot compile the disassembler here.
diff --git a/disas/avr.c b/disas/avr.c
new file mode 100644
index 000..f916e72
--- /dev/null
+++ b/disas/avr.c
@@ -0,0 +1,10 @@
+#include "qemu/osdep.h"
+#include "qemu-common.h"
+#include "disas/bfd.h"
+
+int print_insn_avr(bfd_vma addr, disassemble_info *info)
+{
+int length  = 0;;
+/*  TODO*/
+return length;
+}
diff --git a/include/disas/bfd.h b/include/disas/bfd.h
index a112e9c..04e2201 100644
--- a/include/disas/bfd.h
+++ b/include/disas/bfd.h
@@ -213,6 +213,12 @@ enum bfd_architecture
 #define bfd_mach_m32r  0  /* backwards compatibility */
   bfd_arch_mn10200,/* Matsushita MN10200 */
   bfd_arch_mn10300,/* Matsushita MN10300 */
+  bfd_arch_avr,   /* Atmel AVR microcontrollers.  */
+#define bfd_mach_avr1  1
+#define bfd_mach_avr2  2
+#define bfd_mach_avr3  3
+#define bfd_mach_avr4  4
+#define bfd_mach_avr5  5
   bfd_arch_cris,   /* Axis CRIS */
 #define bfd_mach_cris_v0_v10   255
 #define bfd_mach_cris_v32  32
@@ -415,6 +421,7 @@ int print_insn_crisv10  (bfd_vma, 
disassemble_info*);
 int print_insn_microblaze   (bfd_vma, disassemble_info*);
 int print_insn_ia64 (bfd_vma, disassemble_info*);
 int print_insn_lm32 (bfd_vma, disassemble_info*);
+int print_insn_avr  (bfd_vma, disassemble_info*);
 
 #if 0
 /* Fetch the disassembler for a given BFD, if that support is available.  */
diff --git a/include/sysemu/arch_init.h b/include/sysemu/arch_init.h
index d690dfa..8c75777 100644
--- a/include/sysemu/arch_init.h
+++ b/include/sysemu/arch_init.h
@@ -23,6 +23,7 @@ enum {
 QEMU_ARCH_UNICORE32 = (1 << 14),
 QEMU_ARCH_MOXIE = (1 << 15),
 QEMU_ARCH_TRICORE = (1 << 16),
+QEMU_ARCH_AVR = (1 << 17),
 };
 
 extern const uint32_t arch_type;
diff --git a/target-avr/Makefile.objs b/target-avr/Makefile.objs
new file mode 100644
index 000..c503546
--- /dev/null
+++ b/target-avr/Makefile.objs
@@ -0,0 +1,3 @@
+obj-y   += translate.o cpu.o helper.o
+obj-y   += gdbstub.o
+obj-$(CONFIG_SOFTMMU) += machine.o
diff

[Qemu-devel] [PATCH 5/9] adding AVR interrupt handling

Signed-off-by: Michael Rolnik 
---
 target-avr/helper.c | 64 -
 1 file changed, 63 insertions(+), 1 deletion(-)

diff --git a/target-avr/helper.c b/target-avr/helper.c
index aec37af..ed22b37 100644
--- a/target-avr/helper.c
+++ b/target-avr/helper.c
@@ -33,12 +33,74 @@ boolavr_cpu_exec_interrupt(
 CPUState   *cs,
 int interrupt_request)
 {
-return  false;
+CPUClass*cc  = CPU_GET_CLASS(cs);
+AVRCPU  *cpu = AVR_CPU(cs);
+CPUAVRState *env = >env;
+
+boolret = false;
+
+if (interrupt_request & CPU_INTERRUPT_RESET) {
+if (cpu_interrupts_enabled(env)) {
+cs->exception_index = EXCP_RESET;
+cc->do_interrupt(cs);
+
+cs->interrupt_request   &= ~CPU_INTERRUPT_RESET;
+
+ret = true;
+}
+}
+if (interrupt_request & CPU_INTERRUPT_HARD) {
+if (cpu_interrupts_enabled(env) && env->intsrc != 0) {
+int index   = __builtin_ffs(env->intsrc) - 1;
+cs->exception_index = EXCP_INT(index);
+cc->do_interrupt(cs);
+
+env->intsrc &= env->intsrc - 1; /* clear the interrupt 
*/
+cs->interrupt_request   &= ~CPU_INTERRUPT_HARD;
+
+ret = true;
+}
+}
+return ret;
 }
 
 voidavr_cpu_do_interrupt(
 CPUState   *cs)
 {
+AVRCPU *cpu = AVR_CPU(cs);
+CPUAVRState*env = >env;
+
+uint32_tret = env->pc;
+int vector;
+int size= avr_feature(env, AVR_FEATURE_JMP_CALL) ? 2 : 1;
+int base= 0;/* TODO: where to get it */
+
+if (cs->exception_index == EXCP_RESET) {
+vector  = 0;
+} else if (env->intsrc != 0) {
+vector  = __builtin_ffs(env->intsrc);
+}
+
+if (avr_feature(env, AVR_FEATURE_3_BYTE_PC)) {
+stb_phys(cs->as, env->sp--, (ret & 0xff));
+stb_phys(cs->as, env->sp--, (ret & 0x00ff00) >>  8);
+stb_phys(cs->as, env->sp--, (ret & 0xff) >> 16);
+
+env->pc = base + vector * size;
+} else if (avr_feature(env, AVR_FEATURE_2_BYTE_PC)) {
+stb_phys(cs->as, env->sp--, (ret & 0xff));
+stb_phys(cs->as, env->sp--, (ret & 0x00ff00) >>  8);
+
+env->pc = base + vector * size;
+} else {
+stb_phys(cs->as, env->sp--, (ret & 0xff));
+
+env->pc = base + vector * size;
+}
+
+env->sregI  = 0;/*  clear Global Interrupt Flag */
+
+cs->exception_index = -1;
 }
 
 int avr_cpu_memory_rw_debug(
-- 
2.4.9 (Apple Git-60)

[Qemu-devel] [PATCH 4/4] target-tricore: Added new JNE instruction variant

From: Peer Adelt 

If D[15] is != sign_ext(const4) then PC will be set to (PC +
zero_ext(disp4 + 16)).

Signed-off-by: Peer Adelt 
---
 target-tricore/translate.c   | 1 +
 target-tricore/tricore-opcodes.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/target-tricore/translate.c b/target-tricore/translate.c
index 2145f64..9ad9fcc 100644
--- a/target-tricore/translate.c
+++ b/target-tricore/translate.c
@@ -3363,6 +3363,7 @@ static void gen_compute_branch(DisasContext *ctx, 
uint32_t opc, int r1,
 gen_branch_condi(ctx, TCG_COND_EQ, cpu_gpr_d[15], constant, offset);
 break;
 case OPC1_16_SBC_JNE:
+case OPC1_16_SBC_JNE16:
 gen_branch_condi(ctx, TCG_COND_NE, cpu_gpr_d[15], constant, offset);
 break;
 /* SBRN-format jumps */
diff --git a/target-tricore/tricore-opcodes.h b/target-tricore/tricore-opcodes.h
index 2f25613..7925354 100644
--- a/target-tricore/tricore-opcodes.h
+++ b/target-tricore/tricore-opcodes.h
@@ -318,6 +318,7 @@ enum {
 OPC1_16_SBR_JLEZ = 0x8e,
 OPC1_16_SBR_JLTZ = 0x0e,
 OPC1_16_SBC_JNE  = 0x5e,
+OPC1_16_SBC_JNE16= 0xde,
 OPC1_16_SBR_JNE  = 0x7e,
 OPC1_16_SB_JNZ   = 0xee,
 OPC1_16_SBR_JNZ  = 0xf6,
-- 
2.7.4 (Apple Git-66)

[Qemu-devel] [PATCH 0/4] Added 5 instructions to the tricore target

From: Peer Adelt 

This patch set contains 5 new instructions:
- FTOUZ (converts float to unsigned int, rounds towards zero)
- MADD.F / MSUB.F (multiplies two floats and adds/subtracts result
   to/from the third operand)
- MOV (new variant in RR format - see ISA v1.6 for details)
- JNE (new variant in SBC format - see ISA v1.6 for details) 

Peer Adelt (4):
  target-tricore: Added FTOUZ instruction
  target-tricore: Added MADD.F and MSUB.F instructions
  target-tricore: Added new MOV instruction variant
  target-tricore: Added new JNE instruction variant

 target-tricore/fpu_helper.c  | 74 
 target-tricore/helper.h  |  3 ++
 target-tricore/translate.c   | 16 +
 target-tricore/tricore-opcodes.h |  2 ++
 4 files changed, 95 insertions(+)

-- 
2.7.4 (Apple Git-66)

[Qemu-devel] [PATCH 1/4] target-tricore: Added FTOUZ instruction

From: Peer Adelt 

Converts a 32-bit floating point number to an unsigned int. The
result is rounded towards zero.

Signed-off-by: Peer Adelt 
---
 target-tricore/fpu_helper.c | 20 
 target-tricore/helper.h |  1 +
 target-tricore/translate.c  |  3 +++
 3 files changed, 24 insertions(+)

diff --git a/target-tricore/fpu_helper.c b/target-tricore/fpu_helper.c
index 98fe947..ccaa6b0 100644
--- a/target-tricore/fpu_helper.c
+++ b/target-tricore/fpu_helper.c
@@ -215,3 +215,23 @@ uint32_t helper_itof(CPUTriCoreState *env, uint32_t arg)
 }
 return (uint32_t)f_result;
 }
+
+uint32_t helper_ftouz(CPUTriCoreState *env, uint32_t arg)
+{
+float32 f_arg = make_float32(arg);
+uint32_t result;
+int32_t flags;
+
+result = float32_to_uint32_round_to_zero(f_arg, >fp_status);
+
+flags = f_get_excp_flags(env);
+if (flags) {
+if (float32_is_any_nan(f_arg)) {
+result = 0;
+}
+f_update_psw_flags(env, flags);
+} else {
+env->FPU_FS = 0;
+}
+return (uint32_t)result;
+}
diff --git a/target-tricore/helper.h b/target-tricore/helper.h
index 9333e16..467c880 100644
--- a/target-tricore/helper.h
+++ b/target-tricore/helper.h
@@ -112,6 +112,7 @@ DEF_HELPER_3(fdiv, i32, env, i32, i32)
 DEF_HELPER_3(fcmp, i32, env, i32, i32)
 DEF_HELPER_2(ftoi, i32, env, i32)
 DEF_HELPER_2(itof, i32, env, i32)
+DEF_HELPER_2(ftouz, i32, env, i32)
 /* dvinit */
 DEF_HELPER_3(dvinit_b_13, i64, env, i32, i32)
 DEF_HELPER_3(dvinit_b_131, i64, env, i32, i32)
diff --git a/target-tricore/translate.c b/target-tricore/translate.c
index 83fa4fc..a109c15 100644
--- a/target-tricore/translate.c
+++ b/target-tricore/translate.c
@@ -6698,6 +6698,9 @@ static void decode_rr_divide(CPUTriCoreState *env, 
DisasContext *ctx)
 case OPC2_32_RR_ITOF:
 gen_helper_itof(cpu_gpr_d[r3], cpu_env, cpu_gpr_d[r1]);
 break;
+case OPC2_32_RR_FTOUZ:
+gen_helper_ftouz(cpu_gpr_d[r3], cpu_env, cpu_gpr_d[r1]);
+break;
 default:
 generate_trap(ctx, TRAPC_INSN_ERR, TIN2_IOPC);
 }
-- 
2.7.4 (Apple Git-66)

[Qemu-devel] [PATCH 2/4] target-tricore: Added MADD.F and MSUB.F instructions

From: Peer Adelt 

Multiplies D[a] and D[b] and adds/subtracts the result to/from D[d].
The result is put in D[c]. All operands are floating-point numbers.

Signed-off-by: Peer Adelt 
---
 target-tricore/fpu_helper.c | 54 +
 target-tricore/helper.h |  2 ++
 target-tricore/translate.c  |  8 +++
 3 files changed, 64 insertions(+)

diff --git a/target-tricore/fpu_helper.c b/target-tricore/fpu_helper.c
index ccaa6b0..3207818 100644
--- a/target-tricore/fpu_helper.c
+++ b/target-tricore/fpu_helper.c
@@ -159,6 +159,60 @@ uint32_t helper_fdiv(CPUTriCoreState *env, uint32_t r1, 
uint32_t r2)
 return (uint32_t)f_result;
 }
 
+uint32_t helper_fmadd(CPUTriCoreState *env, uint32_t r1,
+  uint32_t r2, uint32_t r3)
+{
+uint32_t flags;
+float32 arg1 = make_float32(r1);
+float32 arg2 = make_float32(r2);
+float32 arg3 = make_float32(r3);
+float32 f_result;
+
+flags = f_get_excp_flags(env);
+f_result = float32_muladd(arg1, arg2, arg3, flags, >fp_status);
+
+if (flags) {
+/* If the output is a NaN, but the inputs aren't,
+   we return a unique value.  */
+if ((flags & float_flag_invalid)
+&& !float32_is_any_nan(arg1)
+&& !float32_is_any_nan(arg2)) {
+f_result = MUL_NAN;
+}
+f_update_psw_flags(env, flags);
+} else {
+env->FPU_FS = 0;
+}
+return (uint32_t)f_result;
+}
+
+uint32_t helper_fmsub(CPUTriCoreState *env, uint32_t r1,
+  uint32_t r2, uint32_t r3)
+{
+uint32_t flags;
+float32 arg1 = make_float32(r1);
+float32 arg2 = make_float32(r2);
+float32 arg3 = make_float32(r3);
+float32 f_result;
+
+flags = f_get_excp_flags(env);
+f_result = float32_muladd(-arg1, arg2, arg3, flags, >fp_status);
+
+if (flags) {
+/* If the output is a NaN, but the inputs aren't,
+   we return a unique value.  */
+if ((flags & float_flag_invalid)
+&& !float32_is_any_nan(arg1)
+&& !float32_is_any_nan(arg2)) {
+f_result = MUL_NAN;
+}
+f_update_psw_flags(env, flags);
+} else {
+env->FPU_FS = 0;
+}
+return (uint32_t)f_result;
+}
+
 uint32_t helper_fcmp(CPUTriCoreState *env, uint32_t r1, uint32_t r2)
 {
 uint32_t result, flags;
diff --git a/target-tricore/helper.h b/target-tricore/helper.h
index 467c880..c897a44 100644
--- a/target-tricore/helper.h
+++ b/target-tricore/helper.h
@@ -109,6 +109,8 @@ DEF_HELPER_3(fadd, i32, env, i32, i32)
 DEF_HELPER_3(fsub, i32, env, i32, i32)
 DEF_HELPER_3(fmul, i32, env, i32, i32)
 DEF_HELPER_3(fdiv, i32, env, i32, i32)
+DEF_HELPER_4(fmadd, i32, env, i32, i32, i32)
+DEF_HELPER_4(fmsub, i32, env, i32, i32, i32)
 DEF_HELPER_3(fcmp, i32, env, i32, i32)
 DEF_HELPER_2(ftoi, i32, env, i32)
 DEF_HELPER_2(itof, i32, env, i32)
diff --git a/target-tricore/translate.c b/target-tricore/translate.c
index a109c15..e66b433 100644
--- a/target-tricore/translate.c
+++ b/target-tricore/translate.c
@@ -7096,6 +7096,14 @@ static void decode_rrr_divide(CPUTriCoreState *env, 
DisasContext *ctx)
 case OPC2_32_RRR_SUB_F:
 gen_helper_fsub(cpu_gpr_d[r4], cpu_env, cpu_gpr_d[r1], cpu_gpr_d[r3]);
 break;
+case OPC2_32_RRR_MADD_F:
+gen_helper_fmadd(cpu_gpr_d[r4], cpu_env, cpu_gpr_d[r1],
+ cpu_gpr_d[r2], cpu_gpr_d[r3]);
+break;
+case OPC2_32_RRR_MSUB_F:
+gen_helper_fmsub(cpu_gpr_d[r4], cpu_env, cpu_gpr_d[r1],
+ cpu_gpr_d[r2], cpu_gpr_d[r3]);
+break;
 default:
 generate_trap(ctx, TRAPC_INSN_ERR, TIN2_IOPC);
 }
-- 
2.7.4 (Apple Git-66)

[Qemu-devel] [PATCH 3/4] target-tricore: Added new MOV instruction variant

From: Peer Adelt 

Puts the content of data register D[a] into E[c][63:32] and the
content of data register D[b] into E[c][31:0].

Signed-off-by: Peer Adelt 
---
 target-tricore/translate.c   | 4 
 target-tricore/tricore-opcodes.h | 1 +
 2 files changed, 5 insertions(+)

diff --git a/target-tricore/translate.c b/target-tricore/translate.c
index e66b433..2145f64 100644
--- a/target-tricore/translate.c
+++ b/target-tricore/translate.c
@@ -6224,6 +6224,10 @@ static void decode_rr_accumulator(CPUTriCoreState *env, 
DisasContext *ctx)
 case OPC2_32_RR_MOV:
 tcg_gen_mov_tl(cpu_gpr_d[r3], cpu_gpr_d[r2]);
 break;
+case OPC2_32_RR_MOV_EXT:
+tcg_gen_mov_tl(cpu_gpr_d[r3], cpu_gpr_d[r1]);
+tcg_gen_mov_tl(cpu_gpr_d[(r3 + 1)], cpu_gpr_d[r2]);
+break;
 case OPC2_32_RR_NE:
 tcg_gen_setcond_tl(TCG_COND_NE, cpu_gpr_d[r3], cpu_gpr_d[r1],
cpu_gpr_d[r2]);
diff --git a/target-tricore/tricore-opcodes.h b/target-tricore/tricore-opcodes.h
index df666b0..2f25613 100644
--- a/target-tricore/tricore-opcodes.h
+++ b/target-tricore/tricore-opcodes.h
@@ -1062,6 +1062,7 @@ enum {
 OPC2_32_RR_MIN_H = 0x78,
 OPC2_32_RR_MIN_HU= 0x79,
 OPC2_32_RR_MOV   = 0x1f,
+OPC2_32_RR_MOV_EXT   = 0x81,
 OPC2_32_RR_NE= 0x11,
 OPC2_32_RR_OR_EQ = 0x27,
 OPC2_32_RR_OR_GE = 0x2b,
-- 
2.7.4 (Apple Git-66)

Re: [Qemu-devel] [PATCH v6 15/15] translate-all: add tb hash bucket info to 'info jit' dump

On 25/05/16 04:13, Emilio G. Cota wrote:
> Examples:
>
> - Good hashing, i.e. tb_hash_func5(phys_pc, pc, flags):
> TB count715135/2684354
> [...]
> TB hash buckets 388775/524288 (74.15% head buckets used)
> TB hash occupancy   33.04% avg chain occ. Histogram: [0,10)%|▆ █  
> ▅▁▃▁▁|[90,100]%
> TB hash avg chain   1.017 buckets. Histogram: 1|█▁▁|3
>
> - Not-so-good hashing, i.e. tb_hash_func5(phys_pc, pc, 0):
> TB count712636/2684354
> [...]
> TB hash buckets 344924/524288 (65.79% head buckets used)
> TB hash occupancy   31.64% avg chain occ. Histogram: [0,10)%|█ ▆  
> ▅▁▃▁▂|[90,100]%
> TB hash avg chain   1.047 buckets. Histogram: 1|█▁▁▁|4
>
> - Bad hashing, i.e. tb_hash_func5(phys_pc, 0, 0):
> TB count702818/2684354
> [...]
> TB hash buckets 112741/524288 (21.50% head buckets used)
> TB hash occupancy   10.15% avg chain occ. Histogram: [0,10)%|█ ▁  
> ▁|[90,100]%
> TB hash avg chain   2.107 buckets. Histogram: 
> [1.0,10.2)|█▁|[83.8,93.0]
>
> - Good hashing, but no auto-resize:
> TB count715634/2684354
> TB hash buckets 8192/8192 (100.00% head buckets used)
> TB hash occupancy   98.30% avg chain occ. Histogram: 
> [95.3,95.8)%|▁▁▃▄▃▄▁▇▁█|[99.5,100.0]%
> TB hash avg chain   22.070 buckets. Histogram: 
> [15.0,16.7)|▁▂▅▄█▅|[30.3,32.0]

I personally don't see much use of the histogram labels. However,

Acked-by: Sergey Fedorov 

>
> Suggested-by: Richard Henderson 
> Reviewed-by: Richard Henderson 
> Signed-off-by: Emilio G. Cota 
> ---
>  translate-all.c | 36 
>  1 file changed, 36 insertions(+)
>
> diff --git a/translate-all.c b/translate-all.c
> index 5357737..c8074cf 100644
> --- a/translate-all.c
> +++ b/translate-all.c
> @@ -1667,6 +1667,10 @@ void dump_exec_info(FILE *f, fprintf_function 
> cpu_fprintf)
>  int i, target_code_size, max_target_code_size;
>  int direct_jmp_count, direct_jmp2_count, cross_page;
>  TranslationBlock *tb;
> +struct qht_stats hst;
> +uint32_t hgram_opts;
> +size_t hgram_bins;
> +char *hgram;
>  
>  target_code_size = 0;
>  max_target_code_size = 0;
> @@ -1717,6 +1721,38 @@ void dump_exec_info(FILE *f, fprintf_function 
> cpu_fprintf)
>  direct_jmp2_count,
>  tcg_ctx.tb_ctx.nb_tbs ? (direct_jmp2_count * 100) /
>  tcg_ctx.tb_ctx.nb_tbs : 0);
> +
> +qht_statistics_init(_ctx.tb_ctx.htable, );
> +
> +cpu_fprintf(f, "TB hash buckets %zu/%zu (%0.2f%% head buckets 
> used)\n",
> +hst.used_head_buckets, hst.head_buckets,
> +(double)hst.used_head_buckets / hst.head_buckets * 100);
> +
> +hgram_opts =  QDIST_PR_BORDER | QDIST_PR_LABELS;
> +hgram_opts |= QDIST_PR_100X   | QDIST_PR_PERCENT;
> +if (qdist_xmax() - qdist_xmin() == 1) {
> +hgram_opts |= QDIST_PR_NODECIMAL;
> +}
> +hgram = qdist_pr(, 10, hgram_opts);
> +cpu_fprintf(f, "TB hash occupancy   %0.2f%% avg chain occ. Histogram: 
> %s\n",
> +qdist_avg() * 100, hgram);
> +g_free(hgram);
> +
> +hgram_opts = QDIST_PR_BORDER | QDIST_PR_LABELS;
> +hgram_bins = qdist_xmax() - qdist_xmin();
> +if (hgram_bins > 10) {
> +hgram_bins = 10;
> +} else {
> +hgram_bins = 0;
> +hgram_opts |= QDIST_PR_NODECIMAL | QDIST_PR_NOBINRANGE;
> +}
> +hgram = qdist_pr(, hgram_bins, hgram_opts);
> +cpu_fprintf(f, "TB hash avg chain   %0.3f buckets. Histogram: %s\n",
> +qdist_avg(), hgram);
> +g_free(hgram);
> +
> +qht_statistics_destroy();
> +
>  cpu_fprintf(f, "\nStatistics:\n");
>  cpu_fprintf(f, "TB flush count  %d\n", 
> tcg_ctx.tb_ctx.tb_flush_count);
>  cpu_fprintf(f, "TB invalidate count %d\n",

Re: [Qemu-devel] [PATCH v6 14/15] tb hash: track translated blocks with qht

On 25/05/16 04:13, Emilio G. Cota wrote:
> Having a fixed-size hash table for keeping track of all translation blocks
> is suboptimal: some workloads are just too big or too small to get maximum
> performance from the hash table. The MRU promotion policy helps improve
> performance when the hash table is a little undersized, but it cannot
> make up for severely undersized hash tables.
>
> Furthermore, frequent MRU promotions result in writes that are a scalability
> bottleneck. For scalability, lookups should only perform reads, not writes.
> This is not a big deal for now, but it will become one once MTTCG matures.
>
> The appended fixes these issues by using qht as the implementation of
> the TB hash table. This solution is superior to other alternatives considered,
> namely:
>
> - master: implementation in QEMU before this patchset
> - xxhash: before this patch, i.e. fixed buckets + xxhash hashing + MRU.
> - xxhash-rcu: fixed buckets + xxhash + RCU list + MRU.
>   MRU is implemented here by adding an intermediate struct
>   that contains the u32 hash and a pointer to the TB; this
>   allows us, on an MRU promotion, to copy said struct (that is not
>   at the head), and put this new copy at the head. After a grace
>   period, the original non-head struct can be eliminated, and
>   after another grace period, freed.
> - qht-fixed-nomru: fixed buckets + xxhash + qht without auto-resize +
>no MRU for lookups; MRU for inserts.
> The appended solution is the following:
> - qht-dyn-nomru: dynamic number of buckets + xxhash + qht w/ auto-resize +
>  no MRU for lookups; MRU for inserts.
>
> The plots below compare the considered solutions. The Y axis shows the
> boot time (in seconds) of a debian jessie image with arm-softmmu; the X axis
> sweeps the number of buckets (or initial number of buckets for 
> qht-autoresize).
> The plots in PNG format (and with errorbars) can be seen here:
>   http://imgur.com/a/Awgnq
>
> Each test runs 5 times, and the entire QEMU process is pinned to a
> single core for repeatability of results.
>
> Host: Intel Xeon E5-2690
>
>   28 +++-+-+-+++
>  A*+ + + master **A*** +
>   27 ++* xxhash ##B###++
>  |  A**A**   xxhash-rcu $$C$$$ |
>   26 C$$  A**A**qht-fixed-nomru*%%D%%%++
>  D%%$$  A**A**A*qht-dyn-mru A*EA
>   25 ++ %%$$  qht-dyn-nomru ++
>  B#%   |
>   24 ++#C$++
>  |  B###  $|
>  |  ## C$$ |
>   23 ++   #   C$$ ++
>  | B##   C$$%%%D
>   22 ++  %B##   C$$C$$C$$C$$C$$C
>  |D%%B##  @E@@%%%D%%%@@@E@@E
>   21 E@@E@@F&&&@@@E@@@&&%%B##B##B##B##B##B
>  + E@@@   F&&&   +  E@ +  F&&&   + +
>   20 +++-+-+-+++
>  141618202224
>  log2 number of buckets
>
>  Host: Intel i7-4790K
>
>   14.5 ++++-++++
>A**   ++ +master **A*** +
> 14 ++ ** xxhash ##B###++
>   13.5 ++   **   xxhash-rcu $$C$$$++
>|qht-fixed-nomru %%D%%% |
> 13 ++ A**   qht-dyn-mru @@E@@@++
>| A*A**A** qht-dyn-nomru  |
>   12.5 C$$   A**A**A*A*****A
> 12 ++ $$A***  ++
>D%%% $$ |
>   11.5 ++  %% ++
>B###  %C$$  |
> 11 ++  ## D% C$   ++
>| #  %  C$$ |
>   10.5 F&##D%

Re: [Qemu-devel] [PATCH v6 13/15] qht: add test-qht-par to invoke qht-bench from 'check' target

On 25/05/16 04:13, Emilio G. Cota wrote:
> diff --git a/tests/test-qht-par.c b/tests/test-qht-par.c
> new file mode 100644
> index 000..fc0cb23
> --- /dev/null
> +++ b/tests/test-qht-par.c
> @@ -0,0 +1,56 @@
(snip)
> +
> +#define TEST_QHT_STRING "tests/qht-bench 1>/dev/null 2>&1 -R -S0.1 -D1 
> -N1"
> +
> +static void test_qht(int n_threads, int update_rate, int duration)
> +{
> +char *str;
> +int rc;
> +
> +str = g_strdup_printf(TEST_QHT_STRING "-n %d -u %d -d %d",

There needs to be an extra space either at the beginning of the literal
string, or at the end of the string defined by TEST_QHT_STRING, so that
we don't get "... -N1-n ...".

> +  n_threads, update_rate, duration);
> +rc = system(str);
> +g_free(str);
> +g_assert_cmpint(rc, ==, 0);
> +}
> +
>

Kind regards,
Sergey

Re: [Qemu-devel] [PATCH v6 12/15] qht: add qht-bench, a performance benchmark

On 25/05/16 04:13, Emilio G. Cota wrote:
> diff --git a/tests/qht-bench.c b/tests/qht-bench.c
> new file mode 100644
> index 000..30d27c8
> --- /dev/null
> +++ b/tests/qht-bench.c
> @@ -0,0 +1,474 @@
(snip)
> +static void do_rw(struct thread_info *info)
> +{
> +struct thread_stats *stats = >stats;
> +uint32_t hash;
> +long *p;
> +
> +if (info->r >= update_threshold) {
> +bool read;
> +
> +p = [info->r & (lookup_range - 1)];
> +hash = h(*p);
> +read = qht_lookup(, is_equal, p, hash);
> +if (read) {
> +stats->rd++;
> +} else {
> +stats->not_rd++;
> +}
> +} else {
> +p = [info->r & (update_range - 1)];
> +hash = h(*p);

The previous two lines are common for the both "if" branches. Lets move
it above the "if".

> +if (info->write_op) {
> +bool written = false;
> +
> +if (qht_lookup(, is_equal, p, hash) == NULL) {
> +written = qht_insert(, p, hash);
> +}
> +if (written) {
> +stats->in++;
> +} else {
> +stats->not_in++;
> +}
> +} else {
> +bool removed = false;
> +
> +if (qht_lookup(, is_equal, p, hash)) {
> +removed = qht_remove(, p, hash);
> +}
> +if (removed) {
> +stats->rm++;
> +} else {
> +stats->not_rm++;
> +}
> +}
> +info->write_op = !info->write_op;
> +}
> +}
> +
> +static void *thread_func(void *p)
> +{
> +struct thread_info *info = p;
> +
> +while (!atomic_mb_read(_start)) {
> +cpu_relax();
> +}
> +
> +rcu_register_thread();

Shouldn't we do this before checking for 'test_start'?

> +
> +rcu_read_lock();

Why don't we do rcu_read_lock()/rcu_read_unlock() inside the loop?

> +while (!atomic_read(_stop)) {
> +info->r = xorshift64star(info->r);
> +info->func(info);
> +}
> +rcu_read_unlock();
> +
> +rcu_unregister_thread();
> +return NULL;
> +}
> +
> +/* sets everything except info->func */
> +static void prepare_thread_info(struct thread_info *info, int i)
> +{
> +/* seed for the RNG; each thread should have a different one */
> +info->r = (i + 1) ^ time(NULL);
> +/* the first update will be a write */
> +info->write_op = true;
> +/* the first resize will be down */
> +info->resize_down = true;
> +
> +memset(>stats, 0, sizeof(info->stats));
> +}
> +
> +static void
> +th_create_n(QemuThread **threads, struct thread_info **infos, const char 
> *name,
> +void (*func)(struct thread_info *), int offset, int n)

'offset' is not used in this function.

> +{
> +struct thread_info *info;
> +QemuThread *th;
> +int i;
> +
> +th = g_malloc(sizeof(*th) * n);
> +*threads = th;
> +
> +info = qemu_memalign(64, sizeof(*info) * n);
> +*infos = info;
> +
> +for (i = 0; i < n; i++) {
> +prepare_thread_info([i], i);
> +info[i].func = func;
> +qemu_thread_create([i], name, thread_func, [i],
> +   QEMU_THREAD_JOINABLE);
> +}
> +}
> +
(snip)
> +
> +static void run_test(void)
> +{
> +unsigned int remaining;
> +int i;
> +

Are we sure all the threads are ready at this point? Otherwise why
bother with 'test_start' flag?

> +atomic_mb_set(_start, true);
> +do {
> +remaining = sleep(duration);
> +} while (remaining);
> +atomic_mb_set(_stop, true);
> +
> +for (i = 0; i < n_rw_threads; i++) {
> +qemu_thread_join(_threads[i]);
> +}
> +for (i = 0; i < n_rz_threads; i++) {
> +qemu_thread_join(_threads[i]);
> +}
> +}
> +
>

Kind regards,
Sergey

Re: [Qemu-devel] [PATCH v6 11/15] qht: add test program

On 25/05/16 04:13, Emilio G. Cota wrote:
> Reviewed-by: Alex Bennée 
> Reviewed-by: Richard Henderson 
> Signed-off-by: Emilio G. Cota 

Acked-by: Sergey Fedorov 

> ---
>  tests/.gitignore |   1 +
>  tests/Makefile   |   6 ++-
>  tests/test-qht.c | 159 
> +++
>  3 files changed, 165 insertions(+), 1 deletion(-)
>  create mode 100644 tests/test-qht.c
>
> diff --git a/tests/.gitignore b/tests/.gitignore
> index 7c0d156..ffde5d2 100644
> --- a/tests/.gitignore
> +++ b/tests/.gitignore
> @@ -50,6 +50,7 @@ test-qdev-global-props
>  test-qemu-opts
>  test-qdist
>  test-qga
> +test-qht
>  test-qmp-commands
>  test-qmp-commands.h
>  test-qmp-event
> diff --git a/tests/Makefile b/tests/Makefile
> index a5af20b..8589b11 100644
> --- a/tests/Makefile
> +++ b/tests/Makefile
> @@ -72,6 +72,8 @@ check-unit-y += tests/test-rcu-list$(EXESUF)
>  gcov-files-test-rcu-list-y = util/rcu.c
>  check-unit-y += tests/test-qdist$(EXESUF)
>  gcov-files-test-qdist-y = util/qdist.c
> +check-unit-y += tests/test-qht$(EXESUF)
> +gcov-files-test-qht-y = util/qht.c
>  check-unit-y += tests/test-bitops$(EXESUF)
>  check-unit-$(CONFIG_HAS_GLIB_SUBPROCESS_TESTS) += 
> tests/test-qdev-global-props$(EXESUF)
>  check-unit-y += tests/check-qom-interface$(EXESUF)
> @@ -395,7 +397,8 @@ test-obj-y = tests/check-qint.o tests/check-qstring.o 
> tests/check-qdict.o \
>   tests/test-x86-cpuid.o tests/test-mul64.o tests/test-int128.o \
>   tests/test-opts-visitor.o tests/test-qmp-event.o \
>   tests/rcutorture.o tests/test-rcu-list.o \
> - tests/test-qdist.o
> + tests/test-qdist.o \
> + tests/test-qht.o
>  
>  $(test-obj-y): QEMU_INCLUDES += -Itests
>  QEMU_CFLAGS += -I$(SRC_PATH)/tests
> @@ -435,6 +438,7 @@ tests/test-int128$(EXESUF): tests/test-int128.o
>  tests/rcutorture$(EXESUF): tests/rcutorture.o $(test-util-obj-y)
>  tests/test-rcu-list$(EXESUF): tests/test-rcu-list.o $(test-util-obj-y)
>  tests/test-qdist$(EXESUF): tests/test-qdist.o $(test-util-obj-y)
> +tests/test-qht$(EXESUF): tests/test-qht.o $(test-util-obj-y)
>  
>  tests/test-qdev-global-props$(EXESUF): tests/test-qdev-global-props.o \
>   hw/core/qdev.o hw/core/qdev-properties.o hw/core/hotplug.o\
> diff --git a/tests/test-qht.c b/tests/test-qht.c
> new file mode 100644
> index 000..c8eb930
> --- /dev/null
> +++ b/tests/test-qht.c
> @@ -0,0 +1,159 @@
> +/*
> + * Copyright (C) 2016, Emilio G. Cota 
> + *
> + * License: GNU GPL, version 2 or later.
> + *   See the COPYING file in the top-level directory.
> + */
> +#include "qemu/osdep.h"
> +#include 
> +#include "qemu/qht.h"
> +
> +#define N 5000
> +
> +static struct qht ht;
> +static int32_t arr[N * 2];
> +
> +static bool is_equal(const void *obj, const void *userp)
> +{
> +const int32_t *a = obj;
> +const int32_t *b = userp;
> +
> +return *a == *b;
> +}
> +
> +static void insert(int a, int b)
> +{
> +int i;
> +
> +for (i = a; i < b; i++) {
> +uint32_t hash;
> +
> +arr[i] = i;
> +hash = i;
> +
> +qht_insert(, [i], hash);
> +}
> +}
> +
> +static void rm(int init, int end)
> +{
> +int i;
> +
> +for (i = init; i < end; i++) {
> +uint32_t hash;
> +
> +hash = arr[i];
> +g_assert_true(qht_remove(, [i], hash));
> +}
> +}
> +
> +static void check(int a, int b, bool expected)
> +{
> +struct qht_stats stats;
> +int i;
> +
> +for (i = a; i < b; i++) {
> +void *p;
> +uint32_t hash;
> +int32_t val;
> +
> +val = i;
> +hash = i;
> +p = qht_lookup(, is_equal, , hash);
> +g_assert_true(!!p == expected);
> +}
> +qht_statistics_init(, );
> +if (stats.used_head_buckets) {
> +g_assert_cmpfloat(qdist_avg(), >=, 1.0);
> +}
> +g_assert_cmpuint(stats.head_buckets, >, 0);
> +qht_statistics_destroy();
> +}
> +
> +static void count_func(struct qht *ht, void *p, uint32_t hash, void *userp)
> +{
> +unsigned int *curr = userp;
> +
> +(*curr)++;
> +}
> +
> +static void check_n(size_t expected)
> +{
> +struct qht_stats stats;
> +
> +qht_statistics_init(, );
> +g_assert_cmpuint(stats.entries, ==, expected);
> +qht_statistics_destroy();
> +}
> +
> +static void iter_check(unsigned int count)
> +{
> +unsigned int curr = 0;
> +
> +qht_iter(, count_func, );
> +g_assert_cmpuint(curr, ==, count);
> +}
> +
> +static void qht_do_test(unsigned int mode, size_t init_entries)
> +{
> +qht_init(, 0, mode);
> +
> +insert(0, N);
> +check(0, N, true);
> +check_n(N);
> +check(-N, -1, false);
> +iter_check(N);
> +
> +rm(101, 102);
> +check_n(N - 1);
> +insert(N, N * 2);
> +check_n(N + N - 1);
> +rm(N, N * 2);
> +check_n(N - 1);
> +insert(101, 102);
> +check_n(N);
> +
> +rm(10, 200);
> +check_n(N - 190);
> +

Re: [Qemu-devel] [PATCH v6 10/15] qht: QEMU's fast, resizable and scalable Hash Table

On 29/05/16 22:52, Sergey Fedorov wrote:
> On 25/05/16 04:13, Emilio G. Cota wrote:
>> +
>> +/* call with head->lock held */
>> +static bool qht_insert__locked(struct qht *ht, struct qht_map *map,
>> +   struct qht_bucket *head, void *p, uint32_t 
>> hash,
>> +   bool *needs_resize)
>> +{
>> +struct qht_bucket *b = head;
>> +struct qht_bucket *prev = NULL;
>> +struct qht_bucket *new = NULL;
>> +int i;
>> +
>> +for (;;) {
>> +if (b == NULL) {
>> +b = qemu_memalign(QHT_BUCKET_ALIGN, sizeof(*b));
>> +memset(b, 0, sizeof(*b));
>> +new = b;
>> +atomic_inc(>n_added_buckets);
>> +if (unlikely(qht_map_needs_resize(map)) && needs_resize) {
>> +*needs_resize = true;
>> +}
>> +}
>> +for (i = 0; i < QHT_BUCKET_ENTRIES; i++) {
>> +if (b->pointers[i]) {
>> +if (unlikely(b->pointers[i] == p)) {
>> +return false;
>> +}
>> +continue;
>> +}
>> +/* found an empty key: acquire the seqlock and write */
>> +seqlock_write_begin(>sequence);
>> +if (new) {
>> +atomic_rcu_set(>next, b);
>> +}
>> +b->hashes[i] = hash;
>> +atomic_set(>pointers[i], p);
>> +seqlock_write_end(>sequence);
>> +return true;
>> +}
>> +prev = b;
>> +b = b->next;
>> +}
>> +}
> Here is my attempt:

static bool qht_insert__locked(struct qht *ht, struct qht_map *map,
   struct qht_bucket *head, void *p,
uint32_t hash,
   bool *needs_resize)
{
struct qht_bucket **bpp = , *new;
int i = 0;

do {
while (i < QHT_BUCKET_ENTRIES) {
if ((*bpp)->pointers[i]) {
if (unlikely((*bpp)->pointers[i] == p)) {
return false;
}
i++;
continue;
}
goto found;
}
bpp = &(*bpp)->next;
i = 0;
} while (*bpp);

new = qemu_memalign(QHT_BUCKET_ALIGN, sizeof(*new));
memset(new, 0, sizeof(*new));
atomic_rcu_set(bpp, new);
atomic_inc(>n_added_buckets);
if (unlikely(qht_map_needs_resize(map)) && needs_resize) {
*needs_resize = true;
}
found:
/* found an empty key: acquire the seqlock and write */
seqlock_write_begin(>sequence);
(*bpp)->hashes[i] = hash;
atomic_set(&(*bpp)->pointers[i], p);
seqlock_write_end(>sequence);
return true;
}

> Feel free to use it as you wish.

Sorry for the chopped email. Hope this one will be better :)

Kind regards,
Sergey

Re: [Qemu-devel] [PATCH v6 10/15] qht: QEMU's fast, resizable and scalable Hash Table

On 25/05/16 04:13, Emilio G. Cota wrote:
> diff --git a/include/qemu/qht.h b/include/qemu/qht.h
> new file mode 100644
> index 000..aec60aa
> --- /dev/null
> +++ b/include/qemu/qht.h
> @@ -0,0 +1,183 @@
(snip)
> +/**
> + * qht_init - Initialize a QHT
> + * @ht: QHT to be initialized
> + * @n_elems: number of entries the hash table should be optimized for.
> + * @mode: bitmask with OR'ed QHT_MODE_*
> + */
> +void qht_init(struct qht *ht, size_t n_elems, unsigned int mode);

First of all, thank you for spending your time on the documentation of
the API!

I was just wondering if it could be worthwhile to pass a hash function
when initializing a QHT. Then we could have variants of qht_insert(),
qht_remove() and qht_lookup() which does not require a computed hash
value but call the function by themselves. This could make sense since a
hash value passed the the functions should always be exactly the same
for the same object.

(snip)
> +/**
> + * qht_remove - remove a pointer from the hash table
> + * @ht: QHT to remove from
> + * @p: pointer to be removed
> + * @hash: hash corresponding to @p
> + *
> + * Attempting to remove a NULL @p is a bug.
> + *
> + * Just-removed @p pointers cannot be immediately freed; they need to remain
> + * valid until the end of the RCU grace period in which qht_remove() is 
> called.
> + * This guarantees that concurrent lookups will always compare against valid
> + * data.

Mention rcu_call1()/call_rcu()/g_free_rcu()?

> + *
> + * Returns true on success.
> + * Returns false if the @p-@hash pair was not found.
> + */
> +bool qht_remove(struct qht *ht, const void *p, uint32_t hash);
> +
(snip)
> diff --git a/util/qht.c b/util/qht.c
> new file mode 100644
> index 000..ca5a620
> --- /dev/null
> +++ b/util/qht.c
> @@ -0,0 +1,837 @@
(snip)
> +/* trigger a resize when n_added_buckets > n_buckets / div */
> +#define QHT_NR_ADDED_BUCKETS_THRESHOLD_DIV 8

Just out of curiosity, how did you get this number?

> +
> +static void qht_do_resize(struct qht *ht, struct qht_map *new);
> +static void qht_grow_maybe(struct qht *ht);

qht_grow_maybe() is used just once. Please consider reordering of
definitions and removing this forward declaration.

(snip)
> +
> +/* call with head->lock held */
> +static bool qht_insert__locked(struct qht *ht, struct qht_map *map,
> +   struct qht_bucket *head, void *p, uint32_t 
> hash,
> +   bool *needs_resize)
> +{
> +struct qht_bucket *b = head;
> +struct qht_bucket *prev = NULL;
> +struct qht_bucket *new = NULL;
> +int i;
> +
> +for (;;) {
> +if (b == NULL) {
> +b = qemu_memalign(QHT_BUCKET_ALIGN, sizeof(*b));
> +memset(b, 0, sizeof(*b));
> +new = b;
> +atomic_inc(>n_added_buckets);
> +if (unlikely(qht_map_needs_resize(map)) && needs_resize) {
> +*needs_resize = true;
> +}
> +}
> +for (i = 0; i < QHT_BUCKET_ENTRIES; i++) {
> +if (b->pointers[i]) {
> +if (unlikely(b->pointers[i] == p)) {
> +return false;
> +}
> +continue;
> +}
> +/* found an empty key: acquire the seqlock and write */
> +seqlock_write_begin(>sequence);
> +if (new) {
> +atomic_rcu_set(>next, b);
> +}
> +b->hashes[i] = hash;
> +atomic_set(>pointers[i], p);
> +seqlock_write_end(>sequence);
> +return true;
> +}
> +prev = b;
> +b = b->next;
> +}
> +}

Here is my attempt:

static bool qht_insert__locked(struct qht *ht, struct qht_map
*map,   
   struct qht_bucket *head, void *p,
uint32_t hash,
   bool
*needs_resize)
{ 

struct qht_bucket **bpp = ,
*new;
int i =
0;
  

do
{  
while (i < QHT_BUCKET_ENTRIES)
{  
if ((*bpp)->pointers[i])
{
if (unlikely((*bpp)->pointers[i] == p))
{ 
return
false; 
   
} 
   
i++;  
   
continue; 
   
} 
goto
found;

[Qemu-devel] [Bug 1580459] Re: Windows (10?) guest freezes entire host on shutdown if using PCI passthrough

Has any one found a way to shutdown/restart the vm without causing a
system lockup or is this just the way it is until a fix is found?

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

Title:
  Windows (10?) guest freezes entire host on shutdown if using PCI
  passthrough

Status in QEMU:
  New
Status in Arch Linux:
  New
Status in Debian:
  New
Status in Fedora:
  New

Bug description:
  Problem: after leaving a Windows VM that uses PCI passthrough (as we
  do for gaming graphics cards, sound cards, and in my case, a USB card)
  running for some amount of time between 1 and 2 hours (it's not
  consistent with exactly how long), and for any amount of time longer
  than that, shutting down that guest will, right as it finishes
  shutting down, freeze the host computer, making it require a hard
  reboot. Unbinding (or in the other user's case, unbinding and THEN
  binding) any PCI device in sysfs, even one that has nothing to do with
  the VM, also has the same effect as shutting down the VM (if the VM
  has been running long enough). So, it's probably an issue related to
  unbinding and binding PCI devices.

  There's a lot of info on this problem over at 
https://bbs.archlinux.org/viewtopic.php?id=206050
  Here's a better-organized list of main details:
  -at least 2 confirmed victims of this bug; 2 (including me) have provided 
lots of info in the link
  -I'm on Arch Linux and the other one is on Gentoo (distro-nonspecific)
  -issue affects my Windows 10 guest and others' Windows guests, but not my 
Arch Linux guest (the others don't have non-Windows guests to test)
  -I'm using libvirt but the other user is not, so it's not an issue with 
libvirt
  -It seems to be version non-specific, too. I first noticed it at, or when 
testing versions still had the issue at (whichever version is lower), Linux 4.1 
and qemu 2.4.0. It still persists in all releases of both since, including the 
newest ones.
  -I can't track down exactly what package downgrade can fix it, as downgrading 
further than Linux 4.1 and qemu 2.4.0 requires Herculean and system-destroying 
changes such as downgrading ncurses, meaning I don't know whether it's a bug in 
QEMU, the Linux kernel, or some weird seemingly unrelated thing.
  -According to the other user, "graphics intensive gameplay (GTA V) can cause 
the crash to happen sooner," as soon as "15 minutes"
  -Also, "bringing up a second passthrough VM with separate hardware will cause 
the same crash," and "bringing up another VM before the two-hour mark will not 
result in a crash," further cementing that it's triggered by the un/binding of 
PCI devices.
  -This is NOT related to the very similar bug that can be worked around by not 
passing through the HDMI device or sound card. Even when we removed all traces 
of any sort of sound card from the VM, it still had the same behavior.

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

[Qemu-devel] [Bug 1580459] Re: Windows (10?) guest freezes entire host on shutdown if using PCI passthrough

2016-05-29 Thread Jimi

Remember, I think we've done enough testing to know that it isn't
specifically the VM shutting down that causes this, but the binding or
unbinding of PCI devices in sysfs, which is something a VM will do on
shutdown if you're passing hardware into it. It *is* caused by the VM
running for more than an hour, but it is *not* technically caused by the
shutdown itself. I titled it as a shutdown issue because that's pretty
much the only situation anybody's going to notice this problem, and we
need to be Google-friendly.

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

Title:
  Windows (10?) guest freezes entire host on shutdown if using PCI
  passthrough

Status in QEMU:
  New
Status in Arch Linux:
  New
Status in Debian:
  New
Status in Fedora:
  New

Bug description:
  Problem: after leaving a Windows VM that uses PCI passthrough (as we
  do for gaming graphics cards, sound cards, and in my case, a USB card)
  running for some amount of time between 1 and 2 hours (it's not
  consistent with exactly how long), and for any amount of time longer
  than that, shutting down that guest will, right as it finishes
  shutting down, freeze the host computer, making it require a hard
  reboot. Unbinding (or in the other user's case, unbinding and THEN
  binding) any PCI device in sysfs, even one that has nothing to do with
  the VM, also has the same effect as shutting down the VM (if the VM
  has been running long enough). So, it's probably an issue related to
  unbinding and binding PCI devices.

  There's a lot of info on this problem over at 
https://bbs.archlinux.org/viewtopic.php?id=206050
  Here's a better-organized list of main details:
  -at least 2 confirmed victims of this bug; 2 (including me) have provided 
lots of info in the link
  -I'm on Arch Linux and the other one is on Gentoo (distro-nonspecific)
  -issue affects my Windows 10 guest and others' Windows guests, but not my 
Arch Linux guest (the others don't have non-Windows guests to test)
  -I'm using libvirt but the other user is not, so it's not an issue with 
libvirt
  -It seems to be version non-specific, too. I first noticed it at, or when 
testing versions still had the issue at (whichever version is lower), Linux 4.1 
and qemu 2.4.0. It still persists in all releases of both since, including the 
newest ones.
  -I can't track down exactly what package downgrade can fix it, as downgrading 
further than Linux 4.1 and qemu 2.4.0 requires Herculean and system-destroying 
changes such as downgrading ncurses, meaning I don't know whether it's a bug in 
QEMU, the Linux kernel, or some weird seemingly unrelated thing.
  -According to the other user, "graphics intensive gameplay (GTA V) can cause 
the crash to happen sooner," as soon as "15 minutes"
  -Also, "bringing up a second passthrough VM with separate hardware will cause 
the same crash," and "bringing up another VM before the two-hour mark will not 
result in a crash," further cementing that it's triggered by the un/binding of 
PCI devices.
  -This is NOT related to the very similar bug that can be worked around by not 
passing through the HDMI device or sound card. Even when we removed all traces 
of any sort of sound card from the VM, it still had the same behavior.

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

[Qemu-devel] [Bug 1580459] Re: Windows (10?) guest freezes entire host on shutdown if using PCI passthrough

I am not having any issues with my drives during normal operation on the
server.  I only see the ata errors when the system locks up.

If there is something I can do please let me know.  I have been trying
to figure this out for over a month now but have had no luck.

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

Title:
  Windows (10?) guest freezes entire host on shutdown if using PCI
  passthrough

Status in QEMU:
  New
Status in Arch Linux:
  New
Status in Debian:
  New
Status in Fedora:
  New

Bug description:
  Problem: after leaving a Windows VM that uses PCI passthrough (as we
  do for gaming graphics cards, sound cards, and in my case, a USB card)
  running for some amount of time between 1 and 2 hours (it's not
  consistent with exactly how long), and for any amount of time longer
  than that, shutting down that guest will, right as it finishes
  shutting down, freeze the host computer, making it require a hard
  reboot. Unbinding (or in the other user's case, unbinding and THEN
  binding) any PCI device in sysfs, even one that has nothing to do with
  the VM, also has the same effect as shutting down the VM (if the VM
  has been running long enough). So, it's probably an issue related to
  unbinding and binding PCI devices.

  There's a lot of info on this problem over at 
https://bbs.archlinux.org/viewtopic.php?id=206050
  Here's a better-organized list of main details:
  -at least 2 confirmed victims of this bug; 2 (including me) have provided 
lots of info in the link
  -I'm on Arch Linux and the other one is on Gentoo (distro-nonspecific)
  -issue affects my Windows 10 guest and others' Windows guests, but not my 
Arch Linux guest (the others don't have non-Windows guests to test)
  -I'm using libvirt but the other user is not, so it's not an issue with 
libvirt
  -It seems to be version non-specific, too. I first noticed it at, or when 
testing versions still had the issue at (whichever version is lower), Linux 4.1 
and qemu 2.4.0. It still persists in all releases of both since, including the 
newest ones.
  -I can't track down exactly what package downgrade can fix it, as downgrading 
further than Linux 4.1 and qemu 2.4.0 requires Herculean and system-destroying 
changes such as downgrading ncurses, meaning I don't know whether it's a bug in 
QEMU, the Linux kernel, or some weird seemingly unrelated thing.
  -According to the other user, "graphics intensive gameplay (GTA V) can cause 
the crash to happen sooner," as soon as "15 minutes"
  -Also, "bringing up a second passthrough VM with separate hardware will cause 
the same crash," and "bringing up another VM before the two-hour mark will not 
result in a crash," further cementing that it's triggered by the un/binding of 
PCI devices.
  -This is NOT related to the very similar bug that can be worked around by not 
passing through the HDMI device or sound card. Even when we removed all traces 
of any sort of sound card from the VM, it still had the same behavior.

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

[Qemu-devel] [Bug 1580459] Re: Windows (10?) guest freezes entire host on shutdown if using PCI passthrough

Additional syslog image

** Attachment added: "20160527_182715.jpg"
   
https://bugs.launchpad.net/qemu/+bug/1580459/+attachment/4672400/+files/20160527_182715.jpg

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

Title:
  Windows (10?) guest freezes entire host on shutdown if using PCI
  passthrough

Status in QEMU:
  New
Status in Arch Linux:
  New
Status in Debian:
  New
Status in Fedora:
  New

Bug description:
  Problem: after leaving a Windows VM that uses PCI passthrough (as we
  do for gaming graphics cards, sound cards, and in my case, a USB card)
  running for some amount of time between 1 and 2 hours (it's not
  consistent with exactly how long), and for any amount of time longer
  than that, shutting down that guest will, right as it finishes
  shutting down, freeze the host computer, making it require a hard
  reboot. Unbinding (or in the other user's case, unbinding and THEN
  binding) any PCI device in sysfs, even one that has nothing to do with
  the VM, also has the same effect as shutting down the VM (if the VM
  has been running long enough). So, it's probably an issue related to
  unbinding and binding PCI devices.

  There's a lot of info on this problem over at 
https://bbs.archlinux.org/viewtopic.php?id=206050
  Here's a better-organized list of main details:
  -at least 2 confirmed victims of this bug; 2 (including me) have provided 
lots of info in the link
  -I'm on Arch Linux and the other one is on Gentoo (distro-nonspecific)
  -issue affects my Windows 10 guest and others' Windows guests, but not my 
Arch Linux guest (the others don't have non-Windows guests to test)
  -I'm using libvirt but the other user is not, so it's not an issue with 
libvirt
  -It seems to be version non-specific, too. I first noticed it at, or when 
testing versions still had the issue at (whichever version is lower), Linux 4.1 
and qemu 2.4.0. It still persists in all releases of both since, including the 
newest ones.
  -I can't track down exactly what package downgrade can fix it, as downgrading 
further than Linux 4.1 and qemu 2.4.0 requires Herculean and system-destroying 
changes such as downgrading ncurses, meaning I don't know whether it's a bug in 
QEMU, the Linux kernel, or some weird seemingly unrelated thing.
  -According to the other user, "graphics intensive gameplay (GTA V) can cause 
the crash to happen sooner," as soon as "15 minutes"
  -Also, "bringing up a second passthrough VM with separate hardware will cause 
the same crash," and "bringing up another VM before the two-hour mark will not 
result in a crash," further cementing that it's triggered by the un/binding of 
PCI devices.
  -This is NOT related to the very similar bug that can be worked around by not 
passing through the HDMI device or sound card. Even when we removed all traces 
of any sort of sound card from the VM, it still had the same behavior.

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

[Qemu-devel] [Bug 1580459] Re: Windows (10?) guest freezes entire host on shutdown if using PCI passthrough

Additional syslog image

** Attachment added: "20160527_182702.jpg"
   
https://bugs.launchpad.net/qemu/+bug/1580459/+attachment/4672388/+files/20160527_182702.jpg

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

Title:
  Windows (10?) guest freezes entire host on shutdown if using PCI
  passthrough

Status in QEMU:
  New
Status in Arch Linux:
  New
Status in Debian:
  New
Status in Fedora:
  New

Bug description:
  Problem: after leaving a Windows VM that uses PCI passthrough (as we
  do for gaming graphics cards, sound cards, and in my case, a USB card)
  running for some amount of time between 1 and 2 hours (it's not
  consistent with exactly how long), and for any amount of time longer
  than that, shutting down that guest will, right as it finishes
  shutting down, freeze the host computer, making it require a hard
  reboot. Unbinding (or in the other user's case, unbinding and THEN
  binding) any PCI device in sysfs, even one that has nothing to do with
  the VM, also has the same effect as shutting down the VM (if the VM
  has been running long enough). So, it's probably an issue related to
  unbinding and binding PCI devices.

  There's a lot of info on this problem over at 
https://bbs.archlinux.org/viewtopic.php?id=206050
  Here's a better-organized list of main details:
  -at least 2 confirmed victims of this bug; 2 (including me) have provided 
lots of info in the link
  -I'm on Arch Linux and the other one is on Gentoo (distro-nonspecific)
  -issue affects my Windows 10 guest and others' Windows guests, but not my 
Arch Linux guest (the others don't have non-Windows guests to test)
  -I'm using libvirt but the other user is not, so it's not an issue with 
libvirt
  -It seems to be version non-specific, too. I first noticed it at, or when 
testing versions still had the issue at (whichever version is lower), Linux 4.1 
and qemu 2.4.0. It still persists in all releases of both since, including the 
newest ones.
  -I can't track down exactly what package downgrade can fix it, as downgrading 
further than Linux 4.1 and qemu 2.4.0 requires Herculean and system-destroying 
changes such as downgrading ncurses, meaning I don't know whether it's a bug in 
QEMU, the Linux kernel, or some weird seemingly unrelated thing.
  -According to the other user, "graphics intensive gameplay (GTA V) can cause 
the crash to happen sooner," as soon as "15 minutes"
  -Also, "bringing up a second passthrough VM with separate hardware will cause 
the same crash," and "bringing up another VM before the two-hour mark will not 
result in a crash," further cementing that it's triggered by the un/binding of 
PCI devices.
  -This is NOT related to the very similar bug that can be worked around by not 
passing through the HDMI device or sound card. Even when we removed all traces 
of any sort of sound card from the VM, it still had the same behavior.

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

[Qemu-devel] [Bug 1580459] Re: Windows (10?) guest freezes entire host on shutdown if using PCI passthrough

I have tried everything to keep it from happening but have had no
success. The likely hood of an entire system lock up is based on how
long the Win 10 VM is on. I personally have not timed it but usually i
can shutdown/restart without problems for about an hour, maybe more.

My Ubuntu vm is not effected by this issue. I am passing thru 4 vcpus
and a SSD that the vm boots from.

What can we do to help troubleshoot this issue? I find it strange the
the problem happens at VM power off and not while the VM is in use.
What happens at VM power off that can lock the entire system up and
cause CPU stall errors.

The posts in syslog vary from time to time but they all end in cpu
stalls.

** Attachment added: "20160527_182656.jpg"

https://bugs.launchpad.net/qemu/+bug/1580459/+attachment/4672387/+files/20160527_182656.jpg

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

Title:
Windows (10?) guest freezes entire host on shutdown if using PCI
passthrough

Status in QEMU:
New
Status in Arch Linux:
New
Status in Debian:
New
Status in Fedora:
New

Bug description:
Problem: after leaving a Windows VM that uses PCI passthrough (as we
do for gaming graphics cards, sound cards, and in my case, a USB card)
running for some amount of time between 1 and 2 hours (it's not
consistent with exactly how long), and for any amount of time longer
than that, shutting down that guest will, right as it finishes
shutting down, freeze the host computer, making it require a hard
reboot. Unbinding (or in the other user's case, unbinding and THEN
binding) any PCI device in sysfs, even one that has nothing to do with
the VM, also has the same effect as shutting down the VM (if the VM
has been running long enough). So, it's probably an issue related to
unbinding and binding PCI devices.

There's a lot of info on this problem over at
https://bbs.archlinux.org/viewtopic.php?id=206050
Here's a better-organized list of main details:
-at least 2 confirmed victims of this bug; 2 (including me) have provided
lots of info in the link
-I'm on Arch Linux and the other one is on Gentoo (distro-nonspecific)
-issue affects my Windows 10 guest and others' Windows guests, but not my
Arch Linux guest (the others don't have non-Windows guests to test)
-I'm using libvirt but the other user is not, so it's not an issue with
libvirt
-It seems to be version non-specific, too. I first noticed it at, or when
testing versions still had the issue at (whichever version is lower), Linux 4.1
and qemu 2.4.0. It still persists in all releases of both since, including the
newest ones.
-I can't track down exactly what package downgrade can fix it, as downgrading
further than Linux 4.1 and qemu 2.4.0 requires Herculean and system-destroying
changes such as downgrading ncurses, meaning I don't know whether it's a bug in
QEMU, the Linux kernel, or some weird seemingly unrelated thing.
-According to the other user, "graphics intensive gameplay (GTA V) can cause
the crash to happen sooner," as soon as "15 minutes"
-Also, "bringing up a second passthrough VM with separate hardware will cause
the same crash," and "bringing up another VM before the two-hour mark will not
result in a crash," further cementing that it's triggered by the un/binding of
PCI devices.
-This is NOT related to the very similar bug that can be worked around by not
passing through the HDMI device or sound card. Even when we removed all traces
of any sort of sound card from the VM, it still had the same behavior.

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

[Qemu-devel] [Bug 1580459] Re: Windows (10?) guest freezes entire host on shutdown if using PCI passthrough

Additional syslog image

** Attachment added: "20160527_182718.jpg"
   
https://bugs.launchpad.net/qemu/+bug/1580459/+attachment/4672401/+files/20160527_182718.jpg

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

Title:
  Windows (10?) guest freezes entire host on shutdown if using PCI
  passthrough

Status in QEMU:
  New
Status in Arch Linux:
  New
Status in Debian:
  New
Status in Fedora:
  New

Bug description:
  Problem: after leaving a Windows VM that uses PCI passthrough (as we
  do for gaming graphics cards, sound cards, and in my case, a USB card)
  running for some amount of time between 1 and 2 hours (it's not
  consistent with exactly how long), and for any amount of time longer
  than that, shutting down that guest will, right as it finishes
  shutting down, freeze the host computer, making it require a hard
  reboot. Unbinding (or in the other user's case, unbinding and THEN
  binding) any PCI device in sysfs, even one that has nothing to do with
  the VM, also has the same effect as shutting down the VM (if the VM
  has been running long enough). So, it's probably an issue related to
  unbinding and binding PCI devices.

  There's a lot of info on this problem over at 
https://bbs.archlinux.org/viewtopic.php?id=206050
  Here's a better-organized list of main details:
  -at least 2 confirmed victims of this bug; 2 (including me) have provided 
lots of info in the link
  -I'm on Arch Linux and the other one is on Gentoo (distro-nonspecific)
  -issue affects my Windows 10 guest and others' Windows guests, but not my 
Arch Linux guest (the others don't have non-Windows guests to test)
  -I'm using libvirt but the other user is not, so it's not an issue with 
libvirt
  -It seems to be version non-specific, too. I first noticed it at, or when 
testing versions still had the issue at (whichever version is lower), Linux 4.1 
and qemu 2.4.0. It still persists in all releases of both since, including the 
newest ones.
  -I can't track down exactly what package downgrade can fix it, as downgrading 
further than Linux 4.1 and qemu 2.4.0 requires Herculean and system-destroying 
changes such as downgrading ncurses, meaning I don't know whether it's a bug in 
QEMU, the Linux kernel, or some weird seemingly unrelated thing.
  -According to the other user, "graphics intensive gameplay (GTA V) can cause 
the crash to happen sooner," as soon as "15 minutes"
  -Also, "bringing up a second passthrough VM with separate hardware will cause 
the same crash," and "bringing up another VM before the two-hour mark will not 
result in a crash," further cementing that it's triggered by the un/binding of 
PCI devices.
  -This is NOT related to the very similar bug that can be worked around by not 
passing through the HDMI device or sound card. Even when we removed all traces 
of any sort of sound card from the VM, it still had the same behavior.

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

[Qemu-devel] [Bug 1580459] Re: Windows (10?) guest freezes entire host on shutdown if using PCI passthrough

Additional syslog image

** Attachment added: "20160527_182710.jpg"
   
https://bugs.launchpad.net/qemu/+bug/1580459/+attachment/4672389/+files/20160527_182710.jpg

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

Title:
  Windows (10?) guest freezes entire host on shutdown if using PCI
  passthrough

Status in QEMU:
  New
Status in Arch Linux:
  New
Status in Debian:
  New
Status in Fedora:
  New

Bug description:
  Problem: after leaving a Windows VM that uses PCI passthrough (as we
  do for gaming graphics cards, sound cards, and in my case, a USB card)
  running for some amount of time between 1 and 2 hours (it's not
  consistent with exactly how long), and for any amount of time longer
  than that, shutting down that guest will, right as it finishes
  shutting down, freeze the host computer, making it require a hard
  reboot. Unbinding (or in the other user's case, unbinding and THEN
  binding) any PCI device in sysfs, even one that has nothing to do with
  the VM, also has the same effect as shutting down the VM (if the VM
  has been running long enough). So, it's probably an issue related to
  unbinding and binding PCI devices.

  There's a lot of info on this problem over at 
https://bbs.archlinux.org/viewtopic.php?id=206050
  Here's a better-organized list of main details:
  -at least 2 confirmed victims of this bug; 2 (including me) have provided 
lots of info in the link
  -I'm on Arch Linux and the other one is on Gentoo (distro-nonspecific)
  -issue affects my Windows 10 guest and others' Windows guests, but not my 
Arch Linux guest (the others don't have non-Windows guests to test)
  -I'm using libvirt but the other user is not, so it's not an issue with 
libvirt
  -It seems to be version non-specific, too. I first noticed it at, or when 
testing versions still had the issue at (whichever version is lower), Linux 4.1 
and qemu 2.4.0. It still persists in all releases of both since, including the 
newest ones.
  -I can't track down exactly what package downgrade can fix it, as downgrading 
further than Linux 4.1 and qemu 2.4.0 requires Herculean and system-destroying 
changes such as downgrading ncurses, meaning I don't know whether it's a bug in 
QEMU, the Linux kernel, or some weird seemingly unrelated thing.
  -According to the other user, "graphics intensive gameplay (GTA V) can cause 
the crash to happen sooner," as soon as "15 minutes"
  -Also, "bringing up a second passthrough VM with separate hardware will cause 
the same crash," and "bringing up another VM before the two-hour mark will not 
result in a crash," further cementing that it's triggered by the un/binding of 
PCI devices.
  -This is NOT related to the very similar bug that can be worked around by not 
passing through the HDMI device or sound card. Even when we removed all traces 
of any sort of sound card from the VM, it still had the same behavior.

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

Re: [Qemu-devel] [PULL V3 00/20] Net patches

2016-05-29 Thread Peter Maydell

On 29 May 2016 at 16:22, Dmitry Fleytman  wrote:
> It turned out that the issue is not in the new code but in
> pci.h helper functions used by the new code to fill DSN capability.

Thanks for tracking this down.

> Following patch fixes the problem:
>
> diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
> index ef6ba51..ee238ad
> --- a/include/hw/pci/pci.h
> +++ b/include/hw/pci/pci.h
> @@ -468,13 +468,13 @@ pci_get_long(const uint8_t *config)
>  static inline void
>  pci_set_quad(uint8_t *config, uint64_t val)
>  {
> -cpu_to_le64w((uint64_t *)config, val);
> +stq_le_p(config, val);
>  }
>
>  static inline uint64_t
>  pci_get_quad(const uint8_t *config)
>  {
> -return le64_to_cpup((const uint64_t *)config);
> +return ldq_le_p(config);
>  }
>
> I see from git blame that some time ago you did similar change in all other
> pci_set_* pci_get_* functions except these two.
>
> Is there any specific reason you did not change these two functions then?

The patches where I changed the other functions were cleanups
to convert away from some legacy *_to_cpupu() functions, which
were specifically intended to work with unaligned pointers
(which is what the "u" indicated). I was doing the cleanups
per-conversion-function, not per-callsite, and since these
two functions aren't using a _to_cpupu() function but just
_to_cpup() they wouldn't have shown up in my searches.

In any case this is the correct fix, and we should probably
audit the other uses of *_to_cpup and cpu_to_* -- I suspect
many of them are working with possibly-unaligned
pointers in to guest memory and we should replace them with
ld*_*_p functions and get rid of the _to_cpup functions entirely.

thanks
-- PMM

Re: [Qemu-devel] [PULL V3 00/20] Net patches

2016-05-29 Thread Dmitry Fleytman


> On 27 May 2016, at 06:35 AM, Jason Wang  wrote:
> 
> 
> 
> On 2016年05月26日 23:08, Peter Maydell wrote:
>> On 26 May 2016 at 03:16, Jason Wang  wrote:
>>> The following changes since commit 287db79df8af8e31f18e262feb5e05103a09e4d4:
>>> 
>>>   Merge remote-tracking branch 'remotes/ehabkost/tags/x86-pull-request' 
>>> into staging (2016-05-24 13:06:33 +0100)
>>> 
>>> are available in the git repository at:
>>> 
>>>   https://github.com/jasowang/qemu.git tags/net-pull-request
>>> 
>>> for you to fetch changes up to 136796b070ddd09dd14ef73e77ae20419ba6554a:
>>> 
>>>   net/net: Add SocketReadState for reuse codes (2016-05-26 09:58:22 +0800)
>>> 
>>> 
>>> 
>>> Main changes:
>>> - e1000e emulation
>>> - convet vmxnet3 to use DMA api
>>> Changes from V2:
>>> - fix clang build
>>> Changes from V1:
>>> - fix 32bit build
>> Hi. I'm afraid this introduces new errors in the clang sanitizer output
>> from make check: all the check-qtest-i386 and check-qtest-x86_64
>> runs produce output like:
>> 
>> /home/petmay01/linaro/qemu-for-merges/hw/pci/pcie.c:641:25: runtime
>> error: left shift of 4092 by 20 places cannot be
>>  represented in type 'int'
>> /home/petmay01/linaro/qemu-for-merges/hw/pci/pcie.c:642:45: runtime
>> error: left shift of 4092 by 20 places cannot be
>>  represented in type 'int'
>> ==14902==WARNING: Trying to symbolize code, but external symbolizer is
>> not initialized!
>> /home/petmay01/linaro/qemu-for-merges/include/qemu/bswap.h:120:1:
>> runtime error: store to misaligned address 0x2b23c01e6674 for type
>> 'uint64_t' (aka 'unsigned long'), which requires 8 byte alignment
>> 0x2b23c01e6674: note: pointer points here
>>   03 00 01 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00
>> 00 00  00 00 00 00 00 00 00 00
>>   ^
> 
> Sorry for the trouble again. Wonder the correct way to enable sanitizer, 
> after I add "-fsanitizer=address", it produces tons of warnings and errors 
> but don't find the above outputs.
> 
>> The stuff about left shifts is just the usual shift-into-sign-bit
>> which we haven't yet sorted out what we're doing with (ie
>> whether we can ignore them and shut up the sanitizer without
>> silencing other interesting warnings), but we shouldn't be doing
>> misaligned stores of 64-bit values.
> 
> I agree.
> 
>> 
>> Apologies for the lack of any backtraces in the output, but
>> this is almost certainly the result of trying to do le64_to_cpu()
>> or cpu_to_le64() on a buffer which isn't necessarily aligned
>> (usually some pointer into guest memory). Use the functions
>> ldq_le_p() and stq_le_p() instead, which will handle a
>> potentially misaligned pointer for you. (There are similar
>> functions for other access widths too.)
>> 
>> thanks
>> -- PMM
> 
> Leonid and Dmitry, please check the guest memory access as suggested above 
> and respin the series. I will hold the pull until the new version.

Hi Peter,

It turned out that the issue is not in the new code but in pci.h helper 
functions used by the new code to fill DSN capability.

Following patch fixes the problem:

diff --git a/include/hw/pci/pci.h b/include/hw/pci/pci.h
index ef6ba51..ee238ad
--- a/include/hw/pci/pci.h
+++ b/include/hw/pci/pci.h
@@ -468,13 +468,13 @@ pci_get_long(const uint8_t *config)
 static inline void
 pci_set_quad(uint8_t *config, uint64_t val)
 {
-cpu_to_le64w((uint64_t *)config, val);
+stq_le_p(config, val);
 }

 static inline uint64_t
 pci_get_quad(const uint8_t *config)
 {
-return le64_to_cpup((const uint64_t *)config);
+return ldq_le_p(config);
 }

I see from git blame that some time ago you did similar change in all other
pci_set_* pci_get_* functions except these two.

Is there any specific reason you did not change these two functions then?

Thanks,
Dmitry

> 
> Thanks
> 
>

Re: [Qemu-devel] [PATCH] target-s390x: Mask the SIGP order_code to 8bit.

2016-05-29 Thread Philipp Kern

Hi,

On Wed, Aug 26, 2015 at 11:18:42AM +0200, Alexander Graf wrote:
> On 20.08.15 19:16, Thomas Huth wrote:
> > On 18/08/15 04:50, Philipp Kern wrote:
> >> According to "CPU Signaling and Response", "Signal-Processor Orders",
> >> the order field is bit position 56-63. Without this, the Linux
> >> guest kernel is sometimes unable to stop emulation and enters
> >> an infinite loop of "XXX unknown sigp: 0x0005".
> >>
> >> Signed-off-by: Philipp Kern 
> >> ---
> >>  target-s390x/misc_helper.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/target-s390x/misc_helper.c b/target-s390x/misc_helper.c
> >> index 8eac0e1..0f0907c 100644
> >> --- a/target-s390x/misc_helper.c
> >> +++ b/target-s390x/misc_helper.c
> >> @@ -500,7 +500,7 @@ uint32_t HELPER(sigp)(CPUS390XState *env, uint64_t 
> >> order_code, uint32_t r1,
> >>  /* Remember: Use "R1 or R1 + 1, whichever is the odd-numbered 
> >> register"
> >> as parameter (input). Status (output) is always R1. */
> >>  
> >> -switch (order_code) {
> >> +switch (order_code & 0xff) {
> >>  case SIGP_SET_ARCH:
> >>  /* switch arch */
> >>  break;
> > 
> > Reviewed-by: Thomas Huth 
> Thanks, applied to s390-next.

it looks like this patch never made it to qemu master. Could someone apply it
please?

(It also seems to be the only pending patch in agraf's s390-next[1].)

Kind regards and thanks
Philipp Kern

[1] https://github.com/agraf/qemu/tree/s390-next


signature.asc
Description: Digital signature

Re: [Qemu-devel] Initial commit of AVR cores

2016-05-29 Thread Peter Maydell

On 29 May 2016 at 09:57, Michael Rolnik  wrote:
> 1. Initial commit of AVR 8bit cores support
> 2. all instruction, except BREAK/DES/SPM/SPMX, are implemented
> 3. not fully tested yet, however I was able to execute simple code with
> functions. e.g fibonacci calculation
> 4. the current patch includes a non real, sample board
> 5. this patch does not include any peripheral devices.
> 6. no fuses support yet. PC is set to 0 at reset.

Hi; thanks for this contribution to QEMU. Unfortunately as
it is it isn't really reviewable. If you could take a look
at our documentation on how to submit patches and follow
those recommendations that would be very helpful:
http://wiki.qemu.org/Contribute/SubmitAPatch

In particular, you need to split this single huge
patch up into multiple separate patches which each
do one thing and which aren't too large, and you should
then send those as a set of patch emails, rather than
an email with a patch in an attachment. You should
also make sure there aren't any unnecessary changes
in there too (for instance, what are your changes to
gdbstub.c for?). You might find it helpful to look back
through the qemu-devel archives for where other people
added new-architecture support to see how they
structured their patchsets and what kinds of issues
were raised on code review that might apply to your
patches too.

As a random thing I noticed just scrolling through your
patch, you'll also want to change all these unions:

+typedef union avr_opcode_LDI_1110_u {
+uint16_topcode;
+struct { uint16_tlImm:4;
+uint16_tRd:4;
+uint16_thImm:4;
+uint16_t:4; /* 1110 */
+};
+} avr_opcode_LDI_1110_t;

to something else -- bitfield layouts aren't portable
(there's no guarantees about endianness, for instance).
Most targets use the bitops.h functions like extract32().

thanks
-- PMM

[Qemu-devel] [Bug 1586756] [NEW] "-serial unix:" option of qemu-system-* is broken in qemu 2.6.0

2016-05-29 Thread redcap97

Public bug reported:

I found a bug of "-serial unix:PATH_TO_SOCKET" in qemu 2.6.0 (qemu 2.5.1 works 
fine).
Occasionally, a part of the output of qemu disappears in the bug.

It looks like following commit is the cause:

char: ensure all clients are in non-blocking mode (Author: Daniel P. Berrange 
)
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=64c800f808748522727847b9cdc73412f22dffb9

In this commit, UNIX socket is set to non-blocking mode, but qemu_chr_fe_write 
function doesn't handle EAGAIN.
You should fix code like that:

---
diff --git a/qemu-char.c b/qemu-char.c
index b597ee1..0361d78 100644
--- a/qemu-char.c
+++ b/qemu-char.c
@@ -270,6 +270,7 @@ static int qemu_chr_fe_write_buffer(CharDriverState *s, 
const uint8_t *buf, int
 int qemu_chr_fe_write(CharDriverState *s, const uint8_t *buf, int len)
 {
 int ret;
+int offset = 0;
 
 if (s->replay && replay_mode == REPLAY_MODE_PLAY) {
 int offset;
@@ -280,7 +281,21 @@ int qemu_chr_fe_write(CharDriverState *s, const uint8_t 
*buf, int len)
 }
 
 qemu_mutex_lock(>chr_write_lock);
-ret = s->chr_write(s, buf, len);
+
+while (offset < len) {
+retry:
+ret = s->chr_write(s, buf, len);
+if (ret < 0 && errno == EAGAIN) {
+g_usleep(100);
+goto retry;
+}
+
+if (ret <= 0) {
+break;
+}
+
+offset += ret;
+}
 
 if (ret > 0) {
 qemu_chr_fe_write_log(s, buf, ret);
---

Or please do "git revert 64c800f808748522727847b9cdc73412f22dffb9".

** Affects: qemu
 Importance: Undecided
 Status: New

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

Title:
  "-serial unix:" option of qemu-system-* is broken in qemu 2.6.0

Status in QEMU:
  New

Bug description:
  I found a bug of "-serial unix:PATH_TO_SOCKET" in qemu 2.6.0 (qemu 2.5.1 
works fine).
  Occasionally, a part of the output of qemu disappears in the bug.

  It looks like following commit is the cause:

  char: ensure all clients are in non-blocking mode (Author: Daniel P. Berrange 
)
  
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=64c800f808748522727847b9cdc73412f22dffb9

  In this commit, UNIX socket is set to non-blocking mode, but 
qemu_chr_fe_write function doesn't handle EAGAIN.
  You should fix code like that:

  ---
  diff --git a/qemu-char.c b/qemu-char.c
  index b597ee1..0361d78 100644
  --- a/qemu-char.c
  +++ b/qemu-char.c
  @@ -270,6 +270,7 @@ static int qemu_chr_fe_write_buffer(CharDriverState *s, 
const uint8_t *buf, int
   int qemu_chr_fe_write(CharDriverState *s, const uint8_t *buf, int len)
   {
   int ret;
  +int offset = 0;
   
   if (s->replay && replay_mode == REPLAY_MODE_PLAY) {
   int offset;
  @@ -280,7 +281,21 @@ int qemu_chr_fe_write(CharDriverState *s, const uint8_t 
*buf, int len)
   }
   
   qemu_mutex_lock(>chr_write_lock);
  -ret = s->chr_write(s, buf, len);
  +
  +while (offset < len) {
  +retry:
  +ret = s->chr_write(s, buf, len);
  +if (ret < 0 && errno == EAGAIN) {
  +g_usleep(100);
  +goto retry;
  +}
  +
  +if (ret <= 0) {
  +break;
  +}
  +
  +offset += ret;
  +}
   
   if (ret > 0) {
   qemu_chr_fe_write_log(s, buf, ret);
  ---

  Or please do "git revert 64c800f808748522727847b9cdc73412f22dffb9".

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

Re: [Qemu-devel] [PATCH 0/4] Remove unnecessary glib.h includes

24.05.2016 18:24, Peter Maydell wrote:
> This patchset removes '#include ' lines, because the
> header is already included via osdep.h.
> 
> Patch 1 adds the check to clean-includes, and patches 2-4
> apply it (the breakup into 'tests', 'qga' and 'everything else'
> is semi-arbitrary and just to keep patch sizes down.)
> 
> thanks
> -- PMM
> 
> 
> Peter Maydell (4):
>   clean-includes: Add glib.h to list of unneeded includes
>   tests: Remove unnecessary glib.h includes
>   qga: Remove unnecessary glib.h includes
>   all: Remove unnecessary glib.h includes


Applied series to -trivial, thanks!

/mjt

Re: [Qemu-devel] [PATCH] pc: cleanup unused struct PcRomPciInfo

Applied to -trivial, thanks!

/mjt

Re: [Qemu-devel] [PATCH] e1000: Removing unnecessary if statement

Applied to -trivial, thanks!

/mjt

Re: [Qemu-devel] [PATCH] Fix configure test for PBKDF2 in nettle

Applied to trivial, -thanks!

/mjt

Re: [Qemu-devel] [PATCH] hw: Clean up includes

Aplied to -trivial, thanks!

/mjt

Re: [Qemu-devel] [PATCH] docs: Fix a couple of typos in throttle.txt

Applied to -trivial, thanks!

/mjt

Re: [Qemu-devel] [PATCH] replay: Clean up includes

Applied to -trivial, thanks!

/mjt

Re: [Qemu-devel] [PATCH] fw_cfg: follow CODING_STYLE

18.05.2016 13:59, Cao jin wrote:
> Replace tab with 4 spaces; brace the indented statement.

Applied to -trivial, thanks!

/mjt

Re: [Qemu-devel] [PATCH v2] qdev: Clean up around properties

10.05.2016 15:52, Paolo Bonzini wrote:
> Just comments, so
> 
> Cc: qemu-triv...@nongnu.org
> 
> On 17/04/2016 09:45, Cao jin wrote:
>> include:
>> 1. remove unnecessary declaration of static function
>> 2. fix inconsistency between comment and function name, and typo OOM->QOM
>> 2. update comments of functions, use uniform format(GTK-Doc style)

Applied to -trivial, thanks!

/mjt

Re: [Qemu-devel] [PATCH] monitor: Typo fix

Applied to -trivial, thanks!

/mjt

Re: [Qemu-devel] [PATCH v7 07/25] intel_iommu: define several structs for IOMMU IR

2016-05-29 Thread David Kiarie

On Sun, May 29, 2016 at 11:20 AM, David Kiarie  wrote:
> On Tue, May 17, 2016 at 10:15 AM, Peter Xu  wrote:
>> Several data structs are defined to better support the rest of the
>> patches: IRTE to parse remapping table entries, and IOAPIC/MSI related
>> structure bits to parse interrupt entries to be filled in by guest
>> kernel.
>>
>> Signed-off-by: Peter Xu 
>> ---
>>  include/hw/i386/intel_iommu.h | 60 
>> +++
>>  1 file changed, 60 insertions(+)
>>
>> diff --git a/include/hw/i386/intel_iommu.h b/include/hw/i386/intel_iommu.h
>> index cc49839..4914fe6 100644
>> --- a/include/hw/i386/intel_iommu.h
>> +++ b/include/hw/i386/intel_iommu.h
>> @@ -52,6 +52,9 @@ typedef struct IntelIOMMUState IntelIOMMUState;
>>  typedef struct VTDAddressSpace VTDAddressSpace;
>>  typedef struct VTDIOTLBEntry VTDIOTLBEntry;
>>  typedef struct VTDBus VTDBus;
>> +typedef union VTD_IRTE VTD_IRTE;
>> +typedef union VTD_IR_IOAPICEntry VTD_IR_IOAPICEntry;
>> +typedef union VTD_IR_MSIAddress VTD_IR_MSIAddress;
>>
>>  /* Context-Entry */
>>  struct VTDContextEntry {
>> @@ -90,6 +93,63 @@ struct VTDIOTLBEntry {
>>  bool write_flags;
>>  };
>>
>> +/* Interrupt Remapping Table Entry Definition */
>> +union VTD_IRTE {
>> +struct {
>> +uint8_t present:1;  /* Whether entry present/available */
>> +uint8_t fault_disable:1;/* Fault Processing Disable */
>> +uint8_t dest_mode:1;/* Destination Mode */
>> +uint8_t redir_hint:1;   /* Redirection Hint */
>> +uint8_t trigger_mode:1; /* Trigger Mode */
>> +uint8_t delivery_mode:3;/* Delivery Mode */
>> +uint8_t __avail:4;  /* Available spaces for software */
>> +uint8_t __reserved_0:3; /* Reserved 0 */
>> +uint8_t irte_mode:1;/* IRTE Mode */
>> +uint8_t vector:8;   /* Interrupt Vector */
>> +uint8_t __reserved_1:8; /* Reserved 1 */
>> +uint32_t dest_id:32;/* Destination ID */
>> +uint16_t source_id:16;  /* Source-ID */
>> +uint8_t sid_q:2;/* Source-ID Qualifier */
>> +uint8_t sid_vtype:2;/* Source-ID Validation Type */
>> +uint64_t __reserved_2:44;   /* Reserved 2 */
>> +} QEMU_PACKED;
>> +uint64_t data[2];
>> +};
>> +
>> +/* Programming format for IOAPIC table entries */
>> +union VTD_IR_IOAPICEntry {
>> +struct {
>> +uint8_t vector:8;   /* Vector */
>> +uint8_t __zeros:3;  /* Reserved (all zero) */
>> +uint8_t index_h:1;  /* Interrupt Index bit 15 */
>> +uint8_t status:1;   /* Deliver Status */
>> +uint8_t polarity:1; /* Interrupt Polarity */
>> +uint8_t remote_irr:1;   /* Remote IRR */
>> +uint8_t trigger_mode:1; /* Trigger Mode */
>> +uint8_t mask:1; /* Mask */
>> +uint32_t __reserved:31; /* Reserved (should all zero) */
>> +uint8_t int_mode:1; /* Interrupt Format */
>> +uint16_t index_l:15;/* Interrupt Index bits 14-0 */
>> +} QEMU_PACKED;
>> +uint64_t data;
>> +};
>> +
>> +/* Programming format for MSI/MSI-X addresses */
>> +union VTD_IR_MSIAddress {
>> +struct {
>> +uint8_t __not_care:2;
>> +uint8_t index_h:1;  /* Interrupt index bit 15 */
>> +uint8_t sub_valid:1;/* SHV: Sub-Handle Valid bit */
>> +uint8_t int_mode:1; /* Interrupt format */
>> +uint16_t index_l:15;/* Interrupt index bit 14-0 */
>> +uint16_t __head:12; /* Should always be: 0x0fee */
>> +} QEMU_PACKED;
>> +uint32_t data;
>> +};
>
> In a recent discussion, it was brought to my attention that you might
> have a problem with bitfields when the host cpu is not x86. Have you
> considered this ?

In a case when say the host cpu is little endian.

>
>> +
>> +/* When IR is enabled, all MSI/MSI-X data bits should be zero */
>> +#define VTD_IR_MSI_DATA  (0)
>> +
>>  /* The iommu (DMAR) device state struct */
>>  struct IntelIOMMUState {
>>  SysBusDevice busdev;
>> --
>> 2.4.11
>>

Re: [Qemu-devel] [PATCH] ICH9: fix typo

Applied to -trivial, thanks!

/mjt

Re: [Qemu-devel] [PATCH v7 07/25] intel_iommu: define several structs for IOMMU IR

2016-05-29 Thread David Kiarie

On Tue, May 17, 2016 at 10:15 AM, Peter Xu  wrote:
> Several data structs are defined to better support the rest of the
> patches: IRTE to parse remapping table entries, and IOAPIC/MSI related
> structure bits to parse interrupt entries to be filled in by guest
> kernel.
>
> Signed-off-by: Peter Xu 
> ---
>  include/hw/i386/intel_iommu.h | 60 
> +++
>  1 file changed, 60 insertions(+)
>
> diff --git a/include/hw/i386/intel_iommu.h b/include/hw/i386/intel_iommu.h
> index cc49839..4914fe6 100644
> --- a/include/hw/i386/intel_iommu.h
> +++ b/include/hw/i386/intel_iommu.h
> @@ -52,6 +52,9 @@ typedef struct IntelIOMMUState IntelIOMMUState;
>  typedef struct VTDAddressSpace VTDAddressSpace;
>  typedef struct VTDIOTLBEntry VTDIOTLBEntry;
>  typedef struct VTDBus VTDBus;
> +typedef union VTD_IRTE VTD_IRTE;
> +typedef union VTD_IR_IOAPICEntry VTD_IR_IOAPICEntry;
> +typedef union VTD_IR_MSIAddress VTD_IR_MSIAddress;
>
>  /* Context-Entry */
>  struct VTDContextEntry {
> @@ -90,6 +93,63 @@ struct VTDIOTLBEntry {
>  bool write_flags;
>  };
>
> +/* Interrupt Remapping Table Entry Definition */
> +union VTD_IRTE {
> +struct {
> +uint8_t present:1;  /* Whether entry present/available */
> +uint8_t fault_disable:1;/* Fault Processing Disable */
> +uint8_t dest_mode:1;/* Destination Mode */
> +uint8_t redir_hint:1;   /* Redirection Hint */
> +uint8_t trigger_mode:1; /* Trigger Mode */
> +uint8_t delivery_mode:3;/* Delivery Mode */
> +uint8_t __avail:4;  /* Available spaces for software */
> +uint8_t __reserved_0:3; /* Reserved 0 */
> +uint8_t irte_mode:1;/* IRTE Mode */
> +uint8_t vector:8;   /* Interrupt Vector */
> +uint8_t __reserved_1:8; /* Reserved 1 */
> +uint32_t dest_id:32;/* Destination ID */
> +uint16_t source_id:16;  /* Source-ID */
> +uint8_t sid_q:2;/* Source-ID Qualifier */
> +uint8_t sid_vtype:2;/* Source-ID Validation Type */
> +uint64_t __reserved_2:44;   /* Reserved 2 */
> +} QEMU_PACKED;
> +uint64_t data[2];
> +};
> +
> +/* Programming format for IOAPIC table entries */
> +union VTD_IR_IOAPICEntry {
> +struct {
> +uint8_t vector:8;   /* Vector */
> +uint8_t __zeros:3;  /* Reserved (all zero) */
> +uint8_t index_h:1;  /* Interrupt Index bit 15 */
> +uint8_t status:1;   /* Deliver Status */
> +uint8_t polarity:1; /* Interrupt Polarity */
> +uint8_t remote_irr:1;   /* Remote IRR */
> +uint8_t trigger_mode:1; /* Trigger Mode */
> +uint8_t mask:1; /* Mask */
> +uint32_t __reserved:31; /* Reserved (should all zero) */
> +uint8_t int_mode:1; /* Interrupt Format */
> +uint16_t index_l:15;/* Interrupt Index bits 14-0 */
> +} QEMU_PACKED;
> +uint64_t data;
> +};
> +
> +/* Programming format for MSI/MSI-X addresses */
> +union VTD_IR_MSIAddress {
> +struct {
> +uint8_t __not_care:2;
> +uint8_t index_h:1;  /* Interrupt index bit 15 */
> +uint8_t sub_valid:1;/* SHV: Sub-Handle Valid bit */
> +uint8_t int_mode:1; /* Interrupt format */
> +uint16_t index_l:15;/* Interrupt index bit 14-0 */
> +uint16_t __head:12; /* Should always be: 0x0fee */
> +} QEMU_PACKED;
> +uint32_t data;
> +};

In a recent discussion, it was brought to my attention that you might
have a problem with bitfields when the host cpu is not x86. Have you
considered this ?

> +
> +/* When IR is enabled, all MSI/MSI-X data bits should be zero */
> +#define VTD_IR_MSI_DATA  (0)
> +
>  /* The iommu (DMAR) device state struct */
>  struct IntelIOMMUState {
>  SysBusDevice busdev;
> --
> 2.4.11
>

Re: [Qemu-devel] [PATCH] scripts: Use $(..) instead of deprecated `..`

Applied to -trivial, thanks!

Re: [Qemu-devel] [PATCH] configure: Use $(..) instead of deprecated `..`

Applied to -trivial, thanks!

/mjt

Re: [Qemu-devel] [PATCH] Fix linking relocatable objects on Sparc

11.05.2016 00:16, James Clarke wrote:
> On Sparc, gcc implicitly passes --relax to the linker, but -r is
> incompatible with this. Therefore, if --no-relax is supported, it should
> be passed to the linker.

Applied to -trivial, thanks!

/mjt

Re: [Qemu-devel] [PATCH] qemu-options.hx: Specify the units for -machine kvm_shadow_mem

Applied to -trivial, thanks!

/mjt

Re: [Qemu-devel] [PATCH v2 0/5] muldiv64() trivial fixes

09.05.2016 16:24, Laurent Vivier wrote:
> Some fixes in the use of muldiv64()
> 
> The patches have been generated with the help of coccinelle.
> 
> The first patch contains the scripts used to generate the two following
> patches. As it is done for linux, I've added the scripts under
> scripts/coccinelle.
> 
> v2:
> - rework scripts/coccinelle/swap_muldiv64.cocci, to simplify it
> - add overflow_muldiv64.cocci and simplify_muldiv64.cocci
> - add resulting patches
> 
> Laurent Vivier (5):
>   scripts: add muldiv64() checking coccinelle scripts
>   The only 64bit parameter of muldiv64() is the first one.
>   remove useless muldiv64()
>   replace muldiv64(a, b, c) by (uint64_t)a * b / c
>   ppc: Remove a potential overflow in muldiv64()

Applied series to -trivial, thanks!

/mjt

Re: [Qemu-devel] [PATCH] gdbstub: set listen backlog to 1

04.05.2016 12:32, Peter Wu wrote:
> Avoid possible connection drops on Linux (when tcp_syncookies is
> disabled) or fallbacks to SYN cookies with the following kernel warning:
> 
> TCP: request_sock_TCP: Possible SYN flooding on port 1234. Sending 
> cookies.  Check SNMP counters.
> 
> Since Linux 4.4 (ef547f2ac16b "tcp: remove max_qlen_log"), a backlog of
> zero is really treated as the "queue length for completely established
> sockets waiting to be accepted" (listen(2)). This is apparently a valid
> interpretation of an "implementation-defined minimum value" for a
> backlog value of 0 (listen(3p)). Previous kernels would use 8 as
> minimum value, but that is no longer the case.

Applied to -trivial, thanks!

/mjt

Re: [Qemu-devel] [PATCH] po/Makefile: call rm -f directly

20.03.2016 04:58, Jan Vesely wrote:
> Default variables are undefined in rules.mak and this is what the rest
> of the build system uses.
> Fixes make clean in ./po/

Please add qemu-devel@ address for all patches.

Applied to -trivial, thank you!


> Signed-off-by: Jan Vesely 
> ---
>  po/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/po/Makefile b/po/Makefile
> index b271f79..7bab09d 100644
> --- a/po/Makefile
> +++ b/po/Makefile
> @@ -32,7 +32,7 @@ update: $(SRCS)
>  build: $(OBJS)
>  
>  clean:
> - $(RM) $(OBJS)
> + rm -f $(OBJS)
>  
>  install: $(OBJS)
>   for obj in $(OBJS); do \
>

Re: [Qemu-devel] [PATCH] pci: fix identation

Applied to -trivial.

Please don't bother sending identation-fixing-only patches :)

Thanks,

/mjt

Re: [Qemu-devel] [PATCH] target-moxie: Remove unused struct elements