Re: [Qemu-devel] [PATCH v3] qemu-ga: Add guest-network-info command
On Fri, Feb 17, 2012 at 12:06, Michal Privoznik mpriv...@redhat.com wrote:
This command returns an array of:
[ifname, ipaddr, ipaddr_family, prefix, hwaddr]
for each interface in the system that has an IP address.
Currently, only IPv4 and IPv6 are supported.
Signed-off-by: Michal Privoznik mpriv...@redhat.com
---
diff to v2:
-Properly set IP addr family for IPv6
diff to v1:
-move from guest-getip to guest-network-info
-replace black boxed algorithm for population count
-several coding styles improvements
qapi-schema-guest.json | 29
qga/guest-agent-commands.c | 164
2 files changed, 193 insertions(+), 0 deletions(-)
diff --git a/qapi-schema-guest.json b/qapi-schema-guest.json
index 5f8a18d..ca4fdc5 100644
--- a/qapi-schema-guest.json
+++ b/qapi-schema-guest.json
@@ -219,3 +219,32 @@
##
{ 'command': 'guest-fsfreeze-thaw',
'returns': 'int' }
+
+##
+# @guest-network-info:
+#
+# Get list of guest IP addresses, MAC addresses
+# and netmasks.
+#
+# @name: The name of interface for which info are being delivered
+#
+# @ipaddr: IP address assigned to @name
+#
+# @ipaddrtype: Type of @ipaddr (e.g. ipv4, ipv6)
+#
+# @prefix: Network prefix length
+#
+# @hwaddr: Hardware address of @name
+#
+# Returns: List of GuestNetworkInfo on success.
+#
+# Since: 1.1
+##
+{ 'enum': 'GuestIpAddrType',
+ 'data': [ 'ipv4', 'ipv6' ] }
+{ 'type': 'GuestNetworkInfo',
+ 'data': {'iface': {'name': 'str', 'ipaddr': 'str',
+ 'ipaddrtype': 'GuestIpAddrType',
+ 'prefix': 'int', 'hwaddr': 'str'} } }
+{ 'command': 'guest-network-info',
+ 'returns': ['GuestNetworkInfo'] }
diff --git a/qga/guest-agent-commands.c b/qga/guest-agent-commands.c
index a09c8ca..04bab68 100644
--- a/qga/guest-agent-commands.c
+++ b/qga/guest-agent-commands.c
@@ -5,6 +5,7 @@
*
* Authors:
* Michael Roth mdr...@linux.vnet.ibm.com
+ * Michal Privoznik mpriv...@redhat.com
*
* This work is licensed under the terms of the GNU GPL, version 2 or later.
* See the COPYING file in the top-level directory.
@@ -23,6 +24,10 @@
#include sys/types.h
#include sys/ioctl.h
+#include ifaddrs.h
+#include arpa/inet.h
+#include sys/socket.h
+#include net/if.h
#include qga/guest-agent-core.h
#include qga-qmp-commands.h
#include qerror.h
@@ -583,3 +588,162 @@ void ga_command_state_init(GAState *s, GACommandState
*cs)
#endif
ga_command_state_add(cs, guest_file_init, NULL);
}
+
+/* Count the number of '1' bits in @x */
+static int32_t
+count_one_bits(uint32_t x)
+{
+ uint32_t count = 0;
+ for (count = 0; x; count++) {
+ x = x-1;
+ }
+ return count;
+}
Please use ctpop32() provided by host-utils.h instead.
+
+/*
+ * Get the list of interfaces among with their
+ * IP/MAC addresses, prefixes and IP versions
+ */
+GuestNetworkInfoList *qmp_guest_network_info(Error **err)
+{
+ GuestNetworkInfoList *head = NULL, *cur_item = NULL;
+ struct ifaddrs *ifap = NULL, *ifa = NULL;
+ char err_msg[512];
+
+ slog(guest-getip called);
+
+ if (getifaddrs(ifap) 0) {
+ snprintf(err_msg, sizeof(err_msg),
+ getifaddrs failed : %s, strerror(errno));
+ error_set(err, QERR_QGA_COMMAND_FAILED, err_msg);
+ goto error;
+ }
+
+ ifa = ifap;
+ while (ifa) {
+ GuestNetworkInfoList *info = NULL;
+ char addr4[INET_ADDRSTRLEN];
+ char addr6[INET6_ADDRSTRLEN];
+ unsigned char *mac_addr;
+ void *tmp_addr_ptr = NULL;
+ int sock, family;
+ int mac_supported;
+ struct ifreq ifr;
+
+ /* Step over interfaces without an address */
+ if (!ifa-ifa_addr) {
+ continue;
+ }
+
+ g_debug(Processing %s interface, ifa-ifa_name);
+
+ family = ifa-ifa_addr-sa_family;
+
+ if (family == AF_INET) {
+ /* interface with IPv4 address */
+ tmp_addr_ptr = ((struct sockaddr_in *)ifa-ifa_addr)-sin_addr;
+ inet_ntop(AF_INET, tmp_addr_ptr, addr4, sizeof(addr4));
+
+ info = g_malloc0(sizeof(*info));
+ info-value = g_malloc0(sizeof(*info-value));
+ info-value-iface.name = g_strdup(ifa-ifa_name);
+ info-value-iface.ipaddr = g_strdup(addr4);
+ info-value-iface.ipaddrtype = GUEST_IP_ADDR_TYPE_IPV4;
+
+ /* This is safe as '1' and '0' cannot be shuffled in netmask. */
+ tmp_addr_ptr = ((struct sockaddr_in
*)ifa-ifa_netmask)-sin_addr;
+ info-value-iface.prefix =
+ count_one_bits(((uint32_t *) tmp_addr_ptr)[0]);
+ } else if (family == AF_INET6) {
+ /* interface with IPv6 address */
+ tmp_addr_ptr = ((struct sockaddr_in6
*)ifa-ifa_addr)-sin6_addr;
+ inet_ntop(AF_INET6, tmp_addr_ptr, addr6, sizeof(addr6));
+
+
Re: [Qemu-devel] [PATCH] build: add needed missing libraries libm and librt
On Wed, Feb 8, 2012 at 17:06, Roger Pau Monne roger@entel.upc.edu wrote: libm is used in cutils.c, but the library was not specified when linking some binaries, throwing the following error: cutils.o: In function `strtosz_suffix_unit': /home/royger/xen-clean/tools/qemu-xen-dir/cutils.c:354: undefined reference to `__isnan' /home/royger/xen-clean/tools/qemu-xen-dir/cutils.c:357: undefined reference to `modf' collect2: ld returned 1 exit status According to modf man page [0], -lm should be used when linking. librt is used in qemu-time.c, but again the library was not specified at link time, throwing the following error: /home/royger/xen-clean/tools/qemu-xen-dir/qemu-timer.c:597: undefined reference to `timer_gettime' /home/royger/xen-clean/tools/qemu-xen-dir/qemu-timer.c:610: undefined reference to `timer_settime' ../qemu-timer.o: In function `dynticks_start_timer': /home/royger/xen-clean/tools/qemu-xen-dir/qemu-timer.c:565: undefined reference to `timer_create' ../qemu-timer.o: In function `dynticks_stop_timer': /home/royger/xen-clean/tools/qemu-xen-dir/qemu-timer.c:583: undefined reference to `timer_delete' collect2: ld returned 1 exit status According to timer_getttime man page [1], -lrt should be used when linking. [0] http://linux.die.net/man/3/modf [1] http://linux.die.net/man/2/timer_gettime This is Linux man page, is this correct for all OS we support? We already have a test for -lrt in configure, but it looks like it does not detect your case correctly. You should fix that instead. Signed-off-by: Roger Pau Monne roger@entel.upc.edu --- Makefile | 4 ++-- Makefile.target | 2 ++ 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 301c75e..e2c3cd4 100644 --- a/Makefile +++ b/Makefile @@ -34,7 +34,7 @@ configure: ; $(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw) -LIBS+=-lz $(LIBS_TOOLS) +LIBS+=-lz -lm -lrt $(LIBS_TOOLS) ifdef BUILD_DOCS DOCS=qemu-doc.html qemu-tech.html qemu.1 qemu-img.1 qemu-nbd.8 QMP/qmp-commands.txt @@ -170,7 +170,7 @@ test-coroutine: test-coroutine.o qemu-timer-common.o async.o $(coroutine-obj-y) $(qapi-obj-y): $(GENERATED_HEADERS) qapi-dir := $(BUILD_DIR)/qapi-generated test-visitor.o test-qmp-commands.o qemu-ga$(EXESUF): QEMU_CFLAGS += -I $(qapi-dir) -qemu-ga$(EXESUF): LIBS = $(LIBS_QGA) +qemu-ga$(EXESUF): LIBS = $(LIBS_QGA) -lm $(qapi-dir)/test-qapi-types.c $(qapi-dir)/test-qapi-types.h :\ $(SRC_PATH)/qapi-schema-test.json $(SRC_PATH)/scripts/qapi-types.py diff --git a/Makefile.target b/Makefile.target index a111521..95d6bc0 100644 --- a/Makefile.target +++ b/Makefile.target @@ -33,6 +33,8 @@ endif PROGS=$(QEMU_PROG) STPFILES= +LIBS+=-lrt + ifndef CONFIG_HAIKU LIBS+=-lm endif -- 1.7.9
Re: [Qemu-devel] [PATCH] socket: add the support for -netdev socket, listen
On Fri, Feb 17, 2012 at 6:24 PM, Stefan Hajnoczi
stefa...@linux.vnet.ibm.com wrote:
On Fri, Feb 17, 2012 at 12:20:08PM +0800, zwu.ker...@gmail.com wrote:
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
As you have known, QEMU upstream currently doesn't support for -netdev
socket,listen; This patch makes it work now.
This commit description does not give any context. Please explain what
the bug is so readers know what this patch fixes.
I tried the following test:
$ x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1024 \
-drive if=virtio,file=vm1.img,cache=none \
-netdev socket,listen=127.0.0.1:1234,id=socket0 \
-device virtio-net-pci,netdev=socket0
$ x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1024 \
-drive if=virtio,file=vm2.img,cache=none \
-netdev socket,connect=127.0.0.1:1234,id=socket0 \
-device virtio-net-pci,netdev=socket0
The first thing I noticed was that the output of info network in vm1
looks wrong. It should show the virtio-net-pci NIC peered with a socket
fd connection. Instead it shows it peered with a dummy VLANClientState
and I see two socket fds with no peers.
By the way, Can you see socket file descriptioner? Where and How did
you see them?
Network connectivity between the two QEMUs does not work. I assigned
static IPs in both VMs, ran tcpdump in vm1, and then tried to ping vm1
from vm2.
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net/socket.c | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index d4c2002..f82e69d 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -43,6 +43,7 @@ typedef struct NetSocketState {
} NetSocketState;
typedef struct NetSocketListenState {
+ VLANClientState *nc;
VLANState *vlan;
char *model;
char *name;
@@ -389,6 +390,11 @@ static void net_socket_accept(void *opaque)
break;
}
}
+
+ if (s-nc) {
+ qemu_del_vlan_client(s-nc);
+ }
+
s1 = net_socket_fd_init(s-vlan, s-model, s-name, fd, 1);
This has a few issues:
net_socket_fd_init() does not set the peer, only vlan. This means the
connected socket and NIC are not peered up.
qemu_del_vlan_client() brings the link down...we never bring it back up.
We need to avoid leaking s-nc because it is not freed in
qemu_del_vlan_client(). Once peering is fixed s-nc will not be freed
during NIC deletion anymore!
It leaves a dangling pointer to s-nc in the qdev netdev property and
NICInfo nd_table[]. Not sure if this is a problem but it's messy.
I suggest using the real NetSocketState instead - do not create a dummy
VLANClientState. This means we create the socket fd NetSocketState
right away and never need to update the peer. Simply bring the link up
once the socket file descriptor is connected.
Stefan
--
Regards,
Zhi Yong Wu
Re: [Qemu-devel] [PATCH] checkpatch: Don't WARN about missing spaces in audio files
On Fri, Feb 17, 2012 at 14:31, Anthony Liguori aligu...@us.ibm.com wrote:
On 02/11/2012 03:44 AM, Blue Swirl wrote:
On Fri, Feb 10, 2012 at 17:47, Anthony Liguorialigu...@us.ibm.com
wrote:
On 02/09/2012 10:02 PM, malc wrote:
On Fri, 10 Feb 2012, Evgeny Voevodin wrote:
On 02/09/2012 06:59 PM, Andreas F?rber wrote:
Disable warnings for spaces before opening parenthesis in
hw/{ac97,adlib,cs4231a,es1370,gus,sb16}.c.
Why audio files are such a special thing?
Because they are consistently formatted the way they are.
I personally hate the QEMU Coding Style I dislike inconsistency more than
any particular style.
I dislike unclear rules more than inconsistency or coding styles.
So I'm with malc here. I'd be opposed to introducing a new file that
deviated from Coding Style but for the ones that already do, I see no
reason
to convert them all at once or make the code deviate from the style it's
already using.
I'd make a rule, specify the level of importance and try to stick to
it. I would not oppose global reformatting to GNU style even (which I
hate) if that would be the rule.
I really hate having these discussions. I would almost rather we just pay
the one-time cost of re-indenting so we can stop debating about this.
Fully agree on both.
For folks that feel strongly about this, please submit the following:
An indent command that takes the tree to CODING_STYLE along with a diffstat
of the end result.
Depending on how bad the diffstat is, we can consider doing this and ending
this set of arguments once and for all.
IIRC GNU indent could not be convinced to follow QEMU style. A quick
test on target-sparc with the command
indent -kr -i4 -nut -sob -l80 -ss -ncs -il0 -cp1 -nfca -TCPUState
-TCPUSPARCState *.[ch]
is very close, but I couldn't avoid comment reformatting despite
-nfca, indent is totally confused with helper.h and some casts get
spaces despite -ncs.
Regards,
Anthony Liguori
I don't like laissez faire, but if
that is the rule then fine.
Isn't it be better to revert a patch that introduced checkpatch.pl
errors?
No.
Regards,
Anthony Liguori
Re: [Qemu-devel] [QEMU] net: adapt dump to support the new syntax
On Fri, Feb 17, 2012 at 6:55 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Fri, Feb 17, 2012 at 6:54 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: I would like to know if some one is playing around with the patchset. If yes, can any one make one response? I am very interested in rebasing it, and then playing with it. AFAIK no one is working on it - the main thing that is missing here is tests so that we don't break the existing VLAN feature and command-line interface. If you are available, can you let us know what their difference among -net, -netdev and hub? their drawback? their advantage? thanks If you have time to play with stuff though it would be good to fix the block I/O limits issue with IDE. Stefan -- Regards, Zhi Yong Wu
[Qemu-devel] [PATCH] astyle: Formatting rules for QEMU
These AStyle rules try to implement the QEMU coding style.
AStyle can also fix only certain aspects of the coding style,
for example indentation.
Signed-off-by: Stefan Weil s...@weilnetz.de
---
Hi Blue,
maybe this AStyle rules work better. I tried them with target-sparc,
and the result does look quite good.
Regards,
Stefan
scripts/astylerc | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
create mode 100644 scripts/astylerc
diff --git a/scripts/astylerc b/scripts/astylerc
new file mode 100644
index 000..dfbfd41
--- /dev/null
+++ b/scripts/astylerc
@@ -0,0 +1,19 @@
+# Artistic Style (astyle) options for qemu source code.
+
+# Usage:
+# astyle --options=scripts/astylerc {source files}
+
+# For best results, use latest astyle from http://astyle.sourceforge.net/.
+
+add-brackets
+align-pointer=name
+convert-tabs
+max-code-length=80
+style=otbs
+brackets=linux
+indent=spaces=4
+max-code-length=80
+max-instatement-indent=60
+pad-oper
+pad-header
+unpad-paren
--
1.7.9
Re: [Qemu-devel] [PATCH] checkpatch: Don't WARN about missing spaces in audio files
On Fri, Feb 17, 2012 at 15:26, Anthony Liguori aligu...@us.ibm.com wrote: On 02/17/2012 08:55 AM, Markus Armbruster wrote: Anthony Liguorialigu...@us.ibm.com writes: I really hate having these discussions. I would almost rather we just pay the one-time cost of re-indenting so we can stop debating about this. For folks that feel strongly about this, please submit the following: An indent command that takes the tree to CODING_STYLE along with a diffstat of the end result. Depending on how bad the diffstat is, we can consider doing this and ending this set of arguments once and for all. The only justification for an idiosyncratic coding style I can buy is minimizing reindentation of old code. Well this was what I was getting at in my previous comments. If we just need to reindent 10 files with a few random changes here and there, then maybe that isn't so bad. But if we have to touch every single file in the tree in a significant way, then no way is it justified. One way to handle this is gradual reformatting, every time when code is touched, only changes towards common CODING_STYLE are allowed. Small, contained reformatting patches should be also allowed, for example to adjust brace style in one file a time or to remove spaces at the end of line. If we reindent anyway, reindent to something that isn't specific to the QEMU island, please. I don't even want to consider something that touches every line of code. That's effectively creating a new source tree and losing the continuity of our SCM history. I think only 'git blame' output would be affected and that is not 100% reliable anyway, considering for example code movement. Regards, Anthony Liguori
[Qemu-devel] [PATCH v2] net: add the support for -netdev socket, listen
From: Zhi Yong Wu wu...@linux.vnet.ibm.com
The -net socket,listen option does not work with the newer -netdev
syntax:
http://lists.gnu.org/archive/html/qemu-devel/2011-11/msg01508.html
This patch makes it work now.
Signed-off-by: Zhi Yong Wu wu...@linux.vnet.ibm.com
---
net.c| 26 +
net.h|2 +
net/socket.c | 72 +-
3 files changed, 84 insertions(+), 16 deletions(-)
diff --git a/net.c b/net.c
index c34474f..60e7b35 100644
--- a/net.c
+++ b/net.c
@@ -190,6 +190,32 @@ static ssize_t qemu_deliver_packet_iov(VLANClientState
*sender,
int iovcnt,
void *opaque);
+VLANClientState *qemu_lookup_net_client(VLANState *vlan,
+const char *name)
+{
+VLANClientState *vc = NULL;
+
+if (vlan) {
+QTAILQ_FOREACH(vc, vlan-clients, next) {
+if (!strcmp(vc-name, name)) {
+break;
+}
+}
+} else {
+QTAILQ_FOREACH(vc, non_vlan_clients, next) {
+if (!strcmp(vc-name, name)) {
+break;
+}
+}
+}
+
+if (!vc) {
+return NULL;
+}
+
+return vc;
+}
+
VLANClientState *qemu_new_net_client(NetClientInfo *info,
VLANState *vlan,
VLANClientState *peer,
diff --git a/net.h b/net.h
index 75a8c15..7f73160 100644
--- a/net.h
+++ b/net.h
@@ -90,6 +90,8 @@ struct VLANState {
VLANState *qemu_find_vlan(int id, int allocate);
VLANClientState *qemu_find_netdev(const char *id);
+VLANClientState *qemu_lookup_net_client(VLANState *vlan,
+const char *name);
VLANClientState *qemu_new_net_client(NetClientInfo *info,
VLANState *vlan,
VLANClientState *peer,
diff --git a/net/socket.c b/net/socket.c
index d4c2002..3ecee59 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -43,6 +43,7 @@ typedef struct NetSocketState {
} NetSocketState;
typedef struct NetSocketListenState {
+VLANClientState *nc;
VLANState *vlan;
char *model;
char *name;
@@ -247,7 +248,8 @@ static NetClientInfo net_dgram_socket_info = {
static NetSocketState *net_socket_fd_init_dgram(VLANState *vlan,
const char *model,
const char *name,
-int fd, int is_connected)
+int fd, int is_connected,
+int is_listen)
{
struct sockaddr_in saddr;
int newfd;
@@ -286,15 +288,28 @@ static NetSocketState *net_socket_fd_init_dgram(VLANState
*vlan,
}
}
-nc = qemu_new_net_client(net_dgram_socket_info, vlan, NULL, model, name);
+
+if (!is_listen || (is_listen !is_connected)) {
+nc = qemu_new_net_client(net_dgram_socket_info,
+ vlan, NULL, model, name);
+} else {
+nc = qemu_lookup_net_client(vlan, name);
+if (!nc) {
+goto err;
+}
+}
+
+s = DO_UPCAST(NetSocketState, nc, nc);
+
+if (is_listen !is_connected) {
+return s;
+}
snprintf(nc-info_str, sizeof(nc-info_str),
socket: fd=%d (%s mcast=%s:%d),
fd, is_connected ? cloned : ,
inet_ntoa(saddr.sin_addr), ntohs(saddr.sin_port));
-s = DO_UPCAST(NetSocketState, nc, nc);
-
s-fd = fd;
qemu_set_fd_handler(s-fd, net_socket_send_dgram, NULL, s);
@@ -325,16 +340,29 @@ static NetClientInfo net_socket_info = {
static NetSocketState *net_socket_fd_init_stream(VLANState *vlan,
const char *model,
const char *name,
- int fd, int is_connected)
+ int fd, int is_connected,
+ int is_listen)
{
VLANClientState *nc;
NetSocketState *s;
-nc = qemu_new_net_client(net_socket_info, vlan, NULL, model, name);
+if (!is_listen || (is_listen !is_connected)) {
+nc = qemu_new_net_client(net_socket_info, vlan, NULL, model, name);
+} else {
+nc = qemu_lookup_net_client(vlan, name);
+if (!nc) {
+return NULL;
+}
+}
+
+s = DO_UPCAST(NetSocketState, nc, nc);
+
+if (is_listen !is_connected) {
+return s;
+}
snprintf(nc-info_str, sizeof(nc-info_str), socket: fd=%d, fd);
-s = DO_UPCAST(NetSocketState, nc, nc);
s-fd = fd;
@@ -348,7 +376,8 @@ static NetSocketState *net_socket_fd_init_stream(VLANState
*vlan,
static NetSocketState
Re: [Qemu-devel] [QEMU] net: adapt dump to support the new syntax
On Sat, Feb 18, 2012 at 8:57 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Fri, Feb 17, 2012 at 6:55 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Fri, Feb 17, 2012 at 6:54 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: I would like to know if some one is playing around with the patchset. If yes, can any one make one response? I am very interested in rebasing it, and then playing with it. AFAIK no one is working on it - the main thing that is missing here is tests so that we don't break the existing VLAN feature and command-line interface. If you are available, can you let us know what their difference among -net, -netdev and hub? their drawback? their advantage? thanks -net is the old command-line option for defining both guest network devices (e.g. e1000, virtio-net) and also host network devices (e.g. tap, socket, user). It uses the VLAN concept and does not use peer IIRC. -netdev/-device is the new way to specify networking. You use -netdev to define host network devices (e.g. tap, socket, user). You use -device to specify guest network devices (e.g. e1000, virtio-net-pci). This approach does not use the VLAN feature and instead uses -peer. That means nic-per == netdev and netdev-peer == nic. There is a performance improvement with -netdev/-device because we do not use VLAN forwarding in the network subsystem and I think it enables tap offloads (checksum offload, GRO, TSO) but I don't remember the detalis there. The hub is the same as QEMU VLANs except it removes all the special case code in the network subsystem and instead implements the functionality in a normal NetClientState. Now the hub is no longer part of the network subsystem, its just a net device in QEMU. The critical thing when transitioning to the hub device is that the old VLAN command-line options must continue to work! Users should see no difference from before. But internally the net subsystem will only deal with NetClientState instead of VLANClientState plus VLANState. Everything will use -peer. Stefan
Re: [Qemu-devel] [RFC] Next gen kvm api
On 02/16/2012 10:41 PM, Scott Wood wrote: Sharing the data structures is not need. Simply synchronize them before lookup, like we do for ordinary registers. Ordinary registers are a few bytes. We're talking of dozens of kbytes here. A TLB way is a few dozen bytes, no? I think you mean a TLB set... Yes, thanks. but the TLB (or part of it) may be fully associative. A fully associative TLB has to be very small. On e500mc, it's 24 bytes for one TLB entry, and you'd need 4 entries for a set of TLB0, and all 64 entries in TLB1. So 1632 bytes total. Syncing this every time you need a translation (for gdb or the monitor) is trivial in terms of performance. Then we'd need to deal with tracking whether we synchronized one or more specific sets, or everything (for migration or debug TLB dump). The request to synchronize would have to come from within the QEMU MMU code, since that's the point where we know what to ask for (unless we duplicate the logic elsewhere). I'm not sure that reusing the standard QEMU MMU code for individual debug address translation is really simplifying things... And yes, we do have fancier hardware coming fairly soon for which this breaks (TLB0 entries can be loaded without host involvement, as long as there's a translation from guest physical to physical in a separate hardware table). It'd be reasonable to ignore TLB0 for migration (treat it as invalidated), but not for debug since that may be where the translation we're interested in resides. So with this new hardware, the always-sync API breaks. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Re: [Qemu-devel] [PATCH] socket: add the support for -netdev socket, listen
On Sat, Feb 18, 2012 at 8:54 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Fri, Feb 17, 2012 at 6:24 PM, Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: On Fri, Feb 17, 2012 at 12:20:08PM +0800, zwu.ker...@gmail.com wrote: From: Zhi Yong Wu wu...@linux.vnet.ibm.com As you have known, QEMU upstream currently doesn't support for -netdev socket,listen; This patch makes it work now. This commit description does not give any context. Please explain what the bug is so readers know what this patch fixes. I tried the following test: $ x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1024 \ -drive if=virtio,file=vm1.img,cache=none \ -netdev socket,listen=127.0.0.1:1234,id=socket0 \ -device virtio-net-pci,netdev=socket0 $ x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1024 \ -drive if=virtio,file=vm2.img,cache=none \ -netdev socket,connect=127.0.0.1:1234,id=socket0 \ -device virtio-net-pci,netdev=socket0 The first thing I noticed was that the output of info network in vm1 looks wrong. It should show the virtio-net-pci NIC peered with a socket fd connection. Instead it shows it peered with a dummy VLANClientState and I see two socket fds with no peers. By the way, Can you see socket file descriptioner? Where and How did you see them? s-nc.info_str is set to socket: For net_socket_fd_init_stream() you will have socket: fd=%d. The info_str is displayed by info network. Stefan
Re: [Qemu-devel] [RFC] Next gen kvm api
On 02/17/2012 02:19 AM, Alexander Graf wrote: Or we try to be less clever unless we have a really compelling reason. qemu monitor and gdb support aren't compelling reasons to optimize. The goal here was simplicity with a grain of performance concerns. Shared memory is simple in one way, but in other ways it is more complicated since it takes away the kernel's freedom in how it manages the data, how it's laid out, and whether it can lazify things or not. So what would you be envisioning? Should we make all of the MMU walker code in target-ppc KVM aware so it fetches that single way it actually cares about on demand from the kernel? That is pretty intrusive and goes against the general nicely fitting in principle of how KVM integrates today. First, it's trivial, when you access a set you call cpu_synchronize_tlb(set), just like how you access the registers when you want them. Second, and more important, how a random version of qemu works is totally immaterial to the kvm userspace interface. qemu could change in 15 different ways and so could the kernel, and other users exist. Fitting into qemu's current model is not a goal (if qemu happens to have a good model, use it by all means; and clashing with qemu is likely an indication the something is wrong -- but the two projects need to be decoupled). Also, we need to store the guest TLB somewhere. With this model, we can just store it in user space memory, so we keep only a single copy around, reducing memory footprint. If we had to copy it, we would need more than a single copy. That's the whole point. You could store it on the cpu hardware, if the cpu allows it. Forcing it into always-synchronized shared memory takes that ability away from you. At least on x86, we synchronize only rarely. Yeah, on s390 we only know which registers actually contain the information we need for traps / hypercalls when in user space, since that's where the decoding happens. So we better have all GPRs available to read from and write to. Ok. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Re: [Qemu-devel] [RFC] Next gen kvm api
On 02/17/2012 02:09 AM, Michael Ellerman wrote: On Thu, 2012-02-16 at 21:28 +0200, Avi Kivity wrote: On 02/16/2012 03:04 AM, Michael Ellerman wrote: ioctl is good for hardware devices and stuff that you want to enumerate and/or control permissions on. For something like KVM that is really a core kernel service, a syscall makes much more sense. Yeah maybe. That distinction is at least in part just historical. The first problem I see with using a syscall is that you don't need one syscall for KVM, you need ~90. OK so you wouldn't do that, you'd use a multiplexed syscall like epoll_ctl() - or probably several (vm/vcpu/etc). No. Many of our ioctls are for state save/restore - we reduce that to two. Many others are due to the with/without irqchip support - we slash that as well. The device assignment stuff is relegated to vfio. I still have to draw up a concrete proposal, but I think we'll end up with 10-15. That's true, you certainly could reduce it, though by how much I'm not sure. On powerpc I'm working on moving the irq controller emulation into the kernel, and some associated firmware emulation, so that's at least one new ioctl. And there will always be more, whatever scheme you have must be easily extensible - ie. not requiring new syscalls for each new weird platform. Most of it falls into read/write state, which is covered by two syscalls. There's probably need for configuration (wiring etc.); we could call that pseudo-state with fake registers but I don't like that very much. Secondly you still need a handle/context for those syscalls, and I think the most sane thing to use for that is an fd. The context is the process (for vm-wide calls) and thread (for vcpu local calls). Yeah OK I forgot you'd mentioned that. But isn't that change basically orthogonal to how you get into the kernel? ie. we could have the kvm/vcpu pointers in mm_struct/task_struct today? I guess it wouldn't win you much though because you still have the fd and ioctl overhead as well. Yes. I also dislike bypassing ioctl semantics (though we already do that by requiring vcpus to stay on the same thread and vms on the same process). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Re: [Qemu-devel] [PATCH] socket: add the support for -netdev socket, listen
On Sat, Feb 18, 2012 at 5:35 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Fri, Feb 17, 2012 at 6:24 PM, Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: On Fri, Feb 17, 2012 at 12:20:08PM +0800, zwu.ker...@gmail.com wrote: From: Zhi Yong Wu wu...@linux.vnet.ibm.com As you have known, QEMU upstream currently doesn't support for -netdev socket,listen; This patch makes it work now. This commit description does not give any context. Please explain what the bug is so readers know what this patch fixes. I tried the following test: $ x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1024 \ -drive if=virtio,file=vm1.img,cache=none \ -netdev socket,listen=127.0.0.1:1234,id=socket0 \ -device virtio-net-pci,netdev=socket0 $ x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1024 \ -drive if=virtio,file=vm2.img,cache=none \ -netdev socket,connect=127.0.0.1:1234,id=socket0 \ -device virtio-net-pci,netdev=socket0 The first thing I noticed was that the output of info network in vm1 looks wrong. It should show the virtio-net-pci NIC peered with a socket fd connection. Instead it shows it peered with a dummy VLANClientState Sorry, i will correct it. and I see two socket fds with no peers. It seems that other network backends don't set their peers, such as slirp, tap, etc. Right. Normally the backend doesn't because setting the peer is only done once and it is bi-directional. Setting the peer on A will do: A-peer = B; B-peer = A; However, the reason that backends don't set it is because the NIC will find the -netdev and peer with it. This doesn't apply to your patch - you decided to create a dummy VLANClientState and then switch to a different VLANClientState. So what happens is that the NIC probably peers with the dummy VLANClientState. Then later on the socket connection is accepted so you now would need to re-peer. This is the reason why I think the dummy VLANClientState approach is difficult and it's cleaner to create the real VLANClientState right away. qemu_del_vlan_client() brings the link down...we never bring it back up. Since s-nc-peer is NULL, this function will not bring the link down. The default state of the link is up. The peer is non-NULL when -netdev/-device is used because the NIC peers with the netdev. We need to avoid leaking s-nc because it is not freed in qemu_del_vlan_client-qemu_free_vlan_client-g_free(s-nc), i think that it is freed, right? No. When -netdev/-device is used we will have a peer and it will be NET_CLIENT_TYPE_NIC. We go down a code path which sets nic-peer_deleted = true, brings the link down, and cleans up the dummy VLANClientState without freeing it. I suggest using the real NetSocketState instead - do not create a dummy VLANClientState. This means we create the socket fd NetSocketState Sorry, i get confused about fd. Is this fd returned by socket() or accept()? I meant net/socket.c when I said socket fd but the sentence makes sense if we drop that completely: We create the NetSocketState right away and never need to update the peer. If we directly create one real NetSocketState, the code change will be a bit large, right? net_socket_info only implements .receive and .cleanup, and net/socket.c is not a large file. It should be doable in a clean and reasonable way. Stefan
Re: [Qemu-devel] [PATCH] astyle: Formatting rules for QEMU
On Sat, Feb 18, 2012 at 09:07, Stefan Weil s...@weilnetz.de wrote:
These AStyle rules try to implement the QEMU coding style.
AStyle can also fix only certain aspects of the coding style,
for example indentation.
Signed-off-by: Stefan Weil s...@weilnetz.de
---
Hi Blue,
maybe this AStyle rules work better. I tried them with target-sparc,
and the result does look quite good.
There are still indentation problems when expressions continue to next
line, also this does not look OK:
--- a/target-sparc/translate.c
+++ b/target-sparc/translate.c
@@ -36,7 +36,7 @@
#define DYNAMIC_PC 1 /* dynamic pc value */
#define JUMP_PC 2 /* dynamic pc value which takes only two values
- according to jump_pc[T2] */
+according to jump_pc[T2] */
Moving the brace to same line as switch case should not be necessary.
Overall astyle seems to be a better tool than GNU indent.
I also tried to use Emacs to perform the indenting with the attached
scripts, but the result is not that great either, especially some
macros and helper.h confuse indentation.
Regards,
Stefan
scripts/astylerc | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
create mode 100644 scripts/astylerc
diff --git a/scripts/astylerc b/scripts/astylerc
new file mode 100644
index 000..dfbfd41
--- /dev/null
+++ b/scripts/astylerc
@@ -0,0 +1,19 @@
+# Artistic Style (astyle) options for qemu source code.
+
+# Usage:
+# astyle --options=scripts/astylerc {source files}
+
+# For best results, use latest astyle from http://astyle.sourceforge.net/.
+
+add-brackets
+align-pointer=name
+convert-tabs
+max-code-length=80
This is only supported by the SVN HEAD, not even the download tarball offered.
+style=otbs
+brackets=linux
+indent=spaces=4
+max-code-length=80
+max-instatement-indent=60
+pad-oper
+pad-header
+unpad-paren
--
1.7.9
emacs_format_file
Description: Binary data
emacs_format_file.el
Description: Binary data
Re: [Qemu-devel] [PATCH][v11] megasas: LSI Megaraid SAS HBA emulation
On 02/17/2012 07:11 PM, Gerhard Wiesinger wrote: gcc --version gcc (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1) Please submit a new patch which removes unused variables, etc. As already mentioned, this patch is against qemu.git, not qemu-kvm.git. The latter doesn't (yet) have the infrastructure changes, so obviously it won't compile there. For the unused variables I'll be updating the patch. @Avi: Can you pull from qemu to test also qemu-kvm? I pulled on Thursday, are you testing the latest? I something's missing, you can always do a local merge btw. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Re: [Qemu-devel] [PATCH v4 00/10] uq/master: TPR access optimization for Windows guests
On 02/17/2012 07:31 PM, Jan Kiszka wrote: And here is v4: - Changed TPR IP reporting in KVM user space irqchip mode to always report the instruction after the triggering one - Fixed bug that froze TCG with VAPIC enabled during setup (by making run_on_vcpus fully TCG compatible) - Rebased over uq/master - Removed forgotten debug printf The series is also available at git://git.kiszka.org/qemu-kvm.git queues/kvm-tpr Please review/apply. Applied to uq/master, thanks. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Re: [Qemu-devel] [RFC] Next gen kvm api
On 18.02.2012, at 11:00, Avi Kivity a...@redhat.com wrote: On 02/17/2012 02:19 AM, Alexander Graf wrote: Or we try to be less clever unless we have a really compelling reason. qemu monitor and gdb support aren't compelling reasons to optimize. The goal here was simplicity with a grain of performance concerns. Shared memory is simple in one way, but in other ways it is more complicated since it takes away the kernel's freedom in how it manages the data, how it's laid out, and whether it can lazify things or not. Yes and no. Shared memory is a means of transferring data. If it's implemented by copying internally or by implicit sychronization is orthogonal to that. With the interface as is, we can now on newer CPUs (which need changes to user space to work anyways) take the current interface and add a new CAP + ioctl that allows us to force flush the TLYb into the shared buffer. That way we maintain backwards compatibility, memory savings, no in kernel vmalloc cluttering etc. on all CPUs, but get the checkpoint to actually have useful contents for new CPUs. I don't see the problem really. The data is the architected layout of the TLB. It contains all the data that can possibly make up a TLB entry according to the booke spec. If we wanted to copy different data, we'd need a different ioctl too. So what would you be envisioning? Should we make all of the MMU walker code in target-ppc KVM aware so it fetches that single way it actually cares about on demand from the kernel? That is pretty intrusive and goes against the general nicely fitting in principle of how KVM integrates today. First, it's trivial, when you access a set you call cpu_synchronize_tlb(set), just like how you access the registers when you want them. Yes, which is reasonably intrusive and going to be necessary with LRAT. Second, and more important, how a random version of qemu works is totally immaterial to the kvm userspace interface. qemu could change in 15 different ways and so could the kernel, and other users exist. Fitting into qemu's current model is not a goal (if qemu happens to have a good model, use it by all means; and clashing with qemu is likely an indication the something is wrong -- but the two projects need to be decoupled). Sure. In fact, in this case, the two were developed together. QEMU didn't have support for this specific TLB type, so we combined the development efforts. This way any new user space has a very easy time to implement it too, because we didn't model the KVM parts after QEMU, but the QEMU parts after KVM. I still think it holds true that the KVM interface is very easy to plug in to any random emulation project. And to achieve that, the interface should be as little intrusive as possible wrt its requirements. The one we have seemed to fit that pretty well. Sure, we need a special flush command for newer CPUs, but at least we don't have to always copy. We only copy when we need to. Also, we need to store the guest TLB somewhere. With this model, we can just store it in user space memory, so we keep only a single copy around, reducing memory footprint. If we had to copy it, we would need more than a single copy. That's the whole point. You could store it on the cpu hardware, if the cpu allows it. Forcing it into always-synchronized shared memory takes that ability away from you. Yup. So the correct comment to make would be don't make the shared TLB always synchronized, which I agree with today. I still think that the whole idea of passing kvm user space memory to work on is great. It reduces vmalloc footprint, it reduces copying, and it keeps data at one place, reducing chances to mess up. Having it defined to always be in sync was a mistake, but one we can easily fix. That's why the CAP and ioctl interfaces are so awesome ;). I strongly believe that I can't predict the future. So designing an interface that holds stable for the next 10 years is close to imposdible. with an easily extensible interface however, it becomes almost trivial tk fix earlier messups ;). Alex
Re: [Qemu-devel] [PATCH] socket: add the support for -netdev socket, listen
On Sat, Feb 18, 2012 at 5:52 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Sat, Feb 18, 2012 at 8:54 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Fri, Feb 17, 2012 at 6:24 PM, Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: On Fri, Feb 17, 2012 at 12:20:08PM +0800, zwu.ker...@gmail.com wrote: From: Zhi Yong Wu wu...@linux.vnet.ibm.com As you have known, QEMU upstream currently doesn't support for -netdev socket,listen; This patch makes it work now. This commit description does not give any context. Please explain what the bug is so readers know what this patch fixes. I tried the following test: $ x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1024 \ -drive if=virtio,file=vm1.img,cache=none \ -netdev socket,listen=127.0.0.1:1234,id=socket0 \ -device virtio-net-pci,netdev=socket0 $ x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1024 \ -drive if=virtio,file=vm2.img,cache=none \ -netdev socket,connect=127.0.0.1:1234,id=socket0 \ -device virtio-net-pci,netdev=socket0 The first thing I noticed was that the output of info network in vm1 looks wrong. It should show the virtio-net-pci NIC peered with a socket fd connection. Instead it shows it peered with a dummy VLANClientState and I see two socket fds with no peers. By the way, Can you see socket file descriptioner? Where and How did you see them? s-nc.info_str is set to socket: For net_socket_fd_init_stream() you will have socket: fd=%d. The This fd is displayed only for udp type. But in your test command, i don't see that you specifiy if it is udp or tcp type. info_str is displayed by info network. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [QEMU] net: adapt dump to support the new syntax
On Sat, Feb 18, 2012 at 5:48 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Sat, Feb 18, 2012 at 8:57 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Fri, Feb 17, 2012 at 6:55 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Fri, Feb 17, 2012 at 6:54 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: I would like to know if some one is playing around with the patchset. If yes, can any one make one response? I am very interested in rebasing it, and then playing with it. AFAIK no one is working on it - the main thing that is missing here is tests so that we don't break the existing VLAN feature and command-line interface. If you are available, can you let us know what their difference among -net, -netdev and hub? their drawback? their advantage? thanks -net is the old command-line option for defining both guest network devices (e.g. e1000, virtio-net) and also host network devices (e.g. tap, socket, user). It uses the VLAN concept and does not use peer IIRC. -netdev/-device is the new way to specify networking. You use -netdev to define host network devices (e.g. tap, socket, user). You use -device to specify guest network devices (e.g. e1000, virtio-net-pci). This approach does not use the VLAN feature and instead uses -peer. That means nic-per == netdev and netdev-peer == nic. There is a performance improvement with -netdev/-device because we do not use VLAN forwarding in the network subsystem and I think it enables tap offloads (checksum offload, GRO, TSO) but I don't remember the detalis there. The hub is the same as QEMU VLANs except it removes all the special case code in the network subsystem and instead implements the functionality in a normal NetClientState. Now the hub is no longer part of the network subsystem, its just a net device in QEMU. The critical thing when transitioning to the hub device is that the old VLAN command-line options must continue to work! Users should see no difference from before. But internally the net subsystem will only deal with NetClientState instead of VLANClientState plus VLANState. Everything will use -peer. Nice, thanks. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH] socket: add the support for -netdev socket, listen
On Sat, Feb 18, 2012 at 6:06 PM, Stefan Hajnoczi stefa...@gmail.com wrote: On Sat, Feb 18, 2012 at 5:35 AM, Zhi Yong Wu zwu.ker...@gmail.com wrote: On Fri, Feb 17, 2012 at 6:24 PM, Stefan Hajnoczi stefa...@linux.vnet.ibm.com wrote: On Fri, Feb 17, 2012 at 12:20:08PM +0800, zwu.ker...@gmail.com wrote: From: Zhi Yong Wu wu...@linux.vnet.ibm.com As you have known, QEMU upstream currently doesn't support for -netdev socket,listen; This patch makes it work now. This commit description does not give any context. Please explain what the bug is so readers know what this patch fixes. I tried the following test: $ x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1024 \ -drive if=virtio,file=vm1.img,cache=none \ -netdev socket,listen=127.0.0.1:1234,id=socket0 \ -device virtio-net-pci,netdev=socket0 $ x86_64-softmmu/qemu-system-x86_64 -enable-kvm -m 1024 \ -drive if=virtio,file=vm2.img,cache=none \ -netdev socket,connect=127.0.0.1:1234,id=socket0 \ -device virtio-net-pci,netdev=socket0 The first thing I noticed was that the output of info network in vm1 looks wrong. It should show the virtio-net-pci NIC peered with a socket fd connection. Instead it shows it peered with a dummy VLANClientState Sorry, i will correct it. and I see two socket fds with no peers. It seems that other network backends don't set their peers, such as slirp, tap, etc. Right. Normally the backend doesn't because setting the peer is only done once and it is bi-directional. Setting the peer on A will do: A-peer = B; B-peer = A; However, the reason that backends don't set it is because the NIC will find the -netdev and peer with it. This doesn't apply to your patch - you decided to create a dummy VLANClientState and then switch to a different VLANClientState. So what happens is that the NIC probably peers with the dummy VLANClientState. Then later on the socket connection is accepted so you now would need to re-peer. This is the reason why I think the dummy VLANClientState approach is difficult and it's cleaner to create the real VLANClientState right away. qemu_del_vlan_client() brings the link down...we never bring it back up. Since s-nc-peer is NULL, this function will not bring the link down. The default state of the link is up. The peer is non-NULL when -netdev/-device is used because the NIC peers with the netdev. We need to avoid leaking s-nc because it is not freed in qemu_del_vlan_client-qemu_free_vlan_client-g_free(s-nc), i think that it is freed, right? No. When -netdev/-device is used we will have a peer and it will be NET_CLIENT_TYPE_NIC. We go down a code path which sets nic-peer_deleted = true, brings the link down, and cleans up the dummy VLANClientState without freeing it. I suggest using the real NetSocketState instead - do not create a dummy VLANClientState. This means we create the socket fd NetSocketState Sorry, i get confused about fd. Is this fd returned by socket() or accept()? I meant net/socket.c when I said socket fd but the sentence makes sense if we drop that completely: We create the NetSocketState right away and never need to update the peer. If we directly create one real NetSocketState, the code change will be a bit large, right? net_socket_info only implements .receive and .cleanup, and net/socket.c is not a large file. It should be doable in a clean and reasonable way. nic, thanks. Stefan -- Regards, Zhi Yong Wu
Re: [Qemu-devel] [PATCH] checkpatch: Don't WARN about missing spaces in audio files
Am 18.02.2012 10:13, schrieb Blue Swirl: On Fri, Feb 17, 2012 at 15:26, Anthony Liguori aligu...@us.ibm.com wrote: Well this was what I was getting at in my previous comments. If we just need to reindent 10 files with a few random changes here and there, then maybe that isn't so bad. But if we have to touch every single file in the tree in a significant way, then no way is it justified. One way to handle this is gradual reformatting, every time when code is touched, only changes towards common CODING_STYLE are allowed. Small, contained reformatting patches should be also allowed, for example to adjust brace style in one file a time or to remove spaces at the end of line. I'd appreciate it very much if we could remove spaces at line endings for all non binary files as soon as possible. Newer versions of git (maybe also older ones with appropriate configuration, see 'git config --help', core.whitespace / blank-at-eol/ apply.whitespace) complain about patches which add such spaces. Nevertheless even recent patches did add spaces, so obviously not all committers use that git settings. It's good practice to use an editor which automatically removes spaces at end of line (I think most editors can be configured to do this). With the current code, this is difficult because it introduces additional whitespace changes when I edit a file with spaces which are removed by the editor. I don't even want to consider something that touches every line of code. That's effectively creating a new source tree and losing the continuity of our SCM history. I think only 'git blame' output would be affected and that is not 100% reliable anyway, considering for example code movement. 'git blame' can optionally ignore whitespace changes, so that is not really a problem. It can even ignore code movements :-) Just use 'git blame -w -C'. Regards, Stefan
Re: [Qemu-devel] [PATCH] astyle: Formatting rules for QEMU
Am 18.02.2012 11:10, schrieb Blue Swirl: There are still indentation problems when expressions continue to next line, also this does not look OK: --- a/target-sparc/translate.c +++ b/target-sparc/translate.c @@ -36,7 +36,7 @@ #define DYNAMIC_PC 1 /* dynamic pc value */ #define JUMP_PC 2 /* dynamic pc value which takes only two values - according to jump_pc[T2] */ +according to jump_pc[T2] */ Writing comments like this looks nice, but needs more work when the comments are written. Maintenance of the code is also more difficult: any time a new line with a longer name is added, you have to reformat all other lines to preserve the good look. Just add this line to the code given above to see what I mean: #define ANY_LONG_PC 3 /* just an example */ This is why I usually write comments in an extra line before the code statement. Regards, Stefan
Re: [Qemu-devel] [PATCH][v11] megasas: LSI Megaraid SAS HBA emulation
On Sat, 18 Feb 2012, Avi Kivity wrote: On 02/17/2012 07:11 PM, Gerhard Wiesinger wrote: gcc --version gcc (GCC) 4.6.2 20111027 (Red Hat 4.6.2-1) Please submit a new patch which removes unused variables, etc. As already mentioned, this patch is against qemu.git, not qemu-kvm.git. The latter doesn't (yet) have the infrastructure changes, so obviously it won't compile there. For the unused variables I'll be updating the patch. @Avi: Can you pull from qemu to test also qemu-kvm? I pulled on Thursday, are you testing the latest? I something's missing, you can always do a local merge btw. Yes, latest. With patch below, it works also on qemu-kvm. So something is still missing ... Local merge: But then history isn't the same ... What command do you use? Ciao, Gerhard -- http://www.wiesinger.com/ --- hw/megasas.c2012-02-18 09:08:17.0 +0100 +++ ../qemu/hw/megasas.c2012-02-17 20:27:23.0 +0100 @@ -1862,4 +1862,4 @@ type_register_static(megasas_info); } -device_init(megaraid1078_register_types); +type_init(megaraid1078_register_types);
[Qemu-devel] [PULL 00/12] target-xtensa queue
Hi. This is a pull request for my current target-xtensa queue. Changes in the queue are: - 'info tlb' monitor command; - debug option implementation; - a few minor fixes. Debug option series has been posted to the list as an RFC, there were no changes in it since then. Please pull. Thanks. -- Max The following changes since commit 99c7f87826337fa81f2f0f9baa9ca0a44faf90e9: input: send kbd+mouse events only to running guests. (2012-02-17 11:02:55 -0600) are available in the git repository at: git://jcmvbkbc.spb.ru/dumb/qemu-xtensa.git xtensa Max Filippov (12): target-xtensa: define TLB_TEMPLATE for MMU-less cores target-xtensa: implement info tlb monitor command target-xtensa: fetch 3rd opcode byte only when needed target-xtensa: add DEBUGCAUSE SR and configuration target-xtensa: implement instruction breakpoints target-xtensa: add ICOUNT SR and debug exception exec: add missing breaks to the watch_mem_write exec: fix check_watchpoint exiting cpu_loop exec: let cpu_watchpoint_insert accept larger watchpoints target-xtensa: add DBREAK data breakpoints target-xtensa: add DEBUG_SECTION to overlay tool target-xtensa: add breakpoint tests exec.c| 18 +++- hmp-commands.hx |2 +- monitor.c |4 +- target-xtensa/core-dc232b.c |1 + target-xtensa/core-fsf.c |1 + target-xtensa/cpu.h | 43 target-xtensa/helper.c| 110 target-xtensa/helpers.h |7 ++ target-xtensa/op_helper.c | 100 ++ target-xtensa/overlay_tool.h | 23 - target-xtensa/translate.c | 156 - tests/tcg/xtensa/Makefile |1 + tests/tcg/xtensa/test_break.S | 223 + 13 files changed, 674 insertions(+), 15 deletions(-) create mode 100644 tests/tcg/xtensa/test_break.S -- 1.7.7.6
Re: [Qemu-devel] [PATCH][v11] megasas: LSI Megaraid SAS HBA emulation
On 02/18/2012 01:15 PM, Gerhard Wiesinger wrote: I pulled on Thursday, are you testing the latest? I something's missing, you can always do a local merge btw. Yes, latest. With patch below, it works also on qemu-kvm. So something is still missing ... You'll need that patch for qemu.git too. Local merge: But then history isn't the same ... For testing, why do you care? What command do you use? git pull -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.
Re: [Qemu-devel] [PATCH] checkpatch: Don't WARN about missing spaces in audio files
On 02/18/2012 04:56 AM, Stefan Weil wrote: Am 18.02.2012 10:13, schrieb Blue Swirl: On Fri, Feb 17, 2012 at 15:26, Anthony Liguori aligu...@us.ibm.com wrote: Well this was what I was getting at in my previous comments. If we just need to reindent 10 files with a few random changes here and there, then maybe that isn't so bad. But if we have to touch every single file in the tree in a significant way, then no way is it justified. One way to handle this is gradual reformatting, every time when code is touched, only changes towards common CODING_STYLE are allowed. Small, contained reformatting patches should be also allowed, for example to adjust brace style in one file a time or to remove spaces at the end of line. I'd appreciate it very much if we could remove spaces at line endings for all non binary files as soon as possible. Why? I really can't understand this. It's not visible so it does no harm. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] checkpatch: Don't WARN about missing spaces in audio files
On Sat, Feb 18, 2012 at 14:18, Anthony Liguori anth...@codemonkey.ws wrote: On 02/18/2012 04:56 AM, Stefan Weil wrote: Am 18.02.2012 10:13, schrieb Blue Swirl: On Fri, Feb 17, 2012 at 15:26, Anthony Liguori aligu...@us.ibm.com wrote: Well this was what I was getting at in my previous comments. If we just need to reindent 10 files with a few random changes here and there, then maybe that isn't so bad. But if we have to touch every single file in the tree in a significant way, then no way is it justified. One way to handle this is gradual reformatting, every time when code is touched, only changes towards common CODING_STYLE are allowed. Small, contained reformatting patches should be also allowed, for example to adjust brace style in one file a time or to remove spaces at the end of line. I'd appreciate it very much if we could remove spaces at line endings for all non binary files as soon as possible. Why? I really can't understand this. It's not visible so it does no harm. It's not the end of the world, but they could be mangled (which will make patches fail to apply) when mailed and they waste precious bytes. They are also not useful in any way, so better remove them. Regards, Anthony Liguori
Re: [Qemu-devel] [PATCH] Running vgabios during resume from S3 on QEMU by default
On Mon, Feb 13, 2012 at 01:01:07PM +0200, Gleb Natapov wrote: Run vgabios during resume from S3 by default on QEMU. QEMU still able to modify SeaBIOS behavior if it wishes so by providing etc/s3-resume-vga-init file. With QEMU emulated vga cards this behaviour is desirable otherwise console becomes unusable with Linux guests after resume. Since we control vgabios source we can be sure that running it on resume from S3 is safe. Thanks - I committed this change. -Kevin
Re: [Qemu-devel] [PATCH] checkpatch: Don't WARN about missing spaces in audio files
Am 18.02.2012 10:13, schrieb Blue Swirl: One way to handle this is gradual reformatting, every time when code is touched, only changes towards common CODING_STYLE are allowed. That's what we've been doing wrt braces and I appreciate us not cluttering the history with reformatting commits. Especially at a time where I'm touching every target (and seeing quite some variations on coding style) I'm not so happy about this initiative. On Fri, Feb 17, 2012 at 15:26, Anthony Liguori aligu...@us.ibm.com wrote: I don't even want to consider something that touches every line of code. That's effectively creating a new source tree and losing the continuity of our SCM history. I think only 'git blame' output would be affected and that is not 100% reliable anyway, considering for example code movement. I use repo.or.cz's blame function quite often to find out who to cc or what commit to mention, and (valid) typo fixes are already troublesome, requiring to go to the parent commit and to navigate to the same file in its tree. One cannot specify any custom ignore options there. Is there a better tool to do such interactive, recursive git-blame? Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [Bug 824650] Re: Latest GIT assert error in arp_table.c
I'm getting the following error:
qemu-system-arm: slirp/arp_table.c:41: arp_table_add: Assertion `(ip_addr
(__extension__ ({ register unsigned int __v, __x = (~(0xf 28)); if
(__builtin_constant_p (__x)) __v = __x) 0xff00) 24) | (((__x)
0x00ff) 8) | (((__x) 0xff00) 8) | (((__x) 0x00ff)
24)); else __asm__ (bswap %0 : =r (__v) : 0 (__x)); __v; }))) != 0'
failed.
Aborted
Here is the command i'm running:
qemu-system-arm -M versatilepb -cpu arm11mpcore -m 256 -hda
debian6-17-02-2012.img -kernel zImage_3.1.9 -append root=/dev/sda2
The version of qemu was compiled from source today from the latest git
so the above patch was already in place.
Running Ubuntu 11.10
Intel Celeron CPU 550 @ 2.00GHz
2Gb ram
If you need any more info let me know...
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/824650
Title:
Latest GIT assert error in arp_table.c
Status in QEMU:
Fix Released
Bug description:
The latest git version of qemu (commit
8cc7c3952d4d0a681d8d4c3ac89a206a5bfd7f00) crashes after a few minutes.
All was fine up to a few days ago. This is wth both x86 and sparc
emulation, on an x86_64 host.
e.g. qemu-system-sparc -drive
file=netbsd5.0.2-sparc,index=0,media=disk,cache=unsafe -m 256 -boot c
-nographic -redir tcp:2232::22:
qemu-system-sparc: slirp/arp_table.c:75: arp_table_search: Assertion
`(ip_addr (__extension__ ({ register unsigned int __v, __x = (~(0xf
28)); if (__builtin_constant_p (__x)) __v = __x) 0xff00)
24) | (((__x) 0x00ff) 8) | (((__x) 0xff00) 8) |
(((__x) 0x00ff) 24)); else __asm__ (bswap %0 : =r (__v) :
0 (__x)); __v; }))) != 0' failed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/824650/+subscriptions
[Qemu-devel] Curious about this code in the ohci_service_td()
I am reading the code in ohci_service_td().
There is a calculation of the length of the buffer.
if ((td.cbp 0xf000) != (td.be 0xf000)) {
len = (td.be 0xfff) + 0x1001 - (td.cbp 0xfff);
} else {
len = (td.be - td.cbp) + 1;
}
I am curious about the first case.
So the td.be could be less than the tb.cbp?
Seems this is a buffer ring and the size is around 4k?
--
Richard Yang
Help You, Help Me
Re: [Qemu-devel] [PATCH] build: add needed missing libraries libm and librt
Am 18.02.2012 09:24, schrieb Blue Swirl: On Wed, Feb 8, 2012 at 17:06, Roger Pau Monne roger@entel.upc.edu wrote: libm is used in cutils.c, but the library was not specified when linking some binaries, throwing the following error: cutils.o: In function `strtosz_suffix_unit': /home/royger/xen-clean/tools/qemu-xen-dir/cutils.c:354: undefined reference to `__isnan' /home/royger/xen-clean/tools/qemu-xen-dir/cutils.c:357: undefined reference to `modf' collect2: ld returned 1 exit status According to modf man page [0], -lm should be used when linking. librt is used in qemu-time.c, but again the library was not specified at link time, throwing the following error: /home/royger/xen-clean/tools/qemu-xen-dir/qemu-timer.c:597: undefined reference to `timer_gettime' /home/royger/xen-clean/tools/qemu-xen-dir/qemu-timer.c:610: undefined reference to `timer_settime' ../qemu-timer.o: In function `dynticks_start_timer': /home/royger/xen-clean/tools/qemu-xen-dir/qemu-timer.c:565: undefined reference to `timer_create' ../qemu-timer.o: In function `dynticks_stop_timer': /home/royger/xen-clean/tools/qemu-xen-dir/qemu-timer.c:583: undefined reference to `timer_delete' collect2: ld returned 1 exit status According to timer_getttime man page [1], -lrt should be used when linking. [0] http://linux.die.net/man/3/modf [1] http://linux.die.net/man/2/timer_gettime This is Linux man page, is this correct for all OS we support? No, not for Haiku or Mac OS X. We already have a test for -lrt in configure, but it looks like it does not detect your case correctly. You should fix that instead. Signed-off-by: Roger Pau Monne roger@entel.upc.edu --- Makefile|4 ++-- Makefile.target |2 ++ 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 301c75e..e2c3cd4 100644 --- a/Makefile +++ b/Makefile @@ -34,7 +34,7 @@ configure: ; $(call set-vpath, $(SRC_PATH):$(SRC_PATH)/hw) -LIBS+=-lz $(LIBS_TOOLS) +LIBS+=-lz -lm -lrt $(LIBS_TOOLS) NACK. You need to make sure it either lands in $(LIBS_TOOLS) or is added via a new variable with host-dependent contents. ifdef BUILD_DOCS DOCS=qemu-doc.html qemu-tech.html qemu.1 qemu-img.1 qemu-nbd.8 QMP/qmp-commands.txt @@ -170,7 +170,7 @@ test-coroutine: test-coroutine.o qemu-timer-common.o async.o $(coroutine-obj-y) $(qapi-obj-y): $(GENERATED_HEADERS) qapi-dir := $(BUILD_DIR)/qapi-generated test-visitor.o test-qmp-commands.o qemu-ga$(EXESUF): QEMU_CFLAGS += -I $(qapi-dir) -qemu-ga$(EXESUF): LIBS = $(LIBS_QGA) +qemu-ga$(EXESUF): LIBS = $(LIBS_QGA) -lm NACK. Either needs to do LIBS += or must go in $(LIBS_QGA) or new conditionalized variable. $(qapi-dir)/test-qapi-types.c $(qapi-dir)/test-qapi-types.h :\ $(SRC_PATH)/qapi-schema-test.json $(SRC_PATH)/scripts/qapi-types.py diff --git a/Makefile.target b/Makefile.target index a111521..95d6bc0 100644 --- a/Makefile.target +++ b/Makefile.target @@ -33,6 +33,8 @@ endif PROGS=$(QEMU_PROG) STPFILES= +LIBS+=-lrt + ifndef CONFIG_HAIKU LIBS+=-lm endif Here's the special treatment that avoids adding -lm on Haiku host because it doesn't have a libm.so (git-blame would've told you it's in libroot.so there); on Darwin there's a compatibility symlink but it's in libSystem.dylib actually and an ifndef would be appropriate as well. POSIX does not mandate -lm for math functions. Would moving this snippet to Makefile.objs help? What system are you on anyway and are you actually using upstream qemu.git? openSUSE 12.1 does not complain, and without a test case it's hard to find a solution here. Andreas -- 1.7.9 -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] Curious about this code in the ohci_service_td()
On 18 February 2012 16:19, Wei Yang weiyang.ker...@gmail.com wrote:
I am reading the code in ohci_service_td().
There is a calculation of the length of the buffer.
if ((td.cbp 0xf000) != (td.be 0xf000)) {
len = (td.be 0xfff) + 0x1001 - (td.cbp 0xfff);
} else {
len = (td.be - td.cbp) + 1;
}
I am curious about the first case.
So the td.be could be less than the tb.cbp?
Yes. See the OHCI spec:
ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf
and specifically section 4.3: the data buffer described by a
TD may span two separate physically disjoint pages. The exact
page crossing behaviour is described more specifically in
section 4.3.1.3.1. (We don't implement it quite as described
there because we try to handle the whole data buffer at once
rather than byte-by-byte, but the effect is the same. See
also the code later on in the function under 'Transmission
succeeded' which updates td.cbp to the right value if we only
managed to send part of the data.)
-- PMM
Re: [Qemu-devel] [PATCH v2 1/1] exec: Fix watchpoint implementation
Am 17.02.2012 18:06, schrieb Andreas Färber:
Am 17.02.2012 18:03, schrieb Meador Inge:
Fix a bug introduced by commit 1ec9b909ff207a44d5ef2609cb4a2e3d449d485f
where 'watch_mem_write' was modified to fall-through to 'abort' on
every input.
Signed-off-by: Meador Inge mead...@codesourcery.com
Reviewed-by: Andreas Färber afaer...@suse.de
Actually I already reviewed such a fix by Max on Jan 29 (with breaks
from the start), and it's in his PULL request now. So this is again a
duplicate and shouldn't be applied.
If you want to remind maintainers of a patch that's been on the list but
has not yet been applied, the correct procedure is to add a Reviewed-by
or Acked-by tag if you haven't already, or to reply with a Ping?
otherwise.
Andreas
---
* Changes since v1:
- 'break' out of switch statement instead of 'return'.
exec.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/exec.c b/exec.c
index b81677a..f105b43 100644
--- a/exec.c
+++ b/exec.c
@@ -3289,9 +3289,15 @@ static void watch_mem_write(void *opaque,
target_phys_addr_t addr,
{
check_watchpoint(addr ~TARGET_PAGE_MASK, ~(size - 1), BP_MEM_WRITE);
switch (size) {
-case 1: stb_phys(addr, val);
-case 2: stw_phys(addr, val);
-case 4: stl_phys(addr, val);
+case 1:
+stb_phys(addr, val);
+break;
+case 2:
+stw_phys(addr, val);
+break;
+case 4:
+stl_phys(addr, val);
+break;
default: abort();
}
}
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
Re: [Qemu-devel] [PULL 00/12] target-xtensa queue
Am 18.02.2012 12:30, schrieb Max Filippov: Hi. This is a pull request for my current target-xtensa queue. Changes in the queue are: - 'info tlb' monitor command; - debug option implementation; - a few minor fixes. Debug option series has been posted to the list as an RFC, there were no changes in it since then. It would be nice to see those 12 patches threaded to the PULL message, especially when there's been no feedback yet (which may indicate either that people had no objections or didn't look at it yet). Andreas Please pull. Thanks. -- Max The following changes since commit 99c7f87826337fa81f2f0f9baa9ca0a44faf90e9: input: send kbd+mouse events only to running guests. (2012-02-17 11:02:55 -0600) are available in the git repository at: git://jcmvbkbc.spb.ru/dumb/qemu-xtensa.git xtensa Max Filippov (12): target-xtensa: define TLB_TEMPLATE for MMU-less cores target-xtensa: implement info tlb monitor command target-xtensa: fetch 3rd opcode byte only when needed target-xtensa: add DEBUGCAUSE SR and configuration target-xtensa: implement instruction breakpoints target-xtensa: add ICOUNT SR and debug exception exec: add missing breaks to the watch_mem_write exec: fix check_watchpoint exiting cpu_loop exec: let cpu_watchpoint_insert accept larger watchpoints target-xtensa: add DBREAK data breakpoints target-xtensa: add DEBUG_SECTION to overlay tool target-xtensa: add breakpoint tests exec.c| 18 +++- hmp-commands.hx |2 +- monitor.c |4 +- target-xtensa/core-dc232b.c |1 + target-xtensa/core-fsf.c |1 + target-xtensa/cpu.h | 43 target-xtensa/helper.c| 110 target-xtensa/helpers.h |7 ++ target-xtensa/op_helper.c | 100 ++ target-xtensa/overlay_tool.h | 23 - target-xtensa/translate.c | 156 - tests/tcg/xtensa/Makefile |1 + tests/tcg/xtensa/test_break.S | 223 + 13 files changed, 674 insertions(+), 15 deletions(-) create mode 100644 tests/tcg/xtensa/test_break.S -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [Bug 824650] Re: Latest GIT assert error in arp_table.c
hey solitaire,
just add the 5 lines mentioned in my post above to slirp/ip_icmp.c
source code file, recompile qemu and that's it.
this worked pretty fine for me so far.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/824650
Title:
Latest GIT assert error in arp_table.c
Status in QEMU:
Fix Released
Bug description:
The latest git version of qemu (commit
8cc7c3952d4d0a681d8d4c3ac89a206a5bfd7f00) crashes after a few minutes.
All was fine up to a few days ago. This is wth both x86 and sparc
emulation, on an x86_64 host.
e.g. qemu-system-sparc -drive
file=netbsd5.0.2-sparc,index=0,media=disk,cache=unsafe -m 256 -boot c
-nographic -redir tcp:2232::22:
qemu-system-sparc: slirp/arp_table.c:75: arp_table_search: Assertion
`(ip_addr (__extension__ ({ register unsigned int __v, __x = (~(0xf
28)); if (__builtin_constant_p (__x)) __v = __x) 0xff00)
24) | (((__x) 0x00ff) 8) | (((__x) 0xff00) 8) |
(((__x) 0x00ff) 24)); else __asm__ (bswap %0 : =r (__v) :
0 (__x)); __v; }))) != 0' failed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/824650/+subscriptions
Re: [Qemu-devel] [PATCH] checkpatch: Don't WARN about missing spaces in audio files
On 02/18/2012 08:53 AM, Andreas Färber wrote: I think only 'git blame' output would be affected and that is not 100% reliable anyway, considering for example code movement. I use repo.or.cz's blame function quite often to find out who to cc or what commit to mention, and (valid) typo fixes are already troublesome, requiring to go to the parent commit and to navigate to the same file in its tree. One cannot specify any custom ignore options there. Is there a better tool to do such interactive, recursive git-blame? I use 'git gui blame $commit $file ' for interactive recursive blaming. When you find the line that you are interested in blaming, you can click on the commit link on the left side to see the context at the time of the commit that introduced the state of that line, then right click on the right side (the line in question) to easily trigger a 'blame parent' operation. It's about the only thing that I use 'git gui' for, but I find it well worth the pain of using a tcl frontend. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
[Qemu-devel] [PATCH 11/12] target-xtensa: add DEBUG_SECTION to overlay tool
Fill debug configuration from overlay definitions in the DEBUG_SECTION.
Add DEBUG_SECTION to DC232B and FSF cores.
Signed-off-by: Max Filippov jcmvb...@gmail.com
---
target-xtensa/core-dc232b.c |1 +
target-xtensa/core-fsf.c |1 +
target-xtensa/overlay_tool.h |5 +
3 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/target-xtensa/core-dc232b.c b/target-xtensa/core-dc232b.c
index 4d9bd55..b723c4c 100644
--- a/target-xtensa/core-dc232b.c
+++ b/target-xtensa/core-dc232b.c
@@ -22,6 +22,7 @@ static const XtensaConfig dc232b = {
EXCEPTIONS_SECTION,
INTERRUPTS_SECTION,
TLB_SECTION,
+DEBUG_SECTION,
.clock_freq_khz = 1,
};
diff --git a/target-xtensa/core-fsf.c b/target-xtensa/core-fsf.c
index 7650462..88de4dd 100644
--- a/target-xtensa/core-fsf.c
+++ b/target-xtensa/core-fsf.c
@@ -16,6 +16,7 @@ static const XtensaConfig fsf = {
EXCEPTIONS_SECTION,
INTERRUPTS_SECTION,
TLB_SECTION,
+DEBUG_SECTION,
.clock_freq_khz = 1,
};
diff --git a/target-xtensa/overlay_tool.h b/target-xtensa/overlay_tool.h
index e7c4c3a..a3a5650 100644
--- a/target-xtensa/overlay_tool.h
+++ b/target-xtensa/overlay_tool.h
@@ -114,6 +114,7 @@
[EXC_KERNEL] = XCHAL_KERNEL_VECTOR_VADDR, \
[EXC_USER] = XCHAL_USER_VECTOR_VADDR, \
[EXC_DOUBLE] = XCHAL_DOUBLEEXC_VECTOR_VADDR, \
+[EXC_DEBUG] = XCHAL_DEBUG_VECTOR_VADDR, \
}
#define INTERRUPT_VECTORS { \
@@ -302,6 +303,10 @@
#define REGISTER_CORE(core)
#endif
+#define DEBUG_SECTION \
+.debug_level = XCHAL_DEBUGLEVEL, \
+.nibreak = XCHAL_NUM_IBREAK, \
+.ndbreak = XCHAL_NUM_DBREAK
#if XCHAL_NUM_INTLEVELS + XCHAL_HAVE_NMI + 1 = 2
#define XCHAL_INTLEVEL2_VECTOR_VADDR 0
--
1.7.7.6
[Qemu-devel] [PATCH 04/12] target-xtensa: add DEBUGCAUSE SR and configuration
DEBUGCAUSE SR holds information about the most recent debug exception.
See ISA, 4.7.7 for more details.
Signed-off-by: Max Filippov jcmvb...@gmail.com
---
target-xtensa/cpu.h | 15 +++
target-xtensa/translate.c |6 ++
2 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/target-xtensa/cpu.h b/target-xtensa/cpu.h
index c32bf35..c77fe13 100644
--- a/target-xtensa/cpu.h
+++ b/target-xtensa/cpu.h
@@ -137,6 +137,7 @@ enum {
PS = 230,
VECBASE = 231,
EXCCAUSE = 232,
+DEBUGCAUSE = 233,
CCOUNT = 234,
PRID = 235,
EXCVADDR = 238,
@@ -161,6 +162,15 @@ enum {
#define PS_WOE 0x4
+#define DEBUGCAUSE_IC 0x1
+#define DEBUGCAUSE_IB 0x2
+#define DEBUGCAUSE_DB 0x4
+#define DEBUGCAUSE_BI 0x8
+#define DEBUGCAUSE_BN 0x10
+#define DEBUGCAUSE_DI 0x20
+#define DEBUGCAUSE_DBNUM 0xf00
+#define DEBUGCAUSE_DBNUM_SHIFT 8
+
#define MAX_NAREG 64
#define MAX_NINTERRUPT 32
#define MAX_NLEVEL 6
@@ -279,6 +289,11 @@ typedef struct XtensaConfig {
uint32_t timerint[MAX_NCCOMPARE];
unsigned nextint;
unsigned extint[MAX_NINTERRUPT];
+
+unsigned debug_level;
+unsigned nibreak;
+unsigned ndbreak;
+
uint32_t clock_freq_khz;
xtensa_tlb itlb;
diff --git a/target-xtensa/translate.c b/target-xtensa/translate.c
index 6a0177f..da5fdb5 100644
--- a/target-xtensa/translate.c
+++ b/target-xtensa/translate.c
@@ -119,6 +119,7 @@ static const char * const sregnames[256] = {
[PS] = PS,
[VECBASE] = VECBASE,
[EXCCAUSE] = EXCCAUSE,
+[DEBUGCAUSE] = DEBUGCAUSE,
[CCOUNT] = CCOUNT,
[PRID] = PRID,
[EXCVADDR] = EXCVADDR,
@@ -535,6 +536,10 @@ static void gen_wsr_ps(DisasContext *dc, uint32_t sr,
TCGv_i32 v)
gen_jumpi_check_loop_end(dc, -1);
}
+static void gen_wsr_debugcause(DisasContext *dc, uint32_t sr, TCGv_i32 v)
+{
+}
+
static void gen_wsr_prid(DisasContext *dc, uint32_t sr, TCGv_i32 v)
{
}
@@ -571,6 +576,7 @@ static void gen_wsr(DisasContext *dc, uint32_t sr, TCGv_i32
s)
[INTCLEAR] = gen_wsr_intclear,
[INTENABLE] = gen_wsr_intenable,
[PS] = gen_wsr_ps,
+[DEBUGCAUSE] = gen_wsr_debugcause,
[PRID] = gen_wsr_prid,
[CCOMPARE] = gen_wsr_ccompare,
[CCOMPARE + 1] = gen_wsr_ccompare,
--
1.7.7.6
Re: [Qemu-devel] VirtIO 9p mount_tag (bogus?) limit of 32 bytes
On Thu, 16 Feb 2012 06:20:21 -0600, C Anthony Risinger anth...@xtfx.me wrote: a) mapped FS security policy (xattrs) causes `ldconfig` to abort()? root or normal user ... somehow `ldconfig` gets a duplicate inode while constructing the cache, even though it already de-duped (confirmed via gdb and grep -- only a single abort() in the source) b) unable to run `locale-gen` on *any* virtfs configuration? (strace) [...] mmap(NULL, 536870912, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb3aac63000 mmap(0x7fb3aac63000, 103860, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_FIXED, 3, 0) = -1 EINVAL (Invalid argument) cannot map archive header: Invalid argument c) package files containing device nodes fail (maybe this is expected ...); specifically `/lib/udev/devices/loop0` Is this with 9p2000.L ?. What is the guest kernel version ? -aneesh
Re: [Qemu-devel] [PATCH 07/12] exec: add missing breaks to the watch_mem_write
Thanks, incidentally:
Am 18.02.2012 18:11, schrieb Max Filippov:
Signed-off-by: Max Filippov jcmvb...@gmail.com
Reviewed-by is missing. Care to fix on your branch?
I don't see any Rb/Ab on the others as well, please check.
Andreas
---
exec.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/exec.c b/exec.c
index b81677a..f105b43 100644
--- a/exec.c
+++ b/exec.c
@@ -3289,9 +3289,15 @@ static void watch_mem_write(void *opaque,
target_phys_addr_t addr,
{
check_watchpoint(addr ~TARGET_PAGE_MASK, ~(size - 1), BP_MEM_WRITE);
switch (size) {
-case 1: stb_phys(addr, val);
-case 2: stw_phys(addr, val);
-case 4: stl_phys(addr, val);
+case 1:
+stb_phys(addr, val);
+break;
+case 2:
+stw_phys(addr, val);
+break;
+case 4:
+stl_phys(addr, val);
+break;
default: abort();
}
}
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
[Qemu-devel] [PATCH 10/12] target-xtensa: add DBREAK data breakpoints
Add DBREAKA/DBREAKC SRs and implement DBREAK breakpoints as debug
watchpoints.
This implementation is not fully compliant to ISA: when a breakpoint is
set to an unmapped/inaccessible memory address it generates TLB/memory
protection exception instead of debug exception.
See ISA, 4.7.7.3, 4.7.7.6 for more details.
Signed-off-by: Max Filippov jcmvb...@gmail.com
---
target-xtensa/cpu.h | 12
target-xtensa/helper.c| 41 +
target-xtensa/helpers.h |2 +
target-xtensa/op_helper.c | 62 +
target-xtensa/translate.c | 30 +
5 files changed, 147 insertions(+), 0 deletions(-)
diff --git a/target-xtensa/cpu.h b/target-xtensa/cpu.h
index 92441e3..fb8a727 100644
--- a/target-xtensa/cpu.h
+++ b/target-xtensa/cpu.h
@@ -128,6 +128,8 @@ enum {
DTLBCFG = 92,
IBREAKENABLE = 96,
IBREAKA = 128,
+DBREAKA = 144,
+DBREAKC = 160,
EPC1 = 177,
DEPC = 192,
EPS2 = 194,
@@ -175,12 +177,18 @@ enum {
#define DEBUGCAUSE_DBNUM 0xf00
#define DEBUGCAUSE_DBNUM_SHIFT 8
+#define DBREAKC_SB 0x8000
+#define DBREAKC_LB 0x4000
+#define DBREAKC_SB_LB (DBREAKC_SB | DBREAKC_LB)
+#define DBREAKC_MASK 0x3f
+
#define MAX_NAREG 64
#define MAX_NINTERRUPT 32
#define MAX_NLEVEL 6
#define MAX_NNMI 1
#define MAX_NCCOMPARE 3
#define MAX_TLB_WAY_SIZE 8
+#define MAX_NDBREAK 2
#define REGION_PAGE_MASK 0xe000
@@ -330,6 +338,9 @@ typedef struct CPUXtensaState {
int exception_taken;
+/* Watchpoints for DBREAK registers */
+CPUWatchpoint *cpu_watchpoint[MAX_NDBREAK];
+
CPU_COMMON
} CPUXtensaState;
@@ -365,6 +376,7 @@ int xtensa_get_physical_addr(CPUState *env,
uint32_t vaddr, int is_write, int mmu_idx,
uint32_t *paddr, uint32_t *page_size, unsigned *access);
void dump_mmu(FILE *f, fprintf_function cpu_fprintf, CPUState *env);
+void debug_exception_env(CPUState *new_env, uint32_t cause);
#define XTENSA_OPTION_BIT(opt) (((uint64_t)1) (opt))
diff --git a/target-xtensa/helper.c b/target-xtensa/helper.c
index 0a26f8d..2ef50d6 100644
--- a/target-xtensa/helper.c
+++ b/target-xtensa/helper.c
@@ -58,9 +58,44 @@ void xtensa_register_core(XtensaConfigList *node)
xtensa_cores = node;
}
+static uint32_t check_hw_breakpoints(CPUState *env)
+{
+unsigned i;
+
+for (i = 0; i env-config-ndbreak; ++i) {
+if (env-cpu_watchpoint[i]
+env-cpu_watchpoint[i]-flags BP_WATCHPOINT_HIT) {
+return DEBUGCAUSE_DB | (i DEBUGCAUSE_DBNUM_SHIFT);
+}
+}
+return 0;
+}
+
+static CPUDebugExcpHandler *prev_debug_excp_handler;
+
+static void breakpoint_handler(CPUState *env)
+{
+if (env-watchpoint_hit) {
+if (env-watchpoint_hit-flags BP_CPU) {
+uint32_t cause;
+
+env-watchpoint_hit = NULL;
+cause = check_hw_breakpoints(env);
+if (cause) {
+debug_exception_env(env, cause);
+}
+cpu_resume_from_signal(env, NULL);
+}
+}
+if (prev_debug_excp_handler) {
+prev_debug_excp_handler(env);
+}
+}
+
CPUXtensaState *cpu_xtensa_init(const char *cpu_model)
{
static int tcg_inited;
+static int debug_handler_inited;
CPUXtensaState *env;
const XtensaConfig *config = NULL;
XtensaConfigList *core = xtensa_cores;
@@ -84,6 +119,12 @@ CPUXtensaState *cpu_xtensa_init(const char *cpu_model)
xtensa_translate_init();
}
+if (!debug_handler_inited tcg_enabled()) {
+debug_handler_inited = 1;
+prev_debug_excp_handler =
+cpu_set_debug_excp_handler(breakpoint_handler);
+}
+
xtensa_irq_init(env);
qemu_init_vcpu(env);
return env;
diff --git a/target-xtensa/helpers.h b/target-xtensa/helpers.h
index afe39d4..48a741e 100644
--- a/target-xtensa/helpers.h
+++ b/target-xtensa/helpers.h
@@ -33,5 +33,7 @@ DEF_HELPER_3(wtlb, void, i32, i32, i32)
DEF_HELPER_1(wsr_ibreakenable, void, i32)
DEF_HELPER_2(wsr_ibreaka, void, i32, i32)
+DEF_HELPER_2(wsr_dbreaka, void, i32, i32)
+DEF_HELPER_2(wsr_dbreakc, void, i32, i32)
#include def-helper.h
diff --git a/target-xtensa/op_helper.c b/target-xtensa/op_helper.c
index 1feaaee..e184cf6 100644
--- a/target-xtensa/op_helper.c
+++ b/target-xtensa/op_helper.c
@@ -134,6 +134,14 @@ void HELPER(exception_cause_vaddr)(uint32_t pc, uint32_t
cause, uint32_t vaddr)
HELPER(exception_cause)(pc, cause);
}
+void debug_exception_env(CPUState *new_env, uint32_t cause)
+{
+if (xtensa_get_cintlevel(new_env) new_env-config-debug_level) {
+env = new_env;
+HELPER(debug_exception)(env-pc, cause);
+}
+}
+
void HELPER(debug_exception)(uint32_t pc, uint32_t cause)
{
unsigned level = env-config-debug_level;
@@ -700,3 +708,57 @@ void HELPER(wsr_ibreaka)(uint32_t i, uint32_t v)
}
env-sregs[IBREAKA + i] = v;
}
+
+static void set_dbreak(unsigned i, uint32_t
[Qemu-devel] [Bug 824650] Re: Latest GIT assert error in arp_table.c
Thanks.
The 5 lines in the patch are already there. (checked and recompiled,
still the same error!)
Got a work around at the moment by adding -net none to the command.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/824650
Title:
Latest GIT assert error in arp_table.c
Status in QEMU:
Fix Released
Bug description:
The latest git version of qemu (commit
8cc7c3952d4d0a681d8d4c3ac89a206a5bfd7f00) crashes after a few minutes.
All was fine up to a few days ago. This is wth both x86 and sparc
emulation, on an x86_64 host.
e.g. qemu-system-sparc -drive
file=netbsd5.0.2-sparc,index=0,media=disk,cache=unsafe -m 256 -boot c
-nographic -redir tcp:2232::22:
qemu-system-sparc: slirp/arp_table.c:75: arp_table_search: Assertion
`(ip_addr (__extension__ ({ register unsigned int __v, __x = (~(0xf
28)); if (__builtin_constant_p (__x)) __v = __x) 0xff00)
24) | (((__x) 0x00ff) 8) | (((__x) 0xff00) 8) |
(((__x) 0x00ff) 24)); else __asm__ (bswap %0 : =r (__v) :
0 (__x)); __v; }))) != 0' failed.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/824650/+subscriptions
[Qemu-devel] [PATCH 08/12] exec: fix check_watchpoint exiting cpu_loop
In case of BP_STOP_BEFORE_ACCESS watchpoint check_watchpoint intends to
signal EXCP_DEBUG exception on exit from cpu loop, but later overwrites
exception code by the cpu_resume_from_signal call.
Use cpu_loop_exit with BP_STOP_BEFORE_ACCESS watchpoints.
Signed-off-by: Max Filippov jcmvb...@gmail.com
---
exec.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/exec.c b/exec.c
index f105b43..ed091f3 100644
--- a/exec.c
+++ b/exec.c
@@ -3257,11 +3257,12 @@ static void check_watchpoint(int offset, int len_mask,
int flags)
tb_phys_invalidate(tb, -1);
if (wp-flags BP_STOP_BEFORE_ACCESS) {
env-exception_index = EXCP_DEBUG;
+cpu_loop_exit(env);
} else {
cpu_get_tb_cpu_state(env, pc, cs_base, cpu_flags);
tb_gen_code(env, pc, cs_base, cpu_flags, 1);
+cpu_resume_from_signal(env, NULL);
}
-cpu_resume_from_signal(env, NULL);
}
} else {
wp-flags = ~BP_WATCHPOINT_HIT;
--
1.7.7.6
[Qemu-devel] [PATCH 05/12] target-xtensa: implement instruction breakpoints
Add IBREAKA/IBREAKENABLE SRs and implement debug exception, BREAK and
BREAK.N instructions and IBREAK breakpoints.
IBREAK breakpoint address is considered constant for TB lifetime.
On IBREAKA/IBREAKENABLE change corresponding TBs are invalidated.
Signed-off-by: Max Filippov jcmvb...@gmail.com
---
target-xtensa/cpu.h |9 ++
target-xtensa/helper.c|2 +
target-xtensa/helpers.h |5 +++
target-xtensa/op_helper.c | 38 +
target-xtensa/translate.c | 68 +++--
5 files changed, 119 insertions(+), 3 deletions(-)
diff --git a/target-xtensa/cpu.h b/target-xtensa/cpu.h
index c77fe13..a18072b 100644
--- a/target-xtensa/cpu.h
+++ b/target-xtensa/cpu.h
@@ -126,6 +126,8 @@ enum {
RASID = 90,
ITLBCFG = 91,
DTLBCFG = 92,
+IBREAKENABLE = 96,
+IBREAKA = 128,
EPC1 = 177,
DEPC = 192,
EPS2 = 194,
@@ -196,6 +198,7 @@ enum {
EXC_KERNEL,
EXC_USER,
EXC_DOUBLE,
+EXC_DEBUG,
EXC_MAX
};
@@ -425,6 +428,7 @@ static inline int cpu_mmu_index(CPUState *env)
#define XTENSA_TBFLAG_RING_MASK 0x3
#define XTENSA_TBFLAG_EXCM 0x4
#define XTENSA_TBFLAG_LITBASE 0x8
+#define XTENSA_TBFLAG_DEBUG 0x10
static inline void cpu_get_tb_cpu_state(CPUState *env, target_ulong *pc,
target_ulong *cs_base, int *flags)
@@ -440,6 +444,11 @@ static inline void cpu_get_tb_cpu_state(CPUState *env,
target_ulong *pc,
(env-sregs[LITBASE] 1)) {
*flags |= XTENSA_TBFLAG_LITBASE;
}
+if (xtensa_option_enabled(env-config, XTENSA_OPTION_DEBUG)) {
+if (xtensa_get_cintlevel(env) env-config-debug_level) {
+*flags |= XTENSA_TBFLAG_DEBUG;
+}
+}
}
#include cpu-all.h
diff --git a/target-xtensa/helper.c b/target-xtensa/helper.c
index 973c268..0a26f8d 100644
--- a/target-xtensa/helper.c
+++ b/target-xtensa/helper.c
@@ -44,6 +44,7 @@ void cpu_reset(CPUXtensaState *env)
env-sregs[PS] = xtensa_option_enabled(env-config,
XTENSA_OPTION_INTERRUPT) ? 0x1f : 0x10;
env-sregs[VECBASE] = env-config-vecbase;
+env-sregs[IBREAKENABLE] = 0;
env-pending_irq_level = 0;
reset_mmu(env);
@@ -193,6 +194,7 @@ void do_interrupt(CPUState *env)
case EXC_KERNEL:
case EXC_USER:
case EXC_DOUBLE:
+case EXC_DEBUG:
qemu_log_mask(CPU_LOG_INT, %s(%d)
pc = %08x, a0 = %08x, ps = %08x, ccount = %08x\n,
__func__, env-exception_index,
diff --git a/target-xtensa/helpers.h b/target-xtensa/helpers.h
index 09ab332..afe39d4 100644
--- a/target-xtensa/helpers.h
+++ b/target-xtensa/helpers.h
@@ -3,6 +3,8 @@
DEF_HELPER_1(exception, void, i32)
DEF_HELPER_2(exception_cause, void, i32, i32)
DEF_HELPER_3(exception_cause_vaddr, void, i32, i32, i32)
+DEF_HELPER_2(debug_exception, void, i32, i32)
+
DEF_HELPER_1(nsa, i32, i32)
DEF_HELPER_1(nsau, i32, i32)
DEF_HELPER_1(wsr_windowbase, void, i32)
@@ -29,4 +31,7 @@ DEF_HELPER_2(itlb, void, i32, i32)
DEF_HELPER_2(ptlb, i32, i32, i32)
DEF_HELPER_3(wtlb, void, i32, i32, i32)
+DEF_HELPER_1(wsr_ibreakenable, void, i32)
+DEF_HELPER_2(wsr_ibreaka, void, i32, i32)
+
#include def-helper.h
diff --git a/target-xtensa/op_helper.c b/target-xtensa/op_helper.c
index 0605611..1feaaee 100644
--- a/target-xtensa/op_helper.c
+++ b/target-xtensa/op_helper.c
@@ -134,6 +134,19 @@ void HELPER(exception_cause_vaddr)(uint32_t pc, uint32_t
cause, uint32_t vaddr)
HELPER(exception_cause)(pc, cause);
}
+void HELPER(debug_exception)(uint32_t pc, uint32_t cause)
+{
+unsigned level = env-config-debug_level;
+
+env-pc = pc;
+env-sregs[DEBUGCAUSE] = cause;
+env-sregs[EPC1 + level - 1] = pc;
+env-sregs[EPS2 + level - 2] = env-sregs[PS];
+env-sregs[PS] = (env-sregs[PS] ~PS_INTLEVEL) | PS_EXCM |
+(level PS_INTLEVEL_SHIFT);
+HELPER(exception)(EXC_DEBUG);
+}
+
uint32_t HELPER(nsa)(uint32_t v)
{
if (v 0x8000) {
@@ -662,3 +675,28 @@ void HELPER(wtlb)(uint32_t p, uint32_t v, uint32_t dtlb)
split_tlb_entry_spec(v, dtlb, vpn, wi, ei);
xtensa_tlb_set_entry(env, dtlb, wi, ei, vpn, p);
}
+
+
+void HELPER(wsr_ibreakenable)(uint32_t v)
+{
+uint32_t change = v ^ env-sregs[IBREAKENABLE];
+unsigned i;
+
+for (i = 0; i env-config-nibreak; ++i) {
+if (change (1 i)) {
+tb_invalidate_phys_page_range(
+env-sregs[IBREAKA + i], env-sregs[IBREAKA + i] + 1, 0);
+}
+}
+env-sregs[IBREAKENABLE] = v ((1 env-config-nibreak) - 1);
+}
+
+void HELPER(wsr_ibreaka)(uint32_t i, uint32_t v)
+{
+if (env-sregs[IBREAKENABLE] (1 i) env-sregs[IBREAKA + i] != v) {
+tb_invalidate_phys_page_range(
+env-sregs[IBREAKA + i], env-sregs[IBREAKA + i] + 1, 0);
+tb_invalidate_phys_page_range(v, v + 1, 0);
+}
+env-sregs[IBREAKA + i] = v;
+}
diff --git a/target-xtensa/translate.c b/target-xtensa/translate.c
index da5fdb5..a438474 100644
---
[Qemu-devel] [PATCH 06/12] target-xtensa: add ICOUNT SR and debug exception
ICOUNT SR gets incremented on every instruction completion provided that
CINTLEVEL at the beginning of the instruction execution is lower than
ICOUNTLEVEL.
When ICOUNT would increment to 0 a debug exception is raised if
CINTLEVEL is lower than DEBUGLEVEL.
See ISA, 4.7.7.5 for more details.
Signed-off-by: Max Filippov jcmvb...@gmail.com
---
target-xtensa/cpu.h |6 +
target-xtensa/translate.c | 49 -
2 files changed, 54 insertions(+), 1 deletions(-)
diff --git a/target-xtensa/cpu.h b/target-xtensa/cpu.h
index a18072b..92441e3 100644
--- a/target-xtensa/cpu.h
+++ b/target-xtensa/cpu.h
@@ -142,6 +142,8 @@ enum {
DEBUGCAUSE = 233,
CCOUNT = 234,
PRID = 235,
+ICOUNT = 236,
+ICOUNTLEVEL = 237,
EXCVADDR = 238,
CCOMPARE = 240,
};
@@ -429,6 +431,7 @@ static inline int cpu_mmu_index(CPUState *env)
#define XTENSA_TBFLAG_EXCM 0x4
#define XTENSA_TBFLAG_LITBASE 0x8
#define XTENSA_TBFLAG_DEBUG 0x10
+#define XTENSA_TBFLAG_ICOUNT 0x20
static inline void cpu_get_tb_cpu_state(CPUState *env, target_ulong *pc,
target_ulong *cs_base, int *flags)
@@ -448,6 +451,9 @@ static inline void cpu_get_tb_cpu_state(CPUState *env,
target_ulong *pc,
if (xtensa_get_cintlevel(env) env-config-debug_level) {
*flags |= XTENSA_TBFLAG_DEBUG;
}
+if (xtensa_get_cintlevel(env) env-sregs[ICOUNTLEVEL]) {
+*flags |= XTENSA_TBFLAG_ICOUNT;
+}
}
}
diff --git a/target-xtensa/translate.c b/target-xtensa/translate.c
index a438474..3bf880f 100644
--- a/target-xtensa/translate.c
+++ b/target-xtensa/translate.c
@@ -63,6 +63,8 @@ typedef struct DisasContext {
unsigned used_window;
bool debug;
+bool icount;
+TCGv_i32 next_icount;
} DisasContext;
static TCGv_ptr cpu_env;
@@ -127,6 +129,8 @@ static const char * const sregnames[256] = {
[DEBUGCAUSE] = DEBUGCAUSE,
[CCOUNT] = CCOUNT,
[PRID] = PRID,
+[ICOUNT] = ICOUNT,
+[ICOUNTLEVEL] = ICOUNTLEVEL,
[EXCVADDR] = EXCVADDR,
[CCOMPARE] = CCOMPARE0,
[CCOMPARE + 1] = CCOMPARE1,
@@ -313,10 +317,13 @@ static void gen_check_privilege(DisasContext *dc)
static void gen_jump_slot(DisasContext *dc, TCGv dest, int slot)
{
tcg_gen_mov_i32(cpu_pc, dest);
+gen_advance_ccount(dc);
+if (dc-icount) {
+tcg_gen_mov_i32(cpu_SR[ICOUNT], dc-next_icount);
+}
if (dc-singlestep_enabled) {
gen_exception(dc, EXCP_DEBUG);
} else {
-gen_advance_ccount(dc);
if (slot = 0) {
tcg_gen_goto_tb(slot);
tcg_gen_exit_tb((tcg_target_long)dc-tb + slot);
@@ -580,6 +587,22 @@ static void gen_wsr_prid(DisasContext *dc, uint32_t sr,
TCGv_i32 v)
{
}
+static void gen_wsr_icount(DisasContext *dc, uint32_t sr, TCGv_i32 v)
+{
+if (dc-icount) {
+tcg_gen_mov_i32(dc-next_icount, v);
+} else {
+tcg_gen_mov_i32(cpu_SR[sr], v);
+}
+}
+
+static void gen_wsr_icountlevel(DisasContext *dc, uint32_t sr, TCGv_i32 v)
+{
+tcg_gen_andi_i32(cpu_SR[sr], v, 0xf);
+/* This can change tb-flags, so exit tb */
+gen_jumpi_check_loop_end(dc, -1);
+}
+
static void gen_wsr_ccompare(DisasContext *dc, uint32_t sr, TCGv_i32 v)
{
uint32_t id = sr - CCOMPARE;
@@ -617,6 +640,8 @@ static void gen_wsr(DisasContext *dc, uint32_t sr, TCGv_i32
s)
[PS] = gen_wsr_ps,
[DEBUGCAUSE] = gen_wsr_debugcause,
[PRID] = gen_wsr_prid,
+[ICOUNT] = gen_wsr_icount,
+[ICOUNTLEVEL] = gen_wsr_icountlevel,
[CCOMPARE] = gen_wsr_ccompare,
[CCOMPARE + 1] = gen_wsr_ccompare,
[CCOMPARE + 2] = gen_wsr_ccompare,
@@ -2493,10 +2518,14 @@ static void gen_intermediate_code_internal(
dc.is_jmp = DISAS_NEXT;
dc.ccount_delta = 0;
dc.debug = tb-flags XTENSA_TBFLAG_DEBUG;
+dc.icount = tb-flags XTENSA_TBFLAG_ICOUNT;
init_litbase(dc);
init_sar_tracker(dc);
reset_used_window(dc);
+if (dc.icount) {
+dc.next_icount = tcg_temp_local_new_i32();
+}
gen_icount_start();
@@ -2532,12 +2561,27 @@ static void gen_intermediate_code_internal(
gen_io_start();
}
+if (dc.icount) {
+int label = gen_new_label();
+
+tcg_gen_addi_i32(dc.next_icount, cpu_SR[ICOUNT], 1);
+tcg_gen_brcondi_i32(TCG_COND_NE, dc.next_icount, 0, label);
+tcg_gen_mov_i32(dc.next_icount, cpu_SR[ICOUNT]);
+if (dc.debug) {
+gen_debug_exception(dc, DEBUGCAUSE_IC);
+}
+gen_set_label(label);
+}
+
if (dc.debug) {
gen_ibreak_check(env, dc);
}
disas_xtensa_insn(dc);
++insn_count;
+if (dc.icount) {
+tcg_gen_mov_i32(cpu_SR[ICOUNT], dc.next_icount);
+}
if (env-singlestep_enabled) {
tcg_gen_movi_i32(cpu_pc, dc.pc);
gen_exception(dc, EXCP_DEBUG);
Re: [Qemu-devel] [PATCH 07/12] exec: add missing breaks to the watch_mem_write
Thanks, incidentally: Am 18.02.2012 18:11, schrieb Max Filippov: Signed-off-by: Max Filippov jcmvb...@gmail.com Reviewed-by is missing. Care to fix on your branch? Done. I don't see any Rb/Ab on the others as well, please check. A haven't got any other Rb/Ab. Thanks. -- Max
[Qemu-devel] [PATCH 09/12] exec: let cpu_watchpoint_insert accept larger watchpoints
Make cpu_watchpoint_insert accept watchpoints of any power-of-two size
up to the target page size.
Signed-off-by: Max Filippov jcmvb...@gmail.com
---
exec.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/exec.c b/exec.c
index ed091f3..80560fa 100644
--- a/exec.c
+++ b/exec.c
@@ -1443,7 +1443,8 @@ int cpu_watchpoint_insert(CPUState *env, target_ulong
addr, target_ulong len,
CPUWatchpoint *wp;
/* sanity checks: allow power-of-2 lengths, deny unaligned watchpoints */
-if ((len != 1 len != 2 len != 4 len != 8) || (addr ~len_mask)) {
+if ((len (len - 1)) || (addr ~len_mask) ||
+len == 0 || len TARGET_PAGE_SIZE) {
fprintf(stderr, qemu: tried to set invalid watchpoint at
TARGET_FMT_lx , len= TARGET_FMT_lu \n, addr, len);
return -EINVAL;
--
1.7.7.6
[Qemu-devel] [PATCH 01/12] target-xtensa: define TLB_TEMPLATE for MMU-less cores
TLB_TEMPLATE macro specifies TLB geometry in the core configuration.
Make TLB_TEMPLATE available for region protection core variants,
defining 1 way ITLB and DTLB with 8 entries each.
Signed-off-by: Max Filippov jcmvb...@gmail.com
---
target-xtensa/overlay_tool.h | 18 --
1 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/target-xtensa/overlay_tool.h b/target-xtensa/overlay_tool.h
index df19cc9..e7c4c3a 100644
--- a/target-xtensa/overlay_tool.h
+++ b/target-xtensa/overlay_tool.h
@@ -251,6 +251,8 @@
.nextint = XCHAL_NUM_EXTINTERRUPTS, \
.extint = EXTINTS
+#if XCHAL_HAVE_PTP_MMU
+
#define TLB_TEMPLATE(ways, refill_way_size, way56) { \
.nways = ways, \
.way_size = { \
@@ -268,11 +270,23 @@
#define DTLB(varway56) \
TLB_TEMPLATE(10, 1 XCHAL_DTLB_ARF_ENTRIES_LOG2, varway56)
-#if XCHAL_HAVE_PTP_MMU
#define TLB_SECTION \
.itlb = ITLB(XCHAL_HAVE_SPANNING_WAY), \
.dtlb = DTLB(XCHAL_HAVE_SPANNING_WAY)
-#else
+
+#elif XCHAL_HAVE_XLT_CACHEATTR || XCHAL_HAVE_MIMIC_CACHEATTR
+
+#define TLB_TEMPLATE { \
+.nways = 1, \
+.way_size = { \
+8, \
+} \
+}
+
+#define TLB_SECTION \
+.itlb = TLB_TEMPLATE, \
+.dtlb = TLB_TEMPLATE
+
#endif
#if (defined(TARGET_WORDS_BIGENDIAN) != 0) == (XCHAL_HAVE_BE != 0)
--
1.7.7.6
[Qemu-devel] [PATCH 03/12] target-xtensa: fetch 3rd opcode byte only when needed
According to ISA, 3.5.4, third opcode byte should not be fetched for
2-byte instructions.
Signed-off-by: Max Filippov jcmvb...@gmail.com
---
target-xtensa/translate.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/target-xtensa/translate.c b/target-xtensa/translate.c
index c81450d..6a0177f 100644
--- a/target-xtensa/translate.c
+++ b/target-xtensa/translate.c
@@ -749,7 +749,7 @@ static void disas_xtensa_insn(DisasContext *dc)
uint8_t b0 = ldub_code(dc-pc);
uint8_t b1 = ldub_code(dc-pc + 1);
-uint8_t b2 = ldub_code(dc-pc + 2);
+uint8_t b2 = 0;
static const uint32_t B4CONST[] = {
0x, 1, 2, 3, 4, 5, 6, 7, 8, 10, 12, 16, 32, 64, 128, 256
@@ -764,6 +764,7 @@ static void disas_xtensa_insn(DisasContext *dc)
HAS_OPTION(XTENSA_OPTION_CODE_DENSITY);
} else {
dc-next_pc = dc-pc + 3;
+b2 = ldub_code(dc-pc + 2);
}
switch (OP0) {
--
1.7.7.6
[Qemu-devel] [PATCH 07/12] exec: add missing breaks to the watch_mem_write
Signed-off-by: Max Filippov jcmvb...@gmail.com
---
exec.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/exec.c b/exec.c
index b81677a..f105b43 100644
--- a/exec.c
+++ b/exec.c
@@ -3289,9 +3289,15 @@ static void watch_mem_write(void *opaque,
target_phys_addr_t addr,
{
check_watchpoint(addr ~TARGET_PAGE_MASK, ~(size - 1), BP_MEM_WRITE);
switch (size) {
-case 1: stb_phys(addr, val);
-case 2: stw_phys(addr, val);
-case 4: stl_phys(addr, val);
+case 1:
+stb_phys(addr, val);
+break;
+case 2:
+stw_phys(addr, val);
+break;
+case 4:
+stl_phys(addr, val);
+break;
default: abort();
}
}
--
1.7.7.6
[Qemu-devel] [PATCH 12/12] target-xtensa: add breakpoint tests
Signed-off-by: Max Filippov jcmvb...@gmail.com --- tests/tcg/xtensa/Makefile |1 + tests/tcg/xtensa/test_break.S | 223 + 2 files changed, 224 insertions(+), 0 deletions(-) create mode 100644 tests/tcg/xtensa/test_break.S diff --git a/tests/tcg/xtensa/Makefile b/tests/tcg/xtensa/Makefile index 8713af1..7e1e619 100644 --- a/tests/tcg/xtensa/Makefile +++ b/tests/tcg/xtensa/Makefile @@ -23,6 +23,7 @@ CRT= crt.o vectors.o TESTCASES += test_b.tst TESTCASES += test_bi.tst #TESTCASES += test_boolean.tst +TESTCASES += test_break.tst TESTCASES += test_bz.tst TESTCASES += test_clamps.tst TESTCASES += test_fail.tst diff --git a/tests/tcg/xtensa/test_break.S b/tests/tcg/xtensa/test_break.S new file mode 100644 index 000..8a8db80 --- /dev/null +++ b/tests/tcg/xtensa/test_break.S @@ -0,0 +1,223 @@ +.include macros.inc + +#define debug_level 6 +#define debug_vector level6 + +test_suite break + +test break +set_vector debug_vector, 0 +rsila2, debug_level +_break 0, 0 + +set_vector debug_vector, 2f +rsila2, debug_level - 1 +1: +_break 0, 0 +test_fail +2: +rsr a2, ps +movia3, 0x1f +and a2, a2, a3 +movia3, 0x10 | debug_level +assert eq, a2, a3 +rsr a2, epc6 +movia3, 1b +assert eq, a2, a3 +rsr a2, debugcause +movia3, 0x8 +assert eq, a2, a3 +test_end + +test breakn +set_vector debug_vector, 0 +rsila2, debug_level +_break.n 0 + +set_vector debug_vector, 2f +rsila2, debug_level - 1 +1: +_break.n 0 +test_fail +2: +rsr a2, ps +movia3, 0x1f +and a2, a2, a3 +movia3, 0x10 | debug_level +assert eq, a2, a3 +rsr a2, epc6 +movia3, 1b +assert eq, a2, a3 +rsr a2, debugcause +movia3, 0x10 +assert eq, a2, a3 +test_end + +test ibreak +set_vector debug_vector, 0 +rsila2, debug_level +movia2, 1f +wsr a2, ibreaka0 +movia2, 1 +wsr a2, ibreakenable +isync +1: +rsila2, debug_level - 1 +movia2, 1f +wsr a2, ibreaka0 +movia2, 0 +wsr a2, ibreakenable +isync +1: +set_vector debug_vector, 2f +movia2, 1f +wsr a2, ibreaka0 +movia2, 1 +wsr a2, ibreakenable +isync +1: +test_fail +2: +rsr a2, ps +movia3, 0x1f +and a2, a2, a3 +movia3, 0x10 | debug_level +assert eq, a2, a3 +rsr a2, epc6 +movia3, 1b +assert eq, a2, a3 +rsr a2, debugcause +movia3, 0x2 +assert eq, a2, a3 +test_end + +test ibreak_priority +set_vector debug_vector, 2f +rsila2, debug_level - 1 +movia2, 1f +wsr a2, ibreaka0 +movia2, 1 +wsr a2, ibreakenable +isync +1: +break 0, 0 +test_fail +2: +rsr a2, debugcause +movia3, 0x2 +assert eq, a2, a3 +test_end + +test icount +set_vector debug_vector, 2f +rsila2, debug_level - 1 +movia2, -2 +wsr a2, icount +movia2, 1 +wsr a2, icountlevel +isync +rsila2, 0 +nop +1: +break 0, 0 +test_fail +2: +movia2, 0 +wsr a2, icountlevel +rsr a2, epc6 +movia3, 1b +assert eq, a2, a3 +rsr a2, debugcause +movia3, 0x1 +assert eq, a2, a3 +test_end + +.macro check_dbreak dr +rsr a2, epc6 +movia3, 1b +assert eq, a2, a3 +rsr a2, debugcause +movia3, 0x4 | (\dr 8) +assert eq, a2, a3 +movia2, 0 +wsr a2, dbreakc\dr +.endm + +.macro dbreak_test dr, ctl, break, access, op +set_vector debug_vector, 2f +rsila2, debug_level - 1 +movia2, \ctl +wsr a2, dbreakc\dr +movia2, \break +wsr a2, dbreaka\dr +movia2, \access +isync +1: +\op a3, a2, 0 +test_fail +2: +check_dbreak \dr +reset_ps +.endm + +test dbreak_exact +dbreak_test 0, 0x403f, 0xd07f, 0xd07f, l8ui +dbreak_test 1, 0x403e, 0xd07e, 0xd07e, l16ui +dbreak_test 0, 0x403c, 0xd07c, 0xd07c, l32i + +dbreak_test 1, 0x803f, 0xd07f, 0xd07f, s8i +dbreak_test 0, 0x803e, 0xd07e, 0xd07e, s16i +dbreak_test 1, 0x803c, 0xd07c, 0xd07c, s32i +test_end + +test dbreak_overlap +dbreak_test 0, 0x403f, 0xd07d, 0xd07c, l16ui +dbreak_test 1, 0x403f, 0xd07d, 0xd07c, l32i + +dbreak_test 0, 0x403e, 0xd07e, 0xd07f, l8ui +dbreak_test 1, 0x403e, 0xd07e, 0xd07c, l32i + +dbreak_test 0, 0x403c, 0xd07c, 0xd07d, l8ui +dbreak_test 1, 0x403c, 0xd07c, 0xd07c, l16ui + +dbreak_test 0, 0x4038, 0xd078, 0xd07b, l8ui +dbreak_test 1, 0x4038, 0xd078, 0xd07a, l16ui +dbreak_test 0, 0x4038, 0xd078, 0xd07c,
[Qemu-devel] [PATCH 02/12] target-xtensa: implement info tlb monitor command
Command dumps valid ITLB and DTLB entries.
Signed-off-by: Max Filippov jcmvb...@gmail.com
---
hmp-commands.hx|2 +-
monitor.c |4 +-
target-xtensa/cpu.h|1 +
target-xtensa/helper.c | 67
4 files changed, 71 insertions(+), 3 deletions(-)
diff --git a/hmp-commands.hx b/hmp-commands.hx
index 573b823..454d619 100644
--- a/hmp-commands.hx
+++ b/hmp-commands.hx
@@ -1341,7 +1341,7 @@ show i8259 (PIC) state
@item info pci
show emulated PCI device info
@item info tlb
-show virtual to physical memory mappings (i386, SH4, SPARC, and PPC only)
+show virtual to physical memory mappings (i386, SH4, SPARC, PPC, and Xtensa
only)
@item info mem
show the active virtual memory mappings (i386 only)
@item info jit
diff --git a/monitor.c b/monitor.c
index aadbdcb..2ac1965 100644
--- a/monitor.c
+++ b/monitor.c
@@ -1935,7 +1935,7 @@ static void tlb_info(Monitor *mon)
#endif
-#if defined(TARGET_SPARC) || defined(TARGET_PPC)
+#if defined(TARGET_SPARC) || defined(TARGET_PPC) || defined(TARGET_XTENSA)
static void tlb_info(Monitor *mon)
{
CPUState *env1 = mon_get_cpu();
@@ -2382,7 +2382,7 @@ static mon_cmd_t info_cmds[] = {
.mhandler.info = hmp_info_pci,
},
#if defined(TARGET_I386) || defined(TARGET_SH4) || defined(TARGET_SPARC) || \
-defined(TARGET_PPC)
+defined(TARGET_PPC) || defined(TARGET_XTENSA)
{
.name = tlb,
.args_type = ,
diff --git a/target-xtensa/cpu.h b/target-xtensa/cpu.h
index 0db83a6..c32bf35 100644
--- a/target-xtensa/cpu.h
+++ b/target-xtensa/cpu.h
@@ -344,6 +344,7 @@ void xtensa_tlb_set_entry(CPUState *env, bool dtlb,
int xtensa_get_physical_addr(CPUState *env,
uint32_t vaddr, int is_write, int mmu_idx,
uint32_t *paddr, uint32_t *page_size, unsigned *access);
+void dump_mmu(FILE *f, fprintf_function cpu_fprintf, CPUState *env);
#define XTENSA_OPTION_BIT(opt) (((uint64_t)1) (opt))
diff --git a/target-xtensa/helper.c b/target-xtensa/helper.c
index 2a0cb1a..973c268 100644
--- a/target-xtensa/helper.c
+++ b/target-xtensa/helper.c
@@ -540,3 +540,70 @@ int xtensa_get_physical_addr(CPUState *env,
return 0;
}
}
+
+static void dump_tlb(FILE *f, fprintf_function cpu_fprintf,
+CPUState *env, bool dtlb)
+{
+unsigned wi, ei;
+const xtensa_tlb *conf =
+dtlb ? env-config-dtlb : env-config-itlb;
+unsigned (*attr_to_access)(uint32_t) =
+xtensa_option_enabled(env-config, XTENSA_OPTION_MMU) ?
+mmu_attr_to_access : region_attr_to_access;
+
+for (wi = 0; wi conf-nways; ++wi) {
+uint32_t sz = ~xtensa_tlb_get_addr_mask(env, dtlb, wi) + 1;
+const char *sz_text;
+bool print_header = true;
+
+if (sz = 0x10) {
+sz = 20;
+sz_text = MB;
+} else {
+sz = 10;
+sz_text = KB;
+}
+
+for (ei = 0; ei conf-way_size[wi]; ++ei) {
+const xtensa_tlb_entry *entry =
+xtensa_tlb_get_entry(env, dtlb, wi, ei);
+
+if (entry-asid) {
+unsigned access = attr_to_access(entry-attr);
+
+if (print_header) {
+print_header = false;
+cpu_fprintf(f, Way %u (%d %s)\n, wi, sz, sz_text);
+cpu_fprintf(f,
+\tVaddr Paddr ASID Attr RWX\n
+\t-- -- ---\n);
+}
+cpu_fprintf(f,
+\t0x%08x 0x%08x 0x%02x 0x%02x %c%c%c\n,
+entry-vaddr,
+entry-paddr,
+entry-asid,
+entry-attr,
+(access PAGE_READ) ? 'R' : '-',
+(access PAGE_WRITE) ? 'W' : '-',
+(access PAGE_EXEC) ? 'X' : '-');
+}
+}
+}
+}
+
+void dump_mmu(FILE *f, fprintf_function cpu_fprintf, CPUState *env)
+{
+if (xtensa_option_bits_enabled(env-config,
+XTENSA_OPTION_BIT(XTENSA_OPTION_REGION_PROTECTION) |
+XTENSA_OPTION_BIT(XTENSA_OPTION_REGION_TRANSLATION) |
+XTENSA_OPTION_BIT(XTENSA_OPTION_MMU))) {
+
+cpu_fprintf(f, ITLB:\n);
+dump_tlb(f, cpu_fprintf, env, false);
+cpu_fprintf(f, \nDTLB:\n);
+dump_tlb(f, cpu_fprintf, env, true);
+} else {
+cpu_fprintf(f, No TLB for this CPU core\n);
+}
+}
--
1.7.7.6
[Qemu-devel] [Bug 919242] Re: qemu-img convert to VDI corrupts image
** Changed in: qemu
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/919242
Title:
qemu-img convert to VDI corrupts image
Status in QEMU:
Fix Released
Status in “qemu-kvm” package in Ubuntu:
Fix Committed
Bug description:
Hello, thanks to all for the great work on qemu, an excellent
technology.
There appears to be a serious bug in qemu-img 1.0, yielding silent
corruption when converting an image to VDI format. After conversion
to VDI, an image with WinNT4sp6 (NTFS) yields a boot failure (details
below) -- presumably due to some corruption, since the image works
fine as the source .vhd (from virtualPC6), and also when converted to
QCOW2 or VMDK format.
TEST CASE:
OS X 10.6.8 on Intel i5
Qemu 1.0 from mac ports (macports.org)
The source BaseDrive.vhd image is from VirtualPC6 (Mac)
$ qemu-img info BaseDrive.vhd
image: BaseDrive.vhd
file format: vpc
virtual size: 2.0G (2096898048 bytes)
disk size: 190M
The image has a fresh Windows NT4sp6 NTFS installation. It's from VirtualPC6
(Connectix) inside a .vhdp package directory on OS X. Convert via:
qemu-img convert -f vpc -O vdi BaseDrive.vhd BaseDrive.vdi
Now run the resulting vdi file with:
qemu-system-i386 -cpu pentium BaseDrive.vdi
On boot, NT4 crashes with
STOP: c26c {Unable to Load Device Driver}
\??\C:\WINNT\system32\win32k.sys device driver could not be loaded.
Error Status was 0xc221
Both qemu 1.0, and VirtualBox 4.1.8 yield the same error on this VDI.
Conversion of the exact same image to QCOW2 or VMDK format yields a working
image (ie. qemu and VirtualBox boot fine):
qemu-img convert -f vpc -O qcow2 BaseDrive.vhd BaseDrive.qcow2
OR
qemu-img convert -f vpc -O vmdk BaseDrive.vhd BaseDrive.vmdk
Furthermore, I tested converting from raw, qcow2, and vmdk to vdi,
and in all these cases the original format boots, but the converted
VDI fails to boot as above.
Along the way, I think I also tested a VDI natively created and
installed from VirtualBox, which did boot fine in qemu. Thus the
problem appears to be not in qemu-system-i386 reading the VDI, rather
in the qemu-img conversion to VDI.
SEVERITY: CRITICAL
The severity of this bug is critical as it appears to produce a silently
corrupted VDI image. (which is presumably the cause of the boot failure;
though I have not explicitly check-disked the resulting VDI image). It also
impedes easy inter-use between qemu and VirtualBox.
WORKAROUND:
The workaround is to use the VMDK format instead of VDI.
VMDK is supported by both qemu and VirtualBox (and vmWare).
I can supply a test VHD/QCOW2/VMDK image if desired to reproduce the bug.
(but it's large, 190M)
-- jbthiel
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/919242/+subscriptions
[Qemu-devel] [Bug 919242] Re: qemu-img convert to VDI corrupts image
Hi Serge,
yes, please queue it up. The fix was committed to QEMU git master,
but it is still missing in QEMU 1.0.1 and older versions.
So if you have a QEMU patch queue for Ubuntu , it's needed there.
Thanks,
Stefan
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/919242
Title:
qemu-img convert to VDI corrupts image
Status in QEMU:
Fix Released
Status in “qemu-kvm” package in Ubuntu:
Fix Committed
Bug description:
Hello, thanks to all for the great work on qemu, an excellent
technology.
There appears to be a serious bug in qemu-img 1.0, yielding silent
corruption when converting an image to VDI format. After conversion
to VDI, an image with WinNT4sp6 (NTFS) yields a boot failure (details
below) -- presumably due to some corruption, since the image works
fine as the source .vhd (from virtualPC6), and also when converted to
QCOW2 or VMDK format.
TEST CASE:
OS X 10.6.8 on Intel i5
Qemu 1.0 from mac ports (macports.org)
The source BaseDrive.vhd image is from VirtualPC6 (Mac)
$ qemu-img info BaseDrive.vhd
image: BaseDrive.vhd
file format: vpc
virtual size: 2.0G (2096898048 bytes)
disk size: 190M
The image has a fresh Windows NT4sp6 NTFS installation. It's from VirtualPC6
(Connectix) inside a .vhdp package directory on OS X. Convert via:
qemu-img convert -f vpc -O vdi BaseDrive.vhd BaseDrive.vdi
Now run the resulting vdi file with:
qemu-system-i386 -cpu pentium BaseDrive.vdi
On boot, NT4 crashes with
STOP: c26c {Unable to Load Device Driver}
\??\C:\WINNT\system32\win32k.sys device driver could not be loaded.
Error Status was 0xc221
Both qemu 1.0, and VirtualBox 4.1.8 yield the same error on this VDI.
Conversion of the exact same image to QCOW2 or VMDK format yields a working
image (ie. qemu and VirtualBox boot fine):
qemu-img convert -f vpc -O qcow2 BaseDrive.vhd BaseDrive.qcow2
OR
qemu-img convert -f vpc -O vmdk BaseDrive.vhd BaseDrive.vmdk
Furthermore, I tested converting from raw, qcow2, and vmdk to vdi,
and in all these cases the original format boots, but the converted
VDI fails to boot as above.
Along the way, I think I also tested a VDI natively created and
installed from VirtualBox, which did boot fine in qemu. Thus the
problem appears to be not in qemu-system-i386 reading the VDI, rather
in the qemu-img conversion to VDI.
SEVERITY: CRITICAL
The severity of this bug is critical as it appears to produce a silently
corrupted VDI image. (which is presumably the cause of the boot failure;
though I have not explicitly check-disked the resulting VDI image). It also
impedes easy inter-use between qemu and VirtualBox.
WORKAROUND:
The workaround is to use the VMDK format instead of VDI.
VMDK is supported by both qemu and VirtualBox (and vmWare).
I can supply a test VHD/QCOW2/VMDK image if desired to reproduce the bug.
(but it's large, 190M)
-- jbthiel
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/919242/+subscriptions
[Qemu-devel] [Bug 899143] Re: Raw img not recognized by Windows
** Changed in: qemu Status: New = Invalid -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/899143 Title: Raw img not recognized by Windows Status in QEMU: Invalid Bug description: Hi, The installation process of Windows (XP/Vista/7) doesn’t seem to recognize a raw img generated by qemu-img. The installer does not see any hard drive... The problem exists only with a raw img but not with a vmdk for instance. Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/899143/+subscriptions
[Qemu-devel] [patch] qemu-1.0.1/VERSION
Hello, The VERSION file in stable release qemu-1.0.1 has what I believe might be a typo: 1.0,1 rather than 1.0.1. This is causing a parsing issue for windres.exe in Win32 which chokes on: #define CONFIG_FILEVERSION 1,0,1,0,1,0 #define CONFIG_PRODUCTVERSION 1,0,1,0,1,0 when it should be seeing this: #define CONFIG_FILEVERSION 1,0,1,0 #define CONFIG_PRODUCTVERSION 1,0,1,0 Patch: --- VERSION.ORIG2012-02-18 18:56:16.62500 -0500 +++ VERSION 2012-02-18 18:56:31.609375000 -0500 @@ -1 +1 @@ -1.0,1 +1.0.1
[Qemu-devel] [Bug 935945] [NEW] SLIRP still not working for win32
Public bug reported: SLIRP has not worked since 0.14.1 (broken since the move to gthread/gio from the glib library which inherited -mms-bitfields on MinGW32 breaking bit padding on TCP/UDP packets). Patches attempting to reverse effects of GCC's -mms-bitfields do not seem to fix SLIRP. Here is an example slirp debug log: arp_table_add... ip = 0x502000a hw addr = 52:54:00:12:34:56 arp_table_add... ip = 0x502000a hw addr = 52:54:00:12:34:56 m_get... m = 5bd4f0b8 ip_input... m = 5bd4f0b8 m_len = 84 icmp_input... m = 5bd4f0b8 m_len = 84 icmp_type = 8 ip_output... so = 0 m0 = 5bd4f0b8 if_output... so = 0 ifm = 5bd4f0b8 if_start... arp_table_search... ip = 0x502000a found hw addr = 52:54:00:12:34:56 m_free... m = 5bd4f0b8 m_get... m = 5bd4f0b8 ip_input... m = 5bd4f0b8 m_len = 84 icmp_input... m = 5bd4f0b8 m_len = 84 icmp_type = 8 ip_output... so = 0 m0 = 5bd4f0b8 if_output... so = 0 ifm = 5bd4f0b8 if_start... arp_table_search... ip = 0x502000a found hw addr = 52:54:00:12:34:56 m_free... m = 5bd4f0b8 arp_table_add... ip = 0x502000a hw addr = 52:54:00:12:34:56 m_get... m = 5bd4f0b8 ip_input... m = 5bd4f0b8 m_len = 55 udp_input... m = 5bd4f0b8 iphlen = 20 sosendto... so = 5bd104a0 m = 5bd4f0b8 sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 m_free... m = 0 ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... m_get... m = 5bd4f728 ip_input... m = 5bd4f728 m_len = 55 udp_input... m = 5bd4f728 iphlen = 20 sosendto... so = 5bd104a0 m = 5bd4f728 sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 m_free... m = 5bd4f0b8 ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... m_get... m = 5bd4f0b8 ip_input... m = 5bd4f0b8 m_len = 55 udp_input... m = 5bd4f0b8 iphlen = 20 sosendto... so = 5bd104a0 m = 5bd4f0b8 sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 m_free... m = 5bd4f728 ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... [repeated] ** Affects: qemu Importance: Undecided Status: New ** Tags: cygwin mingw mingw32 net slirp user win32 windows -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/935945 Title: SLIRP still not working for win32 Status in QEMU: New Bug description: SLIRP has not worked since 0.14.1 (broken since the move to gthread/gio from the glib library which inherited -mms-bitfields on MinGW32 breaking bit padding on TCP/UDP packets). Patches attempting to reverse effects of GCC's -mms-bitfields do not seem to fix SLIRP. Here is an example slirp debug log: arp_table_add... ip = 0x502000a hw addr = 52:54:00:12:34:56 arp_table_add... ip = 0x502000a hw addr = 52:54:00:12:34:56 m_get... m = 5bd4f0b8 ip_input... m = 5bd4f0b8 m_len = 84 icmp_input... m = 5bd4f0b8 m_len = 84 icmp_type = 8 ip_output... so = 0 m0 = 5bd4f0b8 if_output... so = 0 ifm = 5bd4f0b8 if_start... arp_table_search... ip = 0x502000a found hw addr = 52:54:00:12:34:56 m_free... m = 5bd4f0b8 m_get... m = 5bd4f0b8 ip_input... m = 5bd4f0b8 m_len = 84 icmp_input... m = 5bd4f0b8 m_len = 84 icmp_type = 8 ip_output... so = 0 m0 = 5bd4f0b8 if_output... so = 0 ifm = 5bd4f0b8 if_start... arp_table_search... ip = 0x502000a found hw addr = 52:54:00:12:34:56 m_free... m = 5bd4f0b8 arp_table_add... ip = 0x502000a hw addr = 52:54:00:12:34:56 m_get... m = 5bd4f0b8 ip_input... m = 5bd4f0b8 m_len = 55 udp_input... m = 5bd4f0b8 iphlen = 20 sosendto... so = 5bd104a0 m = 5bd4f0b8 sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 m_free... m = 0 ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... m_get... m = 5bd4f728 ip_input... m = 5bd4f728 m_len = 55 udp_input... m = 5bd4f728 iphlen = 20 sosendto... so = 5bd104a0 m = 5bd4f728 sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 m_free... m = 5bd4f0b8 ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo...
[Qemu-devel] [Bug 935945] Re: SLIRP still not working for win32
Here is a slirp debug log from the latest development version as of 2012-02-19 (last git commit logged 2012-02-15): tcp_listen... haddr = 17f hport = 11555 laddr = 502000a lport = 5632 flags = 1000 ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... arp_table_add... ip = 0x502000a hw addr = 52:54:00:12:34:56 ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... arp_table_add... ip = 0x502000a hw addr = 52:54:00:12:34:56 m_get... m = 1cac1f0 ip_input... m = 1cac1f0 m_len = 55 udp_input... m = 1cac1f0 iphlen = 20 sosendto... so = 5bd10f28 m = 1cac1f0 sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 m_free... m = 0 ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... m_get... m = 1cac850 ip_input... m = 1cac850 m_len = 55 udp_input... m = 1cac850 iphlen = 20 sosendto... so = 5bd10f28 m = 1cac850 sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 m_free... m = 1cac1f0 ip_slowtimo... tcp_slowtimo...
[Qemu-devel] [Bug 935945] Re: SLIRP still not working for win32
So we're revisiting ms-bitfields issue: http://patchwork.ozlabs.org/patch/109989/ -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/935945 Title: SLIRP still not working for win32 Status in QEMU: New Bug description: SLIRP has not worked since 0.14.1 (broken since the move to gthread/gio from the glib library which inherited -mms-bitfields on MinGW32 breaking bit padding on TCP/UDP packets). Patches attempting to reverse effects of GCC's -mms-bitfields do not seem to fix SLIRP. Here is an example slirp debug log: arp_table_add... ip = 0x502000a hw addr = 52:54:00:12:34:56 arp_table_add... ip = 0x502000a hw addr = 52:54:00:12:34:56 m_get... m = 5bd4f0b8 ip_input... m = 5bd4f0b8 m_len = 84 icmp_input... m = 5bd4f0b8 m_len = 84 icmp_type = 8 ip_output... so = 0 m0 = 5bd4f0b8 if_output... so = 0 ifm = 5bd4f0b8 if_start... arp_table_search... ip = 0x502000a found hw addr = 52:54:00:12:34:56 m_free... m = 5bd4f0b8 m_get... m = 5bd4f0b8 ip_input... m = 5bd4f0b8 m_len = 84 icmp_input... m = 5bd4f0b8 m_len = 84 icmp_type = 8 ip_output... so = 0 m0 = 5bd4f0b8 if_output... so = 0 ifm = 5bd4f0b8 if_start... arp_table_search... ip = 0x502000a found hw addr = 52:54:00:12:34:56 m_free... m = 5bd4f0b8 arp_table_add... ip = 0x502000a hw addr = 52:54:00:12:34:56 m_get... m = 5bd4f0b8 ip_input... m = 5bd4f0b8 m_len = 55 udp_input... m = 5bd4f0b8 iphlen = 20 sosendto... so = 5bd104a0 m = 5bd4f0b8 sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 m_free... m = 0 ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... m_get... m = 5bd4f728 ip_input... m = 5bd4f728 m_len = 55 udp_input... m = 5bd4f728 iphlen = 20 sosendto... so = 5bd104a0 m = 5bd4f728 sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 m_free... m = 5bd4f0b8 ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... m_get... m = 5bd4f0b8 ip_input... m = 5bd4f0b8 m_len = 55 udp_input... m = 5bd4f0b8 iphlen = 20 sosendto... so = 5bd104a0 m = 5bd4f0b8 sendto()ing, addr.sin_port=53, addr.sin_addr.s_addr=8.8.8.8 m_free... m = 5bd4f728 ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... ip_slowtimo... tcp_slowtimo... [repeated] To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/935945/+subscriptions
Re: [Qemu-devel] Curious about this code in the ohci_service_td()
2012/2/19 Peter Maydell peter.mayd...@linaro.org:
On 18 February 2012 16:19, Wei Yang weiyang.ker...@gmail.com wrote:
I am reading the code in ohci_service_td().
There is a calculation of the length of the buffer.
if ((td.cbp 0xf000) != (td.be 0xf000)) {
len = (td.be 0xfff) + 0x1001 - (td.cbp 0xfff);
} else {
len = (td.be - td.cbp) + 1;
}
I am curious about the first case.
So the td.be could be less than the tb.cbp?
Thanks Peter.
Yes. See the OHCI spec:
ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf
and specifically section 4.3: the data buffer described by a
TD may span two separate physically disjoint pages. The exact
I see this sentence. So this sentence means.
For example, I have
page 1
page 2
page 3
which contains the content of the TD. (In the guest I think.)
TD buffer could locate at page1 and page 3, without touching page 2?
And I am wondering, the buffer in the guest is page aligned or not?
In struct OHCIState, there is the usb_buf[8192].
I think this is the maximum packet size defined in the MPS field in the ED.
The size is exactly 2 pages, if the page is 4K.
This usb_buf is the buffer in the HC I think, so each time we use ohci_copy_td()
to get the content from the guest and put it in usb_buf.
Now come to my previous question again.
tb.cbp and tb.be is pointing to the address in the guest.
This means
tb.be may point to page 1
while
tb.cbp may point to page 3?
So tb.cbp tb.be?
page crossing behaviour is described more specifically in
section 4.3.1.3.1. (We don't implement it quite as described
there because we try to handle the whole data buffer at once
rather than byte-by-byte, but the effect is the same. See
also the code later on in the function under 'Transmission
succeeded' which updates td.cbp to the right value if we only
managed to send part of the data.)
I quoted it from the specification.
===
If during the data transfer the buffer address contained in the HC’s
working copy of
CurrentBufferPointer crosses a 4K boundary, the upper 20 bits of
Buffer End are copied to the
working value of CurrentBufferPointer causing the next buffer address
to be the 0th byte in the
same 4K page that contains the last byte of the buffer (the 4K
boundary crossing may occur
within a data packet transfer.)
===
As I asked before, if the buffer is paged aligned, the
CurrentBufferPointer is pointing to the
beginning of one page.
Since the MPS is 8K, so Buffer End just has two cases.
Page A Page B
|---||---|
^ ^ ^
| | case 1 | case 2
cbp bebe
PageA and PageB are disjoint pages.
For case 1, it is easy to calculate the buffer size.
For case 2, since the page maybe disjoint, so after copy the first page,
cbp is set to the start of the next page. If we just calculate
cbp = cbp + 0x1000
this may not be the start address of PageB.
I think my assumption is based on
1. buffer size is less than the MPS, which is 8k.
2. the cbp is page aligned.
Hmm I looked at the code again.
len = (td.be 0xfff) + 0x1001 - (td.cbp 0xfff);
If cbp is page aligned, then no need to do (td.cbp 0xfff)?
-- PMM
--
Richard Yang
Help You, Help Me
